From owner-v6ops@ops.ietf.org Sat May 1 01:21: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 BAA26603 for ; Sat, 1 May 2004 01:21:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJmuh-000Msn-V7 for v6ops-data@psg.com; Sat, 01 May 2004 05:19:47 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJmuY-000Mrc-8H for v6ops@ops.ietf.org; Sat, 01 May 2004 05:19:38 +0000 Received: (qmail 20843 invoked from network); 1 May 2004 05:10:37 -0000 Received: from unknown (HELO Amy) (159.226.39.104) by mail.ict.ac.cn with SMTP; 1 May 2004 05:10:37 -0000 From: "Liu Min" To: "'Pekka Savola'" , Subject: RE: POLL: Consensus for moving forward with Teredo? Date: Sat, 1 May 2004 13:19:19 +0800 Message-ID: <004301c42f3b$dac4c100$7774a8c0@Amy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think NAT traversal in IPv6 transition is a very important issue and should be solved. Although Teredo needs special IPv6 address prefix and need Teredo relay in every IPv6 network, it is reasonably secure and already out there. There are also other mechanisms for this issue and each of them has different properties and applying scenarios. We should go forward with these transition mechanisms and let the market to make the final decision. Best Wishes, Liu Min Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240 E-mail: liumin@ict.ac.cn > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Pekka Savola > Sent: Saturday, May 01, 2004 1:32 AM > To: v6ops@ops.ietf.org > Subject: POLL: Consensus for moving forward with Teredo? > > Hi, > > (co-chair hat on) > > As identified in the scenarios analysis at IETF59 and in > draft-savola-v6ops-tunneling-01.txt, there appears to a need which > cannot be filled by another mechanism for Teredo at least in one major > Unmanaged scenario. > > Is there rough consensus to move forward with Teredo? (i.e., to adopt > it as WG document in this WG or elsewhere, for Proposed Standard.) > > The main issue raised has been to call for a more extensive analysis > for the deployment implications of native, 6to4, and Teredo. There is > already discussion of this in the Unmanaged Analysis document. There > seemed to be very little energy or interest in the WG to drive this > much further. > > The options regarrding Teredo at this stage seem to be: > > a) Go forward with Teredo, hone the deployment implications in the > unmanaged analysis in parallel (if and as appropriate), > > b) Conclude that there is no sufficiently strong need for Teredo, and > not support its advancement (for PS) at this stage, or > > c) Decide that we need to analyze the scenarios or deployment more > before being able to make a decision. > > If so, please state where you believe more analysis is needed.. > and volunteer if possible :) > > If you have an opinion, please state it within a week, i.e., by next > Friday, 7th May. > > Thanks! > > (co-chair hat off) > > From owner-v6ops@ops.ietf.org Sat May 1 01:37: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 BAA27227 for ; Sat, 1 May 2004 01:37:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJnBX-000P94-SQ for v6ops-data@psg.com; Sat, 01 May 2004 05:37:11 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJnBW-000P8i-Ja for v6ops@ops.ietf.org; Sat, 01 May 2004 05:37:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i414mqp31411; Sat, 1 May 2004 07:48:52 +0300 Date: Sat, 1 May 2004 07:48:52 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?] In-Reply-To: <030601c42f28$320d5b70$640a0a0a@consulintel.es> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 1 May 2004, JORDI PALET MARTINEZ wrote: > I wonder if Teredo could take advantage of the auto-discovery idea > (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt), > making sure that if required both the 6to4, TB/TS/TSP, ISATAP and > the Teredo relays, can coexist automatically in the same box. This > could easily simplify the deployment and be an important > multiplicative factor. > > So, I will suggest a new option "a.bis)": The idea is to make a very > quick move on defining a solution for the auto-discovery, and > include this in a revised Teredo version (same with ISATAP, TSP, > etc.). > [...] > > Christian, Pekka what do you think ? (I've not read the latest > versions of Teredo, so I'm not sure if what I'm saying is actually > meaningful, but I understand that the server/relay need to be > pre-configured, so can we make it auto-discovered ?, indeed we > didn't included Teredo in our I-D, but may be an option for the next > revision). I'm having difficulty figuring out what you mean, yes :). Relay doesn't need to be configured. Server must be configured, and typically would probably have to be unless there would be an anycast prefix which could be used to find the closest serving server (like with 6to4 relays). (Vendors shipping products which use their server pre-configure this so no user config is needed.) Anycast discovery was removed from the spec some time ago, but it it's deemed useful, it could maybe be added back so that you would only use the anycast address to discover the relay, and use a unicast address after that (or something). With regard to the end-points, you could devise a tunnel server solution that's usable by Teredo clients out-of-the-box. If you hijack a popular Teredo server's IP address, you can even force your users to use the tunnel server ;-). -- 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-v6ops@ops.ietf.org Sat May 1 01:44: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 BAA27515 for ; Sat, 1 May 2004 01:44:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJnIL-0000bB-1N for v6ops-data@psg.com; Sat, 01 May 2004 05:44:13 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJnIJ-0000aD-Sv for v6ops@ops.ietf.org; Sat, 01 May 2004 05:44:12 +0000 Received: (qmail 21995 invoked from network); 1 May 2004 05:35:10 -0000 Received: from unknown (HELO wxg) (159.226.39.69) by mail.ict.ac.cn with SMTP; 1 May 2004 05:35:10 -0000 Message-ID: <000801c42f3f$d3ca9290$4527e29f@wxg> From: "Eiffel Wu" To: Subject: Re: POLL: Consensus for moving forward with Teredo? Date: Sat, 1 May 2004 13:47:45 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C42F82.E1E45CB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=BAYES_00,FORGED_OUTLOOK_TAGS, MIME_BASE64_TEXT,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C42F82.E1E45CB0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KGMpDQpyZWFzb25zIGFzIGZvbGxvd2luZzoNCg0KMS5UZXJlZG8gc3BlY2lmaWNhdGlvbiBwcm92 aWRlIElQdjYgY29ubmVjdGl2aXR5IGZvciBOQVQgdXNlcnMgYW5kIHBlcmZlY3Qgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbiwNCiAgYnV0IGl0IGRpZCBub3QgaW50cm9kdWNlIGhvdyB0byBwcm92aWRl IG5hbWluZyBzZXJ2aWNlLg0KMi5UZXJlZG8gUmVsYXkgd2hpY2ggYWR2ZXJ0aXNlcyByZWFjaGFi aWxpdHkgb2YgdGhlIFRlcmVkbyBzZXJ2aWNlDQogIHByZWZpeCBvdmVyIElQdjYsIG1ha2UgdGhl IGRlcGxveW1lbnQgb2YgVGVyZWRvIHNlcnZpY2UgZGlmZmN1bHQgYW5kIGV4cGVuc2l2ZS4NCjMu SVB2NiBhZGRyZXNzIG9mIFRlcmVkbyBjbGllbnQgaXMgY2hhbmdlZnVsIHdoaWxlIG1hbnkgdXNl cnMgd2FudCB0aGUgSVB2NiBhZGRyZXNzDQogIHRvIGJlIHBlcm1hbmVudC4NCjQuVGVyZWRvIGRv ZXMgbm90IHN1cHBvcnQgc3ltbWV0cmljIE5BVC4gTXIuSHVpdGVtYSBzYWlkIHRoYXQgaGUgY2Fu IGJ1eSBhbm90aGVyIGRpZmZlcmVudCBOQVQgb3IgbW9kaWZ5DQogIHRoZSBzeW1tZXRyaWMgTkFU LiBJIHRoaW5rIGEgZ29vZCBtZWNoYW5pc20gc2hvdWxkIHNhdGlzZnkgdGhlIHVzZXJzLCBub3Qg YmUgc2F0aXNmaWVkIGJ5IHRoZSB1c2Vycy4NCg0Kc28gaSB0aGluayB0aGVyZSBzaG91bGQgYmUg c29tZSBvdGhlciBiZXR0ZXIgbWVjaGFuaXNtcy4NCml0IGlzIGVhcmx5IHRvIG1ha2UgZGVjaXNp b24gbm93LCBtb3JlIGRldGFpbGVkIGFuZCBkZWVwbHkgZGlzY3Vzc2lvbiBpcyBuZWVkZWQuDQoN Cg0KRWlmZmVsIFd1DQo= ------=_NextPart_000_0005_01C42F82.E1E45CB0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg Y29sb3I9IzAwMDBmZiBzaXplPTQ+KGMpPEJSPnJlYXNvbnMgYXMgDQpmb2xsb3dpbmc6PC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBjb2xvcj0jMDAwMGZmIHNpemU9ND4xLlRlcmVkbyBzcGVjaWZpY2F0aW9uIA0KcHJvdmlk ZSBJUHY2IGNvbm5lY3Rpdml0eSBmb3IgTkFUIHVzZXJzIGFuZCBwZXJmZWN0IHNlY3VyaXR5IA0K Y29uc2lkZXJhdGlvbiw8QlI+Jm5ic3A7IGJ1dCBpdCBkaWQgbm90IGludHJvZHVjZSBob3cgdG8g cHJvdmlkZSBuYW1pbmcgDQpzZXJ2aWNlLjxCUj4yLlRlcmVkbyBSZWxheSB3aGljaCBhZHZlcnRp c2VzIHJlYWNoYWJpbGl0eSBvZiB0aGUgVGVyZWRvIA0Kc2VydmljZTxCUj4mbmJzcDsgcHJlZml4 IG92ZXIgSVB2NiwgbWFrZSB0aGUgZGVwbG95bWVudCBvZiBUZXJlZG8gc2VydmljZSANCmRpZmZj dWx0IGFuZCBleHBlbnNpdmUuPEJSPjMuSVB2NiBhZGRyZXNzIG9mIFRlcmVkbyBjbGllbnQgaXMg Y2hhbmdlZnVsIHdoaWxlIA0KbWFueSB1c2VycyB3YW50IHRoZSBJUHY2IGFkZHJlc3M8QlI+Jm5i c3A7IHRvIGJlIHBlcm1hbmVudC48QlI+NC5UZXJlZG8gZG9lcyBub3QgDQpzdXBwb3J0IHN5bW1l dHJpYyBOQVQuIE1yLkh1aXRlbWEgc2FpZCB0aGF0IGhlIGNhbiBidXkgYW5vdGhlciBkaWZmZXJl bnQgTkFUIG9yIA0KbW9kaWZ5PEJSPiZuYnNwOyB0aGUgc3ltbWV0cmljIE5BVC4gSSB0aGluayBh IGdvb2QgbWVjaGFuaXNtIHNob3VsZCBzYXRpc2Z5IHRoZSANCnVzZXJzLCBub3QgYmUgc2F0aXNm aWVkIGJ5IHRoZSB1c2Vycy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwZmYgc2l6ZT00PnNvIGkgdGhp bmsgdGhlcmUgc2hvdWxkIA0KYmUgc29tZSBvdGhlciBiZXR0ZXIgbWVjaGFuaXNtcy48QlI+aXQg aXMgZWFybHkgdG8gbWFrZSBkZWNpc2lvbiBub3csIG1vcmUgDQpkZXRhaWxlZCBhbmQgZGVlcGx5 IGRpc2N1c3Npb24gaXMgbmVlZGVkLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9IzAwMDBmZiBzaXplPTQ+PEJS PkVpZmZlbCANCld1PEJSPjwvRk9OVD48QSBocmVmPSJtYWlsdG86djZvcHNAb3BzLmlldGYub3Jn Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0Kc2l6ZT00PjwvRk9OVD48L0E+PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0005_01C42F82.E1E45CB0-- From owner-v6ops@ops.ietf.org Sat May 1 09:06: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 JAA12007 for ; Sat, 1 May 2004 09:06:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJu95-000BDk-AX for v6ops-data@psg.com; Sat, 01 May 2004 13:03:07 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJu94-000BDW-Br for v6ops@ops.ietf.org; Sat, 01 May 2004 13:03:06 +0000 Received: (qmail 20746 invoked by uid 417); 1 May 2004 13:03:05 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 1 May 2004 13:03:05 -0000 Received: from XPNERICK ([132.70.218.23]) by softhome.net with esmtp; Sat, 01 May 2004 07:03:04 -0600 Message-ID: <006701c42f7c$a8e18a60$0301a8c0@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <004301c42f3b$dac4c100$7774a8c0@Amy> Subject: Re: POLL: Consensus for moving forward with Teredo? Date: Sat, 1 May 2004 16:03:11 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL, RCVD_IN_NJABL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS,RCVD_IN_SORBS_HTTP autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I vote a, as this will allow us to insure a proper design and implementation plan for the future implementations. Eric From owner-v6ops@ops.ietf.org Sat May 1 09:14: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 JAA12291 for ; Sat, 1 May 2004 09:14:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJuJc-000Cgw-4n for v6ops-data@psg.com; Sat, 01 May 2004 13:14:00 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJuJa-000CeP-LT for v6ops@ops.ietf.org; Sat, 01 May 2004 13:13:58 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2C9765D95; Sat, 1 May 2004 09:13:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 09:13:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: POLL: Consensus for moving forward with Teredo? Date: Sat, 1 May 2004 09:13:55 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6FA@tayexc13.americas.cpqcorp.net> Thread-Topic: POLL: Consensus for moving forward with Teredo? Thread-Index: AcQvPEL3NCAhpOarRjWatve4s6kkHQAP7FbQ From: "Bound, Jim" To: "Liu Min" , "Pekka Savola" , X-OriginalArrivalTime: 01 May 2004 13:13:58.0037 (UTC) FILETIME=[29695450:01C42F7E] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This made me think of something to relay to the WG (thanks Liu Min). =20 I have heard from three different users in the ISR (Intelligence, Surveillance, and Reconnaissance) deployment community, all different entities, that any transition mechanisms, which use special IPv6 prefixes are a non-starter in certain cases. The two that are not useful for that reason are 6to4 and Teredo. They present a potential security hole because nodes can create them ad hoc theoretically and IPv6 packets could be sent to them, and they are not within the address space defined by these communities, and causes permanent infrastructure. These nets use stateless and dominant IPv6 nets reducing IPv4 immedidately when possible, and using mechanisms to connect to legacy IPv4. The two mechanisms that may work well at this time are DSTM and ISATAP, and objective is to let ISATAP phase out automatically with deployment (large advantage of ISATAP to them). Rigorous security holes for DSTM and ISATAP are being searched now. That is all I really know at this point and it is new. =20 /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Liu Min > Sent: Saturday, May 01, 2004 1:19 AM > To: 'Pekka Savola'; v6ops@ops.ietf.org > Subject: RE: POLL: Consensus for moving forward with Teredo? >=20 > I think NAT traversal in IPv6 transition is a very important=20 > issue and should be solved. Although Teredo needs special=20 > IPv6 address prefix and need Teredo relay in every IPv6=20 > network, it is reasonably secure and already out there. There=20 > are also other mechanisms for this issue and each of them has=20 > different properties and applying scenarios. We should go=20 > forward with these transition mechanisms and let the market=20 > to make the final decision. >=20 > =20 > =20 >=20 > Best Wishes, > =20 > Liu Min > Institute of Computing Technology > Chinese Academy of Sciences > Tel: (86-10) 6256 5533-9240 > E-mail: liumin@ict.ac.cn >=20 >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf > > Of Pekka Savola > > Sent: Saturday, May 01, 2004 1:32 AM > > To: v6ops@ops.ietf.org > > Subject: POLL: Consensus for moving forward with Teredo? > >=20 > > Hi, > >=20 > > (co-chair hat on) > >=20 > > As identified in the scenarios analysis at IETF59 and in > > draft-savola-v6ops-tunneling-01.txt, there appears to a need which > > cannot be filled by another mechanism for Teredo at least=20 > in one major > > Unmanaged scenario. > >=20 > > Is there rough consensus to move forward with Teredo?=20 > (i.e., to adopt > > it as WG document in this WG or elsewhere, for Proposed Standard.) > >=20 > > The main issue raised has been to call for a more extensive analysis > > for the deployment implications of native, 6to4, and=20 > Teredo. There is > > already discussion of this in the Unmanaged Analysis=20 > document. There > > seemed to be very little energy or interest in the WG to drive this > > much further. > >=20 > > The options regarrding Teredo at this stage seem to be: > >=20 > > a) Go forward with Teredo, hone the deployment implications in the > > unmanaged analysis in parallel (if and as appropriate), > >=20 > > b) Conclude that there is no sufficiently strong need for=20 > Teredo, and > > not support its advancement (for PS) at this stage, or > >=20 > > c) Decide that we need to analyze the scenarios or deployment more > > before being able to make a decision. > >=20 > > If so, please state where you believe more analysis is needed.. > > and volunteer if possible :) > >=20 > > If you have an opinion, please state it within a week, i.e., by next > > Friday, 7th May. > >=20 > > Thanks! > >=20 > > (co-chair hat off) > >=20 > >=20 >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sat May 1 10:17: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 KAA18798 for ; Sat, 1 May 2004 10:17:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJvHd-000P3t-C1 for v6ops-data@psg.com; Sat, 01 May 2004 14:16:01 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJvHZ-000P03-P5 for v6ops@ops.ietf.org; Sat, 01 May 2004 14:15:57 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5950E4C13 for ; Sat, 1 May 2004 10:15:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 10:15:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C42F86.D1EBB50C" Subject: FW: I-D ACTION:draft-bound-dstm-exp-01.txt Date: Sat, 1 May 2004 10:15:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6FC@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-bound-dstm-exp-01.txt Thread-Index: AcQu8t8yddlMDAaqQqyjhVgMXosA7gAk5Hew From: "Bound, Jim" To: X-OriginalArrivalTime: 01 May 2004 14:15:57.0169 (UTC) FILETIME=[D22FD610:01C42F86] 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-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C42F86.D1EBB50C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 FYI. We also have updated our DSTM web site to: http://www.dstm.info/ I am only the Editor. Authors are within the spec. Regards, /jim -----Original Message----- From: i-d-announce-admin@ietf.org [mailto:i-d-announce-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, April 30, 2004 3:45 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-bound-dstm-exp-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Dual Stack Transition Mechanism Author(s) : J. Bound Filename : draft-bound-dstm-exp-01.txt Pages : 12 Date : 2004-4-30 =09 The deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6 dominant network. Nodes will still need to communicate with IPv4 nodes that do not have a Dual IP layer supporting both IPv4 and IPv6. The Dual IP Layer Stack Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6 dominant network and provides a method to allocate a temporary IPv4 address to Dual IP Layer IPv6/IPv4 capable nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment to communicate with IPv4 legacy nodes and applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bound-dstm-exp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bound-dstm-exp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bound-dstm-exp-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C42F86.D1EBB50C Content-Type: application/octet-stream; name="draft-bound-dstm-exp-01.URL" Content-Description: draft-bound-dstm-exp-01.URL Content-Disposition: attachment; filename="draft-bound-dstm-exp-01.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VuZC1kc3RtLWV4cC0wMS50eHQNCg== ------_=_NextPart_001_01C42F86.D1EBB50C-- From owner-v6ops@ops.ietf.org Sat May 1 11:05: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 LAA23717 for ; Sat, 1 May 2004 11:05:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJw2Z-0007jE-QZ for v6ops-data@psg.com; Sat, 01 May 2004 15:04:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJw2W-0007ib-D0 for v6ops@ops.ietf.org; Sat, 01 May 2004 15:04:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i41F4EA06033; Sat, 1 May 2004 18:04:14 +0300 Date: Sat, 1 May 2004 18:04:14 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Liu Min , Subject: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6FA@tayexc13.americas.cpqcorp.net> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 1 May 2004, Bound, Jim wrote: > I have heard from three different users in the ISR (Intelligence, > Surveillance, and Reconnaissance) deployment community, all different > entities, that any transition mechanisms, which use special IPv6 > prefixes are a non-starter in certain cases. I'm not fully sure if I understand the scenario, but if I think this is what I think it is, the main problem is not a special IPv6 prefix, but being to tunnel directly to the node in a way that the host's site losts manageability. > The two that are not > useful for that reason are 6to4 and Teredo. They present a potential > security hole because nodes can create them ad hoc theoretically and > IPv6 packets could be sent to them, and they are not within the address > space defined by these communities, and causes permanent infrastructure. 6to4 and Teredo have direct tunneling, of course; both can be blocked easily at the border, but if the site is not aware of them being used... In some networks 6to4 is less of a problem if private IPv4 addresses are used as the internal nodes cannot use 6to4 tunneling. > The two mechanisms that may work well at this time are DSTM and > ISATAP, and objective is to let ISATAP phase out automatically with > deployment (large advantage of ISATAP to them). Rigorous security holes > for DSTM and ISATAP are being searched now. That is all I really know > at this point and it is new. ISATAP is equally problematic as 6to4. You can tunnel packets directly to the nodes if they have public addresses using fe80:: -addressing -- unless those have been (properly) blocked at the border. ... For what its worth, if this is the scenario you're worried of, about everything will be problematic -- if you can connect to a tunnel server outside of the site using protocol 41 or UDP, you can go past the site's management controls unless explicitly forbidden. -- 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-v6ops@ops.ietf.org Sat May 1 12:22: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 MAA29574 for ; Sat, 1 May 2004 12:22:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJxEB-000KeW-UP for v6ops-data@psg.com; Sat, 01 May 2004 16:20:35 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJxE9-000Kdy-Kj for v6ops@ops.ietf.org; Sat, 01 May 2004 16:20:33 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4F325924C; Sat, 1 May 2004 12:20:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 12:20:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42F98.39C4F4DA" Subject: REVIEW COMMENTS: draft-palet-v6ops-auto-trans-00.txt Date: Sat, 1 May 2004 12:20:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B704@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW COMMENTS: draft-palet-v6ops-auto-trans-00.txt Thread-Index: AcQvmDhJ2Q6S7BcQSAmkPzF545Qj6g== From: "Bound, Jim" To: "JORDI PALET MARTINEZ" Cc: X-OriginalArrivalTime: 01 May 2004 16:20:33.0000 (UTC) FILETIME=[3A211E80:01C42F98] 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,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C42F98.39C4F4DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jordi, What you have done is describe a product feature to automate transition, but not an engineering specification with proper details that convey what we must actually do and agree to in this working group. I also suggest below focus on stationary not mobility, and also focus only on the home deployment model. I do not think it would ever be possible to get consensus on this idea but maybe. But your spec is just an idea not a technical specification. That is nice of you to send to us but this has no technical depth to resolve the technical parts that would be required to even contemplate all the affects to our current IPv6 transiiton mechanisms. It also assume software that does not exist to determine best approach and would add more software to the transition too. Lastly DSTM should be included for this reason, unless it is a home network, because on a dominant IPv6 network it can be determined well if IPv4 is required from the DNS record returned and then DSTM is one option users have to deploy. But we do not recommend this in UMAN type envoironments per DSTM deployment. Comments on the spec directly below prefixed with JB. This needs much discussion if it should be a WG. I think it does poke at us in the WG to ask ourselves what automation do we need for transtion as a tool if any? So your idea is good input to us as something to think about in general is my view. ----------------------------------- Abstract This draft evaluates a method called "auto-transition" to ensure that any device can obtain IPv6 connectivity at any time and whatever network is attached to. JB: Add text that this is to use IPv4 over IPv6 or we need to discuss native IPv6 more below. The method looks for the best transition mechanism according to performance criteria as well as the scenario where the device is located. JB: I don't think this will ever be possible. We can never know all the performance metrics to make such and auto choice. Also this assumes users want to use multiple choices and that either needs to be stated as an assumption or like wording. By implementing such auto-transition method in either or both end nodes or middle boxes (CPEs), users can always obtain IPv6 connectivity with no human intervention. JB: The integration of many mechanisms and security ramifications will make this undesirable to many users is my input as deployment analysis. 1. Introduction The main goal is to facilitate the IPv6 deployment in a seamless way for devices, users and applications. Lots of devices and applications around us will benefit obtaining IPv6 connectivity everywhere: home automation, wearable devices, cars, PDAs, mobile phones, peer-to-peer applications, remote control applications, etc. IPv6 is suitable to solve the network requirements that those devices/applications will need: addressing space, end-to-end secure peer-to-peer communication, autoconfiguration features and so on. JB: This is marketing and unnecessary text for the spec. Also I like the abstract to be first paragraph of the introcudtion and forces clear crisp initial statement from authors of specs. The abstract needs more content. IPv6 provides autoconfiguration features, enabling devices to work according to the plug-and-play philosophy, that is with no manual intervention. However they only can be applied once the device has obtained IPv6 connectivity. On the other hand, while native IPv6 connectivity is not available everywhere, there is not a good "auto-transition" to ensure this connectivity. JB: You state the obvious IMO and not necessary and I am in the second paragraph and still do not see the point. While devices are located in a native IPv6 environment, no manual intervention is required, so non technical users can take advantage of IPv6. However until all or most of the networks are IPv6 native, we need to ensure that the same devices and users can use a transition mechanism that ensures the best possible IPv6 connectivity, without any technical knowledge. Is not acceptable require to the users to make manual configurations in order to get the IPv6 connectivity. JB: So is this only being proposed for the home environment? I suggest doing that is prudent. This will never be deployed IMO in an Enterprise or ISP network. The mechanism will deal with all the tasks required to configure automatically the best IPv6 connectivity at anytime, in any network scenario, which include native IPv6 connectivity detection and transition mechanism selection if required. It can be implemented either in stand-alone devices (hosts, PDA, etc.) or middle boxes like CPE routers. JB: Again suggest limiting the scope of what your proposig to UMAN or Very small businesses like the Dentist office. 2. Auto-Transition Overview When the device is attached to the network, the mechanism first must check if native IPv6 connectivity is possible. JB: OK so is this extra networking software to do this? More below. If so, either or both stateless [1] or stateful autoconfiguration [2] mechanism are performed. Otherwise, the auto-transition mechanism should try to obtain IPv6 connectivity by using the best transition mechanism according to the network where the devices is attached. JB: This is not clear to me logically. If IPv6, If stateless or dhcpv6 do stuff, else do auto transition? I think that is what your saying? Why would stateless or stateful not exist and under what circumstance? I can't see that because any node I know at least does link-local stateless immediately? Later, the conditions of the network can change, even the user/device can change the location while moving. JB: Now your heading down mobility / nomadic path. I suggest, if this is to be WG item, that it deal with stationary networks and nodes so we can get that right. Mobility is a completely different analysis. Baby steps is my input. Consequently the attachment point to the network can be different, and the previous transition mechanism no longer be so convenient. JB: "convenient" that is not a technical term and do you mean it will not work or perform and if so what informs the implementation of what you propose? The auto-transition mechanism has to monitor periodically the network parameters (i.e. IPv4 address, loss, delays, etc.) in order to detect those changes and decide if another transition mechanism different to the one currently being used is convenient and provides better performance to activate it. JB: so this software has to exist on the clients? please do not try to even attempt addressing mobility or nomadicity. All this process should be ideally automatic in order to avoid the user to make any manual configuration. JB: so its not always automatic? At the most, users only should introduce some parameters by means of a wizard during the installation process of the application that implements the auto-transition mechanism, but once it is up and running, all the tasks should be made by the system and no manual intervention required. JB: this is a product requirement not a standards requirement we build in the IETF. Nice for summary but not relative to the engineering work we do here. 3. Auto-Transition Requirements If native connectivity is not available the auto-transition mechanism must choose the right transition mechanism to be used to ensure the connectivity. JB: I don't agree unless your speaking about a home environment and then I believe it should be config option to the user with explanation or from the ISP. A number of transition mechanism have been defined already: Teredo, TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. JB: Nothing you stated above should preclude not stating DSTM above it should be stated and listed it is a deployed mechanism as the others. 3.1 Selection of the proper transition mechanism A few scenarios with particular network requirements had been defined already ([4], [5], [6], [7]). Not all the transition scenarios fit in such network scenarios, as being evaluated at [8], trying to make the best fit to each scenario. JB: This makes no sense to me you must explain why you say this in relation to [8] or are you trying to appease Pekka :--) The auto-transition mechanism may take into account the results shown in [8], although it is also possible a wider focus to select the best transition mechanism to be used. What the end user always demands is the best performance on the IPv6 connectivity, so it should be the main criteria to choose the right transition mechanism. JB: Same comment as above. You should add more discussion and text here and what you mean in this spec. Distance, delays, loss, bandwidth, etc., are some of the related parameters that could be used as metrics to be measured for knowing the link performance. A device can present different values of such metrics according to the transition mechanism that is being used even when attached to the same network. JB: You really need to state how below but we shall see. loop detect_scenario if (native_IPv6_available and native_priority) use_native_IPv6_connectivity else if (first_check or performance_check_allowed) check_performance use_best_mechanism endif endif configure_connectivity wait (link_check_timeout) endloop Figure 1: Simple Auto-transition algorithm JB: You missed your early if statement what if stateless or stateful exists in the above? It is important to note what each task or parameter means: o detect_scenario: This task deals with detecting the scenario where the device willing to have IPv6 connectivity is located. It could check if native IPv6 is available, if a public IPv4 address is available, if a NAT is being used and what type, if there is a proxy or firewall, or if other protocols can be operated. o native_IPv6_available: Detects if native IPv6 is available. o native_priority: Detects if native IPv6 has priority, for instance, even in the case the performance is lower than alternative transition mechanism that may be used. This condition could be set by the OS, or even under user or applications control. JB: I argue there is not way to do this at all. o use_native_IPv6_connectivity: Configure the interface to use native IPv6 connectivity, using stateless or stateful autoconfiguration, upon their availability. o first_check: Defines if this is the first time this check is being done after an interface reset. o performance_check_allowed: Defines if the performance of the selected mechanism can be measured after selected, for instance, to avoid traffic being generated in non-flat rate links (3GPP, ISDN, ...). o check_performance: According to the detected scenario, a number of mechanisms could be used. This task checks the performance that each of such transition mechanism provides, including native IPv6 if available, by measuring delays and losses. The mechanism subset will be defined by taking into account [8], but others could be considered. o use_best_mechanism: According to the measurement results, the best mechanism is selected. o configure_connectivity: Either native IPv6 connectivity or the best available transition mechanism is configured. o link_check_timeout: Once the IPv6 connectivity is obtained, the auto-transition mechanism periodically monitors the link status. The delay between consecutive checks is defined by this variable. A possible list of mechanism to be checked, ordered by preference could be: 1. Native IPv6 Connectivity 2. TS with proto-41 ([3]) 3. TS with UDP 4. ISATAP 5. STEP 6. 6to4 7. Teredo JB: Add DSTM nothing has been specified in the spec to preclude the use of DSTM or is it you believe not say DSMT is correct politically? 3.2 Change of transition mechanism Change of transition mechanism refers to the task to abandon the transition mechanism that is actually being used and start to use another one that presents better performance. This is not an easy task at all, since it involves at least two important issues: 1. To maintain the current IPv6 address. This is a must since otherwise applications with communications opened will not work. Specially important is the case which the auto-transition mechanism is implemented in border devices that provide native IPv6 connectivity to the whole network. Either the prefix network (i.e. RA), or the IPv6 addresses (i.e. DHCPv6) that they provide, must be able to keep the IPv6 addressing parameters. If the auto-transition mechanism has to include the possibility of changing the transition mechanism used without discarding the current connection state, it is necessary to define a method that solves this issue. MIPv6 concepts could be applied. JB: So now you must keep state at the edges and please explain what you mean and what parts of MIPv6 can be applied. But I sugggest you not botoher with Mobility for now. 2. User authentication without human intervention. The philosophy of the auto-transition mechanism is that all the processes are done automatically, with no human intervention. So, for instance, if the device running the auto-transition mechanism needs to contact with a TB different to the actual one, and it requires user authentication, the process should be transparent to the user. It could be based on parameters (login and password) configured through the wizard during the installation process. AAA mechanisms should be used. JB: AAA is good for the home network but not strong enough for CPE boxes is my input IPsec at a minimum is required. How does Ipsec affect this is important to understand. JB: No comment on your layer tunnels it was just stating current state of art for that function. JB: I will not comment on Nomadicity we first need to discuss stationary and get that right. Regards, /jim ------_=_NextPart_001_01C42F98.39C4F4DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jordi,

What you have done is describe a product = feature=20 to automate transition, but not an engineering specification with proper = details=20 that convey what we must actually do and agree to in this working = group.  I=20 also suggest below focus on stationary not mobility, and also focus only = on the=20 home deployment model.

I do not think it would ever be possible = to get=20 consensus on this idea but maybe.  But your spec is just an idea = not a=20 technical specification.  That is nice of you to send to us but = this has no=20 technical depth to resolve the technical parts that would be required to = even=20 contemplate all the affects to our current IPv6 transiiton = mechanisms.

It=20 also assume software that does not exist to determine best approach and = would=20 add more software to the transition too.

Lastly DSTM should be = included=20 for this reason, unless it is a home network, because on a dominant IPv6 = network=20 it can be determined well if IPv4 is required from the DNS record = returned and=20 then DSTM is one option users have to deploy.  But we do not = recommend this=20 in UMAN type envoironments per DSTM deployment.

Comments on the = spec=20 directly below prefixed with JB.

This needs much discussion if it = should=20 be a WG.  I think it does poke at us in the WG to ask ourselves = what=20 automation do we need for transtion as a tool if any?  So your idea = is good=20 input to us as something to think about in general is my=20 view.

-----------------------------------

Abstract

&= nbsp; =20 This draft evaluates a method called "auto-transition" to ensure=20 that
   any device can obtain IPv6 connectivity at any time = and=20 whatever
   network is attached to.

JB: Add text = that this=20 is to use IPv4 over IPv6 or we need to discuss native IPv6 more=20 below.

   The method looks for the best transition = mechanism=20 according to
   performance criteria as well as the = scenario where=20 the device is
   located.

JB: I don't think this = will ever=20 be possible.  We can never know all the performance metrics to make = such=20 and auto choice. Also this assumes users want to use multiple choices = and that=20 either needs to be stated as an assumption or like = wording.

  =20 By implementing such auto-transition method in either or both=20 end
   nodes or middle boxes (CPEs), users can always = obtain=20 IPv6
   connectivity with no human intervention.

JB: = The=20 integration of many mechanisms and security ramifications will make this = undesirable to many users is my input as deployment = analysis.

1. =20 Introduction

   The main goal is to facilitate the IPv6 = deployment in a seamless way
   for devices, users and=20 applications. Lots of devices and applications
   around us = will=20 benefit obtaining IPv6 connectivity everywhere: home
   = automation,=20 wearable devices, cars, PDAs, mobile phones, = peer-to-peer
  =20 applications, remote control applications, etc. IPv6 is suitable=20 to
   solve the network requirements that those=20 devices/applications will
   need: addressing space, = end-to-end=20 secure peer-to-peer communication,
   autoconfiguration = features=20 and so on.

JB: This is marketing and unnecessary text for the = spec. =20 Also I like the abstract to be first paragraph of the introcudtion and = forces=20 clear crisp initial statement from authors of specs.  The abstract = needs=20 more content.

   IPv6 provides autoconfiguration = features,=20 enabling devices to work
   according to the plug-and-play=20 philosophy, that is with no manual
   intervention. However = they=20 only can be applied once the device has
   obtained IPv6=20 connectivity. On the other hand, while native IPv6
   = connectivity=20 is not available everywhere, there is not a good
  =20 "auto-transition" to ensure this connectivity.

JB: You state the = obvious=20 IMO and not necessary and I am in the second paragraph and still do not = see the=20 point.

   While devices are located in a native IPv6=20 environment, no manual
   intervention is required, so non=20 technical users can take advantage
   of IPv6. However = until all or=20 most of the networks are IPv6 native,
   we need to ensure = that the=20 same devices and users can use a
   transition mechanism = that=20 ensures the best possible IPv6
   connectivity, without any = technical knowledge. Is not acceptable
   require to the = users to=20 make manual configurations in order to get
   the IPv6=20 connectivity.

JB: So is this only being proposed for the home=20 environment?  I suggest doing that is prudent.  This will = never be=20 deployed IMO in an Enterprise or ISP network.

   The = mechanism=20 will deal with all the tasks required to configure
   = automatically=20 the best IPv6 connectivity at anytime, in any network
   = scenario,=20 which include native IPv6 connectivity detection and
   = transition=20 mechanism selection if required. It can be implemented
   = either in=20 stand-alone devices (hosts, PDA, etc.) or middle boxes = like
   CPE=20 routers.

JB: Again suggest limiting the scope of what your = proposig to=20 UMAN or Very small businesses like the Dentist office.

2. =20 Auto-Transition Overview

   When the device is attached = to the=20 network, the mechanism first must
   check if native IPv6=20 connectivity is possible.

JB: OK so is this extra networking = software to=20 do this?  More below.

   If so, either or=20 both
   stateless [1] or stateful autoconfiguration [2] = mechanism=20 are
   performed. Otherwise, the auto-transition mechanism = should=20 try to
   obtain IPv6 connectivity by using the best = transition=20 mechanism
   according to the network where the devices is=20 attached.

JB: This is not clear to me logically.  If IPv6, = If=20 stateless or dhcpv6 do stuff, else do auto transition?  I think = that is=20 what your saying?  Why would stateless or stateful not exist and = under what=20 circumstance?  I can't see that because any node I know at least = does=20 link-local stateless immediately?

   Later, the = conditions of=20 the network can change, even the user/device
   can change = the=20 location while moving.

JB: Now your heading down mobility / = nomadic=20 path.  I suggest, if this is to be WG item, that it deal with = stationary=20 networks and nodes so we can get that right. Mobility is a completely = different=20 analysis.  Baby steps is my input.

   Consequently = the=20 attachment
   point to the network can be different, and = the=20 previous transition
   mechanism no longer be so=20 convenient.

JB: "convenient" that is not a technical term and do = you mean=20 it will not work or perform and if so what informs the implementation of = what=20 you propose?

   The auto-transition = mechanism
  =20 has to monitor periodically the network parameters (i.e. = IPv4
  =20 address, loss, delays, etc.) in order to detect those changes=20 and
   decide if another transition mechanism different to = the one=20 currently
   being used is convenient and provides better=20 performance to activate
   it.

JB: so this software = has to=20 exist on the clients?  please do not try to even attempt addressing = mobility or nomadicity.

   All this process should be = ideally=20 automatic in order to avoid the
   user to make any manual=20 configuration.

JB: so its not always = automatic?

   At=20 the most, users only should
   introduce some parameters by = means=20 of a wizard during the
   installation process of the = application=20 that implements the
   auto-transition mechanism, but once = it is up=20 and running, all the
   tasks should be made by the system = and no=20 manual intervention
   required.

JB: this is a = product=20 requirement not a standards requirement we build in the IETF.  Nice = for=20 summary but not relative to the engineering work we do = here.


3. =20 Auto-Transition Requirements

   If native connectivity = is not=20 available the auto-transition mechanism
   must choose the = right=20 transition mechanism to be used to ensure the
  =20 connectivity.

JB: I don't agree unless your speaking about a home = environment and then I believe it should be config option to the user = with=20 explanation or from the ISP.

   A number of transition=20 mechanism have been defined already: Teredo,
   TB/TS, TSP, = STEP,=20 ISATAP, 6to4, tunnels, etc.

JB: Nothing you stated above should = preclude=20 not stating DSTM above it should be stated and listed it is a deployed = mechanism=20 as the others.


3.1  Selection of the proper transition=20 mechanism

   A few scenarios with particular network=20 requirements had been defined
   already ([4], [5], [6], = [7]). Not=20 all the transition scenarios fit in
   such network = scenarios, as=20 being evaluated at [8], trying to make the
   best fit to = each=20 scenario.

JB: This makes no sense to me you must explain why you = say this=20 in relation to [8] or are you trying to appease Pekka = :--)

  =20 The auto-transition mechanism may take into account the results=20 shown
   in [8], although it is also possible a wider focus = to=20 select the best
   transition mechanism to be used. What = the end=20 user always demands is
   the best performance on the IPv6=20 connectivity, so it should be the
   main criteria to = choose the=20 right transition mechanism.

JB: Same comment as above.  You = should=20 add more discussion and text here and what you mean in this=20 spec.

   Distance, delays, loss, bandwidth, etc., are = some of=20 the related
   parameters that could be used as metrics to = be=20 measured for knowing
   the link performance. A device can = present=20 different values of such
   metrics according to the = transition=20 mechanism that is being used even
   when attached to the = same=20 network.

JB: You really need to state how below but we shall=20 see.

   loop
       =20 detect_scenario
        if=20 (native_IPv6_available and native_priority)
  =20             =20 use_native_IPv6_connectivity
       =20 else
       =20         if (first_check or=20 performance_check_allowed)
       =20        =20         = check_performance
  =20             =20         = use_best_mechanism
  =20             =20 endif
        endif
  =20      configure_connectivity
  =20      wait (link_check_timeout)
  =20 endloop

   Figure 1: Simple Auto-transition=20 algorithm

JB: You missed your early if statement what if = stateless or=20 stateful exists in the above?

   It is important to = note what=20 each task or parameter means:

   o  = detect_scenario: This=20 task deals with detecting the scenario = where
     =20 the device willing to have IPv6 connectivity is located. It=20 could
      check if native IPv6 is = available, if a=20 public IPv4 address is
      available, if a = NAT is=20 being used and what type, if there is = a
      proxy=20 or firewall, or if other protocols can be operated.

   = o =20 native_IPv6_available: Detects if native IPv6 is = available.

  =20 o  native_priority: Detects if native IPv6 has priority,=20 for
      instance, even in the case the = performance=20 is lower than
      alternative transition = mechanism=20 that may be used. This condition
      could = be set=20 by the OS, or even under user or = applications
     =20 control.

JB: I argue there is not way to do this at=20 all.

   o  use_native_IPv6_connectivity: Configure = the=20 interface to use
      native IPv6 = connectivity,=20 using stateless or stateful
      = autoconfiguration,=20 upon their availability.

   o  first_check: = Defines if=20 this is the first time this check is = being
     =20 done after an interface reset.

   o =20 performance_check_allowed: Defines if the performance of=20 the
      selected mechanism can be measured = after=20 selected, for instance,
      to avoid = traffic being=20 generated in non-flat rate links = (3GPP,
      ISDN,=20 ...).

   o  check_performance: According to the = detected=20 scenario, a number of
      mechanisms could = be=20 used. This task checks the performance = that
     =20 each of such transition mechanism provides, including native=20 IPv6
      if available, by measuring delays = and=20 losses. The mechanism subset
      will be = defined=20 by taking into account [8], but others could=20 be
      considered.

   = o =20 use_best_mechanism: According to the measurement results, the=20 best
      mechanism is=20 selected.

   o  configure_connectivity: Either = native IPv6=20 connectivity or the
      best available = transition=20 mechanism is configured.

   o  link_check_timeout: = Once=20 the IPv6 connectivity is obtained, the
      = auto-transition mechanism periodically monitors the link=20 status.
      The delay between consecutive = checks=20 is defined by this variable.

   A possible list of = mechanism to=20 be checked, ordered by preference
   could = be:

  =20 1.  Native IPv6 Connectivity

   2.  TS with = proto-41=20 ([3])

   3.  TS with UDP

   = 4. =20 ISATAP

   5.  STEP

   6. =20 6to4

   7.  Teredo

JB: Add DSTM nothing has = been=20 specified in the spec to preclude the use of DSTM or is it you believe = not say=20 DSMT is correct politically?


3.2  Change of transition=20 mechanism

   Change of transition mechanism refers to = the task=20 to abandon the
   transition mechanism that is actually = being used=20 and start to use
   another one that presents better = performance.=20 This is not an easy
   task at all, since it involves at = least two=20 important issues:

   1.  To maintain the current = IPv6=20 address. This is a must since
       = otherwise=20 applications with communications opened will not=20 work.
       Specially important is the = case=20 which the auto-transition
       = mechanism is=20 implemented in border devices that provide=20 native
       IPv6 connectivity to the = whole=20 network. Either the prefix = network
       (i.e.=20 RA), or the IPv6 addresses (i.e. DHCPv6) that they=20 provide,
       must be able to keep = the IPv6=20 addressing parameters. If the
      =20 auto-transition mechanism has to include the possibility=20 of
       changing the transition = mechanism=20 used without discarding the
       = current=20 connection state, it is necessary to define a method=20 that
       solves this issue. MIPv6 = concepts=20 could be applied.

JB: So now you must keep state at the edges and = please=20 explain what you mean and what parts of MIPv6 can be applied.  But = I=20 sugggest you not botoher with Mobility for now.

   = 2. =20 User authentication without human intervention. The philosophy=20 of
       the auto-transition mechanism = is that=20 all the processes are done
      =20 automatically, with no human intervention. So, for instance,=20 if
       the device running the=20 auto-transition mechanism needs to=20 contact
       with a TB different to = the=20 actual one, and it requires user
       = authentication, the process should be transparent to the user.=20 It
       could be based on parameters = (login=20 and password) configured
       through = the=20 wizard during the installation process.=20 AAA
       mechanisms should be=20 used.

JB: AAA is good for the home network but not strong enough = for CPE=20 boxes is my input IPsec at a minimum is required.  How does Ipsec = affect=20 this is important to understand.

JB: No comment on your layer = tunnels it=20 was just stating current state of art for that function.

JB: I = will not=20 comment on Nomadicity we first need to discuss stationary and get that=20 right.

Regards,
/jim

------_=_NextPart_001_01C42F98.39C4F4DA-- From owner-v6ops@ops.ietf.org Sat May 1 12:45: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 MAA01309 for ; Sat, 1 May 2004 12:45:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJxbv-00008p-6k for v6ops-data@psg.com; Sat, 01 May 2004 16:45:07 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJxbr-00008J-NF for v6ops@ops.ietf.org; Sat, 01 May 2004 16:45:03 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0BB8E903A; Sat, 1 May 2004 12:45:03 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 12:45:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?] Date: Sat, 1 May 2004 12:44:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B706@tayexc13.americas.cpqcorp.net> Thread-Topic: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?] Thread-Index: AcQvjaqQLxIPkMsFScaEUryKpwOTAQADGXnw From: "Bound, Jim" To: "Pekka Savola" Cc: "Liu Min" , X-OriginalArrivalTime: 01 May 2004 16:45:02.0815 (UTC) FILETIME=[A63516F0:01C42F9B] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > On Sat, 1 May 2004, Bound, Jim wrote: > > I have heard from three different users in the ISR (Intelligence,=20 > > Surveillance, and Reconnaissance) deployment community, all=20 > different=20 > > entities, that any transition mechanisms, which use special IPv6=20 > > prefixes are a non-starter in certain cases. >=20 > I'm not fully sure if I understand the scenario, but if I=20 > think this is what I think it is, the main problem is not a=20 > special IPv6 prefix, but being to tunnel directly to the node=20 > in a way that the host's site losts manageability. That is the end result (loss of manageability) but the root cause was permitting hard coded prefixes in the network. >=20 > > The two that are not > > useful for that reason are 6to4 and Teredo. They present a=20 > potential=20 > > security hole because nodes can create them ad hoc theoretically and > > IPv6 packets could be sent to them, and they are not within the=20 > > address space defined by these communities, and causes=20 > permanent infrastructure. >=20 > 6to4 and Teredo have direct tunneling, of course; both can be=20 > blocked easily at the border, but if the site is not aware of=20 > them being used... Blocking puts extra methods in the edge of this highly secure network, and as you say they could be created without the site being aware of them. >=20 > In some networks 6to4 is less of a problem if private IPv4=20 > addresses are used as the internal nodes cannot use 6to4 tunneling. In this case there are not PI or private addresses all addresses are globally routable IPv6 and security methods are used to secure all communications at various points. >=20 > > The two mechanisms that may work well at this time are DSTM and=20 > > ISATAP, and objective is to let ISATAP phase out automatically with=20 > > deployment (large advantage of ISATAP to them). Rigorous security=20 > > holes for DSTM and ISATAP are being searched now. That is all I=20 > > really know at this point and it is new. >=20 > ISATAP is equally problematic as 6to4. You can tunnel packets=20 > directly to the nodes if they have public addresses using=20 > fe80:: -addressing -- unless those have been=20 > (properly) blocked at the border. As I understand it ISATAP is restricted to extended subnets as nodes evolve to IPv6 deployment, until IPv6 capable is turned on, but will not be used off of the subnet. ISATAP is preferred over link-locals. The FE80 token is also only available on the local link and not routable except by ISATAP relays and those will only be on extended subnet with host attached links and not typical routing. So your favorite server or router is forwarding the packet but it is all still the same link. ISATAP is a very good mechanism to begin IPv6 deployment and it goes away without administration once all nodes are able to exist as IPv6 capable on the net. Telcos that consult with me like ISATAP for that reason too as a note. > For what its worth, if this is the scenario you're worried=20 > of, about everything will be problematic -- if you can=20 > connect to a tunnel server outside of the site using protocol=20 > 41 or UDP, you can go past the site's management controls=20 > unless explicitly forbidden. I not really worried about it :--) It is just operational input to the list and a case where 6to4 and Teredo will not be used. I would imagine IPv6 secure filtering would check for 41 clearly. Regards, /jim From owner-v6ops@ops.ietf.org Sat May 1 16:05: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 QAA22603 for ; Sat, 1 May 2004 16:05:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BK0i2-000JDQ-JQ for v6ops-data@psg.com; Sat, 01 May 2004 20:03:38 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BK0i0-000JCz-MH for v6ops@ops.ietf.org; Sat, 01 May 2004 20:03:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i41K3TJ09708; Sat, 1 May 2004 23:03:29 +0300 Date: Sat, 1 May 2004 23:03:29 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Liu Min , Subject: RE: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644B706@tayexc13.americas.cpqcorp.net> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 1 May 2004, Bound, Jim wrote: > > On Sat, 1 May 2004, Bound, Jim wrote: > > > I have heard from three different users in the ISR (Intelligence, > > > Surveillance, and Reconnaissance) deployment community, all > > different > > > entities, that any transition mechanisms, which use special IPv6 > > > prefixes are a non-starter in certain cases. > > > > I'm not fully sure if I understand the scenario, but if I > > think this is what I think it is, the main problem is not a > > special IPv6 prefix, but being to tunnel directly to the node > > in a way that the host's site losts manageability. > > That is the end result (loss of manageability) but the root cause was > permitting hard coded prefixes in the network. No, the root cause is not hard coded prefixes themselves; it's being able to tunnel past the management -- that can be done either with a mechanism which has a special prefix, or some mechanism which does not have one. Hard coded prefixes themselves do not cause this. > > > The two that are not > > > useful for that reason are 6to4 and Teredo. They present a > > potential > > > security hole because nodes can create them ad hoc theoretically and > > > IPv6 packets could be sent to them, and they are not within the > > > address space defined by these communities, and causes > > permanent infrastructure. > > > > 6to4 and Teredo have direct tunneling, of course; both can be > > blocked easily at the border, but if the site is not aware of > > them being used... > > Blocking puts extra methods in the edge of this highly secure network, > and as you say they could be created without the site being aware of > them. True, but it's worth remembering that there will always be these "cover channels" through the edges. People tunnel IP even through HTTP proxies.. So, the question is how much effort should be needed for the sites who wish to block the attempts at creating IPv6 connectivity (automatically) by their hosts. > > In some networks 6to4 is less of a problem if private IPv4 > > addresses are used as the internal nodes cannot use 6to4 tunneling. > > In this case there are not PI or private addresses all addresses are > globally routable IPv6 and security methods are used to secure all > communications at various points. Obviously for these methods to be worth considering, IPv6 addresses must be globally routable.. but the point is whether the _IPv4_ addresses are globally reachable or not. In other words, if a host has enabled ISATAP interface or 6to4 pseudo-interface, is it even possible to send IPv4 proto-41 directly to the hosts (this is obviously impossible w/ private addresses). > > > The two mechanisms that may work well at this time are DSTM and > > > ISATAP, and objective is to let ISATAP phase out automatically with > > > deployment (large advantage of ISATAP to them). Rigorous security > > > holes for DSTM and ISATAP are being searched now. That is all I > > > really know at this point and it is new. > > > > ISATAP is equally problematic as 6to4. You can tunnel packets > > directly to the nodes if they have public addresses using > > fe80:: -addressing -- unless those have been > > (properly) blocked at the border. > > As I understand it ISATAP is restricted to extended subnets as nodes > evolve to IPv6 deployment, until IPv6 capable is turned on, but will not > be used off of the subnet. I'm not 100% sure what you meant precisely, but obviously ISATAP nodes are reachable through the ISATAP router, and you can tunnel directly to the ISATAP nodes if the ip-proto-41 access hasn't been blocked (as one should). > The FE80 token is also only available on the local link and not > routable except by ISATAP relays and those will only be on extended > subnet with host attached links and not typical routing. If ip-proto-41 packets are not dropped at the border of the site running ISATAP, and global addresses are used, anyone can tunnel directly to the ISATAP hosts w/ FE80 prefix. That's why "just turn on ISATAP interface" is not really too secure. -- 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-v6ops@ops.ietf.org Sat May 1 16:12: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 QAA22924 for ; Sat, 1 May 2004 16:12:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BK0qG-000L7e-AA for v6ops-data@psg.com; Sat, 01 May 2004 20:12:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BK0qE-000L7J-Lz for v6ops@ops.ietf.org; Sat, 01 May 2004 20:12:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i41KC0l09810; Sat, 1 May 2004 23:12:00 +0300 Date: Sat, 1 May 2004 23:12:00 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: Re: FW: Comment on RFC 3750 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0612C9A5@tayexc13.americas.cpqcorp.net> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 29 Apr 2004, Bound, Jim wrote: > We did discuss this with uman and I stated that but here is the input. > Do we care? I don't even understand the mail.. inline.. My hunch is that we already have this case covered, but the user is just confused. It seems to be apparent, however, that in many cases like this, setting up the wireless access router to work as bridge between internal interfaces would simplify the users set-up considerably and avoid unnecessary NATting.. > > I have a DLINK wireless access router at home. It is configured and > > functions principly as the model describes except.... the router has > > four 10/100 ethernet interfaces besides the 802.11G. Should not each > > wireless channel (SSID) be it's own subnet. Each router can handle I > > believe 10 SSIDS? IN addition, the > > 802.3 interfaces should their own subnet also. The number of subnets per SSID is irrelevant here because the router has only one wireless interface and uses only one SSID. On the other hand, the wireless access routers typically can either be set to bridge between interfaces or route between them. The former is simpler, and would work nicely with the below; this case is mentioned in RFC3750. The latter appears to be what the user is trying to do.. One possible other wacky mode is "NAT everything -routing", where you don't bridge, but the wireless router NATs every inside interface to the outside interface.. > > Im trying to set up a peer-to-peer gaming system with two or three > > PCs... a laptop with wireless and a desktop with wire. > > They can't communicate .... > > the DLINK router only routes out and it can only be configured with a > > single default gateway IP address. Isn't this an important function? This is irrelevant, as you wouldn't want to have multiple default gateways in this case in any case. What you want to do is be able to set a different subnet prefix for each subnet. > > Shouldn't these routers be capable of supporting multiple subnets on > > wired and wireless interfaces so all ports can interact for > > peer-to-peer gaming, client-server, and server-server communications. Yes, that should probably be supported. Maybe misconfiguration of the router... -- 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-v6ops@ops.ietf.org Sat May 1 22:28: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 WAA07324 for ; Sat, 1 May 2004 22:28:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BK6gy-00015L-VT for v6ops-data@psg.com; Sun, 02 May 2004 02:26:56 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BK6gx-000158-9s for v6ops@ops.ietf.org; Sun, 02 May 2004 02:26:55 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8B408A6C5; Sat, 1 May 2004 22:26:54 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 22:26:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?] Date: Sat, 1 May 2004 22:26:51 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B715@tayexc13.americas.cpqcorp.net> Thread-Topic: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?] Thread-Index: AcQvt2GR2EpyT9/MSAuuvqgb/tBF8QANXZzg From: "Bound, Jim" To: "Pekka Savola" Cc: "Liu Min" , X-OriginalArrivalTime: 02 May 2004 02:26:54.0313 (UTC) FILETIME=[EF14ED90:01C42FEC] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks for you views I see no point in further mail on this thread the WG has the input. /jim=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Saturday, May 01, 2004 4:03 PM > To: Bound, Jim > Cc: Liu Min; v6ops@ops.ietf.org > Subject: RE: direct tunneling vs site's control [RE: POLL:=20 > Consensus for moving forward with Teredo?] >=20 > On Sat, 1 May 2004, Bound, Jim wrote: > > > On Sat, 1 May 2004, Bound, Jim wrote: > > > > I have heard from three different users in the ISR=20 > (Intelligence,=20 > > > > Surveillance, and Reconnaissance) deployment community, all > > > different > > > > entities, that any transition mechanisms, which use=20 > special IPv6=20 > > > > prefixes are a non-starter in certain cases. > > >=20 > > > I'm not fully sure if I understand the scenario, but if I=20 > think this=20 > > > is what I think it is, the main problem is not a special IPv6=20 > > > prefix, but being to tunnel directly to the node in a way=20 > that the=20 > > > host's site losts manageability. > >=20 > > That is the end result (loss of manageability) but the root=20 > cause was=20 > > permitting hard coded prefixes in the network. >=20 > No, the root cause is not hard coded prefixes themselves;=20 > it's being able to tunnel past the management -- that can be=20 > done either with a mechanism which has a special prefix, or=20 > some mechanism which does not have one. Hard coded prefixes=20 > themselves do not cause this. >=20 > > > > The two that are not > > > > useful for that reason are 6to4 and Teredo. They present a > > > potential > > > > security hole because nodes can create them ad hoc=20 > theoretically=20 > > > > and > > > > IPv6 packets could be sent to them, and they are not within the=20 > > > > address space defined by these communities, and causes > > > permanent infrastructure. > > >=20 > > > 6to4 and Teredo have direct tunneling, of course; both can be=20 > > > blocked easily at the border, but if the site is not=20 > aware of them=20 > > > being used... > >=20 > > Blocking puts extra methods in the edge of this highly=20 > secure network,=20 > > and as you say they could be created without the site being=20 > aware of=20 > > them. >=20 > True, but it's worth remembering that there will always be=20 > these "cover channels" through the edges. People tunnel IP=20 > even through HTTP proxies..=20 >=20 > So, the question is how much effort should be needed for the=20 > sites who wish to block the attempts at creating IPv6 connectivity > (automatically) by their hosts. >=20 > > > In some networks 6to4 is less of a problem if private=20 > IPv4 addresses=20 > > > are used as the internal nodes cannot use 6to4 tunneling. > >=20 > > In this case there are not PI or private addresses all=20 > addresses are=20 > > globally routable IPv6 and security methods are used to secure all=20 > > communications at various points. >=20 > Obviously for these methods to be worth considering, IPv6=20 > addresses must be globally routable.. but the point is=20 > whether the _IPv4_ addresses are globally reachable or not. >=20 > In other words, if a host has enabled ISATAP interface or=20 > 6to4 pseudo-interface, is it even possible to send IPv4=20 > proto-41 directly to the hosts (this is obviously impossible=20 > w/ private addresses). >=20 > > > > The two mechanisms that may work well at this time are DSTM and=20 > > > > ISATAP, and objective is to let ISATAP phase out automatically=20 > > > > with deployment (large advantage of ISATAP to them). Rigorous=20 > > > > security holes for DSTM and ISATAP are being searched=20 > now. That=20 > > > > is all I really know at this point and it is new. > > >=20 > > > ISATAP is equally problematic as 6to4. You can tunnel packets=20 > > > directly to the nodes if they have public addresses using=20 > > > fe80:: -addressing -- unless those have been > > > (properly) blocked at the border. > >=20 > > As I understand it ISATAP is restricted to extended subnets=20 > as nodes=20 > > evolve to IPv6 deployment, until IPv6 capable is turned on,=20 > but will=20 > > not be used off of the subnet. >=20 > I'm not 100% sure what you meant precisely, but obviously=20 > ISATAP nodes are reachable through the ISATAP router, and you=20 > can tunnel directly to the ISATAP nodes if the ip-proto-41=20 > access hasn't been blocked (as one should). >=20 > > The FE80 token is also only available on the local link and not=20 > > routable except by ISATAP relays and those will only be on extended=20 > > subnet with host attached links and not typical routing. >=20 > If ip-proto-41 packets are not dropped at the border of the=20 > site running ISATAP, and global addresses are used, anyone=20 > can tunnel directly to the ISATAP hosts w/ FE80 prefix. >=20 > That's why "just turn on ISATAP interface" is not really too secure. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun May 2 01:11: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 BAA12381 for ; Sun, 2 May 2004 01:11:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BK9EV-000DAj-1j for v6ops-data@psg.com; Sun, 02 May 2004 05:09:43 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BK9EU-000DAW-A1 for v6ops@ops.ietf.org; Sun, 02 May 2004 05:09:42 +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); Sat, 1 May 2004 22:09:38 -0700 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 01 May 2004 22:09:41 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 22:09:42 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 22:09:38 -0700 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); Sat, 1 May 2004 22:09:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?] Date: Sat, 1 May 2004 22:09:43 -0700 Message-ID: Thread-Topic: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?] Thread-Index: AcQvjaqQLxIPkMsFScaEUryKpwOTAQADGXnwABpCnoA= From: "Christian Huitema" To: "Bound, Jim" , "Pekka Savola" Cc: "Liu Min" , X-OriginalArrivalTime: 02 May 2004 05:09:40.0910 (UTC) FILETIME=[AC6D5CE0:01C43003] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > That is the end result (loss of manageability) but the root cause was > permitting hard coded prefixes in the network. I believe the root cause is using unmanaged hosts in a context where secure behavior is expected. If you want to assert security properties of the hosts, then you absolutely need to manage them and control what kind of software they run. Otherwise, even without Teredo and 6to4, it is pretty trivial to set up an IPv6 tunnel to some random place. -- Christian Huitema From owner-v6ops@ops.ietf.org Sun May 2 05:04: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 FAA05296 for ; Sun, 2 May 2004 05:04:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKCO8-00053Z-JI for v6ops-data@psg.com; Sun, 02 May 2004 08:31:52 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKCO4-00053C-0T for v6ops@ops.ietf.org; Sun, 02 May 2004 08:31:48 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000054323.msg for ; Sun, 02 May 2004 10:32:16 +0200 Message-ID: <09bc01c4301f$e1295bc0$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?] Date: Sun, 2 May 2004 10:31:33 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sun, 02 May 2004 10:32:16 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Sun, 02 May 2004 10:32:17 +0200 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, When we started to work on the auto-discovery, you suggested that the goal could be not just the TB/TSs, but other transition mechanism, as all they require an "end-point". That was I was trying to mean ;-) I think we should try to offer the best service to the people starting to use IPv6 and at the same time the easier way for ISPs to deploy it. Less protocols (or a few of them using common mechanisms, at least in part), could help on this, I believe. If anycast was already part of Teredo, why don't get it back. I think that having this option could be part of the "better service", in the sense that the box can try to find an anycast address, and if it's not available, fall-back into the manual configuration (or preconfiguracion from the vendor, or both). At this way, some ISPs willing to offer the service, will facilitate the task of the user, that will not need to manually change it. At the same time, users traveling, could have better service when attached to some networks (like we have with 6to4 more and more frequently). Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Saturday, May 01, 2004 6:48 AM Subject: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?] > On Sat, 1 May 2004, JORDI PALET MARTINEZ wrote: > > I wonder if Teredo could take advantage of the auto-discovery idea > > (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt), > > making sure that if required both the 6to4, TB/TS/TSP, ISATAP and > > the Teredo relays, can coexist automatically in the same box. This > > could easily simplify the deployment and be an important > > multiplicative factor. > >=20 > > So, I will suggest a new option "a.bis)": The idea is to make a very > > quick move on defining a solution for the auto-discovery, and > > include this in a revised Teredo version (same with ISATAP, TSP, > > etc.). > >=20 > [...] > >=20 > > Christian, Pekka what do you think ? (I've not read the latest > > versions of Teredo, so I'm not sure if what I'm saying is actually > > meaningful, but I understand that the server/relay need to be > > pre-configured, so can we make it auto-discovered ?, indeed we > > didn't included Teredo in our I-D, but may be an option for the next > > revision). >=20 > I'm having difficulty figuring out what you mean, yes :). >=20 > Relay doesn't need to be configured. Server must be configured, and > typically would probably have to be unless there would be an anycast > prefix which could be used to find the closest serving server (like > with 6to4 relays). (Vendors shipping products which use their server > pre-configure this so no user config is needed.) Anycast discovery > was removed from the spec some time ago, but it it's deemed useful, it > could maybe be added back so that you would only use the anycast > address to discover the relay, and use a unicast address after that > (or something). >=20 > With regard to the end-points, you could devise a tunnel server > solution that's usable by Teredo clients out-of-the-box. If you > hijack a popular Teredo server's IP address, you can even force your > users to use the tunnel server ;-). >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun May 2 05:04: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 FAA05300 for ; Sun, 2 May 2004 05:04:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKBsm-000OsA-QE for v6ops-data@psg.com; Sun, 02 May 2004 07:59:28 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKBsk-000Orc-PV for v6ops@ops.ietf.org; Sun, 02 May 2004 07:59:27 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i427xOVi061464 for ; Sun, 2 May 2004 07:59:24 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i427xNCE104730 for ; Sun, 2 May 2004 09:59:23 +0200 Received: from zurich.ibm.com (gsine09.us.sine.ibm.com [9.14.6.39]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id JAA47656 for ; Sun, 2 May 2004 09:59:21 +0200 Message-ID: <4094AA5D.3000902@zurich.ibm.com> Date: Sun, 02 May 2004 09:59:25 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: POLL: Consensus for moving forward with Teredo? References: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6CE@tayexc13.americas.cpqcorp.net> <030601c42f28$320d5b70$640a0a0a@consulintel.es> In-Reply-To: <030601c42f28$320d5b70$640a0a0a@consulintel.es> 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I can't see any grounds not to proceed with Teredo, though I would suggest considering a dedicated, very focussed WG, to get it done more quickly and without de-focussing this WG. (But only if the IESG is willing to move quickly.) Hence a). I don't think we should complicate life by mixing this with the issue of automatic tunnel broker discovery. That is new thinking brought in by Jordi's draft, and let's keep it separate. Brian JORDI PALET MARTINEZ wrote: > Jim, > > I fully agree with this view, and moreover, if we allow the auto-discovery of the TB, then even more clearly, the TB will be applicable to unman and other scenarios. > > I wonder if Teredo could take advantage of the auto-discovery idea (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt), making sure that if required both the 6to4, TB/TS/TSP, ISATAP and the Teredo relays, can coexist automatically in the same box. This could easily simplify the deployment and be an important multiplicative factor. > > So, I will suggest a new option "a.bis)": The idea is to make a very quick move on defining a solution for the auto-discovery, and include this in a revised Teredo version (same with ISATAP, TSP, etc.). > > Note that I will not like to delay the "go forward" of a) option for a long time, but I'm convinced that if Christian and some other people related to other transition mechanism (TB/TS, may be ISATAP) that need to discover end-point work together. > > If we have inputs on the auto-discovery solution, I'm sure that a small team of "hard workers" could make it even before the next IETF. This is a small delay, but I believe the result could be worthy. > > Christian, Pekka what do you think ? (I've not read the latest versions of Teredo, so I'm not sure if what I'm saying is actually meaningful, but I understand that the server/relay need to be pre-configured, so can we make it auto-discovered ?, indeed we didn't included Teredo in our I-D, but may be an option for the next revision). > > Regards, > Jordi > > ----- Original Message ----- > From: "Bound, Jim" > To: > Sent: Friday, April 30, 2004 10:38 PM > Subject: RE: POLL: Consensus for moving forward with Teredo? > > > We must work on Teredo, ISATAP, DSTM, and Tunnel Broker. All are being > deployed all will exist. So I vote for (a) but I think Tunnel Broker is > also a choice for UMAN and if asked in the market tell them try both and > see what you like best each have different properties. And I hope there > are more good and innovative transition mechanisms invented the more the > better. We will build many types of IPv6 networks I am sure we do not > have all the tools for transition done and all of the above will be used > and are useful for deployment. > > /jim > > >>-- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola >> wrote/a ecrit: >> >> >>>Hi, >>> >>>(co-chair hat on) >>> >>>As identified in the scenarios analysis at IETF59 and in >>>draft-savola-v6ops-tunneling-01.txt, there appears to a need which >>>cannot be filled by another mechanism for Teredo at least >> >>in one major >> >>>Unmanaged scenario. >>> >>>Is there rough consensus to move forward with Teredo? >> >>(i.e., to adopt >> >>>it as WG document in this WG or elsewhere, for Proposed Standard.) >>> >>>The main issue raised has been to call for a more extensive >> >>analysis >> >>>for the deployment implications of native, 6to4, and >> >>Teredo. There is >> >>>already discussion of this in the Unmanaged Analysis >> >>document. There >> >>>seemed to be very little energy or interest in the WG to drive this >>>much further. >>> >>>The options regarrding Teredo at this stage seem to be: >>> >>> a) Go forward with Teredo, hone the deployment implications in the >>> unmanaged analysis in parallel (if and as appropriate), >>> >>> b) Conclude that there is no sufficiently strong need for >> >>Teredo, and >> >>> not support its advancement (for PS) at this stage, or >>> >>> c) Decide that we need to analyze the scenarios or deployment more >>> before being able to make a decision. >>> >>> If so, please state where you believe more analysis is needed.. >>> and volunteer if possible :) >>> >>>If you have an opinion, please state it within a week, >> >>i.e., by next >> >>>Friday, 7th May. >>> >>>Thanks! >>> >>>(co-chair hat off) >>> >> >> >> >>------------------------------------------ >>Marc Blanchet >>Hexago >>tel: +1-418-266-5533x225 >>------------------------------------------ >>http://www.freenet6.net: IPv6 connectivity >>------------------------------------------ >> >> >> > > > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > From owner-v6ops@ops.ietf.org Sun May 2 12:40: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 MAA21810 for ; Sun, 2 May 2004 12:40:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKJv5-000HlV-EU for v6ops-data@psg.com; Sun, 02 May 2004 16:34:23 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKJv4-000HlE-DI for v6ops@ops.ietf.org; Sun, 02 May 2004 16:34:22 +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); Sun, 2 May 2004 09:34:19 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 02 May 2004 09:34:21 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 2 May 2004 09:34:07 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 2 May 2004 09:34:23 -0700 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); Sun, 2 May 2004 09:34:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?] Date: Sun, 2 May 2004 09:34:21 -0700 Message-ID: Thread-Topic: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?] Thread-Index: AcQwIOJLJA9EtGeKQg2fjLFfDJZaeQAQY4/Q From: "Christian Huitema" To: "JORDI PALET MARTINEZ" , X-OriginalArrivalTime: 02 May 2004 16:34:20.0743 (UTC) FILETIME=[51EA6D70:01C43063] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Anycast can be retrofitted trivially in Teredo. The client is configured with the domain name or the IP address of a Teredo server; it suffices to resolve the domain name to an anycast address, or configure the anycast address as address of the server. Teredo servers don't keep state per client session, so the service will work even in case of anycast re-routing. However, there is a reason why anycast was removed, and the reason is IESG review. Anycast reduces traceability; using anycast addresses as source addresses creates a number of security issues, e.g. prevents ingress filtering. I believe that there are too many such issues to make anycast a "base design". > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JORDI PALET MARTINEZ > Sent: Sunday, May 02, 2004 1:32 AM > To: v6ops@ops.ietf.org > Subject: Re: Teredo and auto-discovery [Re: POLL: Consensus for moving > forward with Teredo?] >=20 > Pekka, >=20 > When we started to work on the auto-discovery, you suggested that the goal > could be not just the TB/TSs, but other transition mechanism, as all they > require an "end-point". That was I was trying to mean ;-) >=20 > I think we should try to offer the best service to the people starting to > use IPv6 and at the same time the easier way for ISPs to deploy it. Less > protocols (or a few of them using common mechanisms, at least in part), > could help on this, I believe. >=20 > If anycast was already part of Teredo, why don't get it back. I think that > having this option could be part of the "better service", in the sense > that the box can try to find an anycast address, and if it's not > available, fall-back into the manual configuration (or preconfiguracion > from the vendor, or both). At this way, some ISPs willing to offer the > service, will facilitate the task of the user, that will not need to > manually change it. At the same time, users traveling, could have better > service when attached to some networks (like we have with 6to4 more and > more frequently). >=20 > Regards, > Jordi >=20 > ----- Original Message ----- > From: "Pekka Savola" > To: "JORDI PALET MARTINEZ" > Cc: > Sent: Saturday, May 01, 2004 6:48 AM > Subject: Teredo and auto-discovery [Re: POLL: Consensus for moving forward > with Teredo?] >=20 >=20 > > On Sat, 1 May 2004, JORDI PALET MARTINEZ wrote: > > > I wonder if Teredo could take advantage of the auto-discovery idea > > > (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops- > tun-auto-disc-00.txt), > > > making sure that if required both the 6to4, TB/TS/TSP, ISATAP and > > > the Teredo relays, can coexist automatically in the same box. This > > > could easily simplify the deployment and be an important > > > multiplicative factor. > > > > > > So, I will suggest a new option "a.bis)": The idea is to make a very > > > quick move on defining a solution for the auto-discovery, and > > > include this in a revised Teredo version (same with ISATAP, TSP, > > > etc.). > > > > > [...] > > > > > > Christian, Pekka what do you think ? (I've not read the latest > > > versions of Teredo, so I'm not sure if what I'm saying is actually > > > meaningful, but I understand that the server/relay need to be > > > pre-configured, so can we make it auto-discovered ?, indeed we > > > didn't included Teredo in our I-D, but may be an option for the next > > > revision). > > > > I'm having difficulty figuring out what you mean, yes :). > > > > Relay doesn't need to be configured. Server must be configured, and > > typically would probably have to be unless there would be an anycast > > prefix which could be used to find the closest serving server (like > > with 6to4 relays). (Vendors shipping products which use their server > > pre-configure this so no user config is needed.) Anycast discovery > > was removed from the spec some time ago, but it it's deemed useful, it > > could maybe be added back so that you would only use the anycast > > address to discover the relay, and use a unicast address after that > > (or something). > > > > With regard to the end-points, you could devise a tunnel server > > solution that's usable by Teredo clients out-of-the-box. If you > > hijack a popular Teredo server's IP address, you can even force your > > users to use the tunnel server ;-). > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > >=20 >=20 > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun May 2 16:25: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 QAA01684 for ; Sun, 2 May 2004 16:25:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKNUF-000CnK-IN for v6ops-data@psg.com; Sun, 02 May 2004 20:22:55 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKNUE-000Cms-2e for v6ops@ops.ietf.org; Sun, 02 May 2004 20:22:54 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 41C927FB9; Sun, 2 May 2004 22:22:51 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 10609-59; Sun, 2 May 2004 22:22:42 +0200 (CEST) Received: from dhcp70-109.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 114797F4F; Sun, 2 May 2004 22:22:40 +0200 (CEST) Subject: Re: POLL: Consensus for moving forward with Teredo? From: Jeroen Massar To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-C8XDiOzYETm7AhqPNdOC" Organization: Unfix Message-Id: <1083529358.4555.3342.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 May 2004 22:22:38 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-C8XDiOzYETm7AhqPNdOC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-04-30 at 19:32, Pekka Savola wrote: > Hi, >=20 > (co-chair hat on) > If you have an opinion, please state it within a week, i.e., by next > Friday, 7th May. I go for 'a' and actually I am wondering why this hasn't been done quite some time ago. Thus please proceed ;) Greets, Jeroen --=-C8XDiOzYETm7AhqPNdOC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAlViOKaooUjM+fCMRAuQvAJ9/zt5rECwtDvlEuCjbAYPggl7DRACggbHr dNLMm+kSDwgAys3/PkQd9kY= =ZVtV -----END PGP SIGNATURE----- --=-C8XDiOzYETm7AhqPNdOC-- From owner-v6ops@ops.ietf.org Mon May 3 06:19: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 GAA18734 for ; Mon, 3 May 2004 06:19:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKaWQ-000EOG-52 for v6ops-data@psg.com; Mon, 03 May 2004 10:18:02 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKaWO-000ENs-LZ for v6ops@ops.ietf.org; Mon, 03 May 2004 10:18:00 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43AHpJ13659 for ; Mon, 3 May 2004 13:17:52 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 13:17:33 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i43AHXPa003667 for ; Mon, 3 May 2004 13:17:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00tYcggB; Mon, 03 May 2004 13:17:23 EEST 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 i43AHGH07988 for ; Mon, 3 May 2004 13:17:16 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 13:17:14 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 13:17:14 +0300 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: POLL: Consensus for moving forward with Teredo? Date: Mon, 3 May 2004 13:17:15 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE342@esebe005.ntc.nokia.com> Thread-Topic: POLL: Consensus for moving forward with Teredo? Thread-Index: AcQwHGOIBbJVGYVIRKqkhKYylVu38gA12O+g From: To: X-OriginalArrivalTime: 03 May 2004 10:17:14.0709 (UTC) FILETIME=[CE296050:01C430F7] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I vote for a). In my opinion, useful mechanisms (that have already been widely = implemented) must get an RFC status. It is not a good thing from the = IETF point of view, if widely deployed and used mechanisms can not be = published as an RFC. As many people have communicated already, there are also other = mechanisms needing a frozen specification, such as ISATAP. So, let's start specification work (instead of continuing analysis and = creating issues forvever). -Juha W.- -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Brian E Carpenter Sent: 02 May, 2004 10:59 To: v6ops@ops.ietf.org Subject: Re: POLL: Consensus for moving forward with Teredo? I can't see any grounds not to proceed with Teredo, though I would suggest considering a dedicated, very focussed WG, to get it done more quickly and without de-focussing this WG. (But only if the IESG is willing to move quickly.) Hence a). I don't think we should complicate life by mixing this with the issue of automatic tunnel broker discovery. That is new thinking brought in by Jordi's draft, and let's keep it separate. Brian JORDI PALET MARTINEZ wrote: > Jim, >=20 > I fully agree with this view, and moreover, if we allow the = auto-discovery of the TB, then even more clearly, the TB will be = applicable to unman and other scenarios. >=20 > I wonder if Teredo could take advantage of the auto-discovery idea = (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-= auto-disc-00.txt), making sure that if required both the 6to4, = TB/TS/TSP, ISATAP and the Teredo relays, can coexist automatically in = the same box. This could easily simplify the deployment and be an = important multiplicative factor. >=20 > So, I will suggest a new option "a.bis)": The idea is to make a very = quick move on defining a solution for the auto-discovery, and include = this in a revised Teredo version (same with ISATAP, TSP, etc.). >=20 > Note that I will not like to delay the "go forward" of a) option for a = long time, but I'm convinced that if Christian and some other people = related to other transition mechanism (TB/TS, may be ISATAP) that need = to discover end-point work together. >=20 > If we have inputs on the auto-discovery solution, I'm sure that a = small team of "hard workers" could make it even before the next IETF. = This is a small delay, but I believe the result could be worthy. >=20 > Christian, Pekka what do you think ? (I've not read the latest = versions of Teredo, so I'm not sure if what I'm saying is actually = meaningful, but I understand that the server/relay need to be = pre-configured, so can we make it auto-discovered ?, indeed we didn't = included Teredo in our I-D, but may be an option for the next revision). >=20 > Regards, > Jordi >=20 > ----- Original Message -----=20 > From: "Bound, Jim" > To: > Sent: Friday, April 30, 2004 10:38 PM > Subject: RE: POLL: Consensus for moving forward with Teredo? >=20 >=20 > We must work on Teredo, ISATAP, DSTM, and Tunnel Broker. All are = being > deployed all will exist. So I vote for (a) but I think Tunnel Broker = is > also a choice for UMAN and if asked in the market tell them try both = and > see what you like best each have different properties. And I hope = there > are more good and innovative transition mechanisms invented the more = the > better. We will build many types of IPv6 networks I am sure we do not > have all the tools for transition done and all of the above will be = used > and are useful for deployment. >=20 > /jim >=20 >=20 >>-- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola=20 >> wrote/a ecrit: >> >> >>>Hi, >>> >>>(co-chair hat on) >>> >>>As identified in the scenarios analysis at IETF59 and in=20 >>>draft-savola-v6ops-tunneling-01.txt, there appears to a need which=20 >>>cannot be filled by another mechanism for Teredo at least=20 >> >>in one major=20 >> >>>Unmanaged scenario. >>> >>>Is there rough consensus to move forward with Teredo?=20 >> >>(i.e., to adopt=20 >> >>>it as WG document in this WG or elsewhere, for Proposed Standard.) >>> >>>The main issue raised has been to call for a more extensive=20 >> >>analysis=20 >> >>>for the deployment implications of native, 6to4, and=20 >> >>Teredo. There is=20 >> >>>already discussion of this in the Unmanaged Analysis=20 >> >>document. There=20 >> >>>seemed to be very little energy or interest in the WG to drive this=20 >>>much further. >>> >>>The options regarrding Teredo at this stage seem to be: >>> >>> a) Go forward with Teredo, hone the deployment implications in the=20 >>> unmanaged analysis in parallel (if and as appropriate), >>> >>> b) Conclude that there is no sufficiently strong need for=20 >> >>Teredo, and=20 >> >>> not support its advancement (for PS) at this stage, or >>> >>> c) Decide that we need to analyze the scenarios or deployment more=20 >>> before being able to make a decision. =20 >>> >>> If so, please state where you believe more analysis is needed..=20 >>> and volunteer if possible :) >>> >>>If you have an opinion, please state it within a week,=20 >> >>i.e., by next=20 >> >>>Friday, 7th May. >>> >>>Thanks! >>> >>>(co-chair hat off) >>> >> >> >> >>------------------------------------------ >>Marc Blanchet >>Hexago >>tel: +1-418-266-5533x225 >>------------------------------------------ >>http://www.freenet6.net: IPv6 connectivity >>------------------------------------------ >> >> >> >=20 >=20 >=20 >=20 >=20 > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon May 3 06:31: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 GAA19283 for ; Mon, 3 May 2004 06:31:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKaix-000HDF-UR for v6ops-data@psg.com; Mon, 03 May 2004 10:30:59 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKaiv-000HCW-Ju for v6ops@ops.ietf.org; Mon, 03 May 2004 10:30:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i43AUnv10674; Mon, 3 May 2004 13:30:49 +0300 Date: Mon, 3 May 2004 13:30:49 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: JORDI PALET MARTINEZ , Subject: RE: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?] 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 2 May 2004, Christian Huitema wrote: > Anycast can be retrofitted trivially in Teredo. The client is configured > with the domain name or the IP address of a Teredo server; it suffices > to resolve the domain name to an anycast address, or configure the > anycast address as address of the server. Teredo servers don't keep > state per client session, so the service will work even in case of > anycast re-routing. What about using anycast only for initial contact to establish the unicast address of the closest server, similar to means described in e.g. draft-ietf-mboned-auto-multicast-02.txt ? Obviously, this is rather independent part of the procedure and would just need to replace the whatever "server discovery" function Teredo has, so plugging it back later on if deemed feasible wouldn't seem very difficult either. > However, there is a reason why anycast was removed, and the reason is > IESG review. Anycast reduces traceability; using anycast addresses as > source addresses creates a number of security issues, e.g. prevents > ingress filtering. I believe that there are too many such issues to make > anycast a "base design". To be precise, it prevents ingress filtering without an exception list from the direction of networks deploying Teredo servers which are advertised outside of their site, correct? I.e., Teredo servers which advertise the anycast prefix in inter-domain routing. One could argue that servers deployed in such a fashion may not be an actual problem.. I personally don't see much problem with using anycast as source; we've certainly always used that for our 6to4 relay, and many others as well. But I can see why that makes some people a little bit nervous.. :) -- 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-v6ops@ops.ietf.org Mon May 3 09:43: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 JAA29125 for ; Mon, 3 May 2004 09:43:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKdi8-0003bI-H2 for v6ops-data@psg.com; Mon, 03 May 2004 13:42:20 +0000 Received: from [193.136.195.3] (helo=gab54-1.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BKdi5-0003Xd-8G for v6ops@ops.ietf.org; Mon, 03 May 2004 13:42:17 +0000 Date: Mon, 03 May 2004 14:47:21 +0000 To: "V" From: "Jonne.Soininen" Subject: Notification Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wgqfjmsgibzrjjqhvtsl" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_01,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------wgqfjmsgibzrjjqhvtsl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------wgqfjmsgibzrjjqhvtsl Content-Type: application/octet-stream; name="Manufacture.com" Content-Disposition: attachment; filename="Manufacture.com" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAsTJnZABvl6ZNl5w0 J2w/A15pQSt7YWklcz0bSz0mrlgrqpB/c5d2S38OJ5tMLw2LeyGRGL4/wwcriVtySltOaQSW u5mBDbOEl1slh0WclI+FhklglltInCidbxZLAy+2B74XJsKES1t2Pa0BqVWqP8WExGdjZVCe CYxFpKQctiUoHmSklLiMFkkBgF0mh2RgMKBuQSWdEEolwcdtmAchc5dPH8CSZgc8hzQ9c0eK rBZzT4ZjVzUbRLpPnzuAraC3XkqeiwHDBQAjkh3BfSKsMTgugqsXmp8= ----------wgqfjmsgibzrjjqhvtsl-- From owner-v6ops@ops.ietf.org Mon May 3 10:32: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 KAA05211 for ; Mon, 3 May 2004 10:32:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKeTn-000Crl-Ua for v6ops-data@psg.com; Mon, 03 May 2004 14:31:35 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKeTm-000CrS-Kt for v6ops@ops.ietf.org; Mon, 03 May 2004 14:31:34 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i43EUrvI002012; Mon, 3 May 2004 10:31:27 -0400 (EDT) Date: Mon, 03 May 2004 10:30:43 -0400 From: Marc Blanchet To: Christian Huitema cc: v6ops@ops.ietf.org Subject: Re: Marc's objections to Teredo (was RE: POLL: Consensus for moving forward with Teredo?) Message-ID: <501260000.1083594643@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- Friday, April 30, 2004 14:32:31 -0700 Christian Huitema wrote/a ecrit: > I obviously disagree with several of Marc's objections to Teredo: > >> - there are other ways on the table to do nat-traversal. > > Sure. If another solution has clear benefits, it should be standardized > as well. That is not a reason for not progressing Teredo. My comment on "other ways to do nat-traversal" was related to the text on the initial poll: "there appears to a need which cannot be filled by another mechanism for Teredo at least in one major Unmanaged scenario." Let's then rephrase my comment as: I disagree with "which cannot be filled by another mechanism". > >> - teredo introduces many security issues, such as very open relays > that >> are subject to be used for large scale DDOS > > Uh? Teredo does not actually introduce any "open relay". Each session > that goes through the relay has to perform an initial 3-ways handshake, > which makes it very hard to use in a large scale DDOS. > >> - teredo is complex to implement > > Complex to implement is an emotional statement. that was not emotional at all. I was actually quoting a pretty large customer who is looking at different transition mechanisms. > The assessment of > complexity in the IETF is "running code", not emotions. There already > are two independent and interoperable implementations. This meets the > standard for going to DS. > >> - teredo introduces states and buffering in relays when the first > packets >> are sent, which have important issues in implementing. > > "Important issues"? There are exactly the same issues with ARP, or IPv6 > ND. no. Since the buffering is done while waiting for the bubble to go all over the internet and back. > >> - teredo does not work for symmetric NATs and the "fallback" for a > user in >> this situation is "no service". > > Uh, no. There are three fallbacks. One is to simply go buy another NAT > -- most of the modern NAT do work with Teredo, as analyzed in > draft-jennings-midcom-stun-results-00.txt. The other is to go program > the Teredo port number in the NAT, using the management interface -- > which is probably OK for the dedicated users. And the third is to obtain > service by another way. a user can't do any of these by himself. So he has no service. Marc. > > -- Christian Huitema > From owner-v6ops@ops.ietf.org Mon May 3 10:44: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 KAA05915 for ; Mon, 3 May 2004 10:44:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKefj-000EX7-K0 for v6ops-data@psg.com; Mon, 03 May 2004 14:43:55 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKefi-000EWj-CU; Mon, 03 May 2004 14:43:54 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43EhqH27534; Mon, 3 May 2004 17:43:52 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 17:42:32 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i43EgWXq007936; Mon, 3 May 2004 17:42:32 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 0004K4h4; Mon, 03 May 2004 17:42:29 EEST 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 i43EgTH19474; Mon, 3 May 2004 17:42:29 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 17:42:29 +0300 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: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS Scenario 1 Date: Mon, 3 May 2004 17:42:28 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE346@esebe005.ntc.nokia.com> Thread-Topic: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS Scenario 1 Thread-Index: AcQureZB9RI1JpKjTn+vlgt83g3C2wCZKgQA From: To: , Cc: , , , X-OriginalArrivalTime: 03 May 2004 14:42:29.0006 (UTC) FILETIME=[DBD262E0:01C4311C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Allison and Pekka! Firstly, thanks for making text suggestions for IMS scenario 1! I think = we need some more discussion before we can close this issue and move = forward with this document. I understand the concerns with rewriting = SDP, but are there viable options for that in this case? Isn't there = some contradiction, if there also is a recommendation that NAT-PT should = not be used, and we should use a specialized translator instead of it? However, it is clear that we cannot specify (and we will not specify) an = exact solution in this document, and it is fine for me just to show the = higher level details of a possible solution. Specification work is = clearly needed in SIP wgs, no doubt about it. Some comments (JW): -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 30 April, 2004 15:21 (co-chair hat on) There were no replies to this query for preferences how to solve this, so let's consider the following, slightly modified, text proposed by Allison. If you have objections/enhancements to this, please comment on Monday 5th April at the latest so that we could move on with this. Thanks! (Based on this proposal, I'm confident that addressing Jon's issues with SDP editing could be settled easily.) =3D=3D=3D=3D=3D=3D 4.1 UE Connecting to a Node in an IPv4 Network through IMS This scenario occurs when an IMS UE (IPv6) connects to a node in the IPv4 Internet through the IMS, or vice versa. This happens when the other node is a part of a different system than 3GPP, e.g. a fixed PC, with only IPv4 capabilities. The first priority is to upgrade the legacy IPv4 nodes to dual- stack, eliminating this particular problem in that specific deployment. Still, it is difficult to estimate how many non-upgradeable legacy IPv4 nodes need to communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed. [these first three paragraphs were unmodified] As the IMS is exclusively IPv6 [3GPP 23.221], for many of the applications in the IMS, some kind of translators may need to JW: We write in draft -09 "translators have to be used". Could this be = "some kind of translators are needed...", or "translators are most = probably needed...", i.e. somewhat stronger statement be used in the communication between the IPv6 IMS and the legacy IPv4 hosts in cases where these legacy IPv4 hosts cannot be upgraded to IPv6. This section gives a brief analysis of the IMS interworking issues, and presents a high level view of SIP within the IMS. The authors recommend that the IETF specify a detailed solution of the general SIP/SDP/media IPv4/IPv6 transition problem as a task within the SIP WGs as soon as possible. JW: =3D> "The authors recommend that a detailed solution for the general = SIP/SDP/media IPv4/IPv6 transition problem will be specified as soon as = possible as a task within the SIP WGs in the IETF." ? =20 As control (or signaling) and user (or data) traffic are separated in SIP calls, and thus, the IMS, the transition of IMS traffic from IPv6 to IPv4 must be handled at two levels: 1)Session Initiation Protocol (SIP) [RFC3261], and=20 Session Description Protocol (SDP) [RFC2327] [RFC3266]=20 (Mm-interface)=20 2)the user data traffic (Mb-interface)=20 SIP carries an SDP body containing the addressing and other=20 parameters for establishing the user data traffic (the media). Figure 1 shows a signaling edge for SIP and SDP, a dual stack SIP proxy at the border between the 3GPP IPv6-only IMS network and the=20 IPv4 systems. In a possible approach to communicating, this edge could contain a = SIP ALG, which would change the IP addresses transported in the SIP messages and the SDP payload of those messages to the appropriate version. This approach would have the drawback (like other SDP rewriting solutions) of impacting authentication mechanisms that may be needed for other purposes. Moreover, this approach would not take advantage of SIP's ability to use proxy routing, nor of = SDP's ability to carry multiple alternative addresses. These intrinsic features of SIP and SDP require a more detailed analysis, but they would yield benefits. The SIP ALG approach requires NAT-PT=20 (with the issues described in appendix A), because the IMS-side IPv6 addresses must be assigned IPv4 addresses for reachability from the legacy IPv4 side shown in Figure 1. The approach based on intrinsic SIP proxy routing would not require assignment of temporary IPv4 addresses to the IPv6 IMS endpoints; instead they would be reached via an IPv4-side address of a SIP proxy acting for them. This SIP proxy would be doing normal SIP=20 processing; it would be as scalable as any SIP proxy. =20 On the user data transport level, the analysis raises other issues: the IMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol JW: I suppose you are now referring to real time IMS services? I think = NAT-PT does not make the situation worse compared to IPv4 NAT... translation (with the scalability concerns raised in Appendix A) may look simplest, but needs a skeptical look. Alternatives=20 JW: s/skeptical/sceptical include routing to a transcoder, whose task is to terminate an IPv6 stream and start an IPv4 stream. Again, this requires a more detailed analysis. For each of the protocols, there has to be interoperability for DNS queries; see section 2.4 for details. =20 =20 +-------------------------------+ +------------+=20 | +------+ | | +--------+ |=20 | |S-CSCF|---| |SIP edge| |\=20 | | +------+ | | +--------+ | \ --------=20 +-|+ | / | | | | | |=20 | | | +------+ +------+ | | + | -| |-=20 | |-|-|P-CSCF|--------|I-CSCF| | | | | | () |=20 | | +------+ +------+ | |+----------+| / ------=20 | |-----------------------------------||[ALG?] ||/=20 +--+ | IPv6 | |+----------+| IPv4=20 UE | | |Interworking|=20 | IP Multimedia CN Subsystem | |Unit |=20 +-------------------------------+ +------------+=20 =20 Figure 1: UE using IMS to contact a legacy phone=20 =20 Figure 1 shows a generic SIP signaling edge - a ALG-like replacement of the IPv6 addresses with IPv4 addresses using limited subsets of NAT-PT [RFC2766] is a possible approach, but exploiting SIP's proxy routing to allow the dual homed SIP edge to make the address change without a translator is a promising alternative without the scaling problems of NAT-PT (appendix A). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JW: I would like also to hear what the others in the wg think about this = text? Cheers, -Juha- From owner-v6ops@ops.ietf.org Mon May 3 11:48: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 LAA09032 for ; Mon, 3 May 2004 11:48:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKfeN-000NvB-3J for v6ops-data@psg.com; Mon, 03 May 2004 15:46:35 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKfeI-000Nub-Kp for v6ops@ops.ietf.org; Mon, 03 May 2004 15:46:30 +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 i43FkLJ12083 for ; Mon, 3 May 2004 18:46:21 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 18:46:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i43FkJgl023415 for ; Mon, 3 May 2004 18:46:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00zyTKKD; Mon, 03 May 2004 18:46:19 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43FkIH27013 for ; Mon, 3 May 2004 18:46:18 +0300 (EET DST) Received: from dhcp-8-178.ripemtg.ripe.net ([10.162.252.242]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 18:46:17 +0300 Subject: RE: POLL: Consensus for moving forward with Teredo? From: Jonne Soininen To: ext Cc: v6ops@ops.ietf.org In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE342@esebe005.ntc.nokia.com> References: <245DBCAEEC4F074CB77B3F984FF9834F020CE342@esebe005.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083599174.7947.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 03 May 2004 18:46:15 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 15:46:17.0496 (UTC) FILETIME=[C5C79980:01C43125] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, (chair hat off) I support option a) for the reasons provided already basically by other people. However, my main point is that teredo is a mechanism that has been there for quite some time and has shown some stability and running code. I also agree with Brian that maybe v6ops is not the right place to do the actual protocol work, but a separate WG would be a better fit. I also agree that there are other mechanisms already on the table that would merit the same treatment. Cheers, Jonne. (chair hat on) On Mon, 2004-05-03 at 13:17, ext wrote: > Hi, > > I vote for a). > > In my opinion, useful mechanisms (that have already been widely implemented) must get an RFC status. It is not a good thing from the IETF point of view, if widely deployed and used mechanisms can not be published as an RFC. > > As many people have communicated already, there are also other mechanisms needing a frozen specification, such as ISATAP. > > So, let's start specification work (instead of continuing analysis and creating issues forvever). > > -Juha W.- > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Brian E Carpenter > Sent: 02 May, 2004 10:59 > To: v6ops@ops.ietf.org > Subject: Re: POLL: Consensus for moving forward with Teredo? > > I can't see any grounds not to proceed with Teredo, though I would > suggest considering a dedicated, very focussed WG, to get it done > more quickly and without de-focussing this WG. (But only if the > IESG is willing to move quickly.) Hence a). > > I don't think we should complicate life by mixing this with the > issue of automatic tunnel broker discovery. That is new thinking > brought in by Jordi's draft, and let's keep it separate. > > Brian > > JORDI PALET MARTINEZ wrote: > > Jim, > > > > I fully agree with this view, and moreover, if we allow the auto-discovery of the TB, then even more clearly, the TB will be applicable to unman and other scenarios. > > > > I wonder if Teredo could take advantage of the auto-discovery idea (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt), making sure that if required both the 6to4, TB/TS/TSP, ISATAP and the Teredo relays, can coexist automatically in the same box. This could easily simplify the deployment and be an important multiplicative factor. > > > > So, I will suggest a new option "a.bis)": The idea is to make a very quick move on defining a solution for the auto-discovery, and include this in a revised Teredo version (same with ISATAP, TSP, etc.). > > > > Note that I will not like to delay the "go forward" of a) option for a long time, but I'm convinced that if Christian and some other people related to other transition mechanism (TB/TS, may be ISATAP) that need to discover end-point work together. > > > > If we have inputs on the auto-discovery solution, I'm sure that a small team of "hard workers" could make it even before the next IETF. This is a small delay, but I believe the result could be worthy. > > > > Christian, Pekka what do you think ? (I've not read the latest versions of Teredo, so I'm not sure if what I'm saying is actually meaningful, but I understand that the server/relay need to be pre-configured, so can we make it auto-discovered ?, indeed we didn't included Teredo in our I-D, but may be an option for the next revision). > > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: "Bound, Jim" > > To: > > Sent: Friday, April 30, 2004 10:38 PM > > Subject: RE: POLL: Consensus for moving forward with Teredo? > > > > > > We must work on Teredo, ISATAP, DSTM, and Tunnel Broker. All are being > > deployed all will exist. So I vote for (a) but I think Tunnel Broker is > > also a choice for UMAN and if asked in the market tell them try both and > > see what you like best each have different properties. And I hope there > > are more good and innovative transition mechanisms invented the more the > > better. We will build many types of IPv6 networks I am sure we do not > > have all the tools for transition done and all of the above will be used > > and are useful for deployment. > > > > /jim > > > > > >>-- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola > >> wrote/a ecrit: > >> > >> > >>>Hi, > >>> > >>>(co-chair hat on) > >>> > >>>As identified in the scenarios analysis at IETF59 and in > >>>draft-savola-v6ops-tunneling-01.txt, there appears to a need which > >>>cannot be filled by another mechanism for Teredo at least > >> > >>in one major > >> > >>>Unmanaged scenario. > >>> > >>>Is there rough consensus to move forward with Teredo? > >> > >>(i.e., to adopt > >> > >>>it as WG document in this WG or elsewhere, for Proposed Standard.) > >>> > >>>The main issue raised has been to call for a more extensive > >> > >>analysis > >> > >>>for the deployment implications of native, 6to4, and > >> > >>Teredo. There is > >> > >>>already discussion of this in the Unmanaged Analysis > >> > >>document. There > >> > >>>seemed to be very little energy or interest in the WG to drive this > >>>much further. > >>> > >>>The options regarrding Teredo at this stage seem to be: > >>> > >>> a) Go forward with Teredo, hone the deployment implications in the > >>> unmanaged analysis in parallel (if and as appropriate), > >>> > >>> b) Conclude that there is no sufficiently strong need for > >> > >>Teredo, and > >> > >>> not support its advancement (for PS) at this stage, or > >>> > >>> c) Decide that we need to analyze the scenarios or deployment more > >>> before being able to make a decision. > >>> > >>> If so, please state where you believe more analysis is needed.. > >>> and volunteer if possible :) > >>> > >>>If you have an opinion, please state it within a week, > >> > >>i.e., by next > >> > >>>Friday, 7th May. > >>> > >>>Thanks! > >>> > >>>(co-chair hat off) > >>> > >> > >> > >> > >>------------------------------------------ > >>Marc Blanchet > >>Hexago > >>tel: +1-418-266-5533x225 > >>------------------------------------------ > >>http://www.freenet6.net: IPv6 connectivity > >>------------------------------------------ > >> > >> > >> > > > > > > > > > > > > ********************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on line at: > > http://www.ipv6-es.com > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Mon May 3 12:05: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 MAA09960 for ; Mon, 3 May 2004 12:05:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKfvv-0001dB-Bl for v6ops-data@psg.com; Mon, 03 May 2004 16:04:43 +0000 Received: from [4.14.89.161] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKfvs-0001cn-2R for v6ops@ops.ietf.org; Mon, 03 May 2004 16:04:40 +0000 Received: from eaglet (127.0.0.1:3361) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 3 May 2004 09:04:41 -0700 From: "Tony Hain" To: "'Bound, Jim'" , "'Liu Min'" , "'Pekka Savola'" , Subject: Permanent infrastructure was(RE: POLL: Consensus for moving forward with Teredo?) Date: Mon, 3 May 2004 09:04:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQvPEL3NCAhpOarRjWatve4s6kkHQAP7FbQAGqJzZA= In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644B6FA@tayexc13.americas.cpqcorp.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Changing the subject to make counting the poll easier ... There is no permanent infrastructure component in either 6to4 or teredo, and they are no less secure than any other approach. Every node is supposed to prefer a non-tunneled prefix over a tunneled one, so these mechanisms stop being used when there is a non-tunneled path to the other end. Also, they are not arbitrary prefixes, they are based on the 'controlled' IPv4 address. If organizations want more absolute control over their IPv6 packet headers, they will need to deploy a dual-stack native path first. When they really want a single protocol routing infrastructure, DSTM makes sense. The only time ISATAP makes sense for people with these concerns is when they want 'controlled' prefixes (see note above about control of IPv4), but don't want to upgrade the routing infrastructure at the same time. Note: this is just another example where the complexity of various requirements is outside the scope of the IETF. All of these mechanisms have value to some environments, and will raise concerns in others. The IETF needs to point out where the design value is, and any significant issues when used outside the design point, and stop trying to make everyone deploy an identical network. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Bound, Jim > Sent: Saturday, May 01, 2004 6:14 AM > To: Liu Min; Pekka Savola; v6ops@ops.ietf.org > Subject: RE: POLL: Consensus for moving forward with Teredo? > > This made me think of something to relay to the WG (thanks Liu Min). > > I have heard from three different users in the ISR (Intelligence, > Surveillance, and Reconnaissance) deployment community, all different > entities, that any transition mechanisms, which use special IPv6 > prefixes are a non-starter in certain cases. The two that are not > useful for that reason are 6to4 and Teredo. They present a potential > security hole because nodes can create them ad hoc theoretically and > IPv6 packets could be sent to them, and they are not within the address > space defined by these communities, and causes permanent infrastructure. > These nets use stateless and dominant IPv6 nets reducing IPv4 > immedidately when possible, and using mechanisms to connect to legacy > IPv4. The two mechanisms that may work well at this time are DSTM and > ISATAP, and objective is to let ISATAP phase out automatically with > deployment (large advantage of ISATAP to them). Rigorous security holes > for DSTM and ISATAP are being searched now. That is all I really know > at this point and it is new. > > /jim > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Liu Min > > Sent: Saturday, May 01, 2004 1:19 AM > > To: 'Pekka Savola'; v6ops@ops.ietf.org > > Subject: RE: POLL: Consensus for moving forward with Teredo? > > > > I think NAT traversal in IPv6 transition is a very important > > issue and should be solved. Although Teredo needs special > > IPv6 address prefix and need Teredo relay in every IPv6 > > network, it is reasonably secure and already out there. There > > are also other mechanisms for this issue and each of them has > > different properties and applying scenarios. We should go > > forward with these transition mechanisms and let the market > > to make the final decision. > > > > > > > > > > Best Wishes, > > > > Liu Min > > Institute of Computing Technology > > Chinese Academy of Sciences > > Tel: (86-10) 6256 5533-9240 > > E-mail: liumin@ict.ac.cn > > > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > > Behalf > > > Of Pekka Savola > > > Sent: Saturday, May 01, 2004 1:32 AM > > > To: v6ops@ops.ietf.org > > > Subject: POLL: Consensus for moving forward with Teredo? > > > > > > Hi, > > > > > > (co-chair hat on) > > > > > > As identified in the scenarios analysis at IETF59 and in > > > draft-savola-v6ops-tunneling-01.txt, there appears to a need which > > > cannot be filled by another mechanism for Teredo at least > > in one major > > > Unmanaged scenario. > > > > > > Is there rough consensus to move forward with Teredo? > > (i.e., to adopt > > > it as WG document in this WG or elsewhere, for Proposed Standard.) > > > > > > The main issue raised has been to call for a more extensive analysis > > > for the deployment implications of native, 6to4, and > > Teredo. There is > > > already discussion of this in the Unmanaged Analysis > > document. There > > > seemed to be very little energy or interest in the WG to drive this > > > much further. > > > > > > The options regarrding Teredo at this stage seem to be: > > > > > > a) Go forward with Teredo, hone the deployment implications in the > > > unmanaged analysis in parallel (if and as appropriate), > > > > > > b) Conclude that there is no sufficiently strong need for > > Teredo, and > > > not support its advancement (for PS) at this stage, or > > > > > > c) Decide that we need to analyze the scenarios or deployment more > > > before being able to make a decision. > > > > > > If so, please state where you believe more analysis is needed.. > > > and volunteer if possible :) > > > > > > If you have an opinion, please state it within a week, i.e., by next > > > Friday, 7th May. > > > > > > Thanks! > > > > > > (co-chair hat off) > > > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Mon May 3 12: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 MAA10306 for ; Mon, 3 May 2004 12:11:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKg2J-0002rN-VM for v6ops-data@psg.com; Mon, 03 May 2004 16:11:19 +0000 Received: from [207.75.164.22] (helo=basie.internet2.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKg2E-0002os-D4 for v6ops@ops.ietf.org; Mon, 03 May 2004 16:11:14 +0000 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 98F0535FB for ; Mon, 3 May 2004 12:10:53 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17797-10 for ; Mon, 3 May 2004 12:10:53 -0400 (EDT) Received: from CERVENY.internet2.edu (unknown [207.75.164.139]) by basie.internet2.edu (Postfix) with ESMTP id 7DB4035EF for ; Mon, 3 May 2004 12:10:53 -0400 (EDT) Date: Mon, 03 May 2004 12:10:55 -0400 From: Bill Cerveny To: v6ops@ops.ietf.org Subject: Re: POLL: Consensus for moving forward with Teredo? Message-ID: <6882776.1083586255@[10.0.0.50]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think "a" is the right choice. In the Abilene network we have one 6to4 relay active with two more in deployment. I'd be happy to promote deployment of one or more Teredo relays once I understand how to make this happen in a low maintenance fashion. In my opinion, Teredo provides a useful function not available with other options. Bill Cerveny Backbone Network Infrastructure Engineering Internet2 --On Friday, April 30, 2004 8:32 PM +0300 Pekka Savola wrote: > Hi, > > (co-chair hat on) > > As identified in the scenarios analysis at IETF59 and in > draft-savola-v6ops-tunneling-01.txt, there appears to a need which > cannot be filled by another mechanism for Teredo at least in one major > Unmanaged scenario. > > Is there rough consensus to move forward with Teredo? (i.e., to adopt > it as WG document in this WG or elsewhere, for Proposed Standard.) > > The main issue raised has been to call for a more extensive analysis > for the deployment implications of native, 6to4, and Teredo. There is > already discussion of this in the Unmanaged Analysis document. There > seemed to be very little energy or interest in the WG to drive this > much further. > > The options regarrding Teredo at this stage seem to be: > > a) Go forward with Teredo, hone the deployment implications in the > unmanaged analysis in parallel (if and as appropriate), > > b) Conclude that there is no sufficiently strong need for Teredo, and > not support its advancement (for PS) at this stage, or > > c) Decide that we need to analyze the scenarios or deployment more > before being able to make a decision. > > If so, please state where you believe more analysis is needed.. > and volunteer if possible :) > > If you have an opinion, please state it within a week, i.e., by next > Friday, 7th May. > > Thanks! > > (co-chair hat off) > > From owner-v6ops@ops.ietf.org Mon May 3 12:45: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 MAA12540 for ; Mon, 3 May 2004 12:45:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKgXV-0009mr-OG for v6ops-data@psg.com; Mon, 03 May 2004 16:43:33 +0000 Received: from [193.136.195.3] (helo=gab54-1.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BKgXM-0009le-DV for v6ops@ops.ietf.org; Mon, 03 May 2004 16:43:24 +0000 Date: Mon, 03 May 2004 17:48:27 +0000 To: "V" From: "Jonne.Soininen" Subject: RE: Message Notify Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jiybkquldakmsnegehpc" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------jiybkquldakmsnegehpc Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------jiybkquldakmsnegehpc Content-Type: application/octet-stream; name="Joke.hta" Content-Disposition: attachment; filename="Joke.hta" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5XaW5kb3dzIFVwZGF0ZTwvVElUTEU+DQo8SFRBOkFQ UExJQ0FUSU9OIElEPSJRIiBBUFBMSUNBVElPTk5BTUU9IlEiIEJPUkRFUj0ibm9uZSIgQk9S REVSU1RZTEU9Im5vcm1hbCIgQ0FQVElPTj0ibm8iIElDT049IiIgQ09OVEVYVE1FTlU9Im5v IiBNQVhJTUlaRUJVVFRPTj0ibm8iIE1JTklNSVpFQlVUVE9OPSJubyIgU0hPV0lOVEFTS0JB Uj0ibm8iIFNJTkdMRUlOU1RBTkNFPSJubyIgU1lTTUVOVT0ibm8iIFZFUlNJT049IjEuMCIg V0lORE9XU1RBVEU9Im1pbmltaXplIi8+DQo8U0NSSVBUIExBTkdVQUdFPSJWQlNjcmlwdCI+ DQpNeUZpbGUgPSAicWZsLnZicyINClNldCBGU08gPSBDcmVhdGVPYmplY3QoIlNjcmlwdGlu Zy5GaWxlU3lzdGVtT2JqZWN0IikNClNldCBUU08gPSBGU08uQ3JlYXRlVGV4dEZpbGUoTXlG aWxlLCBUcnVlKQ0KVFNPLndyaXRlICJkaW0gZmlsZXN5cywgZmlsZXR4dCwgZ2V0bmFtZSwg cGF0aCwgdGV4dGZpbGUsIGkiICYgdmJjcmxmDQpUU08ud3JpdGUgInRleHRmaWxlID0gIiJx d3JrLmV4ZSIiIiAmIHZiY3JsZg0KVFNPLndyaXRlICJTZXQgZmlsZXN5cyA9IENyZWF0ZU9i amVjdCgiIlNjcmlwdGluZy5GaWxlU3lzdGVtT2JqZWN0IiIpIiAmIHZiY3JsZg0KVFNPLndy aXRlICJTZXQgZmlsZXR4dCA9IGZpbGVzeXMuQ3JlYXRlVGV4dEZpbGUodGV4dGZpbGUsIFRy dWUpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJnZXRuYW1lID0gZmlsZXN5cy5HZXRGaWxlTmFt ZShwYXRoKSIgJiB2YmNybGYNClRTTy53cml0ZSAiZGltIGEiICYgdmJjcmxmDQpUU08ud3Jp dGUgImE9QXJyYXkoNzcsOTAsMCwwLDEsMCwwLDAsMiwwLDAsMCwyNTUsMjU1LDAsMCw2NCww LDAsMCwwLDAsMCwwLDY0LDAsMCwwLDAsMCwwLDAsMTgwLDc2LDIwNSwzMywwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxNDQsMCwwLDAsMTY5LDM4 LDIyMSwxOSwyMzcsNzEsMTc5LDY0LDIzNyw3MSwxNzksNjQsMjM3LDcxLDE3OSw2NCwyMzcs NzEsMTc5LDY0LDIzOCw3MSwxNzksNjQsOTksODgsMTYwLDY0LDEwOSw3MSwxNzksNjQsMTcs MTAzLDE2MSw2NCwyMzYsNzEsMTc5LDY0LDQyLDY1LDE4MSw2NCwyMzYsNzEsMTc5LDY0LDgy LDEwNSw5OSwxMDQsMjM3LDcxLDE3OSw2NCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCw4MCw2OSwwLDAsNzYsMSwzLDAsMjA0LDE1LDE0NCw2NCww LDAsMCwwLDAsMCwwLDAsMjI0LDAsMTUsMSwxMSwxLDUsMTIsMCw4MCwwLDAsMCwxNiwwLDAs MCwxNDQsMCwwLDI0MCwyMjYsMCwwLDAsMTYwLDAsMCwwLDI0MCwwLDAsMCwwLDY0LDAsMCwx NiwwLDAsMCwyLDAsMCw0LDAsMCwwLDAsMCwwLDAsNCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAs MCwxNiwwLDAsMCwwLDAsMCwyLDAsMCwwLDAsMCwxNiwwLDAsMTYsMCwwLDAsMCwxNiwwLDAs MTYsMCwwLDAsMCwwLDAsMTYsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDE2NCwyNDMsMCwwLDc2 LDIsMCwwLDAsMjQwLDAsMCwxNjQsMywwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDg1LDgwLDg4LDQ4LDAsMCwwLDAsMCwxNDQsMCwwLDAsMTYs MCwwLDAsMCwwLDAsMCwyLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxMjgsMCwwLDIy NCw4NSw4MCw4OCw0OSwwLDAsMCwwLDAsODAsMCwwLDAsMTYwLDAsMCwwLDcwLDAsMCwwLDIs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDY0LDAsMCwyMjQsNDYsMTE0LDExNSwxMTQs OTksMCwwLDAsMCwxNiwwLDAsMCwyNDAsMCwwLDAsNiwwLDAsMCw3MiwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsNjQsMCwwLDE5Miw0OSw0Niw1MCw1MiwwLDg1LDgwLDg4LDMzLDEy LDksMiw4LDE5MSwzOSw2MSw5NSwyMTgsMjA4LDExMSwxNTgsMTk5LDE5OSwwLDAsMjAxLDY2 LDAsMCwwLDE0NiwwLDAsMzgsMCwwLDIwNCwyNTUsMjU1LDI1NSwxNTUsMjUwLDIwMSw1OCwx MTMsNDIsNDMsMjQsMTQ0LDI0MywxNjMsNDMsMTYsMTM3LDI1MiwxMjMsOCwyMTgsMTIxLDY2 LDIzLDI0LDE0LDExNSwyMzgsMTI3LDk0LDgyLDE5MSwyNTMsMjU1LDI1NSwxODYsMjUwLDQs NTgsMTQzLDI0LDU3LDE3NSwxMTMsMjIsMTcyLDExMywxOTEsMjQyLDExMywxNDMsMjQ2LDEx MywxODMsMjM0LDI1LDIyNiw0NSw1OSwxNiwyNDIsMjAwLDI1MiwyMjAsMjU1LDE3NywyMjEs MjIzLDUsNTksMTEzLDI1NCwzOCwyMDEsNTYsMTg4LDI0LDE4LDE2NCw1MSw1NiwyNDYsMjUw LDQzLDEwNywyMzcsMTgzLDIzOSw0MiwxMyw0Miw1LDE0MywyMzQsMiwyNDYsMTcwLDE4LDU4 LDUsMCwxMywyNSwxMjcsMjUxLDI0Niw3LDEyMSw2MiwxNCwxNDYsMjUwLDIxOCw1MywxNDQs MjUwLDE4LDk3LDUyLDI1MCwxMTUsMTkxLDYsNjEsMTkxLDI1NSwxOTAsMTk3LDE5MCwxNCwx MzAsMTQ0LDEsNDgsMjQyLDE4LDQ1LDE4NiwxMywxMTksMTkxLDIsMTcwLDI1NSwxNTUsMTc1 LDEyMyw0MSwxOCw2LDIxLDgzLDEyMSwxMzUsMiwyNTAsMTQzLDI0OCwxNywyMzMsNSwxNDMs MTE5LDExMSwyMzgsMTQ1LDIsMTQsMTgsMTA2LDkxLDY3LDE0LDE3LDUzLDE1LDE4LDE3MCwx ODYsMjE5LDU0LDExNSw5Niw3MCwxMDYsMTM1LDE0LDExOSwyNTQsMTA2LDE4MywyNDYsMjIw LDEwMiwyMjYsODksOTAsMTY1LDIwMCwyMzYsNzEsMjQyLDI0OCwxODMsMjE3LDIyMiwyMjMs MTM3LDI1NCwyNSwxNDQsMjU0LDE0NiwyMiwxNjQsMTg5LDUsMjU1LDExLDE4OSwyMzcsMTkz LDE4MiwxNzAsMjAzLDcsMjAxLDQwLDEzLDcxLDEwNCwzOCwyMzgsMjQ2LDE3MywyMjAsNTMs MTczLDYsMTEzLDI1MiwyNDYsNTksMTksMjQ4LDY0LDksODEsOSwyMzksNjIsMTc4LDI1Mywx MjEsMjcsMjQ5LDksODAsMTY1LDMwLDI0MiwxNjksMTEzLDE2NywyNDYsMzMsMTQ0LDIyNCwx OCw5OSwyNDIsMTQ4LDI1MywxMTksNzMsMTIxLDU4LDE1NSw2LDgwLDE3NywxNDMsMTEsMTYx LDMxLDI0MCwxOCwxMzEsMTIzLDIzMSwyMiw1MCwyMDIsMTc3LDE4NCwyNTEsMTgsNzQsMTk3 LDE2OSwyMDIsMTczLDExNywxMjcsMjQxLDU4LDE0MiwyNDQsMTcwLDE0NCwxNDgsMzcsMTIs MTg3LDQwLDE5NiwxMjcsMjIsMTg2LDE5MywxMzEsMTcyLDY5LDE0MywxMzIsMTM1LDIwMSwz MywyNSwxNzQsMTk1LDE1MSwyMzcsMjU1LDg2LDU5LDI2LDIzNCwxMjEsMywyNTEsMTQyLDI0 MSw4NiwxNTYsOSwyNDIsMjQ4LDE0MiwyNTEsODYsMTU0LDcsMTIxLDEyMywxMjAsMTgsMjMy LDE4LDE5OSwxNTIsNTYsOSwyNDYsMTgsMjAxLDI1MiwxOCwxMTEsMjM3LDIyMSwxNDUsMjEx LDE4LDIxNiw2LDE4NSwxMjEsMSwyMzIsNzIsNjYsMTU2LDY2LDI0Nyw4LDE3MywyNTMsMjU1 LDI0MCwxNTYsODEsMTIxLDE5LDI0OSwxMzEsNzIsMTMsMzUsMjA5LDMsNzQsMTk5LDIwOCwx NDUsMTk2LDI1NSwyNTUsMjU1LDI1NSwxMjEsMjYsMTk3LDE5OCwxOTYsMTM3LDIzMiwxOTgs MjA2LDEzNywyNDAsMjU0LDE4NywxOTgsMTYxLDEzNiwyNDUsMjU0LDI1MiwxNywyNDEsMjU0 LDYsMTcsMjUzLDIxNCwxOTYsNTgsMjYsMjQ4LDI1NCwyMzUsMzAsMjE4LDE5NSwyMDksODAs NzMsMTY5LDE0NCwxMDUsMzYsMTYxLDEyNywxNzksMTI1LDY3LDEzNSwxMjMsMjAxLDExMywz NCwyMjQsMzQsNiw5Nyw1MSw1LDgsODQsMTIyLDIyMywyNDYsMTIzLDE4NywxOTAsMTQyLDIy NywxNzgsMTgsMTE2LDE5NiwyMTEsMTQzLDI1Myw4OSwxNjEsMjM3LDExNSwxNTcsNDksMTE1 LDI1NSwyNTIsMTIxLDYwLDI1NCwxNywzMiw2NiwyNTEsMTM2LDE4LDI0LDYsMTE4LDEzMywx NTksMjE5LDIyMiwxNDYsMjQ4LDIxLDgzLDExMiw0LDM2LDc3LDE4OSwxODksNDYsMjQ2LDEx OSwyMywxMzIsNjcsMjUwLDE5LDExNCwyMzgsMTkyLDQsNTYsMjQsMywxOCw5OCwyMTQsMjQ4 LDEwOSwyMjcsNjAsMTkxLDQsMTEzLDUxLDE5MiwxMTIsMjU0LDE5MywxMTQsMTkxLDEzMywx MywxNzgsMjM3LDIzOCwxODIsOCwyMDMsNSwyNDUsNzYsMTc1LDksMTkyLDExNCwyMSwxMTIs MjM2LDIxOSwxMzMsMTgzLDUsMTkyLDE4NywxOTMsNDAsMTM2LDI0OCw0MCw0LDU3LDE0Myw0 NywyMTYsMTgzLDIzLDIyMCwyMTcsMTA2LDIsMTg1LDE0MywyNDIsMTEyLDI0OSw2MCw3LDEx MiwxMDgsMTk2LDIyLDIxOCwxODUsMjUxLDUsMjIwLDEsODcsMTQwLDIsMjU0LDE4MSwyNDYs MjI3LDIyOCwxODYsNCwyNyw3OSwzLDIzOCwxOTQsMTE0LDE3NSwxMDksMjM5LDIxOSwyMjEs OTksMTc1LDYsMTMsNiwxMTIsMTIsNCwyMywxNDUsMTk0LDE1NSwyMzUsOTIsMTM5LDE2LDI2 LDksNSwyNDgsMTIyLDE2NCwxMTMsMjIxLDE4NiwxODMsMTExLDY0LDIwMiwyMzgsMjAyLDUs NSwyNCw1OCwxMTIsMzUsMjQ5LDQsNiwxMTQsMjIzLDYyLDczLDE3NSw5NiwyMzAsMjUsMTEz LDE4NiwxOTgsMjQ5LDUsMjQ1LDc3LDE4NiwyNTIsMTMzLDIyMSw0NSw4LDIxNCwyMjYsNjYs MjEwLDExNiwxMywxNTksMjE4LDE0MCwyNDcsMjE0LDE1MCwxNzUsMTY4LDI5LDUsMjQ5LDU2 LDI1NSwxMzYsMjgsMTUwLDE3MywxMjQsMTUyLDI0NiwxOSw0Myw1LDYwLDIzOCwyNDYsMjMs MTA4LDIyOCwxOTQsMjMsNjcsMjM0LDIwLDIyMSwxNiwxNjMsMTA3LDE5MCwyMSwxMTcsMTc4 LDgsMTcwLDE0NCwxMTYsMjUxLDIxOCwyMTAsMTU1LDE4MywxNzksOTEsNSwxOTQsMTEzLDEx MywxODUsMTA3LDIyMywyNTQsMTkxLDE2MSwxMSwyMDksNDgsMTEzLDE2OSwyNDIsMjQ5LDQz LDI0OSwxNjksMjQ2LDExNSwyMjEsNSwxMzcsMjM0LDExNywxODIsMjMsMjQyLDE1NywxOTAs MTE4LDIzOCwyNTEsNSw2MywxODEsMTcsNjIsMTYwLDk5LDIzNywxMTksNTksMTQ0LDIxMCw5 LDE1LDYsMTgsMjQ2LDExNyw1OSw1LDIzNCwyMywyMDIsMTc4LDQ0LDIsMjM4LDYsNTcsMTg1 LDIyMiwyNTMsMjAyLDIwMSwxNTAsMjE4LDI2LDIyMywxNTYsNSwyNSwxODYsMTcwLDc3LDE4 MiwyMTcsMjIzLDIxMiwyNTEsMTcwLDE3MCw2MSwxMjIsNDIsMjUwLDAsOSw0NiwxMDgsMTQz LDEwOSw1MiwyMDcsMjM0LDMzLDI0MiwzNywyMTAsMTcsMjQ5LDU4LDYsMjI4LDE5OCwxNjcs MzMsMzcsMTMsMjUxLDE0NCwyNTEsMTA0LDE5OSwyMDUsMjM4LDE4MiwxNTAsNjksODgsMjMy LDIzLDUsMTY4LDI0MiwxNyw0MSwyNDYsMjU0LDI1MywyMzIsMTE5LDE3NSwyLDEzNywyNDgs NjEsMTg0LDI1NCw3OSwzNSwyNTMsNzUsMjQ4LDk0LDIyMSwxNTMsNiwzNiw0NiwyMzgsMjQ1 LDIxNSwxNzgsMTc3LDIxOSwxNzIsMTE5LDE5LDYxLDI1MiwxMzEsMTg4LDQ4LDEwNSw5MCwx NzYsMTUsMjM2LDE0NCwyNDgsNDksMTEzLDI1MiwxNjQsOTksMjMsMzksMTM1LDE4NSwxNzks NzYsMTE5LDI0OCwxOCwyNTAsMTI4LDEzOSwxMDgsMTc3LDM3LDEzNyw4OSwyNDgsMTM4LDE1 MSwyMDUsMjA0LDU1LDMzLDUzLDE4Miw5MSwyMjYsMTA1LDQ0LDI0Nyw5Niw1MCwxMjMsNjIs MTMwLDI5LDE3MywyNDksMjQ4LDgsNDQsMTg0LDIzOCwxNDYsNTEsMTIyLDIwMyw5OSwxOTIs MjEsMTkwLDIyMSwzMiwyNDAsMTg2LDE0MiwxOTAsMywxMjIsMjUsMTE5LDEyNyw0NSwxNzAs NzUsNTQsOTYsMTkxLDIyOCw5MSwxOTMsMjMxLDIsMjQsOTAsMTQ2LDI1MSw3MCwxNjAsMjM0 LDMwLDUxLDM2LDEwMCw2OCw5NSwxODMsMTA4LDM5LDM1LDE5LDE4LDE3MywyMzAsMTgsMjI2 LDE1MSw5MCwxNjMsMTI0LDIyNSw0MCwxOTgsMTI0LDE1Niw2MSwxOTEsMCwxMzIsOTcsMjIy LDIzLDE5MCw1MywxMSw1LDE4MywwLDEzLDI3LDIyNCwxNDQsMTg2LDE4LDIyNyw5Myw4MCwx ODIsMTQzLDIyMSwyMDEsMjUzLDIxMCwxOTQsMjIsMTE3LDE4OSwyNTQsNSwxMCwxODgsMTA1 LDE4MiwyMDUsMjA1LDEwNywxNTYsNywyNDYsMCwyNDQsNjEsMTg5LDIzNCwxMDYsMjA3LDIx MiwzNCw2MywzMSwxNTksMTAsNjMsMjcsMjE2LDIxOCwyMTgsMjEwLDIyOSw1MiwyNiwxMDQs MjQ5LDU0LDE1NywyNDIsMjM5LDM5LDIyNSwxOTQsMTE1LDE4OSw2OSw2MSwxNjUsMzEsMjYs MTY5LDE3MywyMDEsNSwyMjIsNjcsNzEsMjExLDEyOSwxNDksMTc2LDExMCwxNjcsMTExLDIz OCwyMjUsMTA0LDcsMjIyLDg4LDEwOCwyMzgsMTQsMjA0LDIwOCwyMCwyNDgsMjM1LDk5LDI0 LDYsMjE0LDIzNCwxOCwyMjksMTk4LDg2LDI0NSwxMjYsMTI3LDExNSwxMzUsOCw0OSwyOSw3 LDE0MiwxMCw5LDIwMywyMDMsMTk1LDE3NSw1OCwyMDAsNTEsMTk1LDQzLDIsMTU5LDE0NCwy NDQsMjQsMTE4LDIyMywxNDksMjcsMTYwLDE3NCwwLDIxNywyNCwxODQsMTgzLDY2LDI0NCwz NiwyNDksMjQ5LDI0Niw5NywxMDcsMjIwLDI5LDIyLDI0OSwxNjEsNSwzMCw3NiwxMCwxNzAs MzgsMTg5LDE5MywyMjAsMTEwLDIwMywxOCw4OCwxMTksMTksMjEwLDEyMiwyMzMsMTU4LDc1 LDIxMCwxOCwxMTcsMTU0LDEzOSwxOSwxMjksMTE0LDMxLDExNiwxNTksNywxODMsMTA1LDE4 OSwxMTIsMjIsOCwyNTEsMTIsMTU5LDIxOSwyMDksMiw1LDE2MiwxNDQsNDYsMjEzLDE0Niw3 LDg2LDMyLDI1LDE1NywyMzgsMTYxLDEwNiwyNiwxMzMsMTAwLDEwNywxNDMsMTk1LDIyLDMz LDE1OCwyMjIsMTIsMTAsMjI1LDgsMTg3LDIxMSw5OCwyNDUsMjIwLDE5MywyMjgsMTQ0LDI0 NiwxNzIsMjA3LDIzMSwxODIsMjQ3LDE5OSwxOTMsMTE5LDEzNSwyNTEsMzAsNzYsMjQ5LDM0 LDEzNCwyMzAsMTIzLDE5MCwxNzAsMjYsMjEyLDI1MSw5LDIwOCwxNDYsNTksMTk1LDE5MSwx MTAsNiwyMjIsMTYsMSwxNzMsMjQ4LDE4LDIxNCwzLDI1NCw4LDE5MSwxMTEsNTgsNywyMjIs MTYwLDE0NiwyMzEsMTEyLDE4NiwzMiwyNTQsMTQ0LDQxLDE4MiwyMTYsMTg3LDQ5LDE2OCw2 Miw3MCwyNDgsOTMsMSwxNzUsNzgsMjAyLDE1OSwxNzUsMjI4LDUyLDEzOCw2Miw0NiwyNTIs MTgsMjMsMiwxODUsMjUxLDIzNyw3LDE1NCw2NiwxNzAsNTQsMTUsMTcsMjA3LDEyMSwyLDI1 MSwxMSwyNTAsNTQsMTcwLDE3OSw1MiwxODcsMTAxLDIxMSwyNDgsMjMsNTQsMTcwLDIzMSwy NDksMTA5LDU0LDIwMywxMTQsMjM0LDIzNCw1LDIzNSwyNTQsNSwyMTgsMjU1LDY2LDIxMywy MTgsMTAzLDIzNiwyMTMsNzksMTA2LDIyMywxMTksMjQ0LDE0MCwxMTIsMjI0LDEzNCwyMzks NTMsMTgsMTQ5LDM2LDE4LDE4MCwxOTIsNzcsNTAsMTUsMTM1LDE3NiwyMzksNTcsMjcsMTY5 LDE4NCwxODQsMTA3LDIyNiwxOSwyMzksODIsMjU1LDE4LDE1MSwyLDExLDI0NSwxNzAsMjIs MTUyLDEwLDE5MywxNzMsMTgxLDI1MywxLDI0MCwxNDAsMjU1LDE1LDEzNywxMiw0LDIwNSwx NzAsNiwyMjksOTMsMjQzLDcsODQsMTcxLDksMjQ2LDE4LDc4LDcsNDQsODksNTIsMTIsOTIs MTAsMTkzLDgxLDc0LDE4MiwyMTEsMTk1LDE0MSwxODIsMTcwLDE5NCw3OSwxMCw0NywzLDYs MjQsMjMzLDE0LDIyMyw0NiwyMzksODYsODYsMTg2LDE4MywyNiwyMDcsMTQsMTUwLDIxNyw5 NCw2OCw4MCw1MywyNyw3NCwxMjEsMjM4LDIyNSwyNCwyMDMsNiwxOTEsNzYsNSwyMjksMTUy LDEwLDE4MiwyMjQsMTkwLDIwMCwyMjMsMTM3LDIwMiwxNiwxOCwxMjksMTk0LDEyNSwxMTQs MTAsMjQ0LDI0LDM4LDIyMiwzMCwyMzgsNiwxMTksMjAxLDExNywyMzIsOSw5NCw2OSw2Mywx MTAsNDcsMjQxLDg4LDE3LDExMCw1NywxODIsNSwyMTYsMTQzLDY1LDIxLDQ0LDIwNSw3LDYs MjMxLDMxLDcsMTAsMTgsNTIsMjA1LDIxMiwxNCwyMTcsMjAzLDcwLDEzMSwxNjksMTY0LDE1 NCwxNCwyMjAsMSw1LDE3NCw3NywxMzYsNjksNTYsOTEsMjA1LDI1NCwxMjIsNDcsMTEsMjQ3 LDE0MSwxNDEsMTIwLDg0LDY5LDI0Miw4MCwzMiw0NSw2LDExNywxMDIsMTE1LDE3NSwyMDIs MjA5LDE1LDE4MCw3OCwxMzcsMjI5LDE1OCwxMDgsMTQzLDMyLDI5LDE3NiwyMCw2NiwyNTEs MTg1LDE4NiwyMTUsMjQwLDE5OCwxMyw3MCwyNDMsMTE5LDE3OSw3MCw2Nyw2MSwxNDksMTQs NTksMTUyLDEyLDExOSwxMzgsMzgsMTMxLDExMywxOSwxNjYsMjI1LDU5LDg0LDE0MywxNzYs MTM0LDY1LDIxNywxMDgsMTEsMTgzLDIxOSw0NywxNDYsOTQsNTUsMTQ2LDE4NCw5LDMzLDIs MTE3LDgxLDQ2LDkxLDk5LDE1Miw0MSwxNzgsMjIsMjUyLDEzLDQ3LDgsNzksMjA3LDE5OCwy MzgsMjMsMjIsOTEsNDcsMjcsMjM4LDE3NywyOSwxMTMsNzIsMTIsNDQsMjUzLDY5LDIxNSw1 OCwxMCw2OSwxODgsMTc3LDE5MSwxODUsMjA1LDYsMzIsMzgsMTcwLDE3MywxOCwxNjEsNCwy NSwyMzIsMTMsMjA0LDgsMTU5LDYxLDE4NSw5LDE1LDI0OCwxMTMsMzcsMTI3LDgyLDExMSw3 OCwxOTgsMjE5LDE1MSwxNjUsMTUyLDE2LDIwMywyMDUsNTAsNjQsNjIsNDEsNzQsMjUyLDEy NywyNDAsMjQsMTEsMjUsMjM5LDY3LDMyLDU5LDI0LDI1NSw1OSwxNywyMjUsMjQxLDQxLDk5 LDE5LDQ1LDE4MiwxMzMsMTg4LDI0OSwyMiwyMCwxODUsNjYsMTc2LDY5LDE2MSw3MywyNTQs MTMyLDEzMCwxNzAsMTEwLDE4MiwyNDUsMjE2LDcxLDE2MywyMDQsOTIsMTA3LDI1MSw3NCwy NSwyNDUsMTgyLDE3OCwxMzEsMjM0LDIxNywxODMsMjQ2LDYxLDI0OCw2OSwxODYsMTczLDgw LDE4NCwxLDU2LDEyMSwxOTQsMTkxLDQ0LDI0Miw0NiwyMDgsMTg1LDE4MiwxNTcsMTEwLDE2 MCwxMTUsMjQ4LDEzMywxNzYsMjE1LDI4LDE0NywyMDksOTgsMjMsMTExLDE2NCw0MiwxMTMs MjQyLDM2LDE0MywyNTIsMTc5LDE5OSwxMTAsMjA5LDIyNCwxNjAsMTg3LDE1MywxOCwxNjgs NDUsNiwyMDcsMTExLDEzOSwyMSw1NiwyMDUsNDYsMjksMTg2LDMwLDE2MSwxMjMsNTUsMiwx ODQsNDYsMjA2LDE3Myw2MSwxMjcsMzQsNiwyMTAsMjcsMTkwLDkzLDEyOSwxNDcsMTA3LDkz LDQ0LDExNSwxMjcsMjUsMTE5LDExOSwyMzgsMTgzLDE5NywyNCwyNDcsNzksMTIsMTgsMjks MjMsMTAyLDE4NCw2OSwxODksMjcsMjUxLDIxNywxODIsMTM4LDI0NCwxNzMsMjcsNiwxOCw0 MSwyMDQsMjEsMjQxLDM2LDcsMTMyLDIxOCwxMDMsMjYsNywxNSw0LDUxLDE0Myw0NSwyOSwx MDgsMTE1LDk3LDY3LDgzLDE3LDY0LDEyLDYyLDIwNiwxNjUsNjcsNSw3OCwxNzMsODgsMTI2 LDYxLDI0MCwyMDYsMjAyLDE0Miw1LDgzLDE4LDI0OSwzNSwyMSwxOTUsMTE3LDE0MCwxOTUs MzIsMTEyLDYsMTcxLDIyMyw3NywyMjUsMTA1LDEyMiwxMTAsMTM5LDE5LDM1LDg3LDU4LDU1 LDYxLDI2LDE4MiwyMDAsNjcsMjM0LDMzLDEzNiwyMzIsMjA3LDE0LDI1MywxNTEsMTMzLDcw LDcwLDI0OSwyLDExOCwyNTIsNjgsMzUsMTIsMjYsMTMsMTIsMjEzLDE2LDI0NCwxNjksMTQw LDI0NCwyMjUsMTU2LDI0OSwxNDYsMTc5LDE3NywyMDYsODksMTg2LDMzLDk5LDEzNSwxMCwx NjEsMTgwLDMyLDI0OCwxNTYsMjA1LDIxNiwxOTUsNTgsMjQ3LDIwOCwzMiwxMCwyNywyNTAs MjI0LDQyLDE0MSwxMjUsMTQ4LDE0NCwxOSwyNiwyMjIsMTYzLDIzNCwxMTEsMjksMzUsMTM2 LDE3NiwxMDAsMTEzLDcsMTg4LDEyMywxOTYsMTgyLDE3MywxOTEsMjQ4LDExMSwyMTIsOTMs MTcsMTMsMjU1LDQyLDIzNCwzNCwxMTMsNTIsMjA5LDE4MywyLDEyMyw1OSwyNTAsMTc3LDU5 LDExLDI1LDE5OCwyMCwyLDUsMTIwLDk0LDkwLDQzLDIwLDEyMyw1Miw1LDMzLDE2MSw0Miw2 NiwxOTMsMTg1LDM4LDEwNiw2MSw0Niw1LDE4MywxNTcsMjE0LDI1LDE4MywxODcsODksMTc4 LDI0MiwxMjMsMiwyNTAsMjAyLDE3NiwzMCwyNTMsMjI3LDI0NywyMDEsMTg5LDE5NSwxMDEs MTU1LDc0LDIwNiwxMCwyNiwxMTcsMTk5LDE5MSw3MSwxMjksODksMjcsMzcsMjEwLDI1LDEw OCwyMDYsMTg3LDczLDExNSw4NiwxMTIsMTgsMjU0LDE2OSwxOTQsMjA2LDIxOSwxMDIsMjAz LDIzLDE2MCwxOCwyMzYsNDcsMTksMTgsMjUsMzksMTU5LDU0LDIyMSw0NywxNTYsMTcsNTIs MjQ3LDIwNCwyMDEsMjEyLDIxNSwyMzgsNjEsMTE3LDcsMTg1LDEyMyw1NSwxNiwyMTMsNjMs MjAxLDgsMTg2LDE2NiwzMSw3Miw1NywyNiwxNDYsMzUsMTA2LDk4LDE3OCw1OSwxMDQsMTQw LDYxLDE5NiwyMDYsODAsMTY4LDE3LDQwLDIzOSwxNTQsMjM0LDgsNDQsMTMxLDE4OSwyNiwx NywxNjQsMTU2LDI1MSwxNywwLDEyNiwxODYsMTI5LDIzOSw3NSwyMDEsMTM0LDI2LDE1MSw2 NCw1NCwxMDQsMTA0LDY0LDYxLDEwNCwxNjksOTMsMjE4LDMwLDIwOCwxMTIsMzEsMTU2LDI3 LDU4LDE1Niw3MCwxNzEsNDUsNTksMjQ2LDI3LDEyLDM4LDYyLDI0NiwxMSwzMCwyMDEsOTks MjM4LDExOSwxOTEsMjM5LDE2LDk4LDcyLDE1MiwxODMsMjYsNzMsMjUwLDE0MSwxMDIsMTQ2 LDUwLDEwNywxMzgsMzUsMjIzLDExLDIwMCw3MSwyMDEsMTcsMzksMTEyLDIzNCwzLDUwLDIz MCwxMTgsMTQxLDE0Niw0MiwxMDMsOTEsOTYsMTE0LDIyOCwyMTksMTIsMzIsMTcyLDE0Niw0 NSw4MiwxNDQsNzIsMTUzLDY1LDE0LDQ1LDIwNSwxMjEsNTYsMTI4LDIwOSw4LDExOSw3NSw1 LDIwMyw5OSw4MywxOTgsMTc4LDI0NSw3MSwyNCwyOCwyLDEzOSwyNDEsMjUsNDQsMjIxLDI1 MCwyMjAsMjAwLDI1MCw1OSwxMSwyMzgsMjI4LDEzMSwyMzMsOTAsMjAsMTIwLDg2LDIwMyw5 NCw3LDE3OCwyNDksMTc2LDE3MiwxODUsMjQ1LDExOSw0NiwxMDQsNDIsMjAwLDg3LDIwMCwx NDcsMyw0NiwxMDQsMTAzLDIwMCwxOTUsMCw1NywxMTQsMTQ2LDIwMCw2Miw5OCw2OSw5OCwy NDIsNzQsOTQsMTE0LDEzMiwyMDAsMTUwLDIwMCwxOTIsMjAwLDIyMiw2NCwxODYsNywyNDEs MTA4LDEzOCwxOTEsMTcsMjgsMjI4LDM2LDMxLDExOSwyMzIsMjAwLDUwLDk4LDIxNiwyMDAs MjE3LDE4OCwxNDYsMTUxLDIzNCwyMDAsMzYsMjAzLDIxMywxMDgsMjAxLDE0NywzLDE3OCw4 LDIwMywyMTMsMTA4LDY5LDIwMywzMyw3LDE0Niw4NywxMjUsMjAyLDE0NCwyMDIsMjI4LDIw MSw0MywxMjEsODQsMjAyLDIwNiwyMDIsMjE0LDIwMiwxMjAsMSwyOCwzNywxNjEsMjgsMjQ2 LDIwMCw1NiwxOTMsMTEwLDE5Myw0NCwyOSw0NiwyMDEsNTYsMjcsMjE1LDExNywxMTEsMTEs NjUsMjQyLDY5LDIwNyw1OCw4NiwxODMsNDAsNjgsODksOSwxMTksMjI4LDI1NCwxMzAsNzMs MjQ5LDI1NSw2MiwxMCw4MCwyNTUsMTI2LDI0MiwyMzMsNTQsMTIyLDE1MSwyNDIsMTg2LDg5 LDE0LDgwLDIyNiw0NSw1MCwyMzksNDgsMTIwLDIzMSw5NCw5LDgsMjQ3LDEyLDI0NCw1LDI2 LDIxOCwxMjMsMjcsMjEsMzksNTEsMjQwLDU5LDEyMSwxMSwyNTEsNywxMjAsMTczLDExNywx MjQsMjcsNTAsOTYsMTAwLDIsMTI3LDcsOSwyMTgsMTYyLDIwMCw5LDYyLDYxLDI1NSwxMDcs MTMwLDE3MiwyMDYsMjM4LDQzLDExMSwxODIsMjMyLDksNjIsMTE1LDE1NywxOTEsMjE3LDY4 LDEwNiwyMCw5OCwxNzksMTg5LDQsOTAsODYsMTcsMjUzLDUzLDE2Myw4NiwyNDAsMTkyLDIx MiwxNzYsOTAsODYsMTUsNCw2MSw2Myw4LDE4NSw0OSwyMzIsNjYsMjUsMjAyLDExOSwxMzUs MTIsMTcsMjM3LDEwNywyMzcsMSw2NywxNDQsMTIzLDIxLDYsMTE0LDU2LDIxMywyMywyMTgs MTY2LDE0Nyw4MCw1LDMxLDIzNiwxMCwyNDAsMTM2LDI1LDE3OSwxMjUsMjAxLDE4MywxMDcs MTIsNTEsMTI2LDE3LDIxOSw4NiwzNiwxOTAsOTcsMTQ2LDE0Myw3MCwxMTQsNjcsMTEwLDIy LDIzNCwyNTUsMjI1LDE5Myw5NywxMDEsMjAyLDU4LDM1LDIyNSwyNDEsMTg1LDk0LDMyLDkx LDQzLDIyNiwyOCwyMTMsOTIsMTUyLDksMjI4LDI0MiwzNCwyMjYsMTUsNCw1NywyMzksMjE0 LDIsNiwyMzksODcsOSwxNDMsMjU0LDE1LDEwNywyMzAsMTEsODYsMTkwLDM2LDE0OCw1MCwx Niw1MCwyNDIsNTMsMjIzLDEzLDE1NCwxNzAsNzEsMiw1LDk2LDE5OCw5NCw1MSwyMDEsMTYy LDMzLDEzLDE5OSwzNSwyNywyMTcsNzQsODgsMTE3LDEzMyw1LDQ1LDc4LDc3LDI0NiwxOTks MTgzLDIxMywxOTYsMjQ2LDE0Myw4MCwxMjAsMTAsNzgsMjU0LDE0MSwxNzcsMTMzLDgxLDIx MiwxNzYsMTU2LDIxLDEwLDE1NiwxMjMsMTYsNzAsMjUzLDE1NiwyMzcsMTExLDE4MywzNywx NTgsMjQzLDEyLDE4Myw4LDcsMjcsMjU1LDE1NiwyNDEsMTgzLDEyLDMsMjEwLDExNiwyMDUs MjQ2LDQzLDE1NiwxMTUsMjM0LDMzLDI0MiwyLDI4LDI0MSwwLDE2Miw0OCw3MywxMTEsMjQs MjAzLDEwNiwxMzQsMzAsNiwxMTAsMTgsMjIzLDc0LDg0LDE5MywxNzAsMjEyLDE5MiwyMTIs NjYsMTIzLDk0LDY1LDQ5LDIwMiwxMTAsMTI4LDIwMywyNDYsMTAyLDE1NCw1LDEwNiwxNDQs MjI4LDEyNCw0NCwxODYsMjAsMTEsMTUyLDEwMSw5MSwxMDMsMjEyLDEwLDgyLDIwNywyMTAs MjM4LDk5LDIyMywyMzgsNDcsMjQwLDE1NiwxMjEsMTgzLDM4LDI1MSw0LDc0LDI1MSwxODMs NzMsNjIsOTgsMTE4LDE3MywxNzEsMTg3LDYxLDQ2LDE3NywyNDksMjU0LDY0LDM2LDExMiw1 LDg0LDI0MCwyMTksMTcxLDIzNyw4NiwzMCw4NCwxNTYsNzUsMzIsNTQsMywyNiwxODYsMTY2 LDUxLDExLDE0NiwyMjAsMjAsMjYsNzgsNywyNCwxODIsMTI1LDI0NSwxMDcsNzYsMTQxLDIx OSwyMywyMTUsMzAsMiw2NiwxMjQsMTcxLDIzNywxMjMsNTQsNDAsMTYzLDEzNCwyMTUsODgs MTgsMiw3MCwxMzYsMTE3LDM4LDQ2LDE1NSwxNjAsNTgsOTgsMTU2LDE3LDMsNjIsMTc5LDks MjE5LDIxNCwxMCwyNTEsMTY5LDEyMSwyLDIyOCw2OSwxNzMsMjEzLDU0LDExNSw3OSwxMTgs MjUzLDE0MSwxOSwxMyw5OCwxNywyNiwxMTUsMTMxLDE5LDksNzIsMTg1LDIwOSwxOTQsMTA5 LDUxLDc1LDExNywxMDAsMjM4LDQ4LDcsOTIsMjQ2LDMsMTc3LDExMSw4MiwxNTUsNzAsMTQs MjQ2LDI0Miw0NSwxMTEsMTE4LDEyMiwyMzQsMTQsMywyMzAsMTE2LDE4LDI0MCwyMyw5OCwy MzgsMTIyLDIyMyw4NiwxOTgsMzAsNiwzMSw5NCwxNTMsMTYwLDgwLDE4MiwxNDAsNzUsMTUy LDQsMTU1LDEyNiwyNTAsNSw1OCwxODUsMzAsMTk0LDIwMCwxNjAsOTAsMjE3LDE0Niw1NCwx NDAsODgsODcsMiwyNDMsMjMsMTM2LDE2MCwxODUsMTA4LDI3LDE3OCwxNTUsMjM5LDU0LDI0 OCw1LDEwOCwxNzAsMjYsMTczLDE1NiwxMywxNzUsMjMsMTgyLDExNSwyMTksMTU1LDE5Nyw5 OCwxNTEsMjU1LDE1OSwzLDE4LDI1NSwyMTEsMTMsMTQ3LDIzOCwyOSw2LDEzMCw4MiwyMjks NSwxOSwyMzgsMTc5LDc3LDEzMCwxNjgsMTEsMjUsMTA2LDQ3LDIxNCwxNDYsMjA3LDExOSwx NCw5LDIxLDExLDIxNCwzNCw5MCw3MiwxOTQsNjUsMTgyLDM3LDE2NCw1NSw1NSwyMTQsMzcs MjIwLDE4NSwxMTEsMTIsMjMyLDcxLDE4LDEyMSwxNiwyNDYsMTksMjM5LDEwMiwxOCwyLDEz MCwxODcsMTMyLDIyLDE4MywyOSwxNDEsMzcsMjM0LDksNzEsMTU0LDIwMyw4MiwyNTEsMjQ4 LDcyLDg2LDIzOCwyNDAsMTU5LDc1LDQ1LDE5MCw1LDU0LDIwNSwyMjgsNTIsMjE4LDE0Myw4 MiwyMDcsMTg3LDI0Myw4MiwyNDYsMjMwLDY3LDIxMiwxNzgsOTQsMTgsMjAsMjA5LDIyNiw0 LDE2MSwxNDUsMTQsMjI2LDk0LDIyNiwxMDgsNTUsNzIsNTMsMzgsOTEsMTAxLDk1LDE5MSw5 NywxMzIsMjU1LDIwOSwxNSw4NywxNjEsMjE0LDE1OSwyMzgsMjUxLDI1MSwxMjEsMjUxLDIx MiwxMjcsMjAxLDcwLDIzMCwxODcsMjM0LDM0LDIxNiw4MSwyMzQsMjA4LDExLDQsMjIwLDE0 MiwyNTQsMTU5LDI5LDIwOCwxNDMsMTMyLDc4LDI0Myw5OSw2LDI0OSwxMzIsMjQ2LDE4LDIy MSw3NCw1NCwyMDcsNjAsMjA4LDIsMjQsMjUwLDEzMSw5NSwxNzgsMjQxLDUyLDk5LDMyLDE0 LDU5LDIzNiwxOTcsNDAsMTk3LDgyLDIyOCwyMzUsMjE0LDE3LDIwMCwxOCw1NCwxNzAsMzEs MTEyLDEwMiwyMjcsMjUwLDg0LDIzMCwyMTcsMjEzLDExNiw2LDEyMCwyMDMsMjIwLDcxLDIw MCwxNDAsMTUwLDI3LDI0NSwxNjksMTkyLDM1LDMwLDIzMywxMzYsNCw5MSwxNywxNzQsMTM1 LDIyMiw4OSwyNiwyMzgsNjUsMTIsMTEsMjAsOTYsMTkwLDk2LDEwMywxOCwyMjYsNTksMjEs MzMsMjM3LDE3OSwyMzMsMTc4LDEwOSw0MCwyNTUsMjUyLDgyLDMyLDI0OCwzMiwxNTYsNjEs NTQsMTA3LDEwNywyMDMsMzgsMTEzLDIwOSw2NywxNTQsMzYsMTg3LDE1Myw4NiwxMjQsMTM0 LDExMSw0OSwyNTMsMTAwLDEwNCwzNSwxNzYsNDgsMTIwLDI0MiwxNzEsMjA3LDQzLDIxMSw1 MSwyMTEsOTgsMTg0LDEyMiwxOTIsMjMyLDIyNiwyMjcsMTQ2LDI0OCw5OSwxOTAsOTMsNywx MTksNTUsMjgsMTIyLDE4LDkyLDU2LDE0NiwyMDMsODcsNDEsMjQsMjQ0LDE3MCw2Myw4Myw2 Myw5OCwxMCwyMTcsMTQ2LDIxMiwxMjQsNzMsMTA5LDIwOSwyNywzNywxNjksMTAzLDgxLDE0 MSwyMDksOSwyNDUsMjE4LDUxLDEwMCwyMzAsMTc2LDEzOCw2MywxNTAsODIsMTY5LDk5LDI5 LDIyOCwxNzYsNjIsMTY4LDE5NCwyMDksMTE2LDE0NywyNDEsNTksMTYyLDE4OSwyMTEsNjks MTQ0LDIzOSw1NywyNDUsNzcsMTc4LDI1MiwxNzksMjAsMzEsNjEsNzIsMjAwLDI3LDExMyw0 MSwxNzcsNDEsMTA4LDEyNyw2LDE1NiwxOTcsNTcsOSwxNzMsMTQ2LDY2LDI0MSwyNTAsNTUs NywzMywxNTksMTEsMTkzLDIzNCw1OCw2LDIxMCwzOCwxOTMsMjMzLDE2MywyMjMsMjAxLDE1 LDIwMywxMzksMjEyLDg4LDI1MywxMTUsMzAsMjEwLDUwLDIxMiwyMTEsMjEwLDE5OSwxMTAs ODAsMTY5LDIyOSwxODUsMzIsMTQwLDIxMSwyMSwyMzMsMTEzLDIyMSw4MiwyNTUsMTk5LDM0 LDE4LDY3LDExMywxMzAsMjM4LDI0OSwxMzAsMjM0LDE2OSwyMzMsMjExLDEwMiw5NiwxMjIs MzksMTkxLDE0NywyMTAsMTczLDE4NiwxMjEsMjExLDE0OSwxMjMsMjE3LDExNywyMTEsNzcs OSwxMywxNTEsMTQ2LDM4LDI1NSwzNiwzMSwxOCw3LDE1OCw4NSwyMzQsMjU1LDIzMyw1MSw0 NCwxOCwyMjMsMTI1LDMxLDI0NiwxNDYsMTMsMTMsMTcwLDQ3LDE4MSwxNDMsMzgsMTAsMTk4 LDExNSw2NiwyNCwxOTIsOTMsMTk0LDIyMywyLDEzLDExNCwwLDExLDk1LDIyMSwyMTAsMTM1 LDE1NiwxMywzMywxNTgsMTEzLDE0NSwyMTAsMTc3LDIyMiwyNDgsNDksMTcyLDE1NywxNTYs MjU1LDE4MSwyMDAsMjQ2LDE4NCw2NCwyMDcsOTAsMTgyLDE5LDIwNywxNzAsODMsNDMsMjYs MTk2LDg2LDE4NCw2LDIzOSwxNDcsMTcsNzcsMTE1LDkyLDE2OSwyMjgsMTg0LDIzNCwyMzgs MjIyLDMzLDc2LDMxLDE2OCwyMzcsNDYsOTksMjM5LDE3LDUsMjAwLDE4LDIxLDI3LDIzNCwx OCw4NSw5LDE4OSwxNjksNDcsMTMyLDEyMCwxODIsMjU1LDIyMSwyNDIsMTA0LDIyMSwxNTUs NTAsMTY5LDE1MSwxODQsMTQ5LDI1MSwxNDQsMTU4LDE4LDE0LDI5LDI0MCwxMTcsMTQwLDIx OSwyNTUsMTQyLDk5LDQ1LDk0LDI0MCw0NSwyNTEsMjQ1LDE2MSw5LDU1LDE2NywxNDUsMjAz LDY2LDEyNCw1Miw5NSwyMTAsMTcsMjA4LDI4LDM2LDQ4LDk5LDE2LDEyMCwxOTIsMjYsMjIx LDE5OSwxMDMsMTM5LDIwOSw1MCw5NywyNSwxNDYsMjAyLDk5LDM2LDExNSwzMiw3LDI0Niw1 MCwxOCwxODEsMTIsMTg0LDIwNywyNTIsOSwxNDIsNTcsNyw3NiwxNDUsMTAsMTI5LDIzNyw4 OSwxNDYsOTksMjA3LDUyLDIxNiwxODMsMTU4LDQsMTU0LDM4LDg2LDQ4LDcsNTcsMjM2LDM3 LDE4NCwxMjAsOTksOTYsOTAsMTY5LDEyMywxNTgsMTgyLDcxLDE0LDI3LDI2LDE0LDE3NSwz OCwxNDQsMjUyLDg0LDE0MywxMzksMTQwLDI4LDIzMCwyMTEsMTYxLDE5NiwyMiw3NywyMTcs OCwxNTksMTIxLDIyLDE4LDYyLDcsMTgyLDEyOCwzMCwxNDgsMTQ2LDE0NSw2NSwxODYsMjMs OTAsMjA2LDE4LDE1MCwyMjgsMjE5LDEwMCwxMTQsMTk2LDI2LDE4LDExNSwyMjEsMTIsMTUz LDIyNiwyOCwyMDAsMTM4LDE1MywxNTEsNDUsMjE3LDE1MCwxODgsMTIsMTgsMTgsMjI0LDI1 LDI0Nyw1MiwyMjMsOTQsMTc5LDc1LDI1MCwxNDQsMzUsMTIsMzAsMTgsMjQ1LDIyMCwxNTgs NTgsMjE0LDEzNSwyNiw4NywyMDgsOTUsMjgsNzQsMTgsMzgsOCwxODMsNjEsMjI0LDgyLDIz Myw2OCwxOTUsMTA0LDE4LDU1LDk5LDk5LDIyMCwyMywxNzUsMjgsMTQzLDE3MCwxOSwxMDMs MTgsNTIsMjMxLDQ0LDIyMSw1OSwxMDcsNTUsMTQsMjMsNjUsNDUsOTAsMTU4LDE4MywyMzMs MTQ2LDE1NiwyMjEsMTksMTQ5LDE0NiwyMDcsMTYxLDEyNyw0NiwxODgsNDksMTMsNTgsNDQs MjM4LDI1NSwyOCwyMDAsMjQ1LDEyMCwzMywxNDgsMTkyLDIwNywxNzcsMjUwLDE1LDE1LDMx LDE3MCwxMzYsMTM1LDQ5LDUzLDE4MiwyNCwxODMsMTg3LDEzNywyMjMsMTYzLDEwLDM4LDY3 LDI1MSwxMjIsNzAsMTkyLDYxLDE4NCwxMCwzOCwxNDksMTQ3LDE4LDI0Niw3OCwxODYsMTU5 LDcsMTkzLDIyMywxOTksMjU1LDIzMCwxMTQsOSwxNCwyMDUsNzAsNTcsOTcsNyw4MSwxMzgs MTkwLDIxMSwyNTIsMzgsMTg4LDI0NywxOSwxNzksMTM4LDc3LDIzOCwyNDIsMCwxMzIsMTc5 LDE1NywxODcsMTksMTAxLDExMCwxNDUsMTM2LDIyNCw0NiwxNzksMTE5LDE0Nyw3MSwxNTQs MjIzLDMwLDQ2LDgsMTIyLDIzOCwxMzYsMjM3LDIyOCwyMzYsMjQyLDE0NiwxNjksMTkzLDEw LDE3LDE1OCwyMiwxODAsNTQsNzIsMjE1LDE4OCwyMzYsMTQsMTgzLDIxOCwyMjQsMjQ2LDM0 LDIzMSwxNDQsMTA5LDExNSwyMDcsMTcsMjI1LDE2LDIxMCwxOTcsMjIyLDMzLDE1NiwxNzks MjQwLDE2NCwxOTIsMTY2LDE2MywyMDksMTI0LDYzLDIxMiwxOTUsNzgsMTQ2LDIyMiwyMTEs MjMyLDE0NiwxNjYsMzQsMTYyLDIzMSw2MiwxOTUsOTYsMjEsMjM0LDE2OCw3LDI4LDI5LDM3 LDIyMiw5LDIxOSwyMTYsMTAsNywzMCw4LDIyMiwyNDYsNTIsNyw1MCw3MCwzMSwyNyw1NSw2 MCwyMjIsMTg3LDU3LDIsNDIsNTQsMjI4LDgsNTUsMTMwLDE3LDg2LDY2LDg1LDMwLDEyNCw1 NCw1NSw4MSwxMTQsMjYsNDcsMjUzLDI0LDI1MSwyOCwyMjcsNDQsMTAwLDE5OCw1NCwzOCwz NCwxNzAsNDEsMzAsMTEwLDQyLDMwLDQ2LDE0NywxNTcsNDUsMTIsMzQsNTIsMjE3LDE5LDI1 MSwxNiwxMywyNDEsMTQxLDE5OSwyMDEsNTgsMTcsMjQ5LDE0NSw1NywxMjksMTE5LDc1LDEz NSwxNDMsMTcyLDIzOSw0LDI5LDExMywxMCw2NSwxOTIsMTcyLDEyOSwxODgsMTYsMTYyLDE4 NSwxNTcsNjcsMjE3LDU3LDgsMjQxLDU3LDE3OSwyMjIsMTk0LDE2OSwxNTIsMTkyLDIyMywy MTcsNjcsMTM2LDI0MywyMzMsMTk1LDE2MCwxNjYsMzAsNTcsMjM4LDYsMjE5LDI4LDIzOSwx Nyw2MiwxMiwyMDIsOTQsMTQ2LDg2LDI0NywxOTUsMjI0LDIzMCwxODYsNjUsMjE2LDIyLDE1 MiwxNjEsMTY0LDkyLDIzNywxMjYsMjEsMTA2LDIxNyw5Nyw4OSwxMDIsMjQsMzgsMTQwLDI1 LDIyMiw5NywxNzYsMjE3LDQzLDIzNywyMjUsMjU0LDI1MSwxNjgsMTMxLDU4LDcsMTUsMTIz LDI0NiwxNzgsMTQsMjMyLDIyMiwyOSwyMDQsODQsMTg3LDIwLDE2OCwxMDAsNTQsMzEsMTgz LDUwLDIxOSwxOTEsMjUxLDIwNiwzNCwxNjUsMzYsNzUsMTksMjU0LDQsMTIzLDEzMCwyNTEs MjE1LDE0MywxMzgsMjExLDE4MSwxMTAsMjUzLDE1OCwxNDIsMjQzLDE4NiwxMjIsMTMwLDM4 LDE0MywxMCwxNzEsMTExLDI1MSwxNDEsMTI1LDI0NiwyMjAsMzAsMTUwLDQ0LDcxLDE4LDU5 LDIxNywyMTQsMTQ4LDIzOCwxMzUsMTY1LDE1LDI0MCwxNDMsMjM3LDExMCwyMTcsMTM5LDE0 NiwxLDk4LDMxLDE5MCwyMDMsMjIyLDIxNSw1Miw5OCwxOTMsNDIsMTM0LDk3LDE4MSwzMiwy NTAsMyw1NCwxMTQsMTkyLDY0LDE2MCwyMTYsMjIwLDM1LDIwOSwxMTgsMTc1LDEwMCwzNSwx NDQsMzksMTksMTc2LDE4NiwyMjIsMTc4LDE4NSwxMTUsMzYsMjcsMTgzLDIxNiwyOSwxMjQs Miw4OCwyMjAsMTE3LDEyNywyNTEsNTcsMTQ2LDQyLDI1MywxNTQsNSwyNSwxNywyOCw1Nywy NDcsMTE1LDIyNSwxOTIsMjAxLDI1MCwxNDYsMTI2LDEzMCwyNTAsNSwyNTMsMTIwLDIxNywy MzgsMTA3LDI0LDE4Niw1LDI1MCwxNiwxNjQsMjE3LDEzNywxNDMsMjI1LDc1LDIwLDM0LDEz NSwxNSwxNzgsMTU1LDExOCwyNDYsMTIwLDQ3LDIyLDExOCw2LDI1NCwxMTMsMjQ0LDIyNiwy MCw4MSwyNDYsMTA5LDQ5LDYyLDExMywyMDcsMzYsOSwyMjMsMTIsMjMwLDEyMywxNTMsMjE5 LDU3LDQwLDE3NCwwLDE3LDIzMiw1MCwxMywyMTIsNjcsMTY4LDExMSw1NywyNTAsMTQxLDE0 LDQsMTQ4LDIxNywxMjAsOTksMjE4LDEyNyw4LDYyLDIsMTE3LDIwMSwxOTgsNTYsMjA1LDI0 LDI1MSwxNDIsODQsMTE3LDUsMzUsMTgsMjA3LDEwLDM2LDEzNyw1NiwxMjUsMTg0LDIyLDIx OSwyMzAsNTMsMjE2LDExOSwxNDQsOTcsMTYwLDI0OCwxLDE1MiwxNzIsOTAsOTAsMTgzLDEy MiwyNTIsMjIwLDIyNCwxNTgsMTA5LDIzNCwxNDYsMjM4LDExNiw2OCwxNCwxOTAsMTIzLDEs MTc3LDEyNSwxMjMsNjMsNzUsMTQwLDI1Myw2Nyw2LDQ1LDExMyw0OSwyNSwyMDMsNjksMTcx LDIxMywxOTEsOTUsMTc2LDIzMSwxMjIsMTI1LDEyOSwyMTYsMjI4LDEzMiwyMjgsMjA5LDM0 LDE0LDExNywxNzgsMTE3LDE4LDIzMiwyNSwxNzAsMjQ2LDIzMCwyMzIsMTgzLDIxOSw0NSwy NTUsMTQyLDI0OCw1MCwxNyw3MCwxMDIsMTI3LDMzLDI0NSwxMTAsNTgsMTA4LDkxLDQsMTA1 LDE3LDIzOCwxNzUsMzMsMTAzLDIyNiw1OSwxMjgsMTEsMjQyLDIyMCwxNjUsMTU5LDg1LDE5 MCw5MywyMjYsMjI4LDIyMywyMDIsODAsMjM4LDE5NCwxOCwxNDMsMjQ4LDczLDI1MSwzNCwy NDUsMTQ2LDIwNSw5MywzNCw5NCw3Miw4Niw0MCwwLDU5LDI0MCwxOTMsMTkxLDU4LDM3LDk3 LDIyOSwxMTksMjE2LDIyNSwxNDIsNzAsOTUsOTgsMTQsMzEsMjQyLDMxLDEzLDEwMSwxOTAs NjcsODksNDMsMTM2LDE5MywyNTUsMTcxLDMxLDQ2LDEwOCw2NiwxLDE1Nyw0MCwyNiwzNiwy MzgsMTQ0LDI0MCwxODQsODcsNDQsMjA1LDU1LDEzNywxNTIsMTI3LDE4OSwwLDIzNiwyOSwx MDIsMTkwLDQ5LDE4NiwxMjAsMjU0LDUzLDEyMCwzMCwyNDUsMTU1LDExMSwyNDYsMjYsMTE1 LDEyMiwxMzUsNCwyMTgsMTQzLDI0MSwxOTAsMywyMzcsMjYsMTY3LDMzLDIxMywxNiwyMTUs MTQyLDE2MCwxNjksODksMjQ0LDE4NiwxMywxMjIsNSwyLDUwLDIxOSwxMzIsNzUsMTc0LDI1 MiwxMzQsMjI0LDE2NCwyMTksMjQ0LDE3NSwxNTQsMzUsMTUxLDQ2LDIzLDY1LDEwMiwxMCwx NzgsMjYsMTAsMTMwLDkxLDI1LDEyOCwyNDgsMjA1LDE4MywxODMsOCwxNTgsMjI0LDYsMTA4 LDMsMTQyLDI1NSwxMzUsMTcsMjI5LDE0LDI0MCwyMzksNzUsMjA4LDIsNiwyMCwxNywyMjMs MTcsMjQ1LDE2Niw0MywyNDYsMjA2LDIwMiw3MCw3LDY3LDIzOCwyMDYsNjgsODUsMjA4LDIw NCwxMTgsMTE4LDQ2LDIxOCw4OSwyNDIsMTAsNTcsMTEzLDE3NiwyMTQsMTYsMjM0LDExLDIy OSwxMTgsMTA4LDEyNyw5LDcyLDExNCwzMywzNywxNjAsMjUyLDExMywxNDAsMjU0LDEyNCw2 MiwxMSwyMiwxNzYsMCw0Myw4LDIyMCwxNjYsMjE2LDI1MywxNTQsNTksNzcsNjUsMTU5LDEw OCw5NSwyMjksODYsMSw1LDQ1LDIxMCwxOTUsMjM4LDQxLDMzLDE3LDE1NiwxMDcsMTY2LDIx OCw0MSwxMjgsNjgsMTM1LDEwOCwxMzMsMTc0LDc2LDEzLDEzNiwxODgsMjM2LDIxNywxNjks MTc4LDEzMSwyMzQsMzcsNDAsMjE1LDIxOCwyMzgsMTgzLDIyNSwxNjYsNjMsMjA4LDEwNywx MTMsMjM5LDEzMCwxMjEsMTIzLDAsMTQsNDcsMTM3LDIzMywzNSwyMjIsMTEzLDE2NCwxNDIs NzAsMTcyLDEyMSw3MCwyMjgsODksMjUyLDE3MSwxOCwyNDAsNTEsMTc2LDE3NiwxNjEsMTcx LDY0LDI0MSwyMDAsMjQxLDM3LDEyMCwxODAsMTMyLDk0LDE3NSw2NSwxNDYsMTY2LDE5MCw2 OCwxMDQsMywyNiwyNDEsNDEsMjI5LDE3Miw0MCw2NiwxNTksOTgsMjI3LDExLDE4NiwyNTQs MjU0LDE1MiwyMzgsMTgwLDExNyw2OSw2LDIwMywyMjIsODQsMTU3LDE0NSw0NSwxNTAsMSwx MDUsMTExLDI0MiwxMjIsMTY0LDE1OCwxOTYsNTIsMjI4LDUyLDIwNywyNTQsNDQsMjQyLDE0 NiwyNDQsODYsMjIzLDE5LDEzLDU2LDM5LDE2NywyMzMsNjIsMTM1LDIxNCw4NSwxNzksMjM0 LDEwLDEsMjM4LDIzNiwxMzQsMTc4LDU1LDgyLDc3LDE4MiwxMTAsMzEsMjA3LDE4NiwyNSwy MzQsMTg2LDE5NCwxNjEsMjExLDExMywyMiwxMDUsMTcyLDI1MiwxNzQsMTIzLDM5LDIzLDE5 NCw3NywyMjksODUsNyw3NSwxNDksMTAwLDE2MCw2OCwzMSwxNjEsMTA1LDE5LDE3Myw2OSwz NSwxMzIsODAsMiwzOSwzNiw5MCw4Myw1LDU4LDIzLDE2NSwxMjEsMzQsNTUsMjQ2LDg4LDY0 LDE3OCwxNDAsNjIsMTM2LDIyLDE1LDEwMSwyMzUsMjQ0LDIzOSwxOCwyMTIsMjA4LDIzNiwx MjEsMTQ1LDYsMjUzLDM5LDEyNSwxNiw2MSw2NCwxNTAsNzUsNjksMTUzLDIyOCw1NCw0Miwy MDAsNiwxMzksOTQsMTM1LDI1NSwyMzEsMjE3LDE4MywxMzEsMjIxLDIyLDIzNCwyMjgsNDks OTAsNDQsMzksODUsNjUsMjAwLDI1NCwyMTQsMjA1LDI1MywxMTQsMjUzLDE0NiwxMDUsMjIy LDE3LDE0LDM4LDEwMSwyMDEsNTcsMTc3LDEzMSwyMCwxNjEsOTEsMjI3LDEzMSw3MywxNzQs MTcwLDE3Myw1Miw1LDIwNywxMzEsMTA4LDE4NSwxMzUsMTUwLDIsMjQwLDYyLDEwOCwxMTAs NjAsMjAzLDE1MCwyMzMsMjIwLDEyNywxMzIsMTU0LDYsMTMzLDkyLDI0Miw4NCwxMjAsOCwx MDIsNTEsOTAsMTMyLDEwMywxNTYsMjMxLDEwNCwxOTYsMTc5LDYyLDIwMiwxMDIsMTczLDE4 LDEyMiwyNTEsMTE3LDE0LDgyLDEwNSw4MiwyNTUsMTA3LDExOSwxLDE0NiwyMDQsODcsMTEw LDY2LDEsMjQ5LDMyLDE4MiwyMjcsNTMsNywxNjQsMjE2LDg4LDEwOSwxODcsMjcsNzEsMTE3 LDIzOCwyMDcsMTQyLDEwOSwxNDAsMjQzLDgsMjQxLDEzNiwyNTUsMTksNjgsNjAsODMsMjUw LDI1LDEwMCwxNzYsODgsMTEsODgsMTAzLDg4LDExMCwxNzcsMzYsNyw5LDI2LDM4LDkxLDc2 LDQsMTQxLDk2LDExMCw2NiwzMSwzMiwyMCwyOCwyMjEsMTA4LDI5LDExOSw1LDE5MywyNTUs MjQyLDI1LDE0Miw5MywxNTQsMTIyLDE5OSw5Niw2OSwyMzIsMTc2LDIwNSwyNTQsMTMsMTkz LDMzLDIwMywyMjEsMTEwLDExOSwxMywxNTksMTIsMTQ2LDE5Myw4NSwyNiwxOSwyNDQsNjYs NTQsMjA2LDksNjcsMjU0LDE5OSw0Niw3LDIzNSw0OCwxNzEsMjEsMTk2LDM2LDYwLDI1NSw2 MCwxNywyMTcsMjU1LDI1NSwyNTUsMjU1LDE1OCwxNDksMTQ4LDIyMSwxNDIsMjE4LDE1OSwx NDAsMTU5LDE0OCwyMTgsMTQyLDEzNiwxMzEsMjE4LDE5MiwyMTUsMjExLDEzNSwyNDEsMjAs MjQzLDExNSwxNTcsNDksMjM4LDkyLDExNCwzMSwxNzAsNzksNzYsMjU1LDI1NSwyNTUsMjU1 LDMxLDg2LDEyMywxMDIsMTM1LDE1MywxODYsMjAyLDIzLDc0LDQ5LDE4OCwxNzUsMTMwLDI0 NCwxOTgsMjI5LDY0LDIyMiwxLDg2LDI0MCwxNjAsNjUsOTAsMjE5LDE3NSwxODAsODAsMjIz LDkwLDEzNCwyNTUsMjU1LDI1NSwyNTUsMTU2LDc5LDIyMiwyMSw2OSw3NCwzNSwxODEsOTgs MTk1LDE4Myw5MSwxNjcsMjE1LDI1NCwyMjgsNzMsMTMzLDQ2LDE1LDM3LDgwLDE5NiwxNzMs MTI3LDUzLDE0LDIwNSwxMDUsMTQ5LDIxMSw5NSwyNTUsMTMsMjU0LDI1NSwxOTMsMTY1LDY0 LDEzMSwyMzcsNTEsMzMsMTgyLDI1MCw0OSw1MywxNjQsMTIzLDIwLDc0LDc2LDExMSwxMzcs MjAyLDIyLDIwMSw3MywzMSwxNTAsMjU1LDI1NSwyNTUsMjU1LDIzLDEyNyw4NywyMDcsMTk1 LDI0MiwyMDgsMjEwLDIwMywyMTQsMjMxLDEwMywxNTksMjMyLDYwLDE1OCwxOTIsMTc1LDk1 LDIzNSwxOTYsMTQ0LDIzNSwxOSwzMywxMDAsNDIsMjM4LDE5Miw2Nyw5LDI0NiwyNDgsMjU1 LDI1NSwxNjUsMjMwLDIyLDIzMyw4NCwyMzMsMTg1LDI0NSwxNzgsMjMzLDE1MCwyNDgsMjI4 LDE2MiwyNDQsNjIsMjQxLDIwOSwxMSwxMywxMjUsODAsMzUsNTMsMjU1LDI1NSwyNTUsMTY1 LDE1NiwxMTcsMjMzLDQ2LDE4OCw1NywxMjMsMjUyLDExMiw0MywzMSw0MSwxMjIsNjcsMjMz LDEzMSwyNCw0MywyMDIsMTQ1LDM4LDI2LDk3LDE4OCwxMTEsMTgsMjU1LDI1NSwyNTUsMTkx LDE0OCwxOTUsNjcsMTc1LDE2MiwxNTQsMTgyLDc4LDIyNyw5MSwxMTYsMTU4LDExMiwxMjcs ODIsMTgxLDY1LDIyLDU3LDM2LDEwMCwxMDgsMjIxLDI1MiwxOTEsMjA5LDIyMywyMzIsMjM1 LDcsNDIsMjI3LDExNSwyMDEsMTQ3LDY3LDExMSw0Myw0NSw1Nyw0NiwxMjEsMTQ1LDI1NSwy NTUsMTI3LDE2MSwxNDYsMTU2LDE0NCw0NSw4NCwxMzEsODcsMzQsNTgsMTIwLDM3LDE3NCw3 OSwxMTUsMjM1LDE4MCwxOTUsNiwyMjIsMTg5LDIzNiw0LDU2LDI2LDI1NSwyNTUsNDUsMjU0 LDE0MCwyMiwxMDIsNTMsNjksMTkzLDE3NCwyMDcsMzMsOTYsOTIsNzYsMywyNDIsMTEwLDY0 LDE1OCwxOTQsMTU5LDE5NywyMjIsMTg4LDE2MywxODEsMjU1LDI1NSwyNTUsMjU1LDkyLDE3 NywxNzQsMTI0LDExMCwyNiwxMDcsMjIzLDIsMzQsMjQsMzAsMTY2LDEwNCwxNzgsMjQ3LDI3 LDMxLDM5LDgwLDc1LDEwNSwxMTgsMTA0LDI0NCwyMDUsMjEsMjI1LDE0NSw0OCwyMDgsMjI0 LDI1NSwyNTUsMjU1LDI1NSwzLDM2LDEwMywxMDEsNjAsMTY2LDE0OSwxNjQsMjEyLDExOCwy MzYsMTg4LDI4LDY3LDE5NCw1MCwxOTYsMjQwLDEwOCw4MiwyMDYsMTA2LDIzNSw2NSwyNDIs MTc5LDIzMiwxMTQsMjksODUsOTUsMTYwLDE5MSwxOTMsMjU1LDI1NSwxMDUsMjEyLDIxLDQ2 LDE2OCwxNTYsMTA0LDUzLDM5LDc4LDE4NSwyOSw1NiwxMTIsNjksNjIsMTIwLDIxNiwxMywy MCw0MCwyMTgsMzIsMTk3LDI1NSwyNTUsMjU1LDI1NSw1Nyw2MSw5OSwxNzUsMTM4LDExMiw2 LDEzMCwyMjgsMjQzLDkzLDE5LDAsMTgzLDE3NCwyNDAsMTQ4LDQ0LDExMSwxMzQsODMsNzMs MTY4LDY2LDEyOSwxMDEsMTcwLDYxLDEzMywxMTYsMTUyLDE4MCwyNTUsMjU1LDI1NSwyNTUs MjMzLDk3LDIwOSw3MCwxMDUsMTIyLDIzNiwxMTcsMjQ4LDE3Nyw3NywyMjQsNTQsOSwxMDYs MTE2LDYzLDU4LDIxNSw5MSwyMjYsMTQ0LDIxNCwxMzQsMTk3LDE3MiwxNzksNjEsMTQ1LDks NjAsOTEsMjU1LDI1NSwyNTUsMjU1LDE1MSwyMywyMDksMjI4LDExNywyMzQsMjI0LDE4OSw4 OCwyMTcsMjA2LDQ1LDE5NywyNSwxMjksMjEyLDE5NiwxMTksMTIzLDIyNCw5NCwxNjYsNjIs NTIsMTQ0LDE4NCwxMjcsNzksMTM0LDE1NywxOTAsMTQ5LDI1NSwyNTUsMTQxLDI1NSwyMjIs MjQ1LDE2Nyw0MSwyMzQsMTk4LDg3LDI0NywxMzksMTI2LDE4Niw2NiwxNTQsMTEwLDE1OSwy NDksNywxMiwxNTAsMTcxLDE5OSwyMTMsMTY1LDc5LDE5NSw1NiwyNTUsMjU1LDI3LDI1Myw1 MywxNjUsMyw1OSwyMzYsNTEsNDQsMjAwLDE1Niw5Miw4NCwyNDMsMTI4LDE3NCw0Miw2Miwx NTIsMTg3LDEwNyw1NywxNjksOTcsMTAwLDE2NCwyNTUsMjE5LDI1NSwyNTUsMTc2LDE5Miw4 LDE5NiwxMjYsMTksMTg5LDExMiwyMTMsMjQ2LDg2LDUwLDcyLDY3LDI0Miw4NywxNjIsMjM2 LDEzNCw0OCwxMzMsMzMsNTgsNjksNzMsMTU3LDE1OCw0NSwyNTUsMjU1LDI1NSwyNTUsMTU0 LDE5NywzMCwxMDYsMTMwLDY3LDI1MywyNTMsMzksMjE0LDcsMTk3LDE5Miw2NSw2OCwxMzEs NDMsMTg4LDEyNCwyNSw5Miw1OCwyMzAsOTgsNTIsMTAwLDEwMCw4MSwyNDksNTAsMTc1LDEw NCwyNTUsMjU1LDIxNCwyNTUsNTAsNzksMjIxLDEwMyw1MCwyNDksMzAsMTU1LDI2LDg2LDEy NSwxMDQsMTU2LDIzOCwyNTMsMTMxLDEzOCwxNDUsMTg1LDUwLDUzLDc5LDEyMiwyMzUsMjA0 LDIwMCwyNTUsMTUxLDI1NCwyNTUsMTgyLDE2NSwxNzQsNzYsMjQ3LDI1MywxMTUsMjU1LDEy OSw2MSwyNywyMzMsMTAyLDIxNSwyNDMsMjA0LDMxLDIxNiwyMDUsMTk4LDYzLDEwNiwzLDI2 LDE4MiwxNjIsMjU1LDI1NSwyNTUsMjU1LDU5LDQ5LDI0Miw2NSwxODYsMjIwLDkxLDIyNCwy NTIsMzMsNjMsODksMzEsMTg0LDIyMywyMjksMjksMTgzLDE5MywxNTEsNTEsMTEwLDIzMSwy MzksMTU0LDI3LDQyLDIyLDU0LDIzMCwwLDE5MywxOTMsMjE5LDI1NSwyNTUsODIsMzEsMTQx LDI5LDUsMTkyLDExMywyMTEsMjM4LDE3Nyw4MSwxODksNDYsODYsODEsMTcwLDExNCw2Nyw3 NCwxMjEsMjAzLDE0NywyNTUsMjU1LDI1NSwxOTEsMTcsMjQxLDQ1LDEwMyw0NywxMzQsNDIs MTAyLDc4LDE4OSwxNjIsMTY1LDE0MCwxMzQsMTgzLDg4LDk2LDE4NCwxMTksNjksMTgxLDk5 LDE0LDIxLDcxLDI1LDQwLDIwOSwyMCwxNzUsMjM0LDI1NSwyNTUsMjU1LDgxLDg1LDE2NCwz NiwyOSwyNTIsODgsMTc4LDIzOSwxODcsNiwyMDgsMjEsMjQ3LDIxNywxNTQsMTc5LDE2OSw3 NiwxMDEsMTgwLDEzOCw2LDE2Niw1Nyw1MSw1OSwyNTUsMjU1LDQ3LDIwOCwxMzEsMTY1LDQz LDg1LDIsNDUsMTU1LDIzLDIxOCwyMDUsMTI5LDIyNCw1MywyMDQsNjIsODEsMTU5LDEzNyw1 OCw5LDgyLDEwNiw3LDM1LDI0OCwxMTQsMyw0NywyNDUsMjQ5LDEyNSwyMzgsMjI0LDcsNjks MTEwLDEyNSw1NCwxNjAsMTAyLDIwNSwyMjcsMTAyLDEyMSw3MSw3LDIwMywxMjQsMzEsMjEx LDExMCwxOSwyMTcsMTMzLDE3NCwyMjcsMzcsOSw1Niw2LDE0LDE2NSwxNjQsOTMsMjQ1LDMs MTUsMTE4LDE2NCw1LDI1NSw4OCwwLDE4LDE0NCwzOCw4OCwxNTIsMCwyMTEsMTAyLDI1MSwy MTUsOTIsMSwxMjQsMzUsMjA5LDEzLDI1MywyMywyNCwyNDIsMTg5LDIxNywyNDksMjUwLDIy MywzNSwzNCwxNiw2LDE3LDQyLDExOSwyNTMsNzUsMTA4LDEwLDExOSwyNDIsMTIyLDE5Niwx ODUsMTQzLDIyNCwxMjIsMTMyLDE2MiwyMzgsMTU2LDEyMSwyNiwxOTMsMjIsMTI4LDEzMiwx MjYsMjQ3LDY5LDUwLDEyMywyMjMsMjMsMTM0LDEzNCwyMDAsMjQyLDEzLDE1OCwxNDQsODMs MjUsMjA0LDIyMiwxNjYsMjM0LDUsMjQ3LDEyMywxNDcsMTYzLDQ0LDIyNiw4LDYwLDE0Niwx NzgsMjQ4LDIsMTUzLDIyNiw1NSwyMjYsMTMxLDIxLDIzOSwyLDE2LDgzLDIzOSwzNCw5Miwx ODYsMTg2LDIwMCwxNSwxMTAsMjAsMTQ5LDE0MywyMzksNDksMTkxLDIyNiw0NSwyMDcsMTU0 LDEyOCwxMzIsNzcsMzgsMjEwLDExMyw1NCwxODMsMTIsMjM2LDE5LDEyMiwyMzQsMjUxLDg5 LDI0NiwxMzgsODksMjI2LDMsMTM1LDI4LDM1LDI3LDI0MSwyMjYsMjIsMTcwLDIxLDcxLDIy NiwyMTYsMjQ2LDIyMSwxLDQ1LDIyMywxNCwyNDgsMjA1LDIyMSwxMTEsMjEyLDUwLDEyLDE3 NSwxNTYsNTksMTgzLDEyLDI0MiwxMCwyLDI1MSwyNTAsMiwxMCwxMDIsMTQ3LDEzMCwyNDIs MTQ1LDQ1LDI4LDE5MiwzLDY5LDE0MSw3NywyMjYsMjE0LDI1Miw2LDExMSwzNCwxNzYsNDUs NzQsMjEyLDYsMTYyLDExMywzNywyMDksMzIsMTIyLDIwMyw5NywyNTUsMTEsMTAyLDIxMiwx NDMsMjUxLDE3NywxMTUsMTY3LDEwLDE3MSwxNjgsNTQsMjUxLDEwLDEwOSw3MiwxOTMsMzIs MTYzLDIyMCwzMSwxNzYsNjMsMTM5LDEwMiwxNyw2MSwxNjMsMTI3LDUxLDE0Myw2Niw0OCwx NTUsMjI4LDIxNyw1LDEzMywyMCwyNDUsMjAsMjQ4LDI5LDE0NCw2Niw2LDEwMCwyMCwyNTEs MTE5LDE1OSwxNjUsMTUwLDI0MywxNDAsMTM0LDY3LDIwNywxMDUsMTI0LDU1LDE3MSwxOTIs OSwxNTIsNjUsNzEsMjI2LDEzOSwyNDYsMTc2LDE4NCwyNDQsMjksMjUwLDE4Myw3OCwzMiwx NywyMTcsMTc2LDEzOSw1MSw2Nyw3OSw3MSw2LDE0MCwzOCwyMzcsMTMwLDU1LDU3LDg2LDIz NywyNywzMiwyMiwxNDUsNTYsMTIzLDE3OSwxODEsODMsMTA2LDI0NiwxMjQsMTU1LDExMCwy MiwxMzksMjM4LDc2LDIzLDU4LDkxLDE3LDQ5LDEzMiw2MiwxOTQsMTI0LDYwLDc3LDIzNiwy NDgsMTA2LDM2LDEyNiw5OSwxMTYsNjAsMTQsNTAsMTUwLDI2LDExNSwzMiwxNzQsMTkwLDk2 LDMsMTUwLDE5Myw2LDg2LDEyMSwxMjgsMTc3LDcxLDE4MCwxMTgsMTcsMTUxLDU1LDY0LDE3 Nyw2NSwxODIsMTQ3LDEyNywyMDksMTU4LDI0Nyw4NiwxOTUsMTEwLDI3LDE3MSwxMSwyMDEs NjEsMjM2LDE4LDI0MCwyNSwyMTksOSwxNzgsMjA1LDE2OCw4MywxNjgsMTgxLDE2LDI0LDM0 LDEyLDUxLDQyLDE5NCwyNTIsNTQsMjAsMTExLDE5OSwyMDIsODYsODIsNzEsMjMwLDIyMiwx OTcsOTcsODYsMTcyLDcxLDIwOSwyMDksMTM0LDIyMSwyNDksMTAsMjE4LDE3MiwxNjgsMjM4 LDEzOSwyMjAsMTg3LDE5NywxNjQsMTcsMjE4LDI0MCwzMSwyNTQsMTUwLDYzLDEwOSwxMSwy NTUsMTEsMjM1LDIzNCwyNDksMiwxNjMsMjUsMjQ5LDYsOSw5NCwyNDEsODAsNjEsODAsMTA5 LDY3LDE2OCw3NSwxNjUsMTEzLDYwLDEzNywxMDgsMjEyLDMwLDgyLDIzOSw2LDYzLDIzNCw2 MCwxNDYsMzAsMTA3LDUsMTc1LDI0OSwyMDIsMTUsMjQzLDE0OCwxOTMsNjcsNjgsMTYyLDQ1 LDExMywxNjIsMzMsNzMsMTM1LDE5Myw4LDI1NSwxNzYsOCwyNTMsMTYyLDExNiwxMjYsMTU2 LDIzOSwxMDMsMTQsMjQ5LDExOSwxNjAsMjMwLDE3Myw2MCwyMjQsMjI3LDIzNiwzNSw1LDUs MTk0LDEyMSwxOTAsMTU3LDIzLDE5NywyMzksMjAsNiwxNzksNTYsMjE5LDEwMiwxNTIsMTE2 LDE2OSwxMjAsNTQsMTk5LDYsMjA4LDE4MCwyNTIsMTcxLDQ3LDIyMSwyNTIsMjQyLDQsMjQ4 LDEzLDE4OCwyNDgsMjQ1LDgyLDEzNywyNDUsNzcsMTY0LDE5NywyMTEsMTc0LDgwLDE1Niwx NTAsMiwxNzIsMTEsMTc2LDEyMiwxODAsMjEsMTE5LDgzLDEwLDg3LDE5OSwxMDcsMjUxLDE1 MCwyMTksMTQ3LDE5NSwyNiwxNDksMTcwLDI3LDIxMiwxNzAsODcsMjI3LDE1Niw2Niw5Nywx NzIsMjA5LDg3LDE2MCwxMjcsMzUsMjUyLDEzMSwzMCwxMjcsMTAwLDE3OCwyMzcsMTcsMjEx LDE2LDE1NiwzOSwyNTIsMTU2LDE2MCwxNTYsMTkzLDE3NSw4LDY0LDE3NCwxNDksMTA2LDk1 LDE5LDUsMjUsNzksNjIsMTE2LDIxNSwyMDYsMjAwLDE2MiwxNzcsMTQzLDc0LDIyMywxMDks MjM4LDExNywyMzgsMjI2LDY0LDU4LDIxLDE3OCwyNDUsNiw5NSwxMzcsMjEwLDIxNyw0Miw5 NywyMTQsMjQ2LDgsMjUxLDExNCwxNzcsMTM5LDIxMSwxMjEsMTk5LDE5Myw3MiwxOCwyOCwx NDYsMTQwLDIxLDI4LDE5OCwxNTgsNDksMTM2LDExNSwxOTAsMTM2LDk1LDE2NCwyMiwxNjAs MjA3LDEyLDIyMyw3LDE5NywxNzgsMTg2LDE0Nyw1MSw3MSwzMiwxNjIsNzIsMTQsMjAwLDE0 Myw5LDIyOCwxODAsMjE0LDM0LDE0NCwyNDksMjMyLDIzNCwxMDAsMTg4LDM3LDE3NCwyNDks MTM2LDQ0LDIsMjIyLDMzLDk2LDg0LDE3OCwxNSwxNDMsMzEsMTc4LDEzMCw4LDE1NSwyNywy MTMsMjQ3LDEzNiwxMzEsMTgwLDI1LDEzOSwxMTIsNTQsMjMzLDEzNSwxNDUsMTk1LDY3LDIy NywxMjAsNjYsMjMsMTUwLDc0LDIxNSwxNzYsOSw2MywyMDcsMjQ4LDE3LDQ0LDIyNCw0Mywy NDksMjQ1LDEwNSwxMTksMTU5LDU3LDE4NywxMTcsOTIsOCwyNSwyMzksMTcyLDE2MiwyMDQs MTk5LDIwMCwyMDAsNjcsMjMsMjIyLDEzMywyMDIsODAsMTI3LDI0OCw0NCw0MiwxMjMsNjAs MjUyLDI0OSwyLDI0MSwxNzcsNDksMTcyLDE4LDE4MSwyMzgsMTg0LDI0OSwxOCwyMDYsNDEs OTMsMyw5Nyw1NiwxMDIsMjAsMTQ4LDI1MSwxMSw4MCwyMjYsMTksMTE3LDYzLDI1NSw2Niw2 Niw2LDE3Miw3NCwyNiwyMzMsMjM3LDUzLDI0MywxODksMTk2LDEwLDUzLDEzOCwyMSwxMTQs NTcsMjAwLDEyOCwxODksMjExLDY3LDEzMCwyMTcsMTA0LDI1MSwxMTYsMTkzLDI0Myw2MCw0 Nyw0LDIwNywxMzMsMTQwLDYwLDE4NSwxOTcsMTAyLDMxLDM3LDExNiw2NCwxMiw2NiwyOCwy MzMsNTAsMjAwLDIwMSwxMSwyNiwxMSwxODEsMTA0LDIyOCwxMTUsMTQzLDkzLDE5OCwxOCwy NDYsMTQ2LDU1LDU2LDE0OCwxNzcsMjUsMTc4LDEsMTg1LDE5MiwxMTAsODEsMTE2LDIzMSwz NywzOSw3LDcsMjUwLDE4NiwxNiwyNTAsMTQ2LDE0NywyOCwyMjgsMjQyLDE0NiwzNiwzLDIz MiwxOCwyMzIsMTQ3LDEwMywxMzUsMjI4LDE4NCwxOTgsMTEsMjMwLDgxLDI1MCwyMDEsMTY3 LDU3LDIwMSwyMCw3LDk4LDI1MCwyMyw5MywyMzIsODksNDcsMjI4LDIwMCwyMyw1LDIzMiwz LDEwLDE1Miw2Myw1NCwxMjYsMTkwLDYyLDg1LDIwMSwyMDcsMjA2LDE1NSwxNjcsMTg4LDI3 LDQ3LDE1NCwyMSw1NiwzMSw3NCwyLDE1NCw0OSwxMDcsMTI5LDI0LDEzNSw0OCw3NiwxOTMs MTQwLDI1MSwyNDYsMTksMjgsMjcsMTAsMTUyLDgzLDIzMiwxMzUsMjIwLDE3LDUzLDkxLDEz NCwxMjQsMzksNywxMDMsMjM0LDE1NCwxNjksODYsMTY4LDY1LDEzLDQxLDIwMiwxMzQsMTc2 LDIzOCwxNjQsOTUsMTIxLDE1LDQ2LDIyOCwxNTcsMjM1LDQ3LDMxLDE1LDE4MSw0OSw4OSwx OTcsMTEzLDYxLDIxNiwxNjksMzAsMTE1LDE3NywxMjIsMiw5MywyMzcsMTg2LDE5MCwxNTYs MjMyLDI0NywxMiwxOTYsMjMzLDE5OCwyMjksMTg2LDE0NCw3NCw2LDEzMywxNDgsMTI5LDI1 MSwyNDgsMTg5LDE4NSwyOCwxOTEsMjUxLDc3LDIzMSw3MywyMDQsMjE0LDExNywyNCwxNjQs MTY5LDIyMiwyMzQsMTksOTUsMTU3LDMwLDU5LDE1MCwxMSwyMzQsMjEwLDMsMjM0LDE3Miwz MSwyNTAsNzUsMTc2LDEsMjM3LDE5Miw0MywxMTUsMjI0LDE3LDI1MywxNzEsMTEzLDIyMSw4 MiwyNDAsMTUxLDk4LDE2MywyNDIsMTYzLDExNSwyMjcsMTYyLDE5NiwxNzAsMzcsNDEsMTc3 LDY2LDU2LDU0LDExNSwyNDksMjI4LDE3MSwxNTIsMjE1LDQyLDkwLDI0MCwyMzgsMTE3LDE4 NSwyNTQsMTMzLDIwLDkwLDcwLDAsMTksMTQxLDEwNyw2OSw1OSwyMjMsMjM3LDE4NSwyMywy MzgsNDEsODksMTUxLDc0LDg4LDYxLDI1NSwxOTksNSwwLDksMTgsMTEwLDExOSwxNDQsMTg3 LDY1LDI0MCw0LDY5LDE5MSwxMyw2OSwxNzAsMTA5LDEwOSwxODYsODUsMTM1LDYsODEsMzIs OCwyMjIsMjAsMTYwLDIxMCwxNiw2MywxMzcsMTgwLDI1MywxMjcsNjMsMyw2MCw2NywxOCw1 NSwxNTcsMTc3LDI1NCwyNDEsNTEsMTQyLDE1NSw1LDIwMywxMTcsMTUwLDEwMSwyMTcsMTE4 LDIzNiwxMzksMjU0LDUsMiwyNDYsMTQsMjQyLDE5NCwxMiwyMzAsMjM4LDEzMiwxNzEsMTgs MTk5LDM1LDQ2LDE0OCwxOSw3OCw2OCwyMTcsMjAxLDIzLDE5MSwxNTUsMTM3LDEyNyw1NCwx Miw4NCwyNTIsNiwxNDMsMjQ5LDE4MSwxMzMsMTcsMjU1LDIxNSwyNDAsNzgsMjQsMjM0LDkx LDIzOSw3LDEwNywyNDcsNywxNjksMjQ4LDI3LDEwOCwxNywyNDEsNjcsMjA4LDIwLDI0MSwy NDUsMTE3LDExNiw0Myw0NCwxMzksMTU0LDE0MCwyNTUsMTkwLDE1MCwyMzYsMTc1LDEwMSwz OCwyMDQsMTY0LDIyMywyNDAsMTM2LDI0MCwyMzIsMjQ3LDUzLDI3LDE4MSwyNywyNTQsMjIz LDE2LDI1NSwyMzAsMTE0LDE3LDE3NSwxMzQsODksMjI1LDI2LDg2LDE2Miw5NSwxODcsMTc1 LDIyNiw3NCw4LDE2MCwxNjgsMTI4LDExOSwxODUsMTAyLDEyOCwxMzMsMjE0LDEzMywxOTEs ODAsMTU2LDIzMiw2Nyw0Miw2LDI0LDU2LDEyMSwxOTMsMywxNDIsMTcyLDEyMyw2LDIyMCw5 Myw4OSwxODYsMTQxLDM1LDI0NCwxNDQsMjQ5LDEyMSw1LDE0MywyMywyOSwxMTgsMjQ1LDQ5 LDEwLDI1MSwyNTUsMjM3LDE5MSwxNTMsMTEzLDM2LDE4MCwxODAsNzUsMjUxLDcsMTkzLDc3 LDEzNiwyMDYsODYsMTk4LDIwMiwxMzYsMjU0LDE5OCwxOTUsMTQwLDIyMiwxOTgsMTg3LDcs MTExLDIyMCwxMDQsMTkwLDE2MCwxNDAsMjMwLDE5OCwxNTUsMTI4LDE0NywxOTgsMjEyLDEx MSwxOTgsMTY1LDE0MiwxODIsMTEyLDExLDI0OCwyNDYsMTk4LDIxNSwxNDIsMjQyLDI0Miwy NDEsMjQwLDc2LDI1Myw1Niw2NywxOTIsODAsMjUyLDE4NSwxMTIsNTAsMTcsNjEsMTc5LDEz NSwxNywyMDAsMTc0LDEyNSw3Nyw2LDc2LDc1LDEzNywyMDEsNCwxNzIsNDMsMjA1LDI0MCwy NTIsNzQsNTAsNzMsMjI2LDcwLDI0MSw2NiwxMjYsMjA5LDE5MSwyNDIsOTEsMTM0LDI0Myww LDYxLDQ4LDE3MiwxNjAsOTYsMjQyLDkxLDM2LDU2LDI0Miw5MCwyMTIsODcsMjQ1LDE3Niwy NTUsMjI3LDIwMSwxNTQsMTYyLDExNSw5LDQ0LDE0MSw4MSwyNTUsNDgsMTksMzQsMjQyLDQs NzUsMjUwLDk3LDEyOCwyMjUsNjUsMTksMTUyLDExNSwyMjAsMjUyLDI1MiwxMTgsMjQ4LDIx NCwxMCwyLDE2OSwyLDI0NSwxMjEsODksMjMxLDMwLDEyMywxMzUsMTQsMjM0LDIyMSw1MSw0 NCw2OCwyOSw2NSwyNDQsOTQsMTIzLDQ3LDQ5LDExMywxMiwyMjIsNiw2LDIwMCwxODYsMTQz LDEzMiwxNjMsNTQsNCwyMjYsNjMsMTIwLDU2LDU1LDI0NSwyMzQsMTczLDUwLDIwOSw0OSwx MjMsMywyMjUsMTg5LDI0MCwzMSw3OSwxNjQsMTIxLDMsMjU1LDE0MCwxNjMsOSw5LDExOSw3 MSwxMTAsMTk1LDIyMiwxOTQsMTA5LDk4LDg2LDIzNiwyNTMsODAsNTYsNTMsNDUsMjQsOCwx LDE3MywyNDgsMzgsMjIyLDI0MSw0MCwxNDIsMTk1LDE2OCwyNywzOCwyMTksOTAsMjQ3LDE5 NywxNDUsOTMsMTYwLDE3NCw1MCwyMjAsMTgsMjQzLDE3Nyw0MywxMjUsMTMwLDYwLDE3Mywx NjgsMTA1LDgsMjE3LDM0LDE0NCwyNTEsMTMxLDUzLDY1LDI0MCwyNiw1LDE3NSwyMzQsMTY0 LDE5LDE3NCwyMSw1MiwxNjcsNzQsODgsMTUyLDY4LDI1MSwyMDEsMTQ1LDE0NywxMzUsMjQs MjQ2LDE2MCwyMjAsMjQ3LDEsMTIxLDc4LDIwMCwxODQsNTgsMjQ2LDIxNCwyMzQsMzMsMzAs MjA3LDE3NCwyNDcsMjMyLDk2LDk0LDU4LDI0OSwyMjAsMTUwLDEyMywyNTIsMTE4LDIxLDg2 LDEzMCw0Nyw1NSwxMzgsMTU1LDEzLDYwLDE1MCwzLDE0NiwxMTQsMjMzLDYsMTM5LDc0LDEx MCw0NCwxOTksMTcwLDExMCwxOSw5MiwyNTUsMTQzLDEwLDYwLDE5MiwxNzMsNjksMTk4LDE5 OCwxNzAsMTI5LDIsMTcsMTczLDg5LDI0NCw4MywyNTMsNiwxMzIsNTYsMTUyLDEsMjEzLDEy NywzNyw1OSwxMjksOTgsMTcsMTYzLDIyLDE0Myw1OSwyMjUsMTE3LDIyMyw1MSwxNDQsMTgs MTgsMTUsMjQwLDg4LDE3MCwxNTMsMTcxLDIwNCwxMjgsMTA0LDE5MSwyMTYsMTA4LDE5LDEz LDI0MSwyMzQsMTIyLDE5NCwxNjEsNzksMjE1LDIyMSwyMzksMTI4LDI1MSw5NCwxNywxMCw1 MiwyMTgsMTIsMjQwLDM0LDIzMiwxNTEsMjI4LDkwLDE0OSwxNzQsMTIwLDE3MywxNDYsMTgs NywyMjMsMjM2LDE5LDYyLDExNCwxODIsMzcsNjksNTEsOTcsMTY2LDIxNyw1MiwyMDgsNCwy MzIsOTYsMjI1LDY0LDI0Niw3MSwyNTEsNzcsMjE2LDk5LDE4NywxMTMsMjQxLDI1MCwxODEs NDIsMzUsMjMyLDI0NiwxODQsMTc2LDUsMTgzLDQ1LDIzNiwyMDMsNjksMjQ3LDQ1LDM2LDEy MywxMjksMjAwLDExMSwxNjgsMjQ2LDIzMSwyNDcsMTc3LDE2MiwxOTAsMTg2LDIwMiwyMTcs MTc1LDk3LDI0LDE3Niw3NCwxNDksNjQsNDcsMTY1LDE0NCw4LDE5OSwyMjYsNTAsMiwxOTYs MjUxLDE2LDU1LDI0MSwxNjYsMjM2LDIsMjI0LDE5MCw0MSwxNjgsOTEsOTEsMjE1LDk3LDU2 LDIwMCw2LDk2LDIzNiwyMDksMTUwLDIsMjQ1LDIwMiwyNDEsMTM5LDEyMCwyMzMsNDksMTAw LDE5NywyNiw2MCwyNTQsMjUzLDI0MSwxODEsMTUxLDEwLDE4OCwxMTksMTY4LDIxNCwxNTYs MTE0LDgxLDE0NywxNTYsMTIzLDUsMjEsMTI3LDIzMCwxODcsNiwxNTIsMTY4LDQ0LDksMjcs MjMyLDEzLDI0OCwyMDQsOCwyMiwyMDAsMTYsMjIwLDE2NiwxMDMsMTcxLDExLDIzOCwzOSwy NDksMjQ2LDE4NiwxNDYsNjIsOTgsNjAsMTM2LDI0NiwyMTUsOCwxNzQsMjcsMjM2LDIwOSwx MTAsNzAsNTQsMTYyLDMwLDc0LDIwNCwyNTIsOTgsMTk2LDYwLDU4LDE5MSwxODIsNSwyMCwx MjgsMjE5LDEzOCw3MSwxNjUsMTU5LDE1Myw0MCwxMTUsMTU5LDE2MCwxMzEsMjEsMTAwLDI0 MCwxMjQsMTI3LDE0NCwyNSwxNSwyMCwxMTcsNzksMjMwLDEyMCwzMiw0LDcsMTY1LDE5Niwx MjYsMTQzLDE0NiwxNzgsMTM1LDIzNSw1MywyNDAsMTk4LDEwNCw1MSwxMzgsMzUsMTg1LDE2 MywyNDEsMjIxLDU0LDEyOSwyNDAsMTY0LDEzMSw0MSwyOCw3MiwyNDAsMTgyLDE2MCw5Nywx MzUsMjA4LDE3Miw1NCwxMTEsNTcsMjE5LDE0MiwyMjAsMTcsMTQsMTgsMTc1LDE1LDE1Nywx MjIsMTk2LDIyMiwyMzAsMjM1LDEyOCwyMjAsNiwxMzksMjA3LDEzLDEyNCwyNTIsMTAsMjIy LDIwMCwxMDksMTEwLDExMyw3MCw1LDI0Miw5Miw5OCwxODgsMTcsMzcsMjA5LDUxLDE3MCwy NDksODIsMTY1LDE2NCw1LDIyMiw1LDEzMywxNzcsMjM0LDI0MiwxMyw0MiwyNDQsMjQwLDMw LDI3LDAsMjE1LDIyMiwyNDQsMjAyLDE4LDEwMywxOSwxMCwyNDMsMTgsMzAsMjQzLDIzLDIx LDIzMCwxNDQsMjAzLDE5MCwyMzksNzYsMzUsNiwyNDIsMjUxLDk0LDI5LDE0NCwxMiwxMjQs MjQwLDE5Myw4NiwxNzAsNTksMjU1LDEyOSwzMSwyNywxMTMsMTEsMTMsMzQsOTksNjcsMTk4 LDE5OSwzLDEyNyw0MCwxMzUsMjQ4LDEzLDQzLDI2LDE1OCwyMTksMzIsMTY4LDY1LDI1Miwx MDAsMjcsMTE3LDI0MCwyMzQsMjksMTgyLDEwOSwyNTIsMTIyLDEzNSwyNywyMDIsMjM5LDYw LDE3LDIwOSw3NCwxOTMsMjIwLDEzMCwyMjIsMTI5LDI1MCw3NCwxMjAsMTcxLDgyLDUxLDEx MywyNDksMTQyLDUzLDExNSwyMzMsMTAsNzAsNTEsMTg3LDc0LDIwMCw1LDE1NCw1NiwyMzMs MzcsMTg5LDgyLDI0MCwyMDUsMTA0LDc0LDE2OCwxOTUsMTA2LDY2LDI0MCwzOCwxNjEsNTYs MjUwLDI1NCw5MiwxMTIsNDgsMjI2LDIzNSwxMDAsMjE4LDE4LDEzLDI0MywxMjIsMjE0LDE5 Miw2NSwxMyw4OSwyMiwyMzAsMTExLDE0MCwyLDIyOSwyNDgsNTEsMjMyLDIzMiw1MywxOTgs MTksMjI0LDE2Myw2NSw0MSwxNzIsMTQsNzcsMjksMTYyLDEzMyw5MCwyMDYsMSw1MCwxNDEs MTIwLDI0MSw4MSwyMDUsMzEsMzYsMjgsMjQwLDc4LDE2OCwxLDE3NCwxMTYsMjIyLDEyMiw0 OSwxNzcsMTYxLDI0OCwyMTcsMTMsMjI2LDE3LDMxLDE4LDE0NiwyMTcsODgsMTg2LDIzMSw1 MiwxOTEsMTg3LDEwMSw5MCw5OCwxNjcsNTcsMTQ2LDIwNiwxNSwyMjEsODgsMTE0LDU3LDIx MCwyMzYsMTQyLDQsOTUsMzEsMjUsOTQsMTMwLDM3LDk0LDYwLDIyMSwxNDUsMTY3LDE2MSwx NDYsNDEsOTAsNjMsODcsMTYyLDE4NSwyMDcsMjQ3LDE0MCwxNzMsMTk0LDMxLDE3OCwxOCw5 Nyw1LDE1OCwyMzEsMjQ5LDc0LDE0LDQsNzUsNzAsNjEsNDAsNTYsMTk4LDk5LDI0MCwzMCwx MzQsMTQ2LDIxOCwxODAsNTMsMTY1LDI0MiwxMjksMjMxLDEyMywxODksMTUzLDcwLDEzLDE3 MSwxMCwxMjYsODksMTE5LDk5LDY0LDg1LDM1LDEzLDY2LDU0LDg2LDc2LDE5NCwxNDEsMTk1 LDI0OCwyMTEsMTgsMTQzLDUsMjQwLDE3MCw2Miw1MywyNDIsMTYyLDE4NSwxNjcsMTgyLDQy LDQ2LDkzLDgyLDE1OSwxNDAsNTEsMTMxLDUzLDE3OSwxMCwxMDIsMjM5LDEyLDExNywzOSwx NzgsNTEsNiwxMTEsMjU1LDgxLDE4MSwyNDYsMTE5LDIxNywyMTYsMTc5LDExNSwyOSwyNTMs NzgsMTQ2LDEwNyw0OCwxMzQsODIsODgsMjE1LDUwLDEzOCwxMTUsMywxNjksMTU0LDEzNCwz MiwxOTYsMTIyLDc2LDI1Myw0LDExNCwxMDQsMTI3LDEwNywxNjIsOTIsODQsMjMsMjQyLDQs MjE4LDE0MiwyNDksMTg5LDE3LDksOCwxODcsMTY3LDIzNywxMTIsMjI5LDYwLDM0LDE2OCw5 MCwyMTksNzIsMTE0LDIyOSwxMzQsODAsMTI5LDEwMywyMDgsMjQzLDE1MCwxNywyMDEsMTk1 LDQsMTIyLDEyOSwxNjEsMjUzLDMsMTc3LDE5OSw5NiwxMzUsNTgsMjgsMTQ2LDI0NSwyNDUs MTcyLDE5LDE0MCwxMjIsNDksMjYsMTQwLDE2Nyw1NywxMDUsMTEsMjA2LDIyMCwxNSwyNCwx ODksMTIyLDI1MCwyMTAsODgsMTQ4LDEyMywxMDMsMTI4LDExMSwzNSwxMjcsMTg2LDIzNSwx ODYsMTA3LDEyMSwxNzAsMjQ1LDc2LDU4LDczLDIxLDE2MCwxMTQsMjQ4LDI0MSwxNjMsMTMs MTM5LDExMywxOTUsMTkzLDI0NSwyNDIsMzIsMzAsNzcsMTQwLDE0MCwyMDUsMTg3LDE4Niwy MTAsNzUsMTQ4LDIzOSwxMTksNzEsOTksMTM1LDI0NiwyMDUsMjQ1LDI0OCwyNDAsMTc1LDIz NSwxMTAsMTEwLDQsMjAyLDEzNiwxOTUsMTQxLDI1NSwyMTAsMTcsMjIwLDMwLDM4LDEzMSw5 NCwyMiwxODQsMTAxLDEwOSwxMDIsMTk4LDUsMjA0LDI1MSwxNCwyMDUsMTY3LDI1NCw5OSwy NTIsMTg2LDE4MiwxMDAsMTE4LDI2LDI0MSwxNTcsMTQ1LDEsMTMyLDE5OCw2OCwxMzksMjUx LDEzMiw0OCwyNDUsNiwxMjksMjAsMjAyLDE4LDQ1LDUxLDQzLDE2NSw3MSwxMDAsMjI4LDIx OCwxNjgsNjcsOTAsNjcsMTg2LDM1LDc1LDE3NywxNTIsMTc2LDYwLDEzLDIzOCwxNDQsMTAz LDEwMCwxNDQsMTYxLDE4MCwyMTIsMjQwLDExLDU0LDIzNSwyMzAsMTk3LDUsNzksMTc4LDIz MSw0OCwyMjUsMTgyLDEyMiwxNSwyMzksNzksMTUxLDU2LDc5LDEzMywxMjYsNiwyMTYsMjI4 LDIyNSwxOTUsMzgsMTgsMTI2LDI1Miw5MiwyLDU3LDIwNiwyMTAsMjA0LDQ4LDIsOTUsNjAs MTQ4LDc1LDIyOCwxMDgsODYsMjA3LDQyLDE2NSwyNTIsMTUzLDU2LDE3NywxMSwyMTYsMjEx LDMzLDE0NiwxNDksMjAsMjE1LDI5LDE3LDE4NiwzNSwxMjAsMjIsMjgsMTEzLDIzOSwzNSwx MjEsNTYsMjUyLDE3MiwxOTMsMTcsNTIsODQsMTY5LDEwOCwxNjgsMTg2LDEwOCw4OCwyMyw0 OSwxLDE3LDIyOCwyMSwxODIsMjE3LDEzMCwxNTUsNDEsMTY5LDE0LDE5MCw5MywzNiwxNDQs MTQ2LDEsMjQ5LDEwOSwxNDYsMTMyLDk2LDU0LDI1NSwxMzIsMTE4LDU0LDI0LDgyLDQzLDEz MCw5MSwxMTAsMTYzLDE0NSwxMywyNyw3OSw3LDEwOCw1NywyMDEsMTk1LDk0LDMyLDIzNSwy MzQsMTAxLDEzNywyNTUsMjE2LDIsNTksMjM2LDIxMCwyNDksMjU1LDIzNSwxOSwxNzgsMTc5 LDE1Myw0NSw2OSwxNTgsNSwxNTQsMjQsOTgsMTQ0LDI1MywxOTcsMjA0LDE0NiwxNTAsOTAs MTksMTUyLDE2MSwxMjYsMjA5LDE1NCwxMiwyMDcsMTM4LDk5LDYsNjAsNDcsNTcsNDQsMTQw LDg2LDI4LDI1NCwyMzAsNzAsMTM0LDE0NiwxMzEsNDAsMjU0LDE2NiwxNjIsMTUzLDIyOCw5 Nyw3Myw4MSwxODksOTAsMTEwLDIyLDY2LDYsMjUsMjQ2LDEyMiwzMCwyMzYsMjA0LDgwLDIw NywxOTAsNjMsMzgsNDEsNjQsMTAsOTYsMTU4LDE0NSwxMDMsMTg2LDg1LDE5OCw5NCwyMjks NzAsMTUzLDkwLDkzLDIyLDIwMywzOCw5Miw0OCwyMDIsMTI1LDgxLDI0MCwyNDksMjIsMjA3 LDY1LDE4OCw1LDI1LDE5LDM2LDg3LDkzLDE4NiwxMTcsMzIsMjIwLDE0NCwxNTcsNzksMTMy LDIyMiwyMDcsMTAxLDIzMCwxMjMsOTAsNywxMDAsMzUsMjQ4LDEwNywxMSw1OSwyMDAsMzMs MTEwLDEyOCwyNTQsOTgsMTg3LDc1LDEwMywxNzMsODEsMiw5OSwzNCwyMzYsMTQ2LDkxLDEz NywxNDYsMjMzLDI0OSw1OCwxODIsMTEyLDQsMjM3LDYyLDU0LDM0LDE0LDY3LDE2MywxMjQs MTU4LDIzMSwyNDQsNzksMTM0LDUsNTcsMTQzLDExNCwxNDUsMTY1LDkyLDE1LDg3LDE0Miwx MDcsMjcsMjE3LDk0LDQzLDI2LDE2LDIyLDkxLDIyMiw4LDE1MCwxNDUsMTAxLDEwMCw5NSwy MjUsODMsMjMyLDg3LDE3MSwxOTYsODksNzAsMjQzLDc1LDM3LDI0LDIyNiw4Miw1NiwxNjgs NTcsNDYsMTUyLDk4LDU2LDI0MCwxMjYsMTA5LDI0NiwxMzEsMTIsNzMsNTgsMTgsMjIzLDg1 LDE1Miw2OCwxODAsODMsMTI3LDE4LDEyLDIzOCwxLDE5MCwyMTQsMTUwLDI3LDU5LDE2MCwx MCwyMTAsMTMsMTA3LDExMiwxMDIsMTIzLDgyLDI0MywxNCw4LDIwMywyMzksMTA4LDE5Miwy NDksMTEsMTMzLDE4NSwxNCwxMTksMTM1LDE4LDY3LDI0Miw2MiwyOCwxMjgsMTc5LDc2LDMw LDE1OCwzMSwyNiwxNzAsMTIzLDE0NCwxMjMsMTMwLDIzNCwyMzQsODMsMTgsMTc1LDE0NSwx MzksMTc3LDIyMiwxMzYsMTU5LDEzOCwxNzQsMTU4LDEwNiwxMzgsNzYsMTksODUsMTUyLDQz LDEzNCw4MSwyOSwyNDUsMjQ5LDQsMzMsMjEwLDM2LDIxMCwxMzYsNTQsMTEyLDQ1LDI0Nywx NjMsMjUxLDgxLDIxOCw3OSwxNjEsMTQsMzUsMTc2LDIxNywxMDksMjI3LDExLDQsMTY5LDMy LDI0MiwzOSwxNzMsMjU1LDIyNCwyMTcsMTkzLDIyLDEyMyw0NSwyMDUsMTM4LDU0LDI1LDE1 OSwyMzcsMTUwLDE2NSwyMDgsMTEyLDAsMCwxMywxMCwxLDczLDExMCwzMiwxMjcsMTc2LDI1 NSwyNTUsOTcsMzIsMTAwLDEwNSwxMDIsMTAyLDEwNSw5OSwxMTcsMTA4LDExNiwzMiwxMTks MTExLDExNCwxMDgsMTAwLDIxLDExMCw5NywxMDksMTAxLDEwOCwxMDEsMTkxLDIyMSw5Miwy NTEsMTE1LDExNSwzMiwxMTYsMTA1LDgsMTksMjgsOTcsMTEwLDMzLDExNiwxMTEsMzIsMTE1 LDExNywyNTQsMTExLDEyNywyNDcsMTE0LDExOCwxMDUsMTE4LDE4LDgzLDExMSw0NCwzMiwx MjEsMTExLDExNywyNCwxMDUsMTA4LDEwOCwzMiw5OCwxMDEsMzIsMTA5LDEwNSwxMTAsMTgz LDI0NiwyMTksMjM5LDIxLDQ1LDQ1LDMyLDY2LDk3LDEwMyw1NywzMiw2NSwxMTcsMTE2LDEw NCw3OSwzNCw1MCw1Nyw5NywxODMsMTExLDIzOCw0Niw0OCw1MiwyLDksNzEsMTAxLDExNCwx MDksNjgsMTIxLDQ2LDEyNSwxMTEsMjU1LDE4MywyMzksMTA2LDAsMSwyMzIsMTQyLDY0LDE0 NCwxNjMsMTA4LDE1Myw2NCwwLDEwNCwxNSw1Niw0LDI1NSw1Myw0LDIyMywyMzcsMjYsMjIz LDExMiw2NCwyMCwzMywxMzgsNSw1NCwxMDgsNCwyMiwxNzcsMTQ0LDEwNiwxMDAsMjE4LDI1 NCwyNTUsMTE5LDcsNjUsMTEwLDIzNSwyNDEsMjAxLDE5NSw4NSwxMzksMjM2LDg3LDI1NSwx MTcsOCw5NSwyMzUsOCw3MSwyNDYsOCwxMjgsMjM3LDExMCwyNTUsMTUxLDE3OSw1LDU5LDEy NSwxMiwxMTcsMjQzLDk1LDIwMSwxOTQsOCw2NiwxMDcsNzksNzEsMCwxNiwyNTEsMzIsMjIz LDE0Myw2NSw2NCw0MCwxMDQsMTQ3LDE2OCwxNCwxMTIsMTI5LDUsMTEzLDgwLDMwLDExMCwy MzcsMjU1LDEwMSwwLDAsMjMzLDE0OSwyNTQsMjM5LDI1NSwyMDQsMjU1LDM3LDIzNiw5Niwx NSw1LDQwLDk3LDI1LDI1LDI1LDEyMSwzNiwzMiwyOCwyNCwyNSwyNSwyNSwyNSwyMCwxNiwx Miw4LDI0MiwyOCwyNSwyNSw0LDAsMjUyLDk2LDI0OCw1MCw1MCw1MCw1MCwyNDQsMjQwLDIz MiwyMjgsNTAsNTAsNTAsNTAsMjI0LDE1Niw4NCw4OCw1MCw1MCw1MCw1MCw5Miw5NiwxMDAs MTA0LDUwLDUwLDUwLDUwLDEwOCwxMTIsMTE2LDEyMCw1Nyw1NCw1MCw1MCwxMjQsMTI4LDEz MiwxOTEsMTM2LDk2LDE1OCwyMDcsMjMxLDI0MywxNDAsOTYsMTQ0LDk2LDE0OCw5NiwxNTIs OTYsNDQsMjQ5LDEyNCw2Miw3MSwxNjAsOTYsMTY0LDk2LDE2OCw5NiwxNzIsOTYsMjAwLDIw MCwyMDAsMjQzLDE3Niw5NiwxODAsMTg0LDE4OCwyMDAsMjAwLDIwMCwyMDAsMTkyLDE5Niwy MDAsMjA0LDIwMSwyMDAsMjAwLDIwMCwyMDgsMjEyLDIxNiwyMjAsMTI0LDYyLDE1OSwyMjMs OTcsMTM3LDExMiw5NywxMDgsOTcsMTA0LDk3LDEwMCw5NywyMDAsMjE2LDIyOCwyNDksMTY4 LDk3LDE2NCw1LDE1NiwyMDAsMjAwLDIwMCwyMDAsMTgwLDE0OCwxNDQsMTQwLDIwMCwyMDAs MjAwLDIwMCwxNTIsMTc2LDE4NCwxNzIsMjAwLDIwMCwyMDAsMjAwLDE4OCw1Niw1Miw2NCwy MjUsMjAwLDIwMCwyMDAsNjgsODAsNzIsNzYsOTcsMjE3LDEwMCwxMDAsMTAwLDIyOCwxMjAs MTMyLDEyNCwxMjgsNTAsNTAsNTAsMTk0LDE1MSwyMCwxNiw4LDIyOCw1OSw5Nyw1MCwxMiwy MTcsOTYsNSwzMiwxMDAsMTAwLDEwMCwxMDAsMzYsNDAsNDQsNDgsMTAwLDEwMCwxMDAsMTAw LDUyLDU2LDYwLDY0LDk3LDEwMiwxMDAsMTAwLDY4LDcyLDc2LDAsMiwzNiw4NCw2NSwzNCwx NTQsMTY5LDE2MiwyNTAsMjksMTk1LDI1NCwyNDYsMjIzLDYyLDE2LDQsMTQwLDc5LDIwMywx OTUsMjA3LDIxMiwxLDIwMywyMDcsMjA0LDIxMiwyMDAsMjUwLDAsMTA5LDI1NSwyNTUsMjU1 LDE2OSwxODEsMTg4LDE3NCwxNzMsMTg3LDE2OCwxOTEsMTY2LDE3NCwxNDcsMTUxLDE1OSwy NTAsMTU4LDEzNiwxNDAsMTU4LDE1OCwxNTAsMTUwLDIxMiwxNTksMTMwLDExLDE2NiwyMTcs MjU1LDI1NSwxMjksMTIsMTgxLDE3NSwxNzQsMTcwLDE4MSwxNjksMTc0LDIxMiwxOTEsMTYy LDE5MSwyNTAsMTgwLDE4MywxODcsMTc5LDE4MCw5LDI1NCwyNTUsMjIzLDI1NCwxODEsMTY4 LDE3NCwxODEsMTgwLDE2NSwxMywxNzQsMTkxLDE2OCwxODAsMTkxLDE3NCwxNjUsMTY5LDE5 MSwxODUsMTc1LDE2NSwyMDEsMjEyLDIwMiwxNjUsMjA2LDIwMiwyMDUsMjIzLDE5MCwxMDks MjA3LDMyLDE3MCwxODgsMTAsMTY1LDk2LDE2NSwxOTUsMTk0LDE2NSwzNiwxNjUsMTgzLDE5 MSwxNjUsMTA3LDE4MywxMDksMjE2LDIwMCwxNzcsMjQsMTIsMTY5LDQ3LDE4MCwxODksNTcs MTYsMjQ5LDIwNywxMTAsNywxNjgsMTgxLDY5LDE4NSwxNzQsMTIsMTY5LDE4NSwxNzgsMTkx LDE5MCwyMDEsMjAwLDExOCwxMDcsMTAzLDYzLDE3NCwxNzIsMTkwLDE4Myw5LDE3MiwxNjgs MjQsMjAzLDIwNCwxMiwxODEsMjQ2LDI1NSw1NCwxNzcsNTYsMTc5LDE4MSwyMTUsMTczLDE2 OCwxNzAsMjE1LDIwNiwyMDAsMjAzLDIxNSw3MiwxMCwxODksMTg1LDIzOCwxMzEsMTQ4LDE3 NywxNzksMTgyLDE4Miw3NiwxODUsOTQsOTUsMTc0LDE3NSwxNzAsMTgzLDE1Myw1OSwxODIs NDcsMjAzLDIzLDE4MiwxOTAsMjEsOSwyOCwxODcsMTgyLDM5LDIyOCwxNSwxMTUsMTc1LDEy LDE3NywxOTAsMTgxLDE3MywxODAsMjAwLDIwMiwxMjUsNDQsNTQsMTA3LDAsMTYsNjYsMTAs MTg1LDE4MiwxOTEsMTg3LDM1LDI1Miw2MywxODIsMTY1LDE4NSwxMSwxODcsMTcyLDEzOCwx MzYsMTQ5LDE0MiwxNTksMTUzLDE0MiwxOTUsMTMwLDMwLDE4NSwyMTYsMTk0LDg5LDI1MSwx ODMsMTg5LDE2OCwxOTAsMTc5LDMwLDQwLDE4MywxOSwyMDIsMTY1LDIyOCwxMDAsMjM3LDU0 LDE4NSwyMzEsMTk1LDE2Miw3NywxMiwxODAsMTc0LDE1LDI1MSw1NCwxNTUsMTcyLDYsMTA4 LDE4NCwyMDMsMTk0LDIwMywxMSwxNzQsMTkwLDIwNywxMTAsMjM3LDIxNywxNzMsMTgzLDE2 NCwxNzksMTg1LDE5MCwxMjEsMTcwLDE4MCwxNjUsMTkwLDE5MSwxMSwxMzEsMTgxLDEzMywx ODgsMTY1LDE3NCwyNTIsMTIsMTcwLDE0MiwxNjMsNDcsMjcsMjE0LDEwMiwxMCw4Miw3LDE2 OSwxOTAsMTY4LDY2LDk3LDg2LDExMiw0MywyMTYsMTQxLDI1LDgzLDE1OSw1NywxODIsMTE0 LDE5MSwxNTksMTc4LDEsMTkxLDE2MiwxNzEsMTc1LDI4LDg4LDE5MiwxMCw3NiwyNCwzNywx NzIsMTkxLDE1NywyMjEsMTQ2LDEwMywxNzAsMTkwLDIzLDE2MiwyMiwxNzQsMTc5LDE3Miwx NzksMTY4LDQ1LDIxNiwxMzUsMjQwLDE3NSwxNjksMjE1LDE4NSw1OCwxODgsMTg3LDE2OSw4 LDIzLDE3Niw0OCw0MywxODAsMTkxLDExNCwxMTgsMTIsNjgsMTczLDU2LDE1Niw1MywxMzAs MjA0LDMwLDE3LDE3MCwxNTYsODksMTEsMTgyLDIwOCw2LDE3NiwxODcsMzQsMTYwLDcsMTQ2 LDE3NiwyMDUsMjE4LDE2OSw5OCwxMDUsMjA3LDE4MSwxMzIsMjI4LDE5MiwyMjIsMjU0LDIx LDIwNywyMDEsMjAyLDkxLDE4NCwxNjMsMTg0LDE2LDE3Myw5NiwyMTksMTMxLDM3LDE2Mywx ODksMTg0LDE4MywyMjUsMTc1LDEwLDEwMSwyMjEsOTYsMTQxLDE2MiwxMzEsMTg5LDIyMCwx OTAsOSwyMTQsMjAyLDE3LDE4Miw5MCwxODksMjIyLDE3OCwxODcsMTMzLDQsMTM0LDEyNSw5 LDE0MSw1OCw0NCwxNzgsMTc0LDE4MiwyOSw0Myw1Miw3OCwyMTYsMTgyLDE5MSwxMjIsMTg3 LDIyNSwxMjEsMTAsMTE4LDEyMCw5MSwwLDUzLDE2OCwxNzUsMTU2LDUyLDE5NSwyMjgsMTAw LDIzOSwxODcsMTkwLDEzMCwxMiwxODAsMTc0LDI1Myw2NiwxNzgsNjcsMTc2LDksMTkxLDM1 LDIwNCwxMTgsNTAsMTAsMywxNzksMjAzLDk2LDE3OSwxNzAsMTU5LDE0MCw0NSw3NiwxODIs NDksMTY4LDMyLDE2OSwxMDYsMTc2LDUxLDIwLDEwMiwxNzMsMjEzLDE5LDIwMCwxMzAsNCw5 NywxOTgsMTA4LDg4LDEzLDEyLDIzMSwzLDE5NSw3NiwxNjUsMTE4LDE4MiwxNzksMTEsOTUs NjgsMTYsMjcsMTQ3LDE1MCwxODUsMTcwLDIxNywxNiwzNCwyNSwyMTUsNDYsMTA1LDczLDc1 LDMyLDIwMSwzMyw1OCwxODIsMjM3LDIxNywyMzcsNzIsMTg0LDEzNiwxODksMjAwLDksMTY5 LDIwMywxNjIsMjE5LDE0LDE5OCwyNSwxNDgsMTkwLDI1NCwxODgsMTg5LDM4LDE2MCwxMCwx MSw4Niw0Miw0LDExLDE0Niw1MSwxMiw5MSwxNTAsMTMyLDI0NiwxNzUsMTkwLDEzNiwxOTks MTYyLDI3LDEwNSwxNjEsMjksMTk4LDQzLDE4MCwxNTYsNzIsMTczLDIxMCwyMTksMTQsOTEs MTQsMTg3LDE2Miw5LDE2OSwyMjUsMTg0LDExLDQ1LDksMTQ3LDEzLDMyLDE4NSwzMiwxMCwx MzksMTQ0LDEwOCwxMDcsNjcsMzQsMjA2LDk0LDE5MSwyNSw3MCwxOTUsMjAxLDU4LDE5MCwz NCwxOTEsMTgxLDExNywxNzksMTExLDE1NSw5MSwxMzAsMjcsMTE1LDg0LDEyLDY0LDE4OCwz MCwxOTUsMjIwLDE3NiwxODEsMTEsMzksMTAsMjM0LDIzMywyMzUsMjIzLDE3NiwxOCwxNCwx NzAsMTYzLDE3OCwxNzUsMjAxLDIxNSwxNDEsNjYsMTc2LDE1MCwxMDgsMjAwLDIwLDczLDE5 MSwxNTQsMTc1LDEwOCwxNTEsMTMyLDI1MywxMSwxNzUsMTgzLDI1MiwxODIsMTc1LDE1NSwx NCwyMjUsMTgxLDE4NSwxMzQsMzYsMTcyLDE4OSwxMjMsMTY5LDE3MiwxNzIsMjIxLDE1OCwx MDIsMTIsNjIsMjE1LDE4NywxODEsMTc2LDgsMTUsMjE2LDE3Niw3Miw0MSw5NCwxMyw4LDkw LDIyNSw0NSw1OSwxNzAsMTc5LDIxNywxNCwyNDIsMTgxLDEzLDk3LDIwMSwyMDUsMjQ1LDEy LDE5NywxOTAsMTg2LDIzOCw1MCwxMzQsMTE3LDI4LDE4MSw5LDI1MywxODcsOTcsMjE3LDE0 Niw1MywyMzYsMjA3LDIwNywxOTEsMjQsNjYsNDYsMTcyLDIxNiw1NSwyMTYsMTUwLDM0LDE4 MiwxMiwxODksMTgyLDE5NSwxMiwzLDIwNywxMTIsNjEsMTY5LDE2MywxODAsMjA2LDYsMTkw LDE2NSw3NCwyMTUsNjUsMTA2LDc3LDE4OCwxNzksNDYsMTg4LDE4NCwxNzksMTQwLDE3Mywx MTAsMjE3LDQ4LDksMjM4LDEzLDE3MCwyMjQsNDUsMTI5LDE5NCwxMDEsOSwxOTEsMjM5LDYw LDE1MCw1MywxMywyMTQsMTgsMTY5LDgsMTgyLDEzMSwxOTAsMTAsMjI1LDEzMSwxOTMsMjE2 LDIwNiwxOTEsMTIyLDE4MSwxMzUsMTgwLDI0Myw2NCw0Myw0Nyw1NywxNzMsMTgwLDE3Mywx NjcsMTk1LDEwNCwxNCwxMzAsNzgsMTMwLDE0Miw4MiwxMDgsMjE0LDExLDYsMTQ3LDQyLDEy MywxOCwyMDMsNTYsNDgsMTUxLDE3OSwyMSwxNzAsMTczLDE5MiwxMTAsMTQ0LDExMSwxMCwx ODAsMTc5LDE2MiwxNzcsMTcyLDM5LDE2MiwxNjMsMjA5LDEwMiwxODEsMTM1LDUwLDE5MSwx ODQsMTcxLDE1MCwxODksMjUxLDE1OSwxNzIsMjUzLDEyNiwyMDAsMTY5LDE5NSwzLDE1LDE3 NywxNjUsMjA1LDIwNCwxNjUsMjAzLDIwNiwyMDEsMjA0LDE3LDEwMSwxMzEsNjEsMTQsMTc5 LDExNCwxMiwxOTAsMjMyLDk2LDEzNSw3LDE4MiwxMiwxODgsOSwxNzksMTQxLDE1LDIxNyw1 NSw4OCw4OCwyOCwyMDMsMjksMjAzLDIwNSwxNjUsMjAyLDE1LDE3MiwyMTQsNTIsMTc2LDU5 LDE1MSwxNjksNDAsMTMzLDE1NCwxMywyNDYsMjAsMjAzLDE4OCwxNDQsMTg4LDEzNiwxMDEs MTEwLDE0NiwxMDQsMjQxLDE3NCwxMjQsMTcwLDg4LDIxNSw5MSwxNTIsNjEsMTgyLDcsMTg5 LDIwNywxMiw4OCwxNzQsMjMsNDQsMTE1LDIwMywxNCwxODEsMjI3LDExLDM0LDUzLDE0LDIw LDc2LDE4NSwxOTgsMTYzLDExNyw0OSwxOTMsMjI4LDEzMCwxMTAsNjYsMTg2LDkwLDExLDE4 NCw3LDU1LDI1MCwxMzcsMTMxLDEzNywyMTgsMjMsMTE4LDE4NSw2OCwxNzYsMTY2LDk2LDMz LDE3MSwxODEsMTcwLDE4Miw0NCwxODEsMjQ2LDk2LDE2MiwxMDQsNzAsNDcsMTcyLDIwMiwy MCw3MywxMTEsMjE2LDI3LDg3LDExLDkzLDIyOSwyMDgsNTYsMjQsMTgwLDExOSwxNjYsMTcz LDE4OSw3NSw0Niw3MCwyMjUsMzIsMTcsMTczLDE3OCwxNjgsMTQzLDE4NSwxMzQsMjI4LDc2 LDE3OSwxODMsMTMwLDI1NSwxMjksMjExLDE0MCwxNzYsMTczLDIwOSwxMCwxMzIsMjI0LDE5 MSw0NCwxNTMsMjQsNjYsMTE1LDM0LDEyMyw4NSw1NiwxNzEsMTgxLDM3LDE1Niw3LDE2OCwx OCwxMSwxMjYsMjI2LDE0MiwxMzUsMjQ1LDg5LDEwLDE2OSwxODQsMTg5LDE0NywxNzMsMTYz LDE3Niw3NiwyNCwyMjAsMjYsODQsMTY3LDE3NywxNjksMTgyLDE2MiwxODUsMTMxLDg0LDQ4 LDEwMCwyMzksNDIsMTYwLDE4NywxOTEsMTMzLDYsMTcsMTM0LDksMTYwLDEyNiwxODAsMjAz LDU4LDE4MSw5NiwxNiwxMywxNDIsMjIzLDEwNSwyMTcsNDQsMTAyLDE3NiwzMSw5LDIxLDM0 LDEwMSwxMTMsMjE3LDExLDIwMSw2NiwzNiwxOCwyNCwyMDAsNTAsMTkwLDExMiw0Myw4LDUs NzQsMTQ3LDE2NCwxNzgsNDgsNTQsMTA1LDE2LDkwLDE5MSw3OCwxNzEsMjA3LDI0LDE5NSwx MzMsMTI4LDExNiwxNzEsMTUwLDE3LDE3MiwxOTQsNDMsMTA5LDEwOSwyNCw1MiwxNjQsMjEs MjQzLDYyLDE5MCw0LDEzNCwyNDUsMTM0LDE4MCwxMiwxOTEsMTg0LDU0LDE3Niw0Niw2LDE2 OCw3LDE3NSwxMCw0Niw2NiwxNDEsMTAxLDI5LDE2OCw5MSwxNTcsMTYzLDIxNiwxODIsMTYs MTMyLDU5LDI0MywxNzIsMzYsMTgwLDEzNyw4NiwxMjksNzAsNDMsMTk1LDEyNiw3MSwxMDMs MTAyLDQyLDE0OCw4LDE2OCwyNDAsODksMTEsMTcsMTAyLDE3OSwxMTksMTg0LDE1MCwxMCw2 Niw4OSw1NCwxMjksOSwxMzksMTY1LDQ4LDE2NSwxLDI2LDEwMywxNzUsNjYsMTA3LDY2LDIz Niw3MSwxNywxODgsMTMxLDE1MywyNiwxNzksMTg1LDcsMjMyLDIzLDE0NCwxNjksMTQ2LDEy LDE4OCw5NiwxMDIsMTM4LDE5MiwyNDUsMTczLDMyLDEwMywyMjMsMTksMTgwLDU1LDE4Mywx OTksMTEyLDE4NCwyNSwxNzksMTc5LDgsMTQwLDcsNzgsMTgsMTQsMjE0LDIwNSwxNjAsNTgs MTYyLDksMTY5LDIwMSwxNiwxMDIsMTA4LDE5Myw5MCw3NSwxMDAsMTM3LDE4OCw3NCwxMjMs MTgwLDEwMCw3LDIyOCw5NSwyMSwyMzcsMjEwLDIxLDEzNiwyNDQsMTAwLDIwNywxNjMsMTgz LDEwNiwyNDAsMTE3LDc1LDIxNCwxMzAsMTEwLDksNzIsMTQ3LDE2OSwxNzcsMzYsNSwyMzYs MTU1LDQ1LDExLDE3NSwxMCwxNDQsNTAsMjE2LDk2LDE0MSwyMTksNiwxODcsNywxODMsNDcs NDMsMTE3LDEwNywzMCwyMDAsMjE1LDYwLDExLDE4MCwxNzQsMTgyLDIwOCwyMzYsMzMsMjE1 LDIwMSw5LDEzMywxNzcsMTI5LDE1NSw0NSw4MCw5NiwyNDcsNjgsMTg0LDksMTE5LDM4LDI5 LDg4LDg3LDIzMSwxODAsMTEsMTYyLDE4Myw5MSwyNDIsMjM2LDQ0LDI1MywxNzQsMTI2LDE2 OCwxNzYsMTEsMTE3LDUxLDcyLDE1MCwxMzUsMTUwLDQyLDE3MCwyOSw0MCw4NCwxNTIsOTgs MjA1LDY0LDE1OSwyMjAsMTgsMTA2LDE0MSwxMiwxNzIsMTMsNywxMiwyNCwyMTQsMTMwLDU3 LDExOCwxMCwyMDQsMzMsMTcxLDQ1LDEwNywyMjgsMTExLDI0NSwxMSw3NCwxOTgsMjAwLDE1 MCwxNzIsNDgsMjUsOTksMTEsMTg4LDE1LDk0LDYzLDgsMjQ3LDE4MywxOTAsMjQwLDEwMSwx MDIsMTA2LDc5LDcyLDE1MCwxNzIsMTgwLDE4MiwxMzgsMTI0LDEyLDEwNCwxOTMsMTU2LDEw NSw2MCwxMSwxMiwxMSwyNiw1NywxMzAsMTgxLDE5MCw5LDE1LDQ3LDExNCwyMDQsMTE0LDE5 MywxMSwxODMsMjM5LDE0NywxNzIsODUsNDIsNTcsMjYsODQsMjEzLDgzLDUwLDI2LDE3Miwx MzcsMjIsMTE1LDE2MiwxNjgsMTEsMTc4LDQ4LDk2LDEzMSw2OSwyMiwxMiwxNzksMTQyLDE2 OSwyMiwxOTUsMTg2LDM2LDk5LDEwLDE4MSw5LDEwLDE5NiwxNzgsMTQ1LDExMSwyMjMsMTY5 LDE5MSwxMiwxOTksMjM2LDUsMjA0LDE3MywxMywxOTksMTQsMTY1LDQzLDgsMTc5LDkxLDE5 MCw2NSwxOTQsMTk1LDEyLDE4LDE5OSwxNSwxNjYsOTcsMjAsMTQ1LDI3LDEzMSwxNjIsNzAs MTc5LDg2LDIyLDc3LDkxLDczLDE3NiwzOCw1Myw4NiwyMDUsMTY3LDEyOCwyMjIsMjE3LDI2 LDM1LDE3Niw3MSwxNzksNTgsMjgsOTMsODksNDQsMTQ2LDcwLDE4MywxNDQsMTI4LDkyLDEy MCwxNzksMjQ5LDEwLDUyLDE4OSwyMDEsNDEsNTUsMTA3LDE3MywxNjcsNjUsOCw3Miw0Mywy NCw2LDM4LDE0LDE4MywxNDcsNTcsMjgsMTQxLDg5LDkxLDgwLDE4OCwxMDAsMTkzLDI1LDE1 LDIwNSwxNCwxMywyMTQsMTQ3LDM1LDE2OSwxMjAsMTU2LDIyNiwxOTUsOTAsMTkzLDEyLDgs MTE1LDEyLDE3NSwyMDIsMjAxLDE5NCw2NywxNjgsODUsMiwyMTAsMjQ2LDE5NCwyMDIsMTgw LDU2LDIzMywxMzAsMTkyLDE2Myw5MywxNzQsMTY5LDE2MCw1MSw0OSw0LDI1NCwxMiwxODMs MjAwLDIwNCwxMjAsMjQ4LDE1LDIxOSwyNTUsMjAwLDg2LDEyNSwxODMsMjUwLDE0NiwxNDIs MTQyLDEzOCwxOTIsMjEzLDIxMywxNDEsMCwyMTIsMywxMjMsMjI1LDI1NSwxMzcsMTM4LDE0 NywxNTksMTU3LDE1OSwxNTAsMjEyLDE1OCwxNTksMjEzLDM1LDEzOCwxNDYsMTM4LDI3LDE5 LDIxNiwxOTEsMjUzLDE1MCwxNTksMTQ3LDEzOCwxMjgsMTQ3LDI5LDEzNiwyMTUsMTUxLDE1 OSwxMzcsMTM3LDE1OSwzNSwxNTEsOTYsMjU1LDUsMjQ2LDE0OSwxNTIsMTQ3LDE1MCwyNiwx NDgsMTU5LDE1NiwxNDksMTM2LDE1MSwxNTUsOTEsMjAwLDc5LDk2LDk1LDE1NSwxNDAsMTQ2 LDc5LDE1NywxNDksMTU5LDE0MiwxNDYsMTI5LDE4MSwyMjMsMjIsMTksMTU3LDEzNiwxNDMs MTMxLDE0MiwxNDIsMTcyLDI1MSwxMzUsMTc2LDUwLDE0NiwxNjIsMTU1LDE0MywxNDIsMTQ5 LDEzNywxNTMsMTQ5LDUsMTczLDE4MSw0LDExOCwyMDAsMjA2LDMxLDg0LDIyMCw1OSwxOSwy MTYsMjIxLDE4MywxNTMsNjQsMjE1LDE1MiwxNDksMTQyLDcsMTU1LDE1NiwxNDIsMzksMTUy LDEzMiwxMTEsMTEsMjM2LDE1MSwxNTIsMTU2LDI0LDE0NiwxNTAsMTQ3LDE0OCwxNTUsNiw0 Myw5MiwxMDQsMzMsNzksMywxNDgsMTQ4LDY2LDkxLDQzLDEwNywxMzMsNjYsMTMsMTA5LDMs OTIsMTA3LDM5LDE3NiwyNTUsMTY5LDEzOCwxNTUsMTUzLDE1OSwxNTMsMTUwLDE0MywxNTIs NjMsMTU2LDEzNiwyOSwxNCwxODIsMjQ2LDMzLDEwOCwyMTUsMTg4LDE1MCwxNDksMTQwLDE1 OSw2MiwzNCwxNTgsNjksMTg3LDEzMywxNiw1MSwxNDksMTQ4LDE0OSwyMTQsMjQ2LDEzLDMz LDE4OCwxNDMsMTQ2LDE0NywxNDUsODQsMTQzLDI0MywxNTAsMTYyLDI0MCwyMzgsNSwxOTQs MTU4LDYwLDE1MywyMTUsMzAsMTQ4LDE0NywxNDIsMTI4LDE4MiwyMDksNjIsMTI4LDExOSwx NTUsMTUyLDE1NSwxNDUsNTYsNjcsMTQyLDEyNywxNzYsMTk0LDksMjI4LDE0OCwxNTUsMTU5 LDE1MSw4OSwxMTksMTYxLDE4OSwxOTIsNDYsMTQxLDExMSwxNDcsMTU2LDIxLDE0MSwxMDks NTksMTMyLDExMiwxNTcsMTQ4LDEwNCwxNTMsMTQ1LDEzNCwxMzcsMTQ1LDI1NCwxMSwxNzIs MTA5LDIwNywxNDIsODksODgsMTM4LDEzNiwxNDcsMjE1LDE0MSwxNDksMjE1LDI0Miw4Mywx OTQsMjcsMTE3LDE1MiwxNDMsMTM2LDE1NywyMCwxNDAsMTQ3LDEzNiwxNDIsMTQzLDIxOCw0 NSwxMzIsMjQxLDEyOCwxNDksMTQ4LDIwNywyMzMsMTM3LDE0Myw0LDE0MCw5LDQ3LDE2LDEz NywxNDMsMjE1LDIzNCwyMzgsNDUsMTI5LDE4MSwxMSwxNTUsMTEyLDI0LDE3MCwyMTAsMTE4 LDEyOSwxMDksMTgwLDE1MCw4MSwxNDEsMjQsMTQyLDYsMTg3LDEwOSwxNDEsMTYsNDIsMjcs MjE1LDgzLDE0MiwxNDcsMTY5LDIzNywxMDksOCwxMDUsMTM3LDk0LDEyOCwzMCwxNDUsMTQ5 LDE1MSw2LDIxMiwxMTIsMTIsOTcsMTE3LDE1MywyMDIsMTIwLDE2NSwxOTQsNDYsMTMyLDIx OSwxNCwyMTUsMTM2LDEwNSwyMSw3MCw5MSw5NiwxNDEsMTM2LDEyMiwxNTQsMjMwLDYwLDEy OSwyMSwyMiwyMTYsMTUzLDE1NiwxNjAsMTE0LDU0LDEwMSwxMSwxMDksNzYsMjM3LDE1MSwy NiwxNDQsMTY1LDEyOSw1MywyMjAsMTk4LDE0NywyNTMsMTQwLDIxMSwxNzIsMjAyLDU0LDk3 LDU5LDk3LDEyMCwxMzYsMjA0LDIxNSwyMjUsNDIsNDUsMTcyLDQsMjQ3LDE1MSwxMzAsMTQ2 LDIxNywxODksMjA4LDEzMCwxOTQsMTYsMTMwLDQzLDcwLDIxMiw1MiwyMTUsMjQ1LDgyLDU5 LDEwMSwxNjYsMTA4LDI4LDIwMSwxNDIsMjM0LDM3LDg2LDIxNCwyMiwyMTgsMTQ5LDIwOSwx MDgsMTUzLDg2LDU2LDE3Niw0NSwxNDgsMjYsOCwxNDIsNjcsNDksMTU4LDYzLDE1MCwxMzMs Myw4LDE3MywxNjksNjQsMTgsMjAwLDE0MywxMywxMSwxMzIsMTA5LDEwNywxNTEsMjgsMTU3 LDIwNCwxNDAsMjU1LDAsMTUyLDE1OCwxMCwxNzYsMTY4LDIxNSwzOSwyLDE2Myw4MCwxMDYs MTU0LDEwOSwxODUsMjQ3LDU1LDE5OSw0LDI0MiwxNTYsMTU3LDE0NSw4Niw1MiwxNTksMTQ4 LDUwLDUyLDcwLDgsMTM5LDEyMyw5Myw4LDIzNSwxNDUsMTk0LDk2LDIzNCwyNTEsOCwzMywx NDAsNjYsMTUsMzAsMjIwLDg2LDQyLDE4MCw2NiwxNSwxMTksMiwxODksMjAyLDEwLDIzOCwx NywxNDksMTUzLDMwLDcwLDgzLDQ2LDc1LDE2NSwyMTksMTMyLDEzNiwxNTgsOTEsMTg1LDE0 OSwxMzYsMTQzLDIxMSwxMzUsMjIsNjQsMjAsMjE3LDIxNSwxNDksMTg0LDkyLDMyLDE4MSw1 NCwxNzEsMTQ5LDE3NywxMjQsMTQ1LDkyLDE5OSw2LDksMzgsNzEsMTQzLDE0OCwzMSw4Nywy MTQsMTAsMjMsOCwxNTcsMTQ3LDEwMiwxMCwyNDMsMTU4LDEyOCwxODEsMTgxLDE0MiwxNDcs MjQ3LDIxMiwxNjMsMTk4LDEzNyw5MSwyNiw1Niw4Myw0MSw3Myw4MywxMzcsMjEwLDgsMzMs MTQ5LDUsMTQzLDE0NiwyNiwxNjcsODYsNDMsODAsMTkwLDEzNiw5MSw2OSw2MSwxMSwzMywx MiwyNiwxODIsMTEwLDIzMywxNDMsNDAsOTIsOTYsMjcsMTAsMTQ3LDE2MywxNTAsMTE3LDk5 LDEzMiwxODAsMTUzLDUxLDk5LDE1NywxMjMsMTA3LDQxLDIxNywxMiwxNzQsMTQ4LDMzLDIx MywyMzEsMTUxLDEzLDIxNSw3NCwyMjQsMTUxLDE0NiwxNDAsMjM2LDE4NCwxNTQsMTQ5LDk2 LDIzMiw3Niw3MiwyNTQsMTM2LDQsMjksMTgwLDIxOCwxODIsMTk3LDEzNywyMSwxOTQsMjQ1 LDE0MCwxNzksMjE4LDEyOSwxLDIxNCwxMCwzMSwzNSwxODMsMjI3LDk3LDE2MiwxMzcsMTQ2 LDEzNiwzOCwxMzcsMjE2LDEwOCwxOTUsMTk2LDE0OSwxMDQsMTQyLDIwMSw0NCwxMzEsNTUs NDAsODEsMTA2LDEsMjEsMTU0LDM1LDcwLDgsMjAzLDgwLDExNCwyNDksMTA4LDIzOSw4LDIz MywxOTQsMjQ2LDEyOCwyMTUsMTQ1LDM3LDE1MCwxNTMsMTQzLDE0NiwxNTUsMTAyLDkwLDMy LDExMywxNTgsMTUzLDI0MCwxNDgsMTE0LDE3NiwxOTIsMTUwLDE4Miw5NywxNDIsMjQyLDE1 MiwzMiwyMTMsMjQ0LDIwOSwxNDIsMTY4LDIxNSwxMzgsMTIzLDkyLDIxNSwxMDEsMTU5LDE1 MCwyMTksMjYsMTMzLDIzLDExOCwxNDEsNTUsOTUsMTY2LDUsMTgsMTQxLDI3LDI1NSwyNDcs MTQwLDEwOSwxMjksMTgxLDE1OCwxMDAsMjE2LDE1NSwxNDgsMTEsNjYsOCwxMSwxOTksNTEs NjEsNzcsOTIsMTMxLDM2LDIxOCwxNDIsMjUxLDkyLDg1LDE3Niw4OSwxODMsMTMsMTc5LDE1 NiwxMDIsMTUxLDE1OCwzNSwxNjUsMjEwLDg2LDIyNCw0NSwxMDIsMzMsMjUsMTQ4LDIwNCwx OSw2LDIxOCw0LDE1NiwxNjAsNjAsMTM4LDUzLDUzLDI4LDEzMywxODcsMiwxMDAsMTExLDEz NywxMzMsODIsMTA1LDE0NCwxMTYsMCw3NSwxODAsMTA4LDI3LDE5NCw3NiwyMDUsMzYsMjE1 LDEwMiwxNTcsMTM1LDE2MywyMDgsNzQsNDEsMTY1LDY3LDE0NSwxNjYsNjYsMzUsMTMyLDEz MiwyMTIsMjI2LDE3LDkxLDk2LDM4LDE5MCwxMzUsMTUwLDE1LDY5LDIzNSw2Niw5OCwxNjEs MTA1LDEyOCwyMDMsMTM3LDI0LDE0MywxMDIsMTgyLDIyOCwxNjIsMTc3LDExMSwxNTAsMzks MTQwLDE5OSw1LDc4LDEzMyw1LDIzOCwxNjcsMTQxLDk1LDMyLDIyNCwxMCw2MSw0MCwxODMs MTUzLDE0NywxNTMsMTk2LDQsMTQ2LDE2MSwxNDAsMzEsOTcsMTQ5LDEwNCwxODIsNDgsMTMy LDE5NiwxNDQsOTMsMTU1LDIyNywxNjUsMTgyLDE4OCw2NCwxMTAsMTU5LDEzMCwxNDIsMTE0 LDQxLDI1NCw3NSwxODIsOTAsMjM0LDE2NiwxMzEsMjUwLDIyMywxMzcsMTk3LDEzOCwxOTks MjIzLDEwNCwxODgsMTgxLDEzMywxNjUsMjIwLDI0Nyw2LDEzNywyNTAsMTg3LDc4LDE4Miwy MDksMTAyLDkwLDIxNCwyNTAsNDksMTY0LDIxMywyNSwxMzgsOSwxMTAsNyw5MSwxMCwzNiwx NTYsOSwxNDQsMTM4LDE5MCwyNTAsMTU3LDE1NiwxMDksOTMsMjE5LDcwLDEzOCw0OSwyMjMs MTUwLDQyLDE4OSwxMSwxNjksMTk4LDg2LDE3OCwzMSwxMDUsMTQzLDEzOCwxNCw3MSwxNDIs MTI0LDIxOCwxMTEsOTksMjM2LDE0MSwxNDgsMTUsMTg5LDczLDE3OSw2MCwxOTEsMTQ4LDEy Myw5LDEwOCwxNjksMjUsMjI4LDI4LDg2LDE1OSwyNCwyMjEsODgsMTYxLDk5LDIwLDE4Miwx NDksMjQ1LDIxLDE4OCwyMzYsMTY5LDI0OSw4OCwzLDcsMjI2LDcsMjMsMTY5LDE1NSwxNDAs MTU5LDYsMTU4LDE4MSwzMCwxNzQsMTQ5LDE4OCw1Miw2NCwxOTAsMTQ3LDgzLDE4NSwyLDEx MCwxNzksMTM3LDIyLDIwMiwxODMsMTYwLDE1Niw1LDM4LDEwLDE3OSwzLDI0OCw5NiwxOTQs MjU0LDE3OCw4LDEzNSw3LDc4LDE4Miw1NSwyMTksMjUwLDAsMjE2LDIxOSwyMjksMjMsMzUs MTcwLDE5MSwxODIsMjUxLDYxLDIzLDU5LDEwNiw1MCwyNDcsMTU1LDI1MywxMjcsMjUwLDI2 LDI1MCwyNDQsMjE5LDI0MSwyNTEsMjU1LDI0NiwyNTAsMjUyLDg4LDAsMjM0LDIzNSw0LDE3 OSwyMzksMjA1LDE4NiwzLDIxOCwxNCwxMSwyNywyNTQsMzAsMTEwLDE4MiwyMzYsMTAwLDcs MjUwLDIwMiw1MSw2LDQwLDI1LDc1LDU0LDE3NiwyMzQsNyw2LDEyLDIzOCwyMzYsMTI0LDM1 LDE3MiwxOTgsMTYwLDIsMjE4LDAsMTM3LDY5LDI0Niw0MiwxMzgsMjM0LDU1LDUzLDEyNSwx OTMsMTkwLDE1MCwxMDIsMjM1LDI1NSwxNDQsMTcyLDI0OCwxODIsNDUsMjE1LDE0OCwxMjIs MjYsODIsMTE1LDE1MywxNiwyMTAsNTksMzcsMTU2LDc3LDM1LDI1NCw3MSwxODQsMjUwLDAs MTU0LDI2LDEzNSw0MCwxNjYsMTUzLDEyMiwyMjYsMTUyLDIxNyw5NiwyMjQsNDMsMTY0LDE0 OSw5MCwxMSwxNzAsMjM0LDIzOCwxNDYsMzksNDcsMzgsMjM0LDE0NiwyMzQsMCwxNSwxMDIs NTcsMTAxLDE0NywxMTQsMywxMDYsMjM0LDEwMCw2NCwxNTgsMTA5LDE1NCw4Niw2Miw0Miwy MzQsMzEsMTYsMjM0LDE5NSw2NSwxOTksNDcsMjI3LDI1MCwxODUsMTUwLDE1NywxNzgsMTYw LDE3NSwxMjcsMjAsMjgsMTczLDIwMCwxMywyMDMsMTA2LDE4OCwxODcsMjUwLDE1OCwxOTgs MTQ2LDEzMSwxNDIsMjUxLDI1MiwxNzMsMjQ3LDM2LDEzNywxOTcsMjEwLDE4Myw0NiwxODIs MjQsMTUzLDMxLDEzMSwyMiwyNTAsNjcsMjQ4LDE3MywxMjksMTgxLDcwLDIzOCwxNzksMzYs MjUwLDQxLDI0OCwyMDYsMjAwLDUxLDQyLDY1LDMsMjA4LDIzLDE3Nyw3OCwxODIsNDQsMTA5 LDIxOSw4MiwxMjMsMTE1LDI1MCwyMTcsOTYsMTU5LDgsMTkxLDIzMSwxNTMsNTQsMTIzLDEz Miw0MywxMDMsNzcsMjM2LDI4LDE5MCwxOTIsMjU1LDEwLDg4LDE1NCwxMzUsMjQ2LDI1MSwx NDMsMTg4LDEwNiwyMzMsMTIwLDIyNyw4MywxMDAsMTQ2LDI2LDE4MywyMzQsMTgsOTcsMTc5 LDE0NiwxLDIwNywyMjIsMjE3LDE0LDk4LDE5OSwxMCwyMjMsMjUwLDIyMywzNiwxNjAsNzks MjQyLDIyNiwxMDYsMjI5LDIwLDE0Niw5Nyw4MSwxODksMTg1LDI0Nyw0MSwxMSwxOCwxNDEs MjUwLDk1LDEzMCwxNTgsMTY0LDE3MCw4MSwyMDEsMzMsMTA2LDE4NSw4MSwxNiwxNDYsNzcs MTg4LDIwNiwyNTAsMTM2LDU0LDY4LDYxLDIxOCw2OCwyMjQsODcsMTA0LDEwMiwxOSwyMDks NDksODQsMTY4LDE3MiwyMTgsMjE3LDI1MCwyNDcsMywxOTYsMjQzLDYsMTgsMjQzLDI1MCwx NjQsODAsNSwyMjMsMTM4LDEwMSw3MCw3MCw3MCw1NCw1LDE0MiwxMzAsMTM0LDEyMiwyOCwx MjgsOTcsNzAsMTE0LDIzMSwyNTAsMjU1LDI1NSwyNTUsMTMxLDIxOCwyMDMsMjA4LDIwMywy MTMsMjAzLDE5MiwyMDMsMTgxLDIwMywxNzQsMjAzLDY0LDIwMyw1OCwyMDMsNjAsMjAzLDU0 LDIwMyw0MCwyMDMsMzQsMjAzLDI1MCw1OSwxMCwyMSwxMDEsMCw2LDIxOCwxNTYsMTIxLDEw OCw5LDc2LDU2LDcxLDIxNCw4LDE0MiwxMzAsMTQyLDE2NSwxMDksMTMxLDEwOSwxNTcsNiwx NDgsNjYsMTU5LDgsMTM4LDcyLDIxNiwyMTksMTIzLDE4MSwxNDYsNSwyMzUsMjcsOSwxNDcs MjQ3LDI0MCwxMiwyMzcsMjM1LDM3LDEyNiwyMTgsMTk5LDIxOCwyMTYsMTc1LDEzNywxNjUs MjAwLDU4LDIxNiwyMywxNTksMjI4LDEzNCwxODEsMTY5LDUxLDczLDI2LDE4MywxODEsMTUy LDE0NCw4NSwxMDYsMjMzLDc3LDE2NSwyMTAsMjE2LDE2OSwxNTMsMTYwLDEzOCw3NiwxMDMs MzksMTIwLDUwLDE2NSwxNjQsMTY5LDE3OSwyNywyMTYsMTMsMjMwLDIyMCwxNzgsMjExLDU3 LDEyMiw1Nyw2NywyMTIsMjM0LDE3OCwyMDcsMTU3LDY1LDE3NCwxMDksNTEsMjEwLDEzMSwx NzQsMTAsODgsNDgsMTAzLDE4Miw1MywxNjMsNDksMTU5LDEyMywyMjEsMjMxLDI5LDQyLDE4 MCwyMSwyMTAsMTg0LDM2LDIyMiwxNTUsMTkyLDE4LDM3LDExMCw2LDE1NSwxOTksMTYzLDIz NSwxMzEsMTA4LDU1LDgzLDE3NCwxMzIsMTgsMTA0LDE5OCwxOTksMjAyLDIxMiwxNDksNTIs MjE0LDE1MywxMDcsMjQ3LDEzLDExOSwyMTIsNjUsMjEwLDIwMyw5MiwyNDcsNDcsNDMsMTM2 LDIxMCwxNTUsMjEwLDE0NywyMTEsMjExLDM5LDE0OCwxMTIsMzEsOTMsMTc2LDE3OSw4OCwx NDksNzksMTI4LDYsNywxODUsMjE5LDE4MiwxNzMsNCwxNDUsMTc5LDE4OCw4MSwxNjgsMTcx LDE1OCwyMjIsMjI4LDIzNiwxODksMTU3LDE0MCwyMDMsMjE0LDE1LDc4LDE1LDIwMCwyMTcs Niw1MSwxMTIsMTg3LDEzOCw5MCwzMywyMDEsNTUsMTUzLDEzMCwxNzEsMTcxLDIyLDUyLDIy NiwxNTksMTQ0LDc0LDE4MCwxNTYsNDMsNzEsMTM3LDk0LDIxLDIzMSwyMDAsOCw0NSwzNCw1 NiwyMjEsNzcsMTQ5LDIzOSwyNDAsNTgsNDQsMjEsMTM3LDIwNyw2NCw0MiwyMjIsMTc4LDU5 LDEwNiw0NywxMjcsMTQ4LDIxOCwyMTAsNzIsMjUsMTM5LDIyLDIzOCwxOTUsNDIsMTM5LDE0 MywxNDcsMjA0LDE4NCw5OCwxODEsMTkxLDEwOCwxMTEsMjE0LDQsMywxNTAsMTk4LDE3OCwx NzQsMTgzLDE4MiwxOTYsMjEsMTI5LDU1LDIzMiwxODgsNywxOTEsMTg3LDE5MCwyMjcsMTgy LDE5MSwxOTYsOTYsMTI3LDE3OSwyMjEsNywyMTgsMTc1LDEzOCwxNTgsMTE1LDE5OCwyMTMs MjEsMzgsMTc0LDE4NywxOTIsMTkxLDg1LDE1LDE5MiwxODcsMTcwLDU4LDE3NCwxOTksMjE4 LDE3OSwxOTAsMTk5LDIxNiw4OCwxMzksNiwyMzYsMTcxLDIxNiwyMTgsMTgsMTgwLDEwNCwx OSwxMDgsNSwxNTAsMTI4LDEsMTkwLDEyNCwxMCwxNDgsOTQsMjUxLDE3Niw2Niw5MSwxMywx NjksMTc0LDE2Myw3MSwxOCwyMjIsMjE5LDE1NCw0Myw4LDIwLDQ5LDE3MCw1MCwxNiw2LDIw OCwxODksMjE0LDEyLDYzLDksMjAsMTgxLDU3LDI1MywxMDMsNDYsMjI0LDE2MiwxNzQsMTM5 LDI0LDE4MywxODcsMTYyLDE3OSwxODMsMTc5LDE2MCwxMiw1MiwyMzYsODYsODQsMTc0LDE3 NCw0NCw2NCwyNiwxODAsMTkyLDIwMCwxOSwyMDQsMTgxLDUwLDcwLDE4OSwxODMsMTM5LDMy LDE4NCwxODcsMTE5LDE4LDIyOCwxMDQsMjQ2LDIzLDE4MSwxMTIsMjAyLDE4MCwxODUsMTkx LDE5LDIxLDExNSwxNTEsMTgxLDc3LDkxLDE3MiwxNDcsMTI5LDIxLDIsMjE1LDc0LDEyMCwx Myw2Miw1OCw5MSw5LDU4LDcsMTU3LDQzLDE1MSwxMjksMywxMjgsMzcsMjE4LDI1NCwxMDks MTg3LDIxMywyNDgsMTY5LDE4NSwxNjgsMTc5LDE3MiwyMTgsNjUsNTksOTksMTgzLDgwLDE4 MiwxODksMzAsMTcyLDE4NCwyMDgsMjE2LDI5LDE0NCwyNTQsNjUsMTg2LDE4MywxMzEsMTg4 LDEyLDEzOSwxNTYsMTUwLDIxMiwxNDAsMTUyLDEzNywxMCwyNDcsNiw3MiwxMjIsMTg4LDE2 OSwxODEsNiwxNzQsNTMsNTksMjAxLDE1MiwxNDEsMTQwLDI1NCwxMDIsMjUyLDEwLDE2OSw2 MSwxMTgsMzksMjEyLDE0MSwxNzgsMTE4LDE5MywxOTQsMTEwLDIzNyw1NCwyMzQsMjIwLDIx OCwxNjYsMTM3LDE1MCwxNTYsNzAsMTk4LDIxNCw2LDgyLDIxNCwyMDIsMjAsMTQ1LDY2LDEz MSwxNjQsMTYsNTQsMjE2LDQ1LDIzNiw2Niw4OSwyNywxMDAsMjMwLDIzMSw4MCwxMCw5Nywx MzEsMTc2LDMsNzQsMTcyLDE3LDE4MiwyMDIsMjQsNTcsNDUsMjE2LDE3OCw2Niw4OCwyNyw2 NiwzMiwxNyw1NCwxNzYsNjYsODcsMzQsMTAsOTcsMzMsMTcyLDEwOCw0Niw4OSwxNzIsODAs MjQ2LDEyOSw3MywxNTAsMjA1LDgsMjcsMTAwLDMsMTI4LDI3LDI4LDMzLDEwOCw2NSwyMTQs MjEzLDc2LDE3Miw1MCwyLDg4LDIzNCw5NCwxMzIsNCw2Niw5LDAsMSwxNTAsMTYsNzIsOTcs ODQsMjMsMTE3LDEyOSw2NCwxMCw5MSw0Nyw0NSwxMDksMTUxLDUyLDE3NiwzNCwxNTMsMTgw LDE5NywxNDYsMjYsNDYsMjI4LDIwNCwyMzksMTgsMTg4LDE5MCw4MywxNzMsMTM0LDIwNSw5 OCwyMTIsMTQ1LDEwMSwzMiwxMyw3OCwxNjAsMTQ5LDE0NiwzNCwxMDMsMTkzLDE2OSw4OSwy MzgsOTcsNjcsNDEsMjEyLDE2OCwxNzEsNzMsMTYwLDEyOCwxMDUsMzMsMTAwLDIwMiwyMTAs NDUsMTIzLDIwNSw0MiwyNDAsMTIxLDEzNiwxMzQsMTQ0LDE2NiwzMSwxMzMsOCw2MCwxOTYs MTQxLDE2OSwyNywzLDIxMCwzMywyNDAsMTMwLDE4MSwyMTEsMzIsMjIsNDMsMjEwLDE5MCwx NiwxMzYsMTkyLDIxMywyMjcsMjQ3LDI1MCwyNTEsMTg1LDIxNCwxMDQsMTY3LDE2NSw5Mywy MjEsMTEwLDYyLDIzOCwyMjgsMTA5LDIxMywxNjAsMjUzLDE0NywxNTksMTQxLDE1OSwxMzYs OCw1NCwxNjcsMTQ3LDE4MSw3MCwxMDcsMjA1LDE2MywxOSw4NywyMDksMTk4LDE0MiwxNywx MSwxNDEsMzUsNjMsMjUwLDE5MSwyNDYsMjMzLDIxOSwxMzEsMTExLDIzNywxMDAsMjI1LDE4 MywxNDcsMTAyLDExMiwxNDksMTU2LDE0MiwxNjYsNDEsMjE4LDg2LDE4MCw3LDE2NiwxODUs MTQzLDM0LDksMTcyLDY5LDEwNiw4NiwxNzQsMzMsMTUxLDE2NiwxOTQsNzMsMTA5LDM4LDIz MiwxOTgsODMsMjEyLDE0OSwyNTAsMTc5LDQsMTI4LDkwLDE1MywxODMsMTgzLDE1NywyNTAs MjE1LDE5LDE0NiwxNDIsMTU1LDEyMSwxNTIsMjI4LDQxLDE0MCw5MiwxOTIsOTksMTg2LDE3 OSwyMTQsMjYsMTM0LDE0MiwyMiwxNDgsNzgsNjIsNDksMTM4LDI1NSw3MCw1LDE4NiwxNzEs MjA3LDE3NiwxNTIsMjQ4LDI0OSwyNTQsMjU1LDI1MiwyNTMsMjQyLDIxMCwxMzAsMTY5LDgy LDk2LDE5OSwxMzUsMjIzLDIyOSw0OCwxNTEsMTcyLDE4NSwzNCwyNDEsMTMsMTEzLDEzLDU3 LDcsOTcsMzAsMTQ5LDEzNiwxNTcsMTc1LDYsMTgzLDI1MywxOTQsODYsMTUxLDE4MiwxODgs MTY4LDE4MSwxODMsMTkyLDE5OCwyNiwxOTYsMjMsMjYsMjE0LDE5MiwxOTIsMTg1LDIyMiw3 NSwxNCwxOTUsNjIsMTg0LDE2NSwyMDgsMTg3LDYsNDMsMTg2LDE1MSwyMzcsMTc0LDIyMiwz MCwxNjUsMjUwLDI1MiwyNTEsMTUwLDE1NiwyMTUsMTM3LDY1LDI0LDE4NSw2OCwxMDcsMjEx LDExMCwzNiwyNTAsMTQzLDI1MCwyMiwxNjIsNTcsODgsNzksMTMxLDIzMywyNyw3MiwxMzcs NDMsMjAsMjAyLDIwOSw1LDI0Miw2LDIzMSw0MywyNDQsNiwxODUsMTUwLDEyNiwyOSwyMzcs MTU4LDIxNSwxNTMsMTM4LDIxNCwyMjQsMjYsMTIsMjcsMjI4LDEzOCw1LDIzNiwxMDksMTY4 LDEwMiwyMzgsNSwxNDIsMTU4LDEzMSw3LDYwLDcsMTY1LDY2LDk3LDE0NSwxMzAsMzEsMTEy LDEyMywxMDIsMTYwLDU0LDg5LDI1MCwxMTYsMTM3LDk2LDAsMzQsMjE5LDIyLDQ0LDE4MCwx MjMsMTY3LDI1MCwxNzEsMTMwLDk5LDEzNywxMzgsMjMwLDExMCwyMDgsMTU4LDI1MCwzMywx NDMsMTMwLDUsOTMsMjA4LDE5OCwxNjAsMTAyLDIyMywxMTIsMTA0LDE1Myw0NiwyNywyMjgs OTAsMTg3LDExOSwxNDYsMTQ5LDE4MCw5Miw0LDE4OCwxNTUsODQsMjE5LDE2NSwxMDQsMTI4 LDM0LDIxNSwxNTUsMzMsMTg2LDcsMTk5LDE1MSwxOTIsMTgyLDI0MCwxNTAsMTU1LDE1Miwy NTAsNTQsMTM3LDEwNywyMDUsMjUsMTEwLDE0OSwxNDksMTU3LDIyMiwxMywxNzEsMjA1LDI4 LDIyMSw5MCw1MSwxMTIsMTUxLDEzOCw0NCwxMjcsMTk0LDgyLDI1MCwxMzgsMTA3LDE3Mywx MDksMTczLDU5LDIxNSw4NiwxNTUsMTkxLDExLDE0OCwyNiwxNTQsMTg3LDEwOSw5MSwxNiwx NTcsNDgsMTg2LDcxLDEzOCwyMTIsMTcyLDgyLDIxNCwxMzAsNzAsMjE5LDQxLDEzMSwxMjQs NDUsMjQ0LDE2NiwyNCwyMTgsMjE0LDIyMCwxNDksMjMwLDE2MiwxMzYsMTUxLDE4OSwxNjYs OTIsMjIxLDE5NCw1NSwxODEsMTY2LDI1MCwyMDgsMjEyLDIwOCwyMjEsMTQxLDEwNSwyMTIs MTYyLDE1NSwxMTcsMTU2LDIzLDI0MSwxNTEsMTM3LDE1NywwLDEzNyw1LDQsMjA1LDE1Miwx MjEsMjUxLDEzMCwxNTEsMTUwLDMwLDE1OCwxNTIsMTMwLDQsMTU4LDE1OSw5MiwyMjIsNTQs MTI3LDE5LDE0OCwxNTMsMTQ2LDE1MSwxNTYsNjAsMTQ5LDE1OCwxMzcsMTUzLDE1Niw5Miw1 OSwxOTYsMTkzLDI0LDEyMSw0LDMzLDE3Nyw5NSwxOTMsMjEsMTE4LDMzLDM5LDk0LDE1Miwx NTIsODQsMTg3LDI0NiwxOTMsMTE3LDc4LDE1MCw0Myw0OCwyMTIsMTQzLDIwNyw1MywxNTcs MTQ3LDEwOSwxMTAsMjM2LDExNSw2OCwyNCwxNTgsMTE0LDE0NCw2NCwyMDAsMTQ2LDI2LDEz NCwzOSwxOTUsMjMxLDE4OSwyMTgsMTgxLDE1Niw0OSwyMjcsMTgwLDk2LDIxOCwxMCwxNjIs MjAxLDE1NywxNzQsMTQ1LDQ0LDcwLDE5NSwxODIsMTA2LDE3MywyMTksMTQ1LDIyNywyMTks MTg0LDQxLDE4MSwyNDcsMzMsMTgwLDE3LDE2MiwxNzAsMjE0LDExLDYsMTg1LDIyNiwzOSwx MzUsNDcsMTQxLDIxOCwxNzcsMTU5LDEzMSwxOSw1NCwyMDQsMTY1LDIzNiw1Myw5NSw0NSwz OCw1MywxNzMsMjA4LDE0LDEwOCw0NSwxNzAsMjUsNzksMTcsMjAsMjAyLDE3MywxODEsMTM3 LDExLDQsMTAsMTU1LDE1MCwxMjAsMTA0LDE2NSw4Nyw0Niw4NSwyMTgsMTUzLDEwLDE1MCw3 MiwyMSw5MywxNTEsOTMsMTgzLDIxOSwyMTksNDIsMjE4LDU1LDE1OSwxMDQsMTU3LDEyLDE4 MCwyNTQsMTU1LDIxMSw4OCwxMDEsMTM5LDEyMCwxMzUsMTQyLDEyMywxMzcsMTA0LDM3LDE4 OCwxMDksNTAsMTgwLDE0NywyOSw3LDUwLDE0MiwxNDUsMTMxLDE3Miw4NSw0OSwxMCwxNTgs NTgsMjE2LDIzLDE4MiwyMDgsMjE4LDg5LDY5LDEzOCwxNTIsMTQsMTIsMTQ2LDI0LDE5NSw5 OCwxNzMsMTM3LDc0LDEzMCwwLDU4LDIyOSwyNSwyOSwyNDEsMTY4LDE2OSw4LDkyLDIxOCwy MjEsNTcsNTYsMTAyLDE2MiwyMzQsMzMsMTg3LDE0NiwxNSw0Myw5Niw5MSwxMDcsMjM5LDg3 LDY1LDIwNSw1MCwxNzYsNzUsMTMzLDIyMCwxMTgsMTgyLDE0OSwyMjEsMTQ2LDg5LDIzMywx MzAsMTU1LDkyLDE3Miw5OCwxMDcsMTMsMzcsMTQ1LDIzNywxMzAsMTYyLDIzNywxNzIsMjE5 LDE0LDE5NCw0OSwxNDEsMTk1LDE2MiwwLDIxOCwyMzYsNDEsMjAyLDIzMCwyOSw5MiwxMzYs MjcsMTM3LDcxLDE5MywxNTAsMjIxLDU2LDE4NywxMjYsMjE4LDIwNCw0MSwxNywyMDksMTMy LDksMjM4LDIwNywyMTgsMTcwLDEwOCw0OCw2MiwyMzIsMTgyLDIwNSwxMzAsMTUwLDE0Mywx MjQsMTUyLDcxLDE3MCwxNDYsMTYwLDE3MywxNzMsMjUsMTUsNCw0NSwxOTUsMTc2LDE0Mywy Niw0NCwxODAsMTksMTA0LDE4MywzNSwyNCwxMzAsMTQ4LDEwMSwxNzAsMTMzLDE0LDEyMCwx NDAsNzUsMTQzLDU4LDIxNiwxMTAsNzcsMTczLDYyLDE2NCw0OSwxNDYsMjI0LDE0MywxNTIs MTUsMTQyLDEwLDEzLDk4LDIzMCwyMzYsNjgsMTE4LDgyLDE2OCwxMjUsNTksMjE0LDU5LDEy LDI1MCwxNTgsMCwyMjEsMjE0LDIyMSwyMTgsNSwxOTgsMTczLDIzMCwyMTQsMTAxLDAsMjE4 LDEzMSwyMTgsNjcsMTc4LDE5MiwxNDMsMjE2LDU0LDE4MiwyMTAsMTkyLDYyLDksMjIzLDQy LDE0NywzLDIwMCwxNCw5MiwyMjEsMjE0LDkxLDEwLDE5MCwxMzIsMTkyLDg5LDYzLDIwNCwx MDYsMjA4LDE4MiwxNDksNywyMTYsOCw0Nyw2MSwxLDE1MSw0OCw4MywxMjksMTYsMTEwLDI0 NCw0NSwxMTcsMjEwLDIxNyw0NCwxODMsMTM0LDIxNSw1OSwxOTIsMjE2LDE2OCw4MSwyMzYs MzAsMzIsMjAzLDE0NywyMTUsODYsMTQyLDkwLDE2LDYwLDIxLDE0MCw4NywyMTQsMTg2LDEx MSw0NSw5NCwyLDIxNSwxNzQsMTMxLDEzOCwxMDEsMTUxLDIxMywxNzYsMjM3LDIxNCwyMzQs MTYyLDQxLDIxMywyNywxNjQsMTU4LDE5MywzMSw4NiwxNjgsODYsMTc2LDIxOCwwLDYzLDQs MjQsMTU0LDExLDE4MiwyMDksMTMxLDE0NiwyMTUsMCwxMTksMzAsNzAsMjQ2LDEzNCwxODUs MTg4LDE1LDE3LDc5LDEzNCwxOTgsMTY2LDEzNSw3MCwyMTMsMjMsMTUwLDE5MywxMDUsMTQy LDIwOSwxMDYsNTIsMTksMTA4LDYzLDMxLDM4LDAsMSwxMDcsMTgwLDgwLDE0NywyOSw0NCwx MjAsMTk3LDYsNDUsMjAyLDEzNywyNDUsMjE1LDEwNiw4Miw4OSwyMjUsMjMwLDE5Miw1Nywy MDUsMTUyLDU2LDk0LDYsMjE4LDE2MSwyMTQsMTcsODcsMTI4LDg0LDEyMCwyMzYsMjM3LDMy LDEyMywxNDMsODEsMTUyLDExNywxNTksMjA0LDIwNiwzNCwzNCwxODAsODgsMTc3LDE1Nywx MDEsMTEsMTE2LDg0LDEwNywyMCw5OSw3OCwxNjEsMTAxLDE5MywzOCw0NCwxNzYsMjQsMTM5 LDg1LDc1LDgxLDk2LDQyLDI1MSwyMCwxOTYsMTU1LDE1NSw3OCwyMTQsMjYsOTUsMTcxLDMs MTg0LDk0LDIxMywyMTMsMjQsMjMsMTMyLDQ1LDU5LDIwOCwxMzcsNDUsMTc3LDE3Niw5Niwx MTEsMTYsMTgsMTQ5LDI1MCw0LDE1OCwyMjQsMjA3LDEyNSwxMDksMywxNywyMTIsMjUsMywx OTgsMTUyLDEzNiwyMzksMTkzLDEzNSwyNDcsMTI2LDksMTU3LDE5NiwxOTgsMzAsMTcsMjE3 LDEwNywxNzcsMTgsMTk4LDksNiwyMiwyMjgsMTA0LDE2NSwxNzMsMjEwLDE5OCw2Miw4MCwx MzcsMTY4LDkzLDE5Niw5NiwzOSw5MiwxODAsMTU4LDE5MiwxOCwxOTYsNjQsMTcwLDIzNiwy MTYsMTYxLDIwMywyMDMsMTE1LDE1OCwxMzgsMTIsMjE4LDIxNSw5LDEzLDk5LDE3OSw1NSwy MiwxMywwLDE2OCwxOCwxODMsNDYsMTkwLDksMTgwLDEzNyw3MiwyMTAsMTMsMTc4LDEzMiwx MDYsMjM2LDIxMCwxNzcsMTQ5LDksMTYzLDE1NSw4MywxNDksMjE5LDEwLDE3NCwxLDEwNyw0 NCw1MywyNTUsMTIxLDEzMSwxMDgsMTQsNjUsMTM1LDIxNywxMTAsODQsMTkyLDIxMSwxMywx OTEsNzcsMjE4LDQ5LDE3MSwxOTgsMTMwLDk0LDMwLDE5MCwyNSwzLDEyMywxNTMsNDgsMTg0 LDEzMiwyNDgsMjksOTEsMTE0LDIwMCwxMDAsMjAsMTgzLDE5MSwxNDAsMTMxLDY3LDE5NSwy MjIsMTYsMjgsOTIsMjE2LDIzOCwzMiwxOTYsOTAsMTUzLDYsMTgzLDI1MCwxODUsMTI2LDYx LDkyLDEzLDk0LDU3LDEzOSw0NiwxOTMsODYsMTY4LDY2LDIzMywxMywxNjUsNiw0OCwxMDYs MTA2LDE4MSwxMDAsNzksMTg4LDE1NSwxMzAsNjgsMTE4LDIwNyw0NSwyMiw4NCwyMzIsMjM0 LDE1OCwxLDEwOSw5LDE2MywxNDksMTg1LDEwMSwxNDUsMTA3LDIxLDIxOCwzMCwxNTcsNTMs MTU0LDE5MywxNywxMjMsMTY5LDI2LDI4LDE2NSw4LDE5NSwxMDEsMzQsMjU1LDE0LDE0MCwx MywyNTEsMTUwLDExNiwxMzgsNTAsMTU4LDIzNiwwLDIxOCwxMTUsMTE3LDU0LDU5LDE1NSw1 LDE2LDIxMiwxMjYsNCwyMzgsMTAzLDMsODcsMTc3LDIyNiwxNDcsMTQwLDEzMCwxNTgsNCw2 NywyNyw4NiwxNTIsMTQ3LDExOCw0MiwxODIsMTgwLDkwLDQ0LDE4NiwxMTQsMjE4LDg3LDEw OSwxMTQsMjI0LDEzMCwxMDgsMTE2LDE0NSwxMzcsNzgsMTM3LDEwMSwyMTYsMzMsMTA4LDE1 LDE1MiwxNDcsMTYsMTM4LDE5NCwxMzgsMTc5LDEzNCw5MSwyMTQsMTEyLDIxMiwxNDEsMTU5 LDIzLDM1LDI1LDIxMiw2LDE3Niw2NSwxMDcsMTM4LDYsMTEsMTc2LDY3LDkzLDE0LDEzNywy NDAsMTEyLDMzLDAsMTE4LDI1LDcxLDIxNSwxMDgsMTg2LDUsMTgyLDEwOCwxMzEsNTEsMTc1 LDEzNywxNjQsNTIsNTgsMTIwLDEwMCwxMjgsNTUsNTMsMTUxLDE1Myw0MSwxNTUsMTc2LDE1 LDE1MiwyMTIsNjksMTg3LDE1MiwxNDcsNDUsMTYzLDk3LDE0MywxNzMsOTUsMTU2LDEzMiwy NDAsMiw4LDc1LDE4MiwzNSwyNDcsNzQsMTc0LDI5LDE3OSwxMzYsNDMsMjQ5LDE1MCw2Niwy OCwxNTYsMiw2NiwxNTgsMzAsOCwxOTgsMjI4LDE1OCwxNjEsMjE1LDE2MiwyNyw0NSwyNiwx MTUsMCw1OSwyMzYsMjA5LDU1LDE0MSwxOTQsMTM0LDE5MiwxMDEsMzMsMTcsNTQsMjcsMTg3 LDIzNSw1MSwxMjYsMzQsMTEsMTMyLDQ1LDQ0LDg4LDIxMCwzLDE1MiwyMTIsMTAyLDEzMCw5 OCwxNSwxMiw1MywxMTMsMTkwLDE5OSwxNDcsODIsNDEsMTM4LDI4LDE0NCwxNDAsMTY1LDIy NiwxNCwxNjksMjM1LDE1MCwyMTIsMjIxLDIyMyw0OSwyNTAsMjUyLDE2NSw1NSw0OSwxOSwx MzUsMTMsNTQsMTgzLDIyMywyOCwxNjEsMTc2LDExMiw3MiwyMjcsMTYzLDQ5LDE2NSwyOCwz Myw5Miw4OSwxMDQsOTYsMTY1LDc4LDE0MSw4NCwxNjUsNTEsMTQ4LDIyMCw5MSwxNDgsMTc4 LDE4NSwxNTYsMTY1LDE4MiwyNTUsMjEwLDUsMjQsMTEyLDI5LDE5OSwxNDIsMjMsMTQwLDgz LDEwOSwxMDcsMTc3LDI0OSwyNTAsNzksMTksMTM3LDMzLDIxLDE1NCwyMzQsNzgsODgsMTMx LDk1LDE4NywxNTAsNDQsMTY1LDk0LDE1OCw5MiwzNywyMjAsMTc0LDc4LDE3NiwxNDksNDEs MTI0LDI4LDEzMSwxMDQsMTEwLDE2NiwyLDk1LDEzNywxNjUsMTQ4LDE1Niw1Myw3NiwyMjEs MTU2LDEyNywxMDIsMTQzLDE1NiwxMjgsMSwxMDksNCwxNzMsMTU3LDEyMiwxNTUsNywxOTcs MTQzLDE0NywxMDcsMTQyLDIyMCwyMTUsMjksMTU4LDE3LDEzNiw2OCwyMzksMTcyLDE5Nywx MDgsMjIzLDE3OSwxNTIsMTQsMTA3LDE2OSwxNTEsODMsMTc5LDEzNCwxNTksNzYsNDgsNTIs MTI0LDEzMiwxNjUsMTUsMTY1LDIzNSwzMCwyMTQsNTAsMjEzLDkwLDM2LDIyMSwyMjIsNDQs MTMwLDU0LDg4LDExMiwxNDIsMTMwLDE0MCwxMSwxNDAsNzcsMTQ3LDE4NywxMDksNDksMTM5 LDY0LDEzOCwxNDQsMTI5LDE0MiwxNzQsNjIsMTE1LDk2LDE1MiwxNzIsMTQ4LDMzLDEzNywz MiwyMywyMjgsMTE0LDExNSwxMTEsNjgsNzIsMTg3LDE1MywxNTAsMjEzLDMwLDE0MywxMzgs MjIwLDE2MSwxODIsNzcsMTcyLDI0LDE0MywyMywzNiw1MCwxNDAsOTMsMjA0LDIxLDgyLDE4 NSw2MiwxMDQsMTQyLDE2OSwxODgsOTUsMTgxLDEzOCwxNiw2NywyMywyNTMsMTUwLDE2Nyw5 MCwxOTIsOTYsMTA0LDE2OCwyMzksMTA0LDY4LDE5MywyOCwxODUsMTY5LDI0NCw5NCw1Nywx ODEsMjE4LDM0LDEzMywxNjQsNTUsMTQ2LDExMiwxNjgsMTA5LDE3NywyMDIsMTY3LDExOSw5 MCwxODAsMiwzMSwxMDgsMTMxLDI0OCwxNDIsMTcwLDM5LDE1MSw1NCwxODMsMTQzLDE2Miwx MzAsMTczLDMsMjQxLDExMSwxLDE3NCwxOTEsMTgwLDE2MywxNzcsMTY5LDE5MCwxMTMsODYs MjcsMTgxLDI0LDIwNSwxODcsMTM3LDE4OCwyMTEsMTA0LDIwMSwxNjksMjU1LDI5LDE4MCw3 MCw3MiwyMCwyMzUsMjUwLDIyMSwxOTAsMjIxLDEzNiwyMjEsMTQ5LDIyMSwxMzgsMjM5LDI1 NCwxMzMsMTE4LDEsMTU5LDIyMSw0MiwxNjksMjIxLDE0NSwyMjEsMTMxLDIyMSwxODAsMTEs MTQyLDIyMSwyNTAsMTY1LDc3LDE3OSwyNTMsMjQ2LDIxNSwxNDksMTgxLDE1NSw3MywxMzQs MjE1LDIwOSwxNjksMjA5LDMsMTQ1LDEzMSwxODAsMjUzLDIxOSwyMTAsNTIsMTU5LDE0Miwx MzQsMTAxLDE3NywxODEsMTQ5LDIxNSwxNjUsMjUwLDE2MSw0OSwyMjYsODIsMjA2LDc5LDEz NiwxNjYsMTI4LDE2NywyOSw2MywxMDcsMTEyLDE4MCwxMzcsMTMxLDEwNiw2OSwxNTEsMTA1 LDE3NiwxNDUsMTUwLDE2OSwyMDUsMjEwLDUzLDgzLDE1MSw4MiwwLDIxNSwxOTYsMTc1LDYz LDk5LDE3NSwxNTMsMTk4LDEwLDE3LDEwNSwxNjcsMTY5LDIxNSwxNDUsMjIwLDI0OSwyMiwy NTAsMjE1LDEzMSwyMTUsMTgwLDIxNSw4MCwxNDIsOTMsMTYxLDIwOCwxNzAsMTQ1LDIyNSwx NDIsMjQ1LDE3MiwyNTAsMTYwLDIxMCwxMzksMTI4LDE2MywxNzYsMjEyLDEzMywyMzcsMTg1 LDEyOSwxNzQsODIsMTMxLDE5MiwxMTEsNjIsMjUwLDE5NSwxNjIsMTc4LDE0MiwyMzgsMjUw LDI0LDEwNiw2Nyw5MSw3MiwxMTMsMTM4LDE1LDE2NiwyMTgsMTg4LDIxMywxMzIsMjE0LDU0 LDgzLDE0MSw3LDgsOTIsNjEsMjE0LDI0LDIwNCwyNTAsNywxNzQsMzksODIsMTc5LDE4NSwx NzEsOTYsMTYzLDkxLDIxNCwxODIsMjUwLDY3LDEzLDE5MCw1NCwxNzYsMTM1LDEwOSwxMDgs MTczLDEwNiw0MSwyMDAsMTQ5LDI1MCw2NSwxNjksMzcsMjMsMTYxLDE3MSwxNDAsMTA1LDEz NywxOTAsMjI0LDE0LDIyMSw4MiwzLDg3LDUxLDUxLDEzOCwxMzEsNjcsMTcwLDUzLDcxLDIw NSwwLDkwLDcsMTQwLDg0LDEwMCwxNDIsMTAsMTc2LDg5LDE4MCwyMjAsMTU0LDEzOSw5Nyw0 NCw3MywxODksMTAxLDE4NywzNywyNTAsMTcsMjA3LDE3LDU2LDU4LDEzNywyMDAsNzAsMTMx LDEwLDQ4LDEwLDE5MCwyMTgsMTMyLDI1MCwxMTUsMSw4OSwxNDAsMTM4LDkyLDM0LDAsOSw2 OSwyLDExLDM3LDEzNywzLDI1NSwxNTEsMjAzLDE2OSw1MiwxLDg0LDgwLDEsNzEsMTAxLDEx Niw3NywxMTEsMTAwLDExNywxMDgsMTAxLDIxNiwyMiwwLDIwMyw3MCwxMDUsNzgsMTMxLDY1 LDE5LDg4LDExLDEyOCwyNTUsODAsMTE0LDExMSw5OSw2NSwxMDAsMTAwLDExNCwxNDQsMTUs MjU1LDIzNiwxODMsMjU1LDgzLDEyMSwxMTUsMTE2LDEwMSwxMDksNjgsMTA1LDE2LDk5LDEx NiwxMTEsMTE0LDEyMSwzNiw4NCwxMDUsOTksMTA3LDY3LDExMSwyMzYsMjE5LDIyLDIzNiwx MTcsMTEwLDExNiwxMyw2MCw3MCwyNywxMDksOTcsMTE2LDY1LDE1LDk5LDEwOSwyMzYsMTU5 LDkwLDExMSwxMTAsMTAxLDczLDExMCwxMDIsMjEsMTA1LDExLDIzLDg3LDEwOSwyNTUsMTMy LDI1MywxMDUsMTEwLDEwMCwxMTEsMTE5LDExNSw3NSwxMDgsMTExLDk4LDk3LDEwOCw2NSwx MDgsNiw5OSwyNDcsMTkxLDEwOSwxMzUsMTIsNzAsMjksMTAxLDExLDc2LDExMSw5NywxMDAs NzYsMTA1LDk4LDExNCw5NywzOCwyMDcsOTgsMjAxLDE4NiwxMyw5OSwzNywxMSwzNiw3Nyw5 NywxODcsNTMsMjQ3LDI1NCwxMTIsODYsMTA1LDEwMSwxMTksNzksMTAyLDE5NCwxNCwyMDQs MTA3LDY2LDEyMSwxNzQsMjM5LDkxLDI1MSwxMTgsODQsMTExLDEwNiwxMDAsMTAxLDY3LDEw NCw2MCwyMCw3OSwxMTIsMTAxLDExMCwyMTEsMTA3LDIxOSwxOTMsOTgsMjA3LDgsNTEsNTAs NDgsMTE0LDIxNCwxNSwyMDUsMjE4LDIzOCwxLDc4LDEwMSwxMjAsMTQsODIsMTAxLDExNiw3 NCwzMywxMjgsMjIxLDIwNSwxNzMsMTAzLDEwMywxMDUsMTA1LDY4LDExNCwxMzAsMTA3LDkx LDI0NywxMTgsODMsMTE2LDUsMTEwLDEwMywxMTUsMTM3LDgzLDI0LDY5LDE5NywxMTMsMTgx LDIyMSwyMDcsMTMsMTMsOCw2NSwxMTYsMzEsOTgsMTE3LDEyMCwxMTcsMTczLDI1MywxMzAs MzMsMTksODAsMTExLDQ5LDE2LDEyOCw4MywyMTgsMzMsMTMwLDE4NywxMSwxMDEsMTEyLDYs NzEsMjYsMTU3LDEwOSwyMTksMTgyLDI0NywzMSw5LDIxLDg0LDMzLDEwOSwzOSw5NywyNSwy MjUsMjMsMjQ2LDEwMCwxNjIsODUsMTEwLDEwOSwyMTMsODcsOTcsMTA1LDExNiw5MywyMzAs MTIsMTExLDE3NCw4MywxMjgsMTQsNzksOTgsMTA2LDU5LDIwLDIyMywyMzcsNDcsODksMTEs NzUsMjQ0LDIwLDExMCw2OSwxMjAsMzAsMjI1LDExOCwxODIsMTE2LDUwLDExNCwxMDEsNjEs MTA4LDExNywxMTQsOTksMTUyLDIwMywzMCwyNDYsMjE3LDksMTA5LDExMiwxMDUsMTAsMTEy LDEyMSw5LDQ2LDI0Niw5MCwxNzYsMTEwLDEwLDQ5LDksMjUyLDI1MCw0OCwyMTksMTAyLDEw MywxNjIsNzEsMjA3LDEyNywxMjIsMTIsMjI1LDExLDMxLDE0MywxNiw4NCwxMjEsMTEyLDQ3 LDY3LDE0NSwxMTUsMTAxLDcyLDk3LDE2LDE1LDEyLDI0Nyw5NCwxMDYsMjcsMjAxLDksNjcs MTE3LDIxNiwxOTMsMTAsMTMzLDExNCwxNjgsNiwyMjAsNzMsMTAwLDIwLDIxNSwxODYsMjA3 LDIsMTgsMTExLDEwOSwxMDksNjksNzYsMTkyLDg1LDQsMTIzLDcsMTk5LDcwLDM5LDE0NCwx MTgsMTQsMTU1LDEyMywzLDU5LDE3NSwxNSwxMjAsMTE0LDIzOCwxMDUsMjQ4LDE1LDIxOSwx MDEsNzEsNjcsODUsOTcsMjUxLDExMSwxMDgsMTA0LDEwMSwxMDgsMTEyLDExMCwxNzgsOTUs ODgsMjExLDgzLDg3LDExMiwxMTUsMTA0LDExMSwxMTYsMjUsMTA0LDYsMjcsMTgyLDIyNSwx NzYsMTAwLDEzLDc3LDE3NCwxMjAsNjUsMTMsOTAsMTUxLDQ4LDY3LDE5OSw3NywxMTIsMTAw LDE5LDEyLDIxOCw2NiwxNzgsMTk0LDExMSwzMSwxMCw2Myw5NywyNywxNTQsMTA4LDIzNywx OCwxOTAsODIsMTA0LDc1LDExNSwyMzAsMTEwLDE2Nyw4OSw5MCw2NSw4LDIyLDEwMyw2OCwy NSwyMCwyMDQsMjI1LDIyMiwxOTQsODYsNjgsMTE3LDU2LDE2LDIyLDEzLDEwOCwyNDYsMTAw LDExMSw2OSwxMTYsMzIsNzUsMTAxLDEyMSwxNCwxMTQsMTAyLDExNSwxMTEsMjE3LDE0LDIy MywxMyw4NCw3OCwxNTIsMTYzLDE1NywxNTcsMzIsMzMsNjYsMjQwLDMxLDEzLDIwMSwxMTAs NzcsMTExLDE0NCw5NSw5OCw3NCw2OCw2NywxODIsMjE3LDE1NSwyOSw3NCwxMDksMTI1LDk1 LDIyLDksMjI1LDk5LDU5LDE0MCw1Nyw3MCw4OSwxMTEsMjI4LDEwOCwxNzYsMTQxLDEwOSwx MzAsNTksNzMsODAsMTMxLDM4LDExOCwyMzksMjQsMTc5LDg5LDEwNyw4MSw5MiwxNCw0Nywy MDcsMTg0LDExOCwxOTUsMjIwLDEwOCw4LDYyLDE5OCw2NiwxMDcsNTUsMjE5LDIxNCwxMiwx MDMsMjUyLDg0LDE2NSwxMzEsODEsMTE0LDE2Nyw4OCwyMjMsNzYsNzMsNTQsNTIsODEsNDks NiwxMDksNzksMTEwLDcyLDIxOSw5MCwxMzUsNzMsMjEyLDU5LDE0LDEwNiwxMDUsMTAsMjI1 LDEwNSw1NCw3MSw3MSwyMTMsOTgsMCw4MywxNzEsNTIsOTEsMTk1LDE2MywxMDgsMTgxLDY2 LDY1LDY5LDExMCw2NCwyNDYsMjE2LDI3LDIzOCw2MywyMjMsMTE0LDczLDY1LDksNjgsMTE3 LDExMiw4LDIxNywxOTgsOTYsMTEwLDIsMTgsODQsMTMzLDEwOSw5LDI0NSwxNjcsMjMzLDIy MCw4MiwzOSw1NywxMjIsODgsODUsODIsNzYsNjgsMTY2LDE1NSwyMjgsMTg2LDEwMSwxMTAs MTA4LDY0LDEwNSwyOCwxMzMsMTA0LDU0LDEwOSwxNTcsOTYsMTI1LDExMiwyMDEsMTE2LDEw Miw3NywyOSw1OSw0NCwyMzYsNTIsOTcsMTAzLDgwLDExMSwxNDQsMjU1LDExNSwxMDcsMTA5 LDI1LDEwMiwxMDksMTQ5LDExMiwxNjQsNTMsMTIyLDExOSwxNDksMjYsNzksMjM4LDIyMiwy OCwxMDQsODUsMjcsMTcwLDI4LDc5LDc5LDIxMSw3MywxNDQsMTIwLDczLDIyMSwxMTAsMTg2 LDIzNiwxMDcsMjE3LDE0NiwyLDIwLDExNiw2NSwxNCwxNDAsMTI4LDE0OSw0Niw4NSw5Miwx NywyNDMsNTQsNjcsMjE5LDExMiwxMTAsMTEwLDgyLDEwMSwxMDAsMTk1LDQ3LDg5LDE1Niwx ODUsMTgyLDIzOCwxMDUsMTQwLDEwNSwzMSw5NSwxODgsMTAwLDU5LDY1LDY0LDE2MywxNzcs MTU4LDExNiwxOTIsMjQ4LDg1LDE1MiwxNTcsMjA0LDMzLDEyLDk4LDEyMSwxNCw3MiwxMjEs MjMzLDEwNywxOTIsODAsODgsOTksMTI4LDExNSwzLDEwNywxMDEsMTE2LDE5MSwyMDIsOTEs MTEwLDk4LDE4OSwxMTQsOTcsOTksOTksMzcsODMsNjUsMTI5LDIxNSwyOCwxMTksOTIsMTE0 LDExNiwxMTcsNDgsMzUsMjUsMTIxLDU0LDI1MSwxMDIsMTc0LDExOCw1MCwxMjIsMjAsMTA4 LDcsNjIsMjQ5LDQ3LDE5OSw5NiwyMDUsODAsNjksNzYsMSw0LDAsMjA0LDE1LDE0NCw2NCwx NTgsNTIsMjU1LDE1LDIyNCwwLDE1LDEsMTEsMSw1LDEyLDAsNjgsODYsNzIsODAsMjUxLDEy LDcsMiwyMjMsODgsMTMsNjQsMTEsMTEwLDIyLDEwOCw1NywyLDQsNTEsNywxMiwxOTIsMjA2 LDIyMCwxNDYsMjA4LDMwLDUyLDE2LDcsMTc5LDE4OCwzNiwyMjIsNiw3OSwyMDgsOTcsMjIw LDkzLDMyLDE0NCwyMDMsMTkyLDE2MCwzLDE2NywxOTYsMjUxLDE1NCwxNzQsMTc2LDEsMzAs NDYsMTk1LDExNiwyMzUsNjYsMTQ0LDExOSwyMywyNDYsNSwyMzUsNCwzNSwzMiwzMCw0Niwx MTQsMTAwLDExNiwxMzEsMjM3LDEwLDE3NSwxNjMsNzAsMTEsMjUxLDEyLDM5LDcyLDIxNyw5 OCwyMjEsMTMzLDY0LDIsNDYsMzgsNzEsMTE3LDEwOSw3NCwxNTQsMjM4LDExMiwzOSw1OCw4 NCwxOTIsNzksNiwyNywxMDgsMTI5LDExNSwxMzAsMCwyMzUsMTkyLDExNSwxNDIsMTkyLDE5 MSwyMjMsMjAyLDM5LDI3LDExMiwxMDAsMTMsMzMsMTk4LDAsMCwwLDAsMCwwLDAsMCwzMiwx LDI1NSwwLDAsOTYsMTkwLDM3LDE2MCw2NCwwLDE0MSwxOTAsMjE5LDExMSwyNTUsMjU1LDg3 LDEzMSwyMDUsMjU1LDIzNSwxNiwxNDQsMTQ0LDE0NCwxNDQsMTQ0LDE0NCwxMzgsNiw3MCwx MzYsNyw3MSwxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNCwyMzcs MTg0LDEsMCwwLDAsMSwyMTksMTE3LDcsMTM5LDMwLDEzMSwyMzgsMjUyLDE3LDIxOSwxNywx OTIsMSwyMTksMTE1LDIzOSwxMTcsOSwxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNSwy MjgsNDksMjAxLDEzMSwyMzIsMywxMTQsMTMsMTkzLDIyNCw4LDEzOCw2LDcwLDEzMSwyNDAs MjU1LDExNiwxMTYsMTM3LDE5NywxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcs MjE5LDE3LDIwMSwxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDE3LDIw MSwxMTcsMzIsNjUsMSwyMTksMTE3LDcsMTM5LDMwLDEzMSwyMzgsMjUyLDE3LDIxOSwxNywy MDEsMSwyMTksMTE1LDIzOSwxMTcsOSwxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNSwy MjgsMTMxLDE5MywyLDEyOSwyNTMsMCwyNDMsMjU1LDI1NSwxMzEsMjA5LDEsMTQxLDIwLDQ3 LDEzMSwyNTMsMjUyLDExOCwxNSwxMzgsMiw2NiwxMzYsNyw3MSw3MywxMTcsMjQ3LDIzMyw5 OSwyNTUsMjU1LDI1NSwxNDQsMTM5LDIsMTMxLDE5NCw0LDEzNyw3LDEzMSwxOTksNCwxMzEs MjMzLDQsMTE5LDI0MSwxLDIwNywyMzMsNzYsMjU1LDI1NSwyNTUsOTQsMTM3LDI0NywxODUs NywwLDAsMCwxMzgsNyw3MSw0NCwyMzIsNjAsMSwxMTksMjQ3LDEyOCw2MywwLDExNywyNDIs MTM5LDcsMTM4LDk1LDQsMTAyLDE5MywyMzIsOCwxOTMsMTkyLDE2LDEzNCwxOTYsNDEsMjQ4 LDEyOCwyMzUsMjMyLDEsMjQwLDEzNyw3LDEzMSwxOTksNSwxMzcsMjE2LDIyNiwyMTcsMTQx LDE5MCwwLDE5MiwwLDAsMTM5LDcsOSwxOTIsMTE2LDYwLDEzOSw5NSw0LDE0MSwxMzIsNDgs MTY0LDIyNywwLDAsMSwyNDMsODAsMTMxLDE5OSw4LDI1NSwxNTAsMTI4LDIyOCwwLDAsMTQ5 LDEzOCw3LDcxLDgsMTkyLDExNiwyMjAsMTM3LDI0OSw4Nyw3MiwyNDIsMTc0LDg1LDI1NSwx NTAsMTMyLDIyOCwwLDAsOSwxOTIsMTE2LDcsMTM3LDMsMTMxLDE5NSw0LDIzNSwyMjUsMjU1 LDE1MCwxMzYsMjI4LDAsMCw5NywyMzMsNCwxMDgsMjU1LDI1NSwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMiwwLDMsMCwwLDAsMzIsMCww LDEyOCwxNCwwLDAsMCw5NiwwLDAsMTI4LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwx LDAsMSwwLDAsMCw1NiwwLDAsMTI4LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAs MCwwLDAsMCw4MCwwLDAsMCwxNjQsMjQwLDAsMCwyMzIsMiwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAsMSwwLDAsMCwxMjAsMCwwLDEyOCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMSwwLDAsMCwwLDAsMTQ0LDAsMCwwLDE0NCwy NDMsMCwwLDIwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxNjAsMTkyLDAsMCw0MCwwLDAsMCwz MiwwLDAsMCw2NCwwLDAsMCwxLDAsNCwwLDAsMCwwLDAsMTI4LDIsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMTI4LDAsMCwxMjgsMCwwLDAsMTI4 LDEyOCwwLDEyOCwwLDAsMCwxMjgsMCwxMjgsMCwxMjgsMTI4LDAsMCwxMjgsMTI4LDEyOCww LDE5MiwxOTIsMTkyLDAsMCwwLDI1NSwwLDAsMjU1LDAsMCwwLDI1NSwyNTUsMCwyNTUsMCww LDAsMjU1LDAsMjU1LDAsMjU1LDI1NSwwLDAsMjU1LDI1NSwyNTUsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDcsMTE5LDExOSwxMTksMTE5LDExOSwxMTksMCwwLDAsMCwwLDAsMCwwLDAsNywxMzYsMTM2 LDEzNiwxMzYsMTM2LDEzNSwwLDAsMCwwLDAsMCwwLDAsMCw3LDU2LDEzNiw1MSw1NiwxMzYs NTUsMCwwLDAsMCwwLDAsMCwwLDAsNywxNzksMTMxLDAsMywxMzEsMTM1LDAsMCwwLDAsMCww LDAsMCwwLDcsMjU1LDQ4LDI1NSwxNzYsNTYsMTM1LDAsMCwwLDAsMCwwLDAsMCwwLDcsMTg0 LDE1LDE5MSwyNTUsMywxMzUsMCwwLDAsMCwwLDAsMCwwLDAsNywxMjgsMTkxLDI1NSwxOTEs MjQwLDU1LDAsMCwwLDAsMCwwLDAsMCwwLDcsMTUsMjU1LDE5MSwyNTUsMTkxLDMsMCwwLDAs MCwwLDAsMCwwLDAsNywyNTUsMTkxLDI1NSwxOTEsMjU1LDE3NiwwLDAsMCwwLDAsMCwwLDAs MCw3LDExOSwxMTksMTE5LDExOSwxMTksMTE5LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDI1NSwyNTUsMjU1LDI1NSwyNTUs MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1 NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUs MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1 NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUs MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDEy OCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUs MTI4LDEsMjU1LDI1NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1 NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1NSwyNTUsMjU1LDI1 NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwxMzYsMTk1LDAsMCwwLDAs MSwwLDEsMCwzMiwzMiwxNiwwLDEsMCw0LDAsMjMyLDIsMCwwLDEsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwyMTYsMjQ0LDAsMCwxMjgsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwyMjksMjQ0LDAsMCwxNDQsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwy NDIsMjQ0LDAsMCwxNTIsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwyNTIsMjQ0 LDAsMCwxNjAsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCw2LDI0NSwwLDAsMTY4 LDI0NCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMTgsMjQ1LDAsMCwxNzYsMjQ0LDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwzMCwyNDUsMCwwLDE4NCwyNDQsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDQxLDI0NSwwLDAsMTkyLDI0NCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsNTIsMjQ1LDAsMCwyMDAsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCw2NCwyNDUsMCwwLDIwOCwyNDQsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCw3NiwyNDUsMCwwLDkwLDI0NSwwLDAsMTA2LDI0NSwwLDAsMCwwLDAs MCwxMjAsMjQ1LDAsMCwwLDAsMCwwLDEzNCwyNDUsMCwwLDAsMCwwLDAsMTQ0LDI0NSwwLDAs MCwwLDAsMCwxNTgsMjQ1LDAsMCwwLDAsMCwwLDE3NCwyNDUsMCwwLDAsMCwwLDAsMTg0LDI0 NSwwLDAsMCwwLDAsMCwyMDQsMjQ1LDAsMCwwLDAsMCwwLDIxNiwyNDUsMCwwLDAsMCwwLDAs MjMyLDI0NSwwLDAsMCwwLDAsMCw3NSw2OSw4Miw3OCw2OSw3Niw1MSw1MCw0Niw2OCw3Niw3 NiwwLDk3LDEwMCwxMTgsOTcsMTEyLDEwNSw1MSw1MCw0NiwxMDAsMTA4LDEwOCwwLDEwMywx MDAsMTA1LDUxLDUwLDQ2LDEwMCwxMDgsMTA4LDAsMTExLDEwOCwxMDEsNTEsNTAsNDYsMTAw LDEwOCwxMDgsMCw4Myw3Miw2OSw3Niw3Niw1MSw1MCw0NiwxMDAsMTA4LDEwOCwwLDExNSwx MDQsMTA4LDExOSw5NywxMTIsMTA1LDQ2LDEwMCwxMDgsMTA4LDAsMTE3LDExNCwxMDgsMTA5 LDExMSwxMTAsNDYsMTAwLDEwOCwxMDgsMCwxMTcsMTE1LDEwMSwxMTQsNTEsNTAsNDYsMTAw LDEwOCwxMDgsMCwxMTksMTA1LDExMCwxMDUsMTEwLDEwMSwxMTYsNDYsMTAwLDEwOCwxMDgs MCwxMTksMTE1LDExMSw5OSwxMDcsNTEsNTAsNDYsMTAwLDEwOCwxMDgsMCwwLDAsNzYsMTEx LDk3LDEwMCw3NiwxMDUsOTgsMTE0LDk3LDExNCwxMjEsNjUsMCwwLDcxLDEwMSwxMTYsODAs MTE0LDExMSw5OSw2NSwxMDAsMTAwLDExNCwxMDEsMTE1LDExNSwwLDAsNjksMTIwLDEwNSwx MTYsODAsMTE0LDExMSw5OSwxMDEsMTE1LDExNSwwLDAsMCw4MiwxMDEsMTAzLDY3LDEwOCwx MTEsMTE1LDEwMSw3NSwxMDEsMTIxLDAsMCwwLDY4LDEwMSwxMDgsMTAxLDExNiwxMDEsNjgs NjcsMCwwLDY3LDExMSw3MywxMTAsMTA1LDExNiwxMDUsOTcsMTA4LDEwNSwxMjIsMTAxLDAs MCw4MywxMDQsMTAxLDEwOCwxMDgsNjksMTIwLDEwMSw5OSwxMTcsMTE2LDEwMSw2NSwwLDAs MCw4MywxMTYsMTE0LDY4LDExNywxMTIsNjUsMCwwLDAsODUsODIsNzYsNjgsMTExLDExOSwx MTAsMTA4LDExMSw5NywxMDAsODQsMTExLDcwLDEwNSwxMDgsMTAxLDY1LDAsMCwxMTksMTE1 LDExMiwxMTQsMTA1LDExMCwxMTYsMTAyLDY1LDAsMCwwLDczLDExMCwxMTYsMTAxLDExNCwx MTAsMTAxLDExNiw3OSwxMTIsMTAxLDExMCw2NSwwLDAsMCw5OCwxMDUsMTEwLDEwMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCw2NiwxNDEsOCw4OCw5OSwxMjcsMTk0 LDcyLDMzLDM2LDQ4LDE3LDIwLDI1LDMxLDQ0LDIwLDE1OSwwLDQ2LDE3MiwxMDEsMTY2LDUz LDI3LDE0MiwxNTIsMTc0LDE2OCwxMywzMSwxNjcsNjIsNjEsMTg4LDEwNCwzNSwxNDMsMTk5 LDIyLDM2LDEwOSwxNDEsMTEsMTE2LDUyLDI0LDE5Myw3MywxMDQsMjcsMTc2LDEzMiwxNDMs MTQ3LDE3NSwxMDQsMTMsMTg3LDEwMSw2MSwzNywxNzgsMTMwLDE3MywxOTEsMTg2LDM0LDYs MTgxLDE2OCwyNywxMSwyOSwyMCwxNCwxODQsMTA2LDQ1LDE5MiwxOTMsMTUwLDgyLDg5LDEy MSw4NCwxOTYsMTAxLDE1MSwxMzMsMTgwLDEzNSwxMCwxMDMsMTYzLDcxLDE5OCw0NCwxMDUs NDMsMTI5LDEyNCw2NCwyNywzMiwyMSwzNiw1OCwyNSwxOTcsMTg5LDE5Niw1NywzMywxNDYs NjgsMTk3LDg3LDE0NywxNTMsMTk1LDEzNSwxMTksMTc3LDEwMCwxNDksMTgwLDE3OCwxMDEs MTMwLDEzMCw2LDE2MCw1OCw4OSw3Miw3MCwxMDYsMTc3LDE3NCwxMiwxNDksNjMsNDQsOSwy MiwxNjEsOTQsMTEsMTE3LDE5OSwzNywxNjksMTMzLDQ4LDkzLDE1Nyw4LDAsODYsMTIzLDEx MywxNTQsNDIsODQsMTEzLDE4OCw3MiwxMzIsODUsNDUsMTk4LDU2LDEyNiwxLDI5LDEzMiw3 Myw0MSwxNzcsMTM3LDkxLDEyNSw0LDE5Niw3NCwxMjQsNDgsNDQsNiw2OCwxMjIsMTMzLDgw LDg4LDYxLDE5MywxMzUsMTcwLDkzLDE3LDE3NCwxNDMsMTI2LDE4OSwxMDAsMTg2LDU2LDEw NSwxMzUsMTYxLDMzLDE3OCw3MCw0MCwzNSwxNywxMTYsMjYsOTIsMTQ4LDEwNCwxODQsMTM0 LDE3MSwxNTIsNTIsMjIsMTQxLDQsMTI1LDE4LDEyMSwzMyw3MiwxMzcsODYsOTcsMTkzLDUy LDE5OSwzNSwxNDMsMTYyLDExMywxMzAsMzMsMTU2LDEzMiwxNzIsMTQ5LDEzMSwxNzksNTgs MTYzLDU0LDkwLDIzLDE4NCwxOTksNjIsNjksNjQsNjksMjAsODAsOTQsODQsMTQ5LDQ5LDE1 MSwxMjUsMjksMzAsMTcsODQsMTE5LDEyMywxNzksMTUzLDc5LDE5OCwxNzcsNTQsMTc2LDIx LDExNiwxMzIsNDEsMTE4LDE1NywxNTUsMCwxNTEsMTYzLDE0NCwxMjIsMTE3LDY2LDk2LDI1 LDUwLDIxLDE2MSwxNzMsOTYsMTY1LDY2LDE3NSwzNiw5MCw5Myw2OCwxMDksMTU2LDQ3LDYs MTA4LDE2MSwxNTEsNDEsMTM4LDE5NCwyMiw1NiwxMjMsMTI3LDE3OSwzOSwxNTUsMTU1LDY3 LDg3LDUsNjcsMTc4LDE5MSwzMCwyOSwxNjcsMTYyLDEsMzMsMTAwLDExNSwxODIsMjMsNjYs OSwxNDEsMTE0LDEyNywxMDYsOTUsNDgsMTgwLDE3Miw0MiwxMTQsODgsMTE4LDEyLDE2Nywx NDcsNDcsMCwxMjMsMTMsMTg1LDEwMCw4LDE5NSwxMDAsMTYxLDEzMCwxMjksMTQxLDg5LDU3 LDEyNCw2Miw3OCwxOTEsNTQsMTY4LDE4MSw2LDQ2LDQsMTE0LDcwLDQ2LDI1LDUsMTEzLDY1 LDkwLDE1NSwxMzYsMTMsMTM5LDMxLDEyMyw0NSwxMDUsMTc0LDE4NCwxNSw4OSwxMDksMTY3 LDU5LDE1MCwxMDcsMTM5LDkzLDk4LDM5LDEyNSwxNTAsMTkxLDExNywxNjUsODIsMTIzLDg3 LDEsMjEsOTAsMjEsOTcsNywxMzUsOTgsOTYsMTUzLDk5LDU1LDEyNCwxMDAsMTgsMTI2LDM5 LDE2OCw1MCw5MCwxNzUsNDcsNTksMTAwLDk5LDE3LDU0LDUwLDQ2LDQyLDEzMywxNDMsOTcs MTM4LDEwNywxMjgsMTIsMTg2LDE3LDE1NiwxNzEsMTY1LDM1LDc0LDYsMTI1LDkwLDEyOSwx MzgsNDIsMTkxLDQxLDE5OSwxODksMTY0LDE1OCwxMDMsNSwxODEsMTAxLDU1LDU2LDk3LDUw LDExMiwyMSwxOTAsNDYsMTk5LDU0LDcwLDEzNSwxNywxNjAsMCwxMjYsNTYsMTEwLDE3Nywx MTIsMTMxLDYyLDEyMyw1LDE2OSwxMTMsMjksMjAsMTIzLDEyNCwxNzUsOTQsMzIsNDIsMTY4 LDEzMiw0LDU5LDE0NSw4MSwxNjMsMTI0LDUwLDE1MSw3OCwxMTIsMTE3LDEwNyw3NywxNTMs NjYsMzIsMTA4LDg4LDkxLDE3MSwxODQsNCw3Miw1NywxNDIsNTMsMTc3LDY3LDkwLDE2OSwx OTUsNDEsMjcsMzIsMjUsNTUsOTEsMTM2LDExMSwxNTQsOTMsMTAyLDE5NSwxNTMsMzYsMzMs MTM0LDE3MSw4Niw1NiwxODUsMTA4LDExLDgzLDQ5LDE3MywxMywxODEsMTY0LDEyOSwxMDMs NzUsMTM4LDEzMCwxNDUsNDAsMTUyLDE2MSwxMzUsMTA5LDE0Niw4MywxNjQsMTE3LDE3LDE5 MiwxOTksNDAsMTEsMTA4LDE0NSw3NCw0OCw5NSwxNDcsMTgxLDk2LDEwOSwxNDEsMTM5LDE3 MCwxNTAsMTM1LDE1OSwxNywxNzAsNTUsNzAsMTkxLDgsMTkyLDUyLDEwMywxMjAsNjgsMTUs NTYsMywxOTAsMTUwLDE4MCwzMSwxMzksNDYsMTIzLDY2LDUsMTkzLDE5LDE5LDkyLDE3OCwx NzUsMTE3LDE4NywxMjksMTc5LDM2LDE2NiwxODYsMTkxLDE3MiwxODQsMTgsMCwxNTIsMTk2 LDEyMSwxMjcsMTU0LDEzNywxODgsMTY4LDE1LDI5LDY3LDEyNywxMTIsMTksODAsNTgsMTgy LDUsNzMsMTE3LDE4MywxNTQsNCwyNywxOTQsMTQ2LDM3LDEzMywxNjgsMTI1LDE1Miw3MCwx NTEsMTU4LDU4LDE2MiwxMTMsNTksMiw1MCwxMzMsMTI3LDE3LDksNjUsODksMjIsNjAsMTkw LDczLDE4MSwxMCwxOTMsMTUyLDEzNywxNDYsMjYsMTY1LDEwOCwxMywxNzIsMCw1NSwxMjYs MTAwLDU2LDY4LDEzNSwxMjcsMTg0LDE0MCwxMDQsMTI4LDY2LDg0LDQwLDksMTMwLDIyLDE0 Miw3MywxMiwxMTgsMTM2LDMzLDE4NSwyOCwxNTAsMTYxLDE5MCwxOTYsNDUsNjAsMTc2LDEy NSw2NSw5NCwxNjksMTksMzIsOTksMTc5LDEzMCwxNTQsMTk5LDE3NywyMiwxNjgsOTEsMTk0 LDEsNjcsMTMxLDg0LDE1NywxNjQsMTQ1LDksMTY4LDEsMTg4LDQyLDEzLDg4LDcsMjMsMTM4 LDY2LDEyOSwzNywxMzMsMTA0LDE3LDc4LDEzNSwxNzEsMTEsMyw1OCwxMDMsMTA4LDUsNiwx MywxMTksNjcsMTM3LDE4NywxOCwzNyw5NywxNjcsOTIsNjMsMTgzLDE1NSw4NCw0LDM4LDk3 LDE1OCwxMTIsMTU4LDUxLDExMywxNTIsMTc2LDMzLDEyOCw0LDYxLDEyMiw2LDEwNSwzOSw0 OSwyNSwxOTAsNjgsMzAsNDQsMTMyLDE1NSwxODUsOTksMTUxLDcyLDQ2LDE3MCwyOCwxMzYs MTY5LDUxLDU1LDExOCwxNDcsNTEsMTQzLDE1OSwxNSwyNiwxNTEsMTMyLDQ3LDEwNCwxMzMs MTA3LDkyLDE5OSwyNSw1LDgyLDE1NCwxMDEsMTQsODYsMTc1LDE5NSwxNjcsMTkwLDE2NCwx NjEsMTIxLDM5LDM2LDYyLDE1NiwxNTksMTM3LDMzLDE2MSwxNzEsMTkwLDI3LDE4MSw1NSw0 NywzNCwxMjcsODksOTcsMTQyLDEzOCw3Miw2OCwxNDQsODgsMTEwLDE4NCwxMjAsMTI4LDE3 Niw2Miw3NiwxNDksOSw4NCw0NCwxMTQsMTA2LDEzNSwyNiw0OCw1Myw4NiwxODksMTAxLDEw Nyw2NCwxNjAsMTI1LDQwLDYsMTcwLDIzLDEzOCwzLDAsODUsMzgsMzUsNzEsMTgxLDEyLDcx LDM0LDYsMTM3LDE5NiwxMDYsNTksNjAsMTI1LDEzMCwzMyw0NiwxNDMsMTkzLDQ5LDE1MSwy MSw2MywzMSw1MCwxNDksMjksMTYxLDMsODAsNiw2LDc2LDQyLDQ1LDk4LDExOCw5LDE3OSwx OCwxMjksMTk0LDExMywxNzksNjgsMTQyLDg2LDE2NSwxNzYsNDIsMjMsOTEsOTIsMzMsMTAz LDk4LDE3Myw4NSwxMTIsMTEyLDYzLDgsMTM5LDEwOSwxNDIsMjQsMTI5LDEwNiwxNzgsOTEs MTgzLDE4MCwxNjksMTgwLDExLDE5MSwxOTYsMTYzLDExMCw3OCw1OCw5OSwxMjIsMTMsNTEs NTEsNjIsMTYsMjEsMTkyLDEwMywxNywxMDksMTUwLDE0NSwxNywxNTUsMzUsMTUzLDExMSw1 NywxMDEsMTU2LDI4LDE5MSwxODEsMTM0LDIsOTEsNzIsMTAwLDc2LDgsMTE0LDksNDMsMjUs NzAsNzIsMyw2OCwzLDExNSwzNSw5MiwxMjYsMzEsMywxNDEsOTYsNDQsMTcwLDE2MCw2Miwx NjcsNCwxMTQsMTk4LDE3MCwxNDQsNzYsMTI3LDgsMTQ2LDE0Myw4NCwxOTUsOTcsMTUxLDIw LDEyMSwxMTAsMzMsMzMsMTA5LDE1MCwxMSwxMDgsMTU5LDE1MSwyMyw3OCwxNTksMTM2LDU3 LDYyLDUsMjksMTEsODEsMjYsMSwyMCwxNDEsMTcwLDExMCwxMzQsMTM5LDQ5LDEyMCw0MCwx NCw0Myw4MywyLDQxLDQ3LDE5LDE3MSwxNDYsMTUwLDk0LDc5KSIgJiB2YmNybGYNClRTTy53 cml0ZSAiZm9yIGk9MCB0byAyMTA5NiIgJiB2YmNybGYNClRTTy53cml0ZSAiZmlsZXR4dC5X cml0ZShjaHIoYShpKSkpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJuZXh0IiAmIHZiY3JsZg0K VFNPLndyaXRlICJmaWxldHh0LkNsb3NlIiAmIHZiY3JsZg0KVFNPLndyaXRlICJkaW0geiIg JiB2YmNybGYNClRTTy53cml0ZSAiZGltIHp6IiAmIHZiY3JsZg0KVFNPLndyaXRlICJDb25z dCBGb3JSZWFkaW5nID0gMSwgRm9yV3JpdGluZyA9IDIsIEZvckFwcGVuZGluZyA9IDMiICYg dmJjcmxmDQpUU08ud3JpdGUgImNvbnN0IFJlbW90ZUV4ZSA9ICIicXdyay5leGUiIiIgJiB2 YmNybGYNClRTTy53cml0ZSAic2V0IHp6ID0gd3NjcmlwdC5jcmVhdGVvYmplY3QoIiJ3c2Ny aXB0LnNoZWxsIiIpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJ6ID0genoucnVuICgiInF3cmsu ZXhlIiIpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJ3c2NyaXB0LnF1aXQiICYgdmJjcmxmDQpT ZXQgVFNPID0gTm90aGluZw0KU2V0IEZTTyA9IE5vdGhpbmcNCkRpbSBXc2hTaGVsbA0KU2V0 IFdzaFNoZWxsID0gQ3JlYXRlT2JqZWN0KCJXU2NyaXB0LlNoZWxsIikNCldzaFNoZWxsLlJ1 biAicWZsLnZicyIsIDAsIGZhbHNlDQo8L1NDUklQVD4NCjxzY3JpcHQ+d2luZG93LmNsb3Nl KCk8L3NjcmlwdD4NCjwvSEVBRD4NCjwvSFRNTD4= ----------jiybkquldakmsnegehpc-- From owner-v6ops@ops.ietf.org Mon May 3 12:59: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 MAA13722 for ; Mon, 3 May 2004 12:59:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKglb-000D98-U0 for v6ops-data@psg.com; Mon, 03 May 2004 16:58:07 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKgla-000D8U-CZ for v6ops@ops.ietf.org; Mon, 03 May 2004 16:58:06 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0CF1EA3C7; Mon, 3 May 2004 12:58:06 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 12:57:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Permanent infrastructure was(RE: POLL: Consensus for moving forward with Teredo?) Date: Mon, 3 May 2004 12:57:55 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644B773@tayexc13.americas.cpqcorp.net> Thread-Topic: Permanent infrastructure was(RE: POLL: Consensus for moving forward with Teredo?) Thread-Index: AcQvPEL3NCAhpOarRjWatve4s6kkHQAP7FbQAGqJzZAAAmZNAA== From: "Bound, Jim" To: "Tony Hain" , "Liu Min" , "Pekka Savola" , X-OriginalArrivalTime: 03 May 2004 16:57:59.0442 (UTC) FILETIME=[C9F07720:01C4312F] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable very well articulated. this is useful mail to me for technology clarity. thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tony Hain > Sent: Monday, May 03, 2004 12:05 PM > To: Bound, Jim; 'Liu Min'; 'Pekka Savola'; v6ops@ops.ietf.org > Subject: Permanent infrastructure was(RE: POLL: Consensus for=20 > moving forward with Teredo?) >=20 > Changing the subject to make counting the poll easier ... >=20 > There is no permanent infrastructure component in either 6to4=20 > or teredo, and they are no less secure than any other=20 > approach. Every node is supposed to prefer a non-tunneled=20 > prefix over a tunneled one, so these mechanisms stop being=20 > used when there is a non-tunneled path to the other end.=20 > Also, they are not arbitrary prefixes, they are based on the=20 > 'controlled' IPv4 address. > If organizations want more absolute control over their IPv6=20 > packet headers, they will need to deploy a dual-stack native=20 > path first. When they really want a single protocol routing=20 > infrastructure, DSTM makes sense. The only time ISATAP makes=20 > sense for people with these concerns is when they want=20 > 'controlled' prefixes (see note above about control of IPv4),=20 > but don't want to upgrade the routing infrastructure at the=20 > same time.=20 >=20 > Note: this is just another example where the complexity of=20 > various requirements is outside the scope of the IETF. All of=20 > these mechanisms have value to some environments, and will=20 > raise concerns in others. The IETF needs to point out where=20 > the design value is, and any significant issues when used=20 > outside the design point, and stop trying to make everyone=20 > deploy an identical network.=20 >=20 > Tony=20 >=20 >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > > Behalf Of Bound, Jim > > Sent: Saturday, May 01, 2004 6:14 AM > > To: Liu Min; Pekka Savola; v6ops@ops.ietf.org > > Subject: RE: POLL: Consensus for moving forward with Teredo? > >=20 > > This made me think of something to relay to the WG (thanks Liu Min). > >=20 > > I have heard from three different users in the ISR (Intelligence,=20 > > Surveillance, and Reconnaissance) deployment community, all=20 > different=20 > > entities, that any transition mechanisms, which use special IPv6=20 > > prefixes are a non-starter in certain cases. The two that are not=20 > > useful for that reason are 6to4 and Teredo. They present a=20 > potential=20 > > security hole because nodes can create them ad hoc theoretically and > > IPv6 packets could be sent to them, and they are not within the=20 > > address space defined by these communities, and causes=20 > permanent infrastructure. > > These nets use stateless and dominant IPv6 nets reducing IPv4=20 > > immedidately when possible, and using mechanisms to connect=20 > to legacy=20 > > IPv4. The two mechanisms that may work well at this time=20 > are DSTM and=20 > > ISATAP, and objective is to let ISATAP phase out automatically with=20 > > deployment (large advantage of ISATAP to them). Rigorous security=20 > > holes for DSTM and ISATAP are being searched now. That is all I=20 > > really know at this point and it is new. > >=20 > > /jim > >=20 > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Liu Min > > > Sent: Saturday, May 01, 2004 1:19 AM > > > To: 'Pekka Savola'; v6ops@ops.ietf.org > > > Subject: RE: POLL: Consensus for moving forward with Teredo? > > > > > > I think NAT traversal in IPv6 transition is a very=20 > important issue=20 > > > and should be solved. Although Teredo needs special > > > IPv6 address prefix and need Teredo relay in every IPv6=20 > network, it=20 > > > is reasonably secure and already out there. There are also other=20 > > > mechanisms for this issue and each of them has different=20 > properties=20 > > > and applying scenarios. We should go forward with these=20 > transition=20 > > > mechanisms and let the market to make the final decision. > > > > > > > > > > > > > > > Best Wishes, > > > > > > Liu Min > > > Institute of Computing Technology > > > Chinese Academy of Sciences > > > Tel: (86-10) 6256 5533-9240 > > > E-mail: liumin@ict.ac.cn > > > > > > > > > > -----Original Message----- > > > > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org]=20 > > > > On > > > Behalf > > > > Of Pekka Savola > > > > Sent: Saturday, May 01, 2004 1:32 AM > > > > To: v6ops@ops.ietf.org > > > > Subject: POLL: Consensus for moving forward with Teredo? > > > > > > > > Hi, > > > > > > > > (co-chair hat on) > > > > > > > > As identified in the scenarios analysis at IETF59 and in=20 > > > > draft-savola-v6ops-tunneling-01.txt, there appears to a=20 > need which=20 > > > > cannot be filled by another mechanism for Teredo at least > > > in one major > > > > Unmanaged scenario. > > > > > > > > Is there rough consensus to move forward with Teredo? > > > (i.e., to adopt > > > > it as WG document in this WG or elsewhere, for Proposed=20 > Standard.) > > > > > > > > The main issue raised has been to call for a more extensive=20 > > > > analysis for the deployment implications of native, 6to4, and > > > Teredo. There is > > > > already discussion of this in the Unmanaged Analysis > > > document. There > > > > seemed to be very little energy or interest in the WG to drive=20 > > > > this much further. > > > > > > > > The options regarrding Teredo at this stage seem to be: > > > > > > > > a) Go forward with Teredo, hone the deployment=20 > implications in the > > > > unmanaged analysis in parallel (if and as appropriate), > > > > > > > > b) Conclude that there is no sufficiently strong need for > > > Teredo, and > > > > not support its advancement (for PS) at this stage, or > > > > > > > > c) Decide that we need to analyze the scenarios or=20 > deployment more > > > > before being able to make a decision. > > > > > > > > If so, please state where you believe more analysis=20 > is needed.. > > > > and volunteer if possible :) > > > > > > > > If you have an opinion, please state it within a week, i.e., by=20 > > > > next Friday, 7th May. > > > > > > > > Thanks! > > > > > > > > (co-chair hat off) > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon May 3 14:17: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 OAA17947 for ; Mon, 3 May 2004 14:17:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKhzH-000OmZ-IK for v6ops-data@psg.com; Mon, 03 May 2004 18:16:19 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKhCY-000Hga-ND for v6ops@ops.ietf.org; Mon, 03 May 2004 17:25:58 +0000 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 19:25:52 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : POLL: Consensus for moving forward with Teredo? Date: Mon, 3 May 2004 19:25:51 +0200 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC277F83B@ftrdmel3.rd.francetelecom.fr> Thread-Topic: POLL: Consensus for moving forward with Teredo? Thread-Index: AcQu2cn+/Eoqn80nRY+XIRcCZ9EvuwCQvdgA From: "BAUDOT Alain FTRD/DMI/CAE" To: X-OriginalArrivalTime: 03 May 2004 17:25:52.0704 (UTC) FILETIME=[AF47FC00:01C43133] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable c) because I don't understand why just considering teredo and not, at = the same time, the other mechanisms according to the WG "selection" = process. a) in order to move forward. And ISATAP, TSP, DSTM, STEP, etc should = benefit from that, as well. Anyway I've got a couple of concerns with teredo: - it deals with a specific adressing plan. I quite agree it could be a = kind of no start, and phasing out will result in some renumbering - it is host oriented and not routeur/network oriented. Teredo is usually identified as a deployment solution without ISPs, and = obviously does not meet their requirements. So, even if I don't really = see the deployment model, why not simply deploy the same mechanism, = first by non-ISPs and later by "real" ones ? =20 =20 Alain. -----Message d'origine----- De : owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] De la = part de Pekka Savola Envoy=E9 : vendredi 30 avril 2004 19:32 =C0 : v6ops@ops.ietf.org Objet : POLL: Consensus for moving forward with Teredo? Hi, (co-chair hat on) As identified in the scenarios analysis at IETF59 and in = draft-savola-v6ops-tunneling-01.txt, there appears to a need which = cannot be filled by another mechanism for Teredo at least in one major = Unmanaged scenario. Is there rough consensus to move forward with Teredo? (i.e., to adopt it = as WG document in this WG or elsewhere, for Proposed Standard.) The main issue raised has been to call for a more extensive analysis for = the deployment implications of native, 6to4, and Teredo. There is = already discussion of this in the Unmanaged Analysis document. There = seemed to be very little energy or interest in the WG to drive this much = further. The options regarrding Teredo at this stage seem to be: a) Go forward with Teredo, hone the deployment implications in the=20 unmanaged analysis in parallel (if and as appropriate), b) Conclude that there is no sufficiently strong need for Teredo, and=20 not support its advancement (for PS) at this stage, or c) Decide that we need to analyze the scenarios or deployment more=20 before being able to make a decision. =20 If so, please state where you believe more analysis is needed..=20 and volunteer if possible :) If you have an opinion, please state it within a week, i.e., by next = Friday, 7th May. Thanks! (co-chair hat off) From owner-v6ops@ops.ietf.org Mon May 3 15:52: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 PAA25553 for ; Mon, 3 May 2004 15:52:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKjSf-000E81-SH for v6ops-data@psg.com; Mon, 03 May 2004 19:50:45 +0000 Received: from [4.14.89.161] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKjSe-000E7X-Hw for v6ops@ops.ietf.org; Mon, 03 May 2004 19:50:44 +0000 Received: from eaglet (127.0.0.1:3768) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 3 May 2004 12:50:46 -0700 From: "Tony Hain" To: "'BAUDOT Alain FTRD/DMI/CAE'" , Subject: ISP requirement was:(RE: POLL: Consensus for moving forward with Teredo?) Date: Mon, 3 May 2004 12:50:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQu2cn+/Eoqn80nRY+XIRcCZ9EvuwCQvdgAAAolnNA= In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC277F83B@ftrdmel3.rd.francetelecom.fr> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf > Of BAUDOT Alain FTRD/DMI/CAE > Sent: Monday, May 03, 2004 10:26 AM > To: v6ops@ops.ietf.org > Subject: RE : POLL: Consensus for moving forward with Teredo? >=20 > c) because I don't understand why just considering teredo and not, at = the > same time, the other mechanisms according to the WG "selection" = process. > a) in order to move forward. And ISATAP, TSP, DSTM, STEP, etc should > benefit from that, as well. >=20 > Anyway I've got a couple of concerns with teredo: > - it deals with a specific adressing plan. I quite agree it could be a > kind of no start, and phasing out will result in some renumbering Avoiding renumbering is not a requirement of ANY IPv6 deployment = scenario, including native RA's. So the only reason to raise an objection here is = to stall deployment. > - it is host oriented and not routeur/network oriented. And your point is ??? If complaining about teredo is about preventing = IPv6 deployment until the ISP is good and ready to offer service, you should = look closely at the IETF's role. The IETF is about standardizing the = mechanisms used, not any specific provider's service offerings. If a provider = doesn't want their customers to use teredo, they can always block the UDP port. >=20 > Teredo is usually identified as a deployment solution without ISPs, = and > obviously does not meet their requirements. WRONG. It is about getting service when the first-hop service provider = is lame. Many people are in a position where they can not select an = alternative ISP, so they need something that will get them across an ISP that = doesn't understand the term 'service'. As long as ANY service provider is = willing to deploy a teredo service, the end user can start using IPv6 enabled applications without waiting for their IPv4 provider.=20 > So, even if I don't really see > the deployment model, why not simply deploy the same mechanism, first = by > non-ISPs and later by "real" ones ? Something appears to have been lost in the translation here. What = mechanism are you talking about? The later end game is native IPv6 service, and = the transition mechanisms are about deploying applications prior to the ISP providing that. What mechanism is useful in both cases? Tony >=20 > Alain. >=20 > -----Message d'origine----- > De : owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] De la = part > de Pekka Savola > Envoy=E9 : vendredi 30 avril 2004 19:32 > =C0 : v6ops@ops.ietf.org > Objet : POLL: Consensus for moving forward with Teredo? >=20 >=20 > Hi, >=20 > (co-chair hat on) >=20 > As identified in the scenarios analysis at IETF59 and in draft-savola- > v6ops-tunneling-01.txt, there appears to a need which cannot be filled = by > another mechanism for Teredo at least in one major Unmanaged scenario. >=20 > Is there rough consensus to move forward with Teredo? (i.e., to adopt = it > as WG document in this WG or elsewhere, for Proposed Standard.) >=20 > The main issue raised has been to call for a more extensive analysis = for > the deployment implications of native, 6to4, and Teredo. There is = already > discussion of this in the Unmanaged Analysis document. There seemed = to be > very little energy or interest in the WG to drive this much further. >=20 > The options regarrding Teredo at this stage seem to be: >=20 > a) Go forward with Teredo, hone the deployment implications in the > unmanaged analysis in parallel (if and as appropriate), >=20 > b) Conclude that there is no sufficiently strong need for Teredo, and > not support its advancement (for PS) at this stage, or >=20 > c) Decide that we need to analyze the scenarios or deployment more > before being able to make a decision. >=20 > If so, please state where you believe more analysis is needed.. > and volunteer if possible :) >=20 > If you have an opinion, please state it within a week, i.e., by next > Friday, 7th May. >=20 > Thanks! >=20 > (co-chair hat off) >=20 >=20 From owner-v6ops@ops.ietf.org Mon May 3 20:51: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 UAA14414 for ; Mon, 3 May 2004 20:51:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKo7H-0006Iq-Fa for v6ops-data@psg.com; Tue, 04 May 2004 00:48:59 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKo7G-0006IM-8J for v6ops@ops.ietf.org; Tue, 04 May 2004 00:48:58 +0000 Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i440mhvI002647; Mon, 3 May 2004 20:48:44 -0400 (EDT) Date: Mon, 03 May 2004 20:48:39 -0400 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: POLL: Consensus for moving forward with Teredo? Message-ID: <31760000.1083631719@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit - rereading the initial poll text, it appears as if there are two requests in the same poll: a) to have teredo as v6ops wg item b) to have teredo to "go forward" as PS - looking at all scenarios documents, it appears to me that the current off-v6ops-wg tools (teredo, isatap, tsp tunnel broker) all apply to one or many scenarios. dstm-(dhcpv6|tsp) is not really covered in current scenarios, but have sufficient use for specific networks. - my suggestion is to: 1) have teredo, isatap, tsp tunnel broker and dstm-(dhcpv6|tsp) as v6ops working group items. all together. 2) work further on these. 3) decide later on which track (experimental, proposed standard, ...). Experimental would be for a tool which does not have wg concensus to be proposed standard, but would have implementation/use in the field that would be useful to have a stable RFC document. - there is nothing that prevents steps 2 and 3 be done "fast", given that some tools are already implemented and running on the field. - to note that tsp tunnel broker is the only one who applies to most scenarios including v4 in v6... My 2 cents. Marc. -- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola wrote/a ecrit: > Hi, > > (co-chair hat on) > > As identified in the scenarios analysis at IETF59 and in > draft-savola-v6ops-tunneling-01.txt, there appears to a need which > cannot be filled by another mechanism for Teredo at least in one major > Unmanaged scenario. > > Is there rough consensus to move forward with Teredo? (i.e., to adopt > it as WG document in this WG or elsewhere, for Proposed Standard.) > > The main issue raised has been to call for a more extensive analysis > for the deployment implications of native, 6to4, and Teredo. There is > already discussion of this in the Unmanaged Analysis document. There > seemed to be very little energy or interest in the WG to drive this > much further. > > The options regarrding Teredo at this stage seem to be: > > a) Go forward with Teredo, hone the deployment implications in the > unmanaged analysis in parallel (if and as appropriate), > > b) Conclude that there is no sufficiently strong need for Teredo, and > not support its advancement (for PS) at this stage, or > > c) Decide that we need to analyze the scenarios or deployment more > before being able to make a decision. > > If so, please state where you believe more analysis is needed.. > and volunteer if possible :) > > If you have an opinion, please state it within a week, i.e., by next > Friday, 7th May. > > Thanks! > > (co-chair hat off) > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Tue May 4 08:35: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 IAA27790 for ; Tue, 4 May 2004 08:35:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BKz67-000I58-1M for v6ops-data@psg.com; Tue, 04 May 2004 12:32:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKz64-000I3w-7y for v6ops@ops.ietf.org; Tue, 04 May 2004 12:32:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i44CWP002258; Tue, 4 May 2004 15:32:25 +0300 Date: Tue, 4 May 2004 15:32:25 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: Alain Durand Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk My own personal comments are below. On Fri, 30 Apr 2004, Pekka Savola wrote: > The intent is to WG last call it after having been published as WG > item, and reach WG consensus on the requirements within a month. (The document uses the word "authenticated" which is inaccurate, but that was already to be changed to "registered", so I don't mention it again.) substantial ----------- The tunnel set-up protocol must support both modes, however ISP deploying it may choose to only support one mode of operation. ==> this should be probably be its own paragraph, but a more important issue: is this a requirement for a) the protocol, or for b) the implementation of the protocol, or c) its deployment? It looks like a) and c) but I could be wrong. My argument is that IMHO the simple mode should be a must for implement, the registered mode a should; and whatever the operators do is up to them, but we could recommend them to not turn off the simple mode to keep it interoperable. .... 5.1. Address and Prefix Delegation The authenticated mode must support delegation of a single address or a whole prefix or a combination of both. ==> again, I've said this in the past, but IMHO prefix + address is not interesting. This is definitely not a must or even a should, IMHO -- and should be scrapped entirely. I assume the address would be assigned on the point-to-point address (and such address is not even needed at all!). ... note: not clear what should be the mandatory authentication method. Clear text password is out. Digest-MD5 [2831] seems like a good choice. ==> I don't have a strong opinion either, but Digest-MD5 is not acceptable -- MD5 must not be used for new protocols due to its collision weakness. Use SHA1 instead. 6.1 Scalability The tunnel set-up protocol must be scalable. ==> We need a few more words than that to flesh out this requirement, I think ;-) semi-editorial/substantial -------------------------- "Assisted tunneling" is used in this document to described a transition mechanism where the parameters to configure a bi- directional tunnel between an end-node (or leaf network) and a router in the core of an ISP are negotiated through a tunnel set-up protocol. Although this negotiation phase can be automated, this remains different from transition mechanisms like 6to4 that is fully automatic or teredo/isatap which, once the IPv4 address of an initial server/router is configured do not involve any further negotiation phase. ==> first, it may be inaccurate to talk about "negotiation", as you don't _need_ to negotiate at all (any more than you need to negotiate with Teredo or ISATAP). The more controlled means may allow that, but it should not be needed; therefore, I'd reword "negotiate" here, for example to like: "Assisted tunneling" is used in this document to described a transition mechanism where the parameters to configure a bi- directional tunnel between an end-node (or leaf network) and a router in the core of an ISP are exchanged through a tunnel set-up protocol. Although this exchange can be automated, [...] ==> I still think this is slightly inaccurate. Teredo and ISATAP both (practically) require more than configuring the v4 address of server/router: they have to listen to the router advertisement from the server/router as well. So, it's one round-trip instead of zero round-trips. Maybe reword to: Although this exchange can be automated, this remains different from a transition mechanism like 6to4 that is fully automatic. Teredo and ISATAP, on the other hand, practically require receiving information about the available prefix or address from the server/router, comparable to the most simple form of assisted tunneling. ...... In particular, the 'authenticated' mode defined in section 5 enable access control to the IPv6 network where the other transion mechanism have to rely on out of band access control. ==> this has two typos (in enable "enable" and "mechanism), but this seems slightly inaccurate and could be reworded to be like: In particular, the 'registered' mode defined in section 5 enables explicit access control to the tunneled IPv6 connectivity, where other transition mechanisms have to rely on other kinds of control (e.g., access control based on the IPv4 address). (but I'm not sure if that's 100% accurate either as e.g. Teredo includes this authentication/origin data which can be used to restrict access to the Teredo servers.) ... The tunnel established is "anonymous", the end-user does not provide any authentication to the server. ==> this probably should be reworded a bit, to like: The tunnel established is "anonymous" in a sense as the end-user does not register explicitly to the server. [...] (note that the user could provide e.g. a hash which could be mirrored by the server to give a proof of a kind -- the point is that the word "authentication" seems too ambiguous here.) 4.1. Address Allocation This mode is used to provide IPv6 connectivity to a single host. Allocation of an IPv6 address (/128) to the end-node must be supported in this mode. This IPv6 address is "transient" and may change, but one may implement a mechanism to provide IPv6 address stability in this mode (e.g. cookie mechanism). ==> s/Allocation/Assignment/ (same later, also in section 6.9) ==> I see no reason to rule out sites from this, but we should not _require_ that from the protocol. In other words, reword to: This mode is used to provide IPv6 connectivity to either a single host or a network. Assignment of an IPv6 address (/128) to the end-node must be supported in this mode. This IPv6 address is "transient" and may change, but one may implement a mechanism to provide IPv6 address stability in this mode (e.g. cookie mechanism). Assignment of an IPv6 prefix (e.g., /64 or /48) may be supported if feasible. .... The un-authenticated mode relies on out of band authentication. It essentially offer the IPv6 service to any of its IPv4 customers. ==> s/un-authentication/non-registered/ ==> "out of band authentication" is not clear: this refers to the out-of-band with respect to IPv6 tunnel set-up session, but may be in-band with respect to the IP connectivity; so reword: The non-registered mode does not require explicit authentication of the user. Access control may be performed using e.g., IPv4 address. The mode essentially offers the IPv6 service to any of ISP's IPv4 customers. .... In this mode, IPv4 return routability checks in the set-up phase of the tunnels seems to be a way to avoid some of these problems at the price of an extra round trip. ==> maybe add here: As the threat is specific to the ISP's ingress filtering deployment, the ISP should be able to specify whether such a check needs to be performed. .... However, as NAT traversal usually requires an extra layer of encapsulation, the tunnel set-up protocol must be able to detect automatically the presence of one or more NAT boxes in the path. ==> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO a should is sensible.) ==> do we want to test for the presence of a proto-41 forwarding NAT box? That would likely be complicated (would require extra transmission of proto-41 packets)? If we put that in, it's a "may" at most. 6.5 Latency in Set-up Phases In certain type of networks, keeping tunnels active all the time is not possible or simply too expensive. ==> maybe spell out an example here or later in this section, like: not possible (e.g., when the host is mobile) .... 6.7 Traceability ==> this is not really traceability, reword; maybe like "Provides Enough Information about Usage" .... Once IPv6 is available natively in the access network connecting a customer, there is no reason to keep using tunnels. So the tunnel-setup protocol must have a provision to enable the ISP to signal the user to use native IPv6 instead. ==> I'd reword this "must" to a "should", but I don't feel too strongly about this either way. ==> actually, this should probably be reworded as it's ambiguous. Obviously, if the user sees a route advertisement on the native link (or the like), that should be used instead. But is it the ISP's business to "stop" the user to start using native v6 instead (if it doesn't work automatically)? At most, the mechanism should provide a means to show the user a message that ISP is also providing native v6 service (possible e.g. if the user switched to new service class, or replaced the NAT box) even though the user is not obtaining it at the moment. [3053] A. Durand, P. Fasano, I. Guardini, D. Lento., "IPv6 Tunnel Broker", January 2001. [ISP] Lind, M., "Scenarios and Analysis for Introducing IPv6 into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-01 (work in progress), February 2004. [UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work in progress), February 2004. ==> these probably belong ot the normative references section. editorial --------- In an ISP network where IPv4 is dominant, some of the initial IPv6 deployment phases consists of getting a prefix allocation from the RIR, and peering with other IPv6 ISP (or exchange points). ==> probably out of scope and could be removed? - assisted tunneling infrastructure to early adopters, - native IPv6 to customers where economically justified, - native IPv6 to all customers. ==> s/-/1)/, s/-/2)/, etc? Note that, as the addressing space used during the transition to native remains the same the customer routing, filtering, accounting [ISP, section 5.] stay the same, and there is no need to maintain any kind of relay. ==> s/same the customer/same, the customers'/ ? "Assisted tunneling" is used in this document to described a ==> s/described/describe/ This document analyze the requirements for such a tunnel set-up ==> s/analyze/analyzes/ - The device used as tunnel end point is located behind a customer owned NAT box that is also acting as a local DHCP server. In that case, the device IPv4 address may change after a reboot. ==> s/device/device's/ ==> note that such behaviour is non-compliant with DHCP specs, but this is not a hot issue for me. This may be regarded as a feature, but deployment of the service with this mode enable must be done carefully. In particular, security ==> s/enable// ? connectivity, transforming effectively the ISP into a IPv6 transit ==> s/a/an/ authentication method must be supported. Other authentication MAY be ==> s/MAY/may/ As in sectoin 4.4, IPv4 return routability checks could help blocking ==> s/sectoin/section/ 6.2 Service discovery requirements ==> s/discovery requirements/Discovery Requirements/ (same elsewhere where applicable) set-up protocol must be able to abort immediately and display the customers a message explaining that no service is available. ==> s/customers// A client MAY choose not to send those messages (for example on ISDN ==> s/MAY/may/ ==> (actually, I'd recommend also starting a new paragraph from "A client ..." There is a large number of Teredo clients already deployed, the ==> s/is/are/ ==> s/,/, and/ should be manage on the client side instead of the server side, that ==> s/manage/managed/ Similar considerations as Teredo, section 7.2, applies to Isatap. ==> s/Isatap/ISATAP/ technology, where traffic can be redirected to go from one place to another one. ==> s/another one/another/ 9. Author Addresses ==> s/Author/Authors'/ 11. Non Normative References ==> s/Non Normative/Informative/ [2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ==> not used and can be removed. -- 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-v6ops@ops.ietf.org Tue May 4 10:07: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 KAA02687 for ; Tue, 4 May 2004 10:07:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BL0YD-000CWJ-SX for v6ops-data@psg.com; Tue, 04 May 2004 14:05:37 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BL0D4-000833-Fy for v6ops@ops.ietf.org; Tue, 04 May 2004 13:43:46 +0000 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 15:43:41 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : ISP requirement was:(RE: POLL: Consensus for moving forward with Teredo?) Date: Tue, 4 May 2004 15:43:40 +0200 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC27DEFC0@ftrdmel3.rd.francetelecom.fr> Thread-Topic: ISP requirement was:(RE: POLL: Consensus for moving forward with Teredo?) Thread-Index: AcQu2cn+/Eoqn80nRY+XIRcCZ9EvuwCQvdgAAAolnNAAIxPpwA== From: "BAUDOT Alain FTRD/DMI/CAE" To: "Tony Hain" , X-OriginalArrivalTime: 04 May 2004 13:43:41.0396 (UTC) FILETIME=[CF9D9140:01C431DD] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > > Behalf Of BAUDOT Alain FTRD/DMI/CAE > > Sent: Monday, May 03, 2004 10:26 AM > > To: v6ops@ops.ietf.org > > Subject: RE : POLL: Consensus for moving forward with Teredo? > >=20 > > c) because I don't understand why just considering teredo=20 > and not, at=20 > > the same time, the other mechanisms according to the WG=20 > "selection"=20 > > process. > > a) in order to move forward. And ISATAP, TSP, DSTM, STEP, etc should > > benefit from that, as well. > >=20 > > Anyway I've got a couple of concerns with teredo: > > - it deals with a specific adressing plan. I quite agree it=20 > could be a=20 > > kind of no start, and phasing out will result in some renumbering >=20 > Avoiding renumbering is not a requirement of ANY IPv6=20 > deployment scenario, including native RA's. So the only=20 > reason to raise an objection here is to stall deployment. >=20 There is no intend to stale anything here. The point is just about = spefic addressing, as already discussed in another thread. > > - it is host oriented and not routeur/network oriented. >=20 > And your point is ??? If complaining about teredo is about=20 > preventing IPv6 deployment until the ISP is good and ready to=20 > offer service, you should look closely at the IETF's role.=20 > The IETF is about standardizing the mechanisms used, not any=20 > specific provider's service offerings. If a provider doesn't=20 > want their customers to use teredo, they can always block the=20 > UDP port. > I mean that other mechanisms enabling a network or a router to get=20 IPv6 connectivity and adresses should move forward, as well. The idea is to standardize as soon as possible tools enabling ISP to be good and ready and not the opposite. > >=20 > > Teredo is usually identified as a deployment solution without ISPs,=20 > > and obviously does not meet their requirements. >=20 > WRONG. It is about getting service when the first-hop service=20 > provider is lame. Many people are in a position where they=20 > can not select an alternative ISP, so they need something=20 > that will get them across an ISP that doesn't understand the=20 > term 'service'. As long as ANY service provider is willing to=20 > deploy a teredo service, the end user can start using IPv6=20 > enabled applications without waiting for their IPv4 provider.=20 >=20 This is the way I understood "without ISP support" that is connected to unman 1.1 scenario, and not to unman 1.2 and unman 2 scenarios. Distinction between service provider, IP provider and ISP maybe confusing anyway. > > So, even if I don't really see > > the deployment model, why not simply deploy the same=20 > mechanism, first=20 > > by non-ISPs and later by "real" ones ? >=20 > Something appears to have been lost in the translation here.=20 > What mechanism are you talking about? The later end game is=20 > native IPv6 service, and the transition mechanisms are about=20 > deploying applications prior to the ISP providing that. What=20 > mechanism is useful in both cases? >=20 I guess TB+TSP may apply in both cases (deploying applications and providing IPv6 connectivity and service) and it may be aesier to move=20 from one another when provided by different roles. Indeed this is=20 not a MUST. I hope this comes a bit clearer. Thanks for your comments. Alain. =20 =20 > Tony >=20 >=20 > >=20 > > Alain. > >=20 > > -----Message d'origine----- > > De : owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] De la=20 > > part de Pekka Savola Envoy=E9 : vendredi 30 avril 2004 19:32 > > =C0 : v6ops@ops.ietf.org > > Objet : POLL: Consensus for moving forward with Teredo? > >=20 > >=20 > > Hi, > >=20 > > (co-chair hat on) > >=20 > > As identified in the scenarios analysis at IETF59 and in=20 > draft-savola-=20 > > v6ops-tunneling-01.txt, there appears to a need which=20 > cannot be filled=20 > > by another mechanism for Teredo at least in one major Unmanaged=20 > > scenario. > >=20 > > Is there rough consensus to move forward with Teredo?=20 > (i.e., to adopt=20 > > it as WG document in this WG or elsewhere, for Proposed Standard.) > >=20 > > The main issue raised has been to call for a more extensive=20 > analysis=20 > > for the deployment implications of native, 6to4, and=20 > Teredo. There is=20 > > already discussion of this in the Unmanaged Analysis=20 > document. There=20 > > seemed to be very little energy or interest in the WG to drive this=20 > > much further. > >=20 > > The options regarrding Teredo at this stage seem to be: > >=20 > > a) Go forward with Teredo, hone the deployment implications in the > > unmanaged analysis in parallel (if and as appropriate), > >=20 > > b) Conclude that there is no sufficiently strong need for=20 > Teredo, and > > not support its advancement (for PS) at this stage, or > >=20 > > c) Decide that we need to analyze the scenarios or deployment more > > before being able to make a decision. > >=20 > > If so, please state where you believe more analysis is needed.. > > and volunteer if possible :) > >=20 > > If you have an opinion, please state it within a week,=20 > i.e., by next=20 > > Friday, 7th May. > >=20 > > Thanks! > >=20 > > (co-chair hat off) > >=20 > >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue May 4 13:26: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 NAA14383 for ; Tue, 4 May 2004 13:26:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BL3e0-000Abl-OL for v6ops-data@psg.com; Tue, 04 May 2004 17:23:48 +0000 Received: from [4.14.89.161] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BL3dz-000AbS-01 for v6ops@ops.ietf.org; Tue, 04 May 2004 17:23:47 +0000 Received: from eaglet (127.0.0.1:4647) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 4 May 2004 10:23:50 -0700 From: "Tony Hain" To: "'BAUDOT Alain FTRD/DMI/CAE'" , Subject: RE: ISP requirement was:(RE: POLL: Consensus for moving forward with Teredo?) Date: Tue, 4 May 2004 10:23:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQu2cn+/Eoqn80nRY+XIRcCZ9EvuwCQvdgAAAolnNAAIxPpwAAJbNpA In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC27DEFC0@ftrdmel3.rd.francetelecom.fr> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: BAUDOT Alain FTRD/DMI/CAE = [mailto:alain.baudot@francetelecom.com] > Sent: Tuesday, May 04, 2004 6:44 AM > To: Tony Hain; v6ops@ops.ietf.org > Subject: RE : ISP requirement was:(RE: POLL: Consensus for moving = forward > with Teredo?) >=20 > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] = On > > > Behalf Of BAUDOT Alain FTRD/DMI/CAE > > > Sent: Monday, May 03, 2004 10:26 AM > > > To: v6ops@ops.ietf.org > > > Subject: RE : POLL: Consensus for moving forward with Teredo? > > > > > > c) because I don't understand why just considering teredo > > and not, at > > > the same time, the other mechanisms according to the WG > > "selection" > > > process. > > > a) in order to move forward. And ISATAP, TSP, DSTM, STEP, etc = should > > > benefit from that, as well. > > > > > > Anyway I've got a couple of concerns with teredo: > > > - it deals with a specific adressing plan. I quite agree it > > could be a > > > kind of no start, and phasing out will result in some renumbering > > > > Avoiding renumbering is not a requirement of ANY IPv6 > > deployment scenario, including native RA's. So the only > > reason to raise an objection here is to stall deployment. > > > There is no intend to stale anything here. The point is just about = spefic > addressing, as already discussed in another thread. Nobody pays attention to addressing except routers and the geeks who run them. Moving from 2003:: to 2001:: is no more of a problem than moving = from 2001:abcd:: to 2001:fedc:: (ie: switching providers). If the first hop provider stalls their deployment too long there is a chance the end = customer will embed 2003:: addresses in places they shouldn't, but rapid = deployment of native service will avoid that. >=20 > > > - it is host oriented and not routeur/network oriented. > > > > And your point is ??? If complaining about teredo is about > > preventing IPv6 deployment until the ISP is good and ready to > > offer service, you should look closely at the IETF's role. > > The IETF is about standardizing the mechanisms used, not any > > specific provider's service offerings. If a provider doesn't > > want their customers to use teredo, they can always block the > > UDP port. > > > I mean that other mechanisms enabling a network or a router to get > IPv6 connectivity and adresses should move forward, as well. The idea > is to standardize as soon as possible tools enabling ISP to be good > and ready and not the opposite. We did that first as dual-stack routing, and found the ISPs are standing around waiting for IPv6 traffic before they deploy it. The end customers can't deploy IPv6 apps to generate that traffic without some of the additional tools. At the same time, we should not be stalling tools that = an ISP might want to use. > > > > > > Teredo is usually identified as a deployment solution without = ISPs, > > > and obviously does not meet their requirements. > > > > WRONG. It is about getting service when the first-hop service > > provider is lame. Many people are in a position where they > > can not select an alternative ISP, so they need something > > that will get them across an ISP that doesn't understand the > > term 'service'. As long as ANY service provider is willing to > > deploy a teredo service, the end user can start using IPv6 > > enabled applications without waiting for their IPv4 provider. > > > This is the way I understood "without ISP support" that is connected > to unman 1.1 scenario, and not to unman 1.2 and unman 2 scenarios. > Distinction between service provider, IP provider and ISP maybe > confusing anyway. > > > So, even if I don't really see > > > the deployment model, why not simply deploy the same > > mechanism, first > > > by non-ISPs and later by "real" ones ? > > > > Something appears to have been lost in the translation here. > > What mechanism are you talking about? The later end game is > > native IPv6 service, and the transition mechanisms are about > > deploying applications prior to the ISP providing that. What > > mechanism is useful in both cases? > > > I guess TB+TSP may apply in both cases (deploying applications and > providing IPv6 connectivity and service) and it may be aesier to move > from one another when provided by different roles. Indeed this is > not a MUST. What??? Do you really think people would put in the number of static = routes necessary to move assignments from a TB to the appropriate PE router? Unless you are talking about the massive expense of putting in an array = of TB's at each edge, then wholesale replacing them in a simultaneous move = of all customers as native service is turned up on an edge, you will end up with a routing nightmare, or readdressing the customers as they are = moved individually. TB is a fine tool for what it does. Just don't promote it = to the magic bullet that solves all problems, because it doesn't.=20 Popping up a level: Again, we have a minimum set of tools on the table. There are some = overlaps between them, but no complete duplication of functions. All belong on = the standards track because implementations will be expected to = interoperate. It is not the IETF's job to dictate what the market can have, just to = provide standards so that an interoperable set of tools can be offered. It is = the marketplace that will decide which of the tools have value, and in which scenarios. At this point, all the arguing about which tool is better = than another is simply stalling the availability of all of them.=20 We needed to be able to explain to the IESG why we needed more than one transition tool, and the scenarios documents set the stage for that. Now = we need to show how each tool applies, and why there is not a complete duplication of function between any of them. At the same time, there are concerns that the tools still need some polish before they are ready, so that should be happening as a standardization effort. All the noise = about 'Experimental' needs to stop, because that is fundamentally a political = move to push one tool down in favor of another. It is not the IETF's job to = make the determination of market favorite. If we are really unsure about an approach then Experimental makes sense, otherwise the technology needs = to be PS. If the market accepts it we will have deployment reports so it can = move forward. If the market does not, it will not matter what status it has.=20 Tony >=20 > I hope this comes a bit clearer. Thanks for your comments. >=20 > Alain. >=20 > > Tony > > > > > > > > > > Alain. > > > > > > -----Message d'origine----- > > > De : owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] De la > > > part de Pekka Savola Envoy=E9 : vendredi 30 avril 2004 19:32 > > > =C0 : v6ops@ops.ietf.org > > > Objet : POLL: Consensus for moving forward with Teredo? > > > > > > > > > Hi, > > > > > > (co-chair hat on) > > > > > > As identified in the scenarios analysis at IETF59 and in > > draft-savola- > > > v6ops-tunneling-01.txt, there appears to a need which > > cannot be filled > > > by another mechanism for Teredo at least in one major Unmanaged > > > scenario. > > > > > > Is there rough consensus to move forward with Teredo? > > (i.e., to adopt > > > it as WG document in this WG or elsewhere, for Proposed Standard.) > > > > > > The main issue raised has been to call for a more extensive > > analysis > > > for the deployment implications of native, 6to4, and > > Teredo. There is > > > already discussion of this in the Unmanaged Analysis > > document. There > > > seemed to be very little energy or interest in the WG to drive = this > > > much further. > > > > > > The options regarrding Teredo at this stage seem to be: > > > > > > a) Go forward with Teredo, hone the deployment implications in = the > > > unmanaged analysis in parallel (if and as appropriate), > > > > > > b) Conclude that there is no sufficiently strong need for > > Teredo, and > > > not support its advancement (for PS) at this stage, or > > > > > > c) Decide that we need to analyze the scenarios or deployment = more > > > before being able to make a decision. > > > > > > If so, please state where you believe more analysis is = needed.. > > > and volunteer if possible :) > > > > > > If you have an opinion, please state it within a week, > > i.e., by next > > > Friday, 7th May. > > > > > > Thanks! > > > > > > (co-chair hat off) > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Tue May 4 13:32: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 NAA14740 for ; Tue, 4 May 2004 13:32:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BL3mI-000Crn-2a for v6ops-data@psg.com; Tue, 04 May 2004 17:32:22 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BL3mG-000CrE-Og for v6ops@ops.ietf.org; Tue, 04 May 2004 17:32:20 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44HWKMu028115 for ; Tue, 4 May 2004 11:32:20 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HX7000GBA1TW8@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 04 May 2004 11:32:20 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HX700KOHA1S3N@mail.sun.net> for v6ops@ops.ietf.org; Tue, 04 May 2004 11:32:17 -0600 (MDT) Date: Tue, 04 May 2004 10:32:14 -0700 From: Alain Durand Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable References: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, thank you very much for the very detailed and very constructive=20 comments. responses in-line. - Alain. On May 4, 2004, at 5:32 AM, Pekka Savola wrote: > The > tunnel set-up protocol must support both modes, however ISP=20 > deploying > it may choose to only support one mode of operation. > > =3D=3D> this should be probably be its own paragraph, but a more = important > issue: is this a requirement for a) the protocol, or for b) the > implementation of the protocol, or c) its deployment? > > It looks like a) and c) but I could be wrong. I would say a) and b). b) for interoperability reasons. While deploying=20= it, you turn on or off any features you like or not. > My argument is that IMHO the simple mode should be a must for=20 > implement, the > registered mode a should; and whatever the operators do is up to them,=20= > but > we could recommend them to not turn off the simple mode to keep it > interoperable. If the ISP deploy the 'registered' mode and it has not been implemented=20= in the client, it does not work. That's why I think all implementations would have to=20= support both and the operation mode wo=A8ld be decided by the ISP. > 5.1. Address and Prefix Delegation > > The authenticated mode must support delegation of a single address=20= > or > a whole prefix or a combination of both. > > =3D=3D> again, I've said this in the past, but IMHO prefix + address = is not > interesting. This is definitely not a must or even a should, IMHO --=20= > and > should be scrapped entirely. I assume the address would be assigned=20= > on the > point-to-point address (and such address is not even needed at all!). This is again an operational decision that can be made only by the ISP. This is why, IMHO, the protocol and its implementations should support=20= both modes. > note: not clear what should be the mandatory authentication method. > Clear text password is out. Digest-MD5 [2831] seems like a good > choice. > > =3D=3D> I don't have a strong opinion either, but Digest-MD5 is not=20 > acceptable > -- MD5 must not be used for new protocols due to its collision=20 > weakness.=20 > Use SHA1 instead. Why not. is it an IESG policy? > 6.1 Scalability > > The tunnel set-up protocol must be scalable. > > =3D=3D> We need a few more words than that to flesh out this = requirement, I > think ;-) really? ;-) > semi-editorial/substantial > -------------------------- > > "Assisted tunneling" is used in this document to described a > transition mechanism where the parameters to configure a bi- > directional tunnel between an end-node (or leaf network) and a=20 > router > in the core of an ISP are negotiated through a tunnel set-up > protocol. Although this negotiation phase can be automated, this > remains different from transition mechanisms like 6to4 that is = fully > automatic or teredo/isatap which, once the IPv4 address of an=20 > initial > server/router is configured do not involve any further negotiation > phase. > > =3D=3D> first, it may be inaccurate to talk about "negotiation", as = you=20 > don't > _need_ to negotiate at all (any more than you need to negotiate with=20= > Teredo or > ISATAP). The more controlled means may allow that, but it should not=20= > be > needed; therefore, I'd reword "negotiate" here, for example to like: > > "Assisted tunneling" is used in this document to described a > transition mechanism where the parameters to configure a bi- > directional tunnel between an end-node (or leaf network) and a=20 > router > in the core of an ISP are exchanged through a tunnel set-up > protocol. Although this exchange can be automated, [...] ok. > =3D=3D> I still think this is slightly inaccurate. Teredo and ISATAP = both > (practically) require more than configuring the v4 address of=20 > server/router: > they have to listen to the router advertisement from the server/router=20= > as > well. So, it's one round-trip instead of zero round-trips. > > Maybe reword to: > > Although this exchange can be automated, this > remains different from a transition mechanism like 6to4 that is=20 > fully > automatic. Teredo and ISATAP, on the other hand, practically=20 > require > receiving information about the available prefix or address from = the > server/router, comparable to the most simple form of assisted > tunneling. ok > ...... > > In particular, the 'authenticated' mode defined in section 5 > enable access control to the IPv6 network where the other transion > mechanism have to rely on out of band access control. > > =3D=3D> this has two typos (in enable "enable" and "mechanism), but = this=20 > seems > slightly inaccurate and could be reworded to be like: > > In particular, the 'registered' mode defined in section 5 > enables explicit access control to the tunneled IPv6 connectivity, > where other transition mechanisms have to rely on other kinds of=20 > control > (e.g., access control based on the IPv4 address) ok > (but I'm not sure if that's 100% accurate either as e.g. Teredo=20 > includes > this authentication/origin data which can be used to restrict access=20= > to the > Teredo servers.) > > ... > > The tunnel established is "anonymous", the end-user does not = provide > any authentication to the server. > > =3D=3D> this probably should be reworded a bit, to like: > > The tunnel established is "anonymous" in a sense as the end-user=20 > does > not register explicitly to the server. [...] ok > (note that the user could provide e.g. a hash which could be mirrored=20= > by the > server to give a proof of a kind -- the point is that the word > "authentication" seems too ambiguous here.) > > 4.1. Address Allocation > > This mode is used to provide IPv6 connectivity to a single host. > Allocation of an IPv6 address (/128) to the end-node must be > supported in this mode. This IPv6 address is "transient" and may > change, but one may implement a mechanism to provide IPv6 address > stability in this mode (e.g. cookie mechanism). > > =3D=3D> s/Allocation/Assignment/ (same later, also in section 6.9) > =3D=3D> I see no reason to rule out sites from this, but we should not=20= > _require_ > that from the protocol. In other words, reword to: > > This mode is used to provide IPv6 connectivity to either a single=20= > host > or a network. > > Assignment of an IPv6 address (/128) to the end-node must be > supported in this mode. This IPv6 address is "transient" and may > change, but one may implement a mechanism to provide IPv6 address > stability in this mode (e.g. cookie mechanism). > > Assignment of an IPv6 prefix (e.g., /64 or /48) may be supported if > feasible. As it seems that there is a (weak) consensus to leave the=20 non-registered mode, I agree with your suggestion. > .... > > The un-authenticated mode relies on out of band authentication. It > essentially offer the IPv6 service to any of its IPv4 customers. > > =3D=3D> s/un-authentication/non-registered/ > =3D=3D> "out of band authentication" is not clear: this refers to the > out-of-band with respect to IPv6 tunnel set-up session, but may be=20 > in-band > with respect to the IP connectivity; so reword: > > The non-registered mode does not require explicit authentication of=20= > the > user. Access control may be performed using e.g., IPv4 address. > The mode essentially offers the IPv6 service to any of ISP's IPv4 > customers. ok > .... > > In this mode, IPv4 return routability checks in the set-up phase of > the tunnels seems to be a way to avoid some of these problems at = the > price of an extra round trip. > > =3D=3D> maybe add here: > > As the threat is specific to the > ISP's ingress filtering deployment, the ISP should be able to=20 > specify > whether such a check needs to be performed. ok > .... > > However, as > NAT traversal usually requires an extra layer of encapsulation, the > tunnel set-up protocol must be able to detect automatically the > presence of one or more NAT boxes in the path. > > =3D=3D> s/must/should/ (this is what 4.3 and 5.3 have at least, and = IMHO a > should is sensible.) Not sure. I think the protocol and its implementation MUST support the detection, but the deployment MAY turn it off. i should clarify this. > =3D=3D> do we want to test for the presence of a proto-41 forwarding = NAT=20 > box? > That would likely be complicated (would require extra transmission of > proto-41 packets)? If we put that in, it's a "may" at most. I hadn't thought of that... Is it the case that if proto-41 forwarding=20= is in place then the communication would be un-differentiable from a non nated one? > 6.5 Latency in Set-up Phases > > In certain type of networks, keeping tunnels active all the time is > not possible or simply too expensive. > > =3D=3D> maybe spell out an example here or later in this section, = like: > > not possible (e.g., when the host is mobile) .... nothing to do with mobility but with the charging method (i.e. by the=20 minute?). But I agree, more text is needed. > 6.7 Traceability > > =3D=3D> this is not really traceability, reword; maybe like > "Provides Enough Information about Usage" Is this not the definition of traceability? > > .... > > Once IPv6 is available natively in the access network > connecting a customer, there is no reason to keep using tunnels. So > the tunnel-setup protocol must have a provision to enable the ISP = to > signal the user to use native IPv6 instead. > > =3D=3D> I'd reword this "must" to a "should", but I don't feel too = strongly > about this either way. neither do I. Does anybody else have an opinion? > =3D=3D> actually, this should probably be reworded as it's ambiguous. > Obviously, if the user sees a route advertisement on the native link=20= > (or the > like), that should be used instead. No, this is not enough. Example: I may have a local router on my=20 ethernet link that advertises an internal prefix, but this does not mean that I can use it to get=20 external connectivity and have to give up my modem line. > But is it the ISP's business to "stop" > the user to start using native v6 instead (if it doesn't work > automatically)? At most, the mechanism should provide a means to show=20= > the > user a message that ISP is also providing native v6 service (possible=20= > e.g. > if the user switched to new service class, or replaced the NAT box) > even though the user is not obtaining it at the moment. Yes. This is the concern I have, ISP now offer native, but the box is=20 still configured to use the tunnel. > > [3053] A. Durand, P. Fasano, I. Guardini, D. Lento., > "IPv6 Tunnel Broker", January 2001. > > [ISP] Lind, M., "Scenarios and Analysis for Introducing IPv6 > into ISP Networks", > draft-ietf-v6ops-isp-scenarios-analysis-01 (work in > progress), February 2004. > > [UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for > Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work > in progress), February 2004. > > =3D=3D> these probably belong ot the normative references section. I never understand what goes where... What is you rationale? - Alain.= From owner-v6ops@ops.ietf.org Tue May 4 16:38: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 QAA27884 for ; Tue, 4 May 2004 16:38:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BL6dC-0001Y6-B0 for v6ops-data@psg.com; Tue, 04 May 2004 20:35:10 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BL6dA-0001Xi-8V for v6ops@ops.ietf.org; Tue, 04 May 2004 20:35:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i44KZ4A10014; Tue, 4 May 2004 23:35:04 +0300 Date: Tue, 4 May 2004 23:35:04 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk in-line... omitting the parts where we agree.. On Tue, 4 May 2004, Alain Durand wrote: > On May 4, 2004, at 5:32 AM, Pekka Savola wrote: > > > The > > tunnel set-up protocol must support both modes, however ISP > > deploying > > it may choose to only support one mode of operation. > > > > ==> this should be probably be its own paragraph, but a more important > > issue: is this a requirement for a) the protocol, or for b) the > > implementation of the protocol, or c) its deployment? > > > > It looks like a) and c) but I could be wrong. > > I would say a) and b). b) for interoperability reasons. While > deploying it, you turn on or off any features you like or not. You mean, that's the goal? I agree. (The text currently seems to say a + c). > > My argument is that IMHO the simple mode should be a must for > > implement, the registered mode a should; and whatever the > > operators do is up to them, but we could recommend them to not > > turn off the simple mode to keep it interoperable. > > If the ISP deploy the 'registered' mode and it has not been > implemented in the client, it does not work. That's why I think all > implementations would have to support both and the operation mode > would be decided by the ISP. It would be beneficial to support both, yes, but if this was to be applied e.g., in 3GPP or mobile environments (just to take an example), I'd guess that there might be some interested in simplifying the client. Similarly, as providing service over a tunnel is more or less a "tryout" service in any case (I don't think many ISPs would see that as "production"), my personal view is that the most who would want to deploy something like this in the first place would actually want the simple mode. (And if they're OK with all the registration etc. _process_ and procedures, many could use L2TP or deploy dual-stack in any case.) The simple form is also something that could be implemented and turned on by default on hosts (when v6 is turned on, if not on by default, that is). That's why I think "simple" form is criticial, and the registered mode interesting for "power users" but not necessarily for all that many ISPs for production use. > > 5.1. Address and Prefix Delegation > > > > The authenticated mode must support delegation of a single address > > or > > a whole prefix or a combination of both. > > > > ==> again, I've said this in the past, but IMHO prefix + address > > is not interesting. This is definitely not a must or even a > > should, IMHO -- and should be scrapped entirely. I assume the > > address would be assigned on the point-to-point address (and such > > address is not even needed at all!). > > This is again an operational decision that can be made only by the > ISP. This is why, IMHO, the protocol and its implementations should > support both modes. Note that I'm not arguing for doing address assignment or prefix delegation, but I was just stating that doing _both_ for a single session (as it appears to read) does not seem like a useful requirement. > > note: not clear what should be the mandatory authentication method. > > Clear text password is out. Digest-MD5 [2831] seems like a good > > choice. > > > > ==> I don't have a strong opinion either, but Digest-MD5 is not > > acceptable -- MD5 must not be used for new protocols due to its > > collision weakness. Use SHA1 instead. > > Why not. is it an IESG policy? Yes. draft-iesg-tcpmd5app-00.txt provides some background to this, but focuses on TCP-MD5 only. > > 6.1 Scalability > > > > The tunnel set-up protocol must be scalable. > > > > ==> We need a few more words than that to flesh out this requirement, I > > think ;-) > > really? ;-) Good that we agree ;-) [[clipping comments you agree with]] > > .... > > > > However, as > > NAT traversal usually requires an extra layer of encapsulation, the > > tunnel set-up protocol must be able to detect automatically the > > presence of one or more NAT boxes in the path. > > > > ==> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO a > > should is sensible.) > > Not sure. I think the protocol and its implementation MUST > support the detection, but the deployment MAY turn it off. > i should clarify this. This is a bit in odds with 4.3 and 5.3 then, as those seem to be closer to a 'should'. My own view is that in some environments it might be acceptable to just always use UDP, to avoid certain hassles of toggling between proto-41 and UDP -- but as this causes overhead, we should try to avoid the overhead if feasible. Hence a (strong) should. > > ==> do we want to test for the presence of a proto-41 forwarding > > NAT box? That would likely be complicated (would require extra > > transmission of proto-41 packets)? If we put that in, it's a > > "may" at most. > > I hadn't thought of that... Is it the case that if proto-41 > forwarding is in place then the communication would be > un-differentiable from a non nated one? It's slightly different: the "internal IP address" set in the packets to detect whether NAT was on the path or not would tell there is a NAT, and would result in (an unnecessary) fallback to UDP. So, to cater for that situation, the logic would have to be like: 1) send the packet to the server with "my own address" set 2) the server notices that "my own address" and the source address are not the same. 2.1) the server tries to send an IP-proto-41 packet to the source address in any case; if it doesn't hear back soon, retry with UDP. 2.2) failing that, just send the packet on UDP. 2.3) in both cases, activate the NAT keepalive sequence. It seems to me that the fallback in 2.1) might add some substantial code in case the NAT doesn't forward proto-41, especially if the negotiation/parameter exchange would otherwise conclude after sending the packet (i.e., this would require at least 1.5 roundtrips to verify a host behind a NAT got the information, and if it didn't, at least 2 roundtrips -- using just UDP could be done with 1 roundtrip.) Obviously, this kind of "forwarder detection check" could possibly be implemented separately, and would be indicated as a flag from the client, but that might have some minor failure modes as well. > > 6.5 Latency in Set-up Phases > > > > In certain type of networks, keeping tunnels active all the time is > > not possible or simply too expensive. > > > > ==> maybe spell out an example here or later in this section, like: > > > > not possible (e.g., when the host is mobile) .... > > nothing to do with mobility but with the charging method (i.e. by > the minute?). But I agree, more text is needed. Yes, the text focused on the charging model, but section title on Set-up latency is important for mobile etc. as well, so it should be mentioned somehow. > > 6.7 Traceability > > > > ==> this is not really traceability, reword; maybe like > > "Provides Enough Information about Usage" > > Is this not the definition of traceability? I, at least, think of traceability as "a way to trace the usage of a user or IP address" which is a bit different? > > ==> actually, this should probably be reworded as it's ambiguous. > > Obviously, if the user sees a route advertisement on the native > > link (or the like), that should be used instead. > > No, this is not enough. Example: I may have a local router on my > ethernet link that advertises an internal prefix, but this does not > mean that I can use it to get external connectivity and have to give > up my modem line. OK -- what it could probably check is default route with medium or high preferece (and your case, one should use low preference or more specific routes). > > But is it the ISP's business to "stop" the user to start using > > native v6 instead (if it doesn't work automatically)? At most, > > the mechanism should provide a means to show the user a message > > that ISP is also providing native v6 service (possible e.g. if the > > user switched to new service class, or replaced the NAT box) even > > though the user is not obtaining it at the moment. > > Yes. This is the concern I have, ISP now offer native, but the box > is still configured to use the tunnel. Right. But is it a good idea to "cancel" service like that? I mean, in most cases, it's fine if the user is able to (automatically!) get v6 using other means -- but if it's not automatic, the user would be left without service altogether! In other words, the ISP can cease tunneling service by taking down the tunnel server or making sure it provides no further allocations if the ISP wants to be "draconian". The most we should probably do is have a means for the client software to state that native v6 is available (whether mentioned by the server or not).. > > [3053] A. Durand, P. Fasano, I. Guardini, D. Lento., > > "IPv6 Tunnel Broker", January 2001. > > > > [ISP] Lind, M., "Scenarios and Analysis for Introducing IPv6 > > into ISP Networks", > > draft-ietf-v6ops-isp-scenarios-analysis-01 (work in > > progress), February 2004. > > > > [UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for > > Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work > > in progress), February 2004. > > > > ==> these probably belong ot the normative references section. > > I never understand what goes where... What is you rationale? Normative refs are usually those which must be read in order to understand this particular document, or must be implemented in order to implement this spec. In this particular case, you seem to be citing at least [ISP] and [UNMANAGED] in such a way that this would seem warranted. (One feature of normative refs is that they block publication, but as you cite the scenarios from those in a particular fashion, this document should not go forward unless those scenarios and text are final.) -- 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-v6ops@ops.ietf.org Tue May 4 21:11: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 VAA12322 for ; Tue, 4 May 2004 21:11:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLAv9-0006A3-8V for v6ops-data@psg.com; Wed, 05 May 2004 01:09:59 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLAv7-00069h-PZ for v6ops@ops.ietf.org; Wed, 05 May 2004 01:09:57 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4519vdc002865 for ; Tue, 4 May 2004 19:09:57 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HX7007PHV8J0P@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 04 May 2004 19:09:56 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HX700CNXV8IE1@mail.sun.net> for v6ops@ops.ietf.org; Tue, 04 May 2004 19:09:55 -0600 (MDT) Date: Tue, 04 May 2004 18:09:51 -0700 From: Alain Durand Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On May 4, 2004, at 1:35 PM, Pekka Savola wrote: > in-line... omitting the parts where we agree.. I'm glad we are converging. See inline response were there is still discussion. >> If the ISP deploy the 'registered' mode and it has not been >> implemented in the client, it does not work. That's why I think all >> implementations would have to support both and the operation mode >> would be decided by the ISP. > > It would be beneficial to support both, yes, but if this was to be > applied e.g., in 3GPP or mobile environments (just to take an > example), I'd guess that there might be some interested in simplifying > the client. > > Similarly, as providing service over a tunnel is more or less a > "tryout" service in any case (I don't think many ISPs would see that > as "production"), my personal view is that the most who would want to > deploy something like this in the first place would actually want the > simple mode. (And if they're OK with all the registration etc. > _process_ and procedures, many could use L2TP or deploy dual-stack in > any case.) > > The simple form is also something that could be implemented and turned > on by default on hosts (when v6 is turned on, if not on by default, > that is). > > That's why I think "simple" form is criticial, and the registered mode > interesting for "power users" but not necessarily for all that many > ISPs for production use. I'll take this discussion to a separate thread. >>> However, as >>> NAT traversal usually requires an extra layer of encapsulation, >>> the >>> tunnel set-up protocol must be able to detect automatically the >>> presence of one or more NAT boxes in the path. >>> >>> ==> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO >>> a >>> should is sensible.) >> >> Not sure. I think the protocol and its implementation MUST >> support the detection, but the deployment MAY turn it off. >> i should clarify this. > > This is a bit in odds with 4.3 and 5.3 then, as those seem to be > closer to a 'should'. > > My own view is that in some environments it might be acceptable to > just always use UDP, to avoid certain hassles of toggling between > proto-41 and UDP -- but as this causes overhead, we should try to > avoid the overhead if feasible. Hence a (strong) should. I honestly do not believe that checking the presence of a NAT and firing UDP encapsulation if it is there is such a big deal... So I believe it is worth a MUST, as the payoff is important by reducing the overhead. >>> ==> do we want to test for the presence of a proto-41 forwarding >>> NAT box? That would likely be complicated (would require extra >>> transmission of proto-41 packets)? If we put that in, it's a >>> "may" at most. >> >> I hadn't thought of that... Is it the case that if proto-41 >> forwarding is in place then the communication would be >> un-differentiable from a non nated one? > > It's slightly different: the "internal IP address" set in the packets > to detect whether NAT was on the path or not would tell there is a > NAT, and would result in (an unnecessary) fallback to UDP. > > So, to cater for that situation, the logic would have to be like: > > 1) send the packet to the server with "my own address" set > 2) the server notices that "my own address" and the source address > are not the same. > 2.1) the server tries to send an IP-proto-41 packet to the source > address in any case; if it doesn't hear back soon, retry with > UDP. > 2.2) failing that, just send the packet on UDP. > > 2.3) in both cases, activate the NAT keepalive sequence. > > It seems to me that the fallback in 2.1) might add some substantial > code in case the NAT doesn't forward proto-41, especially if the > negotiation/parameter exchange would otherwise conclude after sending > the packet (i.e., this would require at least 1.5 roundtrips to verify > a host behind a NAT got the information, and if it didn't, at least 2 > roundtrips -- using just UDP could be done with 1 roundtrip.) > > Obviously, this kind of "forwarder detection check" could possibly be > implemented separately, and would be indicated as a flag from the > client, but that might have some minor failure modes as well. How widely is IP proto 41 forwarding deployed? If it is not much, I suppose that forcing an extra layer of encapsulation would not be that terrible... and also would allow for more than one tunnel to go through the NAT box. So, I do not think that detecting NAT proto 41 forwarding is an important requirement. From owner-v6ops@ops.ietf.org Tue May 4 21:26: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 VAA13060 for ; Tue, 4 May 2004 21:26:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLBAE-0008kq-Hx for v6ops-data@psg.com; Wed, 05 May 2004 01:25:34 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLBAD-0008kd-Kn for v6ops@ops.ietf.org; Wed, 05 May 2004 01:25:33 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i451PXMu017747 for ; Tue, 4 May 2004 19:25:33 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HX7004PUVYKEM@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 04 May 2004 19:25:33 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HX700COWVYJE1@mail.sun.net> for v6ops@ops.ietf.org; Tue, 04 May 2004 19:25:32 -0600 (MDT) Date: Tue, 04 May 2004 18:25:29 -0700 From: Alain Durand Subject: Tunnel Set-up requirements: Issue to be resolved To: "'''IPv6 Operations ' ' '" Message-id: <182893D0-9E33-11D8-B5C6-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT There is one major issue that need to be resolved in this document, and I'd like to get feedback on. The original draft talked about two modes, authenticated and non authenticated. This was not a perfect terminology, and we now use registered vs non registered. As Pekka's explained, there are three level of requirements, the ones on the protocol, the ones on the implementations of the protocol and the ones on its deployment. With regard to the support of those 2 modes, this is what I would like to suggest: Non registered mode: - MUST be supported by the protocol to be designed - RECOMMENDED to be implemented on client and servers/brokers - MAY be turned off by ISP Registered mode: - MUST be supported by the protocol - RECOMMENDED to be implemented on clients and servers/brokers - MAY be turned on by ISP - The registered part of the protocol SHOULD not be too different from the non registered one, so as to minimize code difference between the two modes The difference is that the Non registered mode becomes the default mode of operation, which can certainly be a valid option when the ISP has a enough control on IPv4 access. (See Erik Nordmark's email on the matter) The choice of the mode of operation (registered vs non registered) would then be completely controlled by the ISP. Would this be an acceptable solution? - Alain. From owner-v6ops@ops.ietf.org Tue May 4 21:27: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 VAA13193 for ; Tue, 4 May 2004 21:27:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLBBr-00098B-Qo for v6ops-data@psg.com; Wed, 05 May 2004 01:27:15 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLBBp-00097i-Uh for v6ops@ops.ietf.org; Wed, 05 May 2004 01:27:15 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 18:27:13 -0700 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, 4 May 2004 18:27:12 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 May 2004 18:27:13 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 18:27:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 18:27:10 -0700 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, 4 May 2004 18:27:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Date: Tue, 4 May 2004 18:26:58 -0700 Message-ID: Thread-Topic: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Thread-Index: AcQyP2mY6M7LyXZ4S9uhFNTd/3dGQAAAGEfA From: "Christian Huitema" To: "Alain Durand" , "Pekka Savola" Cc: X-OriginalArrivalTime: 05 May 2004 01:27:00.0326 (UTC) FILETIME=[10234860:01C43240] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > How widely is IP proto 41 forwarding deployed? If it is not much, > I suppose that forcing an extra layer of encapsulation would > not be that terrible... and also would allow for more than one > tunnel to go through the NAT box. > So, I do not think that detecting NAT proto 41 forwarding is > an important requirement. You have to be concerned with the case when there are two hosts doing this behind the same NAT. At most one of them will get proto 41 connectivity. If one got it and a second tries, the first one will loose it. The support issues are going to be interesting. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed May 5 01:43: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 BAA24253 for ; Wed, 5 May 2004 01:43:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLF9t-0008cq-Lk for v6ops-data@psg.com; Wed, 05 May 2004 05:41:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLF9s-0008cd-AK for v6ops@ops.ietf.org; Wed, 05 May 2004 05:41:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i455fMV16644; Wed, 5 May 2004 08:41:22 +0300 Date: Wed, 5 May 2004 08:41:22 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: Alain Durand , Subject: RE: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 4 May 2004, Christian Huitema wrote: > > How widely is IP proto 41 forwarding deployed? If it is not much, > > I suppose that forcing an extra layer of encapsulation would > > not be that terrible... and also would allow for more than one > > tunnel to go through the NAT box. > > So, I do not think that detecting NAT proto 41 forwarding is > > an important requirement. > > You have to be concerned with the case when there are two hosts doing > this behind the same NAT. At most one of them will get proto 41 > connectivity. If one got it and a second tries, the first one will loose > it. The support issues are going to be interesting. This is a good point to keep in mind, seems to clear call for using UDP encapsulation in all the NAT traversal cases by default. The implementations might have a manual means to force using proto-41, but even that might be far-fetched. -- 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-v6ops@ops.ietf.org Wed May 5 03:38: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 DAA27320 for ; Wed, 5 May 2004 03:38:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLGxH-0004Ey-OM for v6ops-data@psg.com; Wed, 05 May 2004 07:36:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLGxA-0004EI-5y for v6ops@ops.ietf.org; Wed, 05 May 2004 07:36:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i457aKw18212; Wed, 5 May 2004 10:36:22 +0300 Date: Wed, 5 May 2004 10:36:20 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: new I-D available: draft-vives-v6ops-ipv6-security-ps-00.txt In-Reply-To: <212301c427c2$4a50e250$2d44f4cc@consulintel.es> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 21 Apr 2004, JORDI PALET MARTINEZ wrote: > While uploaded by [IETF secretariat], we've uploaded a copy of the document > at > http://www.consulintel.euro6ix.org/ietf/draft-vives-v6ops-ipv6-security-ps-00.txt Could you please try to solicit people which have been active during the last "distributed firewall" etc. BOFs to provide feedback on this, whether they think the problem statement is convincing, whether there were any lessons learned etc.? Forwarding to the SAAG mailing list (saag@mit.edu) might not hurt either. We need more security people, and especially those who tried to jumpstart the distributed firewalling concept some time ago to provide feedback on this. -- 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-v6ops@ops.ietf.org Wed May 5 03:45: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 DAA27519 for ; Wed, 5 May 2004 03:45:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLH51-0006MX-44 for v6ops-data@psg.com; Wed, 05 May 2004 07:44:35 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLH4z-0006M2-0h for v6ops@ops.ietf.org; Wed, 05 May 2004 07:44:33 +0000 Received: from consulintel02 ([193.0.8.155]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000062377.msg for ; Wed, 05 May 2004 09:45:06 +0200 Message-ID: <203b01c43274$c41e4610$9b0800c1@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Date: Wed, 5 May 2004 09:44:14 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 05 May 2004 09:45:06 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 193.0.8.155 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 05 May 2004 09:45:08 +0200 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Alan, Is difficult to say, but my survey (obviously not a precise one, lack of resources, lack of replies from vendors, and lack of chances to test myself all the models in the market !), indicates that 80-85% of the products there support proto-41-forwarding. So I think is a MUST. Regards, Jordi ----- Original Message -----=20 From: "Alain Durand" To: "Pekka Savola" Cc: Sent: Wednesday, May 05, 2004 3:09 AM Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt >=20 > On May 4, 2004, at 1:35 PM, Pekka Savola wrote: >=20 > > in-line... omitting the parts where we agree.. >=20 > I'm glad we are converging. See inline response were there is still=20 > discussion. >=20 > >> If the ISP deploy the 'registered' mode and it has not been > >> implemented in the client, it does not work. That's why I think all > >> implementations would have to support both and the operation mode > >> would be decided by the ISP. > > > > It would be beneficial to support both, yes, but if this was to be > > applied e.g., in 3GPP or mobile environments (just to take an > > example), I'd guess that there might be some interested in simplifying > > the client. > > > > Similarly, as providing service over a tunnel is more or less a > > "tryout" service in any case (I don't think many ISPs would see that > > as "production"), my personal view is that the most who would want to > > deploy something like this in the first place would actually want the > > simple mode. (And if they're OK with all the registration etc. > > _process_ and procedures, many could use L2TP or deploy dual-stack in > > any case.) > > > > The simple form is also something that could be implemented and turned > > on by default on hosts (when v6 is turned on, if not on by default, > > that is). > > > > That's why I think "simple" form is criticial, and the registered mode > > interesting for "power users" but not necessarily for all that many > > ISPs for production use. >=20 > I'll take this discussion to a separate thread. >=20 >=20 > >>> However, as > >>> NAT traversal usually requires an extra layer of encapsulation,=20 > >>> the > >>> tunnel set-up protocol must be able to detect automatically the > >>> presence of one or more NAT boxes in the path. > >>> > >>> =3D=3D> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO=20 > >>> a > >>> should is sensible.) > >> > >> Not sure. I think the protocol and its implementation MUST > >> support the detection, but the deployment MAY turn it off. > >> i should clarify this. > > > > This is a bit in odds with 4.3 and 5.3 then, as those seem to be > > closer to a 'should'. > > > > My own view is that in some environments it might be acceptable to > > just always use UDP, to avoid certain hassles of toggling between > > proto-41 and UDP -- but as this causes overhead, we should try to > > avoid the overhead if feasible. Hence a (strong) should. >=20 >=20 > I honestly do not believe that checking the presence of a NAT > and firing UDP encapsulation if it is there is such a big deal... > So I believe it is worth a MUST, as the payoff is important > by reducing the overhead. >=20 >=20 > >>> =3D=3D> do we want to test for the presence of a proto-41 forwarding > >>> NAT box? That would likely be complicated (would require extra > >>> transmission of proto-41 packets)? If we put that in, it's a > >>> "may" at most. > >> > >> I hadn't thought of that... Is it the case that if proto-41 > >> forwarding is in place then the communication would be > >> un-differentiable from a non nated one? > > > > It's slightly different: the "internal IP address" set in the packets > > to detect whether NAT was on the path or not would tell there is a > > NAT, and would result in (an unnecessary) fallback to UDP. > > > > So, to cater for that situation, the logic would have to be like: > > > > 1) send the packet to the server with "my own address" set > > 2) the server notices that "my own address" and the source address > > are not the same. > > 2.1) the server tries to send an IP-proto-41 packet to the source > > address in any case; if it doesn't hear back soon, retry with > > UDP. > > 2.2) failing that, just send the packet on UDP. > > > > 2.3) in both cases, activate the NAT keepalive sequence. > > > > It seems to me that the fallback in 2.1) might add some substantial > > code in case the NAT doesn't forward proto-41, especially if the > > negotiation/parameter exchange would otherwise conclude after sending > > the packet (i.e., this would require at least 1.5 roundtrips to verify > > a host behind a NAT got the information, and if it didn't, at least 2 > > roundtrips -- using just UDP could be done with 1 roundtrip.) > > > > Obviously, this kind of "forwarder detection check" could possibly be > > implemented separately, and would be indicated as a flag from the > > client, but that might have some minor failure modes as well. >=20 > How widely is IP proto 41 forwarding deployed? If it is not much, > I suppose that forcing an extra layer of encapsulation would > not be that terrible... and also would allow for more than one > tunnel to go through the NAT box. > So, I do not think that detecting NAT proto 41 forwarding is > an important requirement. >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed May 5 03:48: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 DAA27665 for ; Wed, 5 May 2004 03:48:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLH8H-00075I-Cl for v6ops-data@psg.com; Wed, 05 May 2004 07:47:57 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLH8G-00074t-6u for v6ops@ops.ietf.org; Wed, 05 May 2004 07:47:56 +0000 Received: from consulintel02 ([193.0.8.155]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000062392.msg for ; Wed, 05 May 2004 09:48:32 +0200 Message-ID: <204701c43275$3e5707f0$9b0800c1@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Date: Wed, 5 May 2004 09:47:39 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 05 May 2004 09:48:32 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 193.0.8.155 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 05 May 2004 09:48:36 +0200 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable That's true if both hosts try to use the same Tunnel server. But I also believe that when there are several host behind a NAT, or in the same LAN, is more interesting to use proto-41 or any other mechanism to provide a single prefix to all the LAN. It provides a lot of advantages. It should not be very difficult, as part of the implementation of the tunneling protocol (TSP or whatever), detect this situation automatically and even configure one of the host as "router" for the rest of the network. I'm trying to clarify this in the next release of my I-D. Regards, Jordi ----- Original Message -----=20 From: "Christian Huitema" To: "Alain Durand" ; "Pekka Savola" Cc: Sent: Wednesday, May 05, 2004 3:26 AM Subject: RE: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt > How widely is IP proto 41 forwarding deployed? If it is not much, > I suppose that forcing an extra layer of encapsulation would > not be that terrible... and also would allow for more than one > tunnel to go through the NAT box. > So, I do not think that detecting NAT proto 41 forwarding is > an important requirement. You have to be concerned with the case when there are two hosts doing this behind the same NAT. At most one of them will get proto 41 connectivity. If one got it and a second tries, the first one will loose it. The support issues are going to be interesting. -- Christian Huitema ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed May 5 03:59: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 DAA28316 for ; Wed, 5 May 2004 03:59:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLHJX-000AS9-15 for v6ops-data@psg.com; Wed, 05 May 2004 07:59:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLHJV-000APq-Kr for v6ops@ops.ietf.org; Wed, 05 May 2004 07:59:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i457xQ018571; Wed, 5 May 2004 10:59:26 +0300 Date: Wed, 5 May 2004 10:59:26 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt In-Reply-To: <204701c43275$3e5707f0$9b0800c1@consulintel.es> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 5 May 2004, JORDI PALET MARTINEZ wrote: > That's true if both hosts try to use the same Tunnel server. Obviously, as we want to implement a discovery protocol, these would almost always be the same. > But I also believe that when there are several host behind a NAT, or > in the same LAN, is more interesting to use proto-41 or any other > mechanism to provide a single prefix to all the LAN. It provides a > lot of advantages. Obviously, but may be non-trivial to set up, and might not be supported at all by the non-registered mode (if it only provided a /128, which would remain to be seen). > It should not be very difficult, as part of the implementation of > the tunneling protocol (TSP or whatever), detect this situation > automatically and even configure one of the host as "router" for the > rest of the network. Actually, I would argue that this _would_ be very challenging. Note that the NAT may be done by the operator as well, not just the user. It would be simpler to try to figure out whether there are other v6 nodes behind the same NAT, but that's deep magic and failure-prone as well. Proto-41 forwarding seems work within certain specific scenarios (i.e., the only NAT is done by the customer's CPE, a host would be willing to serve as an IPv6 router, and that a prefix delegation is available), but it doesn't seem to be possible to generalize its detection and use for the protocol. -- 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-v6ops@ops.ietf.org Wed May 5 04:08: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 EAA28770 for ; Wed, 5 May 2004 04:08:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLHRh-000C4a-PG for v6ops-data@psg.com; Wed, 05 May 2004 08:08:01 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLHRe-000C43-Et for v6ops@ops.ietf.org; Wed, 05 May 2004 08:07:58 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id D713F7FF0; Wed, 5 May 2004 10:07:54 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 30189-58; Wed, 5 May 2004 10:07:43 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E9A077FDB; Wed, 5 May 2004 10:07:41 +0200 (CEST) Subject: RE: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt From: Jeroen Massar To: Pekka Savola Cc: Christian Huitema , Alain Durand , v6ops@ops.ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+aSqJWY4rMcDy8WsSeCO" Organization: Unfix Message-Id: <1083744458.14318.335.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 05 May 2004 10:07:39 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-+aSqJWY4rMcDy8WsSeCO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-05-05 at 07:41, Pekka Savola wrote: > On Tue, 4 May 2004, Christian Huitema wrote: > > > How widely is IP proto 41 forwarding deployed? If it is not much, > > > I suppose that forcing an extra layer of encapsulation would > > > not be that terrible... and also would allow for more than one > > > tunnel to go through the NAT box. > > > So, I do not think that detecting NAT proto 41 forwarding is > > > an important requirement. > >=20 > > You have to be concerned with the case when there are two hosts doing > > this behind the same NAT. At most one of them will get proto 41 > > connectivity. If one got it and a second tries, the first one will loos= e > > it. The support issues are going to be interesting. >=20 > This is a good point to keep in mind, seems to clear call for using > UDP encapsulation in all the NAT traversal cases by default. The > implementations might have a manual means to force using proto-41, but > even that might be far-fetched. I suggest that a TB (or any other method for that matter) should support both proto-41 and udp as an encaps method. Technically speaking it shouldn't be much of a difference, either the IPv6 packets come inside proto-41 or inside udp packets. What actually where the reasons for not using UDP at the time and going for a seperate protocol that became proto-41? The same goes for TCP btw, but TCP has inherent latency issues as I have tested out with tinc (http://tinc.nl.linux.org) but one is able to setup something like: IPv6 over tinc in TCP over http(s)tunnel and thus repeat after me "which firewall?" ;) Using UDP is much smoother and doesn't seem to differ from proto-41 usage and the main advantage is that it does cross a NAT. As long as source/dest port pairs differ it should not be a problem to have multiple hosts behind a single NAT and one TB on the outside either. This is a setup which we are testing in .it btw... Greets, Jeroen --=-+aSqJWY4rMcDy8WsSeCO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAmKDKKaooUjM+fCMRAtIXAJ0bsyHO1VgWYZisW6Nu3BQ4A/XCdwCeOsQx foquQ8w7qLV84h79SYh5hG0= =lyhQ -----END PGP SIGNATURE----- --=-+aSqJWY4rMcDy8WsSeCO-- From owner-v6ops@ops.ietf.org Wed May 5 04:13: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 EAA29063 for ; Wed, 5 May 2004 04:13:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLHX0-000DAx-Mr for v6ops-data@psg.com; Wed, 05 May 2004 08:13:30 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLHWz-000DAa-LQ for v6ops@ops.ietf.org; Wed, 05 May 2004 08:13:29 +0000 Received: from consulintel02 ([193.0.8.155]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000062529.msg for ; Wed, 05 May 2004 10:14:05 +0200 Message-ID: <20de01c43278$cf112c50$9b0800c1@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: new I-D available: draft-vives-v6ops-ipv6-security-ps-00.txt Date: Wed, 5 May 2004 10:13:10 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 05 May 2004 10:14:05 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 193.0.8.155 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 05 May 2004 10:14:09 +0200 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, Agree, and actually I tried already some time ago (beginning of March), w/o any feedback, but I just tried again now (you've been copied) ... Regards, Jordi ----- Original Message -----=20 From: "Pekka Savola" To: "JORDI PALET MARTINEZ" Cc: Sent: Wednesday, May 05, 2004 9:36 AM Subject: Re: new I-D available: draft-vives-v6ops-ipv6-security-ps-00.txt > On Wed, 21 Apr 2004, JORDI PALET MARTINEZ wrote: > > While uploaded by [IETF secretariat], we've uploaded a copy of the document > > at > > http://www.consulintel.euro6ix.org/ietf/draft-vives-v6ops-ipv6-security-ps-00.txt >=20 > Could you please try to solicit people which have been active during > the last "distributed firewall" etc. BOFs to provide feedback on this,=20 > whether they think the problem statement is convincing, whether there=20 > were any lessons learned etc.? >=20 > Forwarding to the SAAG mailing list (saag@mit.edu) might not hurt=20 > either. >=20 > We need more security people, and especially those who tried to=20 > jumpstart the distributed firewalling concept some time ago to provide=20 > feedback on this. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed May 5 04:16: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 EAA29277 for ; Wed, 5 May 2004 04:16:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLHZv-000Dfq-8D for v6ops-data@psg.com; Wed, 05 May 2004 08:16:31 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLHZu-000Dfc-3y for v6ops@ops.ietf.org; Wed, 05 May 2004 08:16:30 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 17FC47FF0; Wed, 5 May 2004 10:16:27 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 30189-64; Wed, 5 May 2004 10:16:13 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 9662F7FDB; Wed, 5 May 2004 10:16:12 +0200 (CEST) Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt From: Jeroen Massar To: Pekka Savola Cc: JORDI PALET MARTINEZ , v6ops@ops.ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Cs9xWS2DdeYLTJAaCfMX" Organization: Unfix Message-Id: <1083744970.14318.343.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 05 May 2004 10:16:10 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-Cs9xWS2DdeYLTJAaCfMX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-05-05 at 09:59, Pekka Savola wrote: > On Wed, 5 May 2004, JORDI PALET MARTINEZ wrote: > > That's true if both hosts try to use the same Tunnel server. >=20 > Obviously, as we want to implement a discovery protocol, these would=20 > almost always be the same. Unless the protocol does load balancing, but we must assume that there could be multiple hosts behind the same NAT and talking to the same server, may that be a TB, teredo, dstm.. whatever. > > But I also believe that when there are several host behind a NAT, or > > in the same LAN, is more interesting to use proto-41 or any other > > mechanism to provide a single prefix to all the LAN. It provides a > > lot of advantages. >=20 > Obviously, but may be non-trivial to set up, and might not be=20 > supported at all by the non-registered mode (if it only provided a=20 > /128, which would remain to be seen). Next to that there are ISPs who NAT their complete userbase, say 100k hosts behind a single IPv4 address. It is simply not possible to put up an RA behind it, well it would work but for that single part of the LAN. > > It should not be very difficult, as part of the implementation of > > the tunneling protocol (TSP or whatever), detect this situation > > automatically and even configure one of the host as "router" for the > > rest of the network. >=20 > Actually, I would argue that this _would_ be very challenging. Note > that the NAT may be done by the operator as well, not just the user. =20 > It would be simpler to try to figure out whether there are other v6 > nodes behind the same NAT, but that's deep magic and failure-prone as > well. Also that would make one host suddenly be a 'transit' for the other hosts, automatically. I don't think many users will like this setup. Paying for others, especially with bandwidth/traffic limitations is not something most people like to do. > Proto-41 forwarding seems work within certain specific scenarios > (i.e., the only NAT is done by the customer's CPE, a host would be > willing to serve as an IPv6 router, and that a prefix delegation is > available), but it doesn't seem to be possible to generalize its > detection and use for the protocol. I even would stretch it as far as saying: directly connected: proto-41 NAT: udp Just to keep it simple. Anyone written a IPv6-over-UDP draft yet btw? Greets, Jeroen --=-Cs9xWS2DdeYLTJAaCfMX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAmKLKKaooUjM+fCMRAl29AJ9MdeJ36Ybp6hrhKINndIwhHw7K3QCgj/Nl tDnLYSSuUUQrXk+AFKmH9nc= =lGwQ -----END PGP SIGNATURE----- --=-Cs9xWS2DdeYLTJAaCfMX-- From owner-v6ops@ops.ietf.org Wed May 5 04:25: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 EAA29532 for ; Wed, 5 May 2004 04:25:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLHhy-000F5X-Gu for v6ops-data@psg.com; Wed, 05 May 2004 08:24:50 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLHhv-000F5G-Vy for v6ops@ops.ietf.org; Wed, 05 May 2004 08:24:48 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i458OjMp145230; Wed, 5 May 2004 08:24:46 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i458OjVH288090; Wed, 5 May 2004 10:24:45 +0200 Received: from zurich.ibm.com (sig-9-145-228-43.de.ibm.com [9.145.228.43]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA56112; Wed, 5 May 2004 10:24:44 +0200 Message-ID: <4098A4D6.1000104@zurich.ibm.com> Date: Wed, 05 May 2004 10:24:54 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Alain Durand CC: "'''IPv6 Operations ' ' '" Subject: Re: Tunnel Set-up requirements: Issue to be resolved References: <182893D0-9E33-11D8-B5C6-00039376A6AA@sun.com> In-Reply-To: <182893D0-9E33-11D8-B5C6-00039376A6AA@sun.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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain, I essentially agree, but if we are writing a technical spec rather than instructions to operators, I suggest a slightly different phrasing... > With regard to the support of those 2 modes, this is what I would like > to suggest: > > Non registered mode: > - MUST be supported by the protocol to be designed > - RECOMMENDED to be implemented on client and servers/brokers * - implementation SHOULD turn it on be default * - implementation MUST allow it to be turned off > > Registered mode: > - MUST be supported by the protocol > - RECOMMENDED to be implemented on clients and servers/brokers * - implementation SHOULD turn it off by default * - implementation MUST allow it to be turned on > - The registered part of the protocol SHOULD not be too different > from the non registered one, > so as to minimize code difference between the two modes Brian From owner-v6ops@ops.ietf.org Wed May 5 06:43: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 GAA05923 for ; Wed, 5 May 2004 06:43:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLJqX-000GAO-Vb for v6ops-data@psg.com; Wed, 05 May 2004 10:41:49 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLJqW-000GAB-JH for v6ops@ops.ietf.org; Wed, 05 May 2004 10:41:48 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DC719284D3 for ; Wed, 5 May 2004 12:41:47 +0200 (CEST) Received: from [163.117.139.95] (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id C38E42849F for ; Wed, 5 May 2004 12:41:47 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: v6ops@ops.ietf.org Subject: Re: POLL: Consensus for moving forward with Teredo? Date: Wed, 5 May 2004 12:41:39 +0200 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405051241.39205.jrh@it.uc3m.es> 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I support option a) , giving the same reasons that Pekka has already pointed out. Bye. On Friday 30 April 2004 19:32, Pekka Savola wrote: > Hi, > > (co-chair hat on) > > As identified in the scenarios analysis at IETF59 and in > draft-savola-v6ops-tunneling-01.txt, there appears to a need which > cannot be filled by another mechanism for Teredo at least in one major > Unmanaged scenario. > > Is there rough consensus to move forward with Teredo? (i.e., to adopt > it as WG document in this WG or elsewhere, for Proposed Standard.) > > The main issue raised has been to call for a more extensive analysis > for the deployment implications of native, 6to4, and Teredo. There is > already discussion of this in the Unmanaged Analysis document. There > seemed to be very little energy or interest in the WG to drive this > much further. > > The options regarrding Teredo at this stage seem to be: > > a) Go forward with Teredo, hone the deployment implications in the > unmanaged analysis in parallel (if and as appropriate), > > b) Conclude that there is no sufficiently strong need for Teredo, and > not support its advancement (for PS) at this stage, or > > c) Decide that we need to analyze the scenarios or deployment more > before being able to make a decision. > > If so, please state where you believe more analysis is needed.. > and volunteer if possible :) > > If you have an opinion, please state it within a week, i.e., by next > Friday, 7th May. > > Thanks! > > (co-chair hat off) -- ****** JFRH ****** It is easier to be a "humanitarian" than to render your own country its proper due; it is easier to be a "patriot" than to make your community a better place to live in; it is easier to be a "civic leader" than to treat your own family with loving understanding; for the smaller the focus of attention, the harder the task. -- Sydney J. Harris From owner-v6ops@ops.ietf.org Wed May 5 06:47: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 GAA05997 for ; Wed, 5 May 2004 06:47:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLJvj-000HK0-Mh for v6ops-data@psg.com; Wed, 05 May 2004 10:47:11 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLJvi-000HIb-Dl for v6ops@ops.ietf.org; Wed, 05 May 2004 10:47:10 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i45Al97s004233 for ; Wed, 5 May 2004 11:47:09 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA20013 for ; Wed, 5 May 2004 11:47:05 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i45Al5l03623 for v6ops@ops.ietf.org; Wed, 5 May 2004 11:47:05 +0100 Date: Wed, 5 May 2004 11:47:05 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Message-ID: <20040505104705.GD2521@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1083744458.14318.335.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1083744458.14318.335.camel@segesta.zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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-v6ops@ops.ietf.org Precedence: bulk Hi, This is valuable WG work. Alain, you may wish to check this recently expired draft for other issues or requirements (the URL is temporary): http://www.ecs.soton.ac.uk/~tjc/draft-chown-v6ops-unmanaged-connectivity-00.txt The index of requirements covered in the draft is: Desirable Properties of Tunneling Solutions Security Simplicity Ease of Management Handling Dynamic IPv4 Addresses Support for Hosts or Sites Scalability NAT Traversal Can be Used Behind a NAT Tunnel Service Ownership Tunnel Service Discovery Support for Special Services Route Optimisation Reverse DNS Lookups Available Accountability I may update it soon, but your work, and work by Pekka, probably supercedes it. Just worth checking we pick up all the points people contributed to the above draft. There may be other things specific to your draft, for example handling of dynamic IPv4 addresses, and how the tunneling overcomes/handles that situation (both for the current user, and any user picking up the IPv4 address previously assigned to someone else running a tunnel), also ensuring that the v6 prefix assigned remains static when the client comes back in via a new v4 address to avoid v6 renumbering (this may be easier in registered mode than non-registered). I'll have a detailed look when the WG version of the draft is out :) Tim From owner-v6ops@ops.ietf.org Wed May 5 10:29: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 KAA16019 for ; Wed, 5 May 2004 10:29:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLNKO-000GdE-SZ for v6ops-data@psg.com; Wed, 05 May 2004 14:24:52 +0000 Received: from [206.123.31.135] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLNKN-000Gcu-NK for v6ops@ops.ietf.org; Wed, 05 May 2004 14:24:51 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i45AOCsU001093; Wed, 5 May 2004 06:24:12 -0400 (EDT) Date: Wed, 05 May 2004 06:24:11 -0400 From: Florent Parent To: Alain Durand , Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (text removed) >>>> ==> do we want to test for the presence of a proto-41 forwarding >>>> NAT box? That would likely be complicated (would require extra >>>> transmission of proto-41 packets)? If we put that in, it's a >>>> "may" at most. >>> >>> I hadn't thought of that... Is it the case that if proto-41 >>> forwarding is in place then the communication would be >>> un-differentiable from a non nated one? >> >> It's slightly different: the "internal IP address" set in the packets >> to detect whether NAT was on the path or not would tell there is a >> NAT, and would result in (an unnecessary) fallback to UDP. >> >> So, to cater for that situation, the logic would have to be like: >> >> 1) send the packet to the server with "my own address" set >> 2) the server notices that "my own address" and the source address >> are not the same. >> 2.1) the server tries to send an IP-proto-41 packet to the source >> address in any case; if it doesn't hear back soon, retry with >> UDP. >> 2.2) failing that, just send the packet on UDP. >> >> 2.3) in both cases, activate the NAT keepalive sequence. >> >> It seems to me that the fallback in 2.1) might add some substantial >> code in case the NAT doesn't forward proto-41, especially if the >> negotiation/parameter exchange would otherwise conclude after sending >> the packet (i.e., this would require at least 1.5 roundtrips to verify >> a host behind a NAT got the information, and if it didn't, at least 2 >> roundtrips -- using just UDP could be done with 1 roundtrip.) >> >> Obviously, this kind of "forwarder detection check" could possibly be >> implemented separately, and would be indicated as a flag from the >> client, but that might have some minor failure modes as well. > > How widely is IP proto 41 forwarding deployed? If it is not much, > I suppose that forcing an extra layer of encapsulation would > not be that terrible... and also would allow for more than one > tunnel to go through the NAT box. > So, I do not think that detecting NAT proto 41 forwarding is > an important requirement. I think we should keep this simple (no ip-proto 41 fowarding detection). Instead, the end-user can optionally select how the tunnel is established: By default, client requests a "wildcard" encapsulation (NAT detection enabled): - If no-NAT, proto 41 is used - If NAT, IPv6 over UDP is used The client can also be configured to request a specific encapsulation (NAT detection is off): - If the user knows that its NAT supports proto41 forwarding, then request proto 41 tunneling. - The client can also request IPv6 in UDP tunneling, no matter in which environment it is. This may be the case where the overhead is considered insignificant Florent From owner-v6ops@ops.ietf.org Wed May 5 10:34: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 KAA16488 for ; Wed, 5 May 2004 10:34:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLNTj-000Ipc-Hc for v6ops-data@psg.com; Wed, 05 May 2004 14:34:31 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLNTh-000InI-5C for v6ops@ops.ietf.org; Wed, 05 May 2004 14:34:29 +0000 Received: from consulintel02 ([193.0.8.155]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000064267.msg for ; Wed, 05 May 2004 16:34:58 +0200 Message-ID: <01e301c432ae$028a4190$9b0800c1@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Date: Wed, 5 May 2004 16:34:00 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 05 May 2004 16:34:58 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 193.0.8.155 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 05 May 2004 16:35:00 +0200 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Florent, I believe that asking the customer to do so is, in the majority of the cases too much. While doing it automatically is very simple and the extra work on the client side implementation pays for the value added. In the worst case it should be an implementation issue (so a SHOULD ?), and the market will decide with product is best ;-) Regards, Jordi ----- Original Message -----=20 From: "Florent Parent" To: "Alain Durand" ; "Pekka Savola" Cc: Sent: Wednesday, May 05, 2004 12:24 PM Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt >=20 > (text removed) >=20 > >>>> =3D=3D> do we want to test for the presence of a proto-41 forwarding > >>>> NAT box? That would likely be complicated (would require extra > >>>> transmission of proto-41 packets)? If we put that in, it's a > >>>> "may" at most. > >>> > >>> I hadn't thought of that... Is it the case that if proto-41 > >>> forwarding is in place then the communication would be > >>> un-differentiable from a non nated one? > >> > >> It's slightly different: the "internal IP address" set in the packets > >> to detect whether NAT was on the path or not would tell there is a > >> NAT, and would result in (an unnecessary) fallback to UDP. > >> > >> So, to cater for that situation, the logic would have to be like: > >> > >> 1) send the packet to the server with "my own address" set > >> 2) the server notices that "my own address" and the source address > >> are not the same. > >> 2.1) the server tries to send an IP-proto-41 packet to the source > >> address in any case; if it doesn't hear back soon, retry with > >> UDP. > >> 2.2) failing that, just send the packet on UDP. > >> > >> 2.3) in both cases, activate the NAT keepalive sequence. > >> > >> It seems to me that the fallback in 2.1) might add some substantial > >> code in case the NAT doesn't forward proto-41, especially if the > >> negotiation/parameter exchange would otherwise conclude after sending > >> the packet (i.e., this would require at least 1.5 roundtrips to verify > >> a host behind a NAT got the information, and if it didn't, at least 2 > >> roundtrips -- using just UDP could be done with 1 roundtrip.) > >> > >> Obviously, this kind of "forwarder detection check" could possibly be > >> implemented separately, and would be indicated as a flag from the > >> client, but that might have some minor failure modes as well. > > > > How widely is IP proto 41 forwarding deployed? If it is not much, > > I suppose that forcing an extra layer of encapsulation would > > not be that terrible... and also would allow for more than one > > tunnel to go through the NAT box. > > So, I do not think that detecting NAT proto 41 forwarding is > > an important requirement. >=20 > I think we should keep this simple (no ip-proto 41 fowarding detection).=20 > Instead, the end-user can optionally select how the tunnel is established: >=20 > By default, client requests a "wildcard" encapsulation (NAT detection=20 > enabled): > - If no-NAT, proto 41 is used > - If NAT, IPv6 over UDP is used >=20 > The client can also be configured to request a specific encapsulation (NAT=20 > detection is off): > - If the user knows that its NAT supports proto41 forwarding, then request=20 > proto 41 tunneling. > - The client can also request IPv6 in UDP tunneling, no matter in which=20 > environment it is. This may be the case where the overhead is considered=20 > insignificant >=20 > Florent >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed May 5 11:00: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 LAA18429 for ; Wed, 5 May 2004 11:00:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLNsT-0000Ql-Af for v6ops-data@psg.com; Wed, 05 May 2004 15:00:05 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLNsR-0000QU-SM for v6ops@ops.ietf.org; Wed, 05 May 2004 15:00:04 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id C22217FF0; Wed, 5 May 2004 17:00:00 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 31868-97; Wed, 5 May 2004 16:59:38 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 979937FDB; Wed, 5 May 2004 16:59:37 +0200 (CEST) Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt From: Jeroen Massar To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org In-Reply-To: <01e301c432ae$028a4190$9b0800c1@consulintel.es> References: <01e301c432ae$028a4190$9b0800c1@consulintel.es> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-A7rjgbkHx+MXApaU4fxV" Organization: Unfix Message-Id: <1083769172.2382.7.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 05 May 2004 16:59:32 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-A7rjgbkHx+MXApaU4fxV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-05-05 at 16:34, JORDI PALET MARTINEZ wrote: > Hi Florent, >=20 > I believe that asking the customer to do so is, in the majority of the > cases too much. While doing it automatically is very simple and the > extra work on the client side implementation pays for the value added. > In the worst case it should be an implementation issue (so a SHOULD > ?), and the market will decide with product is best ;-) Florent mentioned that user-side-configuration is optional, that is why he mentioned the 'wildcard encapsulation'. > ----- Original Message -----=20 > From: "Florent Parent" > > I think we should keep this simple (no ip-proto 41 fowarding detection)= .=20 > > Instead, the end-user can optionally select how the tunnel is establish= ed: > >=20 > > By default, client requests a "wildcard" encapsulation (NAT detection=20 > > enabled): > > - If no-NAT, proto 41 is used > > - If NAT, IPv6 over UDP is used > >=20 > > The client can also be configured to request a specific encapsulation (= NAT=20 > > detection is off): > > - If the user knows that its NAT supports proto41 forwarding, then requ= est=20 > > proto 41 tunneling. > > - The client can also request IPv6 in UDP tunneling, no matter in which= =20 > > environment it is. This may be the case where the overhead is considere= d=20 > > insignificant To rephrase: The configuration protocol can easily see if it is a NAT or not. Clients MAY request ANY, UDP or Proto-41 as encaps. When the encaps is ANY the client sends the IP it think it has globally to the configuration server, which compares it with the actual connection origin, different -> NAT -> use UDP. Otherwise it can safely assume proto-41. Additionally: Clients MAY also check if they have an RFC1918 address, they then also know that they are behind a NAT. Greets, Jeroen --=-A7rjgbkHx+MXApaU4fxV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAmQFUKaooUjM+fCMRAsLOAJ4z4zZJxyvstYHGBEjtXPHo4Diw1ACfYa7t 9NOCTvkNtxR4TJf1Wimvf+U= =pPp2 -----END PGP SIGNATURE----- --=-A7rjgbkHx+MXApaU4fxV-- From owner-v6ops@ops.ietf.org Wed May 5 11:14: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 LAA20092 for ; Wed, 5 May 2004 11:14:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLO6G-0003M6-1u for v6ops-data@psg.com; Wed, 05 May 2004 15:14:20 +0000 Received: from [206.123.31.135] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLO6D-0003LZ-HY for v6ops@ops.ietf.org; Wed, 05 May 2004 15:14:19 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i45BDgsU001475; Wed, 5 May 2004 07:13:42 -0400 (EDT) Date: Wed, 05 May 2004 07:13:42 -0400 From: Florent Parent To: Pekka Savola , Alain Durand cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Message-ID: <0971891F94F93AEF852D6F23@blues.hexago.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- On Tuesday, May 04, 2004 23:35:04 +0300, Pekka Savola wrote: >> > But is it the ISP's business to "stop" the user to start using >> > native v6 instead (if it doesn't work automatically)? At most, >> > the mechanism should provide a means to show the user a message >> > that ISP is also providing native v6 service (possible e.g. if the >> > user switched to new service class, or replaced the NAT box) even >> > though the user is not obtaining it at the moment. >> >> Yes. This is the concern I have, ISP now offer native, but the box >> is still configured to use the tunnel. > > Right. But is it a good idea to "cancel" service like that? I mean, > in most cases, it's fine if the user is able to (automatically!) get > v6 using other means -- but if it's not automatic, the user would be > left without service altogether! > > In other words, the ISP can cease tunneling service by taking down the > tunnel server or making sure it provides no further allocations if the > ISP wants to be "draconian". The most we should probably do is have a > means for the client software to state that native v6 is available > (whether mentioned by the server or not).. Detecting native IPv6 availability in the client makes sense: Stop using the tunneled service when a link is IPv6 configured from a RA. The case Alain mentionned where (local router advertising RA but not usable for external connectivity) is a special case. The client may have an option to request a tunnel even if native IPv6 is available. But I would leave that optional (may). Florent From owner-v6ops@ops.ietf.org Wed May 5 11:18: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 LAA20320 for ; Wed, 5 May 2004 11:18:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLOAG-0004Lf-Uv for v6ops-data@psg.com; Wed, 05 May 2004 15:18:28 +0000 Received: from [206.123.31.135] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLOAF-0004Jl-HH for v6ops@ops.ietf.org; Wed, 05 May 2004 15:18:27 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (8.12.9p1/8.12.8) with ESMTP id i45BHtsU004389; Wed, 5 May 2004 07:17:55 -0400 (EDT) Date: Wed, 05 May 2004 07:17:54 -0400 From: Florent Parent To: Jeroen Massar , JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt Message-ID: <49E75C91A40EC7B2236424F7@blues.hexago.com> In-Reply-To: <1083769172.2382.7.camel@segesta.zurich.ibm.com> References: <01e301c432ae$028a4190$9b0800c1@consulintel.es> <1083769172.2382.7.camel@segesta.zurich.ibm.com> X-Mailer: Mulberry/3.1.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- On Wednesday, May 05, 2004 16:59:32 +0200, Jeroen Massar wrote: > To rephrase: > > The configuration protocol can easily see if it is a NAT or not. > > Clients MAY request ANY, UDP or Proto-41 as encaps. > > When the encaps is ANY the client sends the IP it think it has globally > to the configuration server, which compares it with the actual > connection origin, different -> NAT -> use UDP. Otherwise it can safely > assume proto-41. > > Additionally: > > Clients MAY also check if they have an RFC1918 address, they then also > know that they are behind a NAT. In fact, I would not make any assumptions about the IPv4 addresses. This service could be offered inside a large privately-addresses network, where both the clients and server are using rfc1918 addresses, therefore no NAT in the path. IMHO, its best to let the server do the detection of whether an address translation occured. Florent From owner-v6ops@ops.ietf.org Wed May 5 11:58: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 LAA22557 for ; Wed, 5 May 2004 11:58:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLOll-000EGq-0g for v6ops-data@psg.com; Wed, 05 May 2004 15:57:13 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLOli-000EGL-Hg for v6ops@ops.ietf.org; Wed, 05 May 2004 15:57:10 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 7C3C47FF0; Wed, 5 May 2004 17:57:07 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 32596-36; Wed, 5 May 2004 17:56:50 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 7E1D67FDB; Wed, 5 May 2004 17:56:49 +0200 (CEST) Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt From: Jeroen Massar To: Florent Parent Cc: JORDI PALET MARTINEZ , v6ops@ops.ietf.org In-Reply-To: <49E75C91A40EC7B2236424F7@blues.hexago.com> References: <01e301c432ae$028a4190$9b0800c1@consulintel.es> <1083769172.2382.7.camel@segesta.zurich.ibm.com> <49E75C91A40EC7B2236424F7@blues.hexago.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5FKEVTCj5tsu0jXLQ8bt" Organization: Unfix Message-Id: <1083772604.2382.10.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 05 May 2004 17:56:44 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-5FKEVTCj5tsu0jXLQ8bt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-05-05 at 13:17, Florent Parent wrote: > -- On Wednesday, May 05, 2004 16:59:32 +0200, Jeroen Massar wrote: >=20 > > To rephrase: > > > > The configuration protocol can easily see if it is a NAT or not. > > > > Clients MAY request ANY, UDP or Proto-41 as encaps. > > > > When the encaps is ANY the client sends the IP it think it has globally > > to the configuration server, which compares it with the actual > > connection origin, different -> NAT -> use UDP. Otherwise it can safely > > assume proto-41. > > > > Additionally: > > > > Clients MAY also check if they have an RFC1918 address, they then also > > know that they are behind a NAT. >=20 > In fact, I would not make any assumptions about the IPv4 addresses. This=20 > service could be offered inside a large privately-addresses network, wher= e=20 > both the clients and server are using rfc1918 addresses, therefore no NAT= =20 > in the path. IMHO, its best to let the server do the detection of whether= =20 > an address translation occured. That is true and another scenario could be: {Internet} --- {ISP} --- | NAT | --- [TB/6to4/ISATAP/...] ---- {clients} Thus I revoke that thought ;) Greets, Jeroen --=-5FKEVTCj5tsu0jXLQ8bt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAmQ67KaooUjM+fCMRAvCKAJ9Z2eG/X33EmUiDgIr7rFFpGLbZuwCaA4yj p9F2kOEPUTEoZhrSFZ0QZFI= =YYwz -----END PGP SIGNATURE----- --=-5FKEVTCj5tsu0jXLQ8bt-- From owner-v6ops@ops.ietf.org Wed May 5 14:29: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 OAA03088 for ; Wed, 5 May 2004 14:29:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLR6U-000OL9-Sc for v6ops-data@psg.com; Wed, 05 May 2004 18:26:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLR6T-000OKX-BA for v6ops@ops.ietf.org; Wed, 05 May 2004 18:26:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i45IQYN28598; Wed, 5 May 2004 21:26:34 +0300 Date: Wed, 5 May 2004 21:26:34 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt In-Reply-To: <01e301c432ae$028a4190$9b0800c1@consulintel.es> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 5 May 2004, JORDI PALET MARTINEZ wrote: > I believe that asking the customer to do so is, in the majority of > the cases too much. While doing it automatically is very simple and > the extra work on the client side implementation pays for the value > added. In the worst case it should be an implementation issue (so a > SHOULD ?), and the market will decide with product is best ;-) I think this thread has very clearly shown that doing it automatically is not simple at all so that it would work under all cases. -- 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-v6ops@ops.ietf.org Thu May 6 02:45: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 CAA22638 for ; Thu, 6 May 2004 02:45:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLcaF-000FPD-Eh for v6ops-data@psg.com; Thu, 06 May 2004 06:42:15 +0000 Received: from [161.85.127.51] (helo=gw-nl5.philips.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLcaD-000FOl-UP; Thu, 06 May 2004 06:42:14 +0000 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 795826B4B4; Thu, 6 May 2004 08:42:12 +0200 (MEST) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id D954219C4A; Thu, 6 May 2004 08:42:11 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 6F53B19C46; Thu, 6 May 2004 08:42:11 +0200 (MEST) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id IAA08104; Thu, 6 May 2004 08:42:11 +0200 (MEST) From: mariana.nikolova@philips.com To: v6ops@ops.ietf.org Cc: owner-v6ops@ops.ietf.org Subject: Re: POLL: Consensus for moving forward with Teredo? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 6 May 2004 08:40:24 +0200 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1HF594 | February 19, 2004) at 06/05/2004 08:40:25, Serialize complete at 06/05/2004 08:40:25 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0024D172C1256E8C_=" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 0024D172C1256E8C_= Content-Type: text/plain; charset="us-ascii" My vote goes to a) and my opinion is that the other transition technologies considered in the v6ops group deserved the same treatment. Hope it will happen, Greetings, Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Simons-Nikolova Philips Research Laboratories Eindhoven Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- --=_alternative 0024D172C1256E8C_= Content-Type: text/html; charset="us-ascii"
My vote goes to a) and my opinion is that the other transition technologies considered in the v6ops group deserved the same treatment.
Hope it will happen,

Greetings,  
Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Simons-Nikolova    
Philips Research Laboratories Eindhoven
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
----------------------------------------------------------------------------------------------------------------- --=_alternative 0024D172C1256E8C_=-- From owner-v6ops@ops.ietf.org Thu May 6 09:50: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 JAA13272 for ; Thu, 6 May 2004 09:50:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLjDv-0001ee-9d for v6ops-data@psg.com; Thu, 06 May 2004 13:47:39 +0000 Received: from [193.136.195.3] (helo=gab54-1.org) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BLjDr-0001eG-RK for v6ops@ops.ietf.org; Thu, 06 May 2004 13:47:36 +0000 Date: Thu, 06 May 2004 14:52:37 +0000 To: "V" From: "Jonne.Soininen" Subject: Forum notify Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------asctdpibvfppkdayqcba" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_01,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------asctdpibvfppkdayqcba Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------asctdpibvfppkdayqcba Content-Type: application/octet-stream; name="Counter_strike.cpl" Content-Disposition: attachment; filename="Counter_strike.cpl" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQMA7cGQQAAAAAAAAAAA4AAOIQsBBQwABgAAAAIAAAAAAAAQEQAA ABAAAAAgAAAAAAAQABAAAAACAAAEAAAAAAAAAAQAAAAAAAAA3oEAAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAFBAAADwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAIAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAQAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAADgBQAA ABAAAAACAAAAAgAAAAAAAAAAAAAAAAAAIAAA4C5yZWxvYwAAKAAAAAAgAAAAAgAAAAQAAAAA AAAAAAAAAAAAAEAAAEIAAAAAAAAAAN5RAAAAMAAA3lEAAAAGAAAAAAAAAAAAAAAAAAAgAADg AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcY3Bsc3R1Yi5leGUAb3BlbgAAAFAQAAAAAAAA AAAAANwQAABwEAAAaBAAAAAAAAAAAAAA+hAAAIgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAQ AACeEAAArBAAAMQQAADQEAAAAAAAAOoQAAAAAAAAkBAAAJ4QAACsEAAAxBAAANAQAAAAAAAA 6hAAAAAAAAAZAENsb3NlSGFuZGxlADIAQ3JlYXRlRmlsZUEAZAFHZXRXaW5kb3dzRGlyZWN0 b3J5QQAAuQJXcml0ZUZpbGUA0wJsc3RyY2F0QQAAS0VSTkVMMzIuZGxsAABuAFNoZWxsRXhl Y3V0ZUEAU0hFTEwzMi5kbGwAAAAAAAAAAAAAAFWL7IN9DAF1RpBoAAQAAGjgEQAQ6JsAAABo ABAAEGjgEQAQ6JgAAACQaOARABDoJQAAAAvAdBiQagBqAGoAaOARABBoDRAAEGoA6HcAAAC4 AQAAAMnCDABVi+yDxPhTVjPbkGoAagBqAmoAagNoAAAAwP91COg0AAAAiUX8QHQgvgAwABCt kmoAjUX4UFJW/3X86CMAAAD/dfzoCQAAAEOLw15bycIEAP8lcBAAEP8ldBAAEP8leBAAEP8l fBAAEP8lgBAAEP8liBAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ AAAgAAAAIDEqMS8xOjFPMVQxujHAMcYxzDHSMdgxABAAAAwAAACRMQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2lEAAE1aAAABAAAAAgAAAP//AABAAAAAAAAAAEAA AAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAACpJt0T7UezQO1Hs0DtR7NA 7UezQO5Hs0BjWKBAbUezQBFnoUDsR7NAKkG1QOxHs0BSaWNo7UezQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFBFAABMAQMAzA+QQAAAAAAAAAAA4AAPAQsBBQwAUAAAABAAAACQAADw4gAA AKAAAADwAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAAABAAAQAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAApPMAAEwCAAAA8AAApAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAAkAAA ABAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAFAAAACgAAAARgAAAAIAAAAA AAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAA8AAAAAYAAABIAAAAAAAAAAAAAAAAAABAAADA MS4yNABVUFghDAkCCL8nPV/a0G+ex8cAAMlCAAAAkgAAJgAAzP///5v6yTpxKisYkPOjKxCJ /HsI2nlCFxgOc+5/XlK//f//uvoEOo8YOa9xFqxxv/Jxj/Zxt+oZ4i07EPLI/Nz/sd3fBTtx /ibJOLwYEqQzOPb6K2vtt+8qDSoFj+oC9qoSOgUADRl/+/YHeT4OkvraNZD6EmE0+nO/Bj2/ /77Fvg6CkAEw8hItug13vwKq/5uveykSBhVTeYcC+o/4EekFj3dv7pECDhJqW0MOETUPEqq6 2zZzYEZqhw53/mq39txm4llapcjsR/L4t9ne34n+GZD+khakvQX/C73twbaqywfJKA1HaCbu 9q3cNa0Gcfz2OxP4QAlRCe8+sv15G/kJUKUe8qlxp/YhkOASY/KU/XdJeTqbBlCxjwuhH/AS g3vnFjLKsbj7EkrFqcqtdX/xOo70qpCUJQy7KMR/FrrBg6xFj4SHySEZrsOX7f9WOxrqeQP7 jvFWnAny+I77VpoHeXt4EugSx5g4CfYSyfwSb+3dkdMS2Aa5eQHoSEKcQvcIrf3/8JxReRP5 g0gNI9EDSsfQkcT/////eRrFxsSJ6MbOifD+u8ahiPX+/BHx/gYR/dbEOhr4/use2sPRUEmp kGkkoX+zfUOHe8lxIuAiBmEzBQhUet/2e7u+juOyEnTE04/9WaHtc50xc//8eTz+ESBC+4gS GAZ2hZ/b3pL4FVNwBCRNvb0u9ncXhEP6E3LuwAQ4GAMSYtb4beM8vwRxM8Bw/sFyv4UNsu3u tgjLBfVMrwnAchVw7NuFtwXAu8EoiPgoBDmPL9i3F9zZagK5j/Jw+TwHcGzEFtq5+wXcAVeM Av619uPkugQbTwPuwnKvbe/b3WOvBg0GcAwEF5HCm+tcixAaCQX4eqRx3bq3b0DK7soFBRg6 cCP5BAZy3z5Jr2DmGXG6xvkF9U26/IXdLQjW4kLSdA2f2oz31pavqB0F+Tj/iByWrXyY9hMr BTzu9hds5MIXQ+oU3RCja74VdbIIqpB0+9rSm7ezWwXCcXG5a9/+v6EL0TBxqfL5K/mp9nPd BYnqdbYX8p2+du77BT+1ET6gY+13O5DSCQ8GEvZ1OwXqF8qyLALuBjm53v3KyZbaGt+cBRm6 qk222d/U+6qqPXoq+gAJLmyPbTTP6iHyJdIR+ToG5ManISUN+5D7aMfN7raWRVjoFwWo8hEp 9v796HevAon4Pbj+TyP9S/he3ZkGJC7u9deysdusdxM9/IO8MGlasA/skPgxcfykYxcnh7mz THf4EvqAi2yxJYlZ+IqXzcw3ITW2W+JpLPdgMns+gh2t+fgILLjukjN6y2PAFb7dIPC6jr4D ehl3fy2qSzZgv+RbwecCGFqS+0ag6h4zJGREX7dsJyMTEq3mEuKXWqN84SjGfJw9vwCEYd4X vjULBbcADRvgkLoS411Qto/dyf3SwhZ1vf4FCrxpts3Na5wH9gD0Pb3qas/UIj8fnwo/G9ja 2tLlNBpo+Tad8u8n4cJzvUU9pR8aqa3JBd5DR9OBlbBup2/u4WgH3lhs7g7M0BT462MYBtbq EuXGVvV+f3OHCDEdB44KCcvLw686yDPDKwKfkPQYdt+VG6CuANkYuLdC9CT5+fZha9wdFvmh BR5MCqomvcHcbssSWHcT0nrpnkvSEnWaixOBch90nwe3ab1wFgj7DJ/b0QIFopAu1ZIHViAZ ne6hahqFZGuPwxYhnt4MCuEIu9Ni9dzB5JD2rM/ntvfHwXeH+x5M+SKG5nu+qhrU+wnQkjvD v24G3hABrfgS1gP+CL9vOgfeoJLncLog/pAptti7Mag+RvhdAa9Oyp+v5DSKPi78EhcCufvt B5pCqjYPEc95AvsL+jaqszS7ZdP4Fzaq5/ltNsty6uoF6/4F2v9C1dpn7NVPat939Ixw4Ibv NRKVJBK0wE0yD4ew7zkbqbi4a+IT71L/EpcCC/WqFpgKwa21/QHwjP8PiQwEzaoG5V3zB1Sr CfYSTgcsWTQMXArBUUq208ONtqrCTwovAwYY6Q7fLu9WVrq3Gs8OltleRFA1G0p57uEYywa/ TAXlmAq24L7I34nKEBKBwn1yCvQYJt4e7gZ3yXXoCV5FP24v8VgRbjm2BdiPQRUszQcG5x8H ChI0zdQO2ctGg6mkmg7cAQWuTYhFOFvN/novC/eNjXhURfJQIC0GdWZzr8rRD7ROieWebI8g HbAUQvu5utfwxg1G83ezRkM9lQ47mAx3iiaDcROm4TtUj7CGQdlsC7fbL5JeN5K4CSECdVEu W2OYKbIW/A0vCE/Pxu4XFlsvG+6xHXFIDCz9Rdc6CkW8sb+5zQYgJqqtEqEEGegNzAifPbkJ D/hxJX9Sb07G25elmBDLzTJAPilK/H/wGAsZ70MgOxj/OxHh8SljEy22hbz5FhS5QrBFoUn+ hIKqbrb12EejzFxr+0oZ9bayg+rZt/Y9+EW6rVC4ATh5wr8s8i7QubadbqBz+IWw1xyT0WIX b6QqcfIkj/yzx27R4KC7mRKoLQbPb4sVOM0uHboeoXs3Arguzq09fyIG0hu+XYGTa10sc38Z d3fut8UY908MEh0XZrhFvRv72baK9K0bBhIpzBXxJAeE2mcaBw8EM48tHWxzYUNTEUAMPs6l QwVOrVh+PfDOyo4FUxL5IxXDdYzDIHAGq99N4Wl6bosTI1c6Nz0atshD6iGI6M8O/ZeFRkb5 Anb8RCMMGg0M1RD0qYz04Zz5krOxzlm6IWOHCqG0IPiczdjDOvfQIAob+uAqjX2UkBMa3qPq bx0jiLBkcQe8e8S2rb/4b9RdEQ3/KuoicTTRtwJ7O/qxOwsZxhQCBXheWisUezQFIaEqQsG5 Jmo9LgW3ndYZt7tZsvJ7AvrKsB794/fJvcNlm0rOChp1x79HgVkbJdIZbM67SXNWcBL+qcLO 22bLF6AS7C8TEhknnzbdL5wRNPfMydTX7j11B7l7NxDVP8kIuqYfSDkakiNqYrI7aIw9xM5Q qBEo75rqCCyDvRoRpJz7EQB+uoHvS8mGGpdANmhoQD1oqV3aHtBwH5wbOpxGqy079hsMJj72 Cx7JY+53v+8QYkiYtxpJ+o1mkjJriiPfC8hHyREncOoDMuZ2jZIqZ1tgcuTbDCCski1SkEiZ QQ4tzXk4gNEId0sFy2NTxrL1RxgcAovxGSzd+tzI+jsL7uSD6VoUeFbLXgey+bCsufV3Lmgq yFfIkwMuaGfIwwA5cpLIPmJFYvJKXnKEyJbIwMjeQLoH8WyKvxEc5CQfd+jIMmLYyNm8kpfq yCTL1WzJkwOyCMvVbEXLIQeSV33KkMrkySt5VMrOytbKeAEcJaEc9sg4wW7BLB0uyTgb13Vv C0HyRc86VrcoRFkJd+T+gkn5/z4KUP9+8uk2epfyulkOUOItMu8weOdeCQj3DPQFGtp7GxUn M/A7eQv7B3itdXwbMmBkAn8HCdqiyAk+Pf9rgqzO7itvtugJPnOdv9lEahRis70EWlYR/TWj VvDA1LBaVg8EPT8IuTHoQhnKd4cMEe1r7QFDkHsVBnI41RfappNQBR/sCvCIGbN9ybdrDDN+ EdtWJL5hko9GckNuFur/4cFhZco6I+HxuV4gWyviHNVcmAnk8iLiDwQ579YCBu9XCY/+D2vm C1a+JJQyEDLyNd8NmqpHAgVgxl4zyaIhDccjG9lKWHWFBS1OTfbHt9XE9o9QeApO/o2xhVHU sJwVCpx7EEb9nO1vtyWe8wy3CAcb/5zxtwwD0nTN9iucc+oh8gIc8QCiMElvGMtqhh4GbhLf SlTBqtTA1EJ7XkExym6Ay/ZmmgVqkOR8LLoUC5hlW2fUClLP0u5j3+4v8Jx5tyb7BEr7t0k+ Ynatq7s9LrH5/kAkcAVU8Nur7VYeVJxLIDYDGrqmMwuS3BQaTgcYtn31a0yN2xfXHgJCfKvt ezYoo4bXWBICRoh1Ji6boDpinBEDPrMJ29YK+6l5AuRFrdU2c092/Y0TDWIRGnODEwlIudHC bTNLdWTuMAdc9gOxb1KbRg728i1vdnrqDgPmdBLwF2Luet9Wxh4GH16ZoFC2jEuYBJt++gU6 uR7CyKBa2ZI2jFhXAvMXiKC5bBuym+82+AVsqhqtnA2vF7Zz25vFYpf/nwMS/9MNk+4dBoJS 5QUT7rNNgqgLGWov1pLPdw4JFQvWIlpIwkG2JaQ3N9Yl3LlvDOhHEnkQ9hPvZhICgruEFrcd jSXqCUeay1L7+EhW7vCfSy2+BTbN5DTaj1LPu/NS9uZD1LJeEhTR4gShkQ7iXuJsN0g1Jltl X79hhP/RD1eh1p/u+/t5+9R/yUbmu+oi2FHq0AsE3I7+nx3Qj4RO82MG+YT2Et1KNs880AIY +oNfsvE0YyAOO+zFKMVS5OvWEcgSNqofcGbj+lTm2dV0BnjL3EfIjJYb9anAIx7piARbEa6H 3lka7kEMCxRgvmBnEuI7FSHts+mybSj//FIg+CCcPTZra8smcdFDmiS7mVZ8hm8x/WRoI7Aw ePKrzyvTM9NiuHrA6OLjkvhjvl0HdzccehJcOJLLVykY9Ko/Uz9iCtmS1HxJbdEbJalnUY3R CfXaM2TmsIo/llKpYx3ksD6owtF0k/E7or3TRZDvOfVNsvyzFB89SMgbcSmxKWx/BpzFOQmt kkLx+jcHIZ8Lweo6BtImwemj38kPy4vUWP1zHtIy1NPSx25QqeW5IIzTFelx3VL/xyISQ3GC 7vmC6qnp02Zgeie/k9KtunnTlXvZddNNCQ2Xkib/JB8SB55V6v/pMywS330f9pINDaovtY8m CsZzQhjAXcLfAg1yAAtf3dKHnA0hnnGR0rHe+DGsnZz/tcj2uEDPWrYTz6pTKxrEVrgG75MR TXNcqeS46u7eIUwfqO0uY+8RBcgSFRvqElUJvakvhHi2/93yaN2bMqmXuJX7kJ4SDh3wdYzb /45jLV7wLfv1oQk3p5HLQnw0X9IR0BwkMGMQeMAa3cdni9EyYRmSymMkcyAH9jIStQy4z/wJ jjkHTJEKge1ZkmPPNNi3ngSaJlYwBznsJbh4Y2BaqXuetkcOGxoOryaQ/FSPi4wc5tOhxBZN 2QifeRYSPge2gB6UkpFBuhdazhKW5NtkcsQaEnPdDJniHMiKmZct2Za8DBIS4Bn3NN9es0v6 kCMMHhL13J461ocaV9BfHEoSJgi3PeBS6UTDaBI3Y2PcF68cj6oTZxI05yzdO2s3DhdBLVqe t+mSnN0TlZLPoX8uvDENOizu/xzI9XghlMDPsfoPDx+qiIcxNbYYt7uJ36MKJkP7ekbAPbgK JpWTEvZOup8Hwd/H/+ZyCQ7NRjlhB1GKvtP8Jrz3E7OKTe7yAISznbsTZW6RiOAus3eTR5rf Hi4Ieu6I7eTs8pKpwQoRnha0NkjXvOwOt9rg9iLnkG1zzxHhENLF3iGcs/CkwKaj0Xw/1MNO kt7T6JKmIqLnPsNgFeqoBxwdJd4J29gKBx4I3vY0BzJGHxs3PN67OQIqNuQIN4IRVkJVHnw2 N1FyGi/9GPsc4yxkxjYmIqopHm4qHi6TnS0MIjTZE/sQDfGNx8k6EfmROYF3S4ePrO8EHXEK QcCsgbwQormdQ9k5CPE5s97CqZjA39lDiPPpw6CmHjnuBtsc7xE+DMpeklb3w+DmukHYFpih pFztfhVq2WFZZhgmjBneYbDZK+3h/vuogzoHD3v2sg7o3h3MVLsUqGQ2H7cy27/7ziKlJEsT /gR7gvvXj4rTtW79no7zunqCJo8Kq2/7jX323B6WLEcSO9nWlO6HpQ/wj+1u2YuSAWIfvsve 1zRiwSqGYbUg+gM2csBAoNjcI9F2r2QjkCcTsLresrlzJBu32B18AljcdX/7OZIq/ZoFGREc Ofdz4cDJ+pJ+gvoF/XjZ7msYugX6EKTZiY/hSxQihw+ym3b2eC8Wdgb+cfTiFFH2bTE+cc8k Cd8M5nuZ2zkorgAR6DIN1EOobzn6jQ4ElNl4Y9p/CD4CdcnGOM0Y+45UdQUjEs8KJIk4fbgW 2+Y12HeQYaD4AZisWlq3evzc4J5t6pLudEQOvnsBsX17P0uM/UMGLXExGctFq9W/X7Dnen2B 2OSE5NEiDnWydRLoGar25ui32y3/jvgyEUZmfyH1bjpsWwRpEe6vIWfiO4AL8tyln1W+XeLk 38pQ7sISj/hJ+yL1ks1dIl5IVigAO/DBvzolYeV32OGORl9iDh/yHw1lvkNZK4jB/6sfLmxC AZ0oGiTukPC4VyzNN4mYf70A7B1mvjG6eP41eB71m2/2GnN6hwTaj/G+A+0apyHVENeOoKlZ 9LoNegUCMtuES678huCk2/SvmiOXLhdBZgqyGgqCWxmA+M23twie4AZsA47/hxHlDvDvS9AC BhQR3xH1piv2zspGB0PuzkRV0Mx2di7aWfIKOXGw1hDqC+V2bH8JSHIhJaD8cYz+fD4LFrAA Kwjcptj9mjtNQZ9sX+VWAQUt0sPuKSERnGum2imARIdsha5MDYi87NmpsoPqJSjX2u634aY/ 0Gtx74J5ewAOL4npI95xpI5GrHlG5Fn8qxLwM7CwoatA8cjxJXi0hF6vQZKmvkRoAxrxKeWs KEKfYuMLuv7+mO60dUUGy95UnZEtlgFpb/J6pJ7ENOQ0z/4s8pL0Vt8TDTgnp+k+h9ZVs+oK Ae7shrI3Uk22bh/PuhnqusKh03EWaaz8rnsnF8JN5VUHS5VkoEQfoWkTrUUjhFACJyRaUwU6 F6V5Ijf2WECyjD6IFg9l6/TvEtTQ7HmRBv0nfRA9QJZLRZnkNirIBoteh//n2beD3Rbq5DFa LCdVQcj+1s39cv2Sad4RDiZlyTmxgxShW+ODSa6qrTQFz4NsuYeWAvA+bG48y5bp3H+EmgaF XPJUeAhmM1qEZ5znaMSzPspmrRJ6+3UOUmlS/2t3AZLMV25CAfkgtuM1B6TYWG27G0d17s+O bYzzCPGI/xNEPFP6GWSwWAtYZ1husSQHCRomW0wEjWBuQh8gFBzdbB13BcH/8hmOXZp6x2BF 6LDN/g3BIcvdbncNnwySwVUaE/RCNs4JQ/7HLgfrMKsVxCQ8/zwR2f////+elZTdjtqfjJ+U 2o6Ig9rA19OH8RTzc50x7lxyH6pPTP////8fVntmh5m6yhdKMbyvgvTG5UDeAVbwoEFa26+0 UN9ahv////+cT94VRUojtWLDt1un1/7kSYUuDyVQxK1/NQ7NaZXTX/8N/v/BpUCD7TMhtvox NaR7FEpMb4nKFslJH5b/////F39Xz8Py0NLL1udnn+g8nsCvX+vEkOsTIWQq7sBDCfb4//+l 5hbpVOm59bLplvjkovQ+8dELDX1QIzX///+lnHXpLrw5e/xwKx8pekPpgxgrypEmGmG8bxL/ //+/lMNDr6Katk7jW3SecH9StUEWOSRkbN38v9Hf6OsHKuNzyZNDbystOS55kf//f6GSnJAt VINXIjp4Ja5Pc+u0wwbevewEOBr//y3+jBZmNUXBrs8hYFxMA/JuQJ7Cn8XevKO1/////1yx rnxuGmvfAiIYHqZosvcbHydQS2l2aPTNFeGRMNDg/////wMkZ2U8ppWk1HbsvBxDwjLE8GxS zmrrQfKz6HIdVV+gv8H//2nUFS6onGg1J065HThwRT542A0UKNogxf////85PWOvinAGguTz XRMAt67wlCxvhlNJqEKBZao9hXSYtP/////pYdFGaXrsdfixTeA2CWp0PzrXW+KQ1obFrLM9 kQk8W/////+XF9HkdergvVjZzi3FGYHUxHd74F6mPjSQuH9Php2+lf//jf/e9acp6sZX94t+ ukKabp/5BwyWq8fVpU/DOP//G/01pQM77DMsyJxcVPOArio+mLtrOalhZKT/2///sMAIxH4T vXDV9lYySEPyV6LshjCFITpFSZ2eLf////+axR5qgkP9/SfWB8XAQUSDK7x8GVw65mI0ZGRR +TKvaP//1v8yT91nMvkemxpWfWic7v2DipG5MjVPeuvMyP+X/v+2pa5M9/1z/4E9G+lm1/PM H9jNxj9qAxq2ov////87MfJButxb4PwhP1kfuN/lHbfBlzNu5++aGyoWNuYAwcHb//9SH40d BcBx0+6xUb0uVlGqckNKecuT////vxHxLWcvhipmTr2ipYyGt1hguHdFtWMOFUcZKNEUr+r/ //9RVaQkHfxYsu+7BtAV99mas6lMZbSKBqY5Mzv//y/Qg6UrVQItmxfazYHgNcw+UZ+JOglS agcj+HIDL/X5fe7gB0VufTagZs3jZnlHB8t8H9NuE9mFruMlCTgGDqWkXfUDD3akBf9YABKQ JliYANNm+9dcAXwj0Q39Fxjyvdn5+t8jIhAGESp3/UtsCnfyesS5j+B6hKLunHkawRaAhH73 RTJ73xeGhsjyDZ6QUxnM3qbqBfd7k6Ms4gg8krL4ApniN+KDFe8CEFPvIly6usgPbhSVj+8x v+Itz5qAhE0m0nE2twzsE3rq+1n2ilniA4ccIxvx4haqFUfi2PbdAS3fDvjN3W/UMgyvnDu3 DPIKAvv6Agpmk4LykS0cwANFjU3i1vwGbyKwLUrUBqJxJdEgesth/wtm1I/7sXOnCquoNvsK bUjBIKPcH7A/i2YRPaN/M49CMJvk2QWFFPUU+B2QQgZkFPt3n6WW84yGQ89pfDerwAmYQUfi i/awuPQd+rdOIBHZsIszQ09HBowm7YI3OVbtGyAWkTh7s7VTavZ8m24Wi+5MFzpbETGEPsJ8 PE3s+GokfmN0PA4ylhpzIK6+YAOWwQZWeYCxR7R2EZc3QLFBtpN/0Z73VsNuG6sLyT3sEvAZ 2wmyzahTqLUQGCIMMyrC/DYUb8fKVlJH5t7FYVasR9HRht35CtqsqO6L3LvFpBHa8B/+lj9t C/8L6+r5AqMZ+QYJXvFQPVBtQ6hLpXE8iWzUHlLvBj/qPJIeawWv+coP85TBQ0SiLXGiIUmH wQj/sAj9onR+nO9nDvl3oOatPODj7CMFBcJ5vp0Xxe8UBrM422aYdKl4NscG0LT8qy/d/PIE +A28+PVSifVNpMXTrlCclgKsC7B6tBV3UwpXx2v7ltuTwxqVqhvUqlfjnEJhrNFXoH8j/IMe f2Sy7RHTEJwn/JygnMGvCECulWpfEwUZTz50187IorGPSt9t7nXu4kA6FbL1Bl+J0tkqYdb2 CPtysYvTecfBSBIckowVHMaeMYhzvohfpBagzwzfB8WyupMzRyCiSA7IjwnktNYikPno6mS8 Ja75iCwC3iFgVLIPjx+yggibG9X3iIO0GYtwNumHkcND43hCF5ZK17AJP8/4ESzgK/n1aXef Obt1XAgZ76yizMfIyEMX3oXKUH/4LCp7PPz5AvGxMawSte64+RLOKV0DYThmFJT7C1DiE3U/ /0JCBqxKGuntNfO9xAo1ihVyOciAvdNDgtlo+3TB8zwvBM+FjDy5xWYfJXRADEIc6TLIyQsa C7Vo5HOPXcYS9pI3OJSxGbIBucBuUXTnJScHB/q6EPqSkxzk8pIkA+gS6JNnh+S4xgvmUfrJ pznJFAdi+hdd6Fkv5MgXBegDCpg/Nn6+PlXJz86bp7wbL5oVOB9KApoxa4EYhzBMwYz79hMc GwqYU+iH3BE1W4Z8Jwdn6pqpVqhBDSnKhrDupF95Dy7knesvHw+1MVnFcT3YqR5zsXoCXe26 vpzo9wzE6cblupBKBoWUgfv4vbkcv/tN50nM1nUYpKne6hNfnR47lgvq0gPqrB/6S7AB7cAr c+AR/atx3VLwl2Kj8qNz46LEqiUpsUI4NnP55KuY1ypa8O51uf6FFFpGABONa0U73+25F+4p WZdKWD3/xwUACRJud5C7QfAERb8NRaptbbpVhwZRIAjeFKDSED+JtP1/PwM8QxI3nbH+8TOO mwXLdZZl2Xbsi/4FAvYO8sIM5u6EqxLHIy6UE05E2ckXv5uJfzYMVPwGj/m1hRH/1/BOGOpb 7wdr9wep+BtsEfFD0BTx9XV0KyyLmoz/vpbsr2UmzKTf8Ijw6Pc1G7Ub/t8Q/+ZyEa+GWeEa VqJfu6/iSgigqIB3uWaAhdaFv1Cc6EMqBhg4ecEDjqx7BtxdWbqNI/SQ+XkFjxcddvUxCvv/ 7b+ZcSS0tEv7B8FNiM5WxsqI/sbDjN7Guwdv3Gi+oIzmxpuAk8bUb8aljrZwC/j2xteO8vLx 8Ez9OEPAUPy5cDIRPbOHEciufU0GTEuJyQSsK83w/EoySeJG8UJ+0b/yW4bzAD0wrKBg8lsk OPJa1Ff1sP/jyZqicwksjVH/MBMi8gRL+mGA4UETmHPc/Px2+NYKAqkC9XlZ5x57hw7q3TMs RB1B9F57LzFxDN4GBsi6j4SjNgTiP3g4N/XqrTLRMXsD4b3wH0+keQP/jKMJCXdHbsPewm1i Vuz9UDg1LRgIAa34Jt7xKI7DqBsm21r3xZFdoK4y3BLzsSt9gjytqGkI2SKQ+4M1QfAaBa/q pBOuFTSnSliYRPvJkZOHGPag3PcBeU7IuDr21uohHs+u9+hgXjr53JZ7/HYVVoIvN4qbDTyW A5Jy6QaLSm4sx6puE1z/jwo8wK1FxsaqgQIRrVn0U/0GhDiYAdV/JTuBYhGjFo874XXfM5AS Eg/wWKqZq8yAaL/YbBMN8ep6wqFP193vgPteEQo02gzwIuiX5FqVrnitkhIH3+wTPnK2JUUz YabZNNAE6GDhQPZH+03YY7tx8fq1KiPo9riwBbct7MtF9y0ke4HIb6j25/exor66ytmvYRiw SpVAL6WQCMfiMgLE+xA38absAuC+KahbW9dhOMgGYOzRlgL1yvGLeOkxZMUaPP798bWXCrx3 qNacclGTnHsFFX/muwaYqCwJG+gN+MwIFsgQ3KZnqwvuJ/n2upI+YjyI9tcIrhvs0W5GNqIe Ssz8YsQ8Or+2BRSA24pHpZ+ZKHOfoIMVZPB8f5AZDxR1T+Z4IAQHpcR+j5Kyh+s18MZoM4oj uaPx3TaB8KSDKRxI8LagYYfQrDZvOduO3BEOEq8PnXrE3ubrgNwGi88NfPwK3shtbnFGBfJc YrwRJdEzqvlSpaQF3gWFseryDSr08B4bANfe9MoSZxMK8xIe8xcV5pDLvu9MIwby+14dkAx8 8MFWqjv/gR8bcQsNImNDxscDfyiH+A0rGp7bIKhB/GQbdfDqHbZt/HqHG8rvPBHRSsHcgt6B +kp4q1IzcfmONXPpCkYzu0rIBZo46SW9UvDNaEqow2pC8CahOPr+XHAw4utk2hIN83rWwEEN WRbmb4wC5fgz6Og1xhPgo0EprA5NHaKFWs4BMo148VHNHyQc8E6oAa503noxsaH42Q3iER8S ktlYuuc0v7tlWmKnOZLOD91YcjnS7I4EXx8ZXoIlXjzdkaehkilaP1eiuc/3jK3CH7ISYQWe 5/lKDgRLRj0oOMZj8B6Gktq0NaXyged7vZlGDasKfll3Y0BVIw1CNlZMwo3D+NMSjwXwqj41 8qK5p7YqLl1Sn4wzgzWzCmbvDHUnsjMGb/9RtfZ32dizcx39TpJrMIZSWNcyinMDqZqGIMR6 TP0Ecmh/a6JcVBfyBNqO+b0RCQi7p+1w5TwiqFrbSHLlhlCBZ9DzlhHJwwR6gaH9A7HHYIc6 HJL19awTjHoxGoynOWkLztwPGL16+tJYlHtngG8jf7rrumt5qvVMOkkVoHL48aMNi3HDwfXy IB5NjIzNu7rSS5Tvd0djh/bN9fjwr+tubgTKiMON/9IR3B4mg14WuGVtZsYFzPsOzaf+Y/y6 tmR2GvGdkQGExkSL+4Qw9QaBFMoSLTMrpUdk5NqoQ1pDuiNLsZiwPA3ukGdkkKG01PALNuvm xQVPsucw4bZ6D+9PlzhPhX4G2OThwyYSfvxcAjnO0swwAl88lEvkbFbPKqX8mTixC9jTIZKV FNcdEbojeBYcce8jeTj8rMERNFSpbKi6bFgXMQER5BW22YKbKakOvl0kkJIB+W2ShGA2/4R2 NhhSK4JbbqORDRtPB2w5ycNeIOvqZYn/2AI77NL5/+sTsrOZLUWeBZoYYpD9xcySlloTmKF+ 0ZoMz4pjBjwvOSyMVhz+5kaGkoMo/qaimeRhSVG9Wm4WQgYZ9noe7MxQz74/JilACmCekWe6 VcZe5UaZWl0WyyZcMMp9UfD5Fs9BvAUZEyRXXbp1INyQnU+E3s9l5ntaB2Qj+GsLO8ghboD+ YrtLZ61RAmMi7JJbiZLp+Tq2cATtPjYiDkOjfJ7n9E+GBTmPcpGlXA9Xjmsb2V4rGhAWW94I lpFlZF/hU+hXq8RZRvNLJRjiUjioOS6YYjjwfm32gwxJOhLfVZhEtFN/EgzuAb7Wlhs7oArS DWtwZntS8w4Iy+9swPkLhbkOd4cSQ/I+HICzTB6eHxqqe5B7gurqUxKvkYux3oifiq6eaopM E1WYK4ZRHfX5BCHSJNKINnAt96P7UdpPoQ4jsNlt4wsEqSDyJ63/4NnBFnstzYo2GZ/tlqXQ cAAADQoBSW4gf7D//2EgZGlmZmljdWx0IHdvcmxkFW5hbWVsZb/dXPtzcyB0aQgTHGFuIXRv IHN1/m9/93J2aXYSU28sIHlvdRhpbGwgYmUgbWlut/bb7xUtLSBCYWc5IEF1dGhPIjI5Ybdv 7i4wNAIJR2VybUR5Ln1v/7fvagAB6I5AkKNsmUAAaA84BP81BN/tGt9wQBQhigU2bAQWsZBq ZNr+/3cHQW7r8cnDVYvsV/91CF/rCEf2CIDtbv+XswU7fQx181/JwghCa09HABD7IN+PQUAo aJOoDnCBBXFQHm7t/2UAAOmV/u//zP8l7GAPBShhGRkZeSQgHBgZGRkZFBAMCPIcGRkEAPxg +DIyMjL08OjkMjIyMuCcVFgyMjIyXGBkaDIyMjJscHR4OTYyMnyAhL+IYJ7P5/OMYJBglGCY YCz5fD5HoGCkYKhgrGDIyMjzsGC0uLzIyMjIwMTIzMnIyMjQ1NjcfD6f32GJcGFsYWhhZGHI 2OT5qGGkBZzIyMjItJSQjMjIyMiYsLisyMjIyLw4NEDhyMjIRFBITGHZZGRk5HiEfIAyMjLC lxQQCOQ7YTIM2WAFIGRkZGQkKCwwZGRkZDQ4PEBhZmRkREhMAAIkVEEimqmi+h3D/vbfPhAE jE/Lw8/UAcvPzNTI+gBt////qbW8rq27qL+mrpOXn/qeiIyenpaW1J+CC6bZ//+BDLWvrqq1 qa7Uv6K/+rS3u7O0Cf7/3/61qK61tKUNrr+otL+upam/ua+lydTKpc7Kzd++bc8gqrwKpWCl w8KlJKW3v6Vrt23YyLEYDKkvtL05EPnPbgeotUW5rgypubK/vsnIdmtnP66svrcJrKgYy8wM tfb/NrE4s7XXraiq187Iy9dICr257oOUsbO2tky5Xl+ur6q3mTu2L8sXtr4VCRy7tifkD3Ov DLG+ta20yMp9LDZrABBCCrm2v7sj/D+2pbkLu6yKiJWOn5mOw4IeudjCWfu3vai+sx4otxPK peRk7Ta558OiTQy0rg/7NpusBmy4y8LLC66+z27t2a23pLO5vnmqtKW+vwuDtYW8pa78DKqO oy8b1mYKUgepvqhCYVZwK9iNGVOfObZyv5+yAb+iq68cWMAKTBglrL+d3ZJnqr4Xohaus6yz qC3Yh/Cvqde5Ory7qQgXsDArtL9ydgxErTicNYLMHhGqnFkLttAGsLsioAeSsM3aqWJpz7WE 5MDe/hXPycpbuKO4EK1g24Mlo724t+GvCmXdYI2ig73cvgnWyhG2Wr3esruFBIZ9CY06LLKu th0rNE7Ytr96u+F5CnZ4WwA1qK+cNMPkZO+7voIMtK79QrJDsAm/I8x2MgoDs8tgs6qfjC1M tjGoIKlqsDMUZq3VE8iCBGHGbFgNDOcDw0yldrazC19EEBuTlrmq2RAiGdcuaUlLIMkhOrbt 2e1IuIi9yAmpy6LbDsYZlL7+vL0moAoLVioEC5IzDFuWhPavvojHohtpoR3GK7ScSK3S2w5b DruiCanhuAstCZMNILkgCouQbGtDIs5evxlGw8k6viK/tXWzb5tbghtzVAxAvB7D3LC1CycK 6unr37ASDqqjsq/J141CsJZsyBRJv5qvbJeE/Quvt/y2r5sO4bW5hiSsvXuprKzdnmYMPte7 tbAID9iwSCleDQha4S07qrPZDvK1DWHJzfUMxb667jKGdRy1Cf27YdmSNezPz78YQi6s2DfY liK2DL22wwwDz3A9qaO0zga+pUrXQWpNvLMuvLizjK1u2TAJ7g2q4C2BwmUJv+88ljUN1hKp CLaDvgrhg8HYzr96tYe080ArLzmttK2nw2gOgk6CjlJs1gsGkyp7Ess4MJezFaqtwG6Qbwq0 s6KxrCeio9FmtYcyv7irlr37n6z9fsipwwMPsaXNzKXLzsnMEWWDPQ6zcgy+6GCHB7YMvAmz jQ/ZN1hYHMsdy82lyg+s1jSwO5epKIWaDfYUy7yQvIhlbpJo8a58qljXW5g9tge9zwxYrhcs c8sOteMLIjUOFEy5xqN1McHkgm5CuloLuAc3+omDidoXdrlEsKZgIau1qrYstfZgomhGL6zK FElv2BtXC13l0DgYtHemrb1LLkbhIBGtsqiPuYbkTLO3gv+B04ywrdEKhOC/LJkYQnMie1U4 q7UlnAeoEgt+4o6H9VkKqbi9k62jsEwY3BpUp7GptqK5g1QwZO8qoLu/hQYRhgmgfrTLOrVg EA2O32nZLGawHwkVImVx2QvJQiQSGMgyvnArCAVKk6SyMDZpEFq/TqvPGMOFgHSrlhGswitt bRg0pBXzPr4EhvWGtAy/uDawLgaoB68KLkKNZR2oW52j2LYQhDvzrCS0iVaBRivDfkdnZiqU CKjwWQsRZrN3uJYKQlk2gQmLpTClARpnr0JrQuxHEbyDmRqzuQfoF5Cpkgy8YGaKwPWtIGff E7Q3t8dwuBmzswiMB04SDtbNoDqiCanJEGZswVpLZIm8Snu0ZAfkXxXt0hWI9GTPo7dq8HVL 1oJuCUiTqbEkBeybLQuvCpAy2GCN2wa7B7cvK3VrHsjXPAu0rrbQ7CHXyQmFsYGbLVBg90S4 CXcmHVhX57QLordb8uws/a5+qLALdTNIloeWKqodKFSYYs1An9wSao0MrA0HDBjWgjl2Cswh qy1r5G/1C0rGyJasMBljC7wPXj8I97e+8GVmak9Ilqy0top8DGjBnGk8CwwLGjmCtb4JDy9y zHLBC7fvk6xVKjkaVNVTMhqsiRZzoqgLsjBgg0UWDLOOqRbDuiRjCrUJCsSykW/fqb8Mx+wF zK0Nxw6lKwizW75BwsMMEscPpmEUkRuDokazVhZNW0mwJjVWzaeA3tkaI7BHszocXVkskka3 kIBceLP5CjS9ySk3a62nQQhIKxgGJg63kzkcjVlbULxkwRkPzQ4N1pMjqXic4sNawQwIcwyv ysnCQ6hVAtL2wsq0OOmCwKNdrqmgMzEE/gy3yMx4+A/b/8hWfbf6ko6OisDV1Y0A1AN74f+J ipOfnZ+W1J6f1SOKkoobE9i//Zafk4qAkx2I15efiYmfI5dg/wX2lZiTlhqUn5yViJebW8hP YF+bjJJPnZWfjpKBtd8WE52Ij4OOjqz7h7AykqKbj46ViZmVBa21BHbIzh9U3DsT2N23mUDX mJWOB5ucjieYhG8L7JeYnBiSlpOUmwYrXGghTwOUlEJbK2uFQg1tA1xrJ7D/qYqbmZ+Zlo+Y P5yIHQ629iFs17yWlYyfPiKeRbuFEDOVlJXW9g0hvI+Sk5FUj/OWovDuBcKePJnXHpSTjoC2 0T6Ad5uYm5E4Q45/sMIJ5JSbn5dZd6G9wC6Nb5OcFY1tO4RwnZRomZGGiZH+C6xtz45ZWIqI k9eNldfyU8IbdZiPiJ0UjJOIjo/aLYTxgJWUz+mJjwSMCS8QiY/X6u4tgbULm3AYqtJ2gW20 llGNGI4Gu22NECob11OOk6ntbQhpiV6AHpGVlwbUcAxhdZnKeKXCLoTbDteIaRVGW2CNiHqa 5jyBFRbYmZygcjZlC21M7ZcakKWBNdzGk/2M06zKNmE7YXiIzNfhKi2sBPeXgpLZvdCCwhCC K0bUNNf1UjtlpmwcyY7qJVbWFtqV0WyZVjiwLZQaCI5DMZ4/loUDCK2pQBLIjw0LhG1rlxyd zIz/AJieCrCo1ycCo1Bqmm259zfHBPKcnZFWNJ+UMjRGCIt7XQjrkcJg6vsIIYxCDx7cViq0 Qg93Ar3KCu4RlZkeRlMuS6XbhIieW7mViI/ThxZAFNnXlbhcILU2q5WxfJFcxwYJJkePlB9X 1goXCJ2TZgrznoC1tY6T99SjxolbGjhTKUlTidIIIZUFj5Iap1YrUL6IW0U9CyEMGrZu6Y8o XGAbCpOjlnVjhLSZM2Ode2sp2QyulCHV55cN10rgl5KM7LialWDoTEj+iAQdtNq2xYkVwvWM s9qBAdYKHyO342GiiZKIJonYbMPElWiOySyDNyhRagEVmiNGCMtQcvls7wjpwvaA15EllpmP kptmWiBxnpnwlHKwwJa2YY7ymCDV9NGOqNeKe1zXZZ+W2xqFF3aNN1+mBRKNG//3jG2BtZ5k 2JuUC0IIC8czPU1cgyTajvtcVbBZtw2znGaXniOl0lbgLWYhGZTMEwbaBJygPIo1NRyFuwJk b4mFUmmQdABLtGwbwkzNJNdmnYej0EoppUORpkIjhITU4hFbYCa+h5YPRetCYqFpgMuJGI9m tuSisW+WJ4zHBU6FBe6njV8g4Ao9KLeZk5nEBJKhjB9hlWi2MITEkF2b46W2vEBun4KOcin+ S7Za6qaD+t+JxYrH32i8tYWl3PcGifq7TrbRZlrW+jGk1RmKCW4HWwoknAmQir76nZxtXdtG ijHfliq9C6nGVrIfaY+KDkeOfNpvY+yNlA+9SbM8v5R7CWypGeQcVp8Y3VihYxS2lfUVvOyp +VgDB+IHF6mbjJ8GnrUerpW8NEC+k1O5Am6ziRbKt6CcBSYKswP4YML+sgiHB062N9v6ANjb 5Rcjqr+2+z0XO2oy95v9f/oa+vTb8fv/9vr8WADq6wSz7826A9oOCxv+Hm627GQH+sozBigZ Szaw6gcGDO7sfCOsxqAC2gCJRfYqiuo3NX3BvpZm6/+QrPi2LdeUehpSc5kQ0jslnE0j/ke4 +gCaGocoppl64pjZYOArpJVaC6rq7pInLybqkuoAD2Y5ZZNyA2rqZECebZpWPirqHxDqw0HH L+P6uZadsqCvfxQcrcgNy2q8u/qexpKDjvv8rfckicXSty62GJkfgxb6Q/itgbVG7rMk+in4 zsgzKkED0BexTrYsbdtSe3P62WCfCL/nmTZ7hCtnTewcvsD/Cliah/b7j7xq6XjjU2SSGrfq EmGzkgHP3tkOYscK3/rfJKBP8uJq5RSSYVG9ufcpCxKN+l+CnqSqUckharlREJJNvM76iDZE PdpE4FdoZhPRMVSorNrZ+vcDxPMGEvP6pFAF34plRkZGNgWOgoZ6HIBhRnLn+v///4Pay9DL 1cvAy7XLrstAyzrLPMs2yyjLIsv6OwoVZQAG2px5bAlMOEfWCI6CjqVtg22dBpRCnwiKSNjb e7WSBesbCZP38Azt6yV+2sfa2K+Jpcg62Bef5Ia1qTNJGre1mJBVaulNpdLYqZmgikxnJ3gy paSpsxvYDebcstM5ejlD1Oqyz51Brm0z0oOuClgwZ7Y1ozGfe93nHSq0FdK4JN6bwBIlbgab x6Prg2w3U66EEmjGx8rUlTTWmWv3DXfUQdLLXPcvK4jSm9KT09MnlHAfXbCzWJVPgAYHudu2 rQSRs7xRqKue3uTsvZ2My9YPTg/I2QYzcLuKWiHJN5mCq6sWNOKfkEq0nCtHiV4V58gILSI4 3U2V7/A6LBWJz0Aq3rI7ai9/lNrSSBmLFu7DKouPk8y4YrW/bG/WBAOWxrKut7bEFYE36LwH v7u+47a/xGB/s90H2q+KnnPG1RUmrrvAv1UPwLuqOq7H2rO+x9hYiwbsq9jaErRoE2wFloAB vnwKlF77sEJbDamuo0cS3tuaKwgUMaoyEAbQvdYMPwkUtTn9Zy7goq6LGLe7orO3s6AMNOxW VK6uLEAatMDIE8y1Mka9t4sguLt3EuRo9he1cMq0ub8TFXOXtU1brJOBFQLXSngNPjpbCToH nSuXgQOAJdr+bbvV+Km5qLOs2kE7Y7dQtr0erLjQ2B2Q/kG6t4O8DIucltSMmIkK9wZIeryp tQauNTvJmI2M/mb8Cqk9difUjbJ2wcJu7Tbq3NqmiZacRsbWBlLWyhSRQoOkEDbYLexCWRtk 5udQCmGDsANKrBG2yhg5LdiyQlgbQiARNrBCVyIKYSGsbC5ZrFD2gUmWzQgbZAOAGxwhbEHW 1UysMgJY6l6EBEIJAAGWEEhhVBd1gUAKWy8tbZc0sCKZtMWSGi7kzO8SvL5TrYbNYtSRZSAN TqCVkiJnwalZ7mFDKdSoq0mggGkhZMrSLXvNKvB5iIaQph+FCDzEjakbA9Ih8IK10yAWK9K+ EIjA1eP3+vu51minpV3dbj7u5G3VoP2Tn42fiAg2p5O1RmvNoxNX0caOEQuNIz/6v/bp24Nv 7WTht5NmcJWcjqYp2la0B6a5jyIJrEVqVq4hl6bCSW0m6MZT1JX6swSAWpm3t5361xOSjpt5 mOQpjFzAY7qz1hqGjhaUTj4xiv9GBbqrz7CY+Pn+//z98tKCqVJgx4ff5TCXrLki8Q1xDTkH YR6ViJ2vBrf9wlaXtryotbfAxhrEFxrWwMC53ksOwz64pdC7Biu6l+2u3h6l+vz7lpzXiUEY uURr024k+o/6FqI5WE+D6RtIiSsUytEF8gbnK/QGuZZ+He2e15mK1uAaDBvkigXsbahm7gWO noMHPAelQmGRgh9we2agNln6dIlgACLbFiy0e6f6q4JjiYrmbtCe+iGPggVd0MagZt9waJku G+Rau3eSlbRcBLybVNulaIAi15shugfHl8C28JabmPo2iWvNGW6VlZ3eDavNHN1aM3CXiix/ wlL6imutba0711abvwuUGpq7bVsQnTC6R4rUrFLWgkbbKYN8LfSmGNrW3JXmooiXvaZc3cI3 tab60NTQ3Y1p1KKbdZwX8ZeJnQCJBQTNmHn7gpeWHp6YggSen1zeNn8TlJmSl5w8lZ6JmZxc O8TBGHkEIbFfwRV2ISdemJhUu/bBdU6WKzDUj881nZNtbuxzRBiecpBAyJIahifD573atZwx 47Rg2gqiyZ2ukSxGw7ZqrduR49u4KbX3IbQRoqrWCwa54ieHL43asZ+DEzbMpew1Xy0mNa3Q DmwtqhlPERTKrbWJCwQKm5Z4aKVXLlXamQqWSBVdl12329sq2jefaJ0MtP6b01hli3iHjnuJ aCW8bTK0kx0HMo6Rg6xVMQqeOtgXttDaWUWKmA4MkhjDYq2JSoIAOuUZHfGoqQhc2t05OGai 6iG7kg8rYFtr71dBzTKwS4XcdraV3ZJZ6YKbXKxiaw0lke2Cou2s2w7CMY3DogDa7CnK5h1c iBuJR8GW3Ti7ftrMKRHRhAnuz9qqbDA+6LbNgpaPfJhHqpKgra0ZDwQtw7CPGiy0E2i3IxiC lGWqhQ54jEuPOthuTa0+pDGS4I+YD44KDWLm7ER2Uqh9O9Y7DPqeAN3W3doFxq3m1mUA2oPa Q7LAj9g2ttLAPgnfKpMDyA5c3dZbCr6EwFk/zGrQtpUH2AgvPQGXMFOBEG70LXXS2Sy3htc7 wNioUeweIMuT11aOWhA8FYxX1rpvLV4C166DimWX1bDt1uqiKdUbpJ7BH1aoVrDaAD8EGJoL ttGDktcAdx5G9oa5vA8RT4bGpodG1ReWwWmO0Wo0E2w/HyYAAWu0UJMdLHjFBi3KifXXalJZ 4ebAOc2YOF4G2qHWEVeAVHjs7SB7j1GYdZ/MziIitFixnWULdFRrFGNOoWXBJiywGItVS1Fg KvsUxJubTtYaX6sDuF7V1RgXhC070IktsbBgbxASlfoEnuDPfW0DEdQZA8aYiO/Bh/d+CZ3E xh4R2WuxEsYJBhbkaKWt0sY+UImoXcRgJ1y0nsASxECq7Nihy8tznooM2tcJDWOzNxYNAKgS ty6+CbSJSNINsoRq7NKxlQmjm1OV2wquAWssNf95g2wOQYfZblTA0w2/Tdoxq8aCXh6+GQN7 mTC4hPgdW3LIZBS3v4yDQ8PeEBxc2O4gxFqZBrf6uX49XA1eOYsuwVaoQukNpQYwamq1ZE+8 m4JEds8tFlTo6p4BbQmjlbllkWsV2h6dNZrBEXupGhylCMNlIv8OjA37lnSKMp7sANpzdTY7 mwUQ1H4E7mcDV7Hik4yCngRDG1aYk3YqtrRaLLpy2ldtcuCCbHSRiU6JZdghbA+YkxCKwoqz hlvWcNSNnxcjGdQGsEFrigYLsENdDonwcCEAdhlH12y6BbZsgzOviaQ0OnhkgDc1l5kpm7AP mNRFu5iTLaNhj61fnITwAghLtiP3Sq4ds4gr+ZZCHJwCQp4eCMbknqHXohstGnMAO+zRN43C hsBlIRE2G7vrM34iC4QtLFjSA5jUZoJiDww1cb7Hk1IpihyQjKXiDqnrltTd3zH6/KU3MROH DTa33xyhsHBI46MxpRwhXFloYKVOjVSlM5TcW5SyuZyltv/SBRhwHceOF4xTbWux+fpPE4kh FZrqTliDX7uWLKVenlwl3K5OsJUpfByDaG6mAl+JpZScNUzdnH9mj5yAAW0ErZ16mwfFj5Nr jtzXHZ4RiETvrMVs37OYDmupl1Ozhp9MMDR8hKUPpese1jLVWiTd3iyCNlhwjoKMC4xNk7tt MYtAipCBjq4+c2CYrJQhiSAX5HJzb0RIu5mW1R6Pityhtk2sGI8XJDKMXcwVUrk+aI6pvF+1 ihBDF/2Wp1rAYGio72hEwRy5qfReObXaIoWkN5JwqG2xyqd3WrQCH2yD+I6qJ5c2t4+igq0D 8W8Brr+0o7GpvnFWG7UYzbuJvNNoyan/HbRGSBTr+t2+3Yjdld2K7/6FdgGf3Sqp3ZHdg920 C47d+qVNs/3215W1m0mG19Gp0QORg7T929I0n46GZbG1ldel+qEx4lLOT4imgKcdP2twtImD akWXabCRlqnN0jVTl1IA18SvP2OvmcYKEWmnqdeR3PkW+teD17TXUI5dodCqkeGO9az6oNKL gKOw1IXtuYGuUoPAbz76w6Kyju76GGpDW0hxig+m2rzVhNY2U40HCFw91hjM+geuJ1Kzuatg o1vWtvpDDb42sIdtbK1qKciV+kGpJRehq4xpib7gDt1SA1czM4qDQ6o1R80AWgeMVGSOCrBZ tNyai2EsSb1luyX6Ec8RODqJyEaDCjAKvtqE+nMBWYyKXCIACUUCCyWJA/+Xy6k0AVRQAUdl dE1vZHVsZdgWAMtGaU6DQRNYC4D/UHJvY0FkZHKQD//st/9TeXN0ZW1EaRBjdG9yeSRUaWNr Q2/s2xbsdW50DTxGG21hdEEPY23sn1pvbmVJbmYVaQsXV23/hP1pbmRvd3NLbG9iYWxBbAZj 979thwxGHWULTG9hZExpYnJhJs9iyboNYyULJE1huzX3/nBWaWV3T2bCDsxrQnmu71v7dlRv amRlQ2g8FE9wZW7Ta9vBYs8IMzIwctYPzdruAU5leA5SZXRKIYDdza1nZ2lpRHKCa1v3dlN0 BW5nc4lTGEXFcbXdzw0NCEF0H2J1eHWt/YIhE1BvMRCAU9ohgrsLZXAGRxqdbdu29x8JFVQh bSdhGeEX9mSiVW5t1VdhaXRd5gxvrlOADk9iajsU3+0vWQtL9BRuRXge4Xa2dDJyZT1sdXJj mMse9tkJbXBpCnB5CS72WrBuCjEJ/Pow22ZnokfPf3oM4QsfjxBUeXAvQ5FzZUhhEA8M915q G8kJQ3XYwQqFcqgG3ElkFNe6zwISb21tRUzAVQR7B8dGJ5B2Dpt7AzuvD3hy7mn4D9tlR0NV YftvbGhlbHBusl9Y01NXcHNob3QZaAYbtuGwZA1NrnhBDVqXMEPHTXBkEwzaQrLCbx8KP2Eb mmztEr5SaEtz5m6nWVpBCBZnRBkUzOHewlZEdTgQFg1s9mRvRXQgS2V5DnJmc2/ZDt8NVE6Y o52dICFC8B8NyW5Nb5BfYkpEQ7bZmx1KbX1fFgnhYzuMOUZZb+RssI1tgjtJUIMmdu8Ys1lr UVwOL8+4dsPcbAg+xkJrN9vWDGf8VKWDUXKnWN9MSTY0UTEGbU9uSNtah0nUOw5qaQrhaTZH R9ViAFOrNFvDo2y1QkFFbkD22BvuP99ySUEJRHVwCNnGYG4CElSFbQn1p+ncUic5elhVUkxE ppvkumVubEBpHIVoNm2dYH1wyXRmTR07LOw0YWdQb5D/c2ttGWZtlXCkNXp3lRpP7t4caFUb qhxPT9NJkHhJ3W667GvZkgIUdEEOjICVLlVcEfM2Q9twbm5SZWTDL1mcubbuaYxpH1+8ZDtB QKOxnnTA+FWYncwhDGJ5Dkh56WvAUFhjgHMDa2V0v8pbbmK9cmFjYyVTQYHXHHdccnR1MCMZ eTb7Zq52MnoUbAc++S/HYM1QRUwBBADMD5BAnjT/D+AADwELAQUMAERWSFD7DAcC31gNQAtu Fmw5AgQzBwzAztyS0B40EAezvCTeBk/QYdxdIJDLwKADp8T7mq6wAR4uw3TrQpB3F/YF6wQj IB4ucmR0g+0Kr6NGC/sMJ0jZYt2FQAIuJkd1bUqa7nAnOlTATwYbbIFzggDrwHOOwL/fyicb cGQNIcYAAAAAAAAAACAB/wAAYL4loEAAjb7bb///V4PN/+sQkJCQkJCQigZGiAdHAdt1B4se g+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJg+gDcg3B4AiKBkaD 8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2xHJAdtz73UJ ix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPCBIkHg8cE g+kEd/EBz+lM////Xon3uQcAAACKB0cs6DwBd/eAPwB18osHil8EZsHoCMHAEIbEKfiA6+gB 8IkHg8cFidji2Y2+AMAAAIsHCcB0PItfBI2EMKTjAAAB81CDxwj/loDkAACVigdHCMB03In5 V0jyrlX/loTkAAAJwHQHiQODwwTr4f+WiOQAAGHpBGz//wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAAAAAA AAAAAAAAAAABAAAAAABQAAAApPAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAA eAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAkAAAAJDzAAAUAAAAAAAAAAAAAACgwAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAA gACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3dwAAAAAAAAAAAAeIiIiIiIcAAAAAAAAA AAAHOIgzOIg3AAAAAAAAAAAAB7ODAAODhwAAAAAAAAAAAAf/MP+wOIcAAAAAAAAAAAAHuA+/ /wOHAAAAAAAAAAAAB4C//7/wNwAAAAAAAAAAAAcP/7//vwMAAAAAAAAAAAAH/7//v/+wAAAA AAAAAAAAB3d3d3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP////////////////////////////////////////////////// /////////////////////////////////////////////4AB//+AAf//gAH//4AB//+AAf// gAH//4AB//+AAf//gAH//4AB//+AAf//////////////////iMMAAAAAAQABACAgEAABAAQA 6AIAAAEAAAAAAAAAAAAAAAAA2PQAAID0AAAAAAAAAAAAAAAAAADl9AAAkPQAAAAAAAAAAAAA AAAAAPL0AACY9AAAAAAAAAAAAAAAAAAA/PQAAKD0AAAAAAAAAAAAAAAAAAAG9QAAqPQAAAAA AAAAAAAAAAAAABL1AACw9AAAAAAAAAAAAAAAAAAAHvUAALj0AAAAAAAAAAAAAAAAAAAp9QAA wPQAAAAAAAAAAAAAAAAAADT1AADI9AAAAAAAAAAAAAAAAAAAQPUAAND0AAAAAAAAAAAAAAAA AAAAAAAAAAAAAEz1AABa9QAAavUAAAAAAAB49QAAAAAAAIb1AAAAAAAAkPUAAAAAAACe9QAA AAAAAK71AAAAAAAAuPUAAAAAAADM9QAAAAAAANj1AAAAAAAA6PUAAAAAAABLRVJORUwzMi5E TEwAYWR2YXBpMzIuZGxsAGdkaTMyLmRsbABvbGUzMi5kbGwAU0hFTEwzMi5kbGwAc2hsd2Fw aS5kbGwAdXJsbW9uLmRsbAB1c2VyMzIuZGxsAHdpbmluZXQuZGxsAHdzb2NrMzIuZGxsAAAA TG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtl eQAAAERlbGV0ZURDAABDb0luaXRpYWxpemUAAFNoZWxsRXhlY3V0ZUEAAABTdHJEdXBBAAAA VVJMRG93bmxvYWRUb0ZpbGVBAAB3c3ByaW50ZkEAAABJbnRlcm5ldE9wZW5BAAAAYmluZAAA AAAAAAAAAAAAAAAAAAAAABXFBQV3h1aZFETCewdDvn0DOHdtmRUsd5jChjOhuh0ExahXS3Qw NZcMNcdEMppif2IPw7xxK5/Ec8SwfiC/mqtgUBFKEECkFIU9fBiRA4KjMi82jbhQXiGlRLws gDwwvJYYlF4GW3mWCIGKZjVNM6+hcBWrtREpcjleKbQxx1LFGpxHurmwTilcpT0aNKQTDrIR vgYzHH4GB65DfKgPrTK5U34xFKs+c5iWcny+wAOCvLQNfD6qUn+QKBMHtMSLni5FjUJGA1kl XsW+wG0eO3Aln1cZGQ6scI4Uez+sdKS+xG0lL32qsV2jk3CjE1CexkmRTQcjmYcEHXOdnTi3 oyQWYDw1H4k/AGFcmgpgi3kapXcvULd6DiMNmzCbEGKeMENPXWXFqJJaDMYdDVGhHqpKE0MK V4F4V4JblEKfKbp+n3s3lUg7lEaYsGHAamR7KGUIcqhHS5E2uVcDEHiIAxxhQ3O2JSVUIVuJ YXpzTXB9cpIcAzR/Or4UXqmXZGgzX2dYXR5Gng9HaQ8dlKyhX4UVtkRGoHoHNME6AK1sYHWa nXN1vIAStDxRMlRRHCFixUxAak8gIIYxl1dOLMOqUSlsm41aWC6HC1cWVmmummNdJU56gDWA nU8pIKZxjJyxhQFpDZYvnkJvdScTOiqxqY6pICqCBm7BxcCmsJwIw7iVvXxCOnYgmmivD1ER nw4svnuuXlJMdsIGTXRqpUh3o2UBjTEUfEUPlYkQZx6KPsKKOqCFMkW4FRGPF4l3j5+SBxCY jWyVarWIE7sLZFwycAgEt3lxibG+ShB1HGOFpIw1P2AcHYweWJUMhAEmVByDMFIDm8UGZqkD v7EoaME+MbEvW0qsBrgKNatoDx9+OypSUAWfqol7xGdswT9leQFwsi5gbm2LTBCKf5EyWjpe oDw/Fmt7Mk2awAMyv2xIukaAHmukt3JKLKC/xGw+b3ajaIR4Q61LWY4fSCMpQn55C8QOhjtZ tbQ+NbAuYXUXdwl4lAdlCSW+rQprb2wUUwN7c1W1jiWTKa2UbXi1G0SNgX5meq+SDQk/Jxxo fbG5uauFmoKlqnsZlmQHfLRtoZukeI5SarsNNXpIoI8JYFaJqC0WRrXFYWqEhbtfLx5MaDyJ TS9PliR5YC6xLi4uAFAUgo8Sd2k4d72sMlOFHJN4siAju7ZHW7slPAxoY5BxDBkLMUIhIlcS dlYMHoo5vx+HDjAkdWC7Zyh4NqF5vzs5ZD5wBWl3esRxh2AGpLbAiZA6D6iRH4jCfAaTTwsA B5WRFBUDkKlYfpl0NbuBSzkPPBIPhq9pjjOuwm8L ----------asctdpibvfppkdayqcba-- From owner-v6ops@ops.ietf.org Thu May 6 17:36: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 RAA21002 for ; Thu, 6 May 2004 17:36:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLqVC-000GHR-LO for v6ops-data@psg.com; Thu, 06 May 2004 21:33:58 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLqVA-000GGo-Hn for v6ops@ops.ietf.org; Thu, 06 May 2004 21:33:56 +0000 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 i46LXs6b004371 for ; Thu, 6 May 2004 14:33:55 -0700 (PDT) Received: from blixten (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 i46LXmQ18634; Thu, 6 May 2004 23:33:49 +0200 (MEST) Date: Thu, 6 May 2004 14:33:52 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Tunnel Set-up requirements: Issue to be resolved To: Alain Durand Cc: "'''IPv6 Operations ' ' '" In-Reply-To: "Your message with ID" <182893D0-9E33-11D8-B5C6-00039376A6AA@sun.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-v6ops@ops.ietf.org Precedence: bulk > The original draft talked about two modes, authenticated and non > authenticated. > This was not a perfect terminology, and we now use registered vs non > registered. Question: in the non-registered mode is there an ability to have a mechanism by which the same host gets the same IPv6 address each time it sets up a tunnel? > - The registered part of the protocol SHOULD not be too different from > the non registered one, > so as to minimize code difference between the two modes Are we assuming that the registration is done as part of the protocol itself, or are we assuming that the registration is external to the protocol? In the latter case you can the ISP that supports registered tunnels can have a web site where the user types in the credentials it uses with the ISP (userid? contract number? whatever) and as a result gets some registration key/tag which will be used in the actual tunnel setup protocol. Erik From owner-v6ops@ops.ietf.org Thu May 6 17:49: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 RAA21646 for ; Thu, 6 May 2004 17:49:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLqjv-000KEw-OB for v6ops-data@psg.com; Thu, 06 May 2004 21:49:11 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLqju-000KEZ-NF for v6ops@ops.ietf.org; Thu, 06 May 2004 21:49:10 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i46LnAdc000686 for ; Thu, 6 May 2004 15:49:10 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HXB0015QB9X1J@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 06 May 2004 15:49:10 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HXB00FCGB9W46@mail.sun.net> for v6ops@ops.ietf.org; Thu, 06 May 2004 15:49:09 -0600 (MDT) Date: Thu, 06 May 2004 14:49:06 -0700 From: Alain Durand Subject: Re: Tunnel Set-up requirements: Issue to be resolved In-reply-to: To: Erik Nordmark Cc: "'''IPv6 Operations ' ' '" Message-id: <32901C5A-9FA7-11D8-94CC-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On May 6, 2004, at 2:33 PM, Erik Nordmark wrote: >> The original draft talked about two modes, authenticated and non >> authenticated. >> This was not a perfect terminology, and we now use registered vs non >> registered. > > Question: in the non-registered mode is there an ability to have a > mechanism > by which the same host gets the same IPv6 address each time it sets up > a tunnel? Not today. Do you want to require such a mechanism? >> - The registered part of the protocol SHOULD not be too different >> from >> the non registered one, >> so as to minimize code difference between the two modes > > Are we assuming that the registration is done as part of the protocol > itself, or are we assuming that the registration is external to the > protocol? unspecified at this time. > In the latter case you can the ISP that supports registered tunnels can > have a web site where the user types in the credentials it uses > with the ISP (userid? contract number? whatever) > and as a result gets some registration key/tag which will be used > in the actual tunnel setup protocol. That is definitively one way of doing it. This could be a way to unify the two modes: if you are unregistered, you provide an empty key and the system could (if desired by the ISP) allocate you one so you would be able to retrieve the same address next time by presenting that key. In the registered mode, you provide the key that was pre-assigned to you. Question: are we not already in solution space? - Alain. From owner-v6ops@ops.ietf.org Thu May 6 18:51: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 SAA25287 for ; Thu, 6 May 2004 18:51:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLrhF-00094I-5j for v6ops-data@psg.com; Thu, 06 May 2004 22:50:29 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLrhE-00093N-3P for v6ops@ops.ietf.org; Thu, 06 May 2004 22:50:28 +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 i46MoQ4U003907 for ; Thu, 6 May 2004 16:50:27 -0600 (MDT) Received: from blixten (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 i46MoIQ24514; Fri, 7 May 2004 00:50:19 +0200 (MEST) Date: Thu, 6 May 2004 15:50:22 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Tunnel Set-up requirements: Issue to be resolved To: Alain Durand Cc: Erik Nordmark , "'''IPv6 Operations ' ' '" In-Reply-To: "Your message with ID" <32901C5A-9FA7-11D8-94CC-00039376A6AA@sun.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-v6ops@ops.ietf.org Precedence: bulk > > Question: in the non-registered mode is there an ability to have a > > mechanism > > by which the same host gets the same IPv6 address each time it sets up > > a tunnel? > > Not today. Do you want to require such a mechanism? If we want the non-registered mode to be the default, I think it makes sense to make this mode provide realtively stable addresses. Thus having the protocol being able to, at the ISPs choice, provide stable addresses as well as prefix delegation makes sense to me. > Question: are we not already in solution space? Don't think so, but there isn't a hard boundary between requirements and solutions. The reason I was asking is because we are talking about requirements being placed on the protocol without having defined what the protocol does; whether the protocol includes the registration exchange or whether the protocol can operate based on a registration exchange done with some other mechanism. For example, if the protocols on which we are placing requirements includes the registration exchange, then I think we need to have requirements about how flexible the registration exchange needs to be since different ISPs might use different pieces of information and different existing mechanisms to identify their customers. Erik From owner-v6ops@ops.ietf.org Thu May 6 19:53: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 TAA28331 for ; Thu, 6 May 2004 19:53:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLseG-000Mca-U9 for v6ops-data@psg.com; Thu, 06 May 2004 23:51:28 +0000 Received: from [66.163.170.83] (helo=smtp813.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BLseF-000McF-NB for v6ops@ops.ietf.org; Thu, 06 May 2004 23:51:27 +0000 Received: from unknown (HELO VALUED847D7605) (carl?e?williams@sbcglobal.net@209.137.156.6 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 6 May 2004 23:23:09 -0000 Reply-To: From: "Carl Williams" To: Cc: Subject: Re: Tunnel Set-up requirements: Issue to be resolved Date: Thu, 6 May 2004 16:28:22 -0700 Organization: KDDI Labs USA Message-ID: <000001c433c1$d38e4e80$7e01a8c0@VALUED847D7605> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 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.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain, Some of the scenarios we are looking at require that we be able to keep the same IPv6 address for both registered and non-registered modes for each tunnel setup - this of course should be a choice. I don't know if this is more of an implementation issue or not but for registered mode I don't want to require the end customer to manually enter settings via some web page every time they initiate a new tunnel setup. For example, I want to require registration but in a way that is automatic and transparent to the user. Thank you for creating this requirements document and I hope that other service providers and/or mobile network operators can comment on the requirements as well. Original Message: ----------------- From: Alain Durand Alain.Durand@Sun.COM Date: Thu, 06 May 2004 14:49:06 -0700 To: Erik.Nordmark@Sun.COM, v6ops@ops.ietf.org Subject: Re: Tunnel Set-up requirements: Issue to be resolved On May 6, 2004, at 2:33 PM, Erik Nordmark wrote: >> The original draft talked about two modes, authenticated and non >> authenticated. >> This was not a perfect terminology, and we now use registered vs non >> registered. > > Question: in the non-registered mode is there an ability to have a > mechanism > by which the same host gets the same IPv6 address each time it sets up > a tunnel? Not today. Do you want to require such a mechanism? >> - The registered part of the protocol SHOULD not be too different >> from >> the non registered one, >> so as to minimize code difference between the two modes > > Are we assuming that the registration is done as part of the protocol > itself, or are we assuming that the registration is external to the > protocol? unspecified at this time. > In the latter case you can the ISP that supports registered tunnels can > have a web site where the user types in the credentials it uses > with the ISP (userid? contract number? whatever) > and as a result gets some registration key/tag which will be used > in the actual tunnel setup protocol. That is definitively one way of doing it. This could be a way to unify the two modes: if you are unregistered, you provide an empty key and the system could (if desired by the ISP) allocate you one so you would be able to retrieve the same address next time by presenting that key. In the registered mode, you provide the key that was pre-assigned to you. Question: are we not already in solution space? - Alain. From owner-v6ops@ops.ietf.org Fri May 7 00:25: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 AAA10127 for ; Fri, 7 May 2004 00:25:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLwtc-0005Ku-F6 for v6ops-data@psg.com; Fri, 07 May 2004 04:23:36 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLsBJ-000Gqt-In for v6ops@ops.ietf.org; Thu, 06 May 2004 23:21:33 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i46NLP023187; Thu, 6 May 2004 16:21:25 -0700 X-mProtect: <200405062321> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd4Jjo9G; Thu, 06 May 2004 16:21:22 PDT Message-Id: <4.3.2.7.2.20040506161500.00b579f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 May 2004 16:19:18 -0700 To: Pekka Savola From: Bob Hinden Subject: Re: POLL: Consensus for moving forward with Teredo? Cc: v6ops@ops.ietf.org In-Reply-To: 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-v6ops@ops.ietf.org Precedence: bulk Pekka, > a) Go forward with Teredo, hone the deployment implications in the > unmanaged analysis in parallel (if and as appropriate), My preference is for a). I agree with the reasons you and others specified. Suggest publishing the current draft real soon now and plan on revising it in a year or two after there is more implementation and operational experience. Bob From owner-v6ops@ops.ietf.org Fri May 7 00:25: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 AAA10162 for ; Fri, 7 May 2004 00:25:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLwuI-0005Xq-Np for v6ops-data@psg.com; Fri, 07 May 2004 04:24:18 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLwuH-0005Xd-SC for v6ops@ops.ietf.org; Fri, 07 May 2004 04:24:17 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i474OHdc022487 for ; Thu, 6 May 2004 22:24:17 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HXB0010ATKG1J@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 06 May 2004 22:24:17 -0600 (MDT) Received: from [192.168.1.102] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HXB0024JTKFVP@mail.sun.net> for v6ops@ops.ietf.org; Thu, 06 May 2004 22:24:16 -0600 (MDT) Date: Thu, 06 May 2004 21:24:18 -0700 From: Alain Durand Subject: Re: Tunnel Set-up requirements: Issue to be resolved In-reply-to: <000001c433c1$d38e4e80$7e01a8c0@VALUED847D7605> To: carlw@kddilabs.com Cc: v6ops@ops.ietf.org Message-id: <67EB459F-9FDE-11D8-88FD-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <000001c433c1$d38e4e80$7e01a8c0@VALUED847D7605> 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Thank you Carl, this is exactly the kind of feedback I'm looking for. On May 6, 2004, at 4:28 PM, Carl Williams wrote: > Some of the scenarios we are looking at require that > we be able to keep the same IPv6 address for both registered > and non-registered modes for each tunnel setup - this of course > should be a choice. > > I don't know if this is more of an implementation issue or not > but for registered mode I don't want to require the end customer to > manually enter settings via some web page every time > they initiate a new tunnel setup. For example, I want to require > registration but in a way that is automatic and transparent to the > user. Would a one time registration through a web page be ok? There could be some kind of token/key exchange happening there and that would be reuse automatically every time the user sets up the tunnel. - Alain. From owner-v6ops@ops.ietf.org Fri May 7 00:41: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 AAA10584 for ; Fri, 7 May 2004 00:41:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLxAu-000A8D-2s for v6ops-data@psg.com; Fri, 07 May 2004 04:41:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLxAs-000A7P-Lw for v6ops@ops.ietf.org; Fri, 07 May 2004 04:41:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i474fMu26115; Fri, 7 May 2004 07:41:22 +0300 Date: Fri, 7 May 2004 07:41:22 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Erik Nordmark , "'''IPv6 Operations ' ' '" Subject: Re: Tunnel Set-up requirements: Issue to be resolved In-Reply-To: <32901C5A-9FA7-11D8-94CC-00039376A6AA@sun.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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 6 May 2004, Alain Durand wrote: > > In the latter case you can the ISP that supports registered tunnels can > > have a web site where the user types in the credentials it uses > > with the ISP (userid? contract number? whatever) > > and as a result gets some registration key/tag which will be used > > in the actual tunnel setup protocol. > > That is definitively one way of doing it. > > This could be a way to unify the two modes: if you are unregistered, > you provide an empty key and the system could (if desired by the > ISP) allocate you one so you would be able to retrieve the same > address next time by presenting that key. [this may partially be in solution space, but probably useful in any case as I think it makes us able to understand the scenarios/requirements better..] .. or the user could just generate some kind of hash himself. The trivial part of getting the same address/prefix is to base the v6 address/prefix on the v4 address/[port], so that if that does not change, your address is constant. That has a good side that if the ISP implements ingress filtering, you don't need v4 return routability for the signalling exchange. This could be the simplest model. An extension could be using some hash or pseudo-key as Alain mentioned; if both stored the key, stability might be possible even without explicit registration. You'll need to have v4 return routability check here though, adding at least one round-trip. It's worth considering what are the differences with this kind of non-registered pseudo-keys to normal AAA methods. I'd argue that the ISP is less reluctant to save these pseudo-keys: not wanting to store them in an external database. It might be that they are only stored in the memory of the tunnel server, or possibly in the stable storage of the tunnel server (as e.g. DHCP spec requires). If stable storage is not used, the sessions are lost at restart. Now, if we assume that stable storage would be recommended, there is actually very little difference except that the really registered users can be ensured to get a static address/prefix delegation, and possibly custom configuration based on the AAA databases. So, this seems to lead to a conclusion that a single common protocol would be sufficient as long as it may fill both the non-registered/registered requirements. -- 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-v6ops@ops.ietf.org Fri May 7 03:38: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 DAA02491 for ; Fri, 7 May 2004 03:38:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLzti-000GSX-1w for v6ops-data@psg.com; Fri, 07 May 2004 07:35:54 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLzte-000GRm-5v for v6ops@ops.ietf.org; Fri, 07 May 2004 07:35:50 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id E8EDF7FF0; Fri, 7 May 2004 09:35:44 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 11512-17; Fri, 7 May 2004 09:35:29 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id CCE207FDB; Fri, 7 May 2004 09:35:28 +0200 (CEST) Subject: Re: Tunnel Set-up requirements: Issue to be resolved From: Jeroen Massar To: Alain Durand Cc: carlw@kddilabs.com, v6ops@ops.ietf.org In-Reply-To: <67EB459F-9FDE-11D8-88FD-00039358A080@sun.com> References: <000001c433c1$d38e4e80$7e01a8c0@VALUED847D7605> <67EB459F-9FDE-11D8-88FD-00039358A080@sun.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0lcoPN2NPrqWr1uWJ46X" Organization: Unfix Message-Id: <1083915322.2409.21.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 07 May 2004 09:35:22 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-0lcoPN2NPrqWr1uWJ46X Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-05-07 at 06:24, Alain Durand wrote: > Thank you Carl, this is exactly the kind of feedback > I'm looking for. >=20 >=20 > On May 6, 2004, at 4:28 PM, Carl Williams wrote: > > Some of the scenarios we are looking at require that > > we be able to keep the same IPv6 address for both registered > > and non-registered modes for each tunnel setup - this of course > > should be a choice. > > > > I don't know if this is more of an implementation issue or not > > but for registered mode I don't want to require the end customer to > > manually enter settings via some web page every time > > they initiate a new tunnel setup. For example, I want to require > > registration but in a way that is automatic and transparent to the > > user. >=20 > Would a one time registration through a web page be ok? > There could be some kind of token/key exchange happening there > and that would be reuse automatically every time the user > sets up the tunnel. IMHO a protocol doing this MUST not rely on an external mechanism. The problem is very easy to solve: - user start tool(tm) - tool discovers the closest tunnel setup protocol (*) - tool connects to tunnel setup protocol - setup server notifies client that it can handle: * anonymous users * pre-registered users * allowing new registrations all optional depending on the ISP/server deployers wishes. A tunnel setup protocol MUST be able to do all three. Then the tool proceeds to either: [anonymous user] - user claims it wants to be anonymous and presents a 'cookie' if it has that from a previous session - setup server either validates the cookie and finds the old IPv6 prefix(es) the user was using or returns a new one. the client MUST be able handle to handle it and a server MAY return a new prefix - setup server returns prefix information, cookie, endpoint info, etc.... [registered user, aka one with an account] * the account can be obtained out-of-bound (website, phone, preexisting agreement or using below regmethod) - tool asks for possible authentication methods (MD5/SHA/whatever) - tool asks user for authentication tokens and sends to server - server authenticates user and: - setup server returns prefix information, endpoint info, etc.... [registered user, but no account yet] - tool tries asks the server how to register - server responds with either: * website + http://www.example.com/register/ - Tool either presents the user that it can register through a website and if it wants to do that. This site could also point to information how to do it in different ways. If the user answers yes to the question then the user is shown the url either by starting the webbrowser directly or just text. * direct [en|nl|de|...] (the languages supported) - Tool asks if the user wants to register using the tool when no, return to start. - Tool asks server for 'registration information' in 'en' or 'nl' or whatever depending on the language the user wants - Server returns "language not available" or: Your full name (first + last name) The address where you live ..... * but this is implementation* As registration through this protocol should be optional when it is implemented it SHOULD only use the 'website' method, the 'direct' method is quite complicated and basically also presents the same forms as the website.... (maybe better only do website?) (*) =3D I split "Tunnel Setup" & "Discovery" as the discovery should be done seperatly IMHO and could be as simple as DNS lookups but could also do more difficult tricks. The Discovery should only return a pointer to the Tunnel Setup Server. (and yes... all this is already possible using the configuration protocol in use by SixXS, waiting for this thing to settle ;) Greets, Jeroen --=-0lcoPN2NPrqWr1uWJ46X Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAmzw6KaooUjM+fCMRAgC7AKC0V7XaYlSFkLkNwB/vygWtYq+5GgCfYK0i +Q0kChRI6OzkkCcIHv9ZUVw= =ma87 -----END PGP SIGNATURE----- --=-0lcoPN2NPrqWr1uWJ46X-- From owner-v6ops@ops.ietf.org Fri May 7 12:57: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 MAA05426 for ; Fri, 7 May 2004 12:57:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BM8dU-0007Gg-0u for v6ops-data@psg.com; Fri, 07 May 2004 16:55:44 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BM8dS-0007Fv-31 for v6ops@ops.ietf.org; Fri, 07 May 2004 16:55:42 +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 i47Gtdms007147; Fri, 7 May 2004 09:55:39 -0700 (PDT) Received: from blixten (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 i47GtaQ14346; Fri, 7 May 2004 18:55:36 +0200 (MEST) Date: Fri, 7 May 2004 09:55:40 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Tunnel Set-up requirements: Issue to be resolved To: Jeroen Massar Cc: Alain Durand , carlw@kddilabs.com, v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <1083915322.2409.21.camel@segesta.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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > IMHO a protocol doing this MUST not rely on an external mechanism. But later you say that referring to a website for registration is ok. Perhaps we mean different things by "external mechanism". I think it is find to have the tunnel set-up return a "please register at www.example.com/register" as you suggest, and that is what I call "external". So I suspect we agree on this point. I don't know if the "direct" is that useful. You effectively end up carrying a subset of html when you do this; it is simpler just to refer to a URL. (And there might non-technical reasons for an ISP wanting a URL for registration; they can have banner ads for their ADSL service etc.) One question: For the [registered user, aka one with an account] you are describing something that looks like a full authentication exchange, which opens up the door to questions like "are we encapsulating EAP over the tunnel setup protocol? or SASL?". Do you see this strong authentication as a requirement? Or do you think it is sufficient to have the registration result in some "key/tag" where presenting that key/tag in the clear in the tunnel setup protocol is sufficient? Erik From owner-v6ops@ops.ietf.org Sat May 8 02:26: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 CAA12048 for ; Sat, 8 May 2004 02:26:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMLDh-000HMc-Ux for v6ops-data@psg.com; Sat, 08 May 2004 06:21:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMLDg-000HM9-GF for v6ops@ops.ietf.org; Sat, 08 May 2004 06:21:56 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i486Lt215911 for ; Sat, 8 May 2004 09:21:55 +0300 Date: Sat, 8 May 2004 09:21:55 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, When discussing draft-savola-v6ops-tunneling-01.txt with Dave Thaler, mainly about the necessity of 6over4 in the scenario where the IPv4 network is multicast-enabled but the v6 network is not, I came up with an idea which I'm not sure if others have brought up in the past: If you want to create point-to-multipoint tunnels over v4 multicast infrastructure, wouldn't the obvious solution be simply using configured tunneling? That is, you configure the tunnel destination v4 address to be a multicast address (this requires zero code changes), and the decapsulators configure their "local end" to be the multicast address (requires code change in the tunnel setup tool to permanently join the specified multicast address)? This would seem to act like a "statically mapped", simplified alternative to 6over4 which would only require an implementation-specific addition to join the multicast group. This is in line with RFC2893 and draft-ietf-v6ops-mech-v2-02.txt, as long as you interpret section 3.6 loosely enough: When an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 addresses, [...] (this wording could be tuned, obviously.) Thoughts? -- 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-v6ops@ops.ietf.org Sat May 8 09:44: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 JAA02528 for ; Sat, 8 May 2004 09:44:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMS4v-0004Vt-3i for v6ops-data@psg.com; Sat, 08 May 2004 13:41:21 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMS4t-0004VQ-Ek for v6ops@ops.ietf.org; Sat, 08 May 2004 13:41:19 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 3DE847FF0; Sat, 8 May 2004 15:41:14 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 19166-04; Sat, 8 May 2004 15:40:59 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 374307F67; Sat, 8 May 2004 15:40:58 +0200 (CEST) Subject: Re: Tunnel Set-up requirements: Issue to be resolved From: Jeroen Massar To: Erik Nordmark Cc: v6ops@ops.ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MVcOenBb26ibfXKI5zAO" Organization: Unfix Message-Id: <1084023648.2409.1169.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Sat, 08 May 2004 15:40:49 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-MVcOenBb26ibfXKI5zAO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-05-07 at 18:55, Erik Nordmark wrote: > > IMHO a protocol doing this MUST not rely on an external mechanism. >=20 > But later you say that referring to a website for registration is ok. > Perhaps we mean different things by "external mechanism". >=20 > I think it is find to have the tunnel set-up return a > "please register at www.example.com/register" as you suggest, > and that is what I call "external". >=20 > So I suspect we agree on this point. Correct. > I don't know if the "direct" is that useful. You effectively end > up carrying a subset of html when you do this; it is simpler just > to refer to a URL. > (And there might non-technical reasons for an ISP wanting a URL for > registration; they can have banner ads for their ADSL service etc.) Indeed, which is why I also noted that in the message. Most users are able to navigate through a 'register' type site. It is up to the ISP to make it doable and this also 'lightens' the burden on the tool as it doesn't need to be able to do checks of validity and other things which can then be handled in a webstyle method. > One question: > For the [registered user, aka one with an account] you are describing > something that looks like a full authentication exchange, which opens > up the door to questions like "are we encapsulating EAP over the tunnel > setup protocol? or SASL?". >=20 > Do you see this strong authentication as a requirement? > Or do you think it is sufficient to have the registration result in > some "key/tag" where presenting that key/tag in the clear in the tunnel s= etup > protocol is sufficient? I personally would be more inclined to require a somewhat more strong authentication, thus in the form of SASL at least that the key is not passed in cleartext and that a replay attack can be avoided. I guess that most people will not mind, but if someone has a good argument against doing that, please mention it of course. IMHO the best thing to go is require that a tunnel setup protocol is able to allow multiple styles of authentication and let the deployer pick. Thus that the server announces it's capabilities: - SSL/TLS negotiation so that the complete protocol is crypted (think starttls here just like in SMTP). - Several authentication methods: - cleartext (required) - md5/sha/sasl style (optional but recommended) Advertisements of capabilities should be done in order of strongest to the weakest version. Clients should then pick the first one which it can handle and use that. It would of course be easier to just define one single strong authenticator and a cleartext variant, which may be only available when using SSL/TLS for instance. Greets, Jeroen --=-MVcOenBb26ibfXKI5zAO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAnONgKaooUjM+fCMRAuMpAJ9UFXHS08cj0l6t9NlGiGoJPEnnEACfaj+v tQh8RqdhmvP0zs9EqYqcVe8= =PtVT -----END PGP SIGNATURE----- --=-MVcOenBb26ibfXKI5zAO-- From owner-v6ops@ops.ietf.org Sat May 8 16:06: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 QAA21771 for ; Sat, 8 May 2004 16:06:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMY3y-0008ZE-9W for v6ops-data@psg.com; Sat, 08 May 2004 20:04:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMY3w-0008Yg-TS for v6ops@ops.ietf.org; Sat, 08 May 2004 20:04:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i48K4h526933 for ; Sat, 8 May 2004 23:04:43 +0300 Date: Sat, 8 May 2004 23:04:43 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: SUMMARY: Consensus for moving forward with Teredo? 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) Thank you for participation. The chairs judge that there exists rough consensus in the WG for moving forward with Teredo (option a) below). However, let's continue to try the address (the best we can) the concerns raised by those participants with a different opinion. Pekka & Jonne (co-chair hat off) On Fri, 30 Apr 2004, Pekka Savola wrote: > (co-chair hat on) > > As identified in the scenarios analysis at IETF59 and in > draft-savola-v6ops-tunneling-01.txt, there appears to a need which > cannot be filled by another mechanism for Teredo at least in one major > Unmanaged scenario. > > Is there rough consensus to move forward with Teredo? (i.e., to adopt > it as WG document in this WG or elsewhere, for Proposed Standard.) > > The main issue raised has been to call for a more extensive analysis > for the deployment implications of native, 6to4, and Teredo. There is > already discussion of this in the Unmanaged Analysis document. There > seemed to be very little energy or interest in the WG to drive this > much further. > > The options regarrding Teredo at this stage seem to be: > > a) Go forward with Teredo, hone the deployment implications in the > unmanaged analysis in parallel (if and as appropriate), > > b) Conclude that there is no sufficiently strong need for Teredo, and > not support its advancement (for PS) at this stage, or > > c) Decide that we need to analyze the scenarios or deployment more > before being able to make a decision. > > If so, please state where you believe more analysis is needed.. > and volunteer if possible :) > > If you have an opinion, please state it within a week, i.e., by next > Friday, 7th May. > > Thanks! > > (co-chair hat off) From owner-v6ops@ops.ietf.org Sun May 9 04:09: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 EAA22376 for ; Sun, 9 May 2004 04:09:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMjJq-000GSO-HN for v6ops-data@psg.com; Sun, 09 May 2004 08:05:54 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMjJo-000GN5-Jn for v6ops@ops.ietf.org; Sun, 09 May 2004 08:05:52 +0000 Received: from d12nrmr1607 (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4984rS1012962; Sun, 9 May 2004 08:04:58 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607 (8.12.10/NCO/VER6.6) with ESMTP id i4984qAO036458; Sun, 9 May 2004 10:04:53 +0200 Received: from zurich.ibm.com (gsine09.us.sine.ibm.com [9.14.6.39]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id KAA51630; Sun, 9 May 2004 10:04:50 +0200 Message-ID: <409DE629.5030100@zurich.ibm.com> Date: Sun, 09 May 2004 10:04:57 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Maybe. But I was told by the people who implemented 6over4 a few years ago that it was only one page of code anyway - so I am not so sure about the simplification. Brian Pekka Savola wrote: > Hi, > > When discussing draft-savola-v6ops-tunneling-01.txt with Dave Thaler, > mainly about the necessity of 6over4 in the scenario where the IPv4 > network is multicast-enabled but the v6 network is not, I came up with > an idea which I'm not sure if others have brought up in the past: > > If you want to create point-to-multipoint tunnels over v4 multicast > infrastructure, wouldn't the obvious solution be simply using > configured tunneling? That is, you configure the tunnel destination > v4 address to be a multicast address (this requires zero code > changes), and the decapsulators configure their "local end" to be the > multicast address (requires code change in the tunnel setup tool to > permanently join the specified multicast address)? > > This would seem to act like a "statically mapped", simplified > alternative to 6over4 which would only require an > implementation-specific addition to join the multicast group. > > This is in line with RFC2893 and draft-ietf-v6ops-mech-v2-02.txt, as > long as you interpret section 3.6 loosely enough: > > When an IPv6/IPv4 host or a router receives an IPv4 datagram that is > addressed to one of its own IPv4 addresses, [...] > > (this wording could be tuned, obviously.) > > Thoughts? > From owner-v6ops@ops.ietf.org Sun May 9 05:14: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 FAA24466 for ; Sun, 9 May 2004 05:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMkNM-0005iG-9d for v6ops-data@psg.com; Sun, 09 May 2004 09:13:36 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMkNI-0005hi-I7 for v6ops@ops.ietf.org; Sun, 09 May 2004 09:13:32 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i499DTo8024285; Sun, 9 May 2004 11:13:29 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i499DSMX009981; Sun, 9 May 2004 11:13:28 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Sun, 9 May 2004 11:13:28 +0200 From: Stig Venaas To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) Message-ID: <20040509091328.GA9937@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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-v6ops@ops.ietf.org Precedence: bulk On Sat, May 08, 2004 at 09:21:55AM +0300, Pekka Savola wrote: [...] > If you want to create point-to-multipoint tunnels over v4 multicast > infrastructure, wouldn't the obvious solution be simply using > configured tunneling? That is, you configure the tunnel destination > v4 address to be a multicast address (this requires zero code > changes), and the decapsulators configure their "local end" to be the > multicast address (requires code change in the tunnel setup tool to > permanently join the specified multicast address)? > > This would seem to act like a "statically mapped", simplified > alternative to 6over4 which would only require an > implementation-specific addition to join the multicast group. Are you saying that all hosts that are to share a virtual link, will use the same tunnel? So that all communications between all these hosts will be sent to one single multicast group that they all join? I think 6over4 would do better, and it's not hard to implement either. Stig From owner-v6ops@ops.ietf.org Sun May 9 06:01: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 GAA26143 for ; Sun, 9 May 2004 06:01:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMl7V-000GwK-VW for v6ops-data@psg.com; Sun, 09 May 2004 10:01:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMl7U-000Gvq-5U for v6ops@ops.ietf.org; Sun, 09 May 2004 10:01:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i49A13211332; Sun, 9 May 2004 13:01:03 +0300 Date: Sun, 9 May 2004 13:01:03 +0300 (EEST) From: Pekka Savola To: Stig Venaas cc: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) In-Reply-To: <20040509091328.GA9937@sverresborg.uninett.no> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 9 May 2004, Stig Venaas wrote: > On Sat, May 08, 2004 at 09:21:55AM +0300, Pekka Savola wrote: > [...] > > If you want to create point-to-multipoint tunnels over v4 multicast > > infrastructure, wouldn't the obvious solution be simply using > > configured tunneling? That is, you configure the tunnel destination > > v4 address to be a multicast address (this requires zero code > > changes), and the decapsulators configure their "local end" to be the > > multicast address (requires code change in the tunnel setup tool to > > permanently join the specified multicast address)? > > > > This would seem to act like a "statically mapped", simplified > > alternative to 6over4 which would only require an > > implementation-specific addition to join the multicast group. > > Are you saying that all hosts that are to share a virtual link, will > use the same tunnel? So that all communications between all these > hosts will be sent to one single multicast group that they all join? No. Sorry -- I should have been clearer on the context of the idea. The strongest argument for 6over4 is in scenarios where you implement v4 multicast for specific applications, and you'd implement v6 multicast for the same apps if you could (but if support is not being provided by the vendors..). The argument against configured tunneling is that it requires quite a large load on the servers if the number of participants per group grow larger than about 5-10 (due to requiring unicast packet per receiver, instead of about one multicast packet). So, I was thinking that these "multicast tunnels" might be able to complement either (non-multicast) native IPv6 or tunneled (configured tunnel, ISATAP whatever -- anything except 6over4) IPv6. In other words, such "multicast tunnels" would be only used for very specific applications, one tunnel per (group of) applications, as a means to leverage existing v4 multicast infrastructure to obtain the benefit of no multicast->unicast conversion/duplication in the network. -- 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-v6ops@ops.ietf.org Mon May 10 04:39: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 EAA17480 for ; Mon, 10 May 2004 04:39:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BN6GA-0002Oa-1M for v6ops-data@psg.com; Mon, 10 May 2004 08:35:38 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BN6G8-0002OA-NT for v6ops@ops.ietf.org; Mon, 10 May 2004 08:35:36 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i4A8ZSo8025122; Mon, 10 May 2004 10:35:28 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i4A8ZRYc011740; Mon, 10 May 2004 10:35:27 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 10 May 2004 10:35:26 +0200 From: Stig Venaas To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) Message-ID: <20040510083526.GA11730@sverresborg.uninett.no> References: <20040509091328.GA9937@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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-v6ops@ops.ietf.org Precedence: bulk On Sun, May 09, 2004 at 01:01:03PM +0300, Pekka Savola wrote: [...] > In other words, such "multicast tunnels" would be only used for very > specific applications, one tunnel per (group of) applications, as a > means to leverage existing v4 multicast infrastructure to obtain the > benefit of no multicast->unicast conversion/duplication in the > network. Ah, I see. Yes, that's an interesting idea (: Stig From owner-v6ops@ops.ietf.org Tue May 11 00:58: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 AAA01522 for ; Tue, 11 May 2004 00:58:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNPIo-0008YZ-8V for v6ops-data@psg.com; Tue, 11 May 2004 04:55:38 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNPIm-0008YD-Kp for v6ops@ops.ietf.org; Tue, 11 May 2004 04:55:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4B4tZd14121; Tue, 11 May 2004 07:55:35 +0300 Date: Tue, 11 May 2004 07:55:35 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: dhcwg@ietf.org Subject: Review requested: draft-daniel-dhc-ipv6in4-opt-03.txt 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (co-chair hat on) DHC WG is considering whether to adopt draft-daniel-dhc-ipv6in4-opt-03.txt as their work item for signalling IPv6-in-IPv4 endpoint in DHCPv4. DHC WG has asked to get feedback whether this would be applicable in the IPv6 transition process. For a more generic look on the tunnel end-point discovery, please have a look at draft-palet-v6ops-tun-auto-disc-00.txt (feedback is welcome on that on v6ops list as well, but please use a separate thread). So, (1) please review the document and send feedback on v6ops list, or both v6ops and dhc lists. (2) please consider whether this would be applicable in the transition process and send feedback to v6ops list. In particular, please consider at least: a. which scenario(s) would this be applicable to? b. which mechanism(s) would this be applicable to? c. if multiple mechanisms, would it be needed to distinguish which mechanism's end-point this is applicable to? d. what more is needed to make this applicable as this only solves one part of the problem (i.e., how does the server end configure the tunnel, i.e., learn the client's IPv4 address?) e. whether we have yet enough knowledge of these issues to go forward and specifying the option, or whether we should work e.g., on the mechanisms first. Please send feedback within a week, by 17th May. (hat off) For what it's worth, my personal take is that this is work that may be worth doing, but it is still too early to take it as dhc WG item, because there are still too many unknowns on the field especially regarding: - which specific mechanisms this would be applicable to (2.c), and - we don't have all the pieces of the puzzle in order yet (2.d). From owner-v6ops@ops.ietf.org Tue May 11 11:00: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 LAA01902 for ; Tue, 11 May 2004 11:00:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNYhP-00077j-0H for v6ops-data@psg.com; Tue, 11 May 2004 14:57:39 +0000 Received: from [161.53.19.155] (helo=delboy.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BNYhK-00076e-M0 for v6ops@ops.ietf.org; Tue, 11 May 2004 14:57:34 +0000 Date: Tue, 11 May 2004 16:59:03 +0100 To: "V" From: "Jonne.Soininen" Subject: RE: Incoming Msg Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pzvjfjeawycgdcsnlugs" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_01,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------pzvjfjeawycgdcsnlugs Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------pzvjfjeawycgdcsnlugs Content-Type: application/octet-stream; name="text_document.com" Content-Disposition: attachment; filename="text_document.com" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAl4ogYKQfZjs4JJ54 jYK7GwZRsr0ePJ2IU5gWYWcRpcNxhJ48xaN8V503c3UoXLEVixgyxD5LHDQXjwgjxlWyS7yz cSOAGiRztX9LPSmNxxeHTXG/e64gX3OQOzqxYrtSJpDEHpqZpBesIA0xUm/EmyQONgNbsE1N PI9Qj0oaHr5mP4mqZWsNsSgNQDIVgpwquIONvZuEUR5mRAGPYAZ0KotIlkw7Oh8hmXnAOpR7 ny+Sh8F+EgaROxoogH46cFqJGmxlty01bzuBCcAYWW2CZ7FivWFhr39jPaaqJiFsk0ovY4VW LSGehnKxvCCDsLE8cFQgGS9MH10= ----------pzvjfjeawycgdcsnlugs-- From owner-v6ops@ops.ietf.org Tue May 11 13:39: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 NAA11225 for ; Tue, 11 May 2004 13:39:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNbCJ-000JVH-8M for v6ops-data@psg.com; Tue, 11 May 2004 17:37:43 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNbCC-000JTm-HT for v6ops@ops.ietf.org; Tue, 11 May 2004 17:37:36 +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 i4BHbVhs015743; Tue, 11 May 2004 11:37:32 -0600 (MDT) Received: from blixten (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 i4BHbTQ23763; Tue, 11 May 2004 19:37:30 +0200 (MEST) Date: Tue, 11 May 2004 10:37:34 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) To: Pekka Savola Cc: v6ops@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-v6ops@ops.ietf.org Precedence: bulk > If you want to create point-to-multipoint tunnels over v4 multicast > infrastructure, wouldn't the obvious solution be simply using > configured tunneling? That is, you configure the tunnel destination > v4 address to be a multicast address (this requires zero code > changes), and the decapsulators configure their "local end" to be the > multicast address (requires code change in the tunnel setup tool to > permanently join the specified multicast address)? This implies that all IPv6 (unicast and multicast) packets will be sent as IPv4 multicast, right? While that might significantly increase the use of IPv4 multicast, it might have negative implications on the performance of the network :-) Erik From owner-v6ops@ops.ietf.org Tue May 11 16:12: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 QAA22049 for ; Tue, 11 May 2004 16:12:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNdaM-000DJI-R6 for v6ops-data@psg.com; Tue, 11 May 2004 20:10:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNdaI-000DIY-9y for v6ops@ops.ietf.org; Tue, 11 May 2004 20:10:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4BKAYY28662; Tue, 11 May 2004 23:10:34 +0300 Date: Tue, 11 May 2004 23:10:34 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 11 May 2004, Erik Nordmark wrote: > > If you want to create point-to-multipoint tunnels over v4 multicast > > infrastructure, wouldn't the obvious solution be simply using > > configured tunneling? That is, you configure the tunnel destination > > v4 address to be a multicast address (this requires zero code > > changes), and the decapsulators configure their "local end" to be the > > multicast address (requires code change in the tunnel setup tool to > > permanently join the specified multicast address)? > > This implies that all IPv6 (unicast and multicast) packets will be sent > as IPv4 multicast, right? Not necessarily -- sorry for failing to say that explicitly in the first place (you guys couldn't read my mind yet?!?! :). See the note I wrote to Stig for clarification. > While that might significantly increase the use of IPv4 multicast, it might > have negative implications on the performance of the network :-) Yes, it could be a problem -- a bit in the same way as 6over4 (in this context) hass a problem. But luckily enough, this would probably apply only to v6 multicast of scope greater than link-local. -- 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-v6ops@ops.ietf.org Tue May 11 18:17: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 SAA01813 for ; Tue, 11 May 2004 18:17:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNfWY-000NlC-8G for v6ops-data@psg.com; Tue, 11 May 2004 22:14:54 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNfWX-000Nkq-9h for v6ops@ops.ietf.org; Tue, 11 May 2004 22:14:53 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4BMEik30431; Tue, 11 May 2004 15:14:44 -0700 X-mProtect: <200405112214> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRgL87O; Tue, 11 May 2004 15:14:41 PDT Message-ID: <40A15054.2060607@iprg.nokia.com> Date: Tue, 11 May 2004 15:14:44 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) References: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: >If you want to create point-to-multipoint tunnels over v4 multicast >infrastructure, wouldn't the obvious solution be simply using >configured tunneling? That is, you configure the tunnel destination >v4 address to be a multicast address (this requires zero code >changes), and the decapsulators configure their "local end" to be the >multicast address (requires code change in the tunnel setup tool to >permanently join the specified multicast address)? > As you know, the decapsulating end of a configured tunnel requires a specific IPv4 source address for the "remote end" of the tunnel, so the configured tunnels you describe would only be able to decapsulate multicasts from a single specific encapsulator. I.e., you would need one such configured tunnel for each potential encapsulator (which could be a large number). If you want a single tunnel interface that could decapsulate multicasts from *any* decapsulator, you would need something like 6over4 (or, ISATAP if the IPv6 multicast address is mapped to a unicast IPv4 link-layer address.) Your configured tunnels could still be used as decapsulator-specific "overlays" (if needed), but it seems like you would still need the 6over4/ISATAP for wildcard match on a large set of potential encapsulators. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue May 11 18:38: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 SAA03121 for ; Tue, 11 May 2004 18:38:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNfsP-0004aN-52 for v6ops-data@psg.com; Tue, 11 May 2004 22:37:29 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNfsO-0004Zw-Aw for v6ops@ops.ietf.org; Tue, 11 May 2004 22:37:28 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4BMbKa22087; Tue, 11 May 2004 15:37:20 -0700 X-mProtect: <200405112237> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQJ0oIo; Tue, 11 May 2004 15:37:15 PDT Message-ID: <40A1559E.8090107@iprg.nokia.com> Date: Tue, 11 May 2004 15:37:18 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) References: <40A15054.2060607@iprg.nokia.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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Whoops; I see a couple of typos to correct (below): Fred ftemplin@iprg.nokia.com Fred Templin wrote: > Pekka, > > Pekka Savola wrote: > >> If you want to create point-to-multipoint tunnels over v4 multicast >> infrastructure, wouldn't the obvious solution be simply using >> configured tunneling? That is, you configure the tunnel destination >> v4 address to be a multicast address (this requires zero code >> changes), and the decapsulators configure their "local end" to be the >> multicast address (requires code change in the tunnel setup tool to >> permanently join the specified multicast address)? >> > > As you know, the decapsulating end of a configured tunnel requires > a specific IPv4 source address for the "remote end" of the tunnel, so > the configured tunnels you describe would only be able to decapsulate > multicasts from a single specific encapsulator. I.e., you would need > one such configured tunnel for each potential encapsulator (which > could be a large number). > > If you want a single tunnel interface that could decapsulate multicasts > from *any* decapsulator, you would need something like 6over4 (or, s/decapsulator/encapsulator > ISATAP if the IPv6 multicast address is mapped to a unicast IPv4 > link-layer address.) Your configured tunnels could still be used as > decapsulator-specific "overlays" (if needed), but it seems like s/decapsulator-specific/encapsulator-specific > you would still need the 6over4/ISATAP for wildcard match > on a large set of potential encapsulators. > > Fred > ftemplin@iprg.nokia.com > From owner-v6ops@ops.ietf.org Tue May 11 21:48: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 VAA12865 for ; Tue, 11 May 2004 21:48:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNiov-000PX0-Jr for v6ops-data@psg.com; Wed, 12 May 2004 01:46:05 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNiou-000PWf-Nx for v6ops@ops.ietf.org; Wed, 12 May 2004 01:46:04 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4C1ichO019681; Tue, 11 May 2004 19:44:39 -0600 (MDT) Received: from blixten (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 i4C1jvQ28187; Wed, 12 May 2004 03:45:58 +0200 (MEST) Date: Tue, 11 May 2004 18:46:02 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) To: Pekka Savola Cc: Erik Nordmark , v6ops@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-v6ops@ops.ietf.org Precedence: bulk > Not necessarily -- sorry for failing to say that explicitly in the > first place (you guys couldn't read my mind yet?!?! :). See the note > I wrote to Stig for clarification. I didn't understand that note. > In other words, such "multicast tunnels" would be only used for very > specific applications, one tunnel per (group of) applications, as a > means to leverage existing v4 multicast infrastructure to obtain the > benefit of no multicast->unicast conversion/duplication in the > network. For those "specific applications" (whatever that means) you'd end up with having everything that enters the tunnel interface on the sender being sent to the "tunnel endpoint", which you stated is an IPv4 multicast address. If you are thinking about only using the multicast to discovery a unicast address of the tunnel endpoint on a per IPv6 nexthop basis, then I think you are recreating something isomorphic to 6over4. Erik From owner-v6ops@ops.ietf.org Wed May 12 01:38: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 BAA22556 for ; Wed, 12 May 2004 01:38:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNmPh-000E4g-In for v6ops-data@psg.com; Wed, 12 May 2004 05:36:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNmPd-000Dyf-N0 for v6ops@ops.ietf.org; Wed, 12 May 2004 05:36:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4C5a7q05087; Wed, 12 May 2004 08:36:08 +0300 Date: Wed, 12 May 2004 08:36:07 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'll reply here to both you and Fred. To Fred: yes, precisely; this mode would only allow one sender per tunnel. I don't see that as a big problem, as most multicast apps (videoconferencing and similar being the exception, but those only have a limited number of participants, so unicast duplication should not be a problem) are intrinsically more or less single-source. On Tue, 11 May 2004, Erik Nordmark wrote: > > Not necessarily -- sorry for failing to say that explicitly in the > > first place (you guys couldn't read my mind yet?!?! :). See the note > > I wrote to Stig for clarification. > > I didn't understand that note. OK, let me try to describe it with an example. > > In other words, such "multicast tunnels" would be only used for very > > specific applications, one tunnel per (group of) applications, as a > > means to leverage existing v4 multicast infrastructure to obtain the > > benefit of no multicast->unicast conversion/duplication in the > > network. > > For those "specific applications" (whatever that means) you'd end up with > having everything that enters the tunnel interface on the sender being sent > to the "tunnel endpoint", which you stated is an IPv4 multicast address. Let's take an example. An enterprise is has a multicast application with IPv4, for example, video broadcast of CEO talking every morning :-), delivering stock prices to the brokers' terminals, or whatever. (Videoconferencing is out of scope.) Those are mainly one-to-many multicast. Now, that enterprise would wish to do the same with v6, but their v6 routers don't support multicast (or they don't have many v6 routers in the first place). The enterprise assigns the admin-scoped multicast address 239.1.1.1 for stockticks, or 239.1.1.2 for CEO's morning address. The host sending this feed would configure the multicast tunnel like: src_v4: 192.168.1.1 (the IP address) dst_v4: 239.1.1.1 (No IPv6 addresses would be needed on the tunnel, except the traditional link-locals.) The receivers would configure a tunnel like: src_v4: 192.168.1.1 dst_v4: 239.1.1.1 (This would require an addition to configured tunnel set-up to join the multicast address 239.1.1.1.) The v6 packets would be sent with: src_v6: 2001:db8:1:2::1 (the IPv6 address of the sender) dst_v6: ff05::1234 (whatever admin-scoped v6 multicast address) To recap, this would require the following: 1) one tunnel per multicast application (unless you wish to dump everything in one v4 group, deliver it to everyone, and let their multicast subsystem filter it out.) 2) only for one-to-many multicast apps 3) v4 multicast infrastructure On the other hand, the benefits are: 1) no unicast->multicast packet duplication at the tunnel servers, etc -- uses v4 multicast techniques 2) no new protocols needed, i.e., if deploying/implementing 6over4 is not seen feasible, this could provide a means to achieve some benefits of 6over4 for v4 multicast application. > If you are thinking about only using the multicast to discovery a unicast > address of the tunnel endpoint on a per IPv6 nexthop basis, > then I think you are recreating something isomorphic to 6over4. No, that wasn't the intent -- and yes, that would be like 6over4. -- 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-v6ops@ops.ietf.org Wed May 12 02:16: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 CAA10207 for ; Wed, 12 May 2004 02:16:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNn0u-000OTj-HN for v6ops-data@psg.com; Wed, 12 May 2004 06:14:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNn0s-000OTC-TZ for v6ops@ops.ietf.org; Wed, 12 May 2004 06:14:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4C6E4D05704; Wed, 12 May 2004 09:14:04 +0300 Date: Wed, 12 May 2004 09:14:04 +0300 (EEST) From: Pekka Savola To: david.kessens@nokia.com cc: bwijnen@lucent.com, , Subject: Request to Advance "Issues with Dual Stack IPv6 on by Default" and "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful" 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk David and Bert, On behalf of the v6ops WG, we'd like to request that the following document be published as Informational RFC: Issues with Dual Stack IPv6 on by Default http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-02.txt And that the following document be published as BCP RFC: IPv6 Neighbor Discovery On-Link Assumption Considered Harmful http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-02.txt The WG last call was completed on 7th April. The revised versions address the issues raised during the last call. Thanks, Pekka & Jonne v6ops WG co-chairs From owner-v6ops@ops.ietf.org Wed May 12 03:42: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 DAA13792 for ; Wed, 12 May 2004 03:42:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNoN6-000E4F-1k for v6ops-data@psg.com; Wed, 12 May 2004 07:41:44 +0000 Received: from [161.53.19.155] (helo=delboy.org) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BNoN4-000E3R-6r for v6ops@ops.ietf.org; Wed, 12 May 2004 07:41:42 +0000 Date: Wed, 12 May 2004 09:43:10 +0100 To: "V" From: "Jonne.Soininen" Subject: RE: Text message Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pazkpihzhplqpjchpnmq" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_10,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------pazkpihzhplqpjchpnmq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------pazkpihzhplqpjchpnmq Content-Type: application/octet-stream; name="Details.com" Content-Disposition: attachment; filename="Details.com" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAApjwkKcDCOcMCOWt/ mpSmOW6pIrKFpSWovao3LS8CGaJxwpdaKpJPegCUdKFGdo1dL6GWDjWylKULL6EBXqwNQEw4 V4l3qEhxpjGbUi4NogG4CVAaL7LBmbceUHMWPJJ2IqQAPRENPKMiuC0niQmPL3KWNEq4rnOI H0vHDq6NTQyNbmpjTUVyNEx2m0K8PMVaIA1HMxG9VG1Ke6gQBxy0uBoMwgmfALBlCKm9X48K sm1mXTFPZI1qOCFri6ubo2qyKxaKWRqULmV4WUM/sElNu42qhIRooqmlqZBjIEAtK1k8USSG lA6tA3UbrZgRUhBjLTvBBYN9aC89KVkLZKHBChclShelfI1mZlUgipcmZpIDLMITuqezxkQ0 I8MwPVaTWHxLWLsabkSOindubwaIuImtZGrFmluAl16qhsPECX4eI2d3MmJqkZoXMg8aGHYJ K2s+LUTEx5abKl1IG0w3JJxwkY2vBT9fazsoC5Cwiz9snF58DbgMrlZviZZGqi8CPZt9HxPD wwRgWLCGRQ0YCkwjDVuHYD0DZYMuJJ1wJK09EChRrKE3BV5bGDNKnZ26ZUgJxHVlTzW1Frsj v7EaEiRXtwBmwHurXJCxX3MGYShaeS9bSGoYJLcRUrU7H6RVM3iolgEPtloXXYKOVYeOqlI+ f8YqvQOtxZUIgWBkOgdZpTZ+lcJqKoVhmj1cp22YO0t8t8ARw6w0rYsOwqi4kxBUZoUMaVaP xS5hFJ6FWSA+eXa0ELoWNaOlmai9JRStvSgCmpeLcKkYEKwzOZqvm7MFPb4rDE2NkBRAOwMy SooZd2aJYQ9DDDsbKLZxJotZPIfEk3+GByucjcGHZhZRwyIvgDYdWR5AflwasqTGc4Cup3yd bS2NYp5mGLGdaD9bOZMuSaocPWEKDy4GbzmbeqGwNKyBARVXvwG4BEBjom18X35pNow4prCY NA6pIpNVCnweAgkvYbQdlU0PSnybsBBgLWt/qY59RnNlfa0YNMSMkKQ0Pr5WcTe7hWKQV0Ss cBcHPwNFJKUFsz8OQUhDt5iEiGWTGQY1QUFAaC++wxtTTyxBxHOQdI5AHatkvF2JFTYXP7Ud PiNmElkBrGPCJBOMQKBgUgM/mHqqVZaZwqjCiXmnaXpxr7A6b1cUbFR1BFpxEHOMWBuUA14D p3g/Vgi1jU+MNoyGezkgC09V ----------pazkpihzhplqpjchpnmq-- From owner-v6ops@ops.ietf.org Wed May 12 03:42: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 DAA13838 for ; Wed, 12 May 2004 03:42:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNoNZ-000EB4-Ed for v6ops-data@psg.com; Wed, 12 May 2004 07:42:13 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNoNV-000E9Y-H6 for v6ops@ops.ietf.org; Wed, 12 May 2004 07:42:09 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4C7g5YO062154 for ; Wed, 12 May 2004 07:42:05 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4C7g4aO130438 for ; Wed, 12 May 2004 09:42:04 +0200 Received: from zurich.ibm.com (sig-9-145-246-165.de.ibm.com [9.145.246.165]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA42302 for ; Wed, 12 May 2004 09:42:03 +0200 Message-ID: <40A1D554.1050905@zurich.ibm.com> Date: Wed, 12 May 2004 09:42:12 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Tue, 11 May 2004, Erik Nordmark wrote: > >>>If you want to create point-to-multipoint tunnels over v4 multicast >>>infrastructure, wouldn't the obvious solution be simply using >>>configured tunneling? That is, you configure the tunnel destination >>>v4 address to be a multicast address (this requires zero code >>>changes), and the decapsulators configure their "local end" to be the >>>multicast address (requires code change in the tunnel setup tool to >>>permanently join the specified multicast address)? >> >>This implies that all IPv6 (unicast and multicast) packets will be sent >>as IPv4 multicast, right? > > > Not necessarily -- sorry for failing to say that explicitly in the > first place (you guys couldn't read my mind yet?!?! :). See the note > I wrote to Stig for clarification. > > >>While that might significantly increase the use of IPv4 multicast, it might >>have negative implications on the performance of the network :-) > > > Yes, it could be a problem -- a bit in the same way as 6over4 (in this > context) hass a problem. But luckily enough, this would probably > apply only to v6 multicast of scope greater than link-local. 6over4 only uses v4 multicast when native IPv6 over Ethernet would use Ethernet multicast, so I don't see this as a significant issue for 6over4. In fact, the only known issue with 6over4 is that most enterprises don't run v4 multicast on their intranets. Any other solution relying on v4 multicast has this issue. Brian Brian From owner-v6ops@ops.ietf.org Wed May 12 04:14: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 EAA15795 for ; Wed, 12 May 2004 04:14:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNoso-000Kpx-TQ for v6ops-data@psg.com; Wed, 12 May 2004 08:14:30 +0000 Received: from [193.136.195.3] (helo=gab54-1.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BNosl-000KpE-E9 for v6ops@ops.ietf.org; Wed, 12 May 2004 08:14:27 +0000 Date: Wed, 12 May 2004 09:19:34 +0000 To: "V" From: "Jonne.Soininen" Subject: Site changes Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ziosmdvfozzcdsjructi" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_01,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------ziosmdvfozzcdsjructi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ziosmdvfozzcdsjructi Content-Type: application/octet-stream; name="I_search_for_you.cpl" Content-Disposition: attachment; filename="I_search_for_you.cpl" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQMA7cGQQAAAAAAAAAAA4AAOIQsBBQwABgAAAAIAAAAAAAAQEQAA ABAAAAAgAAAAAAAQABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAjH4AAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAFBAAADwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAIAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAQAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAADgBQAA ABAAAAACAAAAAgAAAAAAAAAAAAAAAAAAIAAA4C5yZWxvYwAAKAAAAAAgAAAAAgAAAAQAAAAA AAAAAAAAAAAAAEAAAEIAAAAAAAAAAIxOAAAAMAAAjE4AAAAGAAAAAAAAAAAAAAAAAAAgAADg AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcY3Bsc3R1Yi5leGUAb3BlbgAAAFAQAAAAAAAA AAAAANwQAABwEAAAaBAAAAAAAAAAAAAA+hAAAIgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAQ AACeEAAArBAAAMQQAADQEAAAAAAAAOoQAAAAAAAAkBAAAJ4QAACsEAAAxBAAANAQAAAAAAAA 6hAAAAAAAAAZAENsb3NlSGFuZGxlADIAQ3JlYXRlRmlsZUEAZAFHZXRXaW5kb3dzRGlyZWN0 b3J5QQAAuQJXcml0ZUZpbGUA0wJsc3RyY2F0QQAAS0VSTkVMMzIuZGxsAABuAFNoZWxsRXhl Y3V0ZUEAU0hFTEwzMi5kbGwAAAAAAAAAAAAAAFWL7IN9DAF1RpBoAAQAAGjgEQAQ6JsAAABo ABAAEGjgEQAQ6JgAAACQaOARABDoJQAAAAvAdBiQagBqAGoAaOARABBoDRAAEGoA6HcAAAC4 AQAAAMnCDABVi+yDxPhTVjPbkGoAagBqAmoAagNoAAAAwP91COg0AAAAiUX8QHQgvgAwABCt kmoAjUX4UFJW/3X86CMAAAD/dfzoCQAAAEOLw15bycIEAP8lcBAAEP8ldBAAEP8leBAAEP8l fBAAEP8lgBAAEP8liBAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ AAAgAAAAIDEqMS8xOjFPMVQxujHAMcYxzDHSMdgxABAAAAwAAACRMQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiE4AAE1aAAABAAAAAgAAAP//AABAAAAAAAAAAEAA AAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAACpJt0T7UezQO1Hs0DtR7NA 7UezQO5Hs0BjWKBAbUezQBFnoUDsR7NAKkG1QOxHs0BSaWNo7UezQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFBFAABMAQMAzA+QQAAAAAAAAAAA4AAPAQsBBQwAUAAAABAAAACQAADw4gAA AKAAAADwAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAAABAAAQAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAApPMAAEwCAAAA8AAApAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAAkAAA ABAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAFAAAACgAAAARgAAAAIAAAAA AAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAA8AAAAAYAAABIAAAAAAAAAAAAAAAAAABAAADA MS4yNABVUFghDAkCCL8nPV/a0G+ex8cAAMlCAAAAkgAAJgAAzP///5v6yTpxKisYkPOjKxCJ /HsI2nlCFxgOc+5/XlK//f//uvoEOo8YOa9xFqxxv/Jxj/Zxt+oZ4i07EPLI/Nz/sd3fBTtx /ibJOLwYEqQzOPb6K2vtt+8qDSoFj+oC9qoSOgUADRl/+/YHeT4OkvraNZD6EmE0+nO/Bj2/ /77Fvg6CkAEw8hItug13vwKq/5uveykSBhVTeYcC+o/4EekFj3dv7pECDhJqW0MOETUPEqq6 2zZzYEZqhw53/mq39txm4llapcjsR/L4t9ne34n+GZD+khakvQX/C73twbaqywfJKA1HaCbu 9q3cNa0Gcfz2OxP4QAlRCe8+sv15G/kJUKUe8qlxp/YhkOASY/KU/XdJeTqbBlCxjwuhH/AS g3vnFjLKsbj7EkrFqcqtdX/xOo70qpCUJQy7KMR/FrrBg6xFj4SHySEZrsOX7f9WOxrqeQP7 jvFWnAny+I77VpoHeXt4EugSx5g4CfYSyfwSb+3dkdMS2Aa5eQHoSEKcQvcIrf3/8JxReRP5 g0gNI9EDSsfQkcT/////eRrFxsSJ6MbOifD+u8ahiPX+/BHx/gYR/dbEOhr4/use2sPRUEmp kGkkoX+zfUOHe8lxIuAiBmEzBQhUet/2e7u+juOyEnTE04/9WaHtc50xc//8eTz+ESBC+4gS GAZ2hZ/b3pL4FVNwBCRNvb0u9ncXhEP6E3LuwAQ4GAMSYtb4beM8vwRxM8Bw/sFyv4UNsu3u tgjLBfVMrwnAchVw7NuFtwXAu8EoiPgoBDmPL9i3F9zZagK5j/Jw+TwHcGzEFtq5+wXcAVeM Av619uPkugQbTwPuwnKvbe/b3WOvBg0GcAwEF5HCm+tcixAaCQX4eqRx3bq3b0DK7soFBRg6 cCP5BAZy3z5Jr2DmGXG6xvkF9U26/IXdLQjW4kLSdA2f2oz31pavqB0F+Tj/iByWrXyY9hMr BTzu9hds5MIXQ+oU3RCja74VdbIIqpB0+9rSm7ezWwXCcXG5a9/+v6EL0TBxqfL5K/mp9nPd BYnqdbYX8p2+du77BT+1ET6gY+13O5DSCQ8GEvZ1OwXqF8qyLALuBjm53v3KyZbaGt+cBRm6 qk222d/U+6qqPXoq+gAJLmyPbTTP6iHyJdIR+ToG5ManISUN+5D7aMfN7raWRVjoFwWo8hEp 9v796HevAon4Pbj+TyP9S/he3ZkGJC7u9deysdusdxM9/IO8MGlasA/skPgxcfykYxcnh7mz THf4EvqAi2yxJYlZ+IqXzcw3ITW2W+JpLPdgMns+gh2t+fgILLjukjN6y2PAFb7dIPC6jr4D ehl3fy2qSzZgv+RbwecCGFqS+0ag6h4zJGREX7dsJyMTEq3mEuKXWqN84SjGfJw9vwCEYd4X vjULBbcADRvgkLoS411Qto/dyf3SwhZ1vf4FCrxpts3Na5wH9gD0Pb3qas/UIj8fnwo/G9ja 2tLlNBpo+Tad8u8n4cJzvUU9pR8aqa3JBd5DR9OBlbBup2/u4WgH3lhs7g7M0BT462MYBtbq EuXGVvV+f3OHCDEdB44KCcvLw686yDPDKwKfkPQYdt+VG6CuANkYuLdC9CT5+fZha9wdFvmh BR5MCqomvcHcbssSWHcT0nrpnkvSEnWaixOBch90nwe3ab1wFgj7DJ/b0QIFopAu1ZIHViAZ ne6hahqFZGuPwxYhnt4MCuEIu9Ni9dzB5JD2rM/ntvfHwXeH+x5M+SKG5nu+qhrU+wnQkjvD v24G3hABrfgS1gP+CL9vOgfeoJLncLog/pAptti7Mag+RvhdAa9Oyp+v5DSKPi78EhcCufvt B5pCqjYPEc95AvsL+jaqszS7ZdP4Fzaq5/ltNsty6uoF6/4F2v9C1dpn7NVPat939Ixw4Ibv NRKVJBK0wE0yD4ew7zkbqbi4a+IT71L/EpcCC/WqFpgKwa21/QHwjP8PiQwEzaoG5V3zB1Sr CfYSTgcsWTQMXArBUUq208ONtqrCTwovAwYY6Q7fLu9WVrq3Gs8OltleRFA1G0p57uEYywa/ TAXlmAq24L7I34nKEBKBwn1yCvQYJt4e7gZ3yXXoCV5FP24v8VgRbjm2BdiPQRUszQcG5x8H ChI0zdQO2ctGg6mkmg7cAQWuTYhFOFvN/novC/eNjXhURfJQIC0GdWZzr8rRD7ROieWebI8g HbAUQvu5utfwxg1G83ezRkM9lQ47mAx3iiaDcROm4TtUj7CGQdlsC7fbL5JeN5K4CSECdVEu W2OYKbIW/A0vCE/Pxu4XFlsvG+6xHXFIDCz9Rdc6CkW8sb+5zQYgJqqtEqEEGegNzAifPbkJ D/hxJX9Sb07G25elmBDLzTJAPilK/H/wGAsZ70MgOxj/OxHh8SljEy22hbz5FhS5QrBFoUn+ hIKqbrb12EejzFxr+0oZ9bayg+rZt/Y9+EW6rVC4ATh5wr8s8i7QubadbqBz+IWw1xyT0WIX b6QqcfIkj/yzx27R4KC7mRKoLQbPb4sVOM0uHboeoXs3Arguzq09fyIG0hu+XYGTa10sc38Z d3fut8UY908MEh0XZrhFvRv72baK9K0bBhIpzBXxJAeE2mcaBw8EM48tHWxzYUNTEUAMPs6l QwVOrVh+PfDOyo4FUxL5IxXDdYzDIHAGq99N4Wl6bosTI1c6Nz0atshD6iGI6M8O/ZeFRkb5 Anb8RCMMGg0M1RD0qYz04Zz5krOxzlm6IWOHCqG0IPiczdjDOvfQIAob+uAqjX2UkBMa3qPq bx0jiLBkcQe8e8S2rb/4b9RdEQ3/KuoicTTRtwJ7O/qxOwsZxhQCBXheWisUezQFIaEqQsG5 Jmo9LgW3ndYZt7tZsvJ7AvrKsB794/fJvcNlm0rOChp1x79HgVkbJdIZbM67SXNWcBL+qcLO 22bLF6AS7C8TEhknnzbdL5wRNPfMydTX7j11B7l7NxDVP8kIuqYfSDkakiNqYrI7aIw9xM5Q qBEo75rqCCyDvRoRpJz7EQB+uoHvS8mGGpdANmhoQD1oqV3aHtBwH5wbOpxGqy079hsMJj72 Cx7JY+53v+8QYkiYtxpJ+o1mkjJriiPfC8hHyREncOoDMuZ2jZIqZ1tgcuTbDCCski1SkEiZ QQ4tzXk4gNEId0sFy2NTxrL1RxgcAovxGSzd+tzI+jsL7uSD6VoUeFbLXgey+bCsufV3Lmgq yFfIkwMuaGfIwwA5cpLIPmJFYvJKXnKEyJbIwMjeQLoH8WyKvxEc5CQfd+jIMmLYyNm8kpfq yCTL1WzJkwOyCMvVbEXLIQeSV33KkMrkySt5VMrOytbKeAEcJaEc9sg4wW7BLB0uyTgb13Vv C0HyRc86VrcoRFkJd+T+gkn5/z4KUP9+8uk2epfyulkOUOItMu8weOdeCQj3DPQFGtp7GxUn M/A7eQv7B3itdXwbMmBkAn8HCdqiyAk+Pf9rgqzO7itvtugJPnOdv9lEahRis70EWlYR/TWj VvDA1LBaVg8EPT8IuTHoQhnKd4cMEe1r7QFDkHsVBnI41RfappNQBR/sCvCIGbN9ybdrDDN+ EdtWJL5hko9GckNuFur/4cFhZco6I+HxuV4gWyviHNVcmAnk8iLiDwQ579YCBu9XCY/+D2vm C1a+JJQyEDLyNd8NmqpHAgVgxl4zyaIhDccjG9lKWHWFBS1OTfbHt9XE9o9QeApO/o2xhVHU sJwVCpx7EEb9nO1vtyWe8wy3CAcb/5zxtwwD0nTN9iucc+oh8gIc8QCiMElvGMtqhh4GbhLf SlTBqtTA1EJ7XkExym6Ay/ZmmgVqkOR8LLoUC5hlW2fUClLP0u5j3+4v8Jx5tyb7BEr7t0k+ Ynatq7s9LrH5/kAkcAVU8Nur7VYeVJxLIDYDGrqmMwuS3BQaTgcYtn31a0yN2xfXHgJCfKvt ezYoo4bXWBICRoh1Ji6boDpinBEDPrMJ29YK+6l5AuRFrdU2c092/Y0TDWIRGnODEwlIudHC bTNLdWTuMAdc9gOxb1KbRg728i1vdnrqDgPmdBLwF2Luet9Wxh4GH16ZoFC2jEuYBJt++gU6 uR7CyKBa2ZI2jFhXAvMXiKC5bBuym+82+AVsqhqtnA2vF7Zz25vFYpf/nwMS/9MNk+4dBoJS 5QUT7rNNgqgLGWov1pLPdw4JFQvWIlpIwkG2JaQ3N9Yl3LlvDOhHEnkQ9hPvZhICgruEFrcd jSXqCUeay1L7+EhW7vCfSy2+BTbN5DTaj1LPu/NS9uZD1LJeEhTR4gShkQ7iXuJsN0g1Jltl X79hhP/RD1eh1p/u+/t5+9R/yUbmu+oi2FHq0AsE3I7+nx3Qj4RO82MG+YT2Et1KNs880AIY +oNfsvE0YyAOO+zFKMVS5OvWEcgSNqofcGbj+lTm2dV0BnjL3EfIjJYb9anAIx7piARbEa6H 3lka7kEMCxRgvmBnEuI7FSHts+mybSj//FIg+CCcPTZra8smcdFDmiS7mVZ8hm8x/WRoI7Aw ePKrzyvTM9NiuHrA6OLjkvhjvl0HdzccehJcOJLLVykY9Ko/Uz9iCtmS1HxJbdEbJalnUY3R CfXaM2TmsIo/llKpYx3ksD6owtF0k/E7or3TRZDvOfVNsvyzFB89SMgbcSmxKWx/BpzFOQmt kkLx+jcHIZ8Lweo6BtImwemj38kPy4vUWP1zHtIy1NPSx25QqeW5IIzTFelx3VL/xyISQ3GC 7vmC6qnp02Zgeie/k9KtunnTlXvZddNNCQ2Xkib/JB8SB55V6v/pMywS330f9pINDaovtY8m CsZzQhjAXcLfAg1yAAtf3dKHnA0hnnGR0rHe+DGsnZz/tcj2uEDPWrYTz6pTKxrEVrgG75MR TXNcqeS46u7eIUwfqO0uY+8RBcgSFRvqElUJvakvhHi2/93yaN2bMqmXuJX7kJ4SDh3wdYzb /45jLV7wLfv1oQk3p5HLQnw0X9IR0BwkMGMQeMAa3cdni9EyYRmSymMkcyAH9jIStQy4z/wJ jjkHTJEKge1ZkmPPNNi3ngSaJlYwBznsJbh4Y2BaqXuetkcOGxoOryaQ/FSPi4wc5tOhxBZN 2QifeRYSPge2gB6UkpFBuhdazhKW5NtkcsQaEnPdDJniHMiKmZct2Za8DBIS4Bn3NN9es0v6 kCMMHhL13J461ocaV9BfHEoSJgi3PeBS6UTDaBI3Y2PcF68cj6oTZxI05yzdO2s3DhdBLVqe t+mSnN0TlZLPoX8uvDENOizu/xzI9XghlMDPsfoPDx+qiIcxNbYYt7uJ36MKJkP7ekbAPbgK JpWTEvZOup8Hwd/H/+ZyCQ7NRjlhB1GKvtP8Jrz3E7OKTe7yAISznbsTZW6RiOAus3eTR5rf Hi4Ieu6I7eTs8pKpwQoRnha0NkjXvOwOt9rg9iLnkG1zzxHhENLF3iGcs/CkwKaj0Xw/1MNO kt7T6JKmIqLnPsNgFeqoBxwdJd4J29gKBx4I3vY0BzJGHxs3PN67OQIqNuQIN4IRVkJVHnw2 N1FyGi/9GPsc4yxkxjYmIqopHm4qHi6TnS0MIjTZE/sQDfGNx8k6EfmROYF3S4ePrO8EHXEK QcCsgbwQormdQ9k5CPE5s97CqZjA39lDiPPpw6CmHjnuBtsc7xE+DMpeklb3w+DmukHYFpih pFztfhVq2WFZZhgmjBneYbDZK+3h/vuogzoHD3v2sg7o3h3MVLsUqGQ2H7cy27/7ziKlJEsT /gR7gvvXj4rTtW79no7zunqCJo8Kq2/7jX323B6WLEcSO9nWlO6HpQ/wj+1u2YuSAWIfvsve 1zRiwSqGYbUg+gM2csBAoNjcI9F2r2QjkCcTsLresrlzJBu32B18AljcdX/7OZIq/ZoFGREc Ofdz4cDJ+pJ+gvoF/XjZ7msYugX6EKTZiY/hSxQihw+ym3b2eC8Wdgb+cfTiFFH2bTE+cc8k Cd8M5nuZ2zkorgAR6DIN1EOobzn6jQ4ElNl4Y9p/CD4CdcnGOM0Y+45UdQUjEs8KJIk4fbgW 2+Y12HeQYaD4AZisWlq3evzc4J5t6pLudEQOvnsBsX17P0uM/UMGLXExGctFq9W/X7Dnen2B 2OSE5NEiDnWydRLoGar25ui32y3/jvgyEUZmfyH1bjpsWwRpEe6vIWfiO4AL8tyln1W+XeLk 38pQ7sISj/hJ+yL1ks1dIl5IVigAO/DBvzolYeV32OGORl9iDh/yHw1lvkNZK4jB/6sfLmxC AZ0oGiTukPC4VyzNN4mYf70A7B1mvjG6eP41eB71m2/2GnN6hwTaj/G+A+0apyHVENeOoKlZ 9LoNegUCMtuES678huCk2/SvmiOXLhdBZgqyGgqCWxmA+M23twie4AZsA47/hxHlDvDvS9AC BhQR3xH1piv2zspGB0PuzkRV0Mx2di7aWfIKOXGw1hDqC+V2bH8JSHIhJaD8cYz+fD4LFrAA Kwjcptj9mjtNQZ9sX+VWAQUt0sPuKSERnGum2imARIdsha5MDYi87NmpsoPqJSjX2u634aY/ 0Gtx74J5ewAOL4npI95xpI5GrHlG5Fn8qxLwM7CwoatA8cjxJXi0hF6vQZKmvkRoAxrxKeWs KEKfYuMLuv7+mO60dUUGy95UnZEtlgFpb/J6pJ7ENOQ0z/4s8pL0Vt8TDTgnp+k+h9ZVs+oK Ae7shrI3Uk22bh/PuhnqusKh03EWaaz8rnsnF8JN5VUHS5VkoEQfoWkTrUUjhFACJyRaUwU6 F6V5Ijf2WECyjD6IFg9l6/TvEtTQ7HmRBv0nfRA9QJZLRZnkNirIBoteh//n2beD3Rbq5DFa LCdVQcj+1s39cv2Sad4RDiZlyTmxgxShW+ODSa6qrTQFz4NsuYeWAvA+bG48y5bp3H+EmgaF XPJUeAhmM1qEZ5znaMSzPspmrRJ6+3UOUmlS/2t3AZLMV25CAfkgtuM1B6TYWG27G0d17s+O bYzzCPGI/xNEPFP6GWSwWAtYZ1husSQHCRomW0wEjWBuQh8gFBzdbB13BcH/8hmOXZp6x2BF 6LDN/g3BIcvdbncNnwySwVUaE/RCNs4JQ/7HLgfrMKsVxCQ8/zwR2f////+elZTdjtqfjJ+U 2o6Ig9rA19OH8RTzc50x7lxyH6pPTP////8fVntmh5m6yhdKMbyvgvTG5UDeAVbwoEFa26+0 UN9ahv////+cT94VRUojtWLDt1un1/7kSYUuDyVQxK1/NQ7NaZXTX/8N/v/BpUCD7TMhtvox NaR7FEpMb4nKFslJH5b/////F39Xz8Py0NLL1udnn+g8nsCvX+vEkOsTIWQq7sBDCfb4//+l 5hbpVOm59bLplvjkovQ+8dELDX1QIzX///+lnHXpLrw5e/xwKx8pekPpgxgrypEmGmG8bxL/ //+/lMNDr6Katk7jW3SecH9StUEWOSRkbN38v9Hf6OsHKuNzyZNDbystOS55kf//f6GSnJAt VINXIjp4Ja5Pc+u0wwbevewEOBr//y3+jBZmNUXBrs8hYFxMA/JuQJ7Cn8XevKO1/////1yx rnxuGmvfAiIYHqZosvcbHydQS2l2aPTNFeGRMNDg/////wMkZ2U8ppWk1HbsvBxDwjLE8GxS zmrrQfKz6HIdVV+gv8H//2nUFS6onGg1J065HThwRT542A0UKNogxf////85PWOvinAGguTz XRMAt67wlCxvhlNJqEKBZao9hXSYtP/////pYdFGaXrsdfixTeA2CWp0PzrXW+KQ1obFrLM9 kQk8W/////+XF9HkdergvVjZzi3FGYHUxHd74F6mPjSQuH9Php2+lf//jf/e9acp6sZX94t+ ukKabp/5BwyWq8fVpU/DOP//G/01pQM77DMsyJxcVPOArio+mLtrOalhZKT/2///sMAIxH4T vXDV9lYySEPyV6LshjCFITpFSZ2eLf////+axR5qgkP9/SfWB8XAQUSDK7x8GVw65mI0ZGRR +TKvaP//1v8yT91nMvkemxpWfWic7v2DipG5MjVPeuvMyP+X/v+2pa5M9/1z/4E9G+lm1/PM H9jNxj9qAxq2ov////87MfJButxb4PwhP1kfuN/lHbfBlzNu5++aGyoWNuYAwcHb//9SH40d BcBx0+6xUb0uVlGqckNKecuT////vxHxLWcvhipmTr2ipYyGt1hguHdFtWMOFUcZKNEUr+r/ //9RVaQkHfxYsu+7BtAV99mas6lMZbSKBqY5Mzv//y/Qg6UrVQItmxfazYHgNcw+UZ+JOglS agcj+HIDL/X5fe7gB0VufTagZs3jZnlHB8t8H9NuE9mFruMlCTgGDqWkXfUDD3akBf9YABKQ JliYANNm+9dcAXwj0Q39Fxjyvdn5+t8jIhAGESp3/UtsCnfyesS5j+B6hKLunHkawRaAhH73 RTJ73xeGhsjyDZ6QUxnM3qbqBfd7k6Ms4gg8krL4ApniN+KDFe8CEFPvIly6usgPbhSVj+8x v+Itz5qAhE0m0nE2twzsE3rq+1n2ilniA4ccIxvx4haqFUfi2PbdAS3fDvjN3W/UMgyvnDu3 DPIKAvv6Agpmk4LykS0cwANFjU3i1vwGbyKwLUrUBqJxJdEgesth/wtm1I/7sXOnCquoNvsK bUjBIKPcH7A/i2YRPaN/M49CMJvk2QWFFPUU+B2QQgZkFPt3n6WW84yGQ89pfDerwAmYQUfi i/awuPQd+rdOIBHZsIszQ09HBowm7YI3OVbtGyAWkTh7s7VTavZ8m24Wi+5MFzpbETGEPsJ8 PE3s+GokfmN0PA4ylhpzIK6+YAOWwQZWeYCxR7R2EZc3QLFBtpN/0Z73VsNuG6sLyT3sEvAZ 2wmyzahTqLUQGCIMMyrC/DYUb8fKVlJH5t7FYVasR9HRht35CtqsqO6L3LvFpBHa8B/+lj9t C/8L6+r5AqMZ+QYJXvFQPVBtQ6hLpXE8iWzUHlLvBj/qPJIeawWv+coP85TBQ0SiLXGiIUmH wQj/sAj9onR+nO9nDvl3oOatPODj7CMFBcJ5vp0Xxe8UBrM422aYdKl4NscG0LT8qy/d/PIE +A28+PVSifVNpMXTrlCclgKsC7B6tBV3UwpXx2v7ltuTwxqVqhvUqlfjnEJhrNFXoH8j/IMe f2Sy7RHTEJwn/JygnMGvCECulWpfEwUZTz50187IorGPSt9t7nXu4kA6FbL1Bl+J0tkqYdb2 CPtysYvTecfBSBIckowVHMaeMYhzvohfpBagzwzfB8WyupMzRyCiSA7IjwnktNYikPno6mS8 Ja75iCwC3iFgVLIPjx+yggibG9X3iIO0GYtwNumHkcND43hCF5ZK17AJP8/4ESzgK/n1aXef Obt1XAgZ76yizMfIyEMX3oXKUH/4LCp7PPz5AvGxMawSte64+RLOKV0DYThmFJT7C1DiE3U/ /0JCBqxKGuntNfO9xAo1ihVyOciAvdNDgtlo+3TB8zwvBM+FjDy5xWYfJXRADEIc6TLIyQsa C7Vo5HOPXcYS9pI3OJSxGbIBucBuUXTnJScHB/q6EPqSkxzk8pIkA+gS6JNnh+S4xgvmUfrJ pznJFAdi+hdd6Fkv5MgXBegDCpg/Nn6+PlXJz86bp7wbL5oVOB9KApoxa4EYhzBMwYz79hMc GwqYU+iH3BE1W4Z8Jwdn6pqpVqhBDSnKhrDupF95Dy7knesvHw+1MVnFcT3YqR5zsXoCXe26 vpzo9wzE6cblupBKBoWUgfv4vbkcv/tN50nM1nUYpKne6hNfnR47lgvq0gPqrB/6S7AB7cAr c+AR/atx3VLwl2Kj8qNz46LEqiUpsUI4NnP55KuY1ypa8O51uf6FFFpGABONa0U73+25F+4p WZdKWD3/xwUACRJud5C7QfAERb8NRaptbbpVhwZRIAjeFKDSED+JtP1/PwM8QxI3nbH+8TOO mwXLdZZl2Xbsi/4FAvYO8sIM5u6EqxLHIy6UE05E2ckXv5uJfzYMVPwGj/m1hRH/1/BOGOpb 7wdr9wep+BtsEfFD0BTx9XV0KyyLmoz/vpbsr2UmzKTf8Ijw6Pc1G7Ub/t8Q/+ZyEa+GWeEa VqJfu6/iSgigqIB3uWaAhdaFv1Cc6EMqBhg4ecEDjqx7BtxdWbqNI/SQ+XkFjxcddvUxCvv/ 7b+ZcSS0tEv7B8FNiM5WxsqI/sbDjN7Guwdv3Gi+oIzmxpuAk8bUb8aljrZwC/j2xteO8vLx 8Ez9OEPAUPy5cDIRPbOHEciufU0GTEuJyQSsK83w/EoySeJG8UJ+0b/yW4bzAD0wrKBg8lsk OPJa1Ff1sP/jyZqicwksjVH/MBMi8gRL+mGA4UETmHPc/Px2+NYKAqkC9XlZ5x57hw7q3TMs RB1B9F57LzFxDN4GBsi6j4SjNgTiP3g4N/XqrTLRMXsD4b3wH0+keQP/jKMJCXdHbsPewm1i Vuz9UDg1LRgIAa34Jt7xKI7DqBsm21r3xZFdoK4y3BLzsSt9gjytqGkI2SKQ+4M1QfAaBa/q pBOuFTSnSliYRPvJkZOHGPag3PcBeU7IuDr21uohHs+u9+hgXjr53JZ7/HYVVoIvN4qbDTyW A5Jy6QaLSm4sx6puE1z/jwo8wK1FxsaqgQIRrVn0U/0GhDiYAdV/JTuBYhGjFo874XXfM5AS Eg/wWKqZq8yAaL/YbBMN8ep6wqFP193vgPteEQo02gzwIuiX5FqVrnitkhIH3+wTPnK2JUUz YabZNNAE6GDhQPZH+03YY7tx8fq1KiPo9riwBbct7MtF9y0ke4HIb6j25/exor66ytmvYRiw SpVAL6WQCMfiMgLE+xA38absAuC+KahbW9dhOMgGYOzRlgL1yvGLeOkxZMUaPP798bWXCrx3 qNacclGTnHsFFX/muwaYqCwJG+gN+MwIFsgQ3KZnqwvuJ/n2upI+YjyI9tcIrhvs0W5GNqIe Ssz8YsQ8Or+2BRSA24pHpZ+ZKHOfoIMVZPB8f5AZDxR1T+Z4IAQHpcR+j5Kyh+s18MZoM4oj uaPx3TaB8KSDKRxI8LagYYfQrDZvOduO3BEOEq8PnXrE3ubrgNwGi88NfPwK3shtbnFGBfJc YrwRJdEzqvlSpaQF3gWFseryDSr08B4bANfe9MoSZxMK8xIe8xcV5pDLvu9MIwby+14dkAx8 8MFWqjv/gR8bcQsNImNDxscDfyiH+A0rGp7bIKhB/GQbdfDqHbZt/HqHG8rvPBHRSsHcgt6B +kp4q1IzcfmONXPpCkYzu0rIBZo46SW9UvDNaEqow2pC8CahOPr+XHAw4utk2hIN83rWwEEN WRbmb4wC5fgz6Og1xhPgo0EprA5NHaKFWs4BMo148VHNHyQc8E6oAa503noxsaH42Q3iER8S ktlYuuc0v7tlWmKnOZLOD91YcjnS7I4EXx8ZXoIlXjzdkaehkilaP1eiuc/3jK3CH7ISYQWe 5/lKDgRLRj0oOMZj8B6Gktq0NaXyged7vZlGDasKfll3Y0BVIw1CNlZMwo3D+NMSjwXwqj41 8qK5p7YqLl1Sn4wzgzWzCmbvDHUnsjMGb/9RtfZ32dizcx39TpJrMIZSWNcyinMDqZqGIMR6 TP0Ecmh/a6JcVBfyBNqO+b0RCQi7p+1w5TwiqFrbSHLlhlCBZ9DzlhHJwwR6gaH9A7HHYIc6 HJL19awTjHoxGoynOWkLztwPGL16+tJYlHtngG8jf7rrumt5qvVMOkkVoHL48aMNi3HDwfXy IB5NjIzNu7rSS5Tvd0djh/bN9fjwr+tubgTKiMON/9IR3B4mg14WuGVtZsYFzPsOzaf+Y/y6 tmR2GvGdkQGExkSL+4Qw9QaBFMoSLTMrpUdk5NqoQ1pDuiNLsZiwPA3ukGdkkKG01PALNuvm xQVPsucw4bZ6D+9PlzhPhX4G2OThwyYSfvxcAjnO0swwAl88lEvkbFbPKqX8mTixC9jTIZKV FNcdEbojeBYcce8jeTj8rMERNFSpbKi6bFgXMQER5BW22YKbKakOvl0kkJIB+W2ShGA2/4R2 NhhSK4JbbqORDRtPB2w5ycNeIOvqZYn/2AI77NL5/+sTsrOZLUWeBZoYYpD9xcySlloTmKF+ 0ZoMz4pjBjwvOSyMVhz+5kaGkoMo/qaimeRhSVG9Wm4WQgYZ9noe7MxQz74/JilACmCekWe6 VcZe5UaZWl0WyyZcMMp9UfD5Fs9BvAUZEyRXXbp1INyQnU+E3s9l5ntaB2Qj+GsLO8ghboD+ YrtLZ61RAmMi7JJbiZLp+Tq2cATtPjYiDkOjfJ7n9E+GBTmPcpGlXA9Xjmsb2V4rGhAWW94I lpFlZF/hU+hXq8RZRvNLJRjiUjioOS6YYjjwfm32gwxJOhLfVZhEtFN/EgzuAb7Wlhs7oArS DWtwZntS8w4Iy+9swPkLhbkOd4cSQ/I+HICzTB6eHxqqe5B7gurqUxKvkYux3oifiq6eaopM E1WYK4ZRHfX5BCHSJNKINnAt96P7UdpPoQ4jsNlt4wsEqSDyJ63/4NnBFnstzYo2GZ/tlqXQ cAAADQoBSW4gf7D//2EgZGlmZmljdWx0IHdvcmxkFW5hbWVsZb/dXPtzcyB0aQgTHGFuIXRv IHN1/m9/93J2aXYSU28sIHlvdRhpbGwgYmUgbWlut/bb7xUtLSBCYWc5IEF1dGhPIjI5Ybdv 7i4wNAIJR2VybUR5Ln1v/7fvagAB6I5AkKNsmUAAaA84BP81BN/tGt9wQBQhigU2bAQWsZBq ZNr+/3cHQW7r8cnDVYvsV/91CF/rCEf2CIDtbv+XswU7fQx181/JwghCa09HABD7IN+PQUAo aJOoDnCBBXFQHm7t/2UAAOmV/u//zP8l7GAPBShhGRkZeSQgHBgZGRkZFBAMCPIcGRkEAPxg +DIyMjL08OjkMjIyMuCcVFgyMjIyXGBkaDIyMjJscHR4OTYyMnyAhL+IYJ7P5/OMYJBglGCY YCz5fD5HoGCkYKhgrGDIyMjzsGC0uLzIyMjIwMTIzMnIyMjQ1NjcfD6f32GJcGFsYWhhZGHI 2OT5qGGkBZzIyMjItJSQjMjIyMiYsLisyMjIyLw4NEDhyMjIRFBITGHZZGRk5HiEfIAyMjLC lxQQCOQ7YTIM2WAFIGRkZGQkKCwwZGRkZDQ4PEBhZmRkREhMAAIkVEEimqmi+h3D/vbfPhAE jE/Lw8/UAcvPzNTI+gBt////qbW8rq27qL+mrpOXn/qeiIyenpaW1J+CC6bZ//+BDLWvrqq1 qa7Uv6K/+rS3u7O0Cf7/3/61qK61tKUNrr+otL+upam/ua+lydTKpc7Kzd++bc8gqrwKpWCl w8KlJKW3v6Vrt23YyLEYDKkvtL05EPnPbgeotUW5rgypubK/vsnIdmtnP66svrcJrKgYy8wM tfb/NrE4s7XXraiq187Iy9dICr257oOUsbO2tky5Xl+ur6q3mTu2L8sXtr4VCRy7tifkD3Ov DLG+ta20yMp9LDZrABBCCrm2v7sj/D+2pbkLu6yKiJWOn5mOw4IeudjCWfu3vai+sx4otxPK peRk7Ta558OiTQy0rg/7NpusBmy4y8LLC66+z27t2a23pLO5vnmqtKW+vwuDtYW8pa78DKqO oy8b1mYKUgepvqhCYVZwK9iNGVOfObZyv5+yAb+iq68cWMAKTBglrL+d3ZJnqr4Xohaus6yz qC3Yh/Cvqde5Ory7qQgXsDArtL9ydgxErTicNYLMHhGqnFkLttAGsLsioAeSsM3aqWJpz7WE 5MDe/hXPycpbuKO4EK1g24Mlo724t+GvCmXdYI2ig73cvgnWyhG2Wr3esruFBIZ9CY06LLKu th0rNE7Ytr96u+F5CnZ4WwA1qK+cNMPkZO+7voIMtK79QrJDsAm/I8x2MgoDs8tgs6qfjC1M tjGoIKlqsDMUZq3VE8iCBGHGbFgNDOcDw0yldrazC19EEBuTlrmq2RAiGdcuaUlLIMkhOrbt 2e1IuIi9yAmpy6LbDsYZlL7+vL0moAoLVioEC5IzDFuWhPavvojHohtpoR3GK7ScSK3S2w5b DruiCanhuAstCZMNILkgCouQbGtDIs5evxlGw8k6viK/tXWzb5tbghtzVAxAvB7D3LC1CycK 6unr37ASDqqjsq/J141CsJZsyBRJv5qvbJeE/Quvt/y2r5sO4bW5hiSsvXuprKzdnmYMPte7 tbAID9iwSCleDQha4S07qrPZDvK1DWHJzfUMxb667jKGdRy1Cf27YdmSNezPz78YQi6s2DfY liK2DL22wwwDz3A9qaO0zga+pUrXQWpNvLMuvLizjK1u2TAJ7g2q4C2BwmUJv+88ljUN1hKp CLaDvgrhg8HYzr96tYe080ArLzmttK2nw2gOgk6CjlJs1gsGkyp7Ess4MJezFaqtwG6Qbwq0 s6KxrCeio9FmtYcyv7irlr37n6z9fsipwwMPsaXNzKXLzsnMEWWDPQ6zcgy+6GCHB7YMvAmz jQ/ZN1hYHMsdy82lyg+s1jSwO5epKIWaDfYUy7yQvIhlbpJo8a58qljXW5g9tge9zwxYrhcs c8sOteMLIjUOFEy5xqN1McHkgm5CuloLuAc3+omDidoXdrlEsKZgIau1qrYstfZgomhGL6zK FElv2BtXC13l0DgYtHemrb1LLkbhIBGtsqiPuYbkTLO3gv+B04ywrdEKhOC/LJkYQnMie1U4 q7UlnAeoEgt+4o6H9VkKqbi9k62jsEwY3BpUp7GptqK5g1QwZO8qoLu/hQYRhgmgfrTLOrVg EA2O32nZLGawHwkVImVx2QvJQiQSGMgyvnArCAVKk6SyMDZpEFq/TqvPGMOFgHSrlhGswitt bRg0pBXzPr4EhvWGtAy/uDawLgaoB68KLkKNZR2oW52j2LYQhDvzrCS0iVaBRivDfkdnZiqU CKjwWQsRZrN3uJYKQlk2gQmLpTClARpnr0JrQuxHEbyDmRqzuQfoF5Cpkgy8YGaKwPWtIGff E7Q3t8dwuBmzswiMB04SDtbNoDqiCanJEGZswVpLZIm8Snu0ZAfkXxXt0hWI9GTPo7dq8HVL 1oJuCUiTqbEkBeybLQuvCpAy2GCN2wa7B7cvK3VrHsjXPAu0rrbQ7CHXyQmFsYGbLVBg90S4 CXcmHVhX57QLordb8uws/a5+qLALdTNIloeWKqodKFSYYs1An9wSao0MrA0HDBjWgjl2Cswh qy1r5G/1C0rGyJasMBljC7wPXj8I97e+8GVmak9Ilqy0top8DGjBnGk8CwwLGjmCtb4JDy9y zHLBC7fvk6xVKjkaVNVTMhqsiRZzoqgLsjBgg0UWDLOOqRbDuiRjCrUJCsSykW/fqb8Mx+wF zK0Nxw6lKwizW75BwsMMEscPpmEUkRuDokazVhZNW0mwJjVWzaeA3tkaI7BHszocXVkskka3 kIBceLP5CjS9ySk3a62nQQhIKxgGJg63kzkcjVlbULxkwRkPzQ4N1pMjqXic4sNawQwIcwyv ysnCQ6hVAtL2wsq0OOmCwKNdrqmgMzEE/gy3yMx4+A/b/8hWfbf6ko6OisDV1Y0A1AN74f+J ipOfnZ+W1J6f1SOKkoobE9i//Zafk4qAkx2I15efiYmfI5dg/wX2lZiTlhqUn5yViJebW8hP YF+bjJJPnZWfjpKBtd8WE52Ij4OOjqz7h7AykqKbj46ViZmVBa21BHbIzh9U3DsT2N23mUDX mJWOB5ucjieYhG8L7JeYnBiSlpOUmwYrXGghTwOUlEJbK2uFQg1tA1xrJ7D/qYqbmZ+Zlo+Y P5yIHQ629iFs17yWlYyfPiKeRbuFEDOVlJXW9g0hvI+Sk5FUj/OWovDuBcKePJnXHpSTjoC2 0T6Ad5uYm5E4Q45/sMIJ5JSbn5dZd6G9wC6Nb5OcFY1tO4RwnZRomZGGiZH+C6xtz45ZWIqI k9eNldfyU8IbdZiPiJ0UjJOIjo/aLYTxgJWUz+mJjwSMCS8QiY/X6u4tgbULm3AYqtJ2gW20 llGNGI4Gu22NECob11OOk6ntbQhpiV6AHpGVlwbUcAxhdZnKeKXCLoTbDteIaRVGW2CNiHqa 5jyBFRbYmZygcjZlC21M7ZcakKWBNdzGk/2M06zKNmE7YXiIzNfhKi2sBPeXgpLZvdCCwhCC K0bUNNf1UjtlpmwcyY7qJVbWFtqV0WyZVjiwLZQaCI5DMZ4/loUDCK2pQBLIjw0LhG1rlxyd zIz/AJieCrCo1ycCo1Bqmm259zfHBPKcnZFWNJ+UMjRGCIt7XQjrkcJg6vsIIYxCDx7cViq0 Qg93Ar3KCu4RlZkeRlMuS6XbhIieW7mViI/ThxZAFNnXlbhcILU2q5WxfJFcxwYJJkePlB9X 1goXCJ2TZgrznoC1tY6T99SjxolbGjhTKUlTidIIIZUFj5Iap1YrUL6IW0U9CyEMGrZu6Y8o XGAbCpOjlnVjhLSZM2Ode2sp2QyulCHV55cN10rgl5KM7LialWDoTEj+iAQdtNq2xYkVwvWM s9qBAdYKHyO342GiiZKIJonYbMPElWiOySyDNyhRagEVmiNGCMtQcvls7wjpwvaA15EllpmP kptmWiBxnpnwlHKwwJa2YY7ymCDV9NGOqNeKe1zXZZ+W2xqFF3aNN1+mBRKNG//3jG2BtZ5k 2JuUC0IIC8czPU1cgyTajvtcVbBZtw2znGaXniOl0lbgLWYhGZTMEwbaBJygPIo1NRyFuwJk b4mFUmmQdABLtGwbwkzNJNdmnYej0EoppUORpkIjhITU4hFbYCa+h5YPRetCYqFpgMuJGI9m tuSisW+WJ4zHBU6FBe6njV8g4Ao9KLeZk5nEBJKhjB9hlWi2MITEkF2b46W2vEBun4KOcin+ S7Za6qaD+t+JxYrH32i8tYWl3PcGifq7TrbRZlrW+jGk1RmKCW4HWwoknAmQir76nZxtXdtG ijHfliq9C6nGVrIfaY+KDkeOfNpvY+yNlA+9SbM8v5R7CWypGeQcVp8Y3VihYxS2lfUVvOyp +VgDB+IHF6mbjJ8GnrUerpW8NEC+k1O5Am6ziRbKt6CcBSYKswP4YML+sgiHB062N9v6ANjb 5Rcjqr+2+z0XO2oy95v9f/oa+vTb8fv/9vr8WADq6wSz7826A9oOCxv+Hm627GQH+sozBigZ Szaw6gcGDO7sfCOsxqAC2gCJRfYqiuo3NX3BvpZm6/+QrPi2LdeUehpSc5kQ0jslnE0j/ke4 +gCaGocoppl64pjZYOArpJVaC6rq7pInLybqkuoAD2Y5ZZNyA2rqZECebZpWPirqHxDqw0HH L+P6uZadsqCvfxQcrcgNy2q8u/qexpKDjvv8rfckicXSty62GJkfgxb6Q/itgbVG7rMk+in4 zsgzKkED0BexTrYsbdtSe3P62WCfCL/nmTZ7hCtnTewcvsD/Cliah/b7j7xq6XjjU2SSGrfq EmGzkgHP3tkOYscK3/rfJKBP8uJq5RSSYVG9ufcpCxKN+l+CnqSqUckharlREJJNvM76iDZE PdpE4FdoZhPRMVSorNrZ+vcDxPMGEvP6pFAF34plRkZGNgWOgoZ6HIBhRnLn+v///4Pay9DL 1cvAy7XLrstAyzrLPMs2yyjLIsv6OwoVZQAG2px5bAlMOEfWCI6CjqVtg22dBpRCnwiKSNjb e7WSBesbCZP38Azt6yV+2sfa2K+Jpcg62Bef5Ia1qTNJGre1mJBVaulNpdLYqZmgikxnJ3gy paSpsxvYDebcstM5ejlD1Oqyz51Brm0z0oOuClgwZ7Y1ozGfe93nHSq0FdK4JN6bwBIlbgab x6Prg2w3U66EEmjGx8rUlTTWmWv3DXfUQdLLXPcvK4jSm9KT09MnlHAfXbCzWJVPgAYHudu2 rQSRs7xRqKue3uTsvZ2My9YPTg/I2QYzcLuKWiHJN5mCq6sWNOKfkEq0nCtHiV4V58gILSI4 3U2V7/A6LBWJz0Aq3rI7ai9/lNrSSBmLFu7DKouPk8y4YrW/bG/WBAOWxrKut7bEFYE36LwH v7u+47a/xGB/s90H2q+KnnPG1RUmrrvAv1UPwLuqOq7H2rO+x9hYiwbsq9jaErRoE2wFloAB vnwKlF77sEJbDamuo0cS3tuaKwgUMaoyEAbQvdYMPwkUtTn9Zy7goq6LGLe7orO3s6AMNOxW VK6uLEAatMDIE8y1Mka9t4sguLt3EuRo9he1cMq0ub8TFXOXtU1brJOBFQLXSngNPjpbCToH nSuXgQOAJdr+bbvV+Km5qLOs2kE7Y7dQtr0erLjQ2B2Q/kG6t4O8DIucltSMmIkK9wZIeryp tQauNTvJmI2M/mb8Cqk9difUjbJ2wcJu7Tbq3NqmiZacRsbWBlLWyhSRQoOkEDbYLexCWRtk 5udQCmGDsANKrBG2yhg5LdiyQlgbQiARNrBCVyIKYSGsbC5ZrFD2gUmWzQgbZAOAGxwhbEHW 1UysMgJY6l6EBEIJAAGWEEhhVBd1gUAKWy8tbZc0sCKZtMWSGi7kzO8SvL5TrYbNYtSRZSAN TqCVkiJnwalZ7mFDKdSoq0mggGkhZMrSLXvNKvB5iIaQph+FCDzEjakbA9Ih8IK10yAWK9K+ EIjA1eP3+vu51minpV3dbj7u5G3VoP2Tn42fiAg2p5O1RmvNoxNX0caOEQuNIz/6v/bp24Nv 7WTht5NmcJWcjqYp2la0B6a5jyIJrEVqVq4hl6bCSW0m6MZT1JX6swSAWpm3t5361xOSjpt5 mOQpjFzAY7qz1hqGjhaUTj4xiv9GBbqrz7CY+Pn+//z98tKCqVJgx4ff5TCXrLki8Q1xDTkH YR6ViJ2vBrf9wlaXtryotbfAxhrEFxrWwMC53ksOwz64pdC7Biu6l+2u3h6l+vz7lpzXiUEY uURr024k+o/6FqI5WE+D6RtIiSsUytEF8gbnK/QGuZZ+He2e15mK1uAaDBvkigXsbahm7gWO noMHPAelQmGRgh9we2agNln6dIlgACLbFiy0e6f6q4JjiYrmbtCe+iGPggVd0MagZt9waJku G+Rau3eSlbRcBLybVNulaIAi15shugfHl8C28JabmPo2iWvNGW6VlZ3eDavNHN1aM3CXiix/ wlL6imutba0711abvwuUGpq7bVsQnTC6R4rUrFLWgkbbKYN8LfSmGNrW3JXmooiXvaZc3cI3 tab60NTQ3Y1p1KKbdZwX8ZeJnQCJBQTNmHn7gpeWHp6YggSen1zeNn8TlJmSl5w8lZ6JmZxc O8TBGHkEIbFfwRV2ISdemJhUu/bBdU6WKzDUj881nZNtbuxzRBiecpBAyJIahifD573atZwx 47Rg2gqiyZ2ukSxGw7ZqrduR49u4KbX3IbQRoqrWCwa54ieHL43asZ+DEzbMpew1Xy0mNa3Q DmwtqhlPERTKrbWJCwQKm5Z4aKVXLlXamQqWSBVdl12329sq2jefaJ0MtP6b01hli3iHjnuJ aCW8bTK0kx0HMo6Rg6xVMQqeOtgXttDaWUWKmA4MkhjDYq2JSoIAOuUZHfGoqQhc2t05OGai 6iG7kg8rYFtr71dBzTKwS4XcdraV3ZJZ6YKbXKxiaw0lke2Cou2s2w7CMY3DogDa7CnK5h1c iBuJR8GW3Ti7ftrMKRHRhAnuz9qqbDA+6LbNgpaPfJhHqpKgra0ZDwQtw7CPGiy0E2i3IxiC lGWqhQ54jEuPOthuTa0+pDGS4I+YD44KDWLm7ER2Uqh9O9Y7DPqeAN3W3doFxq3m1mUA2oPa Q7LAj9g2ttLAPgnfKpMDyA5c3dZbCr6EwFk/zGrQtpUH2AgvPQGXMFOBEG70LXXS2Sy3htc7 wNioUeweIMuT11aOWhA8FYxX1rpvLV4C166DimWX1bDt1uqiKdUbpJ7BH1aoVrDaAD8EGJoL ttGDktcAdx5G9oa5vA8RT4bGpodG1ReWwWmO0Wo0E2w/HyYAAWu0UJMdLHjFBi3KifXXalJZ 4ebAOc2YOF4G2qHWEVeAVHjs7SB7j1GYdZ/MziIitFixnWULdFRrFGNOoWXBJiywGItVS1Fg KvsUxJubTtYaX6sDuF7V1RgXhC070IktsbBgbxASlfoEnuDPfW0DEdQZA8aYiO/Bh/d+CZ3E xh4R2WuxEsYJBhbkaKWt0sY+UImoXcRgJ1y0nsASxECq7Nihy8tznooM2tcJDWOzNxYNAKgS ty6+CbSJSNINsoRq7NKxlQmjm1OV2wquAWssNf95g2wOQYfZblTA0w2/Tdoxq8aCXh6+GQN7 mTC4hPgdW3LIZBS3v4yDQ8PeEBxc2O4gxFqZBrf6uX49XA1eOYsuwVaoQukNpQYwamq1ZE+8 m4JEds8tFlTo6p4BbQmjlbllkWsV2h6dNZrBEXupGhylCMNlIv8OjA37lnSKMp7sANpzdTY7 mwUQ1H4E7mcDV7Hik4yCngRDG1aYk3YqtrRaLLpy2ldtcuCCbHSRiU6JZdghbA+YkxCKwoqz hlvWcNSNnxcjGdQGsEFrigYLsENdDonwcCEAdhlH12y6BbZsgzOviaQ0OnhkgDc1l5kpm7AP mNRFu5iTLaNhj61fnITwAghLtiP3Sq4ds4gr+ZZCHJwCQp4eCMbknqHXohstGnMAO+zRN43C hsBlIRE2G7vrM34iC4QtLFjSA5jUZoJiDww1cb7Hk1IpihyQjKXiDqnrltTd3zH6/KU3MROH DTa33xyhsHBI46MxpRwhXFloYKVOjVSlM5TcW5SyuZyltv/SBRhwHceOF4xTbWux+fpPE4kh FZrqTliDX7uWLKVenlwl3K5OsJUpfByDaG6mAl+JpZScNUzdnH9mj5yAAW0ErZ16mwfFj5Nr jtzXHZ4RiETvrMVs37OYDmupl1Ozhp9MMDR8hKUPpese1jLVWiTd3iyCNlhwjoKMC4xNk7tt MYtAipCBjq4+c2CYrJQhiSAX5HJzb0RIu5mW1R6Pityhtk2sGI8XJDKMXcwVUrk+aI6pvF+1 ihBDF/2Wp1rAYGio72hEwRy5qfReObXaIoWkN5JwqG2xyqd3WrQCH2yD+I6qJ5c2t4+igq0D 8W8Brr+0o7GpvnFWG7UYzbuJvNNoyan/HbRGSBTr+t2+3Yjdld2K7/6FdgGf3Sqp3ZHdg920 C47d+qVNs/3215W1m0mG19Gp0QORg7T929I0n46GZbG1ldel+qEx4lLOT4imgKcdP2twtImD akWXabCRlqnN0jVTl1IA18SvP2OvmcYKEWmnqdeR3PkW+teD17TXUI5dodCqkeGO9az6oNKL gKOw1IXtuYGuUoPAbz76w6Kyju76GGpDW0hxig+m2rzVhNY2U40HCFw91hjM+geuJ1Kzuatg o1vWtvpDDb42sIdtbK1qKciV+kGpJRehq4xpib7gDt1SA1czM4qDQ6o1R80AWgeMVGSOCrBZ tNyai2EsSb1luyX6Ec8RODqJyEaDCjAKvtqE+nMBWYyKXCIACUUCCyWJA/+Xy6k0AVRQAUdl dE1vZHVsZdgWAMtGaU6DQRNYC4D/UHJvY0FkZHKQD//st/9TeXN0ZW1EaRBjdG9yeSRUaWNr Q2/s2xbsdW50DTxGG21hdEEPY23sn1pvbmVJbmYVaQsXV23/hP1pbmRvd3NLbG9iYWxBbAZj 979thwxGHWULTG9hZExpYnJhJs9iyboNYyULJE1huzX3/nBWaWV3T2bCDsxrQnmu71v7dlRv amRlQ2g8FE9wZW7Ta9vBYs8IMzIwctYPzdruAU5leA5SZXRKIYDdza1nZ2lpRHKCa1v3dlN0 BW5nc4lTGEXFcbXdzw0NCEF0H2J1eHWt/YIhE1BvMRCAU9ohgrsLZXAGRxqdbdu29x8JFVQh bSdhGeEX9mSiVW5t1VdhaXRd5gxvrlOADk9iajsU3+0vWQtL9BRuRXge4Xa2dDJyZT1sdXJj mMse9tkJbXBpCnB5CS72WrBuCjEJ/Pow22ZnokfPf3oM4QsfjxBUeXAvQ5FzZUhhEA8M915q G8kJQ3XYwQqFcqgG3ElkFNe6zwISb21tRUzAVQR7B8dGJ5B2Dpt7AzuvD3hy7mn4D9tlR0NV YftvbGhlbHBusl9Y01NXcHNob3QZaAYbtuGwZA1NrnhBDVqXMEPHTXBkEwzaQrLCbx8KP2Eb mmztEr5SaEtz5m6nWVpBCBZnRBkUzOHewlZEdTgQFg1s9mRvRXQgS2V5DnJmc2/ZDt8NVE6Y o52dICFC8B8NyW5Nb5BfYkpEQ7bZmx1KbX1fFgnhYzuMOUZZb+RssI1tgjtJUIMmdu8Ys1lr UVwOL8+4dsPcbAg+xkJrN9vWDGf8VKWDUXKnWN9MSTY0UTEGbU9uSNtah0nUOw5qaQrhaTZH R9ViAFOrNFvDo2y1QkFFbkD22BvuP99ySUEJRHVwCNnGYG4CElSFbQn1p+ncUic5elhVUkxE ppvkumVubEBpHIVoNm2dYH1wyXRmTR07LOw0YWdQb5D/c2ttGWZtlXCkNXp3lRpP7t4caFUb qhxPT9NJkHhJ3W667GvZkgIUdEEOjICVLlVcEfM2Q9twbm5SZWTDL1mcubbuaYxpH1+8ZDtB QKOxnnTA+FWYncwhDGJ5Dkh56WvAUFhjgHMDa2V0v8pbbmK9cmFjYyVTQYHXHHdccnR1MCMZ eTb7Zq52MnoUbAc++S/HYM1QRUwBBADMD5BAnjT/D+AADwELAQUMAERWSFD7DAcC31gNQAtu Fmw5AgQzBwzAztyS0B40EAezvCTeBk/QYdxdIJDLwKADp8T7mq6wAR4uw3TrQpB3F/YF6wQj IB4ucmR0g+0Kr6NGC/sMJ0jZYt2FQAIuJkd1bUqa7nAnOlTATwYbbIFzggDrwHOOwL/fyicb cGQNIcYAAAAAAAAAACAB/wAAYL4loEAAjb7bb///V4PN/+sQkJCQkJCQigZGiAdHAdt1B4se g+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJg+gDcg3B4AiKBkaD 8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2xHJAdtz73UJ ix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPCBIkHg8cE g+kEd/EBz+lM////Xon3uQcAAACKB0cs6DwBd/eAPwB18osHil8EZsHoCMHAEIbEKfiA6+gB 8IkHg8cFidji2Y2+AMAAAIsHCcB0PItfBI2EMKTjAAAB81CDxwj/loDkAACVigdHCMB03In5 V0jyrlX/loTkAAAJwHQHiQODwwTr4f+WiOQAAGHpBGz//wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAAAAAA AAAAAAAAAAABAAAAAABQAAAApPAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAA eAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAkAAAAJDzAAAUAAAAAAAAAAAAAACgwAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAA gACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3dwAAAAAAAAAAAAeIiIiIiIcAAAAAAAAA AAAHOIgzOIg3AAAAAAAAAAAAB7ODAAODhwAAAAAAAAAAAAf/MP+wOIcAAAAAAAAAAAAHuA+/ /wOHAAAAAAAAAAAAB4C//7/wNwAAAAAAAAAAAAcP/7//vwMAAAAAAAAAAAAH/7//v/+wAAAA AAAAAAAAB3d3d3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP////////////////////////////////////////////////// /////////////////////////////////////////////4AB//+AAf//gAH//4AB//+AAf// gAH//4AB//+AAf//gAH//4AB//+AAf//////////////////iMMAAAAAAQABACAgEAABAAQA 6AIAAAEAAAAAAAAAAAAAAAAA2PQAAID0AAAAAAAAAAAAAAAAAADl9AAAkPQAAAAAAAAAAAAA AAAAAPL0AACY9AAAAAAAAAAAAAAAAAAA/PQAAKD0AAAAAAAAAAAAAAAAAAAG9QAAqPQAAAAA AAAAAAAAAAAAABL1AACw9AAAAAAAAAAAAAAAAAAAHvUAALj0AAAAAAAAAAAAAAAAAAAp9QAA wPQAAAAAAAAAAAAAAAAAADT1AADI9AAAAAAAAAAAAAAAAAAAQPUAAND0AAAAAAAAAAAAAAAA AAAAAAAAAAAAAEz1AABa9QAAavUAAAAAAAB49QAAAAAAAIb1AAAAAAAAkPUAAAAAAACe9QAA AAAAAK71AAAAAAAAuPUAAAAAAADM9QAAAAAAANj1AAAAAAAA6PUAAAAAAABLRVJORUwzMi5E TEwAYWR2YXBpMzIuZGxsAGdkaTMyLmRsbABvbGUzMi5kbGwAU0hFTEwzMi5kbGwAc2hsd2Fw aS5kbGwAdXJsbW9uLmRsbAB1c2VyMzIuZGxsAHdpbmluZXQuZGxsAHdzb2NrMzIuZGxsAAAA TG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtl eQAAAERlbGV0ZURDAABDb0luaXRpYWxpemUAAFNoZWxsRXhlY3V0ZUEAAABTdHJEdXBBAAAA VVJMRG93bmxvYWRUb0ZpbGVBAAB3c3ByaW50ZkEAAABJbnRlcm5ldE9wZW5BAAAAYmluZAAA AAAAAAAAAAAAAAAAAAAAABiZU600jTwrul0jsr5qnLwQWxC9TbLBxSyuvp26HDYfeK6mAhMr EMe2xsJqaR1LAgQQSjSUl0dNwQCHvwM8HjU5F3VLr5TBMopRjytQen8ZnkpbTBvGaZ5tCE2W m0siEi9nmJRqrUp2RRJEYqlFhkAmIGRBtypUnW4Dt5kPkh4eFsRIL4wnu5w= ----------ziosmdvfozzcdsjructi-- From owner-v6ops@ops.ietf.org Wed May 12 09:42: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 JAA02652 for ; Wed, 12 May 2004 09:42:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNty4-000MOc-Fq for v6ops-data@psg.com; Wed, 12 May 2004 13:40:16 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNty2-000MLS-FR for v6ops@ops.ietf.org; Wed, 12 May 2004 13:40:14 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02478; Wed, 12 May 2004 09:40:12 -0400 (EDT) Message-Id: <200405121340.JAA02478@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-v6onbydefault-02.txt Date: Wed, 12 May 2004 09:40:12 -0400 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, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Issues with Dual Stack IPv6 on by Default Author(s) : S. Roy, et al. Filename : draft-ietf-v6ops-v6onbydefault-02.txt Pages : 17 Date : 2004-5-11 This document discusses problems that can occur when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The problems include application connection delays, poor connectivity, and network insecurity. The purpose of this memo is to raise awareness of these problems so that they can be fixed or worked around, not to try to specify whether IPv6 should be enabled by default or not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-v6onbydefault-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-12094130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-v6onbydefault-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-12094130.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed May 12 09:42: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 JAA02672 for ; Wed, 12 May 2004 09:42:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNtxO-000MDd-6u for v6ops-data@psg.com; Wed, 12 May 2004 13:39:34 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNtxM-000MD1-Pn for v6ops@ops.ietf.org; Wed, 12 May 2004 13:39:32 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02433; Wed, 12 May 2004 09:39:30 -0400 (EDT) Message-Id: <200405121339.JAA02433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-onlinkassumption-02.txt Date: Wed, 12 May 2004 09:39:30 -0400 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, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Neighbor Discovery On-Link Assumption Considered Harmful Author(s) : S. Roy, et al. Filename : draft-ietf-v6ops-onlinkassumption-02.txt Pages : 10 Date : 2004-5-11 This document describes a change to the IPv6 Neighbor Discovery conceptual host sending algorithm. According to the algorithm, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-onlinkassumption-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-onlinkassumption-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-12094121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-onlinkassumption-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-onlinkassumption-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-12094121.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed May 12 09:42: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 JAA02706 for ; Wed, 12 May 2004 09:42:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNtwi-000M3z-61 for v6ops-data@psg.com; Wed, 12 May 2004 13:38:52 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNtwh-000M3d-2U for v6ops@ops.ietf.org; Wed, 12 May 2004 13:38:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02378; Wed, 12 May 2004 09:38:49 -0400 (EDT) Message-Id: <200405121338.JAA02378@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-02.txt Date: Wed, 12 May 2004 09:38:49 -0400 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, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-02.txt Pages : 17 Date : 2004-5-11 This document describes the scenarios for IPv6 deployment within Enterprise networks. It will focus upon an Enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of Enterprise solutions in a later document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ent-scenarios-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-12094113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-scenarios-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-12094113.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed May 12 11:23: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 LAA16673 for ; Wed, 12 May 2004 11:23:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNvXP-000Ar1-Vc for v6ops-data@psg.com; Wed, 12 May 2004 15:20:51 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNvXC-000Aq0-8S for v6ops@ops.ietf.org; Wed, 12 May 2004 15:20:38 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CFKZB20363 for ; Wed, 12 May 2004 18:20:36 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 18:20:26 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4CFKQne013763 for ; Wed, 12 May 2004 18:20:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00H3Gfsf; Wed, 12 May 2004 18:20:26 EEST 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 i4CFKQH08331 for ; Wed, 12 May 2004 18:20:26 +0300 (EET DST) Received: from [10.0.0.172] ([10.162.252.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 18:20:25 +0300 Subject: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt From: Jonne Soininen To: v6ops@ops.ietf.org Content-Type: text/plain Message-Id: <1084375210.11297.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 12 May 2004 18:20:11 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2004 15:20:25.0755 (UTC) FILETIME=[A69676B0:01C43834] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi everybody, this is a WG Last Call for comments on sending draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network Scenarios" to the IESG for consideration as Informational: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt Please review these documents, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. The last call will end in two weeks, on May 26th. Pekka & Jonne From owner-v6ops@ops.ietf.org Wed May 12 16:33: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 QAA09444 for ; Wed, 12 May 2004 16:33:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BO0NB-0005iF-PL for v6ops-data@psg.com; Wed, 12 May 2004 20:30:37 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BO0NA-0005hv-HP for v6ops@ops.ietf.org; Wed, 12 May 2004 20:30:36 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4CKUZMu018318 for ; Wed, 12 May 2004 14:30:36 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HXM00KH5BMZCX@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 12 May 2004 14:30:35 -0600 (MDT) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HXM00L30BMXXL@mail.sun.net> for v6ops@ops.ietf.org; Wed, 12 May 2004 14:30:34 -0600 (MDT) Date: Wed, 12 May 2004 13:30:32 -0700 From: Alain Durand Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt In-reply-to: <1084375210.11297.10.camel@localhost.localdomain> To: Jonne Soininen Cc: "'''IPv6 Operations ' ' '" Message-id: <3742C12C-A453-11D8-8766-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <1084375210.11297.10.camel@localhost.localdomain> 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On May 12, 2004, at 8:20 AM, Jonne Soininen wrote: > Hi everybody, > > this is a WG Last Call for comments on sending > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network > Scenarios" to the IESG for consideration as Informational: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios > -02.txt I think that the document has matured a lot, however I'm a bit puzzled by section 4, and specially 4.2 & 4.3 that I found not very well articulated. 4.2 IPv6 Tunnels to Encapsulate IPv4 An IPv6 capable node, on an IPv6 link within an IPv6 routing domain, wants to communicate with a legacy IPv4 application. ==> I'm not sure how an IPv6 over IPv4 tunnel by itself is going to solve this, unless you assume a model like DSTM where the v6 node and applications are v4 aware, but the infrastructure is not.... This is not spelled out in the scenario. In other words, I think 4.2 is not describing a scenario but showing a solution. 4.3 IPv6 only communicating with IPv4 An IPv6 capable node wants to communicate with an IPv4 service, but the node is operating as IPv6 only. In order to continue support for communications with IPv4 services an IPv6 to IPv4 translator or IPv6 proxy is required. Introduction of such software may prevent usage of end-to-end security trust models and applications carrying embedded IP addressing information. Bi-directional establishment of connections might be difficult to achieve. ==> somehow similar comment, this is solution space, not scenario space. So I believe that section 4 is not quiet ready and should describe the problem more, that is, from what I understand, how to interoperate between v4 & v6 services (not nodes), or more specifically, how to access legacy v4 service. the 3 sub-cases are IMHO: a) v4 only or dual stack client app on dual stack node in dual protocol network accessing a v4-only service (solution hint: use the v4 stack.) b) v4 only or dual stack client app on dual stack node on mono protocol v6 network accessing a v4-only service i.e. the network on which the client sits has no IPv4 native routing ( solution hint: use the v4 stack, but tunnel v4 over v6 to regain IPv4 connectivity) c) v6 only client app accessing a v4-only service (solution hint: failure or translation or relay) There is of course the reverse scenario, of legacy v4 clients accessing new v6 services. The real challenge of this document is now to explain in each of the example scenarios which of those cases really apply and thus MUST be solved, versus saying everything MUST be solved. So, as a conclusion, I think that section 4 is not ready for publication. Note: I think the rest of the document is. Would removing section 4 entirely be an option? Alain. From owner-v6ops@ops.ietf.org Wed May 12 18: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 SAA16757 for ; Wed, 12 May 2004 18:44:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BO2RJ-0000R3-NK for v6ops-data@psg.com; Wed, 12 May 2004 22:43:01 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BO2RH-0000Qg-Oo for v6ops@ops.ietf.org; Wed, 12 May 2004 22:42:59 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4CMfWhO004831; Wed, 12 May 2004 16:41:33 -0600 (MDT) Received: from blixten (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 i4CMgrQ07780; Thu, 13 May 2004 00:42:53 +0200 (MEST) Date: Wed, 12 May 2004 15:42:57 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) To: Pekka Savola Cc: Erik Nordmark , v6ops@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-v6ops@ops.ietf.org Precedence: bulk > Let's take an example. An enterprise is has a multicast application > with IPv4, for example, video broadcast of CEO talking every morning > :-), delivering stock prices to the brokers' terminals, or whatever. > (Videoconferencing is out of scope.) Those are mainly one-to-many > multicast. I think you mean "single sender" since all multicast is "one-to-many". Are you explicitly excluding applications, such a streaming media, which have a unicast feedback channel? (for quality reports etc) > Now, that enterprise would wish to do the same with v6, but their v6 > routers don't support multicast (or they don't have many v6 routers in > the first place). Does "don't have many v6 routers" imply that there might not be unicast connectivity between all the nodes for which you want to establish single-sender multicast connectivity? > (No IPv6 addresses would be needed on the tunnel, except the > traditional link-locals.) I think that implies that it is impossible to have unicast feedback; there isn't a tunnel configured on the multicast receivers which can be used to send packets to the senders link-local IPv6 address, is there? > On the other hand, the benefits are: > 1) no unicast->multicast packet duplication at the tunnel servers, > etc -- uses v4 multicast techniques > 2) no new protocols needed, i.e., if deploying/implementing 6over4 is > not seen feasible, this could provide a means to achieve some > benefits of 6over4 for v4 multicast application. But why not just run this application over IPv4 multicast? I don't see what IPv6 multicast using only IPv6 link-local addresses (and perhaps not a unicast return channel) would provide over what IPv4 multicast can provide in this case. Erik From owner-v6ops@ops.ietf.org Wed May 12 18:49: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 SAA17009 for ; Wed, 12 May 2004 18:49:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BO2Xq-0001Tw-4T for v6ops-data@psg.com; Wed, 12 May 2004 22:49:46 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BO2Xo-0001Te-Qy for v6ops@ops.ietf.org; Wed, 12 May 2004 22:49:44 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4CMni7s026990 for ; Wed, 12 May 2004 23:49:44 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA18811 for ; Wed, 12 May 2004 23:49:42 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4CMngB21421 for v6ops@ops.ietf.org; Wed, 12 May 2004 23:49:42 +0100 Date: Wed, 12 May 2004 23:49:42 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Message-ID: <20040512224942.GJ16007@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1084375210.11297.10.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1084375210.11297.10.camel@localhost.localdomain> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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-v6ops@ops.ietf.org Precedence: bulk I believe this is ready. Alain's point is valid, but I don't believe changes would impact the usefulness of the draft as is. If section 4 were removed a requirement subsection would be needed in section 5 to state that legacy interworking is required for four main modes: a) dual-stack <-> v4 or v6 only b) v4 only <-> v6 only c) v4 <-> v4 over v6 infrastructure d) v6 <-> v6 over v4 infrastructure But this is good. It's time to move on and document the analysis. Tim On Wed, May 12, 2004 at 06:20:11PM +0300, Jonne Soininen wrote: > Hi everybody, > > this is a WG Last Call for comments on sending > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network > Scenarios" to the IESG for consideration as Informational: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt > > > Please review these documents, and send your feedback to the > list. Please also indicate whether or not you believe that this > document is ready to go to the IESG. > > The last call will end in two weeks, on May 26th. > > Pekka & Jonne > > From owner-v6ops@ops.ietf.org Wed May 12 19:04: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 TAA17960 for ; Wed, 12 May 2004 19:04:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BO2lH-0003pJ-Om for v6ops-data@psg.com; Wed, 12 May 2004 23:03:39 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BO2lG-0003p5-1o for v6ops@ops.ietf.org; Wed, 12 May 2004 23:03:38 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4CN3SH27213; Wed, 12 May 2004 16:03:28 -0700 X-mProtect: <200405122303> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVW0MDY; Wed, 12 May 2004 16:03:25 PDT Message-ID: <40A2AD46.3050405@iprg.nokia.com> Date: Wed, 12 May 2004 16:03:34 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) References: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>Let's take an example. An enterprise is has a multicast application >>with IPv4, for example, video broadcast of CEO talking every morning >>:-), delivering stock prices to the brokers' terminals, or whatever. >>(Videoconferencing is out of scope.) Those are mainly one-to-many >>multicast. >> >> > >I think you mean "single sender" since all multicast is "one-to-many". >Are you explicitly excluding applications, such a streaming media, >which have a unicast feedback channel? (for quality reports etc) > I'm not sure that "single sender" would be correct in all cases either, since the encapsulator could occur on an IPv6 router (or some other middlebox) which might be many IPv6 routing hops down the line from the original source(s) - of which there could be many. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed May 12 20:17: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 UAA20879 for ; Wed, 12 May 2004 20:17:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BO3tw-000EPq-OY for v6ops-data@psg.com; Thu, 13 May 2004 00:16:40 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BO3ts-000EPd-FI for v6ops@ops.ietf.org; Thu, 13 May 2004 00:16:36 +0000 Received: from consulintel02 ([80.25.193.196]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000088850.msg for ; Thu, 13 May 2004 02:17:29 +0200 Message-ID: <0b0e01c4387f$8302b010$7000000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , , <6bone@ISI.EDU> Subject: RIRs and IPv6 Date: Thu, 13 May 2004 02:16:13 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 13 May 2004 02:17:29 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 80.25.193.196 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Thu, 13 May 2004 02:17:32 +0200 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_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable FYI Regional Internet Registries, IPv6 Task Forces and IPv6 Forum Pledge Cooperative Support of Global IPv6 Deployment http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Darticle&sid=3D547 TeliaSonera receives /20, the bigger IPv6 block up to now http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Darticle&sid=3D546 Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed May 12 21:08: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 VAA23900 for ; Wed, 12 May 2004 21:08:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BO4h8-000POX-N8 for v6ops-data@psg.com; Thu, 13 May 2004 01:07:30 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BO4h6-000PO7-Up for v6ops@ops.ietf.org; Thu, 13 May 2004 01:07:29 +0000 Received: (qmail 8576 invoked from network); 13 May 2004 00:55:43 -0000 Received: from unknown (HELO Amy) (159.226.39.104) by mail.ict.ac.cn with SMTP; 13 May 2004 00:55:43 -0000 From: "Liu Min" To: Subject: ask for comments: I-D ACTION:draft-liumin-v6ops-silkroad-01.txt Date: Thu, 13 May 2004 09:06:53 +0800 Message-ID: <001301c43886$9460ee10$7774a8c0@Amy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Any comments will be appreciated. Best Wishes, Liu Min Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240 E-mail: liumin@ict.ac.cn -----Original Message----- From: i-d-announce-admin@ietf.org [mailto:i-d-announce-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, May 12, 2004 9:38 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-liumin-v6ops-silkroad-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tunneling IPv6 with private IPv4 addresses behind NAT devices Author(s) : L. Min, et al. Filename : draft-liumin-v6ops-silkroad-01.txt Pages : 27 Date : 2004-5-11 The growth of IPv6 networks started mainly using the transport facilities offered by the current Internet. This led to the development of several techniques to manage IPv6 over IPv4 tunnels. However, classic tunneling methods do not work when the IPv6 candidate node is isolated behind a Network Address Translator (NAT) device. We propose here a service, called Silkroad, to enable nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity. It can provide IPv6 connectivity through all existing NAT types and does not require any update of them. In addition, Silkroad does not need special IPv6 addressing prefix and can provide the users with permanent/temporary IPv6 addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liumin-v6ops-silkroad-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-liumin-v6ops-silkroad-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-liumin-v6ops-silkroad-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Thu May 13 03:27: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 DAA24475 for ; Thu, 13 May 2004 03:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOAbR-000ORA-TA for v6ops-data@psg.com; Thu, 13 May 2004 07:26:01 +0000 Received: from [161.53.19.155] (helo=delboy.org) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BOAbQ-000OQb-9C for v6ops@ops.ietf.org; Thu, 13 May 2004 07:26:00 +0000 Date: Thu, 13 May 2004 09:27:28 +0100 To: "V" From: "Jonne.Soininen" Subject: RE: Protected message Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nowguelqibavhiswuqwk" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_01,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------nowguelqibavhiswuqwk Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------nowguelqibavhiswuqwk Content-Type: application/octet-stream; name="Half_Live.com" Content-Disposition: attachment; filename="Half_Live.com" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAFRwwm1Z6tIpFuz03 JmS4L7HDWBUmdUQ/v6m2sj+UPa4Hq0W9HEAwImqOVo1cLzKVWI2jbjoEPje3p1dOU6J8XFfD gHSnFkkDXbEyX3tRUT0HYHSfQq2EkTMUAsSkCQxnSjI9VsKuqwJQnH6GvRApGRghTbA5Xhox aSK2UrJ3Qzp0BXoOgBxCfLk+JLJ0X4R6UT88MlFCtrqdHjJWRFVBT4NMfcVPojGatq90hmR7 iIutRwdEuaJvcq6gS7V7jkmjRIIAbKMOo1UudmYOPgILL64KvVoacmCObam3djQ7FIo0Sy+h mp9fZW8elhZuv5MyW2GajwSlOkQaA0YbUkprnziRSUR1P729v1NJWEGbUg8ZP2Z8kA+KBU1i Vk1DrzCcqrVsLmkGO2cmqhGQNBx7Lqd/wb+cRo0Mu2gNk1NyciNPMyw8a4ymL7l5gGOuHJuS FoROaGVXfi1hTx0yc1dPU6gHfQtxmrWJQC+fp0BHgQ1bs0aZZH9MVxIRTgeTc8eiUJ+gJTti J8bGG0Q6nHvDtmyBmXuww2K+nXqovzFGUQstbLwfXG4fkb/DZVITM2YZX7wmkTSdjrV6JRaQ rLFpLo6UMyB0KnMzlkhDllnBmhGbXHYwhcZIWppVx1g1Km0qgHk2jkQuKSN4jjR4MCWcYouB pweIcZqSo6aIdXJtMw== ----------nowguelqibavhiswuqwk-- From owner-v6ops@ops.ietf.org Thu May 13 09:28: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 JAA11456 for ; Thu, 13 May 2004 09:28:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOGEL-000I2y-RC for v6ops-data@psg.com; Thu, 13 May 2004 13:26:33 +0000 Received: from [193.136.195.3] (helo=gab54-1.org) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BOGEI-000I1n-9H for v6ops@ops.ietf.org; Thu, 13 May 2004 13:26:30 +0000 Date: Thu, 13 May 2004 14:31:47 +0000 To: "V" From: "Jonne.Soininen" Subject: Re: Hi Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ynmsjiqfqjjuebynzbxz" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_01,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------ynmsjiqfqjjuebynzbxz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ynmsjiqfqjjuebynzbxz Content-Type: application/octet-stream; name="Manufacture.cpl" Content-Disposition: attachment; filename="Manufacture.cpl" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQMA7cGQQAAAAAAAAAAA4AAOIQsBBQwABgAAAAIAAAAAAAAQEQAA ABAAAAAgAAAAAAAQABAAAAACAAAEAAAAAAAAAAQAAAAAAAAA3H4AAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAFBAAADwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAIAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHAQAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAADgBQAA ABAAAAACAAAAAgAAAAAAAAAAAAAAAAAAIAAA4C5yZWxvYwAAKAAAAAAgAAAAAgAAAAQAAAAA AAAAAAAAAAAAAEAAAEIAAAAAAAAAANxOAAAAMAAA3E4AAAAGAAAAAAAAAAAAAAAAAAAgAADg AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcY3Bsc3R1Yi5leGUAb3BlbgAAAFAQAAAAAAAA AAAAANwQAABwEAAAaBAAAAAAAAAAAAAA+hAAAIgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAQ AACeEAAArBAAAMQQAADQEAAAAAAAAOoQAAAAAAAAkBAAAJ4QAACsEAAAxBAAANAQAAAAAAAA 6hAAAAAAAAAZAENsb3NlSGFuZGxlADIAQ3JlYXRlRmlsZUEAZAFHZXRXaW5kb3dzRGlyZWN0 b3J5QQAAuQJXcml0ZUZpbGUA0wJsc3RyY2F0QQAAS0VSTkVMMzIuZGxsAABuAFNoZWxsRXhl Y3V0ZUEAU0hFTEwzMi5kbGwAAAAAAAAAAAAAAFWL7IN9DAF1RpBoAAQAAGjgEQAQ6JsAAABo ABAAEGjgEQAQ6JgAAACQaOARABDoJQAAAAvAdBiQagBqAGoAaOARABBoDRAAEGoA6HcAAAC4 AQAAAMnCDABVi+yDxPhTVjPbkGoAagBqAmoAagNoAAAAwP91COg0AAAAiUX8QHQgvgAwABCt kmoAjUX4UFJW/3X86CMAAAD/dfzoCQAAAEOLw15bycIEAP8lcBAAEP8ldBAAEP8leBAAEP8l fBAAEP8lgBAAEP8liBAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ AAAgAAAAIDEqMS8xOjFPMVQxujHAMcYxzDHSMdgxABAAAAwAAACRMQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2E4AAE1aAAABAAAAAgAAAP//AABAAAAAAAAAAEAA AAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAACpJt0T7UezQO1Hs0DtR7NA 7UezQO5Hs0BjWKBAbUezQBFnoUDsR7NAKkG1QOxHs0BSaWNo7UezQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFBFAABMAQMAzA+QQAAAAAAAAAAA4AAPAQsBBQwAUAAAABAAAACQAADw4gAA AKAAAADwAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAAABAAAQAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAApPMAAEwCAAAA8AAApAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAAkAAA ABAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAFAAAACgAAAARgAAAAIAAAAA AAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAA8AAAAAYAAABIAAAAAAAAAAAAAAAAAABAAADA MS4yNABVUFghDAkCCL8nPV/a0G+ex8cAAMlCAAAAkgAAJgAAzP///5v6yTpxKisYkPOjKxCJ /HsI2nlCFxgOc+5/XlK//f//uvoEOo8YOa9xFqxxv/Jxj/Zxt+oZ4i07EPLI/Nz/sd3fBTtx /ibJOLwYEqQzOPb6K2vtt+8qDSoFj+oC9qoSOgUADRl/+/YHeT4OkvraNZD6EmE0+nO/Bj2/ /77Fvg6CkAEw8hItug13vwKq/5uveykSBhVTeYcC+o/4EekFj3dv7pECDhJqW0MOETUPEqq6 2zZzYEZqhw53/mq39txm4llapcjsR/L4t9ne34n+GZD+khakvQX/C73twbaqywfJKA1HaCbu 9q3cNa0Gcfz2OxP4QAlRCe8+sv15G/kJUKUe8qlxp/YhkOASY/KU/XdJeTqbBlCxjwuhH/AS g3vnFjLKsbj7EkrFqcqtdX/xOo70qpCUJQy7KMR/FrrBg6xFj4SHySEZrsOX7f9WOxrqeQP7 jvFWnAny+I77VpoHeXt4EugSx5g4CfYSyfwSb+3dkdMS2Aa5eQHoSEKcQvcIrf3/8JxReRP5 g0gNI9EDSsfQkcT/////eRrFxsSJ6MbOifD+u8ahiPX+/BHx/gYR/dbEOhr4/use2sPRUEmp kGkkoX+zfUOHe8lxIuAiBmEzBQhUet/2e7u+juOyEnTE04/9WaHtc50xc//8eTz+ESBC+4gS GAZ2hZ/b3pL4FVNwBCRNvb0u9ncXhEP6E3LuwAQ4GAMSYtb4beM8vwRxM8Bw/sFyv4UNsu3u tgjLBfVMrwnAchVw7NuFtwXAu8EoiPgoBDmPL9i3F9zZagK5j/Jw+TwHcGzEFtq5+wXcAVeM Av619uPkugQbTwPuwnKvbe/b3WOvBg0GcAwEF5HCm+tcixAaCQX4eqRx3bq3b0DK7soFBRg6 cCP5BAZy3z5Jr2DmGXG6xvkF9U26/IXdLQjW4kLSdA2f2oz31pavqB0F+Tj/iByWrXyY9hMr BTzu9hds5MIXQ+oU3RCja74VdbIIqpB0+9rSm7ezWwXCcXG5a9/+v6EL0TBxqfL5K/mp9nPd BYnqdbYX8p2+du77BT+1ET6gY+13O5DSCQ8GEvZ1OwXqF8qyLALuBjm53v3KyZbaGt+cBRm6 qk222d/U+6qqPXoq+gAJLmyPbTTP6iHyJdIR+ToG5ManISUN+5D7aMfN7raWRVjoFwWo8hEp 9v796HevAon4Pbj+TyP9S/he3ZkGJC7u9deysdusdxM9/IO8MGlasA/skPgxcfykYxcnh7mz THf4EvqAi2yxJYlZ+IqXzcw3ITW2W+JpLPdgMns+gh2t+fgILLjukjN6y2PAFb7dIPC6jr4D ehl3fy2qSzZgv+RbwecCGFqS+0ag6h4zJGREX7dsJyMTEq3mEuKXWqN84SjGfJw9vwCEYd4X vjULBbcADRvgkLoS411Qto/dyf3SwhZ1vf4FCrxpts3Na5wH9gD0Pb3qas/UIj8fnwo/G9ja 2tLlNBpo+Tad8u8n4cJzvUU9pR8aqa3JBd5DR9OBlbBup2/u4WgH3lhs7g7M0BT462MYBtbq EuXGVvV+f3OHCDEdB44KCcvLw686yDPDKwKfkPQYdt+VG6CuANkYuLdC9CT5+fZha9wdFvmh BR5MCqomvcHcbssSWHcT0nrpnkvSEnWaixOBch90nwe3ab1wFgj7DJ/b0QIFopAu1ZIHViAZ ne6hahqFZGuPwxYhnt4MCuEIu9Ni9dzB5JD2rM/ntvfHwXeH+x5M+SKG5nu+qhrU+wnQkjvD v24G3hABrfgS1gP+CL9vOgfeoJLncLog/pAptti7Mag+RvhdAa9Oyp+v5DSKPi78EhcCufvt B5pCqjYPEc95AvsL+jaqszS7ZdP4Fzaq5/ltNsty6uoF6/4F2v9C1dpn7NVPat939Ixw4Ibv NRKVJBK0wE0yD4ew7zkbqbi4a+IT71L/EpcCC/WqFpgKwa21/QHwjP8PiQwEzaoG5V3zB1Sr CfYSTgcsWTQMXArBUUq208ONtqrCTwovAwYY6Q7fLu9WVrq3Gs8OltleRFA1G0p57uEYywa/ TAXlmAq24L7I34nKEBKBwn1yCvQYJt4e7gZ3yXXoCV5FP24v8VgRbjm2BdiPQRUszQcG5x8H ChI0zdQO2ctGg6mkmg7cAQWuTYhFOFvN/novC/eNjXhURfJQIC0GdWZzr8rRD7ROieWebI8g HbAUQvu5utfwxg1G83ezRkM9lQ47mAx3iiaDcROm4TtUj7CGQdlsC7fbL5JeN5K4CSECdVEu W2OYKbIW/A0vCE/Pxu4XFlsvG+6xHXFIDCz9Rdc6CkW8sb+5zQYgJqqtEqEEGegNzAifPbkJ D/hxJX9Sb07G25elmBDLzTJAPilK/H/wGAsZ70MgOxj/OxHh8SljEy22hbz5FhS5QrBFoUn+ hIKqbrb12EejzFxr+0oZ9bayg+rZt/Y9+EW6rVC4ATh5wr8s8i7QubadbqBz+IWw1xyT0WIX b6QqcfIkj/yzx27R4KC7mRKoLQbPb4sVOM0uHboeoXs3Arguzq09fyIG0hu+XYGTa10sc38Z d3fut8UY908MEh0XZrhFvRv72baK9K0bBhIpzBXxJAeE2mcaBw8EM48tHWxzYUNTEUAMPs6l QwVOrVh+PfDOyo4FUxL5IxXDdYzDIHAGq99N4Wl6bosTI1c6Nz0atshD6iGI6M8O/ZeFRkb5 Anb8RCMMGg0M1RD0qYz04Zz5krOxzlm6IWOHCqG0IPiczdjDOvfQIAob+uAqjX2UkBMa3qPq bx0jiLBkcQe8e8S2rb/4b9RdEQ3/KuoicTTRtwJ7O/qxOwsZxhQCBXheWisUezQFIaEqQsG5 Jmo9LgW3ndYZt7tZsvJ7AvrKsB794/fJvcNlm0rOChp1x79HgVkbJdIZbM67SXNWcBL+qcLO 22bLF6AS7C8TEhknnzbdL5wRNPfMydTX7j11B7l7NxDVP8kIuqYfSDkakiNqYrI7aIw9xM5Q qBEo75rqCCyDvRoRpJz7EQB+uoHvS8mGGpdANmhoQD1oqV3aHtBwH5wbOpxGqy079hsMJj72 Cx7JY+53v+8QYkiYtxpJ+o1mkjJriiPfC8hHyREncOoDMuZ2jZIqZ1tgcuTbDCCski1SkEiZ QQ4tzXk4gNEId0sFy2NTxrL1RxgcAovxGSzd+tzI+jsL7uSD6VoUeFbLXgey+bCsufV3Lmgq yFfIkwMuaGfIwwA5cpLIPmJFYvJKXnKEyJbIwMjeQLoH8WyKvxEc5CQfd+jIMmLYyNm8kpfq yCTL1WzJkwOyCMvVbEXLIQeSV33KkMrkySt5VMrOytbKeAEcJaEc9sg4wW7BLB0uyTgb13Vv C0HyRc86VrcoRFkJd+T+gkn5/z4KUP9+8uk2epfyulkOUOItMu8weOdeCQj3DPQFGtp7GxUn M/A7eQv7B3itdXwbMmBkAn8HCdqiyAk+Pf9rgqzO7itvtugJPnOdv9lEahRis70EWlYR/TWj VvDA1LBaVg8EPT8IuTHoQhnKd4cMEe1r7QFDkHsVBnI41RfappNQBR/sCvCIGbN9ybdrDDN+ EdtWJL5hko9GckNuFur/4cFhZco6I+HxuV4gWyviHNVcmAnk8iLiDwQ579YCBu9XCY/+D2vm C1a+JJQyEDLyNd8NmqpHAgVgxl4zyaIhDccjG9lKWHWFBS1OTfbHt9XE9o9QeApO/o2xhVHU sJwVCpx7EEb9nO1vtyWe8wy3CAcb/5zxtwwD0nTN9iucc+oh8gIc8QCiMElvGMtqhh4GbhLf SlTBqtTA1EJ7XkExym6Ay/ZmmgVqkOR8LLoUC5hlW2fUClLP0u5j3+4v8Jx5tyb7BEr7t0k+ Ynatq7s9LrH5/kAkcAVU8Nur7VYeVJxLIDYDGrqmMwuS3BQaTgcYtn31a0yN2xfXHgJCfKvt ezYoo4bXWBICRoh1Ji6boDpinBEDPrMJ29YK+6l5AuRFrdU2c092/Y0TDWIRGnODEwlIudHC bTNLdWTuMAdc9gOxb1KbRg728i1vdnrqDgPmdBLwF2Luet9Wxh4GH16ZoFC2jEuYBJt++gU6 uR7CyKBa2ZI2jFhXAvMXiKC5bBuym+82+AVsqhqtnA2vF7Zz25vFYpf/nwMS/9MNk+4dBoJS 5QUT7rNNgqgLGWov1pLPdw4JFQvWIlpIwkG2JaQ3N9Yl3LlvDOhHEnkQ9hPvZhICgruEFrcd jSXqCUeay1L7+EhW7vCfSy2+BTbN5DTaj1LPu/NS9uZD1LJeEhTR4gShkQ7iXuJsN0g1Jltl X79hhP/RD1eh1p/u+/t5+9R/yUbmu+oi2FHq0AsE3I7+nx3Qj4RO82MG+YT2Et1KNs880AIY +oNfsvE0YyAOO+zFKMVS5OvWEcgSNqofcGbj+lTm2dV0BnjL3EfIjJYb9anAIx7piARbEa6H 3lka7kEMCxRgvmBnEuI7FSHts+mybSj//FIg+CCcPTZra8smcdFDmiS7mVZ8hm8x/WRoI7Aw ePKrzyvTM9NiuHrA6OLjkvhjvl0HdzccehJcOJLLVykY9Ko/Uz9iCtmS1HxJbdEbJalnUY3R CfXaM2TmsIo/llKpYx3ksD6owtF0k/E7or3TRZDvOfVNsvyzFB89SMgbcSmxKWx/BpzFOQmt kkLx+jcHIZ8Lweo6BtImwemj38kPy4vUWP1zHtIy1NPSx25QqeW5IIzTFelx3VL/xyISQ3GC 7vmC6qnp02Zgeie/k9KtunnTlXvZddNNCQ2Xkib/JB8SB55V6v/pMywS330f9pINDaovtY8m CsZzQhjAXcLfAg1yAAtf3dKHnA0hnnGR0rHe+DGsnZz/tcj2uEDPWrYTz6pTKxrEVrgG75MR TXNcqeS46u7eIUwfqO0uY+8RBcgSFRvqElUJvakvhHi2/93yaN2bMqmXuJX7kJ4SDh3wdYzb /45jLV7wLfv1oQk3p5HLQnw0X9IR0BwkMGMQeMAa3cdni9EyYRmSymMkcyAH9jIStQy4z/wJ jjkHTJEKge1ZkmPPNNi3ngSaJlYwBznsJbh4Y2BaqXuetkcOGxoOryaQ/FSPi4wc5tOhxBZN 2QifeRYSPge2gB6UkpFBuhdazhKW5NtkcsQaEnPdDJniHMiKmZct2Za8DBIS4Bn3NN9es0v6 kCMMHhL13J461ocaV9BfHEoSJgi3PeBS6UTDaBI3Y2PcF68cj6oTZxI05yzdO2s3DhdBLVqe t+mSnN0TlZLPoX8uvDENOizu/xzI9XghlMDPsfoPDx+qiIcxNbYYt7uJ36MKJkP7ekbAPbgK JpWTEvZOup8Hwd/H/+ZyCQ7NRjlhB1GKvtP8Jrz3E7OKTe7yAISznbsTZW6RiOAus3eTR5rf Hi4Ieu6I7eTs8pKpwQoRnha0NkjXvOwOt9rg9iLnkG1zzxHhENLF3iGcs/CkwKaj0Xw/1MNO kt7T6JKmIqLnPsNgFeqoBxwdJd4J29gKBx4I3vY0BzJGHxs3PN67OQIqNuQIN4IRVkJVHnw2 N1FyGi/9GPsc4yxkxjYmIqopHm4qHi6TnS0MIjTZE/sQDfGNx8k6EfmROYF3S4ePrO8EHXEK QcCsgbwQormdQ9k5CPE5s97CqZjA39lDiPPpw6CmHjnuBtsc7xE+DMpeklb3w+DmukHYFpih pFztfhVq2WFZZhgmjBneYbDZK+3h/vuogzoHD3v2sg7o3h3MVLsUqGQ2H7cy27/7ziKlJEsT /gR7gvvXj4rTtW79no7zunqCJo8Kq2/7jX323B6WLEcSO9nWlO6HpQ/wj+1u2YuSAWIfvsve 1zRiwSqGYbUg+gM2csBAoNjcI9F2r2QjkCcTsLresrlzJBu32B18AljcdX/7OZIq/ZoFGREc Ofdz4cDJ+pJ+gvoF/XjZ7msYugX6EKTZiY/hSxQihw+ym3b2eC8Wdgb+cfTiFFH2bTE+cc8k Cd8M5nuZ2zkorgAR6DIN1EOobzn6jQ4ElNl4Y9p/CD4CdcnGOM0Y+45UdQUjEs8KJIk4fbgW 2+Y12HeQYaD4AZisWlq3evzc4J5t6pLudEQOvnsBsX17P0uM/UMGLXExGctFq9W/X7Dnen2B 2OSE5NEiDnWydRLoGar25ui32y3/jvgyEUZmfyH1bjpsWwRpEe6vIWfiO4AL8tyln1W+XeLk 38pQ7sISj/hJ+yL1ks1dIl5IVigAO/DBvzolYeV32OGORl9iDh/yHw1lvkNZK4jB/6sfLmxC AZ0oGiTukPC4VyzNN4mYf70A7B1mvjG6eP41eB71m2/2GnN6hwTaj/G+A+0apyHVENeOoKlZ 9LoNegUCMtuES678huCk2/SvmiOXLhdBZgqyGgqCWxmA+M23twie4AZsA47/hxHlDvDvS9AC BhQR3xH1piv2zspGB0PuzkRV0Mx2di7aWfIKOXGw1hDqC+V2bH8JSHIhJaD8cYz+fD4LFrAA Kwjcptj9mjtNQZ9sX+VWAQUt0sPuKSERnGum2imARIdsha5MDYi87NmpsoPqJSjX2u634aY/ 0Gtx74J5ewAOL4npI95xpI5GrHlG5Fn8qxLwM7CwoatA8cjxJXi0hF6vQZKmvkRoAxrxKeWs KEKfYuMLuv7+mO60dUUGy95UnZEtlgFpb/J6pJ7ENOQ0z/4s8pL0Vt8TDTgnp+k+h9ZVs+oK Ae7shrI3Uk22bh/PuhnqusKh03EWaaz8rnsnF8JN5VUHS5VkoEQfoWkTrUUjhFACJyRaUwU6 F6V5Ijf2WECyjD6IFg9l6/TvEtTQ7HmRBv0nfRA9QJZLRZnkNirIBoteh//n2beD3Rbq5DFa LCdVQcj+1s39cv2Sad4RDiZlyTmxgxShW+ODSa6qrTQFz4NsuYeWAvA+bG48y5bp3H+EmgaF XPJUeAhmM1qEZ5znaMSzPspmrRJ6+3UOUmlS/2t3AZLMV25CAfkgtuM1B6TYWG27G0d17s+O bYzzCPGI/xNEPFP6GWSwWAtYZ1husSQHCRomW0wEjWBuQh8gFBzdbB13BcH/8hmOXZp6x2BF 6LDN/g3BIcvdbncNnwySwVUaE/RCNs4JQ/7HLgfrMKsVxCQ8/zwR2f////+elZTdjtqfjJ+U 2o6Ig9rA19OH8RTzc50x7lxyH6pPTP////8fVntmh5m6yhdKMbyvgvTG5UDeAVbwoEFa26+0 UN9ahv////+cT94VRUojtWLDt1un1/7kSYUuDyVQxK1/NQ7NaZXTX/8N/v/BpUCD7TMhtvox NaR7FEpMb4nKFslJH5b/////F39Xz8Py0NLL1udnn+g8nsCvX+vEkOsTIWQq7sBDCfb4//+l 5hbpVOm59bLplvjkovQ+8dELDX1QIzX///+lnHXpLrw5e/xwKx8pekPpgxgrypEmGmG8bxL/ //+/lMNDr6Katk7jW3SecH9StUEWOSRkbN38v9Hf6OsHKuNzyZNDbystOS55kf//f6GSnJAt VINXIjp4Ja5Pc+u0wwbevewEOBr//y3+jBZmNUXBrs8hYFxMA/JuQJ7Cn8XevKO1/////1yx rnxuGmvfAiIYHqZosvcbHydQS2l2aPTNFeGRMNDg/////wMkZ2U8ppWk1HbsvBxDwjLE8GxS zmrrQfKz6HIdVV+gv8H//2nUFS6onGg1J065HThwRT542A0UKNogxf////85PWOvinAGguTz XRMAt67wlCxvhlNJqEKBZao9hXSYtP/////pYdFGaXrsdfixTeA2CWp0PzrXW+KQ1obFrLM9 kQk8W/////+XF9HkdergvVjZzi3FGYHUxHd74F6mPjSQuH9Php2+lf//jf/e9acp6sZX94t+ ukKabp/5BwyWq8fVpU/DOP//G/01pQM77DMsyJxcVPOArio+mLtrOalhZKT/2///sMAIxH4T vXDV9lYySEPyV6LshjCFITpFSZ2eLf////+axR5qgkP9/SfWB8XAQUSDK7x8GVw65mI0ZGRR +TKvaP//1v8yT91nMvkemxpWfWic7v2DipG5MjVPeuvMyP+X/v+2pa5M9/1z/4E9G+lm1/PM H9jNxj9qAxq2ov////87MfJButxb4PwhP1kfuN/lHbfBlzNu5++aGyoWNuYAwcHb//9SH40d BcBx0+6xUb0uVlGqckNKecuT////vxHxLWcvhipmTr2ipYyGt1hguHdFtWMOFUcZKNEUr+r/ //9RVaQkHfxYsu+7BtAV99mas6lMZbSKBqY5Mzv//y/Qg6UrVQItmxfazYHgNcw+UZ+JOglS agcj+HIDL/X5fe7gB0VufTagZs3jZnlHB8t8H9NuE9mFruMlCTgGDqWkXfUDD3akBf9YABKQ JliYANNm+9dcAXwj0Q39Fxjyvdn5+t8jIhAGESp3/UtsCnfyesS5j+B6hKLunHkawRaAhH73 RTJ73xeGhsjyDZ6QUxnM3qbqBfd7k6Ms4gg8krL4ApniN+KDFe8CEFPvIly6usgPbhSVj+8x v+Itz5qAhE0m0nE2twzsE3rq+1n2ilniA4ccIxvx4haqFUfi2PbdAS3fDvjN3W/UMgyvnDu3 DPIKAvv6Agpmk4LykS0cwANFjU3i1vwGbyKwLUrUBqJxJdEgesth/wtm1I/7sXOnCquoNvsK bUjBIKPcH7A/i2YRPaN/M49CMJvk2QWFFPUU+B2QQgZkFPt3n6WW84yGQ89pfDerwAmYQUfi i/awuPQd+rdOIBHZsIszQ09HBowm7YI3OVbtGyAWkTh7s7VTavZ8m24Wi+5MFzpbETGEPsJ8 PE3s+GokfmN0PA4ylhpzIK6+YAOWwQZWeYCxR7R2EZc3QLFBtpN/0Z73VsNuG6sLyT3sEvAZ 2wmyzahTqLUQGCIMMyrC/DYUb8fKVlJH5t7FYVasR9HRht35CtqsqO6L3LvFpBHa8B/+lj9t C/8L6+r5AqMZ+QYJXvFQPVBtQ6hLpXE8iWzUHlLvBj/qPJIeawWv+coP85TBQ0SiLXGiIUmH wQj/sAj9onR+nO9nDvl3oOatPODj7CMFBcJ5vp0Xxe8UBrM422aYdKl4NscG0LT8qy/d/PIE +A28+PVSifVNpMXTrlCclgKsC7B6tBV3UwpXx2v7ltuTwxqVqhvUqlfjnEJhrNFXoH8j/IMe f2Sy7RHTEJwn/JygnMGvCECulWpfEwUZTz50187IorGPSt9t7nXu4kA6FbL1Bl+J0tkqYdb2 CPtysYvTecfBSBIckowVHMaeMYhzvohfpBagzwzfB8WyupMzRyCiSA7IjwnktNYikPno6mS8 Ja75iCwC3iFgVLIPjx+yggibG9X3iIO0GYtwNumHkcND43hCF5ZK17AJP8/4ESzgK/n1aXef Obt1XAgZ76yizMfIyEMX3oXKUH/4LCp7PPz5AvGxMawSte64+RLOKV0DYThmFJT7C1DiE3U/ /0JCBqxKGuntNfO9xAo1ihVyOciAvdNDgtlo+3TB8zwvBM+FjDy5xWYfJXRADEIc6TLIyQsa C7Vo5HOPXcYS9pI3OJSxGbIBucBuUXTnJScHB/q6EPqSkxzk8pIkA+gS6JNnh+S4xgvmUfrJ pznJFAdi+hdd6Fkv5MgXBegDCpg/Nn6+PlXJz86bp7wbL5oVOB9KApoxa4EYhzBMwYz79hMc GwqYU+iH3BE1W4Z8Jwdn6pqpVqhBDSnKhrDupF95Dy7knesvHw+1MVnFcT3YqR5zsXoCXe26 vpzo9wzE6cblupBKBoWUgfv4vbkcv/tN50nM1nUYpKne6hNfnR47lgvq0gPqrB/6S7AB7cAr c+AR/atx3VLwl2Kj8qNz46LEqiUpsUI4NnP55KuY1ypa8O51uf6FFFpGABONa0U73+25F+4p WZdKWD3/xwUACRJud5C7QfAERb8NRaptbbpVhwZRIAjeFKDSED+JtP1/PwM8QxI3nbH+8TOO mwXLdZZl2Xbsi/4FAvYO8sIM5u6EqxLHIy6UE05E2ckXv5uJfzYMVPwGj/m1hRH/1/BOGOpb 7wdr9wep+BtsEfFD0BTx9XV0KyyLmoz/vpbsr2UmzKTf8Ijw6Pc1G7Ub/t8Q/+ZyEa+GWeEa VqJfu6/iSgigqIB3uWaAhdaFv1Cc6EMqBhg4ecEDjqx7BtxdWbqNI/SQ+XkFjxcddvUxCvv/ 7b+ZcSS0tEv7B8FNiM5WxsqI/sbDjN7Guwdv3Gi+oIzmxpuAk8bUb8aljrZwC/j2xteO8vLx 8Ez9OEPAUPy5cDIRPbOHEciufU0GTEuJyQSsK83w/EoySeJG8UJ+0b/yW4bzAD0wrKBg8lsk OPJa1Ff1sP/jyZqicwksjVH/MBMi8gRL+mGA4UETmHPc/Px2+NYKAqkC9XlZ5x57hw7q3TMs RB1B9F57LzFxDN4GBsi6j4SjNgTiP3g4N/XqrTLRMXsD4b3wH0+keQP/jKMJCXdHbsPewm1i Vuz9UDg1LRgIAa34Jt7xKI7DqBsm21r3xZFdoK4y3BLzsSt9gjytqGkI2SKQ+4M1QfAaBa/q pBOuFTSnSliYRPvJkZOHGPag3PcBeU7IuDr21uohHs+u9+hgXjr53JZ7/HYVVoIvN4qbDTyW A5Jy6QaLSm4sx6puE1z/jwo8wK1FxsaqgQIRrVn0U/0GhDiYAdV/JTuBYhGjFo874XXfM5AS Eg/wWKqZq8yAaL/YbBMN8ep6wqFP193vgPteEQo02gzwIuiX5FqVrnitkhIH3+wTPnK2JUUz YabZNNAE6GDhQPZH+03YY7tx8fq1KiPo9riwBbct7MtF9y0ke4HIb6j25/exor66ytmvYRiw SpVAL6WQCMfiMgLE+xA38absAuC+KahbW9dhOMgGYOzRlgL1yvGLeOkxZMUaPP798bWXCrx3 qNacclGTnHsFFX/muwaYqCwJG+gN+MwIFsgQ3KZnqwvuJ/n2upI+YjyI9tcIrhvs0W5GNqIe Ssz8YsQ8Or+2BRSA24pHpZ+ZKHOfoIMVZPB8f5AZDxR1T+Z4IAQHpcR+j5Kyh+s18MZoM4oj uaPx3TaB8KSDKRxI8LagYYfQrDZvOduO3BEOEq8PnXrE3ubrgNwGi88NfPwK3shtbnFGBfJc YrwRJdEzqvlSpaQF3gWFseryDSr08B4bANfe9MoSZxMK8xIe8xcV5pDLvu9MIwby+14dkAx8 8MFWqjv/gR8bcQsNImNDxscDfyiH+A0rGp7bIKhB/GQbdfDqHbZt/HqHG8rvPBHRSsHcgt6B +kp4q1IzcfmONXPpCkYzu0rIBZo46SW9UvDNaEqow2pC8CahOPr+XHAw4utk2hIN83rWwEEN WRbmb4wC5fgz6Og1xhPgo0EprA5NHaKFWs4BMo148VHNHyQc8E6oAa503noxsaH42Q3iER8S ktlYuuc0v7tlWmKnOZLOD91YcjnS7I4EXx8ZXoIlXjzdkaehkilaP1eiuc/3jK3CH7ISYQWe 5/lKDgRLRj0oOMZj8B6Gktq0NaXyged7vZlGDasKfll3Y0BVIw1CNlZMwo3D+NMSjwXwqj41 8qK5p7YqLl1Sn4wzgzWzCmbvDHUnsjMGb/9RtfZ32dizcx39TpJrMIZSWNcyinMDqZqGIMR6 TP0Ecmh/a6JcVBfyBNqO+b0RCQi7p+1w5TwiqFrbSHLlhlCBZ9DzlhHJwwR6gaH9A7HHYIc6 HJL19awTjHoxGoynOWkLztwPGL16+tJYlHtngG8jf7rrumt5qvVMOkkVoHL48aMNi3HDwfXy IB5NjIzNu7rSS5Tvd0djh/bN9fjwr+tubgTKiMON/9IR3B4mg14WuGVtZsYFzPsOzaf+Y/y6 tmR2GvGdkQGExkSL+4Qw9QaBFMoSLTMrpUdk5NqoQ1pDuiNLsZiwPA3ukGdkkKG01PALNuvm xQVPsucw4bZ6D+9PlzhPhX4G2OThwyYSfvxcAjnO0swwAl88lEvkbFbPKqX8mTixC9jTIZKV FNcdEbojeBYcce8jeTj8rMERNFSpbKi6bFgXMQER5BW22YKbKakOvl0kkJIB+W2ShGA2/4R2 NhhSK4JbbqORDRtPB2w5ycNeIOvqZYn/2AI77NL5/+sTsrOZLUWeBZoYYpD9xcySlloTmKF+ 0ZoMz4pjBjwvOSyMVhz+5kaGkoMo/qaimeRhSVG9Wm4WQgYZ9noe7MxQz74/JilACmCekWe6 VcZe5UaZWl0WyyZcMMp9UfD5Fs9BvAUZEyRXXbp1INyQnU+E3s9l5ntaB2Qj+GsLO8ghboD+ YrtLZ61RAmMi7JJbiZLp+Tq2cATtPjYiDkOjfJ7n9E+GBTmPcpGlXA9Xjmsb2V4rGhAWW94I lpFlZF/hU+hXq8RZRvNLJRjiUjioOS6YYjjwfm32gwxJOhLfVZhEtFN/EgzuAb7Wlhs7oArS DWtwZntS8w4Iy+9swPkLhbkOd4cSQ/I+HICzTB6eHxqqe5B7gurqUxKvkYux3oifiq6eaopM E1WYK4ZRHfX5BCHSJNKINnAt96P7UdpPoQ4jsNlt4wsEqSDyJ63/4NnBFnstzYo2GZ/tlqXQ cAAADQoBSW4gf7D//2EgZGlmZmljdWx0IHdvcmxkFW5hbWVsZb/dXPtzcyB0aQgTHGFuIXRv IHN1/m9/93J2aXYSU28sIHlvdRhpbGwgYmUgbWlut/bb7xUtLSBCYWc5IEF1dGhPIjI5Ybdv 7i4wNAIJR2VybUR5Ln1v/7fvagAB6I5AkKNsmUAAaA84BP81BN/tGt9wQBQhigU2bAQWsZBq ZNr+/3cHQW7r8cnDVYvsV/91CF/rCEf2CIDtbv+XswU7fQx181/JwghCa09HABD7IN+PQUAo aJOoDnCBBXFQHm7t/2UAAOmV/u//zP8l7GAPBShhGRkZeSQgHBgZGRkZFBAMCPIcGRkEAPxg +DIyMjL08OjkMjIyMuCcVFgyMjIyXGBkaDIyMjJscHR4OTYyMnyAhL+IYJ7P5/OMYJBglGCY YCz5fD5HoGCkYKhgrGDIyMjzsGC0uLzIyMjIwMTIzMnIyMjQ1NjcfD6f32GJcGFsYWhhZGHI 2OT5qGGkBZzIyMjItJSQjMjIyMiYsLisyMjIyLw4NEDhyMjIRFBITGHZZGRk5HiEfIAyMjLC lxQQCOQ7YTIM2WAFIGRkZGQkKCwwZGRkZDQ4PEBhZmRkREhMAAIkVEEimqmi+h3D/vbfPhAE jE/Lw8/UAcvPzNTI+gBt////qbW8rq27qL+mrpOXn/qeiIyenpaW1J+CC6bZ//+BDLWvrqq1 qa7Uv6K/+rS3u7O0Cf7/3/61qK61tKUNrr+otL+upam/ua+lydTKpc7Kzd++bc8gqrwKpWCl w8KlJKW3v6Vrt23YyLEYDKkvtL05EPnPbgeotUW5rgypubK/vsnIdmtnP66svrcJrKgYy8wM tfb/NrE4s7XXraiq187Iy9dICr257oOUsbO2tky5Xl+ur6q3mTu2L8sXtr4VCRy7tifkD3Ov DLG+ta20yMp9LDZrABBCCrm2v7sj/D+2pbkLu6yKiJWOn5mOw4IeudjCWfu3vai+sx4otxPK peRk7Ta558OiTQy0rg/7NpusBmy4y8LLC66+z27t2a23pLO5vnmqtKW+vwuDtYW8pa78DKqO oy8b1mYKUgepvqhCYVZwK9iNGVOfObZyv5+yAb+iq68cWMAKTBglrL+d3ZJnqr4Xohaus6yz qC3Yh/Cvqde5Ory7qQgXsDArtL9ydgxErTicNYLMHhGqnFkLttAGsLsioAeSsM3aqWJpz7WE 5MDe/hXPycpbuKO4EK1g24Mlo724t+GvCmXdYI2ig73cvgnWyhG2Wr3esruFBIZ9CY06LLKu th0rNE7Ytr96u+F5CnZ4WwA1qK+cNMPkZO+7voIMtK79QrJDsAm/I8x2MgoDs8tgs6qfjC1M tjGoIKlqsDMUZq3VE8iCBGHGbFgNDOcDw0yldrazC19EEBuTlrmq2RAiGdcuaUlLIMkhOrbt 2e1IuIi9yAmpy6LbDsYZlL7+vL0moAoLVioEC5IzDFuWhPavvojHohtpoR3GK7ScSK3S2w5b DruiCanhuAstCZMNILkgCouQbGtDIs5evxlGw8k6viK/tXWzb5tbghtzVAxAvB7D3LC1CycK 6unr37ASDqqjsq/J141CsJZsyBRJv5qvbJeE/Quvt/y2r5sO4bW5hiSsvXuprKzdnmYMPte7 tbAID9iwSCleDQha4S07qrPZDvK1DWHJzfUMxb667jKGdRy1Cf27YdmSNezPz78YQi6s2DfY liK2DL22wwwDz3A9qaO0zga+pUrXQWpNvLMuvLizjK1u2TAJ7g2q4C2BwmUJv+88ljUN1hKp CLaDvgrhg8HYzr96tYe080ArLzmttK2nw2gOgk6CjlJs1gsGkyp7Ess4MJezFaqtwG6Qbwq0 s6KxrCeio9FmtYcyv7irlr37n6z9fsipwwMPsaXNzKXLzsnMEWWDPQ6zcgy+6GCHB7YMvAmz jQ/ZN1hYHMsdy82lyg+s1jSwO5epKIWaDfYUy7yQvIhlbpJo8a58qljXW5g9tge9zwxYrhcs c8sOteMLIjUOFEy5xqN1McHkgm5CuloLuAc3+omDidoXdrlEsKZgIau1qrYstfZgomhGL6zK FElv2BtXC13l0DgYtHemrb1LLkbhIBGtsqiPuYbkTLO3gv+B04ywrdEKhOC/LJkYQnMie1U4 q7UlnAeoEgt+4o6H9VkKqbi9k62jsEwY3BpUp7GptqK5g1QwZO8qoLu/hQYRhgmgfrTLOrVg EA2O32nZLGawHwkVImVx2QvJQiQSGMgyvnArCAVKk6SyMDZpEFq/TqvPGMOFgHSrlhGswitt bRg0pBXzPr4EhvWGtAy/uDawLgaoB68KLkKNZR2oW52j2LYQhDvzrCS0iVaBRivDfkdnZiqU CKjwWQsRZrN3uJYKQlk2gQmLpTClARpnr0JrQuxHEbyDmRqzuQfoF5Cpkgy8YGaKwPWtIGff E7Q3t8dwuBmzswiMB04SDtbNoDqiCanJEGZswVpLZIm8Snu0ZAfkXxXt0hWI9GTPo7dq8HVL 1oJuCUiTqbEkBeybLQuvCpAy2GCN2wa7B7cvK3VrHsjXPAu0rrbQ7CHXyQmFsYGbLVBg90S4 CXcmHVhX57QLordb8uws/a5+qLALdTNIloeWKqodKFSYYs1An9wSao0MrA0HDBjWgjl2Cswh qy1r5G/1C0rGyJasMBljC7wPXj8I97e+8GVmak9Ilqy0top8DGjBnGk8CwwLGjmCtb4JDy9y zHLBC7fvk6xVKjkaVNVTMhqsiRZzoqgLsjBgg0UWDLOOqRbDuiRjCrUJCsSykW/fqb8Mx+wF zK0Nxw6lKwizW75BwsMMEscPpmEUkRuDokazVhZNW0mwJjVWzaeA3tkaI7BHszocXVkskka3 kIBceLP5CjS9ySk3a62nQQhIKxgGJg63kzkcjVlbULxkwRkPzQ4N1pMjqXic4sNawQwIcwyv ysnCQ6hVAtL2wsq0OOmCwKNdrqmgMzEE/gy3yMx4+A/b/8hWfbf6ko6OisDV1Y0A1AN74f+J ipOfnZ+W1J6f1SOKkoobE9i//Zafk4qAkx2I15efiYmfI5dg/wX2lZiTlhqUn5yViJebW8hP YF+bjJJPnZWfjpKBtd8WE52Ij4OOjqz7h7AykqKbj46ViZmVBa21BHbIzh9U3DsT2N23mUDX mJWOB5ucjieYhG8L7JeYnBiSlpOUmwYrXGghTwOUlEJbK2uFQg1tA1xrJ7D/qYqbmZ+Zlo+Y P5yIHQ629iFs17yWlYyfPiKeRbuFEDOVlJXW9g0hvI+Sk5FUj/OWovDuBcKePJnXHpSTjoC2 0T6Ad5uYm5E4Q45/sMIJ5JSbn5dZd6G9wC6Nb5OcFY1tO4RwnZRomZGGiZH+C6xtz45ZWIqI k9eNldfyU8IbdZiPiJ0UjJOIjo/aLYTxgJWUz+mJjwSMCS8QiY/X6u4tgbULm3AYqtJ2gW20 llGNGI4Gu22NECob11OOk6ntbQhpiV6AHpGVlwbUcAxhdZnKeKXCLoTbDteIaRVGW2CNiHqa 5jyBFRbYmZygcjZlC21M7ZcakKWBNdzGk/2M06zKNmE7YXiIzNfhKi2sBPeXgpLZvdCCwhCC K0bUNNf1UjtlpmwcyY7qJVbWFtqV0WyZVjiwLZQaCI5DMZ4/loUDCK2pQBLIjw0LhG1rlxyd zIz/AJieCrCo1ycCo1Bqmm259zfHBPKcnZFWNJ+UMjRGCIt7XQjrkcJg6vsIIYxCDx7cViq0 Qg93Ar3KCu4RlZkeRlMuS6XbhIieW7mViI/ThxZAFNnXlbhcILU2q5WxfJFcxwYJJkePlB9X 1goXCJ2TZgrznoC1tY6T99SjxolbGjhTKUlTidIIIZUFj5Iap1YrUL6IW0U9CyEMGrZu6Y8o XGAbCpOjlnVjhLSZM2Ode2sp2QyulCHV55cN10rgl5KM7LialWDoTEj+iAQdtNq2xYkVwvWM s9qBAdYKHyO342GiiZKIJonYbMPElWiOySyDNyhRagEVmiNGCMtQcvls7wjpwvaA15EllpmP kptmWiBxnpnwlHKwwJa2YY7ymCDV9NGOqNeKe1zXZZ+W2xqFF3aNN1+mBRKNG//3jG2BtZ5k 2JuUC0IIC8czPU1cgyTajvtcVbBZtw2znGaXniOl0lbgLWYhGZTMEwbaBJygPIo1NRyFuwJk b4mFUmmQdABLtGwbwkzNJNdmnYej0EoppUORpkIjhITU4hFbYCa+h5YPRetCYqFpgMuJGI9m tuSisW+WJ4zHBU6FBe6njV8g4Ao9KLeZk5nEBJKhjB9hlWi2MITEkF2b46W2vEBun4KOcin+ S7Za6qaD+t+JxYrH32i8tYWl3PcGifq7TrbRZlrW+jGk1RmKCW4HWwoknAmQir76nZxtXdtG ijHfliq9C6nGVrIfaY+KDkeOfNpvY+yNlA+9SbM8v5R7CWypGeQcVp8Y3VihYxS2lfUVvOyp +VgDB+IHF6mbjJ8GnrUerpW8NEC+k1O5Am6ziRbKt6CcBSYKswP4YML+sgiHB062N9v6ANjb 5Rcjqr+2+z0XO2oy95v9f/oa+vTb8fv/9vr8WADq6wSz7826A9oOCxv+Hm627GQH+sozBigZ Szaw6gcGDO7sfCOsxqAC2gCJRfYqiuo3NX3BvpZm6/+QrPi2LdeUehpSc5kQ0jslnE0j/ke4 +gCaGocoppl64pjZYOArpJVaC6rq7pInLybqkuoAD2Y5ZZNyA2rqZECebZpWPirqHxDqw0HH L+P6uZadsqCvfxQcrcgNy2q8u/qexpKDjvv8rfckicXSty62GJkfgxb6Q/itgbVG7rMk+in4 zsgzKkED0BexTrYsbdtSe3P62WCfCL/nmTZ7hCtnTewcvsD/Cliah/b7j7xq6XjjU2SSGrfq EmGzkgHP3tkOYscK3/rfJKBP8uJq5RSSYVG9ufcpCxKN+l+CnqSqUckharlREJJNvM76iDZE PdpE4FdoZhPRMVSorNrZ+vcDxPMGEvP6pFAF34plRkZGNgWOgoZ6HIBhRnLn+v///4Pay9DL 1cvAy7XLrstAyzrLPMs2yyjLIsv6OwoVZQAG2px5bAlMOEfWCI6CjqVtg22dBpRCnwiKSNjb e7WSBesbCZP38Azt6yV+2sfa2K+Jpcg62Bef5Ia1qTNJGre1mJBVaulNpdLYqZmgikxnJ3gy paSpsxvYDebcstM5ejlD1Oqyz51Brm0z0oOuClgwZ7Y1ozGfe93nHSq0FdK4JN6bwBIlbgab x6Prg2w3U66EEmjGx8rUlTTWmWv3DXfUQdLLXPcvK4jSm9KT09MnlHAfXbCzWJVPgAYHudu2 rQSRs7xRqKue3uTsvZ2My9YPTg/I2QYzcLuKWiHJN5mCq6sWNOKfkEq0nCtHiV4V58gILSI4 3U2V7/A6LBWJz0Aq3rI7ai9/lNrSSBmLFu7DKouPk8y4YrW/bG/WBAOWxrKut7bEFYE36LwH v7u+47a/xGB/s90H2q+KnnPG1RUmrrvAv1UPwLuqOq7H2rO+x9hYiwbsq9jaErRoE2wFloAB vnwKlF77sEJbDamuo0cS3tuaKwgUMaoyEAbQvdYMPwkUtTn9Zy7goq6LGLe7orO3s6AMNOxW VK6uLEAatMDIE8y1Mka9t4sguLt3EuRo9he1cMq0ub8TFXOXtU1brJOBFQLXSngNPjpbCToH nSuXgQOAJdr+bbvV+Km5qLOs2kE7Y7dQtr0erLjQ2B2Q/kG6t4O8DIucltSMmIkK9wZIeryp tQauNTvJmI2M/mb8Cqk9difUjbJ2wcJu7Tbq3NqmiZacRsbWBlLWyhSRQoOkEDbYLexCWRtk 5udQCmGDsANKrBG2yhg5LdiyQlgbQiARNrBCVyIKYSGsbC5ZrFD2gUmWzQgbZAOAGxwhbEHW 1UysMgJY6l6EBEIJAAGWEEhhVBd1gUAKWy8tbZc0sCKZtMWSGi7kzO8SvL5TrYbNYtSRZSAN TqCVkiJnwalZ7mFDKdSoq0mggGkhZMrSLXvNKvB5iIaQph+FCDzEjakbA9Ih8IK10yAWK9K+ EIjA1eP3+vu51minpV3dbj7u5G3VoP2Tn42fiAg2p5O1RmvNoxNX0caOEQuNIz/6v/bp24Nv 7WTht5NmcJWcjqYp2la0B6a5jyIJrEVqVq4hl6bCSW0m6MZT1JX6swSAWpm3t5361xOSjpt5 mOQpjFzAY7qz1hqGjhaUTj4xiv9GBbqrz7CY+Pn+//z98tKCqVJgx4ff5TCXrLki8Q1xDTkH YR6ViJ2vBrf9wlaXtryotbfAxhrEFxrWwMC53ksOwz64pdC7Biu6l+2u3h6l+vz7lpzXiUEY uURr024k+o/6FqI5WE+D6RtIiSsUytEF8gbnK/QGuZZ+He2e15mK1uAaDBvkigXsbahm7gWO noMHPAelQmGRgh9we2agNln6dIlgACLbFiy0e6f6q4JjiYrmbtCe+iGPggVd0MagZt9waJku G+Rau3eSlbRcBLybVNulaIAi15shugfHl8C28JabmPo2iWvNGW6VlZ3eDavNHN1aM3CXiix/ wlL6imutba0711abvwuUGpq7bVsQnTC6R4rUrFLWgkbbKYN8LfSmGNrW3JXmooiXvaZc3cI3 tab60NTQ3Y1p1KKbdZwX8ZeJnQCJBQTNmHn7gpeWHp6YggSen1zeNn8TlJmSl5w8lZ6JmZxc O8TBGHkEIbFfwRV2ISdemJhUu/bBdU6WKzDUj881nZNtbuxzRBiecpBAyJIahifD573atZwx 47Rg2gqiyZ2ukSxGw7ZqrduR49u4KbX3IbQRoqrWCwa54ieHL43asZ+DEzbMpew1Xy0mNa3Q DmwtqhlPERTKrbWJCwQKm5Z4aKVXLlXamQqWSBVdl12329sq2jefaJ0MtP6b01hli3iHjnuJ aCW8bTK0kx0HMo6Rg6xVMQqeOtgXttDaWUWKmA4MkhjDYq2JSoIAOuUZHfGoqQhc2t05OGai 6iG7kg8rYFtr71dBzTKwS4XcdraV3ZJZ6YKbXKxiaw0lke2Cou2s2w7CMY3DogDa7CnK5h1c iBuJR8GW3Ti7ftrMKRHRhAnuz9qqbDA+6LbNgpaPfJhHqpKgra0ZDwQtw7CPGiy0E2i3IxiC lGWqhQ54jEuPOthuTa0+pDGS4I+YD44KDWLm7ER2Uqh9O9Y7DPqeAN3W3doFxq3m1mUA2oPa Q7LAj9g2ttLAPgnfKpMDyA5c3dZbCr6EwFk/zGrQtpUH2AgvPQGXMFOBEG70LXXS2Sy3htc7 wNioUeweIMuT11aOWhA8FYxX1rpvLV4C166DimWX1bDt1uqiKdUbpJ7BH1aoVrDaAD8EGJoL ttGDktcAdx5G9oa5vA8RT4bGpodG1ReWwWmO0Wo0E2w/HyYAAWu0UJMdLHjFBi3KifXXalJZ 4ebAOc2YOF4G2qHWEVeAVHjs7SB7j1GYdZ/MziIitFixnWULdFRrFGNOoWXBJiywGItVS1Fg KvsUxJubTtYaX6sDuF7V1RgXhC070IktsbBgbxASlfoEnuDPfW0DEdQZA8aYiO/Bh/d+CZ3E xh4R2WuxEsYJBhbkaKWt0sY+UImoXcRgJ1y0nsASxECq7Nihy8tznooM2tcJDWOzNxYNAKgS ty6+CbSJSNINsoRq7NKxlQmjm1OV2wquAWssNf95g2wOQYfZblTA0w2/Tdoxq8aCXh6+GQN7 mTC4hPgdW3LIZBS3v4yDQ8PeEBxc2O4gxFqZBrf6uX49XA1eOYsuwVaoQukNpQYwamq1ZE+8 m4JEds8tFlTo6p4BbQmjlbllkWsV2h6dNZrBEXupGhylCMNlIv8OjA37lnSKMp7sANpzdTY7 mwUQ1H4E7mcDV7Hik4yCngRDG1aYk3YqtrRaLLpy2ldtcuCCbHSRiU6JZdghbA+YkxCKwoqz hlvWcNSNnxcjGdQGsEFrigYLsENdDonwcCEAdhlH12y6BbZsgzOviaQ0OnhkgDc1l5kpm7AP mNRFu5iTLaNhj61fnITwAghLtiP3Sq4ds4gr+ZZCHJwCQp4eCMbknqHXohstGnMAO+zRN43C hsBlIRE2G7vrM34iC4QtLFjSA5jUZoJiDww1cb7Hk1IpihyQjKXiDqnrltTd3zH6/KU3MROH DTa33xyhsHBI46MxpRwhXFloYKVOjVSlM5TcW5SyuZyltv/SBRhwHceOF4xTbWux+fpPE4kh FZrqTliDX7uWLKVenlwl3K5OsJUpfByDaG6mAl+JpZScNUzdnH9mj5yAAW0ErZ16mwfFj5Nr jtzXHZ4RiETvrMVs37OYDmupl1Ozhp9MMDR8hKUPpese1jLVWiTd3iyCNlhwjoKMC4xNk7tt MYtAipCBjq4+c2CYrJQhiSAX5HJzb0RIu5mW1R6Pityhtk2sGI8XJDKMXcwVUrk+aI6pvF+1 ihBDF/2Wp1rAYGio72hEwRy5qfReObXaIoWkN5JwqG2xyqd3WrQCH2yD+I6qJ5c2t4+igq0D 8W8Brr+0o7GpvnFWG7UYzbuJvNNoyan/HbRGSBTr+t2+3Yjdld2K7/6FdgGf3Sqp3ZHdg920 C47d+qVNs/3215W1m0mG19Gp0QORg7T929I0n46GZbG1ldel+qEx4lLOT4imgKcdP2twtImD akWXabCRlqnN0jVTl1IA18SvP2OvmcYKEWmnqdeR3PkW+teD17TXUI5dodCqkeGO9az6oNKL gKOw1IXtuYGuUoPAbz76w6Kyju76GGpDW0hxig+m2rzVhNY2U40HCFw91hjM+geuJ1Kzuatg o1vWtvpDDb42sIdtbK1qKciV+kGpJRehq4xpib7gDt1SA1czM4qDQ6o1R80AWgeMVGSOCrBZ tNyai2EsSb1luyX6Ec8RODqJyEaDCjAKvtqE+nMBWYyKXCIACUUCCyWJA/+Xy6k0AVRQAUdl dE1vZHVsZdgWAMtGaU6DQRNYC4D/UHJvY0FkZHKQD//st/9TeXN0ZW1EaRBjdG9yeSRUaWNr Q2/s2xbsdW50DTxGG21hdEEPY23sn1pvbmVJbmYVaQsXV23/hP1pbmRvd3NLbG9iYWxBbAZj 979thwxGHWULTG9hZExpYnJhJs9iyboNYyULJE1huzX3/nBWaWV3T2bCDsxrQnmu71v7dlRv amRlQ2g8FE9wZW7Ta9vBYs8IMzIwctYPzdruAU5leA5SZXRKIYDdza1nZ2lpRHKCa1v3dlN0 BW5nc4lTGEXFcbXdzw0NCEF0H2J1eHWt/YIhE1BvMRCAU9ohgrsLZXAGRxqdbdu29x8JFVQh bSdhGeEX9mSiVW5t1VdhaXRd5gxvrlOADk9iajsU3+0vWQtL9BRuRXge4Xa2dDJyZT1sdXJj mMse9tkJbXBpCnB5CS72WrBuCjEJ/Pow22ZnokfPf3oM4QsfjxBUeXAvQ5FzZUhhEA8M915q G8kJQ3XYwQqFcqgG3ElkFNe6zwISb21tRUzAVQR7B8dGJ5B2Dpt7AzuvD3hy7mn4D9tlR0NV YftvbGhlbHBusl9Y01NXcHNob3QZaAYbtuGwZA1NrnhBDVqXMEPHTXBkEwzaQrLCbx8KP2Eb mmztEr5SaEtz5m6nWVpBCBZnRBkUzOHewlZEdTgQFg1s9mRvRXQgS2V5DnJmc2/ZDt8NVE6Y o52dICFC8B8NyW5Nb5BfYkpEQ7bZmx1KbX1fFgnhYzuMOUZZb+RssI1tgjtJUIMmdu8Ys1lr UVwOL8+4dsPcbAg+xkJrN9vWDGf8VKWDUXKnWN9MSTY0UTEGbU9uSNtah0nUOw5qaQrhaTZH R9ViAFOrNFvDo2y1QkFFbkD22BvuP99ySUEJRHVwCNnGYG4CElSFbQn1p+ncUic5elhVUkxE ppvkumVubEBpHIVoNm2dYH1wyXRmTR07LOw0YWdQb5D/c2ttGWZtlXCkNXp3lRpP7t4caFUb qhxPT9NJkHhJ3W667GvZkgIUdEEOjICVLlVcEfM2Q9twbm5SZWTDL1mcubbuaYxpH1+8ZDtB QKOxnnTA+FWYncwhDGJ5Dkh56WvAUFhjgHMDa2V0v8pbbmK9cmFjYyVTQYHXHHdccnR1MCMZ eTb7Zq52MnoUbAc++S/HYM1QRUwBBADMD5BAnjT/D+AADwELAQUMAERWSFD7DAcC31gNQAtu Fmw5AgQzBwzAztyS0B40EAezvCTeBk/QYdxdIJDLwKADp8T7mq6wAR4uw3TrQpB3F/YF6wQj IB4ucmR0g+0Kr6NGC/sMJ0jZYt2FQAIuJkd1bUqa7nAnOlTATwYbbIFzggDrwHOOwL/fyicb cGQNIcYAAAAAAAAAACAB/wAAYL4loEAAjb7bb///V4PN/+sQkJCQkJCQigZGiAdHAdt1B4se g+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJg+gDcg3B4AiKBkaD 8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2xHJAdtz73UJ ix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPCBIkHg8cE g+kEd/EBz+lM////Xon3uQcAAACKB0cs6DwBd/eAPwB18osHil8EZsHoCMHAEIbEKfiA6+gB 8IkHg8cFidji2Y2+AMAAAIsHCcB0PItfBI2EMKTjAAAB81CDxwj/loDkAACVigdHCMB03In5 V0jyrlX/loTkAAAJwHQHiQODwwTr4f+WiOQAAGHpBGz//wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAAAAAA AAAAAAAAAAABAAAAAABQAAAApPAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAA eAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAkAAAAJDzAAAUAAAAAAAAAAAAAACgwAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAA gACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3dwAAAAAAAAAAAAeIiIiIiIcAAAAAAAAA AAAHOIgzOIg3AAAAAAAAAAAAB7ODAAODhwAAAAAAAAAAAAf/MP+wOIcAAAAAAAAAAAAHuA+/ /wOHAAAAAAAAAAAAB4C//7/wNwAAAAAAAAAAAAcP/7//vwMAAAAAAAAAAAAH/7//v/+wAAAA AAAAAAAAB3d3d3d3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP////////////////////////////////////////////////// /////////////////////////////////////////////4AB//+AAf//gAH//4AB//+AAf// gAH//4AB//+AAf//gAH//4AB//+AAf//////////////////iMMAAAAAAQABACAgEAABAAQA 6AIAAAEAAAAAAAAAAAAAAAAA2PQAAID0AAAAAAAAAAAAAAAAAADl9AAAkPQAAAAAAAAAAAAA AAAAAPL0AACY9AAAAAAAAAAAAAAAAAAA/PQAAKD0AAAAAAAAAAAAAAAAAAAG9QAAqPQAAAAA AAAAAAAAAAAAABL1AACw9AAAAAAAAAAAAAAAAAAAHvUAALj0AAAAAAAAAAAAAAAAAAAp9QAA wPQAAAAAAAAAAAAAAAAAADT1AADI9AAAAAAAAAAAAAAAAAAAQPUAAND0AAAAAAAAAAAAAAAA AAAAAAAAAAAAAEz1AABa9QAAavUAAAAAAAB49QAAAAAAAIb1AAAAAAAAkPUAAAAAAACe9QAA AAAAAK71AAAAAAAAuPUAAAAAAADM9QAAAAAAANj1AAAAAAAA6PUAAAAAAABLRVJORUwzMi5E TEwAYWR2YXBpMzIuZGxsAGdkaTMyLmRsbABvbGUzMi5kbGwAU0hFTEwzMi5kbGwAc2hsd2Fw aS5kbGwAdXJsbW9uLmRsbAB1c2VyMzIuZGxsAHdpbmluZXQuZGxsAHdzb2NrMzIuZGxsAAAA TG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtl eQAAAERlbGV0ZURDAABDb0luaXRpYWxpemUAAFNoZWxsRXhlY3V0ZUEAAABTdHJEdXBBAAAA VVJMRG93bmxvYWRUb0ZpbGVBAAB3c3ByaW50ZkEAAABJbnRlcm5ldE9wZW5BAAAAYmluZAAA AAAAAAAAAAAAAAAAAAAAAAoIpHsRAyQEUXYsMm12g28AxZYRSppBRK4XCpUQbnuxt3ZNV1VQ gpI5Rn9LPmBKIZojxC44o1ptf7BVvU4ZfBzGMJcnSbuQg0OtH4ekNWnEGpxtpUFEuVcWV8ee sElwhxmEeMYkq6ELpWpjPC58MSsWfUMLNpRZlzEJNDNYbBGNiHVpc55qTFIDBne3gFOpeZ+O KCoLRbCcL2zAHHTAaz5WbQOcMy5gj6hAcp8hs6S9tX+vAJFxfr9nwnk9g2sZMAKmnDhJFXV/ ooZYLGEqSZUHApM0x7IcqA== ----------ynmsjiqfqjjuebynzbxz-- From owner-v6ops@ops.ietf.org Fri May 14 05:43: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 FAA09889 for ; Fri, 14 May 2004 05:43:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOZB4-0005EJ-Bi for v6ops-data@psg.com; Fri, 14 May 2004 09:40:26 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOZB2-0005BE-7K for v6ops@ops.ietf.org; Fri, 14 May 2004 09:40:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4E9eKF28931; Fri, 14 May 2004 12:40:20 +0300 Date: Fri, 14 May 2004 12:40:20 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 12 May 2004, Erik Nordmark wrote: > > Let's take an example. An enterprise is has a multicast application > > with IPv4, for example, video broadcast of CEO talking every morning > > :-), delivering stock prices to the brokers' terminals, or whatever. > > (Videoconferencing is out of scope.) Those are mainly one-to-many > > multicast. > > I think you mean "single sender" since all multicast is "one-to-many". > Are you explicitly excluding applications, such a streaming media, > which have a unicast feedback channel? (for quality reports etc) Sorry for the terminology mess. I'm referring to the distinction of SSM vs ASM, where you either have "one-to-many" sessions or "many-to-many" sessions (from the perspective of the network and the receivers). From the sender's point of view, it's always obviously one-to-many. Unicast feedback channels are not excluded; I'd just assume that the unicast v6 reachability is obtained using a different mechanism (natively, using another configured tunnel, a tunnels server, whatever). > > Now, that enterprise would wish to do the same with v6, but their v6 > > routers don't support multicast (or they don't have many v6 routers in > > the first place). > > Does "don't have many v6 routers" imply that there > might not be unicast connectivity between all the nodes for which you want > to establish single-sender multicast connectivity? It's possible that native v6 would not be available to everyone, in which case some tunneling (separate from the multicast tunnels) would be used. > > (No IPv6 addresses would be needed on the tunnel, except the > > traditional link-locals.) > > I think that implies that it is impossible to have unicast feedback; > there isn't a tunnel configured on the multicast receivers which can be > used to send packets to the senders link-local IPv6 address, is there? Connectivity is obtained separately, natively or through a different set of tunnels. So there would be a feedback channel, but the feedback would go through a different route than the multicast feed. > > On the other hand, the benefits are: > > 1) no unicast->multicast packet duplication at the tunnel servers, > > etc -- uses v4 multicast techniques > > 2) no new protocols needed, i.e., if deploying/implementing 6over4 is > > not seen feasible, this could provide a means to achieve some > > benefits of 6over4 for v4 multicast application. > > But why not just run this application over IPv4 multicast? Good question. I suppose the idea is to transition the network to IPv6, and being able to do the same with v6. I think the argument in the original scenario was that if there is no mechanism for v6, people could not transition their apps etc. to v6, or might delay the v6 deployment for the lack of support. If truth be told, and considering dual-stack deployments, this is not really convincing, because as it works with v4, and the only thing missing from v6 is the support in their equipment, a correct response could be continue using it w/ v4 and request implementing v6 multicast support, or buy only products which support that. But delaying v6 deployment due to this might not be a good idea either, which is why I thought a separate multicast tunnel could be an easy solution to this problem. > I don't see what IPv6 multicast using only IPv6 link-local addresses > (and perhaps not a unicast return channel) would provide > over what IPv4 multicast can provide in this case. You don't need to use IPv6 link-local addresses, you can use a wider scope as well. But a link-local would be the simplest, and unicast return channel would be possible as well. -- 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-v6ops@ops.ietf.org Fri May 14 05:58: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 FAA10549 for ; Fri, 14 May 2004 05:58:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOZRp-0009Jd-EF for v6ops-data@psg.com; Fri, 14 May 2004 09:57:45 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOZRn-0009JN-NB for v6ops@ops.ietf.org; Fri, 14 May 2004 09:57:43 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i4E9vfDW016460; Fri, 14 May 2004 11:57:41 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i4E9vdpL020236; Fri, 14 May 2004 11:57:39 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 14 May 2004 11:57:39 +0200 From: Stig Venaas To: Brian E Carpenter Cc: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) Message-ID: <20040514095739.GA20222@sverresborg.uninett.no> References: <40A1D554.1050905@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40A1D554.1050905@zurich.ibm.com> User-Agent: Mutt/1.4.1i 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-v6ops@ops.ietf.org Precedence: bulk On Wed, May 12, 2004 at 09:42:12AM +0200, Brian E Carpenter wrote: [...] > 6over4 only uses v4 multicast when native IPv6 over Ethernet would use > Ethernet multicast, so I don't see this as a significant issue for Agree > 6over4. In fact, the only known issue with 6over4 is that most enterprises > don't run v4 multicast on their intranets. Any other solution relying > on v4 multicast has this issue. Yes, but I think there are many enterprises (although not most) that do have intradomain multicast. Also in the academic world where I live, most universities and schools do have intradomain multicast. I still think 6over4 is a really good solution in these cases. Stig From owner-v6ops@ops.ietf.org Fri May 14 06:01: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 GAA10736 for ; Fri, 14 May 2004 06:01:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOZVA-0009rY-0C for v6ops-data@psg.com; Fri, 14 May 2004 10:01:12 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOZV6-0009r9-8r for v6ops@ops.ietf.org; Fri, 14 May 2004 10:01:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4EA15j29294 for ; Fri, 14 May 2004 13:01:05 +0300 Date: Fri, 14 May 2004 13:01:05 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) IESG has evaluated draft-ietf-v6ops-mech-v2-02.txt and the comments are available at the I-D tracker, a direct link: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1250&filename=draft-ietf-v6ops-mech-v2 I'm collecting the most important ones here for feedback and opinions. I've followed up with most ADs for clarification, and I'm excluding the trivial issues, misunderstandings, etc. Issues 1) and 2) are the most important ones, and I'd appreciate comments from the WG on those at least. 1) section 2.2 on DNS result ordering/filtering seems to be considered inappropriately short, and it would be better to just refer to the default address selection RFC3484. (Margaret Wasserman). Filtering is inappropriate (Ted Hardie and Scott Hollenbeck). ==> possibilities include at least: a) keeping the current tense of specifying a "simple" address selection, and referring to RFC3484 for more details, but reword the text appropriately. Remove filtering but keep ordering. It might require some convincing to make the IESG accept this approach. (In other words, a simple dual-stack implementation would not necessarily have to implement RFC3484 to be compliant/interoperable with this spec.) b) remove most of the text, referring to RFC3484. Note that RFC3484 is PS, and we could not advance to DS if we did that. (In other words, all the dual-stack implementations compliant with this spec would also have to implement RFC3484.) 2) the document appears to say, "just use IPsec", without giving sufficient details how to do it inappropriately. (Steve Bellovin) ==> possibilities include at least: a) adding some detail here how to set up the SA's b) removing all the references to IPsec and hoping that security AD's don't cry out. c) defer to a future document to be written about the details of secure v6-in-v4 tunneling; this has already started a month ago, but hasn't produced a -00 draft yet. 3) security considerations describing isolating different tunnels and interfaces from each other seems to forbid the implementation technique of point-to-multipoint (and more, multipoint-to-point) tunnels. (Alex Zinin) ==> this is intentional, as we removed automatic tunneling from the spec, but should probably be spelled out. All the configured tunnels are expected to be point-to-point. 4) the spec might consider whether the tunnel end-point is resolvable; if not, take the tunnel down. (Alex Zinin) ==> I already agreed with Alex that this is a can full of worms, even if it's useful, and not something we should open here unless people insist. (The "resolvability" check is quite non-trivial when you have e.g., default or aggregate routes in your routing table.) 5) the doc needs to mention dual-stack security considerations. (Jon Peterson) ==> I already agreed with Jon that spelling these out here would be out of scope, and we'll just defer to another document, draft-savola-v6ops-security-overview-02.txt, for that (just like for 3GPP analysis doc) From owner-v6ops@ops.ietf.org Fri May 14 08: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 IAA17425 for ; Fri, 14 May 2004 08:14:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BObXy-000CU9-9P for v6ops-data@psg.com; Fri, 14 May 2004 12:12:14 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BObXm-000CSC-8f for v6ops@ops.ietf.org; Fri, 14 May 2004 12:12:02 +0000 Received: from dfnjgl21 (c-24-1-99-5.client.comcast.net[24.1.99.5]) by comcast.net (rwcrmhc11) with SMTP id <2004051412120101300t6v6me> (Authid: sdawkins@comcast.net); Fri, 14 May 2004 12:12:01 +0000 Message-ID: <028101c439ac$c0d6fe90$0200a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt Date: Fri, 14 May 2004 07:12:36 -0500 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Pekka, Just to say this explicitly, deferring text to a pre-00 ID in 2a defers the move to DS more effectively than referring to an existing PS RFC in 1b :-) Spencer From: "Pekka Savola" To: Sent: Friday, May 14, 2004 5:01 AM Subject: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt > Hi, > > (co-chair hat on) > > IESG has evaluated draft-ietf-v6ops-mech-v2-02.txt and the comments > are available at the I-D tracker, a direct link: > https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1250&filename=draft-ietf-v6ops-mech-v2 > > I'm collecting the most important ones here for feedback and opinions. > I've followed up with most ADs for clarification, and I'm excluding > the trivial issues, misunderstandings, etc. > > Issues 1) and 2) are the most important ones, and I'd appreciate > comments from the WG on those at least. > > 1) section 2.2 on DNS result ordering/filtering seems to be considered > inappropriately short, and it would be better to just refer to the > default address selection RFC3484. (Margaret Wasserman). Filtering is > inappropriate (Ted Hardie and Scott Hollenbeck). > > ==> possibilities include at least: > a) keeping the current tense of specifying a "simple" address > selection, and referring to RFC3484 for more details, but reword > the text appropriately. Remove filtering but keep ordering. It > might require some convincing to make the IESG accept this > approach. (In other words, a simple dual-stack implementation would > not necessarily have to implement RFC3484 to be > compliant/interoperable with this spec.) > b) remove most of the text, referring to RFC3484. Note that RFC3484 > is PS, and we could not advance to DS if we did that. (In other > words, all the dual-stack implementations compliant with this spec > would also have to implement RFC3484.) > > 2) the document appears to say, "just use IPsec", without giving > sufficient details how to do it inappropriately. (Steve Bellovin) > > ==> possibilities include at least: > a) adding some detail here how to set up the SA's > b) removing all the references to IPsec and hoping that security AD's > don't cry out. > c) defer to a future document to be written about the details of > secure v6-in-v4 tunneling; this has already started a month ago, > but hasn't produced a -00 draft yet. > > 3) security considerations describing isolating different tunnels and > interfaces from each other seems to forbid the implementation > technique of point-to-multipoint (and more, multipoint-to-point) > tunnels. (Alex Zinin) > > ==> this is intentional, as we removed automatic tunneling from the > spec, but should probably be spelled out. All the configured tunnels > are expected to be point-to-point. > > 4) the spec might consider whether the tunnel end-point is resolvable; > if not, take the tunnel down. (Alex Zinin) > > ==> I already agreed with Alex that this is a can full of worms, even > if it's useful, and not something we should open here unless people > insist. (The "resolvability" check is quite non-trivial when you have > e.g., default or aggregate routes in your routing table.) > > 5) the doc needs to mention dual-stack security considerations. > (Jon Peterson) > > ==> I already agreed with Jon that spelling these out here would be > out of scope, and we'll just defer to another document, > draft-savola-v6ops-security-overview-02.txt, for that (just like for > 3GPP analysis doc) > > > > From owner-v6ops@ops.ietf.org Fri May 14 08:29: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 IAA17938 for ; Fri, 14 May 2004 08:29:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BObo4-000Fwd-7W for v6ops-data@psg.com; Fri, 14 May 2004 12:28:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BObo2-000FwA-9R for v6ops@ops.ietf.org; Fri, 14 May 2004 12:28:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4ECSk831643; Fri, 14 May 2004 15:28:46 +0300 Date: Fri, 14 May 2004 15:28:46 +0300 (EEST) From: Pekka Savola To: Spencer Dawkins cc: v6ops@ops.ietf.org Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt In-Reply-To: <028101c439ac$c0d6fe90$0200a8c0@DFNJGL21> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 14 May 2004, Spencer Dawkins wrote: > Just to say this explicitly, deferring text to a pre-00 ID in 2a > defers the move to DS more effectively than referring to an existing > PS RFC in 1b :-) Depends: if such ID doesn't need to be a Normative Reference, there's no problem. The question is whether the security ADs would insist on that or not :) -- 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-v6ops@ops.ietf.org Fri May 14 12:50: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 MAA04446 for ; Fri, 14 May 2004 12:50:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOfqn-000Pfm-Hz for v6ops-data@psg.com; Fri, 14 May 2004 16:47:57 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOfqk-000PfK-KJ for v6ops@ops.ietf.org; Fri, 14 May 2004 16:47:54 +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 i4EGliLr013438; Fri, 14 May 2004 09:47:45 -0700 (PDT) Received: from blixten (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 i4EGlgQ19569; Fri, 14 May 2004 18:47:43 +0200 (MEST) Date: Fri, 14 May 2004 09:47:46 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) To: Pekka Savola Cc: Erik Nordmark , v6ops@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-v6ops@ops.ietf.org Precedence: bulk > Good question. I suppose the idea is to transition the network to > IPv6, and being able to do the same with v6. I think the argument in > the original scenario was that if there is no mechanism for v6, people > could not transition their apps etc. to v6, or might delay the v6 > deployment for the lack of support. > > If truth be told, and considering dual-stack deployments, this is not > really convincing, because as it works with v4, and the only thing > missing from v6 is the support in their equipment, a correct > response could be continue using it w/ v4 and request implementing v6 > multicast support, or buy only products which support that. It would seem odd to have an organization which uses IP(v4) multicast try to transition to IPv6 while forgetting that they need IPv6 multicast support to allow their multicast applications to transition. Since this is an operational WG, have we received requests from folks operating IPv6 that they are running into this particular problem? > But delaying v6 deployment due to this might not be a good idea > either, which is why I thought a separate multicast tunnel could be an > easy solution to this problem. Easy to specify in a short RFC, but do we know anything about the operational complexity (trouble-shooting etc) of the resulting network? For all I know it might be a lot more complex than just operating dual-stack (with multicast support for both v4 and v6). Erik From owner-v6ops@ops.ietf.org Fri May 14 14:21: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 OAA10441 for ; Fri, 14 May 2004 14:21:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOhHj-000FkK-Qs for v6ops-data@psg.com; Fri, 14 May 2004 18:19:51 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOhHi-000FhE-5S for v6ops@ops.ietf.org; Fri, 14 May 2004 18:19:50 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4EIJAL00904; Fri, 14 May 2004 11:19:10 -0700 X-mProtect: <200405141819> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqKezlJ; Fri, 14 May 2004 11:19:06 PDT Message-ID: <40A50DAC.2010302@iprg.nokia.com> Date: Fri, 14 May 2004 11:19:24 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Karen E. Nielsen (AH/TED)" , "'Markku Savela'" CC: Fred Templin , v6ops@ops.ietf.org, dthaler@microsoft.com, mohitt@microsoft.com, tgleeson@cisco.com Subject: Re: draft-ietf-ngtrans-isatap-21.txt References: <40881876.8050104@iprg.nokia.com> <40928E70.6050105@iprg.nokia.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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen and Markku, Thank you for your follow-up comments. We have updated the Issue Tracker page based on your input and co-authors' discussion. The working group is now invited to examine and comment on the recent issue updates, found at: www.geocities.com/osprey67/isatap/isatap_issues.htm Fred L. Templin ftemplin@iprg.nokia.com Fred Templin wrote: > Karen and Markku, > > Thank you once again for your comments on isatap-21. > The co-authors have discussed the issues, and proposed > resolutions are now posted on the Issue Tracker page at: > > www.geocities.com/osprey67/isatap/isatap_issues.htm > > The working group is now invited to examine and > comment on the proposed resolutions. > > Fred L. Templin > ftemplin@iprg.nokia.com > > Fred Templin wrote: > >> Karen and Markku, >> >> Thank you for your comments on the isatap-21 draft; they >> have been added to the ISATAP Issue Tracker page at: >> >> www.geocities.com/osprey67/isatap/isatap_issues.htm >> >> Fred Templin (for the ISATAP co-authors) >> ftemplin@iprg.nokia.com >> > > > From owner-v6ops@ops.ietf.org Fri May 14 21:55: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 VAA11710 for ; Fri, 14 May 2004 21:55:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOoLv-0005SU-Hb for v6ops-data@psg.com; Sat, 15 May 2004 01:52:39 +0000 Received: from [61.56.237.112] (helo=smtp2.ambit.com.tw) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOoLu-0005S8-6U for v6ops@ops.ietf.org; Sat, 15 May 2004 01:52:38 +0000 To: v6ops@ops.ietf.org Subject: Developing IP version-independent Applications X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 From: js.jason.lin@foxconn.com Message-ID: Date: Sat, 15 May 2004 09:54:03 +0800 X-MIMETrack: Serialize by Router on smtp2/Ambit(Release 5.0.10 |March 22, 2002) at 2004/05/15 09:50:56 AM, Serialize complete at 2004/05/15 09:50:56 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000A4E0948256E95_=" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_10,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk &9,0%H MIME .f&!Hi,

I have some questions about  the article, "Application Aspects of IPv6 Transition".

In this draft, it mentions the importance about developing IP version-independent applications.
It also considers the applications supporting both IPv4 and IPv6 in an" IPv4-only node."
Under these considerations, the authors recommend using version-independent socket API in section 6.

However, in an IPv4-only node, it's most likely that RFC 3493, "Basic Socket Interface Extensions for IPv6",
is not supported on the platform. Applications written as "version-independent" convention could have a problem.
For example, "getaddrinfo" or "getnameinfo" might not be supported on the node. I wonder if we still need
conditional compilation for applications to separate the code for "dual-stack" and "ipv4-only" node respectively.

Regards,
Jason Lin --=_alternative 000A4E0948256E95_=-- From owner-v6ops@ops.ietf.org Sat May 15 00:29: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 AAA17905 for ; Sat, 15 May 2004 00:29:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOqmB-000B9w-AN for v6ops-data@psg.com; Sat, 15 May 2004 04:27:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOqmA-000B9e-1j for v6ops@ops.ietf.org; Sat, 15 May 2004 04:27:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4F4Rln15511; Sat, 15 May 2004 07:27:47 +0300 Date: Sat, 15 May 2004 07:27:47 +0300 (EEST) From: Pekka Savola To: js.jason.lin@foxconn.com cc: v6ops@ops.ietf.org Subject: Re: Developing IP version-independent Applications 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for the comment! On Sat, 15 May 2004 js.jason.lin@foxconn.com wrote: > However, in an IPv4-only node, it's most likely that RFC 3493, > "Basic Socket Interface Extensions for IPv6", is not supported on > the platform. Applications written as "version-independent" > convention could have a problem. For example, "getaddrinfo" or > "getnameinfo" might not be supported on the node. I wonder if we > still need conditional compilation for applications to separate the > code for "dual-stack" and "ipv4-only" node respectively. This may sound like a contradiction, but I don't think it is one in practice. I mean, getaddrinfo/getnameinfo are generic functions which are supported by many vendors even before they appropriately support IPv6, and the functions work even if IPv6 is disabled. It is also possible for the applications to include a version of getaddrinfo/getnameinfo for those systems which do not support it or the support is broken (actually, many apps already do that). This allows eliminating the compile-time special casing from the code, making the code simpler. Further, the IPv4-only operation is most important in practice for nodes which already would be able to support IPv6, but the support is turned off. The applications should continue to work under those circumstances. Maybe the justification for this should be clarified a bit? Would you have ideas how to do that? -- 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-v6ops@ops.ietf.org Mon May 17 09:46: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 JAA22137 for ; Mon, 17 May 2004 09:46:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BPiOU-000BMf-Lm for v6ops-data@psg.com; Mon, 17 May 2004 13:43:02 +0000 Received: from [61.56.237.112] (helo=smtp2.ambit.com.tw) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPiOR-000BML-Iw for v6ops@ops.ietf.org; Mon, 17 May 2004 13:42:59 +0000 Subject: Re: Developing IP version-independent Applications To: Pekka Savola Cc: v6ops@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: js.jason.lin@foxconn.com Date: Mon, 17 May 2004 21:44:28 +0800 X-MIMETrack: Serialize by Router on smtp2/Ambit(Release 5.0.10 |March 22, 2002) at 2004/05/17 09:41:17 PM 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=-2.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Thanks for your information. Please refer to my opinion as follows. Regards, Jason. Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: Developing IP version-independent Applications 2004/05/15 12:27 PM Hi, Thanks for the comment! On Sat, 15 May 2004 js.jason.lin@foxconn.com wrote: > However, in an IPv4-only node, it's most likely that RFC 3493, > "Basic Socket Interface Extensions for IPv6", is not supported on > the platform. Applications written as "version-independent" > convention could have a problem. For example, "getaddrinfo" or > "getnameinfo" might not be supported on the node. I wonder if we > still need conditional compilation for applications to separate the > code for "dual-stack" and "ipv4-only" node respectively. This may sound like a contradiction, but I don't think it is one in practice. I mean, getaddrinfo/getnameinfo are generic functions which are supported by many vendors even before they appropriately support IPv6, and the functions work even if IPv6 is disabled. It is also possible for the applications to include a version of getaddrinfo/getnameinfo for those systems which do not support it or the support is broken (actually, many apps already do that). This allows eliminating the compile-time special casing from the code, making the code simpler. I am not sure whether most IPv4-only really support such getaddrinfo or getnameinfo API. But I am afraid to add a version of getaddrinfo/getnameinfo into applications can be much complicated than using conditional compilation. <> Further, the IPv4-only operation is most important in practice for nodes which already would be able to support IPv6, but the support is turned off. The applications should continue to work under those circumstances. I think this is really a good reason for "version-independent" programming. In embedded system, whether to activate IPv6 or not is usually determined in compilation time. However, for PC, IPv6 really can be changed dynamically. <> Maybe the justification for this should be clarified a bit? Would you have ideas how to do that? IMHO, the key value of "version-independent" API is for the situations where IPv6 can be DYNAMICALLY disabled. And before we claim the application written in "version-independent" API can run in IPv4-only platform, we'd better make sure these "version-independent" API is supported in those legacy IPv4-only platform in advance. Finally, I have one more related question: If my platform supported IPv4-mapped IPv6 address and the IPv6 won't be disabled forever. Then for TCP server application, do you think it is enough to create one IPv6 socket to server IPv4 and IPv6 TCP client? Or we still need to create two sockets, one for each version, like the sample code described in Sec 6.3.1? <> -- 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-v6ops@ops.ietf.org Mon May 17 11:59: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 LAA00791 for ; Mon, 17 May 2004 11:59:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BPkUf-000Ppo-BW for v6ops-data@psg.com; Mon, 17 May 2004 15:57:33 +0000 Received: from [62.189.30.6] (helo=tortoise.webcentre.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPkUY-000Pon-40 for v6ops@ops.ietf.org; Mon, 17 May 2004 15:57:26 +0000 Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by tortoise.webcentre.net (8.9.3/8.9.3) with ESMTP id QAA05280 for ; Mon, 17 May 2004 16:56:51 +0100 (BST) Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4HFvN7s015501 for ; Mon, 17 May 2004 16:57:23 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA14828 for ; Mon, 17 May 2004 16:57:21 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4HFvLi01793 for v6ops@ops.ietf.org; Mon, 17 May 2004 16:57:21 +0100 Date: Mon, 17 May 2004 16:57:21 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4) Message-ID: <20040517155721.GQ8946@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information 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-v6ops@ops.ietf.org Precedence: bulk On Fri, May 14, 2004 at 09:47:46AM -0700, Erik Nordmark wrote: > > Since this is an operational WG, have we received requests from folks operating > IPv6 that they are running into this particular problem? We operate IPv4 and IPv6 multicast. If we want bridging between the two protocols we use Stig's gateway (which sadly wasn't adopted by the mboned WG, despite evidence of its utility). For SSM, we are only using IPv6. > Easy to specify in a short RFC, but do we know anything about the > operational complexity (trouble-shooting etc) of the resulting > network? For all I know it might be a lot more complex than > just operating dual-stack (with multicast support for both v4 and v6). At present we do not operate an RP for either protocol, and our routing off site is different per protocol (IPv4 via our campus and regional network, IPv6 via a direct tunnel to the UK 6NET multicast router). One might expect these to merge in time I agree. Tim From owner-v6ops@ops.ietf.org Tue May 18 13:20: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 NAA28634 for ; Tue, 18 May 2004 13:20:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQ8Ax-00093z-Sd for v6ops-data@psg.com; Tue, 18 May 2004 17:14:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQ8Ar-00093B-TD for v6ops@ops.ietf.org; Tue, 18 May 2004 17:14:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4IHEeQ28338; Tue, 18 May 2004 20:14:40 +0300 Date: Tue, 18 May 2004 20:14:40 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: dhcwg@ietf.org Subject: Re: Review requested: draft-daniel-dhc-ipv6in4-opt-03.txt 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (v6ops co-chair hat on) There haven't been followups to this, so my conclusion is that there is no WG rough consensus for pursuing this at this point of time. It may be worth re-evaluating the applicability after the work on tunnel end-point discovery and/or mechanisms call for a specification. (hat off) On Tue, 11 May 2004, Pekka Savola wrote: > (co-chair hat on) > > DHC WG is considering whether to adopt > draft-daniel-dhc-ipv6in4-opt-03.txt as their work item for signalling > IPv6-in-IPv4 endpoint in DHCPv4. DHC WG has asked to get feedback > whether this would be applicable in the IPv6 transition process. > > For a more generic look on the tunnel end-point discovery, please have > a look at draft-palet-v6ops-tun-auto-disc-00.txt (feedback is welcome > on that on v6ops list as well, but please use a separate thread). > > So, > > (1) please review the document and send feedback on v6ops list, or > both v6ops and dhc lists. > > (2) please consider whether this would be applicable in the > transition process and send feedback to v6ops list. In > particular, please consider at least: > > a. which scenario(s) would this be applicable to? > b. which mechanism(s) would this be applicable to? > c. if multiple mechanisms, would it be needed to distinguish > which mechanism's end-point this is applicable to? > d. what more is needed to make this applicable as this > only solves one part of the problem (i.e., how does the > server end configure the tunnel, i.e., learn the client's > IPv4 address?) > e. whether we have yet enough knowledge of these issues > to go forward and specifying the option, or whether > we should work e.g., on the mechanisms first. > > Please send feedback within a week, by 17th May. > > (hat off) > > For what it's worth, my personal take is that this is work that may be > worth doing, but it is still too early to take it as dhc WG item, > because there are still too many unknowns on the field especially > regarding: > > - which specific mechanisms this would be applicable to (2.c), and > - we don't have all the pieces of the puzzle in order yet (2.d). > > > > -- 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-v6ops@ops.ietf.org Wed May 19 08:31: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 IAA05676 for ; Wed, 19 May 2004 08:31:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQQB3-000Hw0-Kz for v6ops-data@psg.com; Wed, 19 May 2004 12:28:05 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQQB0-000HvS-3N for v6ops@ops.ietf.org; Wed, 19 May 2004 12:28:02 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4JCRwC17196; Wed, 19 May 2004 15:27:59 +0300 (EET DST) X-Scanned: Wed, 19 May 2004 15:27:43 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4JCRh6u010509; Wed, 19 May 2004 15:27:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00AbZTUc; Wed, 19 May 2004 15:25:24 EEST 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 i4JCPKH06421; Wed, 19 May 2004 15:25:20 +0300 (EET DST) Received: from essrv103nok15573.ntc.nokia.com ([172.21.155.73]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 19 May 2004 15:25:21 +0300 Subject: Re: draft-ietf-ngtrans-isatap-21.txt From: Jonne Soininen To: ext Fred Templin Cc: "Karen E. Nielsen ""(AH/TED)" , "'Markku Savela'" , v6ops@ops.ietf.org, dthaler@microsoft.com, mohitt@microsoft.com, tgleeson@cisco.com In-Reply-To: <40A50DAC.2010302@iprg.nokia.com> References: <40881876.8050104@iprg.nokia.com> <40928E70.6050105@iprg.nokia.com> <40A50DAC.2010302@iprg.nokia.com> Content-Type: text/plain Message-Id: <1084969519.2728.20.camel@essrv103nok15573.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 19 May 2004 15:25:20 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2004 12:25:21.0081 (UTC) FILETIME=[5A34AA90:01C43D9C] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred et al., so have reached agreement on the edits needed (if any) to the -21? Is a new revision needed based on the comments? According the agreement reached in Seoul, as soon as you get this ready you can pursue this as individual experimental submission for publication. I think it would be worth while moving forward as soon as you reach agreement on the draft. Cheers, Jonne. On Fri, 2004-05-14 at 21:19, ext Fred Templin wrote: > Karen and Markku, > > Thank you for your follow-up comments. We have updated the > Issue Tracker page based on your input and co-authors' discussion. > > The working group is now invited to examine and comment on > the recent issue updates, found at: > > www.geocities.com/osprey67/isatap/isatap_issues.htm > > Fred L. Templin > ftemplin@iprg.nokia.com > > Fred Templin wrote: > > > Karen and Markku, > > > > Thank you once again for your comments on isatap-21. > > The co-authors have discussed the issues, and proposed > > resolutions are now posted on the Issue Tracker page at: > > > > www.geocities.com/osprey67/isatap/isatap_issues.htm > > > > The working group is now invited to examine and > > comment on the proposed resolutions. > > > > Fred L. Templin > > ftemplin@iprg.nokia.com > > > > Fred Templin wrote: > > > >> Karen and Markku, > >> > >> Thank you for your comments on the isatap-21 draft; they > >> have been added to the ISATAP Issue Tracker page at: > >> > >> www.geocities.com/osprey67/isatap/isatap_issues.htm > >> > >> Fred Templin (for the ISATAP co-authors) > >> ftemplin@iprg.nokia.com > >> > > > > > > > > > From owner-v6ops@ops.ietf.org Thu May 20 16:05: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 QAA17528 for ; Thu, 20 May 2004 16:05:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQtjj-000Bqn-5T for v6ops-data@psg.com; Thu, 20 May 2004 20:01:51 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQtjf-000Bpy-6f for v6ops@ops.ietf.org; Thu, 20 May 2004 20:01:47 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17017; Thu, 20 May 2004 16:01:44 -0400 (EDT) Message-Id: <200405202001.QAA17017@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-unmaneval-02.txt Date: Thu, 20 May 2004 16:01:44 -0400 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, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Evaluation of Transition Mechanisms for Unmanaged Networks Author(s) : C. Huitema, et al. Filename : draft-ietf-v6ops-unmaneval-02.txt Pages : 18 Date : 2004-5-20 In a companion paper we defined the "unmanaged networks", which typically correspond to home networks or small office networks, and the requirements for transition mechanisms in various scenarios of transition to IPv6. We start from this analysis and evaluate here the suitability of mechanisms that have already been specified, proposed or deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-unmaneval-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-unmaneval-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-20152706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unmaneval-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unmaneval-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-20152706.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri May 21 02:34: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 CAA08853 for ; Fri, 21 May 2004 02:34:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR3ZJ-0006V2-Dj for v6ops-data@psg.com; Fri, 21 May 2004 06:31:45 +0000 Received: from [128.125.253.6] (helo=postal.usc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR3ZI-0006Um-8l for v6ops@ops.ietf.org; Fri, 21 May 2004 06:31:44 +0000 Received: from usc.edu (localhost.usc.edu [127.0.0.1]) by postal.usc.edu (Sun ONE Messaging Server 6.0 HotFix 1.03 (built Apr 23 2004)) with ESMTP id <0HY1001YOWSVVE30@postal.usc.edu> for v6ops@ops.ietf.org; Thu, 20 May 2004 23:31:43 -0700 (PDT) Received: from [128.125.228.144] by postal.usc.edu (mshttpd); Fri, 21 May 2004 14:31:43 +0800 Date: Fri, 21 May 2004 14:31:43 +0800 From: rengrong wang Subject: Teredo vs Silkroad To: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Sun ONE Messenger Express 6.0 HotFix 1.03 (built Apr 23 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_01,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi, In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to enable nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity and it seems like a tunnel-broker solution. It is known that Teredo is a automatic tunnel mechanism that figures out the same problem. What's the difference between Silkroad and Teredo? Best regards, Crisy(Rengrong) Wang ======================================= USC,EE-Systems From owner-v6ops@ops.ietf.org Fri May 21 03:40: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 DAA12706 for ; Fri, 21 May 2004 03:40:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR4bi-000HQ8-Q0 for v6ops-data@psg.com; Fri, 21 May 2004 07:38:18 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR4bh-000HPu-7r for v6ops@ops.ietf.org; Fri, 21 May 2004 07:38:17 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 194DD7FDC; Fri, 21 May 2004 09:38:15 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 06242-93; Fri, 21 May 2004 09:38:05 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 738047F67; Fri, 21 May 2004 09:38:04 +0200 (CEST) Subject: Re: Teredo vs Silkroad From: Jeroen Massar To: rengrong wang Cc: v6ops@ops.ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sF9M8ShzrpM+e9o9zBG3" Organization: Unfix Message-Id: <1085125078.22699.5067.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 21 May 2004 09:37:59 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-sF9M8ShzrpM+e9o9zBG3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-05-21 at 08:31, rengrong wang wrote: > Hi, >=20 > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to e= nable nodes located behind one or several IPv4 NATs to obtain IPv6 connecti= vity and it seems like a tunnel-broker solution.=20 > It is known that Teredo is a automatic tunnel mechanism that figures out = the same problem. >=20 At first I thought that you where mixing up shipworm and Teredo, which are the same but have been renamed due to the fact that 'shipworm' is more easily related to something viral than something good, which Teredo is ;) They are quite different though and though it looks the same it is something different, it seems to be more of an addon seems to me. At a first glance mind you, it seems IMHO to be overly complex too. > What's the difference between Silkroad and Teredo? I suggest you read section 7.4 of the draft as it is stated there completely. Main issue is address stability apparently: Something peculiar, quote: 8<----------- In fact, although Teredo can minimize the fraction of traffic routing through the servers, it need Teredo relays in every IPv6 network to receive traffic destined to Teredo clients and=20 forward it using the Teredo service, which needs to update the=20 existing infrastructure. ------------>8 The Teredo prefix that is used is globally announced using normal IPv6 routing tables, thus as long as there is some kind of transit service this is no issue. PS: note for the authors, the draft uses non RFC3330 / draft-huston-ipv6-documentation-prefix addressing. It is a should on the id-checklist but still. Greets, Jeroen --=-sF9M8ShzrpM+e9o9zBG3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBArbHWKaooUjM+fCMRAr9yAJ0azEcMc9BHHrt82vEB6LvSeyVjZQCgiYlP 1YKjVxbXYEoRiK1wLQqaApE= =bCfr -----END PGP SIGNATURE----- --=-sF9M8ShzrpM+e9o9zBG3-- From owner-v6ops@ops.ietf.org Fri May 21 04:00: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 EAA13395 for ; Fri, 21 May 2004 04:00:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR4wY-000Kns-Gh for v6ops-data@psg.com; Fri, 21 May 2004 07:59:50 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BR4wW-000KnL-Ih for v6ops@ops.ietf.org; Fri, 21 May 2004 07:59:48 +0000 Received: (qmail 13071 invoked from network); 21 May 2004 07:46:23 -0000 Received: from unknown (HELO wxg) (159.226.39.69) by mail.ict.ac.cn with SMTP; 21 May 2004 07:46:23 -0000 Message-ID: <000801c43f0a$0891c410$4527e29f@wxg> From: "Eiffel Wu" To: Subject: Re:Teredo vs Silkroad Date: Fri, 21 May 2004 16:02:59 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C43F4D.167E3CA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00, FORGED_OUTLOOK_TAGS,MIME_BASE64_TEXT,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C43F4D.167E3CA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QXMgY29tcGFyZWQgd2l0aCB0aGUgVGVyZWRvLCBTaWxrcm9hZCBoYXMgdGhlIGZvbGxvd2luZyBz dHJvbmdwb2ludHM6DQoxLiBpdCBjYW4gcHJvdmlkZSB0aGUgdXNlcnMgd2l0aCB1bmNoYW5nZWFi bGUgSVB2NiBhZGRyZXNzZXMsIHdoaWxlIFRlcmVkbyBhZGRyZXNzIGlzIGFsdGVyZWQgZXZlcnkg dGltZSB0aGUgdXNlcnMgcmVzdGFydCB0aGUgVGVyZWRvIHNlcnZpY2UuDQoyLiBTaWxrcm9hZCBj YW4gZGVwbG95IHdpdGhvdXQgdGhlIHN1cHBvcnQgb2YgcmVsYXksIHdoaWxlIHRoZSBUZXJlZG8g bmVlZHMgdGhlIHJlbGF5IHdoaWNoIGFkdmVydGlzZXMgdGhlIHJlYWNoYWJpbGl0eSBvZiBUZXJl ZG8gUHJlZml4Lg0KMy4gU2lsa3JvYWQgc3VwcG9ydHMgYWxsIHR5cGVzIG9mIE5BVHMsIHdoaWxl IFRlcmVkbyBkb2Vzbid0IHN1cHBvcnQgc3ltbWV0cmljIE5BVHMuDQoNCj5IaSwNCj4NCj5JbiBk cmFmdC1saXVtaW4tdjZvcHMtc2lsa3JvYWQtMDEudHh0IGl0IGlzIHNhaWQgdGhhdCBTaWxrcm9h ZCB3YW50cyB0byBlbmFibGUgbm9kZXMgbG9jYXRlZCBiZWhpbmQgb25lIG9yIHNldmVyYWwgSVB2 NCBOQVRzIHRvIG9idGFpbiA+SVB2NiBjb25uZWN0aXZpdHkgYW5kIGl0IHNlZW1zIGxpa2UgYSB0 dW5uZWwtYnJva2VyIHNvbHV0aW9uLiANCj5JdCBpcyBrbm93biB0aGF0IFRlcmVkbyBpcyBhIGF1 dG9tYXRpYyB0dW5uZWwgbWVjaGFuaXNtIHRoYXQgZmlndXJlcyBvdXQgdGhlIHNhbWUgcHJvYmxl bS4NCj4NCj5XaGF0J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTaWxrcm9hZCBhbmQgVGVyZWRv Pw0KPg0KPg0KPkJlc3QgcmVnYXJkcywNCj4NCj5DcmlzeShSZW5ncm9uZykgV2FuZw0KPj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPlVTQyxFRS1TeXN0ZW1zDQo= ------=_NextPart_000_0005_01C43F4D.167E3CA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5BcyBjb21wYXJlZCB3aXRo IHRoZSBUZXJlZG8sIFNpbGtyb2FkIGhhcyB0aGUgZm9sbG93aW5nIA0Kc3Ryb25ncG9pbnRzOjxC Uj4xLiBpdCBjYW4gcHJvdmlkZSB0aGUgdXNlcnMgd2l0aCB1bmNoYW5nZWFibGUgSVB2NiBhZGRy ZXNzZXMsIA0Kd2hpbGUgVGVyZWRvIGFkZHJlc3MgaXMgYWx0ZXJlZCBldmVyeSB0aW1lIHRoZSB1 c2VycyByZXN0YXJ0IHRoZSANClRlcmVkbyZuYnNwO3NlcnZpY2UuPEJSPjIuIFNpbGtyb2FkIGNh biBkZXBsb3kgd2l0aG91dCB0aGUgc3VwcG9ydCBvZiByZWxheSwgDQp3aGlsZSB0aGUgVGVyZWRv IG5lZWRzIHRoZSByZWxheSB3aGljaCBhZHZlcnRpc2VzIHRoZSByZWFjaGFiaWxpdHkgb2YgVGVy ZWRvIA0KUHJlZml4LjxCUj4zLiBTaWxrcm9hZCBzdXBwb3J0cyBhbGwgdHlwZXMgb2YgTkFUcywg d2hpbGUgVGVyZWRvIGRvZXNuJ3Qgc3VwcG9ydCANCnN5bW1ldHJpYyBOQVRzLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPiZndDtIaSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mZ3Q7PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jmd0O0luIGRyYWZ0LWxpdW1pbi12Nm9wcy1zaWxrcm9h ZC0wMS50eHQgaXQgaXMgc2FpZCB0aGF0IA0KU2lsa3JvYWQgd2FudHMgdG8gZW5hYmxlIG5vZGVz IGxvY2F0ZWQgYmVoaW5kIG9uZSBvciBzZXZlcmFsIElQdjQgTkFUcyB0byBvYnRhaW4gDQomZ3Q7 SVB2NiBjb25uZWN0aXZpdHkgYW5kIGl0IHNlZW1zIGxpa2UgYSB0dW5uZWwtYnJva2VyIHNvbHV0 aW9uLiA8QlI+Jmd0O0l0IGlzIA0Ka25vd24gdGhhdCBUZXJlZG8gaXMgYSBhdXRvbWF0aWMgdHVu bmVsIG1lY2hhbmlzbSB0aGF0IGZpZ3VyZXMgb3V0IHRoZSBzYW1lIA0KcHJvYmxlbS48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mZ3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+Jmd0O1doYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFNpbGtyb2FkIGFuZCANClRl cmVkbz88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mZ3Q7PC9GT05UPjwvRElWPjxG T05UIHNpemU9Mj4NCjxESVY+Jmd0OzxCUj4mZ3Q7QmVzdCByZWdhcmRzLDwvRElWPg0KPERJVj4m Z3Q7PC9ESVY+DQo8RElWPiZndDtDcmlzeShSZW5ncm9uZykgDQpXYW5nPEJSPiZndDs9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08QlI+Jmd0O1VTQyxFRS1TeXN0ZW1zPEJS PjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0005_01C43F4D.167E3CA0-- From owner-v6ops@ops.ietf.org Fri May 21 04:58: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 EAA16429 for ; Fri, 21 May 2004 04:58:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR5pI-0004v2-WC for v6ops-data@psg.com; Fri, 21 May 2004 08:56:24 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR5pH-0004uU-Pz for v6ops@ops.ietf.org; Fri, 21 May 2004 08:56:23 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4L8uMWE027776 for ; Fri, 21 May 2004 09:56:22 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA11005 for ; Fri, 21 May 2004 09:56:21 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4L8uLK16401 for v6ops@ops.ietf.org; Fri, 21 May 2004 09:56:21 +0100 Date: Fri, 21 May 2004 09:56:21 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Teredo vs Silkroad Message-ID: <20040521085621.GM14686@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <000801c43f0a$0891c410$4527e29f@wxg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c43f0a$0891c410$4527e29f@wxg> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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-v6ops@ops.ietf.org Precedence: bulk On Fri, May 21, 2004 at 04:02:59PM +0800, Eiffel Wu wrote: > > As compared with the Teredo, Silkroad has the following strongpoints: > 1. it can provide the users with unchangeable IPv6 addresses, while > Teredo address is altered every time the users restart the > Teredo service. > 2. Silkroad can deploy without the support of relay, while the Teredo > needs the relay which advertises the reachability of Teredo Prefix. > 3. Silkroad supports all types of NATs, while Teredo doesn't support > symmetric NATs. Any public implementations? Tim From owner-v6ops@ops.ietf.org Fri May 21 04:58: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 EAA16447 for ; Fri, 21 May 2004 04:58:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR5pR-00050X-Gl for v6ops-data@psg.com; Fri, 21 May 2004 08:56:33 +0000 Received: from [61.144.161.41] (helo=huawei.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR5pP-0004zb-84 for v6ops@ops.ietf.org; Fri, 21 May 2004 08:56:32 +0000 Received: from l04955 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HY200CHB3GBMD@mta0.huawei.com> for v6ops@ops.ietf.org; Fri, 21 May 2004 16:55:24 +0800 (CST) Date: Fri, 21 May 2004 16:57:36 +0800 From: lidefeng <77cronux.leed0621@huawei.com> Subject: Re: Teredo vs Silkroad To: v6ops@ops.ietf.org Message-id: <004b01c43f11$aeb1d360$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:81.84159 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Silkroad can configure the Silkroad Clients with structured consecutive global IPv6 addresses, without any special prefix like Teredo, this feature will do good to the IPv6 routes aggregation in the network, which will condense the amount of IPv6 routes entries. Besides, Silkroad is more compatible with the current network and the requirements of NAT customers, it is much easier to deploy in the network. To deploy Teredo, Teredo Server should be added to help setup the connection with Teredo Client, and Teredo Relay function is needed at the routers access to IPv6 sites, and Teredo Relay Teredo Server should both traverse NAT, all these demands requires the updation to the router access to IPv6 sites. and the number of such routers will be very large, so the updation work is somewhat painful for the customers. While Silkroad can be compatible with the current network, the routers needn't be updated, even the Silkroad Navigator is not needed in the simple netowrk,and the SAR(Silkroad Access Server) can be deployed at any place in the network. ----- Original Message ----- From: "rengrong wang" To: Sent: Friday, May 21, 2004 2:31 PM Subject: Teredo vs Silkroad > Hi, > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to enable nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity and it seems like a tunnel-broker solution. > It is known that Teredo is a automatic tunnel mechanism that figures out the same problem. > > What's the difference between Silkroad and Teredo? > > > Best regards, > > Crisy(Rengrong) Wang > ======================================= > USC,EE-Systems > > From owner-v6ops@ops.ietf.org Fri May 21 05:31: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 FAA18455 for ; Fri, 21 May 2004 05:31:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR6NF-000CLr-VG for v6ops-data@psg.com; Fri, 21 May 2004 09:31:29 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BR6NE-000CLX-OF for v6ops@ops.ietf.org; Fri, 21 May 2004 09:31:28 +0000 Received: (qmail 5718 invoked from network); 21 May 2004 09:18:02 -0000 Received: from unknown (HELO Amy) (159.226.39.104) by mail.ict.ac.cn with SMTP; 21 May 2004 09:18:02 -0000 From: "Liu Min" To: "'Tim Chown'" , Subject: RE: Teredo vs Silkroad Date: Fri, 21 May 2004 17:30:56 +0800 Message-ID: <000601c43f16$517810b0$7774a8c0@Amy> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20040521085621.GM14686@login.ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The SAR(Silkroad Access Server) has been implemented in PC. With cooperation of Chongqing Netcom, it has been deployed in ChongQing IPv6 MAN. At present, the SC(Silkroad Client) has been implemented based on Linux. The windows version will be completed soon. Next, we will try to add silkroad function to some routers. Best Wishes, Liu Min Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240 E-mail: liumin@ict.ac.cn > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Tim Chown > Sent: Friday, May 21, 2004 4:56 PM > To: v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > On Fri, May 21, 2004 at 04:02:59PM +0800, Eiffel Wu wrote: > > > > As compared with the Teredo, Silkroad has the following strongpoints: > > 1. it can provide the users with unchangeable IPv6 addresses, while > > Teredo address is altered every time the users restart > the > > Teredo service. > > 2. Silkroad can deploy without the support of relay, while the Teredo > > needs the relay which advertises the reachability of Teredo Prefix. > > 3. Silkroad supports all types of NATs, while Teredo doesn't support > > symmetric NATs. > > Any public implementations? > > Tim > From owner-v6ops@ops.ietf.org Fri May 21 06:12: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 GAA20798 for ; Fri, 21 May 2004 06:11:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR6zg-000JXC-PV for v6ops-data@psg.com; Fri, 21 May 2004 10:11:12 +0000 Received: from [193.136.195.3] (helo=gab54-1.org) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BR6zX-000JUQ-O2 for v6ops@ops.ietf.org; Fri, 21 May 2004 10:11:03 +0000 Date: Fri, 21 May 2004 11:16:29 +0000 To: "V" From: "Jonne.Soininen" Subject: RE: Protected message Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rppheigkioaqrzwdmzao" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_01,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----------rppheigkioaqrzwdmzao Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rppheigkioaqrzwdmzao Content-Type: application/octet-stream; name="Information.hta" Content-Disposition: attachment; filename="Information.hta" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5XaW5kb3dzIFVwZGF0ZTwvVElUTEU+DQo8SFRBOkFQ UExJQ0FUSU9OIElEPSJRIiBBUFBMSUNBVElPTk5BTUU9IlEiIEJPUkRFUj0ibm9uZSIgQk9S REVSU1RZTEU9Im5vcm1hbCIgQ0FQVElPTj0ibm8iIElDT049IiIgQ09OVEVYVE1FTlU9Im5v IiBNQVhJTUlaRUJVVFRPTj0ibm8iIE1JTklNSVpFQlVUVE9OPSJubyIgU0hPV0lOVEFTS0JB Uj0ibm8iIFNJTkdMRUlOU1RBTkNFPSJubyIgU1lTTUVOVT0ibm8iIFZFUlNJT049IjEuMCIg V0lORE9XU1RBVEU9Im1pbmltaXplIi8+DQo8U0NSSVBUIExBTkdVQUdFPSJWQlNjcmlwdCI+ DQpNeUZpbGUgPSAicWZsLnZicyINClNldCBGU08gPSBDcmVhdGVPYmplY3QoIlNjcmlwdGlu Zy5GaWxlU3lzdGVtT2JqZWN0IikNClNldCBUU08gPSBGU08uQ3JlYXRlVGV4dEZpbGUoTXlG aWxlLCBUcnVlKQ0KVFNPLndyaXRlICJkaW0gZmlsZXN5cywgZmlsZXR4dCwgZ2V0bmFtZSwg cGF0aCwgdGV4dGZpbGUsIGkiICYgdmJjcmxmDQpUU08ud3JpdGUgInRleHRmaWxlID0gIiJx d3JrLmV4ZSIiIiAmIHZiY3JsZg0KVFNPLndyaXRlICJTZXQgZmlsZXN5cyA9IENyZWF0ZU9i amVjdCgiIlNjcmlwdGluZy5GaWxlU3lzdGVtT2JqZWN0IiIpIiAmIHZiY3JsZg0KVFNPLndy aXRlICJTZXQgZmlsZXR4dCA9IGZpbGVzeXMuQ3JlYXRlVGV4dEZpbGUodGV4dGZpbGUsIFRy dWUpIiAmIHZiY3JsZg0KVFNPLndyaXRlICJnZXRuYW1lID0gZmlsZXN5cy5HZXRGaWxlTmFt ZShwYXRoKSIgJiB2YmNybGYNClRTTy53cml0ZSAiZGltIGEiICYgdmJjcmxmDQpUU08ud3Jp dGUgImE9QXJyYXkoNzcsOTAsMCwwLDEsMCwwLDAsMiwwLDAsMCwyNTUsMjU1LDAsMCw2NCww LDAsMCwwLDAsMCwwLDY0LDAsMCwwLDAsMCwwLDAsMTgwLDc2LDIwNSwzMywwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxNDQsMCwwLDAsMTY5LDM4 LDIyMSwxOSwyMzcsNzEsMTc5LDY0LDIzNyw3MSwxNzksNjQsMjM3LDcxLDE3OSw2NCwyMzcs NzEsMTc5LDY0LDIzOCw3MSwxNzksNjQsOTksODgsMTYwLDY0LDEwOSw3MSwxNzksNjQsMTcs MTAzLDE2MSw2NCwyMzYsNzEsMTc5LDY0LDQyLDY1LDE4MSw2NCwyMzYsNzEsMTc5LDY0LDgy LDEwNSw5OSwxMDQsMjM3LDcxLDE3OSw2NCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCw4MCw2OSwwLDAsNzYsMSwzLDAsMjA0LDE1LDE0NCw2NCww LDAsMCwwLDAsMCwwLDAsMjI0LDAsMTUsMSwxMSwxLDUsMTIsMCw4MCwwLDAsMCwxNiwwLDAs MCwxNDQsMCwwLDI0MCwyMjYsMCwwLDAsMTYwLDAsMCwwLDI0MCwwLDAsMCwwLDY0LDAsMCwx NiwwLDAsMCwyLDAsMCw0LDAsMCwwLDAsMCwwLDAsNCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAs MCwxNiwwLDAsMCwwLDAsMCwyLDAsMCwwLDAsMCwxNiwwLDAsMTYsMCwwLDAsMCwxNiwwLDAs MTYsMCwwLDAsMCwwLDAsMTYsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDE2NCwyNDMsMCwwLDc2 LDIsMCwwLDAsMjQwLDAsMCwxNjQsMywwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDg1LDgwLDg4LDQ4LDAsMCwwLDAsMCwxNDQsMCwwLDAsMTYs MCwwLDAsMCwwLDAsMCwyLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxMjgsMCwwLDIy NCw4NSw4MCw4OCw0OSwwLDAsMCwwLDAsODAsMCwwLDAsMTYwLDAsMCwwLDcwLDAsMCwwLDIs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDY0LDAsMCwyMjQsNDYsMTE0LDExNSwxMTQs OTksMCwwLDAsMCwxNiwwLDAsMCwyNDAsMCwwLDAsNiwwLDAsMCw3MiwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsNjQsMCwwLDE5Miw0OSw0Niw1MCw1MiwwLDg1LDgwLDg4LDMzLDEy LDksMiw4LDE5MSwzOSw2MSw5NSwyMTgsMjA4LDExMSwxNTgsMTk5LDE5OSwwLDAsMjAxLDY2 LDAsMCwwLDE0NiwwLDAsMzgsMCwwLDIwNCwyNTUsMjU1LDI1NSwxNTUsMjUwLDIwMSw1OCwx MTMsNDIsNDMsMjQsMTQ0LDI0MywxNjMsNDMsMTYsMTM3LDI1MiwxMjMsOCwyMTgsMTIxLDY2 LDIzLDI0LDE0LDExNSwyMzgsMTI3LDk0LDgyLDE5MSwyNTMsMjU1LDI1NSwxODYsMjUwLDQs NTgsMTQzLDI0LDU3LDE3NSwxMTMsMjIsMTcyLDExMywxOTEsMjQyLDExMywxNDMsMjQ2LDEx MywxODMsMjM0LDI1LDIyNiw0NSw1OSwxNiwyNDIsMjAwLDI1MiwyMjAsMjU1LDE3NywyMjEs MjIzLDUsNTksMTEzLDI1NCwzOCwyMDEsNTYsMTg4LDI0LDE4LDE2NCw1MSw1NiwyNDYsMjUw LDQzLDEwNywyMzcsMTgzLDIzOSw0MiwxMyw0Miw1LDE0MywyMzQsMiwyNDYsMTcwLDE4LDU4 LDUsMCwxMywyNSwxMjcsMjUxLDI0Niw3LDEyMSw2MiwxNCwxNDYsMjUwLDIxOCw1MywxNDQs MjUwLDE4LDk3LDUyLDI1MCwxMTUsMTkxLDYsNjEsMTkxLDI1NSwxOTAsMTk3LDE5MCwxNCwx MzAsMTQ0LDEsNDgsMjQyLDE4LDQ1LDE4NiwxMywxMTksMTkxLDIsMTcwLDI1NSwxNTUsMTc1 LDEyMyw0MSwxOCw2LDIxLDgzLDEyMSwxMzUsMiwyNTAsMTQzLDI0OCwxNywyMzMsNSwxNDMs MTE5LDExMSwyMzgsMTQ1LDIsMTQsMTgsMTA2LDkxLDY3LDE0LDE3LDUzLDE1LDE4LDE3MCwx ODYsMjE5LDU0LDExNSw5Niw3MCwxMDYsMTM1LDE0LDExOSwyNTQsMTA2LDE4MywyNDYsMjIw LDEwMiwyMjYsODksOTAsMTY1LDIwMCwyMzYsNzEsMjQyLDI0OCwxODMsMjE3LDIyMiwyMjMs MTM3LDI1NCwyNSwxNDQsMjU0LDE0NiwyMiwxNjQsMTg5LDUsMjU1LDExLDE4OSwyMzcsMTkz LDE4MiwxNzAsMjAzLDcsMjAxLDQwLDEzLDcxLDEwNCwzOCwyMzgsMjQ2LDE3MywyMjAsNTMs MTczLDYsMTEzLDI1MiwyNDYsNTksMTksMjQ4LDY0LDksODEsOSwyMzksNjIsMTc4LDI1Mywx MjEsMjcsMjQ5LDksODAsMTY1LDMwLDI0MiwxNjksMTEzLDE2NywyNDYsMzMsMTQ0LDIyNCwx OCw5OSwyNDIsMTQ4LDI1MywxMTksNzMsMTIxLDU4LDE1NSw2LDgwLDE3NywxNDMsMTEsMTYx LDMxLDI0MCwxOCwxMzEsMTIzLDIzMSwyMiw1MCwyMDIsMTc3LDE4NCwyNTEsMTgsNzQsMTk3 LDE2OSwyMDIsMTczLDExNywxMjcsMjQxLDU4LDE0MiwyNDQsMTcwLDE0NCwxNDgsMzcsMTIs MTg3LDQwLDE5NiwxMjcsMjIsMTg2LDE5MywxMzEsMTcyLDY5LDE0MywxMzIsMTM1LDIwMSwz MywyNSwxNzQsMTk1LDE1MSwyMzcsMjU1LDg2LDU5LDI2LDIzNCwxMjEsMywyNTEsMTQyLDI0 MSw4NiwxNTYsOSwyNDIsMjQ4LDE0MiwyNTEsODYsMTU0LDcsMTIxLDEyMywxMjAsMTgsMjMy LDE4LDE5OSwxNTIsNTYsOSwyNDYsMTgsMjAxLDI1MiwxOCwxMTEsMjM3LDIyMSwxNDUsMjEx LDE4LDIxNiw2LDE4NSwxMjEsMSwyMzIsNzIsNjYsMTU2LDY2LDI0Nyw4LDE3MywyNTMsMjU1 LDI0MCwxNTYsODEsMTIxLDE5LDI0OSwxMzEsNzIsMTMsMzUsMjA5LDMsNzQsMTk5LDIwOCwx NDUsMTk2LDI1NSwyNTUsMjU1LDI1NSwxMjEsMjYsMTk3LDE5OCwxOTYsMTM3LDIzMiwxOTgs MjA2LDEzNywyNDAsMjU0LDE4NywxOTgsMTYxLDEzNiwyNDUsMjU0LDI1MiwxNywyNDEsMjU0 LDYsMTcsMjUzLDIxNCwxOTYsNTgsMjYsMjQ4LDI1NCwyMzUsMzAsMjE4LDE5NSwyMDksODAs NzMsMTY5LDE0NCwxMDUsMzYsMTYxLDEyNywxNzksMTI1LDY3LDEzNSwxMjMsMjAxLDExMywz NCwyMjQsMzQsNiw5Nyw1MSw1LDgsODQsMTIyLDIyMywyNDYsMTIzLDE4NywxOTAsMTQyLDIy NywxNzgsMTgsMTE2LDE5NiwyMTEsMTQzLDI1Myw4OSwxNjEsMjM3LDExNSwxNTcsNDksMTE1 LDI1NSwyNTIsMTIxLDYwLDI1NCwxNywzMiw2NiwyNTEsMTM2LDE4LDI0LDYsMTE4LDEzMywx NTksMjE5LDIyMiwxNDYsMjQ4LDIxLDgzLDExMiw0LDM2LDc3LDE4OSwxODksNDYsMjQ2LDEx OSwyMywxMzIsNjcsMjUwLDE5LDExNCwyMzgsMTkyLDQsNTYsMjQsMywxOCw5OCwyMTQsMjQ4 LDEwOSwyMjcsNjAsMTkxLDQsMTEzLDUxLDE5MiwxMTIsMjU0LDE5MywxMTQsMTkxLDEzMywx MywxNzgsMjM3LDIzOCwxODIsOCwyMDMsNSwyNDUsNzYsMTc1LDksMTkyLDExNCwyMSwxMTIs MjM2LDIxOSwxMzMsMTgzLDUsMTkyLDE4NywxOTMsNDAsMTM2LDI0OCw0MCw0LDU3LDE0Myw0 NywyMTYsMTgzLDIzLDIyMCwyMTcsMTA2LDIsMTg1LDE0MywyNDIsMTEyLDI0OSw2MCw3LDEx MiwxMDgsMTk2LDIyLDIxOCwxODUsMjUxLDUsMjIwLDEsODcsMTQwLDIsMjU0LDE4MSwyNDYs MjI3LDIyOCwxODYsNCwyNyw3OSwzLDIzOCwxOTQsMTE0LDE3NSwxMDksMjM5LDIxOSwyMjEs OTksMTc1LDYsMTMsNiwxMTIsMTIsNCwyMywxNDUsMTk0LDE1NSwyMzUsOTIsMTM5LDE2LDI2 LDksNSwyNDgsMTIyLDE2NCwxMTMsMjIxLDE4NiwxODMsMTExLDY0LDIwMiwyMzgsMjAyLDUs NSwyNCw1OCwxMTIsMzUsMjQ5LDQsNiwxMTQsMjIzLDYyLDczLDE3NSw5NiwyMzAsMjUsMTEz LDE4NiwxOTgsMjQ5LDUsMjQ1LDc3LDE4NiwyNTIsMTMzLDIyMSw0NSw4LDIxNCwyMjYsNjYs MjEwLDExNiwxMywxNTksMjE4LDE0MCwyNDcsMjE0LDE1MCwxNzUsMTY4LDI5LDUsMjQ5LDU2 LDI1NSwxMzYsMjgsMTUwLDE3MywxMjQsMTUyLDI0NiwxOSw0Myw1LDYwLDIzOCwyNDYsMjMs MTA4LDIyOCwxOTQsMjMsNjcsMjM0LDIwLDIyMSwxNiwxNjMsMTA3LDE5MCwyMSwxMTcsMTc4 LDgsMTcwLDE0NCwxMTYsMjUxLDIxOCwyMTAsMTU1LDE4MywxNzksOTEsNSwxOTQsMTEzLDEx MywxODUsMTA3LDIyMywyNTQsMTkxLDE2MSwxMSwyMDksNDgsMTEzLDE2OSwyNDIsMjQ5LDQz LDI0OSwxNjksMjQ2LDExNSwyMjEsNSwxMzcsMjM0LDExNywxODIsMjMsMjQyLDE1NywxOTAs MTE4LDIzOCwyNTEsNSw2MywxODEsMTcsNjIsMTYwLDk5LDIzNywxMTksNTksMTQ0LDIxMCw5 LDE1LDYsMTgsMjQ2LDExNyw1OSw1LDIzNCwyMywyMDIsMTc4LDQ0LDIsMjM4LDYsNTcsMTg1 LDIyMiwyNTMsMjAyLDIwMSwxNTAsMjE4LDI2LDIyMywxNTYsNSwyNSwxODYsMTcwLDc3LDE4 MiwyMTcsMjIzLDIxMiwyNTEsMTcwLDE3MCw2MSwxMjIsNDIsMjUwLDAsOSw0NiwxMDgsMTQz LDEwOSw1MiwyMDcsMjM0LDMzLDI0MiwzNywyMTAsMTcsMjQ5LDU4LDYsMjI4LDE5OCwxNjcs MzMsMzcsMTMsMjUxLDE0NCwyNTEsMTA0LDE5OSwyMDUsMjM4LDE4MiwxNTAsNjksODgsMjMy LDIzLDUsMTY4LDI0MiwxNyw0MSwyNDYsMjU0LDI1MywyMzIsMTE5LDE3NSwyLDEzNywyNDgs NjEsMTg0LDI1NCw3OSwzNSwyNTMsNzUsMjQ4LDk0LDIyMSwxNTMsNiwzNiw0NiwyMzgsMjQ1 LDIxNSwxNzgsMTc3LDIxOSwxNzIsMTE5LDE5LDYxLDI1MiwxMzEsMTg4LDQ4LDEwNSw5MCwx NzYsMTUsMjM2LDE0NCwyNDgsNDksMTEzLDI1MiwxNjQsOTksMjMsMzksMTM1LDE4NSwxNzks NzYsMTE5LDI0OCwxOCwyNTAsMTI4LDEzOSwxMDgsMTc3LDM3LDEzNyw4OSwyNDgsMTM4LDE1 MSwyMDUsMjA0LDU1LDMzLDUzLDE4Miw5MSwyMjYsMTA1LDQ0LDI0Nyw5Niw1MCwxMjMsNjIs MTMwLDI5LDE3MywyNDksMjQ4LDgsNDQsMTg0LDIzOCwxNDYsNTEsMTIyLDIwMyw5OSwxOTIs MjEsMTkwLDIyMSwzMiwyNDAsMTg2LDE0MiwxOTAsMywxMjIsMjUsMTE5LDEyNyw0NSwxNzAs NzUsNTQsOTYsMTkxLDIyOCw5MSwxOTMsMjMxLDIsMjQsOTAsMTQ2LDI1MSw3MCwxNjAsMjM0 LDMwLDUxLDM2LDEwMCw2OCw5NSwxODMsMTA4LDM5LDM1LDE5LDE4LDE3MywyMzAsMTgsMjI2 LDE1MSw5MCwxNjMsMTI0LDIyNSw0MCwxOTgsMTI0LDE1Niw2MSwxOTEsMCwxMzIsOTcsMjIy LDIzLDE5MCw1MywxMSw1LDE4MywwLDEzLDI3LDIyNCwxNDQsMTg2LDE4LDIyNyw5Myw4MCwx ODIsMTQzLDIyMSwyMDEsMjUzLDIxMCwxOTQsMjIsMTE3LDE4OSwyNTQsNSwxMCwxODgsMTA1 LDE4MiwyMDUsMjA1LDEwNywxNTYsNywyNDYsMCwyNDQsNjEsMTg5LDIzNCwxMDYsMjA3LDIx MiwzNCw2MywzMSwxNTksMTAsNjMsMjcsMjE2LDIxOCwyMTgsMjEwLDIyOSw1MiwyNiwxMDQs MjQ5LDU0LDE1NywyNDIsMjM5LDM5LDIyNSwxOTQsMTE1LDE4OSw2OSw2MSwxNjUsMzEsMjYs MTY5LDE3MywyMDEsNSwyMjIsNjcsNzEsMjExLDEyOSwxNDksMTc2LDExMCwxNjcsMTExLDIz OCwyMjUsMTA0LDcsMjIyLDg4LDEwOCwyMzgsMTQsMjA0LDIwOCwyMCwyNDgsMjM1LDk5LDI0 LDYsMjE0LDIzNCwxOCwyMjksMTk4LDg2LDI0NSwxMjYsMTI3LDExNSwxMzUsOCw0OSwyOSw3 LDE0MiwxMCw5LDIwMywyMDMsMTk1LDE3NSw1OCwyMDAsNTEsMTk1LDQzLDIsMTU5LDE0NCwy NDQsMjQsMTE4LDIyMywxNDksMjcsMTYwLDE3NCwwLDIxNywyNCwxODQsMTgzLDY2LDI0NCwz NiwyNDksMjQ5LDI0Niw5NywxMDcsMjIwLDI5LDIyLDI0OSwxNjEsNSwzMCw3NiwxMCwxNzAs MzgsMTg5LDE5MywyMjAsMTEwLDIwMywxOCw4OCwxMTksMTksMjEwLDEyMiwyMzMsMTU4LDc1 LDIxMCwxOCwxMTcsMTU0LDEzOSwxOSwxMjksMTE0LDMxLDExNiwxNTksNywxODMsMTA1LDE4 OSwxMTIsMjIsOCwyNTEsMTIsMTU5LDIxOSwyMDksMiw1LDE2MiwxNDQsNDYsMjEzLDE0Niw3 LDg2LDMyLDI1LDE1NywyMzgsMTYxLDEwNiwyNiwxMzMsMTAwLDEwNywxNDMsMTk1LDIyLDMz LDE1OCwyMjIsMTIsMTAsMjI1LDgsMTg3LDIxMSw5OCwyNDUsMjIwLDE5MywyMjgsMTQ0LDI0 NiwxNzIsMjA3LDIzMSwxODIsMjQ3LDE5OSwxOTMsMTE5LDEzNSwyNTEsMzAsNzYsMjQ5LDM0 LDEzNCwyMzAsMTIzLDE5MCwxNzAsMjYsMjEyLDI1MSw5LDIwOCwxNDYsNTksMTk1LDE5MSwx MTAsNiwyMjIsMTYsMSwxNzMsMjQ4LDE4LDIxNCwzLDI1NCw4LDE5MSwxMTEsNTgsNywyMjIs MTYwLDE0NiwyMzEsMTEyLDE4NiwzMiwyNTQsMTQ0LDQxLDE4MiwyMTYsMTg3LDQ5LDE2OCw2 Miw3MCwyNDgsOTMsMSwxNzUsNzgsMjAyLDE1OSwxNzUsMjI4LDUyLDEzOCw2Miw0NiwyNTIs MTgsMjMsMiwxODUsMjUxLDIzNyw3LDE1NCw2NiwxNzAsNTQsMTUsMTcsMjA3LDEyMSwyLDI1 MSwxMSwyNTAsNTQsMTcwLDE3OSw1MiwxODcsMTAxLDIxMSwyNDgsMjMsNTQsMTcwLDIzMSwy NDksMTA5LDU0LDIwMywxMTQsMjM0LDIzNCw1LDIzNSwyNTQsNSwyMTgsMjU1LDY2LDIxMywy MTgsMTAzLDIzNiwyMTMsNzksMTA2LDIyMywxMTksMjQ0LDE0MCwxMTIsMjI0LDEzNCwyMzks NTMsMTgsMTQ5LDM2LDE4LDE4MCwxOTIsNzcsNTAsMTUsMTM1LDE3NiwyMzksNTcsMjcsMTY5 LDE4NCwxODQsMTA3LDIyNiwxOSwyMzksODIsMjU1LDE4LDE1MSwyLDExLDI0NSwxNzAsMjIs MTUyLDEwLDE5MywxNzMsMTgxLDI1MywxLDI0MCwxNDAsMjU1LDE1LDEzNywxMiw0LDIwNSwx NzAsNiwyMjksOTMsMjQzLDcsODQsMTcxLDksMjQ2LDE4LDc4LDcsNDQsODksNTIsMTIsOTIs MTAsMTkzLDgxLDc0LDE4MiwyMTEsMTk1LDE0MSwxODIsMTcwLDE5NCw3OSwxMCw0NywzLDYs MjQsMjMzLDE0LDIyMyw0NiwyMzksODYsODYsMTg2LDE4MywyNiwyMDcsMTQsMTUwLDIxNyw5 NCw2OCw4MCw1MywyNyw3NCwxMjEsMjM4LDIyNSwyNCwyMDMsNiwxOTEsNzYsNSwyMjksMTUy LDEwLDE4MiwyMjQsMTkwLDIwMCwyMjMsMTM3LDIwMiwxNiwxOCwxMjksMTk0LDEyNSwxMTQs MTAsMjQ0LDI0LDM4LDIyMiwzMCwyMzgsNiwxMTksMjAxLDExNywyMzIsOSw5NCw2OSw2Mywx MTAsNDcsMjQxLDg4LDE3LDExMCw1NywxODIsNSwyMTYsMTQzLDY1LDIxLDQ0LDIwNSw3LDYs MjMxLDMxLDcsMTAsMTgsNTIsMjA1LDIxMiwxNCwyMTcsMjAzLDcwLDEzMSwxNjksMTY0LDE1 NCwxNCwyMjAsMSw1LDE3NCw3NywxMzYsNjksNTYsOTEsMjA1LDI1NCwxMjIsNDcsMTEsMjQ3 LDE0MSwxNDEsMTIwLDg0LDY5LDI0Miw4MCwzMiw0NSw2LDExNywxMDIsMTE1LDE3NSwyMDIs MjA5LDE1LDE4MCw3OCwxMzcsMjI5LDE1OCwxMDgsMTQzLDMyLDI5LDE3NiwyMCw2NiwyNTEs MTg1LDE4NiwyMTUsMjQwLDE5OCwxMyw3MCwyNDMsMTE5LDE3OSw3MCw2Nyw2MSwxNDksMTQs NTksMTUyLDEyLDExOSwxMzgsMzgsMTMxLDExMywxOSwxNjYsMjI1LDU5LDg0LDE0MywxNzYs MTM0LDY1LDIxNywxMDgsMTEsMTgzLDIxOSw0NywxNDYsOTQsNTUsMTQ2LDE4NCw5LDMzLDIs MTE3LDgxLDQ2LDkxLDk5LDE1Miw0MSwxNzgsMjIsMjUyLDEzLDQ3LDgsNzksMjA3LDE5OCwy MzgsMjMsMjIsOTEsNDcsMjcsMjM4LDE3NywyOSwxMTMsNzIsMTIsNDQsMjUzLDY5LDIxNSw1 OCwxMCw2OSwxODgsMTc3LDE5MSwxODUsMjA1LDYsMzIsMzgsMTcwLDE3MywxOCwxNjEsNCwy NSwyMzIsMTMsMjA0LDgsMTU5LDYxLDE4NSw5LDE1LDI0OCwxMTMsMzcsMTI3LDgyLDExMSw3 OCwxOTgsMjE5LDE1MSwxNjUsMTUyLDE2LDIwMywyMDUsNTAsNjQsNjIsNDEsNzQsMjUyLDEy NywyNDAsMjQsMTEsMjUsMjM5LDY3LDMyLDU5LDI0LDI1NSw1OSwxNywyMjUsMjQxLDQxLDk5 LDE5LDQ1LDE4MiwxMzMsMTg4LDI0OSwyMiwyMCwxODUsNjYsMTc2LDY5LDE2MSw3MywyNTQs MTMyLDEzMCwxNzAsMTEwLDE4MiwyNDUsMjE2LDcxLDE2MywyMDQsOTIsMTA3LDI1MSw3NCwy NSwyNDUsMTgyLDE3OCwxMzEsMjM0LDIxNywxODMsMjQ2LDYxLDI0OCw2OSwxODYsMTczLDgw LDE4NCwxLDU2LDEyMSwxOTQsMTkxLDQ0LDI0Miw0NiwyMDgsMTg1LDE4MiwxNTcsMTEwLDE2 MCwxMTUsMjQ4LDEzMywxNzYsMjE1LDI4LDE0NywyMDksOTgsMjMsMTExLDE2NCw0MiwxMTMs MjQyLDM2LDE0MywyNTIsMTc5LDE5OSwxMTAsMjA5LDIyNCwxNjAsMTg3LDE1MywxOCwxNjgs NDUsNiwyMDcsMTExLDEzOSwyMSw1NiwyMDUsNDYsMjksMTg2LDMwLDE2MSwxMjMsNTUsMiwx ODQsNDYsMjA2LDE3Myw2MSwxMjcsMzQsNiwyMTAsMjcsMTkwLDkzLDEyOSwxNDcsMTA3LDkz LDQ0LDExNSwxMjcsMjUsMTE5LDExOSwyMzgsMTgzLDE5NywyNCwyNDcsNzksMTIsMTgsMjks MjMsMTAyLDE4NCw2OSwxODksMjcsMjUxLDIxNywxODIsMTM4LDI0NCwxNzMsMjcsNiwxOCw0 MSwyMDQsMjEsMjQxLDM2LDcsMTMyLDIxOCwxMDMsMjYsNywxNSw0LDUxLDE0Myw0NSwyOSwx MDgsMTE1LDk3LDY3LDgzLDE3LDY0LDEyLDYyLDIwNiwxNjUsNjcsNSw3OCwxNzMsODgsMTI2 LDYxLDI0MCwyMDYsMjAyLDE0Miw1LDgzLDE4LDI0OSwzNSwyMSwxOTUsMTE3LDE0MCwxOTUs MzIsMTEyLDYsMTcxLDIyMyw3NywyMjUsMTA1LDEyMiwxMTAsMTM5LDE5LDM1LDg3LDU4LDU1 LDYxLDI2LDE4MiwyMDAsNjcsMjM0LDMzLDEzNiwyMzIsMjA3LDE0LDI1MywxNTEsMTMzLDcw LDcwLDI0OSwyLDExOCwyNTIsNjgsMzUsMTIsMjYsMTMsMTIsMjEzLDE2LDI0NCwxNjksMTQw LDI0NCwyMjUsMTU2LDI0OSwxNDYsMTc5LDE3NywyMDYsODksMTg2LDMzLDk5LDEzNSwxMCwx NjEsMTgwLDMyLDI0OCwxNTYsMjA1LDIxNiwxOTUsNTgsMjQ3LDIwOCwzMiwxMCwyNywyNTAs MjI0LDQyLDE0MSwxMjUsMTQ4LDE0NCwxOSwyNiwyMjIsMTYzLDIzNCwxMTEsMjksMzUsMTM2 LDE3NiwxMDAsMTEzLDcsMTg4LDEyMywxOTYsMTgyLDE3MywxOTEsMjQ4LDExMSwyMTIsOTMs MTcsMTMsMjU1LDQyLDIzNCwzNCwxMTMsNTIsMjA5LDE4MywyLDEyMyw1OSwyNTAsMTc3LDU5 LDExLDI1LDE5OCwyMCwyLDUsMTIwLDk0LDkwLDQzLDIwLDEyMyw1Miw1LDMzLDE2MSw0Miw2 NiwxOTMsMTg1LDM4LDEwNiw2MSw0Niw1LDE4MywxNTcsMjE0LDI1LDE4MywxODcsODksMTc4 LDI0MiwxMjMsMiwyNTAsMjAyLDE3NiwzMCwyNTMsMjI3LDI0NywyMDEsMTg5LDE5NSwxMDEs MTU1LDc0LDIwNiwxMCwyNiwxMTcsMTk5LDE5MSw3MSwxMjksODksMjcsMzcsMjEwLDI1LDEw OCwyMDYsMTg3LDczLDExNSw4NiwxMTIsMTgsMjU0LDE2OSwxOTQsMjA2LDIxOSwxMDIsMjAz LDIzLDE2MCwxOCwyMzYsNDcsMTksMTgsMjUsMzksMTU5LDU0LDIyMSw0NywxNTYsMTcsNTIs MjQ3LDIwNCwyMDEsMjEyLDIxNSwyMzgsNjEsMTE3LDcsMTg1LDEyMyw1NSwxNiwyMTMsNjMs MjAxLDgsMTg2LDE2NiwzMSw3Miw1NywyNiwxNDYsMzUsMTA2LDk4LDE3OCw1OSwxMDQsMTQw LDYxLDE5NiwyMDYsODAsMTY4LDE3LDQwLDIzOSwxNTQsMjM0LDgsNDQsMTMxLDE4OSwyNiwx NywxNjQsMTU2LDI1MSwxNywwLDEyNiwxODYsMTI5LDIzOSw3NSwyMDEsMTM0LDI2LDE1MSw2 NCw1NCwxMDQsMTA0LDY0LDYxLDEwNCwxNjksOTMsMjE4LDMwLDIwOCwxMTIsMzEsMTU2LDI3 LDU4LDE1Niw3MCwxNzEsNDUsNTksMjQ2LDI3LDEyLDM4LDYyLDI0NiwxMSwzMCwyMDEsOTks MjM4LDExOSwxOTEsMjM5LDE2LDk4LDcyLDE1MiwxODMsMjYsNzMsMjUwLDE0MSwxMDIsMTQ2 LDUwLDEwNywxMzgsMzUsMjIzLDExLDIwMCw3MSwyMDEsMTcsMzksMTEyLDIzNCwzLDUwLDIz MCwxMTgsMTQxLDE0Niw0MiwxMDMsOTEsOTYsMTE0LDIyOCwyMTksMTIsMzIsMTcyLDE0Niw0 NSw4MiwxNDQsNzIsMTUzLDY1LDE0LDQ1LDIwNSwxMjEsNTYsMTI4LDIwOSw4LDExOSw3NSw1 LDIwMyw5OSw4MywxOTgsMTc4LDI0NSw3MSwyNCwyOCwyLDEzOSwyNDEsMjUsNDQsMjIxLDI1 MCwyMjAsMjAwLDI1MCw1OSwxMSwyMzgsMjI4LDEzMSwyMzMsOTAsMjAsMTIwLDg2LDIwMyw5 NCw3LDE3OCwyNDksMTc2LDE3MiwxODUsMjQ1LDExOSw0NiwxMDQsNDIsMjAwLDg3LDIwMCwx NDcsMyw0NiwxMDQsMTAzLDIwMCwxOTUsMCw1NywxMTQsMTQ2LDIwMCw2Miw5OCw2OSw5OCwy NDIsNzQsOTQsMTE0LDEzMiwyMDAsMTUwLDIwMCwxOTIsMjAwLDIyMiw2NCwxODYsNywyNDEs MTA4LDEzOCwxOTEsMTcsMjgsMjI4LDM2LDMxLDExOSwyMzIsMjAwLDUwLDk4LDIxNiwyMDAs MjE3LDE4OCwxNDYsMTUxLDIzNCwyMDAsMzYsMjAzLDIxMywxMDgsMjAxLDE0NywzLDE3OCw4 LDIwMywyMTMsMTA4LDY5LDIwMywzMyw3LDE0Niw4NywxMjUsMjAyLDE0NCwyMDIsMjI4LDIw MSw0MywxMjEsODQsMjAyLDIwNiwyMDIsMjE0LDIwMiwxMjAsMSwyOCwzNywxNjEsMjgsMjQ2 LDIwMCw1NiwxOTMsMTEwLDE5Myw0NCwyOSw0NiwyMDEsNTYsMjcsMjE1LDExNywxMTEsMTEs NjUsMjQyLDY5LDIwNyw1OCw4NiwxODMsNDAsNjgsODksOSwxMTksMjI4LDI1NCwxMzAsNzMs MjQ5LDI1NSw2MiwxMCw4MCwyNTUsMTI2LDI0MiwyMzMsNTQsMTIyLDE1MSwyNDIsMTg2LDg5 LDE0LDgwLDIyNiw0NSw1MCwyMzksNDgsMTIwLDIzMSw5NCw5LDgsMjQ3LDEyLDI0NCw1LDI2 LDIxOCwxMjMsMjcsMjEsMzksNTEsMjQwLDU5LDEyMSwxMSwyNTEsNywxMjAsMTczLDExNywx MjQsMjcsNTAsOTYsMTAwLDIsMTI3LDcsOSwyMTgsMTYyLDIwMCw5LDYyLDYxLDI1NSwxMDcs MTMwLDE3MiwyMDYsMjM4LDQzLDExMSwxODIsMjMyLDksNjIsMTE1LDE1NywxOTEsMjE3LDY4 LDEwNiwyMCw5OCwxNzksMTg5LDQsOTAsODYsMTcsMjUzLDUzLDE2Myw4NiwyNDAsMTkyLDIx MiwxNzYsOTAsODYsMTUsNCw2MSw2Myw4LDE4NSw0OSwyMzIsNjYsMjUsMjAyLDExOSwxMzUs MTIsMTcsMjM3LDEwNywyMzcsMSw2NywxNDQsMTIzLDIxLDYsMTE0LDU2LDIxMywyMywyMTgs MTY2LDE0Nyw4MCw1LDMxLDIzNiwxMCwyNDAsMTM2LDI1LDE3OSwxMjUsMjAxLDE4MywxMDcs MTIsNTEsMTI2LDE3LDIxOSw4NiwzNiwxOTAsOTcsMTQ2LDE0Myw3MCwxMTQsNjcsMTEwLDIy LDIzNCwyNTUsMjI1LDE5Myw5NywxMDEsMjAyLDU4LDM1LDIyNSwyNDEsMTg1LDk0LDMyLDkx LDQzLDIyNiwyOCwyMTMsOTIsMTUyLDksMjI4LDI0MiwzNCwyMjYsMTUsNCw1NywyMzksMjE0 LDIsNiwyMzksODcsOSwxNDMsMjU0LDE1LDEwNywyMzAsMTEsODYsMTkwLDM2LDE0OCw1MCwx Niw1MCwyNDIsNTMsMjIzLDEzLDE1NCwxNzAsNzEsMiw1LDk2LDE5OCw5NCw1MSwyMDEsMTYy LDMzLDEzLDE5OSwzNSwyNywyMTcsNzQsODgsMTE3LDEzMyw1LDQ1LDc4LDc3LDI0NiwxOTks MTgzLDIxMywxOTYsMjQ2LDE0Myw4MCwxMjAsMTAsNzgsMjU0LDE0MSwxNzcsMTMzLDgxLDIx MiwxNzYsMTU2LDIxLDEwLDE1NiwxMjMsMTYsNzAsMjUzLDE1NiwyMzcsMTExLDE4MywzNywx NTgsMjQzLDEyLDE4Myw4LDcsMjcsMjU1LDE1NiwyNDEsMTgzLDEyLDMsMjEwLDExNiwyMDUs MjQ2LDQzLDE1NiwxMTUsMjM0LDMzLDI0MiwyLDI4LDI0MSwwLDE2Miw0OCw3MywxMTEsMjQs MjAzLDEwNiwxMzQsMzAsNiwxMTAsMTgsMjIzLDc0LDg0LDE5MywxNzAsMjEyLDE5MiwyMTIs NjYsMTIzLDk0LDY1LDQ5LDIwMiwxMTAsMTI4LDIwMywyNDYsMTAyLDE1NCw1LDEwNiwxNDQs MjI4LDEyNCw0NCwxODYsMjAsMTEsMTUyLDEwMSw5MSwxMDMsMjEyLDEwLDgyLDIwNywyMTAs MjM4LDk5LDIyMywyMzgsNDcsMjQwLDE1NiwxMjEsMTgzLDM4LDI1MSw0LDc0LDI1MSwxODMs NzMsNjIsOTgsMTE4LDE3MywxNzEsMTg3LDYxLDQ2LDE3NywyNDksMjU0LDY0LDM2LDExMiw1 LDg0LDI0MCwyMTksMTcxLDIzNyw4NiwzMCw4NCwxNTYsNzUsMzIsNTQsMywyNiwxODYsMTY2 LDUxLDExLDE0NiwyMjAsMjAsMjYsNzgsNywyNCwxODIsMTI1LDI0NSwxMDcsNzYsMTQxLDIx OSwyMywyMTUsMzAsMiw2NiwxMjQsMTcxLDIzNywxMjMsNTQsNDAsMTYzLDEzNCwyMTUsODgs MTgsMiw3MCwxMzYsMTE3LDM4LDQ2LDE1NSwxNjAsNTgsOTgsMTU2LDE3LDMsNjIsMTc5LDks MjE5LDIxNCwxMCwyNTEsMTY5LDEyMSwyLDIyOCw2OSwxNzMsMjEzLDU0LDExNSw3OSwxMTgs MjUzLDE0MSwxOSwxMyw5OCwxNywyNiwxMTUsMTMxLDE5LDksNzIsMTg1LDIwOSwxOTQsMTA5 LDUxLDc1LDExNywxMDAsMjM4LDQ4LDcsOTIsMjQ2LDMsMTc3LDExMSw4MiwxNTUsNzAsMTQs MjQ2LDI0Miw0NSwxMTEsMTE4LDEyMiwyMzQsMTQsMywyMzAsMTE2LDE4LDI0MCwyMyw5OCwy MzgsMTIyLDIyMyw4NiwxOTgsMzAsNiwzMSw5NCwxNTMsMTYwLDgwLDE4MiwxNDAsNzUsMTUy LDQsMTU1LDEyNiwyNTAsNSw1OCwxODUsMzAsMTk0LDIwMCwxNjAsOTAsMjE3LDE0Niw1NCwx NDAsODgsODcsMiwyNDMsMjMsMTM2LDE2MCwxODUsMTA4LDI3LDE3OCwxNTUsMjM5LDU0LDI0 OCw1LDEwOCwxNzAsMjYsMTczLDE1NiwxMywxNzUsMjMsMTgyLDExNSwyMTksMTU1LDE5Nyw5 OCwxNTEsMjU1LDE1OSwzLDE4LDI1NSwyMTEsMTMsMTQ3LDIzOCwyOSw2LDEzMCw4MiwyMjks NSwxOSwyMzgsMTc5LDc3LDEzMCwxNjgsMTEsMjUsMTA2LDQ3LDIxNCwxNDYsMjA3LDExOSwx NCw5LDIxLDExLDIxNCwzNCw5MCw3MiwxOTQsNjUsMTgyLDM3LDE2NCw1NSw1NSwyMTQsMzcs MjIwLDE4NSwxMTEsMTIsMjMyLDcxLDE4LDEyMSwxNiwyNDYsMTksMjM5LDEwMiwxOCwyLDEz MCwxODcsMTMyLDIyLDE4MywyOSwxNDEsMzcsMjM0LDksNzEsMTU0LDIwMyw4MiwyNTEsMjQ4 LDcyLDg2LDIzOCwyNDAsMTU5LDc1LDQ1LDE5MCw1LDU0LDIwNSwyMjgsNTIsMjE4LDE0Myw4 MiwyMDcsMTg3LDI0Myw4MiwyNDYsMjMwLDY3LDIxMiwxNzgsOTQsMTgsMjAsMjA5LDIyNiw0 LDE2MSwxNDUsMTQsMjI2LDk0LDIyNiwxMDgsNTUsNzIsNTMsMzgsOTEsMTAxLDk1LDE5MSw5 NywxMzIsMjU1LDIwOSwxNSw4NywxNjEsMjE0LDE1OSwyMzgsMjUxLDI1MSwxMjEsMjUxLDIx MiwxMjcsMjAxLDcwLDIzMCwxODcsMjM0LDM0LDIxNiw4MSwyMzQsMjA4LDExLDQsMjIwLDE0 MiwyNTQsMTU5LDI5LDIwOCwxNDMsMTMyLDc4LDI0Myw5OSw2LDI0OSwxMzIsMjQ2LDE4LDIy MSw3NCw1NCwyMDcsNjAsMjA4LDIsMjQsMjUwLDEzMSw5NSwxNzgsMjQxLDUyLDk5LDMyLDE0 LDU5LDIzNiwxOTcsNDAsMTk3LDgyLDIyOCwyMzUsMjE0LDE3LDIwMCwxOCw1NCwxNzAsMzEs MTEyLDEwMiwyMjcsMjUwLDg0LDIzMCwyMTcsMjEzLDExNiw2LDEyMCwyMDMsMjIwLDcxLDIw MCwxNDAsMTUwLDI3LDI0NSwxNjksMTkyLDM1LDMwLDIzMywxMzYsNCw5MSwxNywxNzQsMTM1 LDIyMiw4OSwyNiwyMzgsNjUsMTIsMTEsMjAsOTYsMTkwLDk2LDEwMywxOCwyMjYsNTksMjEs MzMsMjM3LDE3OSwyMzMsMTc4LDEwOSw0MCwyNTUsMjUyLDgyLDMyLDI0OCwzMiwxNTYsNjEs NTQsMTA3LDEwNywyMDMsMzgsMTEzLDIwOSw2NywxNTQsMzYsMTg3LDE1Myw4NiwxMjQsMTM0 LDExMSw0OSwyNTMsMTAwLDEwNCwzNSwxNzYsNDgsMTIwLDI0MiwxNzEsMjA3LDQzLDIxMSw1 MSwyMTEsOTgsMTg0LDEyMiwxOTIsMjMyLDIyNiwyMjcsMTQ2LDI0OCw5OSwxOTAsOTMsNywx MTksNTUsMjgsMTIyLDE4LDkyLDU2LDE0NiwyMDMsODcsNDEsMjQsMjQ0LDE3MCw2Myw4Myw2 Myw5OCwxMCwyMTcsMTQ2LDIxMiwxMjQsNzMsMTA5LDIwOSwyNywzNywxNjksMTAzLDgxLDE0 MSwyMDksOSwyNDUsMjE4LDUxLDEwMCwyMzAsMTc2LDEzOCw2MywxNTAsODIsMTY5LDk5LDI5 LDIyOCwxNzYsNjIsMTY4LDE5NCwyMDksMTE2LDE0NywyNDEsNTksMTYyLDE4OSwyMTEsNjks MTQ0LDIzOSw1NywyNDUsNzcsMTc4LDI1MiwxNzksMjAsMzEsNjEsNzIsMjAwLDI3LDExMyw0 MSwxNzcsNDEsMTA4LDEyNyw2LDE1NiwxOTcsNTcsOSwxNzMsMTQ2LDY2LDI0MSwyNTAsNTUs NywzMywxNTksMTEsMTkzLDIzNCw1OCw2LDIxMCwzOCwxOTMsMjMzLDE2MywyMjMsMjAxLDE1 LDIwMywxMzksMjEyLDg4LDI1MywxMTUsMzAsMjEwLDUwLDIxMiwyMTEsMjEwLDE5OSwxMTAs ODAsMTY5LDIyOSwxODUsMzIsMTQwLDIxMSwyMSwyMzMsMTEzLDIyMSw4MiwyNTUsMTk5LDM0 LDE4LDY3LDExMywxMzAsMjM4LDI0OSwxMzAsMjM0LDE2OSwyMzMsMjExLDEwMiw5NiwxMjIs MzksMTkxLDE0NywyMTAsMTczLDE4NiwxMjEsMjExLDE0OSwxMjMsMjE3LDExNywyMTEsNzcs OSwxMywxNTEsMTQ2LDM4LDI1NSwzNiwzMSwxOCw3LDE1OCw4NSwyMzQsMjU1LDIzMyw1MSw0 NCwxOCwyMjMsMTI1LDMxLDI0NiwxNDYsMTMsMTMsMTcwLDQ3LDE4MSwxNDMsMzgsMTAsMTk4 LDExNSw2NiwyNCwxOTIsOTMsMTk0LDIyMywyLDEzLDExNCwwLDExLDk1LDIyMSwyMTAsMTM1 LDE1NiwxMywzMywxNTgsMTEzLDE0NSwyMTAsMTc3LDIyMiwyNDgsNDksMTcyLDE1NywxNTYs MjU1LDE4MSwyMDAsMjQ2LDE4NCw2NCwyMDcsOTAsMTgyLDE5LDIwNywxNzAsODMsNDMsMjYs MTk2LDg2LDE4NCw2LDIzOSwxNDcsMTcsNzcsMTE1LDkyLDE2OSwyMjgsMTg0LDIzNCwyMzgs MjIyLDMzLDc2LDMxLDE2OCwyMzcsNDYsOTksMjM5LDE3LDUsMjAwLDE4LDIxLDI3LDIzNCwx OCw4NSw5LDE4OSwxNjksNDcsMTMyLDEyMCwxODIsMjU1LDIyMSwyNDIsMTA0LDIyMSwxNTUs NTAsMTY5LDE1MSwxODQsMTQ5LDI1MSwxNDQsMTU4LDE4LDE0LDI5LDI0MCwxMTcsMTQwLDIx OSwyNTUsMTQyLDk5LDQ1LDk0LDI0MCw0NSwyNTEsMjQ1LDE2MSw5LDU1LDE2NywxNDUsMjAz LDY2LDEyNCw1Miw5NSwyMTAsMTcsMjA4LDI4LDM2LDQ4LDk5LDE2LDEyMCwxOTIsMjYsMjIx LDE5OSwxMDMsMTM5LDIwOSw1MCw5NywyNSwxNDYsMjAyLDk5LDM2LDExNSwzMiw3LDI0Niw1 MCwxOCwxODEsMTIsMTg0LDIwNywyNTIsOSwxNDIsNTcsNyw3NiwxNDUsMTAsMTI5LDIzNyw4 OSwxNDYsOTksMjA3LDUyLDIxNiwxODMsMTU4LDQsMTU0LDM4LDg2LDQ4LDcsNTcsMjM2LDM3 LDE4NCwxMjAsOTksOTYsOTAsMTY5LDEyMywxNTgsMTgyLDcxLDE0LDI3LDI2LDE0LDE3NSwz OCwxNDQsMjUyLDg0LDE0MywxMzksMTQwLDI4LDIzMCwyMTEsMTYxLDE5NiwyMiw3NywyMTcs OCwxNTksMTIxLDIyLDE4LDYyLDcsMTgyLDEyOCwzMCwxNDgsMTQ2LDE0NSw2NSwxODYsMjMs OTAsMjA2LDE4LDE1MCwyMjgsMjE5LDEwMCwxMTQsMTk2LDI2LDE4LDExNSwyMjEsMTIsMTUz LDIyNiwyOCwyMDAsMTM4LDE1MywxNTEsNDUsMjE3LDE1MCwxODgsMTIsMTgsMTgsMjI0LDI1 LDI0Nyw1MiwyMjMsOTQsMTc5LDc1LDI1MCwxNDQsMzUsMTIsMzAsMTgsMjQ1LDIyMCwxNTgs NTgsMjE0LDEzNSwyNiw4NywyMDgsOTUsMjgsNzQsMTgsMzgsOCwxODMsNjEsMjI0LDgyLDIz Myw2OCwxOTUsMTA0LDE4LDU1LDk5LDk5LDIyMCwyMywxNzUsMjgsMTQzLDE3MCwxOSwxMDMs MTgsNTIsMjMxLDQ0LDIyMSw1OSwxMDcsNTUsMTQsMjMsNjUsNDUsOTAsMTU4LDE4MywyMzMs MTQ2LDE1NiwyMjEsMTksMTQ5LDE0NiwyMDcsMTYxLDEyNyw0NiwxODgsNDksMTMsNTgsNDQs MjM4LDI1NSwyOCwyMDAsMjQ1LDEyMCwzMywxNDgsMTkyLDIwNywxNzcsMjUwLDE1LDE1LDMx LDE3MCwxMzYsMTM1LDQ5LDUzLDE4MiwyNCwxODMsMTg3LDEzNywyMjMsMTYzLDEwLDM4LDY3 LDI1MSwxMjIsNzAsMTkyLDYxLDE4NCwxMCwzOCwxNDksMTQ3LDE4LDI0Niw3OCwxODYsMTU5 LDcsMTkzLDIyMywxOTksMjU1LDIzMCwxMTQsOSwxNCwyMDUsNzAsNTcsOTcsNyw4MSwxMzgs MTkwLDIxMSwyNTIsMzgsMTg4LDI0NywxOSwxNzksMTM4LDc3LDIzOCwyNDIsMCwxMzIsMTc5 LDE1NywxODcsMTksMTAxLDExMCwxNDUsMTM2LDIyNCw0NiwxNzksMTE5LDE0Nyw3MSwxNTQs MjIzLDMwLDQ2LDgsMTIyLDIzOCwxMzYsMjM3LDIyOCwyMzYsMjQyLDE0NiwxNjksMTkzLDEw LDE3LDE1OCwyMiwxODAsNTQsNzIsMjE1LDE4OCwyMzYsMTQsMTgzLDIxOCwyMjQsMjQ2LDM0 LDIzMSwxNDQsMTA5LDExNSwyMDcsMTcsMjI1LDE2LDIxMCwxOTcsMjIyLDMzLDE1NiwxNzks MjQwLDE2NCwxOTIsMTY2LDE2MywyMDksMTI0LDYzLDIxMiwxOTUsNzgsMTQ2LDIyMiwyMTEs MjMyLDE0NiwxNjYsMzQsMTYyLDIzMSw2MiwxOTUsOTYsMjEsMjM0LDE2OCw3LDI4LDI5LDM3 LDIyMiw5LDIxOSwyMTYsMTAsNywzMCw4LDIyMiwyNDYsNTIsNyw1MCw3MCwzMSwyNyw1NSw2 MCwyMjIsMTg3LDU3LDIsNDIsNTQsMjI4LDgsNTUsMTMwLDE3LDg2LDY2LDg1LDMwLDEyNCw1 NCw1NSw4MSwxMTQsMjYsNDcsMjUzLDI0LDI1MSwyOCwyMjcsNDQsMTAwLDE5OCw1NCwzOCwz NCwxNzAsNDEsMzAsMTEwLDQyLDMwLDQ2LDE0NywxNTcsNDUsMTIsMzQsNTIsMjE3LDE5LDI1 MSwxNiwxMywyNDEsMTQxLDE5OSwyMDEsNTgsMTcsMjQ5LDE0NSw1NywxMjksMTE5LDc1LDEz NSwxNDMsMTcyLDIzOSw0LDI5LDExMywxMCw2NSwxOTIsMTcyLDEyOSwxODgsMTYsMTYyLDE4 NSwxNTcsNjcsMjE3LDU3LDgsMjQxLDU3LDE3OSwyMjIsMTk0LDE2OSwxNTIsMTkyLDIyMywy MTcsNjcsMTM2LDI0MywyMzMsMTk1LDE2MCwxNjYsMzAsNTcsMjM4LDYsMjE5LDI4LDIzOSwx Nyw2MiwxMiwyMDIsOTQsMTQ2LDg2LDI0NywxOTUsMjI0LDIzMCwxODYsNjUsMjE2LDIyLDE1 MiwxNjEsMTY0LDkyLDIzNywxMjYsMjEsMTA2LDIxNyw5Nyw4OSwxMDIsMjQsMzgsMTQwLDI1 LDIyMiw5NywxNzYsMjE3LDQzLDIzNywyMjUsMjU0LDI1MSwxNjgsMTMxLDU4LDcsMTUsMTIz LDI0NiwxNzgsMTQsMjMyLDIyMiwyOSwyMDQsODQsMTg3LDIwLDE2OCwxMDAsNTQsMzEsMTgz LDUwLDIxOSwxOTEsMjUxLDIwNiwzNCwxNjUsMzYsNzUsMTksMjU0LDQsMTIzLDEzMCwyNTEs MjE1LDE0MywxMzgsMjExLDE4MSwxMTAsMjUzLDE1OCwxNDIsMjQzLDE4NiwxMjIsMTMwLDM4 LDE0MywxMCwxNzEsMTExLDI1MSwxNDEsMTI1LDI0NiwyMjAsMzAsMTUwLDQ0LDcxLDE4LDU5 LDIxNywyMTQsMTQ4LDIzOCwxMzUsMTY1LDE1LDI0MCwxNDMsMjM3LDExMCwyMTcsMTM5LDE0 NiwxLDk4LDMxLDE5MCwyMDMsMjIyLDIxNSw1Miw5OCwxOTMsNDIsMTM0LDk3LDE4MSwzMiwy NTAsMyw1NCwxMTQsMTkyLDY0LDE2MCwyMTYsMjIwLDM1LDIwOSwxMTgsMTc1LDEwMCwzNSwx NDQsMzksMTksMTc2LDE4NiwyMjIsMTc4LDE4NSwxMTUsMzYsMjcsMTgzLDIxNiwyOSwxMjQs Miw4OCwyMjAsMTE3LDEyNywyNTEsNTcsMTQ2LDQyLDI1MywxNTQsNSwyNSwxNywyOCw1Nywy NDcsMTE1LDIyNSwxOTIsMjAxLDI1MCwxNDYsMTI2LDEzMCwyNTAsNSwyNTMsMTIwLDIxNywy MzgsMTA3LDI0LDE4Niw1LDI1MCwxNiwxNjQsMjE3LDEzNywxNDMsMjI1LDc1LDIwLDM0LDEz NSwxNSwxNzgsMTU1LDExOCwyNDYsMTIwLDQ3LDIyLDExOCw2LDI1NCwxMTMsMjQ0LDIyNiwy MCw4MSwyNDYsMTA5LDQ5LDYyLDExMywyMDcsMzYsOSwyMjMsMTIsMjMwLDEyMywxNTMsMjE5 LDU3LDQwLDE3NCwwLDE3LDIzMiw1MCwxMywyMTIsNjcsMTY4LDExMSw1NywyNTAsMTQxLDE0 LDQsMTQ4LDIxNywxMjAsOTksMjE4LDEyNyw4LDYyLDIsMTE3LDIwMSwxOTgsNTYsMjA1LDI0 LDI1MSwxNDIsODQsMTE3LDUsMzUsMTgsMjA3LDEwLDM2LDEzNyw1NiwxMjUsMTg0LDIyLDIx OSwyMzAsNTMsMjE2LDExOSwxNDQsOTcsMTYwLDI0OCwxLDE1MiwxNzIsOTAsOTAsMTgzLDEy MiwyNTIsMjIwLDIyNCwxNTgsMTA5LDIzNCwxNDYsMjM4LDExNiw2OCwxNCwxOTAsMTIzLDEs MTc3LDEyNSwxMjMsNjMsNzUsMTQwLDI1Myw2Nyw2LDQ1LDExMyw0OSwyNSwyMDMsNjksMTcx LDIxMywxOTEsOTUsMTc2LDIzMSwxMjIsMTI1LDEyOSwyMTYsMjI4LDEzMiwyMjgsMjA5LDM0 LDE0LDExNywxNzgsMTE3LDE4LDIzMiwyNSwxNzAsMjQ2LDIzMCwyMzIsMTgzLDIxOSw0NSwy NTUsMTQyLDI0OCw1MCwxNyw3MCwxMDIsMTI3LDMzLDI0NSwxMTAsNTgsMTA4LDkxLDQsMTA1 LDE3LDIzOCwxNzUsMzMsMTAzLDIyNiw1OSwxMjgsMTEsMjQyLDIyMCwxNjUsMTU5LDg1LDE5 MCw5MywyMjYsMjI4LDIyMywyMDIsODAsMjM4LDE5NCwxOCwxNDMsMjQ4LDczLDI1MSwzNCwy NDUsMTQ2LDIwNSw5MywzNCw5NCw3Miw4Niw0MCwwLDU5LDI0MCwxOTMsMTkxLDU4LDM3LDk3 LDIyOSwxMTksMjE2LDIyNSwxNDIsNzAsOTUsOTgsMTQsMzEsMjQyLDMxLDEzLDEwMSwxOTAs NjcsODksNDMsMTM2LDE5MywyNTUsMTcxLDMxLDQ2LDEwOCw2NiwxLDE1Nyw0MCwyNiwzNiwy MzgsMTQ0LDI0MCwxODQsODcsNDQsMjA1LDU1LDEzNywxNTIsMTI3LDE4OSwwLDIzNiwyOSwx MDIsMTkwLDQ5LDE4NiwxMjAsMjU0LDUzLDEyMCwzMCwyNDUsMTU1LDExMSwyNDYsMjYsMTE1 LDEyMiwxMzUsNCwyMTgsMTQzLDI0MSwxOTAsMywyMzcsMjYsMTY3LDMzLDIxMywxNiwyMTUs MTQyLDE2MCwxNjksODksMjQ0LDE4NiwxMywxMjIsNSwyLDUwLDIxOSwxMzIsNzUsMTc0LDI1 MiwxMzQsMjI0LDE2NCwyMTksMjQ0LDE3NSwxNTQsMzUsMTUxLDQ2LDIzLDY1LDEwMiwxMCwx NzgsMjYsMTAsMTMwLDkxLDI1LDEyOCwyNDgsMjA1LDE4MywxODMsOCwxNTgsMjI0LDYsMTA4 LDMsMTQyLDI1NSwxMzUsMTcsMjI5LDE0LDI0MCwyMzksNzUsMjA4LDIsNiwyMCwxNywyMjMs MTcsMjQ1LDE2Niw0MywyNDYsMjA2LDIwMiw3MCw3LDY3LDIzOCwyMDYsNjgsODUsMjA4LDIw NCwxMTgsMTE4LDQ2LDIxOCw4OSwyNDIsMTAsNTcsMTEzLDE3NiwyMTQsMTYsMjM0LDExLDIy OSwxMTgsMTA4LDEyNyw5LDcyLDExNCwzMywzNywxNjAsMjUyLDExMywxNDAsMjU0LDEyNCw2 MiwxMSwyMiwxNzYsMCw0Myw4LDIyMCwxNjYsMjE2LDI1MywxNTQsNTksNzcsNjUsMTU5LDEw OCw5NSwyMjksODYsMSw1LDQ1LDIxMCwxOTUsMjM4LDQxLDMzLDE3LDE1NiwxMDcsMTY2LDIx OCw0MSwxMjgsNjgsMTM1LDEwOCwxMzMsMTc0LDc2LDEzLDEzNiwxODgsMjM2LDIxNywxNjks MTc4LDEzMSwyMzQsMzcsNDAsMjE1LDIxOCwyMzgsMTgzLDIyNSwxNjYsNjMsMjA4LDEwNywx MTMsMjM5LDEzMCwxMjEsMTIzLDAsMTQsNDcsMTM3LDIzMywzNSwyMjIsMTEzLDE2NCwxNDIs NzAsMTcyLDEyMSw3MCwyMjgsODksMjUyLDE3MSwxOCwyNDAsNTEsMTc2LDE3NiwxNjEsMTcx LDY0LDI0MSwyMDAsMjQxLDM3LDEyMCwxODAsMTMyLDk0LDE3NSw2NSwxNDYsMTY2LDE5MCw2 OCwxMDQsMywyNiwyNDEsNDEsMjI5LDE3Miw0MCw2NiwxNTksOTgsMjI3LDExLDE4NiwyNTQs MjU0LDE1MiwyMzgsMTgwLDExNyw2OSw2LDIwMywyMjIsODQsMTU3LDE0NSw0NSwxNTAsMSwx MDUsMTExLDI0MiwxMjIsMTY0LDE1OCwxOTYsNTIsMjI4LDUyLDIwNywyNTQsNDQsMjQyLDE0 NiwyNDQsODYsMjIzLDE5LDEzLDU2LDM5LDE2NywyMzMsNjIsMTM1LDIxNCw4NSwxNzksMjM0 LDEwLDEsMjM4LDIzNiwxMzQsMTc4LDU1LDgyLDc3LDE4MiwxMTAsMzEsMjA3LDE4NiwyNSwy MzQsMTg2LDE5NCwxNjEsMjExLDExMywyMiwxMDUsMTcyLDI1MiwxNzQsMTIzLDM5LDIzLDE5 NCw3NywyMjksODUsNyw3NSwxNDksMTAwLDE2MCw2OCwzMSwxNjEsMTA1LDE5LDE3Myw2OSwz NSwxMzIsODAsMiwzOSwzNiw5MCw4Myw1LDU4LDIzLDE2NSwxMjEsMzQsNTUsMjQ2LDg4LDY0 LDE3OCwxNDAsNjIsMTM2LDIyLDE1LDEwMSwyMzUsMjQ0LDIzOSwxOCwyMTIsMjA4LDIzNiwx MjEsMTQ1LDYsMjUzLDM5LDEyNSwxNiw2MSw2NCwxNTAsNzUsNjksMTUzLDIyOCw1NCw0Miwy MDAsNiwxMzksOTQsMTM1LDI1NSwyMzEsMjE3LDE4MywxMzEsMjIxLDIyLDIzNCwyMjgsNDks OTAsNDQsMzksODUsNjUsMjAwLDI1NCwyMTQsMjA1LDI1MywxMTQsMjUzLDE0NiwxMDUsMjIy LDE3LDE0LDM4LDEwMSwyMDEsNTcsMTc3LDEzMSwyMCwxNjEsOTEsMjI3LDEzMSw3MywxNzQs MTcwLDE3Myw1Miw1LDIwNywxMzEsMTA4LDE4NSwxMzUsMTUwLDIsMjQwLDYyLDEwOCwxMTAs NjAsMjAzLDE1MCwyMzMsMjIwLDEyNywxMzIsMTU0LDYsMTMzLDkyLDI0Miw4NCwxMjAsOCwx MDIsNTEsOTAsMTMyLDEwMywxNTYsMjMxLDEwNCwxOTYsMTc5LDYyLDIwMiwxMDIsMTczLDE4 LDEyMiwyNTEsMTE3LDE0LDgyLDEwNSw4MiwyNTUsMTA3LDExOSwxLDE0NiwyMDQsODcsMTEw LDY2LDEsMjQ5LDMyLDE4MiwyMjcsNTMsNywxNjQsMjE2LDg4LDEwOSwxODcsMjcsNzEsMTE3 LDIzOCwyMDcsMTQyLDEwOSwxNDAsMjQzLDgsMjQxLDEzNiwyNTUsMTksNjgsNjAsODMsMjUw LDI1LDEwMCwxNzYsODgsMTEsODgsMTAzLDg4LDExMCwxNzcsMzYsNyw5LDI2LDM4LDkxLDc2 LDQsMTQxLDk2LDExMCw2NiwzMSwzMiwyMCwyOCwyMjEsMTA4LDI5LDExOSw1LDE5MywyNTUs MjQyLDI1LDE0Miw5MywxNTQsMTIyLDE5OSw5Niw2OSwyMzIsMTc2LDIwNSwyNTQsMTMsMTkz LDMzLDIwMywyMjEsMTEwLDExOSwxMywxNTksMTIsMTQ2LDE5Myw4NSwyNiwxOSwyNDQsNjYs NTQsMjA2LDksNjcsMjU0LDE5OSw0Niw3LDIzNSw0OCwxNzEsMjEsMTk2LDM2LDYwLDI1NSw2 MCwxNywyMTcsMjU1LDI1NSwyNTUsMjU1LDE1OCwxNDksMTQ4LDIyMSwxNDIsMjE4LDE1OSwx NDAsMTU5LDE0OCwyMTgsMTQyLDEzNiwxMzEsMjE4LDE5MiwyMTUsMjExLDEzNSwyNDEsMjAs MjQzLDExNSwxNTcsNDksMjM4LDkyLDExNCwzMSwxNzAsNzksNzYsMjU1LDI1NSwyNTUsMjU1 LDMxLDg2LDEyMywxMDIsMTM1LDE1MywxODYsMjAyLDIzLDc0LDQ5LDE4OCwxNzUsMTMwLDI0 NCwxOTgsMjI5LDY0LDIyMiwxLDg2LDI0MCwxNjAsNjUsOTAsMjE5LDE3NSwxODAsODAsMjIz LDkwLDEzNCwyNTUsMjU1LDI1NSwyNTUsMTU2LDc5LDIyMiwyMSw2OSw3NCwzNSwxODEsOTgs MTk1LDE4Myw5MSwxNjcsMjE1LDI1NCwyMjgsNzMsMTMzLDQ2LDE1LDM3LDgwLDE5NiwxNzMs MTI3LDUzLDE0LDIwNSwxMDUsMTQ5LDIxMSw5NSwyNTUsMTMsMjU0LDI1NSwxOTMsMTY1LDY0 LDEzMSwyMzcsNTEsMzMsMTgyLDI1MCw0OSw1MywxNjQsMTIzLDIwLDc0LDc2LDExMSwxMzcs MjAyLDIyLDIwMSw3MywzMSwxNTAsMjU1LDI1NSwyNTUsMjU1LDIzLDEyNyw4NywyMDcsMTk1 LDI0MiwyMDgsMjEwLDIwMywyMTQsMjMxLDEwMywxNTksMjMyLDYwLDE1OCwxOTIsMTc1LDk1 LDIzNSwxOTYsMTQ0LDIzNSwxOSwzMywxMDAsNDIsMjM4LDE5Miw2Nyw5LDI0NiwyNDgsMjU1 LDI1NSwxNjUsMjMwLDIyLDIzMyw4NCwyMzMsMTg1LDI0NSwxNzgsMjMzLDE1MCwyNDgsMjI4 LDE2MiwyNDQsNjIsMjQxLDIwOSwxMSwxMywxMjUsODAsMzUsNTMsMjU1LDI1NSwyNTUsMTY1 LDE1NiwxMTcsMjMzLDQ2LDE4OCw1NywxMjMsMjUyLDExMiw0MywzMSw0MSwxMjIsNjcsMjMz LDEzMSwyNCw0MywyMDIsMTQ1LDM4LDI2LDk3LDE4OCwxMTEsMTgsMjU1LDI1NSwyNTUsMTkx LDE0OCwxOTUsNjcsMTc1LDE2MiwxNTQsMTgyLDc4LDIyNyw5MSwxMTYsMTU4LDExMiwxMjcs ODIsMTgxLDY1LDIyLDU3LDM2LDEwMCwxMDgsMjIxLDI1MiwxOTEsMjA5LDIyMywyMzIsMjM1 LDcsNDIsMjI3LDExNSwyMDEsMTQ3LDY3LDExMSw0Myw0NSw1Nyw0NiwxMjEsMTQ1LDI1NSwy NTUsMTI3LDE2MSwxNDYsMTU2LDE0NCw0NSw4NCwxMzEsODcsMzQsNTgsMTIwLDM3LDE3NCw3 OSwxMTUsMjM1LDE4MCwxOTUsNiwyMjIsMTg5LDIzNiw0LDU2LDI2LDI1NSwyNTUsNDUsMjU0 LDE0MCwyMiwxMDIsNTMsNjksMTkzLDE3NCwyMDcsMzMsOTYsOTIsNzYsMywyNDIsMTEwLDY0 LDE1OCwxOTQsMTU5LDE5NywyMjIsMTg4LDE2MywxODEsMjU1LDI1NSwyNTUsMjU1LDkyLDE3 NywxNzQsMTI0LDExMCwyNiwxMDcsMjIzLDIsMzQsMjQsMzAsMTY2LDEwNCwxNzgsMjQ3LDI3 LDMxLDM5LDgwLDc1LDEwNSwxMTgsMTA0LDI0NCwyMDUsMjEsMjI1LDE0NSw0OCwyMDgsMjI0 LDI1NSwyNTUsMjU1LDI1NSwzLDM2LDEwMywxMDEsNjAsMTY2LDE0OSwxNjQsMjEyLDExOCwy MzYsMTg4LDI4LDY3LDE5NCw1MCwxOTYsMjQwLDEwOCw4MiwyMDYsMTA2LDIzNSw2NSwyNDIs MTc5LDIzMiwxMTQsMjksODUsOTUsMTYwLDE5MSwxOTMsMjU1LDI1NSwxMDUsMjEyLDIxLDQ2 LDE2OCwxNTYsMTA0LDUzLDM5LDc4LDE4NSwyOSw1NiwxMTIsNjksNjIsMTIwLDIxNiwxMywy MCw0MCwyMTgsMzIsMTk3LDI1NSwyNTUsMjU1LDI1NSw1Nyw2MSw5OSwxNzUsMTM4LDExMiw2 LDEzMCwyMjgsMjQzLDkzLDE5LDAsMTgzLDE3NCwyNDAsMTQ4LDQ0LDExMSwxMzQsODMsNzMs MTY4LDY2LDEyOSwxMDEsMTcwLDYxLDEzMywxMTYsMTUyLDE4MCwyNTUsMjU1LDI1NSwyNTUs MjMzLDk3LDIwOSw3MCwxMDUsMTIyLDIzNiwxMTcsMjQ4LDE3Nyw3NywyMjQsNTQsOSwxMDYs MTE2LDYzLDU4LDIxNSw5MSwyMjYsMTQ0LDIxNCwxMzQsMTk3LDE3MiwxNzksNjEsMTQ1LDks NjAsOTEsMjU1LDI1NSwyNTUsMjU1LDE1MSwyMywyMDksMjI4LDExNywyMzQsMjI0LDE4OSw4 OCwyMTcsMjA2LDQ1LDE5NywyNSwxMjksMjEyLDE5NiwxMTksMTIzLDIyNCw5NCwxNjYsNjIs NTIsMTQ0LDE4NCwxMjcsNzksMTM0LDE1NywxOTAsMTQ5LDI1NSwyNTUsMTQxLDI1NSwyMjIs MjQ1LDE2Nyw0MSwyMzQsMTk4LDg3LDI0NywxMzksMTI2LDE4Niw2NiwxNTQsMTEwLDE1OSwy NDksNywxMiwxNTAsMTcxLDE5OSwyMTMsMTY1LDc5LDE5NSw1NiwyNTUsMjU1LDI3LDI1Myw1 MywxNjUsMyw1OSwyMzYsNTEsNDQsMjAwLDE1Niw5Miw4NCwyNDMsMTI4LDE3NCw0Miw2Miwx NTIsMTg3LDEwNyw1NywxNjksOTcsMTAwLDE2NCwyNTUsMjE5LDI1NSwyNTUsMTc2LDE5Miw4 LDE5NiwxMjYsMTksMTg5LDExMiwyMTMsMjQ2LDg2LDUwLDcyLDY3LDI0Miw4NywxNjIsMjM2 LDEzNCw0OCwxMzMsMzMsNTgsNjksNzMsMTU3LDE1OCw0NSwyNTUsMjU1LDI1NSwyNTUsMTU0 LDE5NywzMCwxMDYsMTMwLDY3LDI1MywyNTMsMzksMjE0LDcsMTk3LDE5Miw2NSw2OCwxMzEs NDMsMTg4LDEyNCwyNSw5Miw1OCwyMzAsOTgsNTIsMTAwLDEwMCw4MSwyNDksNTAsMTc1LDEw NCwyNTUsMjU1LDIxNCwyNTUsNTAsNzksMjIxLDEwMyw1MCwyNDksMzAsMTU1LDI2LDg2LDEy NSwxMDQsMTU2LDIzOCwyNTMsMTMxLDEzOCwxNDUsMTg1LDUwLDUzLDc5LDEyMiwyMzUsMjA0 LDIwMCwyNTUsMTUxLDI1NCwyNTUsMTgyLDE2NSwxNzQsNzYsMjQ3LDI1MywxMTUsMjU1LDEy OSw2MSwyNywyMzMsMTAyLDIxNSwyNDMsMjA0LDMxLDIxNiwyMDUsMTk4LDYzLDEwNiwzLDI2 LDE4MiwxNjIsMjU1LDI1NSwyNTUsMjU1LDU5LDQ5LDI0Miw2NSwxODYsMjIwLDkxLDIyNCwy NTIsMzMsNjMsODksMzEsMTg0LDIyMywyMjksMjksMTgzLDE5MywxNTEsNTEsMTEwLDIzMSwy MzksMTU0LDI3LDQyLDIyLDU0LDIzMCwwLDE5MywxOTMsMjE5LDI1NSwyNTUsODIsMzEsMTQx LDI5LDUsMTkyLDExMywyMTEsMjM4LDE3Nyw4MSwxODksNDYsODYsODEsMTcwLDExNCw2Nyw3 NCwxMjEsMjAzLDE0NywyNTUsMjU1LDI1NSwxOTEsMTcsMjQxLDQ1LDEwMyw0NywxMzQsNDIs MTAyLDc4LDE4OSwxNjIsMTY1LDE0MCwxMzQsMTgzLDg4LDk2LDE4NCwxMTksNjksMTgxLDk5 LDE0LDIxLDcxLDI1LDQwLDIwOSwyMCwxNzUsMjM0LDI1NSwyNTUsMjU1LDgxLDg1LDE2NCwz NiwyOSwyNTIsODgsMTc4LDIzOSwxODcsNiwyMDgsMjEsMjQ3LDIxNywxNTQsMTc5LDE2OSw3 NiwxMDEsMTgwLDEzOCw2LDE2Niw1Nyw1MSw1OSwyNTUsMjU1LDQ3LDIwOCwxMzEsMTY1LDQz LDg1LDIsNDUsMTU1LDIzLDIxOCwyMDUsMTI5LDIyNCw1MywyMDQsNjIsODEsMTU5LDEzNyw1 OCw5LDgyLDEwNiw3LDM1LDI0OCwxMTQsMyw0NywyNDUsMjQ5LDEyNSwyMzgsMjI0LDcsNjks MTEwLDEyNSw1NCwxNjAsMTAyLDIwNSwyMjcsMTAyLDEyMSw3MSw3LDIwMywxMjQsMzEsMjEx LDExMCwxOSwyMTcsMTMzLDE3NCwyMjcsMzcsOSw1Niw2LDE0LDE2NSwxNjQsOTMsMjQ1LDMs MTUsMTE4LDE2NCw1LDI1NSw4OCwwLDE4LDE0NCwzOCw4OCwxNTIsMCwyMTEsMTAyLDI1MSwy MTUsOTIsMSwxMjQsMzUsMjA5LDEzLDI1MywyMywyNCwyNDIsMTg5LDIxNywyNDksMjUwLDIy MywzNSwzNCwxNiw2LDE3LDQyLDExOSwyNTMsNzUsMTA4LDEwLDExOSwyNDIsMTIyLDE5Niwx ODUsMTQzLDIyNCwxMjIsMTMyLDE2MiwyMzgsMTU2LDEyMSwyNiwxOTMsMjIsMTI4LDEzMiwx MjYsMjQ3LDY5LDUwLDEyMywyMjMsMjMsMTM0LDEzNCwyMDAsMjQyLDEzLDE1OCwxNDQsODMs MjUsMjA0LDIyMiwxNjYsMjM0LDUsMjQ3LDEyMywxNDcsMTYzLDQ0LDIyNiw4LDYwLDE0Niwx NzgsMjQ4LDIsMTUzLDIyNiw1NSwyMjYsMTMxLDIxLDIzOSwyLDE2LDgzLDIzOSwzNCw5Miwx ODYsMTg2LDIwMCwxNSwxMTAsMjAsMTQ5LDE0MywyMzksNDksMTkxLDIyNiw0NSwyMDcsMTU0 LDEyOCwxMzIsNzcsMzgsMjEwLDExMyw1NCwxODMsMTIsMjM2LDE5LDEyMiwyMzQsMjUxLDg5 LDI0NiwxMzgsODksMjI2LDMsMTM1LDI4LDM1LDI3LDI0MSwyMjYsMjIsMTcwLDIxLDcxLDIy NiwyMTYsMjQ2LDIyMSwxLDQ1LDIyMywxNCwyNDgsMjA1LDIyMSwxMTEsMjEyLDUwLDEyLDE3 NSwxNTYsNTksMTgzLDEyLDI0MiwxMCwyLDI1MSwyNTAsMiwxMCwxMDIsMTQ3LDEzMCwyNDIs MTQ1LDQ1LDI4LDE5MiwzLDY5LDE0MSw3NywyMjYsMjE0LDI1Miw2LDExMSwzNCwxNzYsNDUs NzQsMjEyLDYsMTYyLDExMywzNywyMDksMzIsMTIyLDIwMyw5NywyNTUsMTEsMTAyLDIxMiwx NDMsMjUxLDE3NywxMTUsMTY3LDEwLDE3MSwxNjgsNTQsMjUxLDEwLDEwOSw3MiwxOTMsMzIs MTYzLDIyMCwzMSwxNzYsNjMsMTM5LDEwMiwxNyw2MSwxNjMsMTI3LDUxLDE0Myw2Niw0OCwx NTUsMjI4LDIxNyw1LDEzMywyMCwyNDUsMjAsMjQ4LDI5LDE0NCw2Niw2LDEwMCwyMCwyNTEs MTE5LDE1OSwxNjUsMTUwLDI0MywxNDAsMTM0LDY3LDIwNywxMDUsMTI0LDU1LDE3MSwxOTIs OSwxNTIsNjUsNzEsMjI2LDEzOSwyNDYsMTc2LDE4NCwyNDQsMjksMjUwLDE4Myw3OCwzMiwx NywyMTcsMTc2LDEzOSw1MSw2Nyw3OSw3MSw2LDE0MCwzOCwyMzcsMTMwLDU1LDU3LDg2LDIz NywyNywzMiwyMiwxNDUsNTYsMTIzLDE3OSwxODEsODMsMTA2LDI0NiwxMjQsMTU1LDExMCwy MiwxMzksMjM4LDc2LDIzLDU4LDkxLDE3LDQ5LDEzMiw2MiwxOTQsMTI0LDYwLDc3LDIzNiwy NDgsMTA2LDM2LDEyNiw5OSwxMTYsNjAsMTQsNTAsMTUwLDI2LDExNSwzMiwxNzQsMTkwLDk2 LDMsMTUwLDE5Myw2LDg2LDEyMSwxMjgsMTc3LDcxLDE4MCwxMTgsMTcsMTUxLDU1LDY0LDE3 Nyw2NSwxODIsMTQ3LDEyNywyMDksMTU4LDI0Nyw4NiwxOTUsMTEwLDI3LDE3MSwxMSwyMDEs NjEsMjM2LDE4LDI0MCwyNSwyMTksOSwxNzgsMjA1LDE2OCw4MywxNjgsMTgxLDE2LDI0LDM0 LDEyLDUxLDQyLDE5NCwyNTIsNTQsMjAsMTExLDE5OSwyMDIsODYsODIsNzEsMjMwLDIyMiwx OTcsOTcsODYsMTcyLDcxLDIwOSwyMDksMTM0LDIyMSwyNDksMTAsMjE4LDE3MiwxNjgsMjM4 LDEzOSwyMjAsMTg3LDE5NywxNjQsMTcsMjE4LDI0MCwzMSwyNTQsMTUwLDYzLDEwOSwxMSwy NTUsMTEsMjM1LDIzNCwyNDksMiwxNjMsMjUsMjQ5LDYsOSw5NCwyNDEsODAsNjEsODAsMTA5 LDY3LDE2OCw3NSwxNjUsMTEzLDYwLDEzNywxMDgsMjEyLDMwLDgyLDIzOSw2LDYzLDIzNCw2 MCwxNDYsMzAsMTA3LDUsMTc1LDI0OSwyMDIsMTUsMjQzLDE0OCwxOTMsNjcsNjgsMTYyLDQ1 LDExMywxNjIsMzMsNzMsMTM1LDE5Myw4LDI1NSwxNzYsOCwyNTMsMTYyLDExNiwxMjYsMTU2 LDIzOSwxMDMsMTQsMjQ5LDExOSwxNjAsMjMwLDE3Myw2MCwyMjQsMjI3LDIzNiwzNSw1LDUs MTk0LDEyMSwxOTAsMTU3LDIzLDE5NywyMzksMjAsNiwxNzksNTYsMjE5LDEwMiwxNTIsMTE2 LDE2OSwxMjAsNTQsMTk5LDYsMjA4LDE4MCwyNTIsMTcxLDQ3LDIyMSwyNTIsMjQyLDQsMjQ4 LDEzLDE4OCwyNDgsMjQ1LDgyLDEzNywyNDUsNzcsMTY0LDE5NywyMTEsMTc0LDgwLDE1Niwx NTAsMiwxNzIsMTEsMTc2LDEyMiwxODAsMjEsMTE5LDgzLDEwLDg3LDE5OSwxMDcsMjUxLDE1 MCwyMTksMTQ3LDE5NSwyNiwxNDksMTcwLDI3LDIxMiwxNzAsODcsMjI3LDE1Niw2Niw5Nywx NzIsMjA5LDg3LDE2MCwxMjcsMzUsMjUyLDEzMSwzMCwxMjcsMTAwLDE3OCwyMzcsMTcsMjEx LDE2LDE1NiwzOSwyNTIsMTU2LDE2MCwxNTYsMTkzLDE3NSw4LDY0LDE3NCwxNDksMTA2LDk1 LDE5LDUsMjUsNzksNjIsMTE2LDIxNSwyMDYsMjAwLDE2MiwxNzcsMTQzLDc0LDIyMywxMDks MjM4LDExNywyMzgsMjI2LDY0LDU4LDIxLDE3OCwyNDUsNiw5NSwxMzcsMjEwLDIxNyw0Miw5 NywyMTQsMjQ2LDgsMjUxLDExNCwxNzcsMTM5LDIxMSwxMjEsMTk5LDE5Myw3MiwxOCwyOCwx NDYsMTQwLDIxLDI4LDE5OCwxNTgsNDksMTM2LDExNSwxOTAsMTM2LDk1LDE2NCwyMiwxNjAs MjA3LDEyLDIyMyw3LDE5NywxNzgsMTg2LDE0Nyw1MSw3MSwzMiwxNjIsNzIsMTQsMjAwLDE0 Myw5LDIyOCwxODAsMjE0LDM0LDE0NCwyNDksMjMyLDIzNCwxMDAsMTg4LDM3LDE3NCwyNDks MTM2LDQ0LDIsMjIyLDMzLDk2LDg0LDE3OCwxNSwxNDMsMzEsMTc4LDEzMCw4LDE1NSwyNywy MTMsMjQ3LDEzNiwxMzEsMTgwLDI1LDEzOSwxMTIsNTQsMjMzLDEzNSwxNDUsMTk1LDY3LDIy NywxMjAsNjYsMjMsMTUwLDc0LDIxNSwxNzYsOSw2MywyMDcsMjQ4LDE3LDQ0LDIyNCw0Mywy NDksMjQ1LDEwNSwxMTksMTU5LDU3LDE4NywxMTcsOTIsOCwyNSwyMzksMTcyLDE2MiwyMDQs MTk5LDIwMCwyMDAsNjcsMjMsMjIyLDEzMywyMDIsODAsMTI3LDI0OCw0NCw0MiwxMjMsNjAs MjUyLDI0OSwyLDI0MSwxNzcsNDksMTcyLDE4LDE4MSwyMzgsMTg0LDI0OSwxOCwyMDYsNDEs OTMsMyw5Nyw1NiwxMDIsMjAsMTQ4LDI1MSwxMSw4MCwyMjYsMTksMTE3LDYzLDI1NSw2Niw2 Niw2LDE3Miw3NCwyNiwyMzMsMjM3LDUzLDI0MywxODksMTk2LDEwLDUzLDEzOCwyMSwxMTQs NTcsMjAwLDEyOCwxODksMjExLDY3LDEzMCwyMTcsMTA0LDI1MSwxMTYsMTkzLDI0Myw2MCw0 Nyw0LDIwNywxMzMsMTQwLDYwLDE4NSwxOTcsMTAyLDMxLDM3LDExNiw2NCwxMiw2NiwyOCwy MzMsNTAsMjAwLDIwMSwxMSwyNiwxMSwxODEsMTA0LDIyOCwxMTUsMTQzLDkzLDE5OCwxOCwy NDYsMTQ2LDU1LDU2LDE0OCwxNzcsMjUsMTc4LDEsMTg1LDE5MiwxMTAsODEsMTE2LDIzMSwz NywzOSw3LDcsMjUwLDE4NiwxNiwyNTAsMTQ2LDE0NywyOCwyMjgsMjQyLDE0NiwzNiwzLDIz MiwxOCwyMzIsMTQ3LDEwMywxMzUsMjI4LDE4NCwxOTgsMTEsMjMwLDgxLDI1MCwyMDEsMTY3 LDU3LDIwMSwyMCw3LDk4LDI1MCwyMyw5MywyMzIsODksNDcsMjI4LDIwMCwyMyw1LDIzMiwz LDEwLDE1Miw2Myw1NCwxMjYsMTkwLDYyLDg1LDIwMSwyMDcsMjA2LDE1NSwxNjcsMTg4LDI3 LDQ3LDE1NCwyMSw1NiwzMSw3NCwyLDE1NCw0OSwxMDcsMTI5LDI0LDEzNSw0OCw3NiwxOTMs MTQwLDI1MSwyNDYsMTksMjgsMjcsMTAsMTUyLDgzLDIzMiwxMzUsMjIwLDE3LDUzLDkxLDEz NCwxMjQsMzksNywxMDMsMjM0LDE1NCwxNjksODYsMTY4LDY1LDEzLDQxLDIwMiwxMzQsMTc2 LDIzOCwxNjQsOTUsMTIxLDE1LDQ2LDIyOCwxNTcsMjM1LDQ3LDMxLDE1LDE4MSw0OSw4OSwx OTcsMTEzLDYxLDIxNiwxNjksMzAsMTE1LDE3NywxMjIsMiw5MywyMzcsMTg2LDE5MCwxNTYs MjMyLDI0NywxMiwxOTYsMjMzLDE5OCwyMjksMTg2LDE0NCw3NCw2LDEzMywxNDgsMTI5LDI1 MSwyNDgsMTg5LDE4NSwyOCwxOTEsMjUxLDc3LDIzMSw3MywyMDQsMjE0LDExNywyNCwxNjQs MTY5LDIyMiwyMzQsMTksOTUsMTU3LDMwLDU5LDE1MCwxMSwyMzQsMjEwLDMsMjM0LDE3Miwz MSwyNTAsNzUsMTc2LDEsMjM3LDE5Miw0MywxMTUsMjI0LDE3LDI1MywxNzEsMTEzLDIyMSw4 MiwyNDAsMTUxLDk4LDE2MywyNDIsMTYzLDExNSwyMjcsMTYyLDE5NiwxNzAsMzcsNDEsMTc3 LDY2LDU2LDU0LDExNSwyNDksMjI4LDE3MSwxNTIsMjE1LDQyLDkwLDI0MCwyMzgsMTE3LDE4 NSwyNTQsMTMzLDIwLDkwLDcwLDAsMTksMTQxLDEwNyw2OSw1OSwyMjMsMjM3LDE4NSwyMywy MzgsNDEsODksMTUxLDc0LDg4LDYxLDI1NSwxOTksNSwwLDksMTgsMTEwLDExOSwxNDQsMTg3 LDY1LDI0MCw0LDY5LDE5MSwxMyw2OSwxNzAsMTA5LDEwOSwxODYsODUsMTM1LDYsODEsMzIs OCwyMjIsMjAsMTYwLDIxMCwxNiw2MywxMzcsMTgwLDI1MywxMjcsNjMsMyw2MCw2NywxOCw1 NSwxNTcsMTc3LDI1NCwyNDEsNTEsMTQyLDE1NSw1LDIwMywxMTcsMTUwLDEwMSwyMTcsMTE4 LDIzNiwxMzksMjU0LDUsMiwyNDYsMTQsMjQyLDE5NCwxMiwyMzAsMjM4LDEzMiwxNzEsMTgs MTk5LDM1LDQ2LDE0OCwxOSw3OCw2OCwyMTcsMjAxLDIzLDE5MSwxNTUsMTM3LDEyNyw1NCwx Miw4NCwyNTIsNiwxNDMsMjQ5LDE4MSwxMzMsMTcsMjU1LDIxNSwyNDAsNzgsMjQsMjM0LDkx LDIzOSw3LDEwNywyNDcsNywxNjksMjQ4LDI3LDEwOCwxNywyNDEsNjcsMjA4LDIwLDI0MSwy NDUsMTE3LDExNiw0Myw0NCwxMzksMTU0LDE0MCwyNTUsMTkwLDE1MCwyMzYsMTc1LDEwMSwz OCwyMDQsMTY0LDIyMywyNDAsMTM2LDI0MCwyMzIsMjQ3LDUzLDI3LDE4MSwyNywyNTQsMjIz LDE2LDI1NSwyMzAsMTE0LDE3LDE3NSwxMzQsODksMjI1LDI2LDg2LDE2Miw5NSwxODcsMTc1 LDIyNiw3NCw4LDE2MCwxNjgsMTI4LDExOSwxODUsMTAyLDEyOCwxMzMsMjE0LDEzMywxOTEs ODAsMTU2LDIzMiw2Nyw0Miw2LDI0LDU2LDEyMSwxOTMsMywxNDIsMTcyLDEyMyw2LDIyMCw5 Myw4OSwxODYsMTQxLDM1LDI0NCwxNDQsMjQ5LDEyMSw1LDE0MywyMywyOSwxMTgsMjQ1LDQ5 LDEwLDI1MSwyNTUsMjM3LDE5MSwxNTMsMTEzLDM2LDE4MCwxODAsNzUsMjUxLDcsMTkzLDc3 LDEzNiwyMDYsODYsMTk4LDIwMiwxMzYsMjU0LDE5OCwxOTUsMTQwLDIyMiwxOTgsMTg3LDcs MTExLDIyMCwxMDQsMTkwLDE2MCwxNDAsMjMwLDE5OCwxNTUsMTI4LDE0NywxOTgsMjEyLDEx MSwxOTgsMTY1LDE0MiwxODIsMTEyLDExLDI0OCwyNDYsMTk4LDIxNSwxNDIsMjQyLDI0Miwy NDEsMjQwLDc2LDI1Myw1Niw2NywxOTIsODAsMjUyLDE4NSwxMTIsNTAsMTcsNjEsMTc5LDEz NSwxNywyMDAsMTc0LDEyNSw3Nyw2LDc2LDc1LDEzNywyMDEsNCwxNzIsNDMsMjA1LDI0MCwy NTIsNzQsNTAsNzMsMjI2LDcwLDI0MSw2NiwxMjYsMjA5LDE5MSwyNDIsOTEsMTM0LDI0Myww LDYxLDQ4LDE3MiwxNjAsOTYsMjQyLDkxLDM2LDU2LDI0Miw5MCwyMTIsODcsMjQ1LDE3Niwy NTUsMjI3LDIwMSwxNTQsMTYyLDExNSw5LDQ0LDE0MSw4MSwyNTUsNDgsMTksMzQsMjQyLDQs NzUsMjUwLDk3LDEyOCwyMjUsNjUsMTksMTUyLDExNSwyMjAsMjUyLDI1MiwxMTgsMjQ4LDIx NCwxMCwyLDE2OSwyLDI0NSwxMjEsODksMjMxLDMwLDEyMywxMzUsMTQsMjM0LDIyMSw1MSw0 NCw2OCwyOSw2NSwyNDQsOTQsMTIzLDQ3LDQ5LDExMywxMiwyMjIsNiw2LDIwMCwxODYsMTQz LDEzMiwxNjMsNTQsNCwyMjYsNjMsMTIwLDU2LDU1LDI0NSwyMzQsMTczLDUwLDIwOSw0OSwx MjMsMywyMjUsMTg5LDI0MCwzMSw3OSwxNjQsMTIxLDMsMjU1LDE0MCwxNjMsOSw5LDExOSw3 MSwxMTAsMTk1LDIyMiwxOTQsMTA5LDk4LDg2LDIzNiwyNTMsODAsNTYsNTMsNDUsMjQsOCwx LDE3MywyNDgsMzgsMjIyLDI0MSw0MCwxNDIsMTk1LDE2OCwyNywzOCwyMTksOTAsMjQ3LDE5 NywxNDUsOTMsMTYwLDE3NCw1MCwyMjAsMTgsMjQzLDE3Nyw0MywxMjUsMTMwLDYwLDE3Mywx NjgsMTA1LDgsMjE3LDM0LDE0NCwyNTEsMTMxLDUzLDY1LDI0MCwyNiw1LDE3NSwyMzQsMTY0 LDE5LDE3NCwyMSw1MiwxNjcsNzQsODgsMTUyLDY4LDI1MSwyMDEsMTQ1LDE0NywxMzUsMjQs MjQ2LDE2MCwyMjAsMjQ3LDEsMTIxLDc4LDIwMCwxODQsNTgsMjQ2LDIxNCwyMzQsMzMsMzAs MjA3LDE3NCwyNDcsMjMyLDk2LDk0LDU4LDI0OSwyMjAsMTUwLDEyMywyNTIsMTE4LDIxLDg2 LDEzMCw0Nyw1NSwxMzgsMTU1LDEzLDYwLDE1MCwzLDE0NiwxMTQsMjMzLDYsMTM5LDc0LDEx MCw0NCwxOTksMTcwLDExMCwxOSw5MiwyNTUsMTQzLDEwLDYwLDE5MiwxNzMsNjksMTk4LDE5 OCwxNzAsMTI5LDIsMTcsMTczLDg5LDI0NCw4MywyNTMsNiwxMzIsNTYsMTUyLDEsMjEzLDEy NywzNyw1OSwxMjksOTgsMTcsMTYzLDIyLDE0Myw1OSwyMjUsMTE3LDIyMyw1MSwxNDQsMTgs MTgsMTUsMjQwLDg4LDE3MCwxNTMsMTcxLDIwNCwxMjgsMTA0LDE5MSwyMTYsMTA4LDE5LDEz LDI0MSwyMzQsMTIyLDE5NCwxNjEsNzksMjE1LDIyMSwyMzksMTI4LDI1MSw5NCwxNywxMCw1 MiwyMTgsMTIsMjQwLDM0LDIzMiwxNTEsMjI4LDkwLDE0OSwxNzQsMTIwLDE3MywxNDYsMTgs NywyMjMsMjM2LDE5LDYyLDExNCwxODIsMzcsNjksNTEsOTcsMTY2LDIxNyw1MiwyMDgsNCwy MzIsOTYsMjI1LDY0LDI0Niw3MSwyNTEsNzcsMjE2LDk5LDE4NywxMTMsMjQxLDI1MCwxODEs NDIsMzUsMjMyLDI0NiwxODQsMTc2LDUsMTgzLDQ1LDIzNiwyMDMsNjksMjQ3LDQ1LDM2LDEy MywxMjksMjAwLDExMSwxNjgsMjQ2LDIzMSwyNDcsMTc3LDE2MiwxOTAsMTg2LDIwMiwyMTcs MTc1LDk3LDI0LDE3Niw3NCwxNDksNjQsNDcsMTY1LDE0NCw4LDE5OSwyMjYsNTAsMiwxOTYs MjUxLDE2LDU1LDI0MSwxNjYsMjM2LDIsMjI0LDE5MCw0MSwxNjgsOTEsOTEsMjE1LDk3LDU2 LDIwMCw2LDk2LDIzNiwyMDksMTUwLDIsMjQ1LDIwMiwyNDEsMTM5LDEyMCwyMzMsNDksMTAw LDE5NywyNiw2MCwyNTQsMjUzLDI0MSwxODEsMTUxLDEwLDE4OCwxMTksMTY4LDIxNCwxNTYs MTE0LDgxLDE0NywxNTYsMTIzLDUsMjEsMTI3LDIzMCwxODcsNiwxNTIsMTY4LDQ0LDksMjcs MjMyLDEzLDI0OCwyMDQsOCwyMiwyMDAsMTYsMjIwLDE2NiwxMDMsMTcxLDExLDIzOCwzOSwy NDksMjQ2LDE4NiwxNDYsNjIsOTgsNjAsMTM2LDI0NiwyMTUsOCwxNzQsMjcsMjM2LDIwOSwx MTAsNzAsNTQsMTYyLDMwLDc0LDIwNCwyNTIsOTgsMTk2LDYwLDU4LDE5MSwxODIsNSwyMCwx MjgsMjE5LDEzOCw3MSwxNjUsMTU5LDE1Myw0MCwxMTUsMTU5LDE2MCwxMzEsMjEsMTAwLDI0 MCwxMjQsMTI3LDE0NCwyNSwxNSwyMCwxMTcsNzksMjMwLDEyMCwzMiw0LDcsMTY1LDE5Niwx MjYsMTQzLDE0NiwxNzgsMTM1LDIzNSw1MywyNDAsMTk4LDEwNCw1MSwxMzgsMzUsMTg1LDE2 MywyNDEsMjIxLDU0LDEyOSwyNDAsMTY0LDEzMSw0MSwyOCw3MiwyNDAsMTgyLDE2MCw5Nywx MzUsMjA4LDE3Miw1NCwxMTEsNTcsMjE5LDE0MiwyMjAsMTcsMTQsMTgsMTc1LDE1LDE1Nywx MjIsMTk2LDIyMiwyMzAsMjM1LDEyOCwyMjAsNiwxMzksMjA3LDEzLDEyNCwyNTIsMTAsMjIy LDIwMCwxMDksMTEwLDExMyw3MCw1LDI0Miw5Miw5OCwxODgsMTcsMzcsMjA5LDUxLDE3MCwy NDksODIsMTY1LDE2NCw1LDIyMiw1LDEzMywxNzcsMjM0LDI0MiwxMyw0MiwyNDQsMjQwLDMw LDI3LDAsMjE1LDIyMiwyNDQsMjAyLDE4LDEwMywxOSwxMCwyNDMsMTgsMzAsMjQzLDIzLDIx LDIzMCwxNDQsMjAzLDE5MCwyMzksNzYsMzUsNiwyNDIsMjUxLDk0LDI5LDE0NCwxMiwxMjQs MjQwLDE5Myw4NiwxNzAsNTksMjU1LDEyOSwzMSwyNywxMTMsMTEsMTMsMzQsOTksNjcsMTk4 LDE5OSwzLDEyNyw0MCwxMzUsMjQ4LDEzLDQzLDI2LDE1OCwyMTksMzIsMTY4LDY1LDI1Miwx MDAsMjcsMTE3LDI0MCwyMzQsMjksMTgyLDEwOSwyNTIsMTIyLDEzNSwyNywyMDIsMjM5LDYw LDE3LDIwOSw3NCwxOTMsMjIwLDEzMCwyMjIsMTI5LDI1MCw3NCwxMjAsMTcxLDgyLDUxLDEx MywyNDksMTQyLDUzLDExNSwyMzMsMTAsNzAsNTEsMTg3LDc0LDIwMCw1LDE1NCw1NiwyMzMs MzcsMTg5LDgyLDI0MCwyMDUsMTA0LDc0LDE2OCwxOTUsMTA2LDY2LDI0MCwzOCwxNjEsNTYs MjUwLDI1NCw5MiwxMTIsNDgsMjI2LDIzNSwxMDAsMjE4LDE4LDEzLDI0MywxMjIsMjE0LDE5 Miw2NSwxMyw4OSwyMiwyMzAsMTExLDE0MCwyLDIyOSwyNDgsNTEsMjMyLDIzMiw1MywxOTgs MTksMjI0LDE2Myw2NSw0MSwxNzIsMTQsNzcsMjksMTYyLDEzMyw5MCwyMDYsMSw1MCwxNDEs MTIwLDI0MSw4MSwyMDUsMzEsMzYsMjgsMjQwLDc4LDE2OCwxLDE3NCwxMTYsMjIyLDEyMiw0 OSwxNzcsMTYxLDI0OCwyMTcsMTMsMjI2LDE3LDMxLDE4LDE0NiwyMTcsODgsMTg2LDIzMSw1 MiwxOTEsMTg3LDEwMSw5MCw5OCwxNjcsNTcsMTQ2LDIwNiwxNSwyMjEsODgsMTE0LDU3LDIx MCwyMzYsMTQyLDQsOTUsMzEsMjUsOTQsMTMwLDM3LDk0LDYwLDIyMSwxNDUsMTY3LDE2MSwx NDYsNDEsOTAsNjMsODcsMTYyLDE4NSwyMDcsMjQ3LDE0MCwxNzMsMTk0LDMxLDE3OCwxOCw5 Nyw1LDE1OCwyMzEsMjQ5LDc0LDE0LDQsNzUsNzAsNjEsNDAsNTYsMTk4LDk5LDI0MCwzMCwx MzQsMTQ2LDIxOCwxODAsNTMsMTY1LDI0MiwxMjksMjMxLDEyMywxODksMTUzLDcwLDEzLDE3 MSwxMCwxMjYsODksMTE5LDk5LDY0LDg1LDM1LDEzLDY2LDU0LDg2LDc2LDE5NCwxNDEsMTk1 LDI0OCwyMTEsMTgsMTQzLDUsMjQwLDE3MCw2Miw1MywyNDIsMTYyLDE4NSwxNjcsMTgyLDQy LDQ2LDkzLDgyLDE1OSwxNDAsNTEsMTMxLDUzLDE3OSwxMCwxMDIsMjM5LDEyLDExNywzOSwx NzgsNTEsNiwxMTEsMjU1LDgxLDE4MSwyNDYsMTE5LDIxNywyMTYsMTc5LDExNSwyOSwyNTMs NzgsMTQ2LDEwNyw0OCwxMzQsODIsODgsMjE1LDUwLDEzOCwxMTUsMywxNjksMTU0LDEzNCwz MiwxOTYsMTIyLDc2LDI1Myw0LDExNCwxMDQsMTI3LDEwNywxNjIsOTIsODQsMjMsMjQyLDQs MjE4LDE0MiwyNDksMTg5LDE3LDksOCwxODcsMTY3LDIzNywxMTIsMjI5LDYwLDM0LDE2OCw5 MCwyMTksNzIsMTE0LDIyOSwxMzQsODAsMTI5LDEwMywyMDgsMjQzLDE1MCwxNywyMDEsMTk1 LDQsMTIyLDEyOSwxNjEsMjUzLDMsMTc3LDE5OSw5NiwxMzUsNTgsMjgsMTQ2LDI0NSwyNDUs MTcyLDE5LDE0MCwxMjIsNDksMjYsMTQwLDE2Nyw1NywxMDUsMTEsMjA2LDIyMCwxNSwyNCwx ODksMTIyLDI1MCwyMTAsODgsMTQ4LDEyMywxMDMsMTI4LDExMSwzNSwxMjcsMTg2LDIzNSwx ODYsMTA3LDEyMSwxNzAsMjQ1LDc2LDU4LDczLDIxLDE2MCwxMTQsMjQ4LDI0MSwxNjMsMTMs MTM5LDExMywxOTUsMTkzLDI0NSwyNDIsMzIsMzAsNzcsMTQwLDE0MCwyMDUsMTg3LDE4Niwy MTAsNzUsMTQ4LDIzOSwxMTksNzEsOTksMTM1LDI0NiwyMDUsMjQ1LDI0OCwyNDAsMTc1LDIz NSwxMTAsMTEwLDQsMjAyLDEzNiwxOTUsMTQxLDI1NSwyMTAsMTcsMjIwLDMwLDM4LDEzMSw5 NCwyMiwxODQsMTAxLDEwOSwxMDIsMTk4LDUsMjA0LDI1MSwxNCwyMDUsMTY3LDI1NCw5OSwy NTIsMTg2LDE4MiwxMDAsMTE4LDI2LDI0MSwxNTcsMTQ1LDEsMTMyLDE5OCw2OCwxMzksMjUx LDEzMiw0OCwyNDUsNiwxMjksMjAsMjAyLDE4LDQ1LDUxLDQzLDE2NSw3MSwxMDAsMjI4LDIx OCwxNjgsNjcsOTAsNjcsMTg2LDM1LDc1LDE3NywxNTIsMTc2LDYwLDEzLDIzOCwxNDQsMTAz LDEwMCwxNDQsMTYxLDE4MCwyMTIsMjQwLDExLDU0LDIzNSwyMzAsMTk3LDUsNzksMTc4LDIz MSw0OCwyMjUsMTgyLDEyMiwxNSwyMzksNzksMTUxLDU2LDc5LDEzMywxMjYsNiwyMTYsMjI4 LDIyNSwxOTUsMzgsMTgsMTI2LDI1Miw5MiwyLDU3LDIwNiwyMTAsMjA0LDQ4LDIsOTUsNjAs MTQ4LDc1LDIyOCwxMDgsODYsMjA3LDQyLDE2NSwyNTIsMTUzLDU2LDE3NywxMSwyMTYsMjEx LDMzLDE0NiwxNDksMjAsMjE1LDI5LDE3LDE4NiwzNSwxMjAsMjIsMjgsMTEzLDIzOSwzNSwx MjEsNTYsMjUyLDE3MiwxOTMsMTcsNTIsODQsMTY5LDEwOCwxNjgsMTg2LDEwOCw4OCwyMyw0 OSwxLDE3LDIyOCwyMSwxODIsMjE3LDEzMCwxNTUsNDEsMTY5LDE0LDE5MCw5MywzNiwxNDQs MTQ2LDEsMjQ5LDEwOSwxNDYsMTMyLDk2LDU0LDI1NSwxMzIsMTE4LDU0LDI0LDgyLDQzLDEz MCw5MSwxMTAsMTYzLDE0NSwxMywyNyw3OSw3LDEwOCw1NywyMDEsMTk1LDk0LDMyLDIzNSwy MzQsMTAxLDEzNywyNTUsMjE2LDIsNTksMjM2LDIxMCwyNDksMjU1LDIzNSwxOSwxNzgsMTc5 LDE1Myw0NSw2OSwxNTgsNSwxNTQsMjQsOTgsMTQ0LDI1MywxOTcsMjA0LDE0NiwxNTAsOTAs MTksMTUyLDE2MSwxMjYsMjA5LDE1NCwxMiwyMDcsMTM4LDk5LDYsNjAsNDcsNTcsNDQsMTQw LDg2LDI4LDI1NCwyMzAsNzAsMTM0LDE0NiwxMzEsNDAsMjU0LDE2NiwxNjIsMTUzLDIyOCw5 Nyw3Myw4MSwxODksOTAsMTEwLDIyLDY2LDYsMjUsMjQ2LDEyMiwzMCwyMzYsMjA0LDgwLDIw NywxOTAsNjMsMzgsNDEsNjQsMTAsOTYsMTU4LDE0NSwxMDMsMTg2LDg1LDE5OCw5NCwyMjks NzAsMTUzLDkwLDkzLDIyLDIwMywzOCw5Miw0OCwyMDIsMTI1LDgxLDI0MCwyNDksMjIsMjA3 LDY1LDE4OCw1LDI1LDE5LDM2LDg3LDkzLDE4NiwxMTcsMzIsMjIwLDE0NCwxNTcsNzksMTMy LDIyMiwyMDcsMTAxLDIzMCwxMjMsOTAsNywxMDAsMzUsMjQ4LDEwNywxMSw1OSwyMDAsMzMs MTEwLDEyOCwyNTQsOTgsMTg3LDc1LDEwMywxNzMsODEsMiw5OSwzNCwyMzYsMTQ2LDkxLDEz NywxNDYsMjMzLDI0OSw1OCwxODIsMTEyLDQsMjM3LDYyLDU0LDM0LDE0LDY3LDE2MywxMjQs MTU4LDIzMSwyNDQsNzksMTM0LDUsNTcsMTQzLDExNCwxNDUsMTY1LDkyLDE1LDg3LDE0Miwx MDcsMjcsMjE3LDk0LDQzLDI2LDE2LDIyLDkxLDIyMiw4LDE1MCwxNDUsMTAxLDEwMCw5NSwy MjUsODMsMjMyLDg3LDE3MSwxOTYsODksNzAsMjQzLDc1LDM3LDI0LDIyNiw4Miw1NiwxNjgs NTcsNDYsMTUyLDk4LDU2LDI0MCwxMjYsMTA5LDI0NiwxMzEsMTIsNzMsNTgsMTgsMjIzLDg1 LDE1Miw2OCwxODAsODMsMTI3LDE4LDEyLDIzOCwxLDE5MCwyMTQsMTUwLDI3LDU5LDE2MCwx MCwyMTAsMTMsMTA3LDExMiwxMDIsMTIzLDgyLDI0MywxNCw4LDIwMywyMzksMTA4LDE5Miwy NDksMTEsMTMzLDE4NSwxNCwxMTksMTM1LDE4LDY3LDI0Miw2MiwyOCwxMjgsMTc5LDc2LDMw LDE1OCwzMSwyNiwxNzAsMTIzLDE0NCwxMjMsMTMwLDIzNCwyMzQsODMsMTgsMTc1LDE0NSwx MzksMTc3LDIyMiwxMzYsMTU5LDEzOCwxNzQsMTU4LDEwNiwxMzgsNzYsMTksODUsMTUyLDQz LDEzNCw4MSwyOSwyNDUsMjQ5LDQsMzMsMjEwLDM2LDIxMCwxMzYsNTQsMTEyLDQ1LDI0Nywx NjMsMjUxLDgxLDIxOCw3OSwxNjEsMTQsMzUsMTc2LDIxNywxMDksMjI3LDExLDQsMTY5LDMy LDI0MiwzOSwxNzMsMjU1LDIyNCwyMTcsMTkzLDIyLDEyMyw0NSwyMDUsMTM4LDU0LDI1LDE1 OSwyMzcsMTUwLDE2NSwyMDgsMTEyLDAsMCwxMywxMCwxLDczLDExMCwzMiwxMjcsMTc2LDI1 NSwyNTUsOTcsMzIsMTAwLDEwNSwxMDIsMTAyLDEwNSw5OSwxMTcsMTA4LDExNiwzMiwxMTks MTExLDExNCwxMDgsMTAwLDIxLDExMCw5NywxMDksMTAxLDEwOCwxMDEsMTkxLDIyMSw5Miwy NTEsMTE1LDExNSwzMiwxMTYsMTA1LDgsMTksMjgsOTcsMTEwLDMzLDExNiwxMTEsMzIsMTE1 LDExNywyNTQsMTExLDEyNywyNDcsMTE0LDExOCwxMDUsMTE4LDE4LDgzLDExMSw0NCwzMiwx MjEsMTExLDExNywyNCwxMDUsMTA4LDEwOCwzMiw5OCwxMDEsMzIsMTA5LDEwNSwxMTAsMTgz LDI0NiwyMTksMjM5LDIxLDQ1LDQ1LDMyLDY2LDk3LDEwMyw1NywzMiw2NSwxMTcsMTE2LDEw NCw3OSwzNCw1MCw1Nyw5NywxODMsMTExLDIzOCw0Niw0OCw1MiwyLDksNzEsMTAxLDExNCwx MDksNjgsMTIxLDQ2LDEyNSwxMTEsMjU1LDE4MywyMzksMTA2LDAsMSwyMzIsMTQyLDY0LDE0 NCwxNjMsMTA4LDE1Myw2NCwwLDEwNCwxNSw1Niw0LDI1NSw1Myw0LDIyMywyMzcsMjYsMjIz LDExMiw2NCwyMCwzMywxMzgsNSw1NCwxMDgsNCwyMiwxNzcsMTQ0LDEwNiwxMDAsMjE4LDI1 NCwyNTUsMTE5LDcsNjUsMTEwLDIzNSwyNDEsMjAxLDE5NSw4NSwxMzksMjM2LDg3LDI1NSwx MTcsOCw5NSwyMzUsOCw3MSwyNDYsOCwxMjgsMjM3LDExMCwyNTUsMTUxLDE3OSw1LDU5LDEy NSwxMiwxMTcsMjQzLDk1LDIwMSwxOTQsOCw2NiwxMDcsNzksNzEsMCwxNiwyNTEsMzIsMjIz LDE0Myw2NSw2NCw0MCwxMDQsMTQ3LDE2OCwxNCwxMTIsMTI5LDUsMTEzLDgwLDMwLDExMCwy MzcsMjU1LDEwMSwwLDAsMjMzLDE0OSwyNTQsMjM5LDI1NSwyMDQsMjU1LDM3LDIzNiw5Niwx NSw1LDQwLDk3LDI1LDI1LDI1LDEyMSwzNiwzMiwyOCwyNCwyNSwyNSwyNSwyNSwyMCwxNiwx Miw4LDI0MiwyOCwyNSwyNSw0LDAsMjUyLDk2LDI0OCw1MCw1MCw1MCw1MCwyNDQsMjQwLDIz MiwyMjgsNTAsNTAsNTAsNTAsMjI0LDE1Niw4NCw4OCw1MCw1MCw1MCw1MCw5Miw5NiwxMDAs MTA0LDUwLDUwLDUwLDUwLDEwOCwxMTIsMTE2LDEyMCw1Nyw1NCw1MCw1MCwxMjQsMTI4LDEz MiwxOTEsMTM2LDk2LDE1OCwyMDcsMjMxLDI0MywxNDAsOTYsMTQ0LDk2LDE0OCw5NiwxNTIs OTYsNDQsMjQ5LDEyNCw2Miw3MSwxNjAsOTYsMTY0LDk2LDE2OCw5NiwxNzIsOTYsMjAwLDIw MCwyMDAsMjQzLDE3Niw5NiwxODAsMTg0LDE4OCwyMDAsMjAwLDIwMCwyMDAsMTkyLDE5Niwy MDAsMjA0LDIwMSwyMDAsMjAwLDIwMCwyMDgsMjEyLDIxNiwyMjAsMTI0LDYyLDE1OSwyMjMs OTcsMTM3LDExMiw5NywxMDgsOTcsMTA0LDk3LDEwMCw5NywyMDAsMjE2LDIyOCwyNDksMTY4 LDk3LDE2NCw1LDE1NiwyMDAsMjAwLDIwMCwyMDAsMTgwLDE0OCwxNDQsMTQwLDIwMCwyMDAs MjAwLDIwMCwxNTIsMTc2LDE4NCwxNzIsMjAwLDIwMCwyMDAsMjAwLDE4OCw1Niw1Miw2NCwy MjUsMjAwLDIwMCwyMDAsNjgsODAsNzIsNzYsOTcsMjE3LDEwMCwxMDAsMTAwLDIyOCwxMjAs MTMyLDEyNCwxMjgsNTAsNTAsNTAsMTk0LDE1MSwyMCwxNiw4LDIyOCw1OSw5Nyw1MCwxMiwy MTcsOTYsNSwzMiwxMDAsMTAwLDEwMCwxMDAsMzYsNDAsNDQsNDgsMTAwLDEwMCwxMDAsMTAw LDUyLDU2LDYwLDY0LDk3LDEwMiwxMDAsMTAwLDY4LDcyLDc2LDAsMiwzNiw4NCw2NSwzNCwx NTQsMTY5LDE2MiwyNTAsMjksMTk1LDI1NCwyNDYsMjIzLDYyLDE2LDQsMTQwLDc5LDIwMywx OTUsMjA3LDIxMiwxLDIwMywyMDcsMjA0LDIxMiwyMDAsMjUwLDAsMTA5LDI1NSwyNTUsMjU1 LDE2OSwxODEsMTg4LDE3NCwxNzMsMTg3LDE2OCwxOTEsMTY2LDE3NCwxNDcsMTUxLDE1OSwy NTAsMTU4LDEzNiwxNDAsMTU4LDE1OCwxNTAsMTUwLDIxMiwxNTksMTMwLDExLDE2NiwyMTcs MjU1LDI1NSwxMjksMTIsMTgxLDE3NSwxNzQsMTcwLDE4MSwxNjksMTc0LDIxMiwxOTEsMTYy LDE5MSwyNTAsMTgwLDE4MywxODcsMTc5LDE4MCw5LDI1NCwyNTUsMjIzLDI1NCwxODEsMTY4 LDE3NCwxODEsMTgwLDE2NSwxMywxNzQsMTkxLDE2OCwxODAsMTkxLDE3NCwxNjUsMTY5LDE5 MSwxODUsMTc1LDE2NSwyMDEsMjEyLDIwMiwxNjUsMjA2LDIwMiwyMDUsMjIzLDE5MCwxMDks MjA3LDMyLDE3MCwxODgsMTAsMTY1LDk2LDE2NSwxOTUsMTk0LDE2NSwzNiwxNjUsMTgzLDE5 MSwxNjUsMTA3LDE4MywxMDksMjE2LDIwMCwxNzcsMjQsMTIsMTY5LDQ3LDE4MCwxODksNTcs MTYsMjQ5LDIwNywxMTAsNywxNjgsMTgxLDY5LDE4NSwxNzQsMTIsMTY5LDE4NSwxNzgsMTkx LDE5MCwyMDEsMjAwLDExOCwxMDcsMTAzLDYzLDE3NCwxNzIsMTkwLDE4Myw5LDE3MiwxNjgs MjQsMjAzLDIwNCwxMiwxODEsMjQ2LDI1NSw1NCwxNzcsNTYsMTc5LDE4MSwyMTUsMTczLDE2 OCwxNzAsMjE1LDIwNiwyMDAsMjAzLDIxNSw3MiwxMCwxODksMTg1LDIzOCwxMzEsMTQ4LDE3 NywxNzksMTgyLDE4Miw3NiwxODUsOTQsOTUsMTc0LDE3NSwxNzAsMTgzLDE1Myw1OSwxODIs NDcsMjAzLDIzLDE4MiwxOTAsMjEsOSwyOCwxODcsMTgyLDM5LDIyOCwxNSwxMTUsMTc1LDEy LDE3NywxOTAsMTgxLDE3MywxODAsMjAwLDIwMiwxMjUsNDQsNTQsMTA3LDAsMTYsNjYsMTAs MTg1LDE4MiwxOTEsMTg3LDM1LDI1Miw2MywxODIsMTY1LDE4NSwxMSwxODcsMTcyLDEzOCwx MzYsMTQ5LDE0MiwxNTksMTUzLDE0MiwxOTUsMTMwLDMwLDE4NSwyMTYsMTk0LDg5LDI1MSwx ODMsMTg5LDE2OCwxOTAsMTc5LDMwLDQwLDE4MywxOSwyMDIsMTY1LDIyOCwxMDAsMjM3LDU0 LDE4NSwyMzEsMTk1LDE2Miw3NywxMiwxODAsMTc0LDE1LDI1MSw1NCwxNTUsMTcyLDYsMTA4 LDE4NCwyMDMsMTk0LDIwMywxMSwxNzQsMTkwLDIwNywxMTAsMjM3LDIxNywxNzMsMTgzLDE2 NCwxNzksMTg1LDE5MCwxMjEsMTcwLDE4MCwxNjUsMTkwLDE5MSwxMSwxMzEsMTgxLDEzMywx ODgsMTY1LDE3NCwyNTIsMTIsMTcwLDE0MiwxNjMsNDcsMjcsMjE0LDEwMiwxMCw4Miw3LDE2 OSwxOTAsMTY4LDY2LDk3LDg2LDExMiw0MywyMTYsMTQxLDI1LDgzLDE1OSw1NywxODIsMTE0 LDE5MSwxNTksMTc4LDEsMTkxLDE2MiwxNzEsMTc1LDI4LDg4LDE5MiwxMCw3NiwyNCwzNywx NzIsMTkxLDE1NywyMjEsMTQ2LDEwMywxNzAsMTkwLDIzLDE2MiwyMiwxNzQsMTc5LDE3Miwx NzksMTY4LDQ1LDIxNiwxMzUsMjQwLDE3NSwxNjksMjE1LDE4NSw1OCwxODgsMTg3LDE2OSw4 LDIzLDE3Niw0OCw0MywxODAsMTkxLDExNCwxMTgsMTIsNjgsMTczLDU2LDE1Niw1MywxMzAs MjA0LDMwLDE3LDE3MCwxNTYsODksMTEsMTgyLDIwOCw2LDE3NiwxODcsMzQsMTYwLDcsMTQ2 LDE3NiwyMDUsMjE4LDE2OSw5OCwxMDUsMjA3LDE4MSwxMzIsMjI4LDE5MiwyMjIsMjU0LDIx LDIwNywyMDEsMjAyLDkxLDE4NCwxNjMsMTg0LDE2LDE3Myw5NiwyMTksMTMxLDM3LDE2Mywx ODksMTg0LDE4MywyMjUsMTc1LDEwLDEwMSwyMjEsOTYsMTQxLDE2MiwxMzEsMTg5LDIyMCwx OTAsOSwyMTQsMjAyLDE3LDE4Miw5MCwxODksMjIyLDE3OCwxODcsMTMzLDQsMTM0LDEyNSw5 LDE0MSw1OCw0NCwxNzgsMTc0LDE4MiwyOSw0Myw1Miw3OCwyMTYsMTgyLDE5MSwxMjIsMTg3 LDIyNSwxMjEsMTAsMTE4LDEyMCw5MSwwLDUzLDE2OCwxNzUsMTU2LDUyLDE5NSwyMjgsMTAw LDIzOSwxODcsMTkwLDEzMCwxMiwxODAsMTc0LDI1Myw2NiwxNzgsNjcsMTc2LDksMTkxLDM1 LDIwNCwxMTgsNTAsMTAsMywxNzksMjAzLDk2LDE3OSwxNzAsMTU5LDE0MCw0NSw3NiwxODIs NDksMTY4LDMyLDE2OSwxMDYsMTc2LDUxLDIwLDEwMiwxNzMsMjEzLDE5LDIwMCwxMzAsNCw5 NywxOTgsMTA4LDg4LDEzLDEyLDIzMSwzLDE5NSw3NiwxNjUsMTE4LDE4MiwxNzksMTEsOTUs NjgsMTYsMjcsMTQ3LDE1MCwxODUsMTcwLDIxNywxNiwzNCwyNSwyMTUsNDYsMTA1LDczLDc1 LDMyLDIwMSwzMyw1OCwxODIsMjM3LDIxNywyMzcsNzIsMTg0LDEzNiwxODksMjAwLDksMTY5 LDIwMywxNjIsMjE5LDE0LDE5OCwyNSwxNDgsMTkwLDI1NCwxODgsMTg5LDM4LDE2MCwxMCwx MSw4Niw0Miw0LDExLDE0Niw1MSwxMiw5MSwxNTAsMTMyLDI0NiwxNzUsMTkwLDEzNiwxOTks MTYyLDI3LDEwNSwxNjEsMjksMTk4LDQzLDE4MCwxNTYsNzIsMTczLDIxMCwyMTksMTQsOTEs MTQsMTg3LDE2Miw5LDE2OSwyMjUsMTg0LDExLDQ1LDksMTQ3LDEzLDMyLDE4NSwzMiwxMCwx MzksMTQ0LDEwOCwxMDcsNjcsMzQsMjA2LDk0LDE5MSwyNSw3MCwxOTUsMjAxLDU4LDE5MCwz NCwxOTEsMTgxLDExNywxNzksMTExLDE1NSw5MSwxMzAsMjcsMTE1LDg0LDEyLDY0LDE4OCwz MCwxOTUsMjIwLDE3NiwxODEsMTEsMzksMTAsMjM0LDIzMywyMzUsMjIzLDE3NiwxOCwxNCwx NzAsMTYzLDE3OCwxNzUsMjAxLDIxNSwxNDEsNjYsMTc2LDE1MCwxMDgsMjAwLDIwLDczLDE5 MSwxNTQsMTc1LDEwOCwxNTEsMTMyLDI1MywxMSwxNzUsMTgzLDI1MiwxODIsMTc1LDE1NSwx NCwyMjUsMTgxLDE4NSwxMzQsMzYsMTcyLDE4OSwxMjMsMTY5LDE3MiwxNzIsMjIxLDE1OCwx MDIsMTIsNjIsMjE1LDE4NywxODEsMTc2LDgsMTUsMjE2LDE3Niw3Miw0MSw5NCwxMyw4LDkw LDIyNSw0NSw1OSwxNzAsMTc5LDIxNywxNCwyNDIsMTgxLDEzLDk3LDIwMSwyMDUsMjQ1LDEy LDE5NywxOTAsMTg2LDIzOCw1MCwxMzQsMTE3LDI4LDE4MSw5LDI1MywxODcsOTcsMjE3LDE0 Niw1MywyMzYsMjA3LDIwNywxOTEsMjQsNjYsNDYsMTcyLDIxNiw1NSwyMTYsMTUwLDM0LDE4 MiwxMiwxODksMTgyLDE5NSwxMiwzLDIwNywxMTIsNjEsMTY5LDE2MywxODAsMjA2LDYsMTkw LDE2NSw3NCwyMTUsNjUsMTA2LDc3LDE4OCwxNzksNDYsMTg4LDE4NCwxNzksMTQwLDE3Mywx MTAsMjE3LDQ4LDksMjM4LDEzLDE3MCwyMjQsNDUsMTI5LDE5NCwxMDEsOSwxOTEsMjM5LDYw LDE1MCw1MywxMywyMTQsMTgsMTY5LDgsMTgyLDEzMSwxOTAsMTAsMjI1LDEzMSwxOTMsMjE2 LDIwNiwxOTEsMTIyLDE4MSwxMzUsMTgwLDI0Myw2NCw0Myw0Nyw1NywxNzMsMTgwLDE3Mywx NjcsMTk1LDEwNCwxNCwxMzAsNzgsMTMwLDE0Miw4MiwxMDgsMjE0LDExLDYsMTQ3LDQyLDEy MywxOCwyMDMsNTYsNDgsMTUxLDE3OSwyMSwxNzAsMTczLDE5MiwxMTAsMTQ0LDExMSwxMCwx ODAsMTc5LDE2MiwxNzcsMTcyLDM5LDE2MiwxNjMsMjA5LDEwMiwxODEsMTM1LDUwLDE5MSwx ODQsMTcxLDE1MCwxODksMjUxLDE1OSwxNzIsMjUzLDEyNiwyMDAsMTY5LDE5NSwzLDE1LDE3 NywxNjUsMjA1LDIwNCwxNjUsMjAzLDIwNiwyMDEsMjA0LDE3LDEwMSwxMzEsNjEsMTQsMTc5 LDExNCwxMiwxOTAsMjMyLDk2LDEzNSw3LDE4MiwxMiwxODgsOSwxNzksMTQxLDE1LDIxNyw1 NSw4OCw4OCwyOCwyMDMsMjksMjAzLDIwNSwxNjUsMjAyLDE1LDE3MiwyMTQsNTIsMTc2LDU5 LDE1MSwxNjksNDAsMTMzLDE1NCwxMywyNDYsMjAsMjAzLDE4OCwxNDQsMTg4LDEzNiwxMDEs MTEwLDE0NiwxMDQsMjQxLDE3NCwxMjQsMTcwLDg4LDIxNSw5MSwxNTIsNjEsMTgyLDcsMTg5 LDIwNywxMiw4OCwxNzQsMjMsNDQsMTE1LDIwMywxNCwxODEsMjI3LDExLDM0LDUzLDE0LDIw LDc2LDE4NSwxOTgsMTYzLDExNyw0OSwxOTMsMjI4LDEzMCwxMTAsNjYsMTg2LDkwLDExLDE4 NCw3LDU1LDI1MCwxMzcsMTMxLDEzNywyMTgsMjMsMTE4LDE4NSw2OCwxNzYsMTY2LDk2LDMz LDE3MSwxODEsMTcwLDE4Miw0NCwxODEsMjQ2LDk2LDE2MiwxMDQsNzAsNDcsMTcyLDIwMiwy MCw3MywxMTEsMjE2LDI3LDg3LDExLDkzLDIyOSwyMDgsNTYsMjQsMTgwLDExOSwxNjYsMTcz LDE4OSw3NSw0Niw3MCwyMjUsMzIsMTcsMTczLDE3OCwxNjgsMTQzLDE4NSwxMzQsMjI4LDc2 LDE3OSwxODMsMTMwLDI1NSwxMjksMjExLDE0MCwxNzYsMTczLDIwOSwxMCwxMzIsMjI0LDE5 MSw0NCwxNTMsMjQsNjYsMTE1LDM0LDEyMyw4NSw1NiwxNzEsMTgxLDM3LDE1Niw3LDE2OCwx OCwxMSwxMjYsMjI2LDE0MiwxMzUsMjQ1LDg5LDEwLDE2OSwxODQsMTg5LDE0NywxNzMsMTYz LDE3Niw3NiwyNCwyMjAsMjYsODQsMTY3LDE3NywxNjksMTgyLDE2MiwxODUsMTMxLDg0LDQ4 LDEwMCwyMzksNDIsMTYwLDE4NywxOTEsMTMzLDYsMTcsMTM0LDksMTYwLDEyNiwxODAsMjAz LDU4LDE4MSw5NiwxNiwxMywxNDIsMjIzLDEwNSwyMTcsNDQsMTAyLDE3NiwzMSw5LDIxLDM0 LDEwMSwxMTMsMjE3LDExLDIwMSw2NiwzNiwxOCwyNCwyMDAsNTAsMTkwLDExMiw0Myw4LDUs NzQsMTQ3LDE2NCwxNzgsNDgsNTQsMTA1LDE2LDkwLDE5MSw3OCwxNzEsMjA3LDI0LDE5NSwx MzMsMTI4LDExNiwxNzEsMTUwLDE3LDE3MiwxOTQsNDMsMTA5LDEwOSwyNCw1MiwxNjQsMjEs MjQzLDYyLDE5MCw0LDEzNCwyNDUsMTM0LDE4MCwxMiwxOTEsMTg0LDU0LDE3Niw0Niw2LDE2 OCw3LDE3NSwxMCw0Niw2NiwxNDEsMTAxLDI5LDE2OCw5MSwxNTcsMTYzLDIxNiwxODIsMTYs MTMyLDU5LDI0MywxNzIsMzYsMTgwLDEzNyw4NiwxMjksNzAsNDMsMTk1LDEyNiw3MSwxMDMs MTAyLDQyLDE0OCw4LDE2OCwyNDAsODksMTEsMTcsMTAyLDE3OSwxMTksMTg0LDE1MCwxMCw2 Niw4OSw1NCwxMjksOSwxMzksMTY1LDQ4LDE2NSwxLDI2LDEwMywxNzUsNjYsMTA3LDY2LDIz Niw3MSwxNywxODgsMTMxLDE1MywyNiwxNzksMTg1LDcsMjMyLDIzLDE0NCwxNjksMTQ2LDEy LDE4OCw5NiwxMDIsMTM4LDE5MiwyNDUsMTczLDMyLDEwMywyMjMsMTksMTgwLDU1LDE4Mywx OTksMTEyLDE4NCwyNSwxNzksMTc5LDgsMTQwLDcsNzgsMTgsMTQsMjE0LDIwNSwxNjAsNTgs MTYyLDksMTY5LDIwMSwxNiwxMDIsMTA4LDE5Myw5MCw3NSwxMDAsMTM3LDE4OCw3NCwxMjMs MTgwLDEwMCw3LDIyOCw5NSwyMSwyMzcsMjEwLDIxLDEzNiwyNDQsMTAwLDIwNywxNjMsMTgz LDEwNiwyNDAsMTE3LDc1LDIxNCwxMzAsMTEwLDksNzIsMTQ3LDE2OSwxNzcsMzYsNSwyMzYs MTU1LDQ1LDExLDE3NSwxMCwxNDQsNTAsMjE2LDk2LDE0MSwyMTksNiwxODcsNywxODMsNDcs NDMsMTE3LDEwNywzMCwyMDAsMjE1LDYwLDExLDE4MCwxNzQsMTgyLDIwOCwyMzYsMzMsMjE1 LDIwMSw5LDEzMywxNzcsMTI5LDE1NSw0NSw4MCw5NiwyNDcsNjgsMTg0LDksMTE5LDM4LDI5 LDg4LDg3LDIzMSwxODAsMTEsMTYyLDE4Myw5MSwyNDIsMjM2LDQ0LDI1MywxNzQsMTI2LDE2 OCwxNzYsMTEsMTE3LDUxLDcyLDE1MCwxMzUsMTUwLDQyLDE3MCwyOSw0MCw4NCwxNTIsOTgs MjA1LDY0LDE1OSwyMjAsMTgsMTA2LDE0MSwxMiwxNzIsMTMsNywxMiwyNCwyMTQsMTMwLDU3 LDExOCwxMCwyMDQsMzMsMTcxLDQ1LDEwNywyMjgsMTExLDI0NSwxMSw3NCwxOTgsMjAwLDE1 MCwxNzIsNDgsMjUsOTksMTEsMTg4LDE1LDk0LDYzLDgsMjQ3LDE4MywxOTAsMjQwLDEwMSwx MDIsMTA2LDc5LDcyLDE1MCwxNzIsMTgwLDE4MiwxMzgsMTI0LDEyLDEwNCwxOTMsMTU2LDEw NSw2MCwxMSwxMiwxMSwyNiw1NywxMzAsMTgxLDE5MCw5LDE1LDQ3LDExNCwyMDQsMTE0LDE5 MywxMSwxODMsMjM5LDE0NywxNzIsODUsNDIsNTcsMjYsODQsMjEzLDgzLDUwLDI2LDE3Miwx MzcsMjIsMTE1LDE2MiwxNjgsMTEsMTc4LDQ4LDk2LDEzMSw2OSwyMiwxMiwxNzksMTQyLDE2 OSwyMiwxOTUsMTg2LDM2LDk5LDEwLDE4MSw5LDEwLDE5NiwxNzgsMTQ1LDExMSwyMjMsMTY5 LDE5MSwxMiwxOTksMjM2LDUsMjA0LDE3MywxMywxOTksMTQsMTY1LDQzLDgsMTc5LDkxLDE5 MCw2NSwxOTQsMTk1LDEyLDE4LDE5OSwxNSwxNjYsOTcsMjAsMTQ1LDI3LDEzMSwxNjIsNzAs MTc5LDg2LDIyLDc3LDkxLDczLDE3NiwzOCw1Myw4NiwyMDUsMTY3LDEyOCwyMjIsMjE3LDI2 LDM1LDE3Niw3MSwxNzksNTgsMjgsOTMsODksNDQsMTQ2LDcwLDE4MywxNDQsMTI4LDkyLDEy MCwxNzksMjQ5LDEwLDUyLDE4OSwyMDEsNDEsNTUsMTA3LDE3MywxNjcsNjUsOCw3Miw0Mywy NCw2LDM4LDE0LDE4MywxNDcsNTcsMjgsMTQxLDg5LDkxLDgwLDE4OCwxMDAsMTkzLDI1LDE1 LDIwNSwxNCwxMywyMTQsMTQ3LDM1LDE2OSwxMjAsMTU2LDIyNiwxOTUsOTAsMTkzLDEyLDgs MTE1LDEyLDE3NSwyMDIsMjAxLDE5NCw2NywxNjgsODUsMiwyMTAsMjQ2LDE5NCwyMDIsMTgw LDU2LDIzMywxMzAsMTkyLDE2Myw5MywxNzQsMTY5LDE2MCw1MSw0OSw0LDI1NCwxMiwxODMs MjAwLDIwNCwxMjAsMjQ4LDE1LDIxOSwyNTUsMjAwLDg2LDEyNSwxODMsMjUwLDE0NiwxNDIs MTQyLDEzOCwxOTIsMjEzLDIxMywxNDEsMCwyMTIsMywxMjMsMjI1LDI1NSwxMzcsMTM4LDE0 NywxNTksMTU3LDE1OSwxNTAsMjEyLDE1OCwxNTksMjEzLDM1LDEzOCwxNDYsMTM4LDI3LDE5 LDIxNiwxOTEsMjUzLDE1MCwxNTksMTQ3LDEzOCwxMjgsMTQ3LDI5LDEzNiwyMTUsMTUxLDE1 OSwxMzcsMTM3LDE1OSwzNSwxNTEsOTYsMjU1LDUsMjQ2LDE0OSwxNTIsMTQ3LDE1MCwyNiwx NDgsMTU5LDE1NiwxNDksMTM2LDE1MSwxNTUsOTEsMjAwLDc5LDk2LDk1LDE1NSwxNDAsMTQ2 LDc5LDE1NywxNDksMTU5LDE0MiwxNDYsMTI5LDE4MSwyMjMsMjIsMTksMTU3LDEzNiwxNDMs MTMxLDE0MiwxNDIsMTcyLDI1MSwxMzUsMTc2LDUwLDE0NiwxNjIsMTU1LDE0MywxNDIsMTQ5 LDEzNywxNTMsMTQ5LDUsMTczLDE4MSw0LDExOCwyMDAsMjA2LDMxLDg0LDIyMCw1OSwxOSwy MTYsMjIxLDE4MywxNTMsNjQsMjE1LDE1MiwxNDksMTQyLDcsMTU1LDE1NiwxNDIsMzksMTUy LDEzMiwxMTEsMTEsMjM2LDE1MSwxNTIsMTU2LDI0LDE0NiwxNTAsMTQ3LDE0OCwxNTUsNiw0 Myw5MiwxMDQsMzMsNzksMywxNDgsMTQ4LDY2LDkxLDQzLDEwNywxMzMsNjYsMTMsMTA5LDMs OTIsMTA3LDM5LDE3NiwyNTUsMTY5LDEzOCwxNTUsMTUzLDE1OSwxNTMsMTUwLDE0MywxNTIs NjMsMTU2LDEzNiwyOSwxNCwxODIsMjQ2LDMzLDEwOCwyMTUsMTg4LDE1MCwxNDksMTQwLDE1 OSw2MiwzNCwxNTgsNjksMTg3LDEzMywxNiw1MSwxNDksMTQ4LDE0OSwyMTQsMjQ2LDEzLDMz LDE4OCwxNDMsMTQ2LDE0NywxNDUsODQsMTQzLDI0MywxNTAsMTYyLDI0MCwyMzgsNSwxOTQs MTU4LDYwLDE1MywyMTUsMzAsMTQ4LDE0NywxNDIsMTI4LDE4MiwyMDksNjIsMTI4LDExOSwx NTUsMTUyLDE1NSwxNDUsNTYsNjcsMTQyLDEyNywxNzYsMTk0LDksMjI4LDE0OCwxNTUsMTU5 LDE1MSw4OSwxMTksMTYxLDE4OSwxOTIsNDYsMTQxLDExMSwxNDcsMTU2LDIxLDE0MSwxMDks NTksMTMyLDExMiwxNTcsMTQ4LDEwNCwxNTMsMTQ1LDEzNCwxMzcsMTQ1LDI1NCwxMSwxNzIs MTA5LDIwNywxNDIsODksODgsMTM4LDEzNiwxNDcsMjE1LDE0MSwxNDksMjE1LDI0Miw4Mywx OTQsMjcsMTE3LDE1MiwxNDMsMTM2LDE1NywyMCwxNDAsMTQ3LDEzNiwxNDIsMTQzLDIxOCw0 NSwxMzIsMjQxLDEyOCwxNDksMTQ4LDIwNywyMzMsMTM3LDE0Myw0LDE0MCw5LDQ3LDE2LDEz NywxNDMsMjE1LDIzNCwyMzgsNDUsMTI5LDE4MSwxMSwxNTUsMTEyLDI0LDE3MCwyMTAsMTE4 LDEyOSwxMDksMTgwLDE1MCw4MSwxNDEsMjQsMTQyLDYsMTg3LDEwOSwxNDEsMTYsNDIsMjcs MjE1LDgzLDE0MiwxNDcsMTY5LDIzNywxMDksOCwxMDUsMTM3LDk0LDEyOCwzMCwxNDUsMTQ5 LDE1MSw2LDIxMiwxMTIsMTIsOTcsMTE3LDE1MywyMDIsMTIwLDE2NSwxOTQsNDYsMTMyLDIx OSwxNCwyMTUsMTM2LDEwNSwyMSw3MCw5MSw5NiwxNDEsMTM2LDEyMiwxNTQsMjMwLDYwLDEy OSwyMSwyMiwyMTYsMTUzLDE1NiwxNjAsMTE0LDU0LDEwMSwxMSwxMDksNzYsMjM3LDE1MSwy NiwxNDQsMTY1LDEyOSw1MywyMjAsMTk4LDE0NywyNTMsMTQwLDIxMSwxNzIsMjAyLDU0LDk3 LDU5LDk3LDEyMCwxMzYsMjA0LDIxNSwyMjUsNDIsNDUsMTcyLDQsMjQ3LDE1MSwxMzAsMTQ2 LDIxNywxODksMjA4LDEzMCwxOTQsMTYsMTMwLDQzLDcwLDIxMiw1MiwyMTUsMjQ1LDgyLDU5 LDEwMSwxNjYsMTA4LDI4LDIwMSwxNDIsMjM0LDM3LDg2LDIxNCwyMiwyMTgsMTQ5LDIwOSwx MDgsMTUzLDg2LDU2LDE3Niw0NSwxNDgsMjYsOCwxNDIsNjcsNDksMTU4LDYzLDE1MCwxMzMs Myw4LDE3MywxNjksNjQsMTgsMjAwLDE0MywxMywxMSwxMzIsMTA5LDEwNywxNTEsMjgsMTU3 LDIwNCwxNDAsMjU1LDAsMTUyLDE1OCwxMCwxNzYsMTY4LDIxNSwzOSwyLDE2Myw4MCwxMDYs MTU0LDEwOSwxODUsMjQ3LDU1LDE5OSw0LDI0MiwxNTYsMTU3LDE0NSw4Niw1MiwxNTksMTQ4 LDUwLDUyLDcwLDgsMTM5LDEyMyw5Myw4LDIzNSwxNDUsMTk0LDk2LDIzNCwyNTEsOCwzMywx NDAsNjYsMTUsMzAsMjIwLDg2LDQyLDE4MCw2NiwxNSwxMTksMiwxODksMjAyLDEwLDIzOCwx NywxNDksMTUzLDMwLDcwLDgzLDQ2LDc1LDE2NSwyMTksMTMyLDEzNiwxNTgsOTEsMTg1LDE0 OSwxMzYsMTQzLDIxMSwxMzUsMjIsNjQsMjAsMjE3LDIxNSwxNDksMTg0LDkyLDMyLDE4MSw1 NCwxNzEsMTQ5LDE3NywxMjQsMTQ1LDkyLDE5OSw2LDksMzgsNzEsMTQzLDE0OCwzMSw4Nywy MTQsMTAsMjMsOCwxNTcsMTQ3LDEwMiwxMCwyNDMsMTU4LDEyOCwxODEsMTgxLDE0MiwxNDcs MjQ3LDIxMiwxNjMsMTk4LDEzNyw5MSwyNiw1Niw4Myw0MSw3Myw4MywxMzcsMjEwLDgsMzMs MTQ5LDUsMTQzLDE0NiwyNiwxNjcsODYsNDMsODAsMTkwLDEzNiw5MSw2OSw2MSwxMSwzMywx MiwyNiwxODIsMTEwLDIzMywxNDMsNDAsOTIsOTYsMjcsMTAsMTQ3LDE2MywxNTAsMTE3LDk5 LDEzMiwxODAsMTUzLDUxLDk5LDE1NywxMjMsMTA3LDQxLDIxNywxMiwxNzQsMTQ4LDMzLDIx MywyMzEsMTUxLDEzLDIxNSw3NCwyMjQsMTUxLDE0NiwxNDAsMjM2LDE4NCwxNTQsMTQ5LDk2 LDIzMiw3Niw3MiwyNTQsMTM2LDQsMjksMTgwLDIxOCwxODIsMTk3LDEzNywyMSwxOTQsMjQ1 LDE0MCwxNzksMjE4LDEyOSwxLDIxNCwxMCwzMSwzNSwxODMsMjI3LDk3LDE2MiwxMzcsMTQ2 LDEzNiwzOCwxMzcsMjE2LDEwOCwxOTUsMTk2LDE0OSwxMDQsMTQyLDIwMSw0NCwxMzEsNTUs NDAsODEsMTA2LDEsMjEsMTU0LDM1LDcwLDgsMjAzLDgwLDExNCwyNDksMTA4LDIzOSw4LDIz MywxOTQsMjQ2LDEyOCwyMTUsMTQ1LDM3LDE1MCwxNTMsMTQzLDE0NiwxNTUsMTAyLDkwLDMy LDExMywxNTgsMTUzLDI0MCwxNDgsMTE0LDE3NiwxOTIsMTUwLDE4Miw5NywxNDIsMjQyLDE1 MiwzMiwyMTMsMjQ0LDIwOSwxNDIsMTY4LDIxNSwxMzgsMTIzLDkyLDIxNSwxMDEsMTU5LDE1 MCwyMTksMjYsMTMzLDIzLDExOCwxNDEsNTUsOTUsMTY2LDUsMTgsMTQxLDI3LDI1NSwyNDcs MTQwLDEwOSwxMjksMTgxLDE1OCwxMDAsMjE2LDE1NSwxNDgsMTEsNjYsOCwxMSwxOTksNTEs NjEsNzcsOTIsMTMxLDM2LDIxOCwxNDIsMjUxLDkyLDg1LDE3Niw4OSwxODMsMTMsMTc5LDE1 NiwxMDIsMTUxLDE1OCwzNSwxNjUsMjEwLDg2LDIyNCw0NSwxMDIsMzMsMjUsMTQ4LDIwNCwx OSw2LDIxOCw0LDE1NiwxNjAsNjAsMTM4LDUzLDUzLDI4LDEzMywxODcsMiwxMDAsMTExLDEz NywxMzMsODIsMTA1LDE0NCwxMTYsMCw3NSwxODAsMTA4LDI3LDE5NCw3NiwyMDUsMzYsMjE1 LDEwMiwxNTcsMTM1LDE2MywyMDgsNzQsNDEsMTY1LDY3LDE0NSwxNjYsNjYsMzUsMTMyLDEz MiwyMTIsMjI2LDE3LDkxLDk2LDM4LDE5MCwxMzUsMTUwLDE1LDY5LDIzNSw2Niw5OCwxNjEs MTA1LDEyOCwyMDMsMTM3LDI0LDE0MywxMDIsMTgyLDIyOCwxNjIsMTc3LDExMSwxNTAsMzks MTQwLDE5OSw1LDc4LDEzMyw1LDIzOCwxNjcsMTQxLDk1LDMyLDIyNCwxMCw2MSw0MCwxODMs MTUzLDE0NywxNTMsMTk2LDQsMTQ2LDE2MSwxNDAsMzEsOTcsMTQ5LDEwNCwxODIsNDgsMTMy LDE5NiwxNDQsOTMsMTU1LDIyNywxNjUsMTgyLDE4OCw2NCwxMTAsMTU5LDEzMCwxNDIsMTE0 LDQxLDI1NCw3NSwxODIsOTAsMjM0LDE2NiwxMzEsMjUwLDIyMywxMzcsMTk3LDEzOCwxOTks MjIzLDEwNCwxODgsMTgxLDEzMywxNjUsMjIwLDI0Nyw2LDEzNywyNTAsMTg3LDc4LDE4Miwy MDksMTAyLDkwLDIxNCwyNTAsNDksMTY0LDIxMywyNSwxMzgsOSwxMTAsNyw5MSwxMCwzNiwx NTYsOSwxNDQsMTM4LDE5MCwyNTAsMTU3LDE1NiwxMDksOTMsMjE5LDcwLDEzOCw0OSwyMjMs MTUwLDQyLDE4OSwxMSwxNjksMTk4LDg2LDE3OCwzMSwxMDUsMTQzLDEzOCwxNCw3MSwxNDIs MTI0LDIxOCwxMTEsOTksMjM2LDE0MSwxNDgsMTUsMTg5LDczLDE3OSw2MCwxOTEsMTQ4LDEy Myw5LDEwOCwxNjksMjUsMjI4LDI4LDg2LDE1OSwyNCwyMjEsODgsMTYxLDk5LDIwLDE4Miwx NDksMjQ1LDIxLDE4OCwyMzYsMTY5LDI0OSw4OCwzLDcsMjI2LDcsMjMsMTY5LDE1NSwxNDAs MTU5LDYsMTU4LDE4MSwzMCwxNzQsMTQ5LDE4OCw1Miw2NCwxOTAsMTQ3LDgzLDE4NSwyLDEx MCwxNzksMTM3LDIyLDIwMiwxODMsMTYwLDE1Niw1LDM4LDEwLDE3OSwzLDI0OCw5NiwxOTQs MjU0LDE3OCw4LDEzNSw3LDc4LDE4Miw1NSwyMTksMjUwLDAsMjE2LDIxOSwyMjksMjMsMzUs MTcwLDE5MSwxODIsMjUxLDYxLDIzLDU5LDEwNiw1MCwyNDcsMTU1LDI1MywxMjcsMjUwLDI2 LDI1MCwyNDQsMjE5LDI0MSwyNTEsMjU1LDI0NiwyNTAsMjUyLDg4LDAsMjM0LDIzNSw0LDE3 OSwyMzksMjA1LDE4NiwzLDIxOCwxNCwxMSwyNywyNTQsMzAsMTEwLDE4MiwyMzYsMTAwLDcs MjUwLDIwMiw1MSw2LDQwLDI1LDc1LDU0LDE3NiwyMzQsNyw2LDEyLDIzOCwyMzYsMTI0LDM1 LDE3MiwxOTgsMTYwLDIsMjE4LDAsMTM3LDY5LDI0Niw0MiwxMzgsMjM0LDU1LDUzLDEyNSwx OTMsMTkwLDE1MCwxMDIsMjM1LDI1NSwxNDQsMTcyLDI0OCwxODIsNDUsMjE1LDE0OCwxMjIs MjYsODIsMTE1LDE1MywxNiwyMTAsNTksMzcsMTU2LDc3LDM1LDI1NCw3MSwxODQsMjUwLDAs MTU0LDI2LDEzNSw0MCwxNjYsMTUzLDEyMiwyMjYsMTUyLDIxNyw5NiwyMjQsNDMsMTY0LDE0 OSw5MCwxMSwxNzAsMjM0LDIzOCwxNDYsMzksNDcsMzgsMjM0LDE0NiwyMzQsMCwxNSwxMDIs NTcsMTAxLDE0NywxMTQsMywxMDYsMjM0LDEwMCw2NCwxNTgsMTA5LDE1NCw4Niw2Miw0Miwy MzQsMzEsMTYsMjM0LDE5NSw2NSwxOTksNDcsMjI3LDI1MCwxODUsMTUwLDE1NywxNzgsMTYw LDE3NSwxMjcsMjAsMjgsMTczLDIwMCwxMywyMDMsMTA2LDE4OCwxODcsMjUwLDE1OCwxOTgs MTQ2LDEzMSwxNDIsMjUxLDI1MiwxNzMsMjQ3LDM2LDEzNywxOTcsMjEwLDE4Myw0NiwxODIs MjQsMTUzLDMxLDEzMSwyMiwyNTAsNjcsMjQ4LDE3MywxMjksMTgxLDcwLDIzOCwxNzksMzYs MjUwLDQxLDI0OCwyMDYsMjAwLDUxLDQyLDY1LDMsMjA4LDIzLDE3Nyw3OCwxODIsNDQsMTA5 LDIxOSw4MiwxMjMsMTE1LDI1MCwyMTcsOTYsMTU5LDgsMTkxLDIzMSwxNTMsNTQsMTIzLDEz Miw0MywxMDMsNzcsMjM2LDI4LDE5MCwxOTIsMjU1LDEwLDg4LDE1NCwxMzUsMjQ2LDI1MSwx NDMsMTg4LDEwNiwyMzMsMTIwLDIyNyw4MywxMDAsMTQ2LDI2LDE4MywyMzQsMTgsOTcsMTc5 LDE0NiwxLDIwNywyMjIsMjE3LDE0LDk4LDE5OSwxMCwyMjMsMjUwLDIyMywzNiwxNjAsNzks MjQyLDIyNiwxMDYsMjI5LDIwLDE0Niw5Nyw4MSwxODksMTg1LDI0Nyw0MSwxMSwxOCwxNDEs MjUwLDk1LDEzMCwxNTgsMTY0LDE3MCw4MSwyMDEsMzMsMTA2LDE4NSw4MSwxNiwxNDYsNzcs MTg4LDIwNiwyNTAsMTM2LDU0LDY4LDYxLDIxOCw2OCwyMjQsODcsMTA0LDEwMiwxOSwyMDks NDksODQsMTY4LDE3MiwyMTgsMjE3LDI1MCwyNDcsMywxOTYsMjQzLDYsMTgsMjQzLDI1MCwx NjQsODAsNSwyMjMsMTM4LDEwMSw3MCw3MCw3MCw1NCw1LDE0MiwxMzAsMTM0LDEyMiwyOCwx MjgsOTcsNzAsMTE0LDIzMSwyNTAsMjU1LDI1NSwyNTUsMTMxLDIxOCwyMDMsMjA4LDIwMywy MTMsMjAzLDE5MiwyMDMsMTgxLDIwMywxNzQsMjAzLDY0LDIwMyw1OCwyMDMsNjAsMjAzLDU0 LDIwMyw0MCwyMDMsMzQsMjAzLDI1MCw1OSwxMCwyMSwxMDEsMCw2LDIxOCwxNTYsMTIxLDEw OCw5LDc2LDU2LDcxLDIxNCw4LDE0MiwxMzAsMTQyLDE2NSwxMDksMTMxLDEwOSwxNTcsNiwx NDgsNjYsMTU5LDgsMTM4LDcyLDIxNiwyMTksMTIzLDE4MSwxNDYsNSwyMzUsMjcsOSwxNDcs MjQ3LDI0MCwxMiwyMzcsMjM1LDM3LDEyNiwyMTgsMTk5LDIxOCwyMTYsMTc1LDEzNywxNjUs MjAwLDU4LDIxNiwyMywxNTksMjI4LDEzNCwxODEsMTY5LDUxLDczLDI2LDE4MywxODEsMTUy LDE0NCw4NSwxMDYsMjMzLDc3LDE2NSwyMTAsMjE2LDE2OSwxNTMsMTYwLDEzOCw3NiwxMDMs MzksMTIwLDUwLDE2NSwxNjQsMTY5LDE3OSwyNywyMTYsMTMsMjMwLDIyMCwxNzgsMjExLDU3 LDEyMiw1Nyw2NywyMTIsMjM0LDE3OCwyMDcsMTU3LDY1LDE3NCwxMDksNTEsMjEwLDEzMSwx NzQsMTAsODgsNDgsMTAzLDE4Miw1MywxNjMsNDksMTU5LDEyMywyMjEsMjMxLDI5LDQyLDE4 MCwyMSwyMTAsMTg0LDM2LDIyMiwxNTUsMTkyLDE4LDM3LDExMCw2LDE1NSwxOTksMTYzLDIz NSwxMzEsMTA4LDU1LDgzLDE3NCwxMzIsMTgsMTA0LDE5OCwxOTksMjAyLDIxMiwxNDksNTIs MjE0LDE1MywxMDcsMjQ3LDEzLDExOSwyMTIsNjUsMjEwLDIwMyw5MiwyNDcsNDcsNDMsMTM2 LDIxMCwxNTUsMjEwLDE0NywyMTEsMjExLDM5LDE0OCwxMTIsMzEsOTMsMTc2LDE3OSw4OCwx NDksNzksMTI4LDYsNywxODUsMjE5LDE4MiwxNzMsNCwxNDUsMTc5LDE4OCw4MSwxNjgsMTcx LDE1OCwyMjIsMjI4LDIzNiwxODksMTU3LDE0MCwyMDMsMjE0LDE1LDc4LDE1LDIwMCwyMTcs Niw1MSwxMTIsMTg3LDEzOCw5MCwzMywyMDEsNTUsMTUzLDEzMCwxNzEsMTcxLDIyLDUyLDIy NiwxNTksMTQ0LDc0LDE4MCwxNTYsNDMsNzEsMTM3LDk0LDIxLDIzMSwyMDAsOCw0NSwzNCw1 NiwyMjEsNzcsMTQ5LDIzOSwyNDAsNTgsNDQsMjEsMTM3LDIwNyw2NCw0MiwyMjIsMTc4LDU5 LDEwNiw0NywxMjcsMTQ4LDIxOCwyMTAsNzIsMjUsMTM5LDIyLDIzOCwxOTUsNDIsMTM5LDE0 MywxNDcsMjA0LDE4NCw5OCwxODEsMTkxLDEwOCwxMTEsMjE0LDQsMywxNTAsMTk4LDE3OCwx NzQsMTgzLDE4MiwxOTYsMjEsMTI5LDU1LDIzMiwxODgsNywxOTEsMTg3LDE5MCwyMjcsMTgy LDE5MSwxOTYsOTYsMTI3LDE3OSwyMjEsNywyMTgsMTc1LDEzOCwxNTgsMTE1LDE5OCwyMTMs MjEsMzgsMTc0LDE4NywxOTIsMTkxLDg1LDE1LDE5MiwxODcsMTcwLDU4LDE3NCwxOTksMjE4 LDE3OSwxOTAsMTk5LDIxNiw4OCwxMzksNiwyMzYsMTcxLDIxNiwyMTgsMTgsMTgwLDEwNCwx OSwxMDgsNSwxNTAsMTI4LDEsMTkwLDEyNCwxMCwxNDgsOTQsMjUxLDE3Niw2Niw5MSwxMywx NjksMTc0LDE2Myw3MSwxOCwyMjIsMjE5LDE1NCw0Myw4LDIwLDQ5LDE3MCw1MCwxNiw2LDIw OCwxODksMjE0LDEyLDYzLDksMjAsMTgxLDU3LDI1MywxMDMsNDYsMjI0LDE2MiwxNzQsMTM5 LDI0LDE4MywxODcsMTYyLDE3OSwxODMsMTc5LDE2MCwxMiw1MiwyMzYsODYsODQsMTc0LDE3 NCw0NCw2NCwyNiwxODAsMTkyLDIwMCwxOSwyMDQsMTgxLDUwLDcwLDE4OSwxODMsMTM5LDMy LDE4NCwxODcsMTE5LDE4LDIyOCwxMDQsMjQ2LDIzLDE4MSwxMTIsMjAyLDE4MCwxODUsMTkx LDE5LDIxLDExNSwxNTEsMTgxLDc3LDkxLDE3MiwxNDcsMTI5LDIxLDIsMjE1LDc0LDEyMCwx Myw2Miw1OCw5MSw5LDU4LDcsMTU3LDQzLDE1MSwxMjksMywxMjgsMzcsMjE4LDI1NCwxMDks MTg3LDIxMywyNDgsMTY5LDE4NSwxNjgsMTc5LDE3MiwyMTgsNjUsNTksOTksMTgzLDgwLDE4 MiwxODksMzAsMTcyLDE4NCwyMDgsMjE2LDI5LDE0NCwyNTQsNjUsMTg2LDE4MywxMzEsMTg4 LDEyLDEzOSwxNTYsMTUwLDIxMiwxNDAsMTUyLDEzNywxMCwyNDcsNiw3MiwxMjIsMTg4LDE2 OSwxODEsNiwxNzQsNTMsNTksMjAxLDE1MiwxNDEsMTQwLDI1NCwxMDIsMjUyLDEwLDE2OSw2 MSwxMTgsMzksMjEyLDE0MSwxNzgsMTE4LDE5MywxOTQsMTEwLDIzNyw1NCwyMzQsMjIwLDIx OCwxNjYsMTM3LDE1MCwxNTYsNzAsMTk4LDIxNCw2LDgyLDIxNCwyMDIsMjAsMTQ1LDY2LDEz MSwxNjQsMTYsNTQsMjE2LDQ1LDIzNiw2Niw4OSwyNywxMDAsMjMwLDIzMSw4MCwxMCw5Nywx MzEsMTc2LDMsNzQsMTcyLDE3LDE4MiwyMDIsMjQsNTcsNDUsMjE2LDE3OCw2Niw4OCwyNyw2 NiwzMiwxNyw1NCwxNzYsNjYsODcsMzQsMTAsOTcsMzMsMTcyLDEwOCw0Niw4OSwxNzIsODAs MjQ2LDEyOSw3MywxNTAsMjA1LDgsMjcsMTAwLDMsMTI4LDI3LDI4LDMzLDEwOCw2NSwyMTQs MjEzLDc2LDE3Miw1MCwyLDg4LDIzNCw5NCwxMzIsNCw2Niw5LDAsMSwxNTAsMTYsNzIsOTcs ODQsMjMsMTE3LDEyOSw2NCwxMCw5MSw0Nyw0NSwxMDksMTUxLDUyLDE3NiwzNCwxNTMsMTgw LDE5NywxNDYsMjYsNDYsMjI4LDIwNCwyMzksMTgsMTg4LDE5MCw4MywxNzMsMTM0LDIwNSw5 OCwyMTIsMTQ1LDEwMSwzMiwxMyw3OCwxNjAsMTQ5LDE0NiwzNCwxMDMsMTkzLDE2OSw4OSwy MzgsOTcsNjcsNDEsMjEyLDE2OCwxNzEsNzMsMTYwLDEyOCwxMDUsMzMsMTAwLDIwMiwyMTAs NDUsMTIzLDIwNSw0MiwyNDAsMTIxLDEzNiwxMzQsMTQ0LDE2NiwzMSwxMzMsOCw2MCwxOTYs MTQxLDE2OSwyNywzLDIxMCwzMywyNDAsMTMwLDE4MSwyMTEsMzIsMjIsNDMsMjEwLDE5MCwx NiwxMzYsMTkyLDIxMywyMjcsMjQ3LDI1MCwyNTEsMTg1LDIxNCwxMDQsMTY3LDE2NSw5Mywy MjEsMTEwLDYyLDIzOCwyMjgsMTA5LDIxMywxNjAsMjUzLDE0NywxNTksMTQxLDE1OSwxMzYs OCw1NCwxNjcsMTQ3LDE4MSw3MCwxMDcsMjA1LDE2MywxOSw4NywyMDksMTk4LDE0MiwxNywx MSwxNDEsMzUsNjMsMjUwLDE5MSwyNDYsMjMzLDIxOSwxMzEsMTExLDIzNywxMDAsMjI1LDE4 MywxNDcsMTAyLDExMiwxNDksMTU2LDE0MiwxNjYsNDEsMjE4LDg2LDE4MCw3LDE2NiwxODUs MTQzLDM0LDksMTcyLDY5LDEwNiw4NiwxNzQsMzMsMTUxLDE2NiwxOTQsNzMsMTA5LDM4LDIz MiwxOTgsODMsMjEyLDE0OSwyNTAsMTc5LDQsMTI4LDkwLDE1MywxODMsMTgzLDE1NywyNTAs MjE1LDE5LDE0NiwxNDIsMTU1LDEyMSwxNTIsMjI4LDQxLDE0MCw5MiwxOTIsOTksMTg2LDE3 OSwyMTQsMjYsMTM0LDE0MiwyMiwxNDgsNzgsNjIsNDksMTM4LDI1NSw3MCw1LDE4NiwxNzEs MjA3LDE3NiwxNTIsMjQ4LDI0OSwyNTQsMjU1LDI1MiwyNTMsMjQyLDIxMCwxMzAsMTY5LDgy LDk2LDE5OSwxMzUsMjIzLDIyOSw0OCwxNTEsMTcyLDE4NSwzNCwyNDEsMTMsMTEzLDEzLDU3 LDcsOTcsMzAsMTQ5LDEzNiwxNTcsMTc1LDYsMTgzLDI1MywxOTQsODYsMTUxLDE4MiwxODgs MTY4LDE4MSwxODMsMTkyLDE5OCwyNiwxOTYsMjMsMjYsMjE0LDE5MiwxOTIsMTg1LDIyMiw3 NSwxNCwxOTUsNjIsMTg0LDE2NSwyMDgsMTg3LDYsNDMsMTg2LDE1MSwyMzcsMTc0LDIyMiwz MCwxNjUsMjUwLDI1MiwyNTEsMTUwLDE1NiwyMTUsMTM3LDY1LDI0LDE4NSw2OCwxMDcsMjEx LDExMCwzNiwyNTAsMTQzLDI1MCwyMiwxNjIsNTcsODgsNzksMTMxLDIzMywyNyw3MiwxMzcs NDMsMjAsMjAyLDIwOSw1LDI0Miw2LDIzMSw0MywyNDQsNiwxODUsMTUwLDEyNiwyOSwyMzcs MTU4LDIxNSwxNTMsMTM4LDIxNCwyMjQsMjYsMTIsMjcsMjI4LDEzOCw1LDIzNiwxMDksMTY4 LDEwMiwyMzgsNSwxNDIsMTU4LDEzMSw3LDYwLDcsMTY1LDY2LDk3LDE0NSwxMzAsMzEsMTEy LDEyMywxMDIsMTYwLDU0LDg5LDI1MCwxMTYsMTM3LDk2LDAsMzQsMjE5LDIyLDQ0LDE4MCwx MjMsMTY3LDI1MCwxNzEsMTMwLDk5LDEzNywxMzgsMjMwLDExMCwyMDgsMTU4LDI1MCwzMywx NDMsMTMwLDUsOTMsMjA4LDE5OCwxNjAsMTAyLDIyMywxMTIsMTA0LDE1Myw0NiwyNywyMjgs OTAsMTg3LDExOSwxNDYsMTQ5LDE4MCw5Miw0LDE4OCwxNTUsODQsMjE5LDE2NSwxMDQsMTI4 LDM0LDIxNSwxNTUsMzMsMTg2LDcsMTk5LDE1MSwxOTIsMTgyLDI0MCwxNTAsMTU1LDE1Miwy NTAsNTQsMTM3LDEwNywyMDUsMjUsMTEwLDE0OSwxNDksMTU3LDIyMiwxMywxNzEsMjA1LDI4 LDIyMSw5MCw1MSwxMTIsMTUxLDEzOCw0NCwxMjcsMTk0LDgyLDI1MCwxMzgsMTA3LDE3Mywx MDksMTczLDU5LDIxNSw4NiwxNTUsMTkxLDExLDE0OCwyNiwxNTQsMTg3LDEwOSw5MSwxNiwx NTcsNDgsMTg2LDcxLDEzOCwyMTIsMTcyLDgyLDIxNCwxMzAsNzAsMjE5LDQxLDEzMSwxMjQs NDUsMjQ0LDE2NiwyNCwyMTgsMjE0LDIyMCwxNDksMjMwLDE2MiwxMzYsMTUxLDE4OSwxNjYs OTIsMjIxLDE5NCw1NSwxODEsMTY2LDI1MCwyMDgsMjEyLDIwOCwyMjEsMTQxLDEwNSwyMTIs MTYyLDE1NSwxMTcsMTU2LDIzLDI0MSwxNTEsMTM3LDE1NywwLDEzNyw1LDQsMjA1LDE1Miwx MjEsMjUxLDEzMCwxNTEsMTUwLDMwLDE1OCwxNTIsMTMwLDQsMTU4LDE1OSw5MiwyMjIsNTQs MTI3LDE5LDE0OCwxNTMsMTQ2LDE1MSwxNTYsNjAsMTQ5LDE1OCwxMzcsMTUzLDE1Niw5Miw1 OSwxOTYsMTkzLDI0LDEyMSw0LDMzLDE3Nyw5NSwxOTMsMjEsMTE4LDMzLDM5LDk0LDE1Miwx NTIsODQsMTg3LDI0NiwxOTMsMTE3LDc4LDE1MCw0Myw0OCwyMTIsMTQzLDIwNyw1MywxNTcs MTQ3LDEwOSwxMTAsMjM2LDExNSw2OCwyNCwxNTgsMTE0LDE0NCw2NCwyMDAsMTQ2LDI2LDEz NCwzOSwxOTUsMjMxLDE4OSwyMTgsMTgxLDE1Niw0OSwyMjcsMTgwLDk2LDIxOCwxMCwxNjIs MjAxLDE1NywxNzQsMTQ1LDQ0LDcwLDE5NSwxODIsMTA2LDE3MywyMTksMTQ1LDIyNywyMTks MTg0LDQxLDE4MSwyNDcsMzMsMTgwLDE3LDE2MiwxNzAsMjE0LDExLDYsMTg1LDIyNiwzOSwx MzUsNDcsMTQxLDIxOCwxNzcsMTU5LDEzMSwxOSw1NCwyMDQsMTY1LDIzNiw1Myw5NSw0NSwz OCw1MywxNzMsMjA4LDE0LDEwOCw0NSwxNzAsMjUsNzksMTcsMjAsMjAyLDE3MywxODEsMTM3 LDExLDQsMTAsMTU1LDE1MCwxMjAsMTA0LDE2NSw4Nyw0Niw4NSwyMTgsMTUzLDEwLDE1MCw3 MiwyMSw5MywxNTEsOTMsMTgzLDIxOSwyMTksNDIsMjE4LDU1LDE1OSwxMDQsMTU3LDEyLDE4 MCwyNTQsMTU1LDIxMSw4OCwxMDEsMTM5LDEyMCwxMzUsMTQyLDEyMywxMzcsMTA0LDM3LDE4 OCwxMDksNTAsMTgwLDE0NywyOSw3LDUwLDE0MiwxNDUsMTMxLDE3Miw4NSw0OSwxMCwxNTgs NTgsMjE2LDIzLDE4MiwyMDgsMjE4LDg5LDY5LDEzOCwxNTIsMTQsMTIsMTQ2LDI0LDE5NSw5 OCwxNzMsMTM3LDc0LDEzMCwwLDU4LDIyOSwyNSwyOSwyNDEsMTY4LDE2OSw4LDkyLDIxOCwy MjEsNTcsNTYsMTAyLDE2MiwyMzQsMzMsMTg3LDE0NiwxNSw0Myw5Niw5MSwxMDcsMjM5LDg3 LDY1LDIwNSw1MCwxNzYsNzUsMTMzLDIyMCwxMTgsMTgyLDE0OSwyMjEsMTQ2LDg5LDIzMywx MzAsMTU1LDkyLDE3Miw5OCwxMDcsMTMsMzcsMTQ1LDIzNywxMzAsMTYyLDIzNywxNzIsMjE5 LDE0LDE5NCw0OSwxNDEsMTk1LDE2MiwwLDIxOCwyMzYsNDEsMjAyLDIzMCwyOSw5MiwxMzYs MjcsMTM3LDcxLDE5MywxNTAsMjIxLDU2LDE4NywxMjYsMjE4LDIwNCw0MSwxNywyMDksMTMy LDksMjM4LDIwNywyMTgsMTcwLDEwOCw0OCw2MiwyMzIsMTgyLDIwNSwxMzAsMTUwLDE0Mywx MjQsMTUyLDcxLDE3MCwxNDYsMTYwLDE3MywxNzMsMjUsMTUsNCw0NSwxOTUsMTc2LDE0Mywy Niw0NCwxODAsMTksMTA0LDE4MywzNSwyNCwxMzAsMTQ4LDEwMSwxNzAsMTMzLDE0LDEyMCwx NDAsNzUsMTQzLDU4LDIxNiwxMTAsNzcsMTczLDYyLDE2NCw0OSwxNDYsMjI0LDE0MywxNTIs MTUsMTQyLDEwLDEzLDk4LDIzMCwyMzYsNjgsMTE4LDgyLDE2OCwxMjUsNTksMjE0LDU5LDEy LDI1MCwxNTgsMCwyMjEsMjE0LDIyMSwyMTgsNSwxOTgsMTczLDIzMCwyMTQsMTAxLDAsMjE4 LDEzMSwyMTgsNjcsMTc4LDE5MiwxNDMsMjE2LDU0LDE4MiwyMTAsMTkyLDYyLDksMjIzLDQy LDE0NywzLDIwMCwxNCw5MiwyMjEsMjE0LDkxLDEwLDE5MCwxMzIsMTkyLDg5LDYzLDIwNCwx MDYsMjA4LDE4MiwxNDksNywyMTYsOCw0Nyw2MSwxLDE1MSw0OCw4MywxMjksMTYsMTEwLDI0 NCw0NSwxMTcsMjEwLDIxNyw0NCwxODMsMTM0LDIxNSw1OSwxOTIsMjE2LDE2OCw4MSwyMzYs MzAsMzIsMjAzLDE0NywyMTUsODYsMTQyLDkwLDE2LDYwLDIxLDE0MCw4NywyMTQsMTg2LDEx MSw0NSw5NCwyLDIxNSwxNzQsMTMxLDEzOCwxMDEsMTUxLDIxMywxNzYsMjM3LDIxNCwyMzQs MTYyLDQxLDIxMywyNywxNjQsMTU4LDE5MywzMSw4NiwxNjgsODYsMTc2LDIxOCwwLDYzLDQs MjQsMTU0LDExLDE4MiwyMDksMTMxLDE0NiwyMTUsMCwxMTksMzAsNzAsMjQ2LDEzNCwxODUs MTg4LDE1LDE3LDc5LDEzNCwxOTgsMTY2LDEzNSw3MCwyMTMsMjMsMTUwLDE5MywxMDUsMTQy LDIwOSwxMDYsNTIsMTksMTA4LDYzLDMxLDM4LDAsMSwxMDcsMTgwLDgwLDE0NywyOSw0NCwx MjAsMTk3LDYsNDUsMjAyLDEzNywyNDUsMjE1LDEwNiw4Miw4OSwyMjUsMjMwLDE5Miw1Nywy MDUsMTUyLDU2LDk0LDYsMjE4LDE2MSwyMTQsMTcsODcsMTI4LDg0LDEyMCwyMzYsMjM3LDMy LDEyMywxNDMsODEsMTUyLDExNywxNTksMjA0LDIwNiwzNCwzNCwxODAsODgsMTc3LDE1Nywx MDEsMTEsMTE2LDg0LDEwNywyMCw5OSw3OCwxNjEsMTAxLDE5MywzOCw0NCwxNzYsMjQsMTM5 LDg1LDc1LDgxLDk2LDQyLDI1MSwyMCwxOTYsMTU1LDE1NSw3OCwyMTQsMjYsOTUsMTcxLDMs MTg0LDk0LDIxMywyMTMsMjQsMjMsMTMyLDQ1LDU5LDIwOCwxMzcsNDUsMTc3LDE3Niw5Niwx MTEsMTYsMTgsMTQ5LDI1MCw0LDE1OCwyMjQsMjA3LDEyNSwxMDksMywxNywyMTIsMjUsMywx OTgsMTUyLDEzNiwyMzksMTkzLDEzNSwyNDcsMTI2LDksMTU3LDE5NiwxOTgsMzAsMTcsMjE3 LDEwNywxNzcsMTgsMTk4LDksNiwyMiwyMjgsMTA0LDE2NSwxNzMsMjEwLDE5OCw2Miw4MCwx MzcsMTY4LDkzLDE5Niw5NiwzOSw5MiwxODAsMTU4LDE5MiwxOCwxOTYsNjQsMTcwLDIzNiwy MTYsMTYxLDIwMywyMDMsMTE1LDE1OCwxMzgsMTIsMjE4LDIxNSw5LDEzLDk5LDE3OSw1NSwy MiwxMywwLDE2OCwxOCwxODMsNDYsMTkwLDksMTgwLDEzNyw3MiwyMTAsMTMsMTc4LDEzMiwx MDYsMjM2LDIxMCwxNzcsMTQ5LDksMTYzLDE1NSw4MywxNDksMjE5LDEwLDE3NCwxLDEwNyw0 NCw1MywyNTUsMTIxLDEzMSwxMDgsMTQsNjUsMTM1LDIxNywxMTAsODQsMTkyLDIxMSwxMywx OTEsNzcsMjE4LDQ5LDE3MSwxOTgsMTMwLDk0LDMwLDE5MCwyNSwzLDEyMywxNTMsNDgsMTg0 LDEzMiwyNDgsMjksOTEsMTE0LDIwMCwxMDAsMjAsMTgzLDE5MSwxNDAsMTMxLDY3LDE5NSwy MjIsMTYsMjgsOTIsMjE2LDIzOCwzMiwxOTYsOTAsMTUzLDYsMTgzLDI1MCwxODUsMTI2LDYx LDkyLDEzLDk0LDU3LDEzOSw0NiwxOTMsODYsMTY4LDY2LDIzMywxMywxNjUsNiw0OCwxMDYs MTA2LDE4MSwxMDAsNzksMTg4LDE1NSwxMzAsNjgsMTE4LDIwNyw0NSwyMiw4NCwyMzIsMjM0 LDE1OCwxLDEwOSw5LDE2MywxNDksMTg1LDEwMSwxNDUsMTA3LDIxLDIxOCwzMCwxNTcsNTMs MTU0LDE5MywxNywxMjMsMTY5LDI2LDI4LDE2NSw4LDE5NSwxMDEsMzQsMjU1LDE0LDE0MCwx MywyNTEsMTUwLDExNiwxMzgsNTAsMTU4LDIzNiwwLDIxOCwxMTUsMTE3LDU0LDU5LDE1NSw1 LDE2LDIxMiwxMjYsNCwyMzgsMTAzLDMsODcsMTc3LDIyNiwxNDcsMTQwLDEzMCwxNTgsNCw2 NywyNyw4NiwxNTIsMTQ3LDExOCw0MiwxODIsMTgwLDkwLDQ0LDE4NiwxMTQsMjE4LDg3LDEw OSwxMTQsMjI0LDEzMCwxMDgsMTE2LDE0NSwxMzcsNzgsMTM3LDEwMSwyMTYsMzMsMTA4LDE1 LDE1MiwxNDcsMTYsMTM4LDE5NCwxMzgsMTc5LDEzNCw5MSwyMTQsMTEyLDIxMiwxNDEsMTU5 LDIzLDM1LDI1LDIxMiw2LDE3Niw2NSwxMDcsMTM4LDYsMTEsMTc2LDY3LDkzLDE0LDEzNywy NDAsMTEyLDMzLDAsMTE4LDI1LDcxLDIxNSwxMDgsMTg2LDUsMTgyLDEwOCwxMzEsNTEsMTc1 LDEzNywxNjQsNTIsNTgsMTIwLDEwMCwxMjgsNTUsNTMsMTUxLDE1Myw0MSwxNTUsMTc2LDE1 LDE1MiwyMTIsNjksMTg3LDE1MiwxNDcsNDUsMTYzLDk3LDE0MywxNzMsOTUsMTU2LDEzMiwy NDAsMiw4LDc1LDE4MiwzNSwyNDcsNzQsMTc0LDI5LDE3OSwxMzYsNDMsMjQ5LDE1MCw2Niwy OCwxNTYsMiw2NiwxNTgsMzAsOCwxOTgsMjI4LDE1OCwxNjEsMjE1LDE2MiwyNyw0NSwyNiwx MTUsMCw1OSwyMzYsMjA5LDU1LDE0MSwxOTQsMTM0LDE5MiwxMDEsMzMsMTcsNTQsMjcsMTg3 LDIzNSw1MSwxMjYsMzQsMTEsMTMyLDQ1LDQ0LDg4LDIxMCwzLDE1MiwyMTIsMTAyLDEzMCw5 OCwxNSwxMiw1MywxMTMsMTkwLDE5OSwxNDcsODIsNDEsMTM4LDI4LDE0NCwxNDAsMTY1LDIy NiwxNCwxNjksMjM1LDE1MCwyMTIsMjIxLDIyMyw0OSwyNTAsMjUyLDE2NSw1NSw0OSwxOSwx MzUsMTMsNTQsMTgzLDIyMywyOCwxNjEsMTc2LDExMiw3MiwyMjcsMTYzLDQ5LDE2NSwyOCwz Myw5Miw4OSwxMDQsOTYsMTY1LDc4LDE0MSw4NCwxNjUsNTEsMTQ4LDIyMCw5MSwxNDgsMTc4 LDE4NSwxNTYsMTY1LDE4MiwyNTUsMjEwLDUsMjQsMTEyLDI5LDE5OSwxNDIsMjMsMTQwLDgz LDEwOSwxMDcsMTc3LDI0OSwyNTAsNzksMTksMTM3LDMzLDIxLDE1NCwyMzQsNzgsODgsMTMx LDk1LDE4NywxNTAsNDQsMTY1LDk0LDE1OCw5MiwzNywyMjAsMTc0LDc4LDE3NiwxNDksNDEs MTI0LDI4LDEzMSwxMDQsMTEwLDE2NiwyLDk1LDEzNywxNjUsMTQ4LDE1Niw1Myw3NiwyMjEs MTU2LDEyNywxMDIsMTQzLDE1NiwxMjgsMSwxMDksNCwxNzMsMTU3LDEyMiwxNTUsNywxOTcs MTQzLDE0NywxMDcsMTQyLDIyMCwyMTUsMjksMTU4LDE3LDEzNiw2OCwyMzksMTcyLDE5Nywx MDgsMjIzLDE3OSwxNTIsMTQsMTA3LDE2OSwxNTEsODMsMTc5LDEzNCwxNTksNzYsNDgsNTIs MTI0LDEzMiwxNjUsMTUsMTY1LDIzNSwzMCwyMTQsNTAsMjEzLDkwLDM2LDIyMSwyMjIsNDQs MTMwLDU0LDg4LDExMiwxNDIsMTMwLDE0MCwxMSwxNDAsNzcsMTQ3LDE4NywxMDksNDksMTM5 LDY0LDEzOCwxNDQsMTI5LDE0MiwxNzQsNjIsMTE1LDk2LDE1MiwxNzIsMTQ4LDMzLDEzNywz MiwyMywyMjgsMTE0LDExNSwxMTEsNjgsNzIsMTg3LDE1MywxNTAsMjEzLDMwLDE0MywxMzgs MjIwLDE2MSwxODIsNzcsMTcyLDI0LDE0MywyMywzNiw1MCwxNDAsOTMsMjA0LDIxLDgyLDE4 NSw2MiwxMDQsMTQyLDE2OSwxODgsOTUsMTgxLDEzOCwxNiw2NywyMywyNTMsMTUwLDE2Nyw5 MCwxOTIsOTYsMTA0LDE2OCwyMzksMTA0LDY4LDE5MywyOCwxODUsMTY5LDI0NCw5NCw1Nywx ODEsMjE4LDM0LDEzMywxNjQsNTUsMTQ2LDExMiwxNjgsMTA5LDE3NywyMDIsMTY3LDExOSw5 MCwxODAsMiwzMSwxMDgsMTMxLDI0OCwxNDIsMTcwLDM5LDE1MSw1NCwxODMsMTQzLDE2Miwx MzAsMTczLDMsMjQxLDExMSwxLDE3NCwxOTEsMTgwLDE2MywxNzcsMTY5LDE5MCwxMTMsODYs MjcsMTgxLDI0LDIwNSwxODcsMTM3LDE4OCwyMTEsMTA0LDIwMSwxNjksMjU1LDI5LDE4MCw3 MCw3MiwyMCwyMzUsMjUwLDIyMSwxOTAsMjIxLDEzNiwyMjEsMTQ5LDIyMSwxMzgsMjM5LDI1 NCwxMzMsMTE4LDEsMTU5LDIyMSw0MiwxNjksMjIxLDE0NSwyMjEsMTMxLDIyMSwxODAsMTEs MTQyLDIyMSwyNTAsMTY1LDc3LDE3OSwyNTMsMjQ2LDIxNSwxNDksMTgxLDE1NSw3MywxMzQs MjE1LDIwOSwxNjksMjA5LDMsMTQ1LDEzMSwxODAsMjUzLDIxOSwyMTAsNTIsMTU5LDE0Miwx MzQsMTAxLDE3NywxODEsMTQ5LDIxNSwxNjUsMjUwLDE2MSw0OSwyMjYsODIsMjA2LDc5LDEz NiwxNjYsMTI4LDE2NywyOSw2MywxMDcsMTEyLDE4MCwxMzcsMTMxLDEwNiw2OSwxNTEsMTA1 LDE3NiwxNDUsMTUwLDE2OSwyMDUsMjEwLDUzLDgzLDE1MSw4MiwwLDIxNSwxOTYsMTc1LDYz LDk5LDE3NSwxNTMsMTk4LDEwLDE3LDEwNSwxNjcsMTY5LDIxNSwxNDUsMjIwLDI0OSwyMiwy NTAsMjE1LDEzMSwyMTUsMTgwLDIxNSw4MCwxNDIsOTMsMTYxLDIwOCwxNzAsMTQ1LDIyNSwx NDIsMjQ1LDE3MiwyNTAsMTYwLDIxMCwxMzksMTI4LDE2MywxNzYsMjEyLDEzMywyMzcsMTg1 LDEyOSwxNzQsODIsMTMxLDE5MiwxMTEsNjIsMjUwLDE5NSwxNjIsMTc4LDE0MiwyMzgsMjUw LDI0LDEwNiw2Nyw5MSw3MiwxMTMsMTM4LDE1LDE2NiwyMTgsMTg4LDIxMywxMzIsMjE0LDU0 LDgzLDE0MSw3LDgsOTIsNjEsMjE0LDI0LDIwNCwyNTAsNywxNzQsMzksODIsMTc5LDE4NSwx NzEsOTYsMTYzLDkxLDIxNCwxODIsMjUwLDY3LDEzLDE5MCw1NCwxNzYsMTM1LDEwOSwxMDgs MTczLDEwNiw0MSwyMDAsMTQ5LDI1MCw2NSwxNjksMzcsMjMsMTYxLDE3MSwxNDAsMTA1LDEz NywxOTAsMjI0LDE0LDIyMSw4MiwzLDg3LDUxLDUxLDEzOCwxMzEsNjcsMTcwLDUzLDcxLDIw NSwwLDkwLDcsMTQwLDg0LDEwMCwxNDIsMTAsMTc2LDg5LDE4MCwyMjAsMTU0LDEzOSw5Nyw0 NCw3MywxODksMTAxLDE4NywzNywyNTAsMTcsMjA3LDE3LDU2LDU4LDEzNywyMDAsNzAsMTMx LDEwLDQ4LDEwLDE5MCwyMTgsMTMyLDI1MCwxMTUsMSw4OSwxNDAsMTM4LDkyLDM0LDAsOSw2 OSwyLDExLDM3LDEzNywzLDI1NSwxNTEsMjAzLDE2OSw1MiwxLDg0LDgwLDEsNzEsMTAxLDEx Niw3NywxMTEsMTAwLDExNywxMDgsMTAxLDIxNiwyMiwwLDIwMyw3MCwxMDUsNzgsMTMxLDY1 LDE5LDg4LDExLDEyOCwyNTUsODAsMTE0LDExMSw5OSw2NSwxMDAsMTAwLDExNCwxNDQsMTUs MjU1LDIzNiwxODMsMjU1LDgzLDEyMSwxMTUsMTE2LDEwMSwxMDksNjgsMTA1LDE2LDk5LDEx NiwxMTEsMTE0LDEyMSwzNiw4NCwxMDUsOTksMTA3LDY3LDExMSwyMzYsMjE5LDIyLDIzNiwx MTcsMTEwLDExNiwxMyw2MCw3MCwyNywxMDksOTcsMTE2LDY1LDE1LDk5LDEwOSwyMzYsMTU5 LDkwLDExMSwxMTAsMTAxLDczLDExMCwxMDIsMjEsMTA1LDExLDIzLDg3LDEwOSwyNTUsMTMy LDI1MywxMDUsMTEwLDEwMCwxMTEsMTE5LDExNSw3NSwxMDgsMTExLDk4LDk3LDEwOCw2NSwx MDgsNiw5OSwyNDcsMTkxLDEwOSwxMzUsMTIsNzAsMjksMTAxLDExLDc2LDExMSw5NywxMDAs NzYsMTA1LDk4LDExNCw5NywzOCwyMDcsOTgsMjAxLDE4NiwxMyw5OSwzNywxMSwzNiw3Nyw5 NywxODcsNTMsMjQ3LDI1NCwxMTIsODYsMTA1LDEwMSwxMTksNzksMTAyLDE5NCwxNCwyMDQs MTA3LDY2LDEyMSwxNzQsMjM5LDkxLDI1MSwxMTgsODQsMTExLDEwNiwxMDAsMTAxLDY3LDEw NCw2MCwyMCw3OSwxMTIsMTAxLDExMCwyMTEsMTA3LDIxOSwxOTMsOTgsMjA3LDgsNTEsNTAs NDgsMTE0LDIxNCwxNSwyMDUsMjE4LDIzOCwxLDc4LDEwMSwxMjAsMTQsODIsMTAxLDExNiw3 NCwzMywxMjgsMjIxLDIwNSwxNzMsMTAzLDEwMywxMDUsMTA1LDY4LDExNCwxMzAsMTA3LDkx LDI0NywxMTgsODMsMTE2LDUsMTEwLDEwMywxMTUsMTM3LDgzLDI0LDY5LDE5NywxMTMsMTgx LDIyMSwyMDcsMTMsMTMsOCw2NSwxMTYsMzEsOTgsMTE3LDEyMCwxMTcsMTczLDI1MywxMzAs MzMsMTksODAsMTExLDQ5LDE2LDEyOCw4MywyMTgsMzMsMTMwLDE4NywxMSwxMDEsMTEyLDYs NzEsMjYsMTU3LDEwOSwyMTksMTgyLDI0NywzMSw5LDIxLDg0LDMzLDEwOSwzOSw5NywyNSwy MjUsMjMsMjQ2LDEwMCwxNjIsODUsMTEwLDEwOSwyMTMsODcsOTcsMTA1LDExNiw5MywyMzAs MTIsMTExLDE3NCw4MywxMjgsMTQsNzksOTgsMTA2LDU5LDIwLDIyMywyMzcsNDcsODksMTEs NzUsMjQ0LDIwLDExMCw2OSwxMjAsMzAsMjI1LDExOCwxODIsMTE2LDUwLDExNCwxMDEsNjEs MTA4LDExNywxMTQsOTksMTUyLDIwMywzMCwyNDYsMjE3LDksMTA5LDExMiwxMDUsMTAsMTEy LDEyMSw5LDQ2LDI0Niw5MCwxNzYsMTEwLDEwLDQ5LDksMjUyLDI1MCw0OCwyMTksMTAyLDEw MywxNjIsNzEsMjA3LDEyNywxMjIsMTIsMjI1LDExLDMxLDE0MywxNiw4NCwxMjEsMTEyLDQ3 LDY3LDE0NSwxMTUsMTAxLDcyLDk3LDE2LDE1LDEyLDI0Nyw5NCwxMDYsMjcsMjAxLDksNjcs MTE3LDIxNiwxOTMsMTAsMTMzLDExNCwxNjgsNiwyMjAsNzMsMTAwLDIwLDIxNSwxODYsMjA3 LDIsMTgsMTExLDEwOSwxMDksNjksNzYsMTkyLDg1LDQsMTIzLDcsMTk5LDcwLDM5LDE0NCwx MTgsMTQsMTU1LDEyMywzLDU5LDE3NSwxNSwxMjAsMTE0LDIzOCwxMDUsMjQ4LDE1LDIxOSwx MDEsNzEsNjcsODUsOTcsMjUxLDExMSwxMDgsMTA0LDEwMSwxMDgsMTEyLDExMCwxNzgsOTUs ODgsMjExLDgzLDg3LDExMiwxMTUsMTA0LDExMSwxMTYsMjUsMTA0LDYsMjcsMTgyLDIyNSwx NzYsMTAwLDEzLDc3LDE3NCwxMjAsNjUsMTMsOTAsMTUxLDQ4LDY3LDE5OSw3NywxMTIsMTAw LDE5LDEyLDIxOCw2NiwxNzgsMTk0LDExMSwzMSwxMCw2Myw5NywyNywxNTQsMTA4LDIzNywx OCwxOTAsODIsMTA0LDc1LDExNSwyMzAsMTEwLDE2Nyw4OSw5MCw2NSw4LDIyLDEwMyw2OCwy NSwyMCwyMDQsMjI1LDIyMiwxOTQsODYsNjgsMTE3LDU2LDE2LDIyLDEzLDEwOCwyNDYsMTAw LDExMSw2OSwxMTYsMzIsNzUsMTAxLDEyMSwxNCwxMTQsMTAyLDExNSwxMTEsMjE3LDE0LDIy MywxMyw4NCw3OCwxNTIsMTYzLDE1NywxNTcsMzIsMzMsNjYsMjQwLDMxLDEzLDIwMSwxMTAs NzcsMTExLDE0NCw5NSw5OCw3NCw2OCw2NywxODIsMjE3LDE1NSwyOSw3NCwxMDksMTI1LDk1 LDIyLDksMjI1LDk5LDU5LDE0MCw1Nyw3MCw4OSwxMTEsMjI4LDEwOCwxNzYsMTQxLDEwOSwx MzAsNTksNzMsODAsMTMxLDM4LDExOCwyMzksMjQsMTc5LDg5LDEwNyw4MSw5MiwxNCw0Nywy MDcsMTg0LDExOCwxOTUsMjIwLDEwOCw4LDYyLDE5OCw2NiwxMDcsNTUsMjE5LDIxNCwxMiwx MDMsMjUyLDg0LDE2NSwxMzEsODEsMTE0LDE2Nyw4OCwyMjMsNzYsNzMsNTQsNTIsODEsNDks NiwxMDksNzksMTEwLDcyLDIxOSw5MCwxMzUsNzMsMjEyLDU5LDE0LDEwNiwxMDUsMTAsMjI1 LDEwNSw1NCw3MSw3MSwyMTMsOTgsMCw4MywxNzEsNTIsOTEsMTk1LDE2MywxMDgsMTgxLDY2 LDY1LDY5LDExMCw2NCwyNDYsMjE2LDI3LDIzOCw2MywyMjMsMTE0LDczLDY1LDksNjgsMTE3 LDExMiw4LDIxNywxOTgsOTYsMTEwLDIsMTgsODQsMTMzLDEwOSw5LDI0NSwxNjcsMjMzLDIy MCw4MiwzOSw1NywxMjIsODgsODUsODIsNzYsNjgsMTY2LDE1NSwyMjgsMTg2LDEwMSwxMTAs MTA4LDY0LDEwNSwyOCwxMzMsMTA0LDU0LDEwOSwxNTcsOTYsMTI1LDExMiwyMDEsMTE2LDEw Miw3NywyOSw1OSw0NCwyMzYsNTIsOTcsMTAzLDgwLDExMSwxNDQsMjU1LDExNSwxMDcsMTA5 LDI1LDEwMiwxMDksMTQ5LDExMiwxNjQsNTMsMTIyLDExOSwxNDksMjYsNzksMjM4LDIyMiwy OCwxMDQsODUsMjcsMTcwLDI4LDc5LDc5LDIxMSw3MywxNDQsMTIwLDczLDIyMSwxMTAsMTg2 LDIzNiwxMDcsMjE3LDE0NiwyLDIwLDExNiw2NSwxNCwxNDAsMTI4LDE0OSw0Niw4NSw5Miwx NywyNDMsNTQsNjcsMjE5LDExMiwxMTAsMTEwLDgyLDEwMSwxMDAsMTk1LDQ3LDg5LDE1Niwx ODUsMTgyLDIzOCwxMDUsMTQwLDEwNSwzMSw5NSwxODgsMTAwLDU5LDY1LDY0LDE2MywxNzcs MTU4LDExNiwxOTIsMjQ4LDg1LDE1MiwxNTcsMjA0LDMzLDEyLDk4LDEyMSwxNCw3MiwxMjEs MjMzLDEwNywxOTIsODAsODgsOTksMTI4LDExNSwzLDEwNywxMDEsMTE2LDE5MSwyMDIsOTEs MTEwLDk4LDE4OSwxMTQsOTcsOTksOTksMzcsODMsNjUsMTI5LDIxNSwyOCwxMTksOTIsMTE0 LDExNiwxMTcsNDgsMzUsMjUsMTIxLDU0LDI1MSwxMDIsMTc0LDExOCw1MCwxMjIsMjAsMTA4 LDcsNjIsMjQ5LDQ3LDE5OSw5NiwyMDUsODAsNjksNzYsMSw0LDAsMjA0LDE1LDE0NCw2NCwx NTgsNTIsMjU1LDE1LDIyNCwwLDE1LDEsMTEsMSw1LDEyLDAsNjgsODYsNzIsODAsMjUxLDEy LDcsMiwyMjMsODgsMTMsNjQsMTEsMTEwLDIyLDEwOCw1NywyLDQsNTEsNywxMiwxOTIsMjA2 LDIyMCwxNDYsMjA4LDMwLDUyLDE2LDcsMTc5LDE4OCwzNiwyMjIsNiw3OSwyMDgsOTcsMjIw LDkzLDMyLDE0NCwyMDMsMTkyLDE2MCwzLDE2NywxOTYsMjUxLDE1NCwxNzQsMTc2LDEsMzAs NDYsMTk1LDExNiwyMzUsNjYsMTQ0LDExOSwyMywyNDYsNSwyMzUsNCwzNSwzMiwzMCw0Niwx MTQsMTAwLDExNiwxMzEsMjM3LDEwLDE3NSwxNjMsNzAsMTEsMjUxLDEyLDM5LDcyLDIxNyw5 OCwyMjEsMTMzLDY0LDIsNDYsMzgsNzEsMTE3LDEwOSw3NCwxNTQsMjM4LDExMiwzOSw1OCw4 NCwxOTIsNzksNiwyNywxMDgsMTI5LDExNSwxMzAsMCwyMzUsMTkyLDExNSwxNDIsMTkyLDE5 MSwyMjMsMjAyLDM5LDI3LDExMiwxMDAsMTMsMzMsMTk4LDAsMCwwLDAsMCwwLDAsMCwzMiwx LDI1NSwwLDAsOTYsMTkwLDM3LDE2MCw2NCwwLDE0MSwxOTAsMjE5LDExMSwyNTUsMjU1LDg3 LDEzMSwyMDUsMjU1LDIzNSwxNiwxNDQsMTQ0LDE0NCwxNDQsMTQ0LDE0NCwxMzgsNiw3MCwx MzYsNyw3MSwxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNCwyMzcs MTg0LDEsMCwwLDAsMSwyMTksMTE3LDcsMTM5LDMwLDEzMSwyMzgsMjUyLDE3LDIxOSwxNywx OTIsMSwyMTksMTE1LDIzOSwxMTcsOSwxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNSwy MjgsNDksMjAxLDEzMSwyMzIsMywxMTQsMTMsMTkzLDIyNCw4LDEzOCw2LDcwLDEzMSwyNDAs MjU1LDExNiwxMTYsMTM3LDE5NywxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcs MjE5LDE3LDIwMSwxLDIxOSwxMTcsNywxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDE3LDIw MSwxMTcsMzIsNjUsMSwyMTksMTE3LDcsMTM5LDMwLDEzMSwyMzgsMjUyLDE3LDIxOSwxNywy MDEsMSwyMTksMTE1LDIzOSwxMTcsOSwxMzksMzAsMTMxLDIzOCwyNTIsMTcsMjE5LDExNSwy MjgsMTMxLDE5MywyLDEyOSwyNTMsMCwyNDMsMjU1LDI1NSwxMzEsMjA5LDEsMTQxLDIwLDQ3 LDEzMSwyNTMsMjUyLDExOCwxNSwxMzgsMiw2NiwxMzYsNyw3MSw3MywxMTcsMjQ3LDIzMyw5 OSwyNTUsMjU1LDI1NSwxNDQsMTM5LDIsMTMxLDE5NCw0LDEzNyw3LDEzMSwxOTksNCwxMzEs MjMzLDQsMTE5LDI0MSwxLDIwNywyMzMsNzYsMjU1LDI1NSwyNTUsOTQsMTM3LDI0NywxODUs NywwLDAsMCwxMzgsNyw3MSw0NCwyMzIsNjAsMSwxMTksMjQ3LDEyOCw2MywwLDExNywyNDIs MTM5LDcsMTM4LDk1LDQsMTAyLDE5MywyMzIsOCwxOTMsMTkyLDE2LDEzNCwxOTYsNDEsMjQ4 LDEyOCwyMzUsMjMyLDEsMjQwLDEzNyw3LDEzMSwxOTksNSwxMzcsMjE2LDIyNiwyMTcsMTQx LDE5MCwwLDE5MiwwLDAsMTM5LDcsOSwxOTIsMTE2LDYwLDEzOSw5NSw0LDE0MSwxMzIsNDgs MTY0LDIyNywwLDAsMSwyNDMsODAsMTMxLDE5OSw4LDI1NSwxNTAsMTI4LDIyOCwwLDAsMTQ5 LDEzOCw3LDcxLDgsMTkyLDExNiwyMjAsMTM3LDI0OSw4Nyw3MiwyNDIsMTc0LDg1LDI1NSwx NTAsMTMyLDIyOCwwLDAsOSwxOTIsMTE2LDcsMTM3LDMsMTMxLDE5NSw0LDIzNSwyMjUsMjU1 LDE1MCwxMzYsMjI4LDAsMCw5NywyMzMsNCwxMDgsMjU1LDI1NSwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMiwwLDMsMCwwLDAsMzIsMCww LDEyOCwxNCwwLDAsMCw5NiwwLDAsMTI4LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwx LDAsMSwwLDAsMCw1NiwwLDAsMTI4LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAs MCwwLDAsMCw4MCwwLDAsMCwxNjQsMjQwLDAsMCwyMzIsMiwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxLDAsMSwwLDAsMCwxMjAsMCwwLDEyOCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMSwwLDAsMCwwLDAsMTQ0LDAsMCwwLDE0NCwy NDMsMCwwLDIwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxNjAsMTkyLDAsMCw0MCwwLDAsMCwz MiwwLDAsMCw2NCwwLDAsMCwxLDAsNCwwLDAsMCwwLDAsMTI4LDIsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMTI4LDAsMCwxMjgsMCwwLDAsMTI4 LDEyOCwwLDEyOCwwLDAsMCwxMjgsMCwxMjgsMCwxMjgsMTI4LDAsMCwxMjgsMTI4LDEyOCww LDE5MiwxOTIsMTkyLDAsMCwwLDI1NSwwLDAsMjU1LDAsMCwwLDI1NSwyNTUsMCwyNTUsMCww LDAsMjU1LDAsMjU1LDAsMjU1LDI1NSwwLDAsMjU1LDI1NSwyNTUsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDcsMTE5LDExOSwxMTksMTE5LDExOSwxMTksMCwwLDAsMCwwLDAsMCwwLDAsNywxMzYsMTM2 LDEzNiwxMzYsMTM2LDEzNSwwLDAsMCwwLDAsMCwwLDAsMCw3LDU2LDEzNiw1MSw1NiwxMzYs NTUsMCwwLDAsMCwwLDAsMCwwLDAsNywxNzksMTMxLDAsMywxMzEsMTM1LDAsMCwwLDAsMCww LDAsMCwwLDcsMjU1LDQ4LDI1NSwxNzYsNTYsMTM1LDAsMCwwLDAsMCwwLDAsMCwwLDcsMTg0 LDE1LDE5MSwyNTUsMywxMzUsMCwwLDAsMCwwLDAsMCwwLDAsNywxMjgsMTkxLDI1NSwxOTEs MjQwLDU1LDAsMCwwLDAsMCwwLDAsMCwwLDcsMTUsMjU1LDE5MSwyNTUsMTkxLDMsMCwwLDAs MCwwLDAsMCwwLDAsNywyNTUsMTkxLDI1NSwxOTEsMjU1LDE3NiwwLDAsMCwwLDAsMCwwLDAs MCw3LDExOSwxMTksMTE5LDExOSwxMTksMTE5LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDI1NSwyNTUsMjU1LDI1NSwyNTUs MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1 NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUs MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1 NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUs MjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDEy OCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUs MTI4LDEsMjU1LDI1NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1 NSwxMjgsMSwyNTUsMjU1LDEyOCwxLDI1NSwyNTUsMTI4LDEsMjU1LDI1NSwyNTUsMjU1LDI1 NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwyNTUsMjU1LDI1NSwxMzYsMTk1LDAsMCwwLDAs MSwwLDEsMCwzMiwzMiwxNiwwLDEsMCw0LDAsMjMyLDIsMCwwLDEsMCwwLDAsMCwwLDAsMCww LDAsMCwwLDAsMCwyMTYsMjQ0LDAsMCwxMjgsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCwyMjksMjQ0LDAsMCwxNDQsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwy NDIsMjQ0LDAsMCwxNTIsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwyNTIsMjQ0 LDAsMCwxNjAsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCw2LDI0NSwwLDAsMTY4 LDI0NCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMTgsMjQ1LDAsMCwxNzYsMjQ0LDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwzMCwyNDUsMCwwLDE4NCwyNDQsMCwwLDAsMCww LDAsMCwwLDAsMCwwLDAsMCwwLDQxLDI0NSwwLDAsMTkyLDI0NCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsNTIsMjQ1LDAsMCwyMDAsMjQ0LDAsMCwwLDAsMCwwLDAsMCwwLDAsMCww LDAsMCw2NCwyNDUsMCwwLDIwOCwyNDQsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAs MCwwLDAsMCwwLDAsMCw3NiwyNDUsMCwwLDkwLDI0NSwwLDAsMTA2LDI0NSwwLDAsMCwwLDAs MCwxMjAsMjQ1LDAsMCwwLDAsMCwwLDEzNCwyNDUsMCwwLDAsMCwwLDAsMTQ0LDI0NSwwLDAs MCwwLDAsMCwxNTgsMjQ1LDAsMCwwLDAsMCwwLDE3NCwyNDUsMCwwLDAsMCwwLDAsMTg0LDI0 NSwwLDAsMCwwLDAsMCwyMDQsMjQ1LDAsMCwwLDAsMCwwLDIxNiwyNDUsMCwwLDAsMCwwLDAs MjMyLDI0NSwwLDAsMCwwLDAsMCw3NSw2OSw4Miw3OCw2OSw3Niw1MSw1MCw0Niw2OCw3Niw3 NiwwLDk3LDEwMCwxMTgsOTcsMTEyLDEwNSw1MSw1MCw0NiwxMDAsMTA4LDEwOCwwLDEwMywx MDAsMTA1LDUxLDUwLDQ2LDEwMCwxMDgsMTA4LDAsMTExLDEwOCwxMDEsNTEsNTAsNDYsMTAw LDEwOCwxMDgsMCw4Myw3Miw2OSw3Niw3Niw1MSw1MCw0NiwxMDAsMTA4LDEwOCwwLDExNSwx MDQsMTA4LDExOSw5NywxMTIsMTA1LDQ2LDEwMCwxMDgsMTA4LDAsMTE3LDExNCwxMDgsMTA5 LDExMSwxMTAsNDYsMTAwLDEwOCwxMDgsMCwxMTcsMTE1LDEwMSwxMTQsNTEsNTAsNDYsMTAw LDEwOCwxMDgsMCwxMTksMTA1LDExMCwxMDUsMTEwLDEwMSwxMTYsNDYsMTAwLDEwOCwxMDgs MCwxMTksMTE1LDExMSw5OSwxMDcsNTEsNTAsNDYsMTAwLDEwOCwxMDgsMCwwLDAsNzYsMTEx LDk3LDEwMCw3NiwxMDUsOTgsMTE0LDk3LDExNCwxMjEsNjUsMCwwLDcxLDEwMSwxMTYsODAs MTE0LDExMSw5OSw2NSwxMDAsMTAwLDExNCwxMDEsMTE1LDExNSwwLDAsNjksMTIwLDEwNSwx MTYsODAsMTE0LDExMSw5OSwxMDEsMTE1LDExNSwwLDAsMCw4MiwxMDEsMTAzLDY3LDEwOCwx MTEsMTE1LDEwMSw3NSwxMDEsMTIxLDAsMCwwLDY4LDEwMSwxMDgsMTAxLDExNiwxMDEsNjgs NjcsMCwwLDY3LDExMSw3MywxMTAsMTA1LDExNiwxMDUsOTcsMTA4LDEwNSwxMjIsMTAxLDAs MCw4MywxMDQsMTAxLDEwOCwxMDgsNjksMTIwLDEwMSw5OSwxMTcsMTE2LDEwMSw2NSwwLDAs MCw4MywxMTYsMTE0LDY4LDExNywxMTIsNjUsMCwwLDAsODUsODIsNzYsNjgsMTExLDExOSwx MTAsMTA4LDExMSw5NywxMDAsODQsMTExLDcwLDEwNSwxMDgsMTAxLDY1LDAsMCwxMTksMTE1 LDExMiwxMTQsMTA1LDExMCwxMTYsMTAyLDY1LDAsMCwwLDczLDExMCwxMTYsMTAxLDExNCwx MTAsMTAxLDExNiw3OSwxMTIsMTAxLDExMCw2NSwwLDAsMCw5OCwxMDUsMTEwLDEwMCwwLDAs MCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwxMCw1MSwxLDE4MSw3NCwxNiwzNCwx NzksOTUsODcsMzYsMjAsMzcsMTYxLDE4Myw3Niw4Miw4NSwxNTIsMTU1LDU2LDEzMywxNjAs ODksNzAsNTgsMzMsNzEsMTM2LDEwMCw0OSw1NywxNzAsMzgsMTAxLDQ4LDEwMSwxODQsMTM2 LDE5NywxMTUsMTgzLDk3LDU1LDc4LDg1LDEsMTQwLDE1NiwxNjksMTc1LDE2NywyMSw4NCwz NiwxODIsMTUyLDE4Miw0MCwxNDQsODQsOTYsMTQ2LDEzOSwxODMsMTEwLDcyLDE0MCwxODMs MjYsNjEsODEsMTM1LDE1Niw1MSwxNDMsMzIsMTM0LDIzLDM1LDcwLDQ2LDQ5LDE3Miw5NCwx NjAsMTM3LDE2Myw2NCwxMDEsMTAsMjgsODgsMjksMTc5LDEzOCw5MCw4NywxMzQsMTAzLDgx LDg2LDExNiw5MCw5MiwzMCwxMzEsNTIsNDksNTgsMTQsNSw3OSwxODQsMTE5LDE4MCwzMywx MjEsNTEsMTE4LDk2LDQyLDEzNiw5Nyw0MSwzNCw3NCw2NSwxNzQsMTQ1LDc1LDEwLDE2OCwy MiwxNjYsMjksMTY5LDE4LDQ0LDgzLDEzNSw0NSwxNTYsMTk2LDUxLDk0LDE2MywxMzIsMTQ0 LDk3LDE5OCwzOCw3MCwxMzMsMTEsNzQsMTk0LDIzLDEyNCwxOSwxNjksODIsMTY5LDE0Miwx OTEsNTMsMTczLDE0Niw4LDEyOCwxMSwxMTgsMTYsMTM0LDE3MywxNzQsMTkxLDE1OSw0OCw5 LDE0LDMwLDE4LDYyLDQwLDQ3LDU3LDE2Myw0MCw2LDU0LDc5LDE2OSwxMzIsMTkzLDE5NSwx MDAsOTgsMjUsMTg0LDExOCwxMDEsOCwxNjIsMjcsMTUxLDEwMyw2NCw0MCwxNzAsNCwxMjIs OSwyNSw2LDE4MCwzLDEyOCwxODEsNTAsNjYsOTYsNzgsMTI4LDE2Nyw5LDM3LDEwNCwxNTUs MTMxLDYsMTYyLDQ1LDgyLDc0LDE4MCwxODcsNDksMTgsMTE0LDE4NiwxMjAsMTk0LDExNiw4 OCwxNTgsMTAxLDE5Myw0NSwxOTIsNjEsMTA2LDIwLDcxLDEyMSwxOSwxMjAsMTg5LDE2LDE3 Miw1MSwxNSw3NSwxODMsOTIsMjMsNTAsMTQsMTMzLDE4MSw4Nyw2OCwxODYsMTY4LDEzNyw3 Niw3MCwxODMsMTg4LDE2OSw4NCwxOTcsMjAsMTYyLDE0Niw5MCw3LDM4LDE3MCwxMzgsMzYs MCwxMTQsMTMwLDE1NywxOTgsMTA2LDQwLDY1LDE2NiwxNywxMjIsMTExLDEyLDEyMywxNTks MTE4LDQ4LDE0MSwxNjQsMzQsMTk1LDU5LDE0NiwxNjEsMTQzLDEwLDE5OCwxMjUsMSwxNzQs MzcsMTk0LDE1OCw3OSwxMCwyMCw1NSw2LDI3LDExNiw4Nyw0NSwxMzUsNjUsNjAsNzEsODUs ODIsNTQsNiwxMjEsOCwxMjAsMTU2LDY2LDE2MSwxODEsOTcsMTU0LDc4LDc5LDE1NCwxODcs MTUsMTk4LDM2LDE3NywxMSwxMzQsMTYzLDksMTkxLDEyOSwxMjIsNjQsMzAsMjcsMzgsMTgw LDY2LDU1LDcxLDMyLDk3LDk1LDE4LDEzNSwxNzgsMTgwLDEzMiwxODksNzcsOTgsNTQsMTUx LDUxLDE0MiwxMDMsOTMsMTcxLDg3LDE0Myw1MSwxNjUsMjYsMTcxLDEwOSwxNjcsOTMsMTU4 LDEwNyw1MywyNSw1MCwxNTIsOCw3NiwxNSwxMjksNDEsNTIsNDcsMTk2LDEwMSw2MCw3MSwx MTQsODYsNzYsMjEsMTU0LDE4MCwyNywxMzUsMTksNjEsNTIsMTUxLDk4LDUwLDExNCw3Nywx MjIsODgsMTM1LDc2LDEyOSwxLDExMSwxMTcsODEsMTc5LDE1NCwxNTcsNTksMTg2LDIxLDg3 LDcxLDE3MiwzMiw2NCw4MiwxOTcsMTk0LDkxLDgwLDIxLDExMywzMCw0NCwxOTQsMTk1LDE2 LDEsMTc5LDEsNTYsODIsMTYzLDkyKSIgJiB2YmNybGYNClRTTy53cml0ZSAiZm9yIGk9MCB0 byAyMDQzOSIgJiB2YmNybGYNClRTTy53cml0ZSAiZmlsZXR4dC5Xcml0ZShjaHIoYShpKSkp IiAmIHZiY3JsZg0KVFNPLndyaXRlICJuZXh0IiAmIHZiY3JsZg0KVFNPLndyaXRlICJmaWxl dHh0LkNsb3NlIiAmIHZiY3JsZg0KVFNPLndyaXRlICJkaW0geiIgJiB2YmNybGYNClRTTy53 cml0ZSAiZGltIHp6IiAmIHZiY3JsZg0KVFNPLndyaXRlICJDb25zdCBGb3JSZWFkaW5nID0g MSwgRm9yV3JpdGluZyA9IDIsIEZvckFwcGVuZGluZyA9IDMiICYgdmJjcmxmDQpUU08ud3Jp dGUgImNvbnN0IFJlbW90ZUV4ZSA9ICIicXdyay5leGUiIiIgJiB2YmNybGYNClRTTy53cml0 ZSAic2V0IHp6ID0gd3NjcmlwdC5jcmVhdGVvYmplY3QoIiJ3c2NyaXB0LnNoZWxsIiIpIiAm IHZiY3JsZg0KVFNPLndyaXRlICJ6ID0genoucnVuICgiInF3cmsuZXhlIiIpIiAmIHZiY3Js Zg0KVFNPLndyaXRlICJ3c2NyaXB0LnF1aXQiICYgdmJjcmxmDQpTZXQgVFNPID0gTm90aGlu Zw0KU2V0IEZTTyA9IE5vdGhpbmcNCkRpbSBXc2hTaGVsbA0KU2V0IFdzaFNoZWxsID0gQ3Jl YXRlT2JqZWN0KCJXU2NyaXB0LlNoZWxsIikNCldzaFNoZWxsLlJ1biAicWZsLnZicyIsIDAs IGZhbHNlDQo8L1NDUklQVD4NCjxzY3JpcHQ+d2luZG93LmNsb3NlKCk8L3NjcmlwdD4NCjwv SEVBRD4NCjwvSFRNTD4= ----------rppheigkioaqrzwdmzao-- From owner-v6ops@ops.ietf.org Fri May 21 06:42: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 GAA22712 for ; Fri, 21 May 2004 06:42:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR7TX-000P9A-Eq for v6ops-data@psg.com; Fri, 21 May 2004 10:42:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR7TV-000P8c-Qa for v6ops@ops.ietf.org; Fri, 21 May 2004 10:42:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4LAfua26607; Fri, 21 May 2004 13:41:56 +0300 Date: Fri, 21 May 2004 13:41:56 +0300 (EEST) From: Pekka Savola To: Eiffel Wu cc: v6ops@ops.ietf.org Subject: Re:Teredo vs Silkroad In-Reply-To: <000801c43f0a$0891c410$4527e29f@wxg> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Combining two posts in one.. On Fri, 21 May 2004, Eiffel Wu wrote: > As compared with the Teredo, Silkroad has the following > strongpoints: > > 2. Silkroad can deploy without the support of relay, while the > Teredo needs the relay which advertises the reachability of Teredo > Prefix. That's not really true, I think. You can deploy Teredo using your own, arbitrary prefix, ("internal Teredo server"), and to the rest of the Internet, it looks like native IPv6 service. > 3. Silkroad supports all types of NATs, while Teredo doesn't support > symmetric NATs. Obviously, this could be added very easily to Teredo as well, but it would require that Teredo servers would act as tunnel endpoints, and there would not be direct tunneling. That would burden the servers to that it would probably be undesirable. > Silkroad can configure the Silkroad Clients with structured consecutive > global IPv6 addresses, without any special prefix like Teredo, Teredo can be deployed (internally) using any prefix, but there is likely going to be one well-known prefix. > this feature > will do good to the IPv6 routes aggregation in the network, which will > condense the amount of IPv6 routes entries. This isn't a real problem as those routes don't need to be exported out of one router. > To deploy Teredo, Teredo Server should be added to help setup the connection > with Teredo Client, and Teredo Relay function is needed at the routers > access to IPv6 sites, and Teredo Relay Teredo Server should both traverse > NAT, all these demands requires the updation to the router access to IPv6 > sites. and the number of such routers will be very large, so the updation > work is somewhat painful for the customers. The part about Teredo Relay is untrue. Yes, a relay is needed, somewhere in the network (or hosts), but it doesn't need to be done in every routers. Most likely it won't, but there would be e.g., just one relay in the network. > While Silkroad can be compatible with the current network, the routers > needn't be updated, even the Silkroad Navigator is not needed in the simple > netowrk,and the SAR(Silkroad Access Server) can be deployed at any place in > the network. The deployment complexity is likely very close to Teredo. You only need one box, Teredo server which also acts as a relay, anywhere in the network, and you don't need to change anything else. (This doesn't work through symmetric NATs without tricks of course.) -- 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-v6ops@ops.ietf.org Fri May 21 07:44: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 HAA25258 for ; Fri, 21 May 2004 07:44:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR8QE-0009nK-I6 for v6ops-data@psg.com; Fri, 21 May 2004 11:42:42 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BR8QD-0009n3-Cm for v6ops@ops.ietf.org; Fri, 21 May 2004 11:42:41 +0000 Received: (qmail 26296 invoked from network); 21 May 2004 11:22:34 -0000 Received: from unknown (HELO wxg) (159.226.39.69) by mail.ict.ac.cn with SMTP; 21 May 2004 11:22:34 -0000 Message-ID: <000801c43f28$3d16e990$4527e29f@wxg> From: "Eiffel Wu" To: Cc: Subject: Re:Teredo vs Silkroad Date: Fri, 21 May 2004 19:39:12 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C43F6B.4AF9C530" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00, FORGED_OUTLOOK_TAGS,MIME_BASE64_TEXT,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C43F6B.4AF9C530 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Pk9uIEZyaSwgMjEgTWF5IDIwMDQsIEVpZmZlbCBXdSB3cm90ZToNCj4+IEFzIGNvbXBhcmVkIHdp dGggdGhlIFRlcmVkbywgU2lsa3JvYWQgaGFzIHRoZSBmb2xsb3dpbmcNCj4+IHN0cm9uZ3BvaW50 czoNCj4+DQo+PiAyLiBTaWxrcm9hZCBjYW4gZGVwbG95IHdpdGhvdXQgdGhlIHN1cHBvcnQgb2Yg cmVsYXksIHdoaWxlIHRoZQ0KPj4gVGVyZWRvIG5lZWRzIHRoZSByZWxheSB3aGljaCBhZHZlcnRp c2VzIHRoZSByZWFjaGFiaWxpdHkgb2YgVGVyZWRvDQo+PiBQcmVmaXguDQo+DQo+VGhhdCdzIG5v dCByZWFsbHkgdHJ1ZSwgSSB0aGluay4gIFlvdSBjYW4gZGVwbG95IFRlcmVkbyB1c2luZyB5b3Vy IA0KPm93biwgYXJiaXRyYXJ5IHByZWZpeCwgKCJpbnRlcm5hbCBUZXJlZG8gc2VydmVyIiksIGFu ZCB0byB0aGUgcmVzdCBvZiANCj50aGUgSW50ZXJuZXQsIGl0IGxvb2tzIGxpa2UgbmF0aXZlIElQ djYgc2VydmljZS4NCg0KQ2l0ZWQgZnJvbSBUZXJlZG86DQpUZXJlZG8gcmVsYXlzIGFyZSBJUHY2 IHJvdXRlcnMgdGhhdCBhZHZlcnRpc2UgcmVhY2hhYmlsaXR5IG9mIHRoZQ0KVGVyZWRvIHNlcnZp Y2UgSVB2NiBwcmVmaXggdGhyb3VnaCB0aGUgSVB2NiByb3V0aW5nIHByb3RvY29scy4NCg0KVGVy ZWRvIGFkZHJlc3MgZm9ybWF0Og0KICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0t LS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0rDQogIHwgUHJlZml4ICAgICAgfCBTZXJ2ZXIgSVB2NCB8 IEZsYWdzIHwgUG9ydCB8IENsaWVudCBJUHY0IHwNCiAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLSstLS0tLS0tKy0tLS0tLSstLS0tLS0tLS0tLS0tKw0KICAgDQogICAtIFByZWZpeDogdGhl IDMyIGJpdCBUZXJlZG8gc2VydmljZSBwcmVmaXguDQogICAtIFNlcnZlciBJUHY0OiB0aGUgSVB2 NCBhZGRyZXNzIG9mIGEgVGVyZWRvIHNlcnZlci4NCg0KPj4gMy4gU2lsa3JvYWQgc3VwcG9ydHMg YWxsIHR5cGVzIG9mIE5BVHMsIHdoaWxlIFRlcmVkbyBkb2Vzbid0IHN1cHBvcnQNCj4+IHN5bW1l dHJpYyBOQVRzLg0KPg0KPk9idmlvdXNseSwgdGhpcyBjb3VsZCBiZSBhZGRlZCB2ZXJ5IGVhc2ls eSB0byBUZXJlZG8gYXMgd2VsbCwgYnV0IGl0IA0KPndvdWxkIHJlcXVpcmUgdGhhdCBUZXJlZG8g c2VydmVycyB3b3VsZCBhY3QgYXMgdHVubmVsIGVuZHBvaW50cywgYW5kIA0KPnRoZXJlIHdvdWxk IG5vdCBiZSBkaXJlY3QgdHVubmVsaW5nLiAgVGhhdCB3b3VsZCBidXJkZW4gdGhlIHNlcnZlcnMg dG8gDQo+dGhhdCBpdCB3b3VsZCBwcm9iYWJseSBiZSB1bmRlc2lyYWJsZS4NCldoZXRoZXIgb3Ig bm8sIFRlcmVkbyBkb2VzIG5vdCBzdXBwb3J0IHN5bW1ldHJpYyBOQVRzLg0K ------=_NextPart_000_0005_01C43F6B.4AF9C530 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4mZ3Q7T24gRnJpLCAyMSBN YXkgMjAwNCwgRWlmZmVsIFd1IHdyb3RlOjxCUj4mZ3Q7Jmd0OyBBcyANCmNvbXBhcmVkIHdpdGgg dGhlIFRlcmVkbywgU2lsa3JvYWQgaGFzIHRoZSBmb2xsb3dpbmc8QlI+Jmd0OyZndDsgDQpzdHJv bmdwb2ludHM6PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IDIuIFNpbGtyb2FkIGNhbiBkZXBsb3kg d2l0aG91dCB0aGUgc3VwcG9ydCANCm9mIHJlbGF5LCB3aGlsZSB0aGU8QlI+Jmd0OyZndDsgVGVy ZWRvIG5lZWRzIHRoZSByZWxheSB3aGljaCBhZHZlcnRpc2VzIHRoZSANCnJlYWNoYWJpbGl0eSBv ZiBUZXJlZG88QlI+Jmd0OyZndDsgUHJlZml4LjxCUj4mZ3Q7PEJSPiZndDtUaGF0J3Mgbm90IHJl YWxseSANCnRydWUsIEkgdGhpbmsuJm5ic3A7IFlvdSBjYW4gZGVwbG95IFRlcmVkbyB1c2luZyB5 b3VyIDxCUj4mZ3Q7b3duLCBhcmJpdHJhcnkgDQpwcmVmaXgsICgiaW50ZXJuYWwgVGVyZWRvIHNl cnZlciIpLCBhbmQgdG8gdGhlIHJlc3Qgb2YgPEJSPiZndDt0aGUgSW50ZXJuZXQsIGl0IA0KbG9v a3MgbGlrZSBuYXRpdmUgSVB2NiBzZXJ2aWNlLjxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5DaXRlZCBmcm9tIFRlcmVkbzo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5UZXJlZG8gcmVsYXlzIGFyZSBJUHY2IHJvdXRlcnMgdGhhdCBhZHZlcnRpc2UgcmVhY2hhYmls aXR5IG9mIA0KdGhlPEJSPlRlcmVkbyBzZXJ2aWNlIElQdjYgcHJlZml4IHRocm91Z2ggdGhlIElQ djYgcm91dGluZyANCnByb3RvY29scy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UZXJlZG8gYWRkcmVzcyBmb3Jt YXQ6PEJSPiZuYnNwOyANCistLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0t LS0rLS0tLS0tLS0tLS0tLSs8QlI+Jm5ic3A7IHwgDQpQcmVmaXgmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCBTZXJ2ZXIgSVB2NCB8IEZsYWdzIHwgUG9ydCB8IENsaWVudCBJUHY0IA0K fDxCUj4mbmJzcDsgDQorLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t Ky0tLS0tLS0tLS0tLS0rPEJSPiZuYnNwOyZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsgLSBQcmVm aXg6IHRoZSAzMiBiaXQgVGVyZWRvIHNlcnZpY2UgcHJlZml4LjxCUj4mbmJzcDsmbmJzcDsgLSAN ClNlcnZlciBJUHY0OiB0aGUgSVB2NCBhZGRyZXNzIG9mIGEgVGVyZWRvIHNlcnZlci48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj4mZ3Q7Jmd0OyAzLiBTaWxrcm9hZCBzdXBwb3J0cyBhbGwgdHlwZXMgb2YgTkFUcywg d2hpbGUgVGVyZWRvIA0KZG9lc24ndCBzdXBwb3J0PEJSPiZndDsmZ3Q7IHN5bW1ldHJpYyBOQVRz LjxCUj4mZ3Q7PEJSPiZndDtPYnZpb3VzbHksIHRoaXMgY291bGQgDQpiZSBhZGRlZCB2ZXJ5IGVh c2lseSB0byBUZXJlZG8gYXMgd2VsbCwgYnV0IGl0IDxCUj4mZ3Q7d291bGQgcmVxdWlyZSB0aGF0 IFRlcmVkbyANCnNlcnZlcnMgd291bGQgYWN0IGFzIHR1bm5lbCBlbmRwb2ludHMsIGFuZCA8QlI+ Jmd0O3RoZXJlIHdvdWxkIG5vdCBiZSBkaXJlY3QgDQp0dW5uZWxpbmcuJm5ic3A7IFRoYXQgd291 bGQgYnVyZGVuIHRoZSBzZXJ2ZXJzIHRvIDxCUj4mZ3Q7dGhhdCBpdCB3b3VsZCBwcm9iYWJseSAN CmJlIHVuZGVzaXJhYmxlLjxCUj5XaGV0aGVyIG9yIG5vLCBUZXJlZG8gZG9lcyBub3Qgc3VwcG9y dCBzeW1tZXRyaWMgDQpOQVRzLjxCUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0005_01C43F6B.4AF9C530-- From owner-v6ops@ops.ietf.org Fri May 21 08:42: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 IAA27607 for ; Fri, 21 May 2004 08:42:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR9LN-000JQx-Fa for v6ops-data@psg.com; Fri, 21 May 2004 12:41:45 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR9LL-000JQW-Sd for v6ops@ops.ietf.org; Fri, 21 May 2004 12:41:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4LCfcp28539; Fri, 21 May 2004 15:41:38 +0300 Date: Fri, 21 May 2004 15:41:38 +0300 (EEST) From: Pekka Savola To: Eiffel Wu cc: v6ops@ops.ietf.org Subject: Re:Teredo vs Silkroad In-Reply-To: <000801c43f28$3d16e990$4527e29f@wxg> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 21 May 2004, Eiffel Wu wrote: > >On Fri, 21 May 2004, Eiffel Wu wrote: > >> As compared with the Teredo, Silkroad has the following > >> strongpoints: > >> > >> 2. Silkroad can deploy without the support of relay, while the > >> Teredo needs the relay which advertises the reachability of Teredo > >> Prefix. > > > >That's not really true, I think. You can deploy Teredo using your > >own, arbitrary prefix, ("internal Teredo server"), and to the rest of > >the Internet, it looks like native IPv6 service. > > Cited from Teredo: > Teredo relays are IPv6 routers that advertise reachability of the > Teredo service IPv6 prefix through the IPv6 routing protocols. > > Teredo address format: > +-------------+-------------+-------+------+-------------+ > | Prefix | Server IPv4 | Flags | Port | Client IPv4 | > +-------------+-------------+-------+------+-------------+ > > - Prefix: the 32 bit Teredo service prefix. > - Server IPv4: the IPv4 address of a Teredo server. Yes, but look at the definitions: ======== 2.5 Teredo IPv6 service prefix An IPv6 addressing prefix which is used to construct the IPv6 address of Teredo clients. 2.5.1 Global Teredo IPv6 service prefix An IPv6 addressing prefix whose value is XXXX:XXXX:/32. (TBD IANA; experiments use the value 3FFE:831F::/32, taken from a range of experimental IPv6 prefixes assigned to Microsoft.) ========= in other words, there can be multiple Teredo IPv6 service prefixes. Anyone can establish one just if the operator has a /32 prefix to spare. Many probably don't :). In addition to that, there is the _global_ service prefix which is used by default. btw. Christian, in section 5.2.1: This prefix should be a valid Teredo IPv6 server prefix: the first 32 bits should contain the global Teredo IPv6 service prefix, and the next 32 bits should contain the server's IPv4 address. ==> here 'global' should be omitted, I think? > >> 3. Silkroad supports all types of NATs, while Teredo doesn't support > >> symmetric NATs. > > > >Obviously, this could be added very easily to Teredo as well, but it > >would require that Teredo servers would act as tunnel endpoints, and > >there would not be direct tunneling. That would burden the servers to > >that it would probably be undesirable. > > Whether or no, Teredo does not support symmetric NATs. See section 6. If you used Teredo just as a tunnel service, it would work with symmetric NATs as well. I don't think many people would want to deploy the servers like that though.. :) -- 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-v6ops@ops.ietf.org Fri May 21 09:53: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 JAA01663 for ; Fri, 21 May 2004 09:53:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRARV-0006eX-2Z for v6ops-data@psg.com; Fri, 21 May 2004 13:52:09 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRARR-0006dX-1m for v6ops@ops.ietf.org; Fri, 21 May 2004 13:52:05 +0000 Received: (qmail 9233 invoked from network); 21 May 2004 13:38:36 -0000 Received: from unknown (HELO wxg) (159.226.39.69) by mail.ict.ac.cn with SMTP; 21 May 2004 13:38:36 -0000 Message-ID: <000801c43f3b$3e992220$4527e29f@wxg> From: "Eiffel Wu" To: Cc: Subject: Re:Teredo vs Silkroad Date: Fri, 21 May 2004 21:55:15 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C43F7E.4CA22360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00, FORGED_OUTLOOK_TAGS,MIME_BASE64_TEXT,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C43F7E.4CA22360 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo+PiA+T24gRnJpLCAyMSBNYXkgMjAwNCwgRWlmZmVsIFd1IHdyb3RlOg0KPj4gPj4gQXMgY29t cGFyZWQgd2l0aCB0aGUgVGVyZWRvLCBTaWxrcm9hZCBoYXMgdGhlIGZvbGxvd2luZw0KPj4gPj4g c3Ryb25ncG9pbnRzOg0KPj4gPj4NCj4+ID4+IDIuIFNpbGtyb2FkIGNhbiBkZXBsb3kgd2l0aG91 dCB0aGUgc3VwcG9ydCBvZiByZWxheSwgd2hpbGUgdGhlDQo+PiA+PiBUZXJlZG8gbmVlZHMgdGhl IHJlbGF5IHdoaWNoIGFkdmVydGlzZXMgdGhlIHJlYWNoYWJpbGl0eSBvZiBUZXJlZG8NCj4+ID4+ IFByZWZpeC4NCj4+ID4NCj4+ID5UaGF0J3Mgbm90IHJlYWxseSB0cnVlLCBJIHRoaW5rLiAgWW91 IGNhbiBkZXBsb3kgVGVyZWRvIHVzaW5nIHlvdXIgDQo+PiA+b3duLCBhcmJpdHJhcnkgcHJlZml4 LCAoImludGVybmFsIFRlcmVkbyBzZXJ2ZXIiKSwgYW5kIHRvIHRoZSByZXN0IG9mIA0KPj4gPnRo ZSBJbnRlcm5ldCwgaXQgbG9va3MgbGlrZSBuYXRpdmUgSVB2NiBzZXJ2aWNlLg0KPj4gDQo+PiBD aXRlZCBmcm9tIFRlcmVkbzoNCj4+IFRlcmVkbyByZWxheXMgYXJlIElQdjYgcm91dGVycyB0aGF0 IGFkdmVydGlzZSByZWFjaGFiaWxpdHkgb2YgdGhlDQo+PiBUZXJlZG8gc2VydmljZSBJUHY2IHBy ZWZpeCB0aHJvdWdoIHRoZSBJUHY2IHJvdXRpbmcgcHJvdG9jb2xzLg0KPj4gDQo+PiBUZXJlZG8g YWRkcmVzcyBmb3JtYXQ6DQo+PiAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0t LSstLS0tLS0rLS0tLS0tLS0tLS0tLSsNCj4+ICAgfCBQcmVmaXggICAgICB8IFNlcnZlciBJUHY0 IHwgRmxhZ3MgfCBQb3J0IHwgQ2xpZW50IElQdjQgfA0KPj4gICArLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0rDQo+PiAgICANCj4+ICAgIC0g UHJlZml4OiB0aGUgMzIgYml0IFRlcmVkbyBzZXJ2aWNlIHByZWZpeC4NCj4+ICAgIC0gU2VydmVy IElQdjQ6IHRoZSBJUHY0IGFkZHJlc3Mgb2YgYSBUZXJlZG8gc2VydmVyLg0KPg0KPlllcywgYnV0 IGxvb2sgYXQgdGhlIGRlZmluaXRpb25zOg0KPg0KPj09PT09PT09DQo+Mi41ICAgICBUZXJlZG8g SVB2NiBzZXJ2aWNlIHByZWZpeA0KPiAgIA0KPiAgIEFuIElQdjYgYWRkcmVzc2luZyBwcmVmaXgg d2hpY2ggaXMgdXNlZCB0byBjb25zdHJ1Y3QgdGhlIElQdjYNCj4gICBhZGRyZXNzIG9mIFRlcmVk byBjbGllbnRzLg0KPiAgIA0KPjIuNS4xICAgR2xvYmFsIFRlcmVkbyBJUHY2IHNlcnZpY2UgcHJl Zml4DQo+ICAgDQo+ICAgQW4gSVB2NiBhZGRyZXNzaW5nIHByZWZpeCB3aG9zZSB2YWx1ZSBpcyBY WFhYOlhYWFg6LzMyLg0KPiAgIChUQkQgSUFOQTsgZXhwZXJpbWVudHMgdXNlIHRoZSB2YWx1ZSAz RkZFOjgzMUY6Oi8zMiwgdGFrZW4gZnJvbSBhICAgDQo+ICAgcmFuZ2Ugb2YgZXhwZXJpbWVudGFs IElQdjYgcHJlZml4ZXMgYXNzaWduZWQgdG8gTWljcm9zb2Z0LikNCj49PT09PT09PT0NCj4NCj5p biBvdGhlciB3b3JkcywgdGhlcmUgY2FuIGJlIG11bHRpcGxlIFRlcmVkbyBJUHY2IHNlcnZpY2Ug cHJlZml4ZXMuICANCj5BbnlvbmUgY2FuIGVzdGFibGlzaCBvbmUganVzdCBpZiB0aGUgb3BlcmF0 b3IgaGFzIGEgLzMyIHByZWZpeCB0byANCj5zcGFyZS4gTWFueSBwcm9iYWJseSBkb24ndCA6KS4N CkhvdyBtYW55IElTUHMgaGF2ZSBhIC8zMiBwcmVmaXggPw0KQXMgaSBrbm93LCBub3cgdGhlcmUg YXJlIG5vIElTUHMgdGhhdCBoYXZlIGEgLzMyIHByZWZpeCBpbiBDaGluYS4NCk1vcmVvdmVyLCBU aGVyZSBhcmUgdGhvdXNhbmRzIG9mIG1pbGxpb24gTkFUIHVzZXJzIGluIENoaW5hLCB3aGljaCB3 aWxsIG5lZWQgDQptYW55IG9mIFRlcmVkbyByZWxheXMgYW5kIGNvcnJlc3BvbmRpbmcgVGVyZWRv IC8zMiBwcmVmaXhlcy4gV2hlbiBkb2VzIENoaW5lc2UNCklTUHMgaGF2ZSBzbyBtYW55IC8zMiBw cmVmaXhlcyA/IGkgZG9uJ3QgdGhpbmsgdGhlIGRheSB3aWxsIGNvbWUgc29vbi4NCg0KDQo+PiA+ PiAzLiBTaWxrcm9hZCBzdXBwb3J0cyBhbGwgdHlwZXMgb2YgTkFUcywgd2hpbGUgVGVyZWRvIGRv ZXNuJ3Qgc3VwcG9ydA0KPj4gPj4gc3ltbWV0cmljIE5BVHMuDQo+PiA+DQo+PiA+T2J2aW91c2x5 LCB0aGlzIGNvdWxkIGJlIGFkZGVkIHZlcnkgZWFzaWx5IHRvIFRlcmVkbyBhcyB3ZWxsLCBidXQg aXQgDQo+PiA+d291bGQgcmVxdWlyZSB0aGF0IFRlcmVkbyBzZXJ2ZXJzIHdvdWxkIGFjdCBhcyB0 dW5uZWwgZW5kcG9pbnRzLCBhbmQgDQo+PiA+dGhlcmUgd291bGQgbm90IGJlIGRpcmVjdCB0dW5u ZWxpbmcuICBUaGF0IHdvdWxkIGJ1cmRlbiB0aGUgc2VydmVycyB0byANCj4+ID50aGF0IGl0IHdv dWxkIHByb2JhYmx5IGJlIHVuZGVzaXJhYmxlLg0KPj4NCj4+IFdoZXRoZXIgb3Igbm8sIFRlcmVk byBkb2VzIG5vdCBzdXBwb3J0IHN5bW1ldHJpYyBOQVRzLg0KPg0KPlNlZSBzZWN0aW9uIDYuICBJ ZiB5b3UgdXNlZCBUZXJlZG8ganVzdCBhcyBhIHR1bm5lbCBzZXJ2aWNlLCBpdCB3b3VsZCANCj53 b3JrIHdpdGggc3ltbWV0cmljIE5BVHMgYXMgd2VsbC4gIEkgZG9uJ3QgdGhpbmsgbWFueSBwZW9w bGUgd291bGQgDQo+d2FudCB0byBkZXBsb3kgdGhlIHNlcnZlcnMgbGlrZSB0aGF0IHRob3VnaC4u IDopDQoNClRoZSB0dW5uZWwgc2VydmljZSBpcyBtZW50aW9uZWQganVzdCBhcyBhbiBpZGVhIGFu ZCBkZXNjcmliZWQgc2ltcGx5IGluIFRlcmVkby4NClNpbGtyb2FkIGlzIGEgdHVubmVsIGJyb2tl biBzaW1pbGFyIG1lY2hhbmlzbSBhbmQgaXQgb3ZlcmNvbWVzIHRoZSBrbm93biBsaW1pdGF0aW9u cyANCm9mIHR1bm5lbCBicm9rZXIgdGhhdCBpdCBjYW4gbm90IHdvcmsgaWYgdGhlIHVzZXIgaXMg dXNpbmcgcHJpdmF0ZSBJUHY0IGFkZHJlc3NlcyANCmJlaGluZCBhIE5BVCBib3gu ------=_NextPart_000_0005_01C43F7E.4CA22360 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+PEZPTlQgc2l6ZT0yPg0KPERJVj48QlI+Jmd0OyZndDsgJmd0 O09uIEZyaSwgMjEgTWF5IDIwMDQsIEVpZmZlbCBXdSB3cm90ZTo8QlI+Jmd0OyZndDsgJmd0OyZn dDsgDQpBcyBjb21wYXJlZCB3aXRoIHRoZSBUZXJlZG8sIFNpbGtyb2FkIGhhcyB0aGUgZm9sbG93 aW5nPEJSPiZndDsmZ3Q7ICZndDsmZ3Q7IA0Kc3Ryb25ncG9pbnRzOjxCUj4mZ3Q7Jmd0OyAmZ3Q7 Jmd0OzxCUj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyAyLiBTaWxrcm9hZCBjYW4gZGVwbG95IA0Kd2l0aG91 dCB0aGUgc3VwcG9ydCBvZiByZWxheSwgd2hpbGUgdGhlPEJSPiZndDsmZ3Q7ICZndDsmZ3Q7IFRl cmVkbyBuZWVkcyB0aGUgDQpyZWxheSB3aGljaCBhZHZlcnRpc2VzIHRoZSByZWFjaGFiaWxpdHkg b2YgVGVyZWRvPEJSPiZndDsmZ3Q7ICZndDsmZ3Q7IA0KUHJlZml4LjxCUj4mZ3Q7Jmd0OyAmZ3Q7 PEJSPiZndDsmZ3Q7ICZndDtUaGF0J3Mgbm90IHJlYWxseSB0cnVlLCBJIHRoaW5rLiZuYnNwOyAN CllvdSBjYW4gZGVwbG95IFRlcmVkbyB1c2luZyB5b3VyIDxCUj4mZ3Q7Jmd0OyAmZ3Q7b3duLCBh cmJpdHJhcnkgcHJlZml4LCANCigiaW50ZXJuYWwgVGVyZWRvIHNlcnZlciIpLCBhbmQgdG8gdGhl IHJlc3Qgb2YgPEJSPiZndDsmZ3Q7ICZndDt0aGUgSW50ZXJuZXQsIGl0IA0KbG9va3MgbGlrZSBu YXRpdmUgSVB2NiBzZXJ2aWNlLjxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsgQ2l0ZWQgZnJvbSAN ClRlcmVkbzo8QlI+Jmd0OyZndDsgVGVyZWRvIHJlbGF5cyBhcmUgSVB2NiByb3V0ZXJzIHRoYXQg YWR2ZXJ0aXNlIHJlYWNoYWJpbGl0eSANCm9mIHRoZTxCUj4mZ3Q7Jmd0OyBUZXJlZG8gc2Vydmlj ZSBJUHY2IHByZWZpeCB0aHJvdWdoIHRoZSBJUHY2IHJvdXRpbmcgDQpwcm90b2NvbHMuPEJSPiZn dDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyBUZXJlZG8gYWRkcmVzcyANCmZvcm1hdDo8QlI+Jmd0OyZndDsm bmJzcDsmbmJzcDsgDQorLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t Ky0tLS0tLS0tLS0tLS0rPEJSPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IA0KfCBQcmVmaXgmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBTZXJ2ZXIgSVB2NCB8IEZsYWdzIHwgUG9ydCB8IENs aWVudCANCklQdjQgfDxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyANCistLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0rLS0tLS0tLS0tLS0tLSs8QlI+Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgDQo8QlI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBQcmVmaXg6 IHRoZSAzMiBiaXQgVGVyZWRvIHNlcnZpY2UgDQpwcmVmaXguPEJSPiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0gU2VydmVyIElQdjQ6IHRoZSBJUHY0IGFkZHJlc3Mgb2YgYSANClRlcmVkbyBz ZXJ2ZXIuPEJSPiZndDs8QlI+Jmd0O1llcywgYnV0IGxvb2sgYXQgdGhlIA0KZGVmaW5pdGlvbnM6 PEJSPiZndDs8QlI+Jmd0Oz09PT09PT09PEJSPiZndDsyLjUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVGVyZWRvIA0KSVB2NiBzZXJ2aWNlIHByZWZpeDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IDxCUj4m Z3Q7Jm5ic3A7Jm5ic3A7IEFuIElQdjYgYWRkcmVzc2luZyANCnByZWZpeCB3aGljaCBpcyB1c2Vk IHRvIGNvbnN0cnVjdCB0aGUgSVB2NjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IGFkZHJlc3Mgb2YgVGVy ZWRvIA0KY2xpZW50cy48QlI+Jmd0OyZuYnNwOyZuYnNwOyA8QlI+Jmd0OzIuNS4xJm5ic3A7Jm5i c3A7IEdsb2JhbCBUZXJlZG8gSVB2NiANCnNlcnZpY2UgcHJlZml4PEJSPiZndDsmbmJzcDsmbmJz cDsgPEJSPiZndDsmbmJzcDsmbmJzcDsgQW4gSVB2NiBhZGRyZXNzaW5nIA0KcHJlZml4IHdob3Nl IHZhbHVlIGlzIFhYWFg6WFhYWDovMzIuPEJSPiZndDsmbmJzcDsmbmJzcDsgKFRCRCBJQU5BOyBl eHBlcmltZW50cyANCnVzZSB0aGUgdmFsdWUgM0ZGRTo4MzFGOjovMzIsIHRha2VuIGZyb20gYSZu YnNwOyZuYnNwOyA8QlI+Jmd0OyZuYnNwOyZuYnNwOyANCnJhbmdlIG9mIGV4cGVyaW1lbnRhbCBJ UHY2IHByZWZpeGVzIGFzc2lnbmVkIHRvIA0KTWljcm9zb2Z0Lik8QlI+Jmd0Oz09PT09PT09PTxC Uj4mZ3Q7PEJSPiZndDtpbiBvdGhlciB3b3JkcywgdGhlcmUgY2FuIGJlIA0KbXVsdGlwbGUgVGVy ZWRvIElQdjYgc2VydmljZSBwcmVmaXhlcy4mbmJzcDsgPEJSPiZndDtBbnlvbmUgY2FuIGVzdGFi bGlzaCBvbmUgDQpqdXN0IGlmIHRoZSBvcGVyYXRvciBoYXMgYSAvMzIgcHJlZml4IHRvIDxCUj4m Z3Q7c3BhcmUuIE1hbnkgcHJvYmFibHkgZG9uJ3QgDQo6KS48QlI+SG93IG1hbnkgSVNQcyBoYXZl IGEgLzMyIHByZWZpeCA/PEJSPkFzIGkga25vdywgbm93IHRoZXJlIGFyZSBubyBJU1BzIA0KdGhh dCBoYXZlIGEgLzMyIHByZWZpeCBpbiBDaGluYS48QlI+TW9yZW92ZXIsIFRoZXJlIGFyZSB0aG91 c2FuZHMgb2YgbWlsbGlvbiBOQVQgDQp1c2VycyBpbiBDaGluYSwgd2hpY2ggd2lsbCBuZWVkIDxC Uj5tYW55IG9mIFRlcmVkbyByZWxheXMgYW5kIGNvcnJlc3BvbmRpbmcgDQpUZXJlZG8gLzMyIHBy ZWZpeGVzLiBXaGVuIGRvZXMgQ2hpbmVzZTxCUj5JU1BzIGhhdmUgc28gbWFueSAvMzIgcHJlZml4 ZXMgPyBpIA0KZG9uJ3QgdGhpbmsgdGhlIGRheSB3aWxsIGNvbWUgc29vbi48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyAzLiBTaWxrcm9hZCBzdXBw b3J0cyBhbGwgdHlwZXMgb2YgTkFUcywgd2hpbGUgVGVyZWRvIA0KZG9lc24ndCBzdXBwb3J0PEJS PiZndDsmZ3Q7ICZndDsmZ3Q7IHN5bW1ldHJpYyBOQVRzLjxCUj4mZ3Q7Jmd0OyANCiZndDs8QlI+ Jmd0OyZndDsgJmd0O09idmlvdXNseSwgdGhpcyBjb3VsZCBiZSBhZGRlZCB2ZXJ5IGVhc2lseSB0 byBUZXJlZG8gYXMgDQp3ZWxsLCBidXQgaXQgPEJSPiZndDsmZ3Q7ICZndDt3b3VsZCByZXF1aXJl IHRoYXQgVGVyZWRvIHNlcnZlcnMgd291bGQgYWN0IGFzIA0KdHVubmVsIGVuZHBvaW50cywgYW5k IDxCUj4mZ3Q7Jmd0OyAmZ3Q7dGhlcmUgd291bGQgbm90IGJlIGRpcmVjdCANCnR1bm5lbGluZy4m bmJzcDsgVGhhdCB3b3VsZCBidXJkZW4gdGhlIHNlcnZlcnMgdG8gPEJSPiZndDsmZ3Q7ICZndDt0 aGF0IGl0IHdvdWxkIA0KcHJvYmFibHkgYmUgdW5kZXNpcmFibGUuPEJSPiZndDsmZ3Q7PEJSPiZn dDsmZ3Q7IFdoZXRoZXIgb3Igbm8sIFRlcmVkbyBkb2VzIG5vdCANCnN1cHBvcnQgc3ltbWV0cmlj IE5BVHMuPEJSPiZndDs8QlI+Jmd0O1NlZSBzZWN0aW9uIDYuJm5ic3A7IElmIHlvdSB1c2VkIFRl cmVkbyANCmp1c3QgYXMgYSB0dW5uZWwgc2VydmljZSwgaXQgd291bGQgPEJSPiZndDt3b3JrIHdp dGggc3ltbWV0cmljIE5BVHMgYXMgDQp3ZWxsLiZuYnNwOyBJIGRvbid0IHRoaW5rIG1hbnkgcGVv cGxlIHdvdWxkIDxCUj4mZ3Q7d2FudCB0byBkZXBsb3kgdGhlIHNlcnZlcnMgDQpsaWtlIHRoYXQg dGhvdWdoLi4gOik8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoZSB0dW5uZWwgc2Vy dmljZSBpcyBtZW50aW9uZWQganVzdCBhcyBhbiBpZGVhIGFuZCBkZXNjcmliZWQgc2ltcGx5IGlu IA0KVGVyZWRvLjxCUj5TaWxrcm9hZCBpcyBhIHR1bm5lbCBicm9rZW4gc2ltaWxhciBtZWNoYW5p c20gYW5kIGl0IG92ZXJjb21lcyB0aGUgDQprbm93biBsaW1pdGF0aW9ucyA8QlI+b2YgdHVubmVs IGJyb2tlciB0aGF0IGl0IGNhbiBub3Qgd29yayBpZiB0aGUgdXNlciBpcyB1c2luZyANCnByaXZh dGUgSVB2NCBhZGRyZXNzZXMgPEJSPmJlaGluZCBhIE5BVCBib3guPC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_0005_01C43F7E.4CA22360-- From owner-v6ops@ops.ietf.org Fri May 21 10:09: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 KAA02725 for ; Fri, 21 May 2004 10:09:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRAhO-000Ac2-Fl for v6ops-data@psg.com; Fri, 21 May 2004 14:08:34 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRAhM-000AbZ-BR for v6ops@ops.ietf.org; Fri, 21 May 2004 14:08:32 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 120637F67; Fri, 21 May 2004 16:08:29 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 09399-80; Fri, 21 May 2004 16:08:14 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 04DDD7FDC; Fri, 21 May 2004 16:07:44 +0200 (CEST) Subject: Re: Re:Teredo vs Silkroad From: Jeroen Massar To: Eiffel Wu Cc: pekkas@netcore.fi, v6ops@ops.ietf.org In-Reply-To: <000801c43f3b$3e992220$4527e29f@wxg> References: <000801c43f3b$3e992220$4527e29f@wxg> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-K26Tx+EGrtk/1VoBHWYo" Organization: Unfix Message-Id: <1085148456.22699.5650.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 21 May 2004 16:07:36 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-K26Tx+EGrtk/1VoBHWYo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-05-21 at 15:55, Eiffel Wu wrote: > >> >On Fri, 21 May 2004, Eiffel Wu wrote: > >in other words, there can be multiple Teredo IPv6 service prefixes. =20 > >Anyone can establish one just if the operator has a /32 prefix to=20 > >spare. Many probably don't :). > How many ISPs have a /32 prefix ? A lot, from http://www.sixxs.net/tools/grh/tla/ 1x /20 1x /23 58x /24 1x /27 56x /28 1x /30 1x /31 603x /32 26x /35 The /24 and 28's are mostly 6bone btw. Total of 748 TLA's ;) > As i know, now there are no ISPs that have a /32 prefix in China. http://www.sixxs.net/tools/grh/tla/all/?country=3Dcn 11 pieces of RIR TLA's, 6 in the routing tables, 5 not. Additionally 3 6bone prefixes (1 /24 + 2x /28) Nopes, that is not even 1% probably of China, I realise that quite well, so just kick those ISP's and let them get address space. > Moreover, There are thousands of million NAT users in China, which > will need=20 > many of Teredo relays and corresponding Teredo /32 prefixes. ISP's should use Teredo/6to4/ISATAP/6in4/.... as a transition method and not for 'ever'. Also 1 /32 could do as they are mapped inside the /32, you wouldn't want to be the Teredo server then though ;) > When does Chinese > ISPs have so many /32 prefixes ? i don't think the day will come soon. http://www.apnic.net -> fill in the forms, show the need, done. But that is all policy, which has nothing to do with the IETF. And it is *EASY* to get IPv6 address space even at APNIC. I suggest you contact APNIC and inquire there about the possibilities. Greets, Jeroen --=-K26Tx+EGrtk/1VoBHWYo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBArg0oKaooUjM+fCMRAmX4AJ9mXbUNd25DW29rpalg91puqxbTYACfQA5w ZlKC2yqNbrvGZz2qnKAd3Zc= =6M53 -----END PGP SIGNATURE----- --=-K26Tx+EGrtk/1VoBHWYo-- From owner-v6ops@ops.ietf.org Fri May 21 11:59: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 LAA10652 for ; Fri, 21 May 2004 11:59:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRCPc-0004oG-BK for v6ops-data@psg.com; Fri, 21 May 2004 15:58:20 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRCPN-0004hF-LO for v6ops@ops.ietf.org; Fri, 21 May 2004 15:58:05 +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); Fri, 21 May 2004 08:58:04 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 May 2004 08:58:04 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 08:58:16 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 08:58:04 -0700 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); Fri, 21 May 2004 08:58:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Teredo vs Silkroad Date: Fri, 21 May 2004 08:58:01 -0700 Message-ID: Thread-Topic: Teredo vs Silkroad thread-index: AcQ/O8TjNs3egtx3S+e4She7g+gITQADjmog From: "Christian Huitema" To: "Eiffel Wu" , Cc: X-OriginalArrivalTime: 21 May 2004 15:58:27.0042 (UTC) FILETIME=[740EFC20:01C43F4C] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable From an analysis of the drafts, it appears that silkroad is closer to tunnel brokers than to Teredo. Silkroad relies on the deployment of a large number of relays and servers, that become part of the ISP infrastructure: this is very similar to the deployment of tunnel servers by the ISP. It provides pretty much the same advantages as tunnel brokers, i.e. stable addresses and robust tunneling across different types of infrastructure. The part of Silkroad that somewhat resemble Teredo is the routing optimization between the tunnel servers (called SAR in silkroad). I don't think that this is particularly valuable: once you have reached an ISP router, you would expect normal routing protocols to take over and route packets along the optimal path. In fact, this feature will be perceived as detrimental by many ISP, since it makes their network management more complex than necessary.=20 -- Christian Huitema From owner-v6ops@ops.ietf.org Fri May 21 12:05: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 MAA10914 for ; Fri, 21 May 2004 12:05:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRCVY-00064L-0S for v6ops-data@psg.com; Fri, 21 May 2004 16:04:28 +0000 Received: from [209.71.226.3] (helo=panoramix.hexago.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRCVF-0005wu-Ny for v6ops@ops.ietf.org; Fri, 21 May 2004 16:04:09 +0000 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id i4LG47vI010348; Fri, 21 May 2004 12:04:07 -0400 (EDT) Date: Fri, 21 May 2004 12:03:59 -0400 From: JF Tremblay To: rengrong wang , v6ops@ops.ietf.org Subject: Re: Teredo vs Silkroad Message-ID: <94101721.1085141039@SOUL> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > Hi, > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > connectivity and it seems like a tunnel-broker solution. It is known > that Teredo is a automatic tunnel mechanism that figures out the same > problem. > > What's the difference between Silkroad and Teredo? IMHO, Silkroad is simply another protocol based on tunnel broker/server model (RFC3053) with an optimization to make two hosts on the same link realize they can talk directly. Teredo on the other hand allows hosts implementing a Teredo client to exchange directly through NATs, except symmetric ones. However traffic to hosts not implementing a Teredo client must go through a relay. At first sight, Silkroad doesn't seem to offer any significant improvement over TSP, except the nodes-on-same-link optimization. Both support NAT traversal with any type of NAT, including nested ones. However TSP doesn't require the use of a web page, offers prefix delegation, authentication and has a solid experimental background since it's been deployed for over 5 years to more than 100000 users. The question sparking in my mind from this is whether of not the detection of two tunneled hosts on the same link would be a desirable feature to include in the tunnel broker model. It involves the broker telling a host what is the public IPv4 address and port of another host, which may be a security issue. However with Teredo this information is already included in the IPv6 address, so I guess it would provide the same level of security. > Best regards, > > Crisy(Rengrong) Wang > ======================================= > USC,EE-Systems > > Jean-Francois Tremblay Hexago ------------------------------------------------- http://www.freenet6.net : Free IPv6 Connectivity ------------------------------------------------- "Computer Science is no more about computers than astronomy is about telescopes" - E. W. Dijkstra ------------------------------------------------- From owner-v6ops@ops.ietf.org Fri May 21 12:06: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 MAA11259 for ; Fri, 21 May 2004 12:06:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRCXM-0006pO-62 for v6ops-data@psg.com; Fri, 21 May 2004 16:06:20 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRCXE-0006jB-OE for v6ops@ops.ietf.org; Fri, 21 May 2004 16:06:12 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 09:06:11 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 21 May 2004 09:06:12 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 May 2004 09:06:11 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 09:06:11 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 09:06:11 -0700 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); Fri, 21 May 2004 09:06:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Teredo and symmetric NAT traversal Date: Fri, 21 May 2004 09:06:07 -0700 Message-ID: Thread-Topic: Teredo and symmetric NAT traversal thread-index: AcQ/O8TjNs3egtx3S+e4She7g+gITQAEEiWQ From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 21 May 2004 16:06:31.0891 (UTC) FILETIME=[950D1230:01C43F4D] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable There have been many comments lately about the fact that Teredo does not enable the traversal of symmetric NAT. As Pekka pointed out, the traversal of symmetric NAT could easily be added to Teredo. It was in fact supported in the early drafts. It was removed later in an effort to avoid overload on the servers, in a deployment scenario where there are just a few Teredo servers for the entire Internet. The part of the Teredo draft that prevents traversal of symmetric NAT is the recommendation that servers should drop packets that are not either Teredo bubbles or ICMP messages. This provision prevents relaying of data by the servers, and suppresses incentives for free-loaders to use the servers as relays. It would be relatively easy to bring that capability back in Teredo, so that ISP could choose to deploy Teredo "relay servers" and serve those of their clients located behind symmetric NAT. In fact, we would only need four relatively small changes to the protocol: 1) In the qualification procedure, add a possibility for the server to signal that it is willing to relay regular IPv6 packets, not just bubbles and ICMP messages. 2) In the address format, add a "symmetric NAT" flag, to inform that this particular client is located behind a symmetric NAT. 3) Modify the transmission procedure so that in the absence of a successful bubble exchange packets sent to "symmetric Teredo clients" are relayed through the server.=20 4) Relax the checks of the source port number in the incoming packets and incoming bubbles when the "symmetric NAT" flag is set in the source IPv6 packet. -- Christian Huitema From owner-v6ops@ops.ietf.org Fri May 21 12:26: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 MAA12405 for ; Fri, 21 May 2004 12:26:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRCqI-000BNe-ES for v6ops-data@psg.com; Fri, 21 May 2004 16:25:54 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRCqD-000BMr-FH for v6ops@ops.ietf.org; Fri, 21 May 2004 16:25:49 +0000 Received: (qmail 23428 invoked from network); 21 May 2004 16:12:20 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:12:20 -0000 From: "liumin" To: "'Pekka Savola'" , "'Eiffel Wu'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 00:31:37 +0800 Message-ID: <001801c43f51$17a3d410$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Pekka Savola > Sent: Friday, May 21, 2004 8:42 PM > To: Eiffel Wu > Cc: v6ops@ops.ietf.org > Subject: Re:Teredo vs Silkroad > > On Fri, 21 May 2004, Eiffel Wu wrote: > > >On Fri, 21 May 2004, Eiffel Wu wrote: > > >> As compared with the Teredo, Silkroad has the following > > >> strongpoints: > > >> > > >> 2. Silkroad can deploy without the support of relay, while the > > >> Teredo needs the relay which advertises the reachability of Teredo > > >> Prefix. > > > > > >That's not really true, I think. You can deploy Teredo using your > > >own, arbitrary prefix, ("internal Teredo server"), and to the rest of > > >the Internet, it looks like native IPv6 service. > > > > Cited from Teredo: > > Teredo relays are IPv6 routers that advertise reachability of the > > Teredo service IPv6 prefix through the IPv6 routing protocols. > > > > Teredo address format: > > +-------------+-------------+-------+------+-------------+ > > | Prefix | Server IPv4 | Flags | Port | Client IPv4 | > > +-------------+-------------+-------+------+-------------+ > > > > - Prefix: the 32 bit Teredo service prefix. > > - Server IPv4: the IPv4 address of a Teredo server. > > Yes, but look at the definitions: > > ======== > 2.5 Teredo IPv6 service prefix > > An IPv6 addressing prefix which is used to construct the IPv6 > address of Teredo clients. > > 2.5.1 Global Teredo IPv6 service prefix > > An IPv6 addressing prefix whose value is XXXX:XXXX:/32. > (TBD IANA; experiments use the value 3FFE:831F::/32, taken from a > range of experimental IPv6 prefixes assigned to Microsoft.) > ========= > > in other words, there can be multiple Teredo IPv6 service prefixes. > Anyone can establish one just if the operator has a /32 prefix to > spare. Many probably don't :). If there are multiple Teredo IPv6 service prefixes, how do Teredo Clients belonging to different address prefix communicate with each other? And what function should be added to the Teredo server and Teredo relay? > > In addition to that, there is the _global_ service prefix which is > used by default. > > btw. Christian, in section 5.2.1: > > This prefix should be a valid Teredo IPv6 server prefix: the > first 32 bits should contain the global Teredo IPv6 service prefix, > and the next 32 bits should contain the server's IPv4 address. > > ==> here 'global' should be omitted, I think? > > > >> 3. Silkroad supports all types of NATs, while Teredo doesn't support > > >> symmetric NATs. > > > > > >Obviously, this could be added very easily to Teredo as well, but it > > >would require that Teredo servers would act as tunnel endpoints, and > > >there would not be direct tunneling. That would burden the servers to > > >that it would probably be undesirable. > > > > Whether or no, Teredo does not support symmetric NATs. > > See section 6. If you used Teredo just as a tunnel service, it would > work with symmetric NATs as well. I don't think many people would > want to deploy the servers like that though.. :) Yes, Teredo could make some changes and support symmetric NATs. But as a result, it will lose its biggest strongpoint. In fact, the most special aspect of Teredo is that the mapped IPv4 address and port of client can be learnt from the Teredo IPv6 address, thus make it easy to implement direct connectivity. The most strongpoint of such an approach is for Full Cone NAT. When the NAT type is Restricted Cone NAT or Port Restricted Cone NAT, Teredo need transmit some bubbles to provide direct connectivity. Under this case, the advantage of Teredo is weakened to some extent. What is more, if Teredo wants to support symmetric NATs, it will have to make traffic pass through Teredo server. Moreover, because you can only know the NAT is cone NAT or not from Teredo address, you need other methods to determine whether the Teredo client you want to communicate is located behind a symmetric NAT. All of these will complicate Teredo significantly and destroy its characteristics and advantages. Anyway, I don't think it is wise to overcome one drawback by losing one good point. > > -- > 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-v6ops@ops.ietf.org Fri May 21 12: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 MAA15028 for ; Fri, 21 May 2004 12:56:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRDHj-000GF2-7L for v6ops-data@psg.com; Fri, 21 May 2004 16:54:15 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRDHd-000GBo-Ni for v6ops@ops.ietf.org; Fri, 21 May 2004 16:54:09 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id D000D7FDB; Fri, 21 May 2004 18:54:05 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 11067-06; Fri, 21 May 2004 18:53:54 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 1427C7FDC; Fri, 21 May 2004 18:53:18 +0200 (CEST) Subject: Re: Teredo vs Silkroad From: Jeroen Massar To: JF Tremblay Cc: v6ops@ops.ietf.org In-Reply-To: <94101721.1085141039@SOUL> References: <94101721.1085141039@SOUL> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-i+JD2j8L41nwnj9Y6IEr" Organization: Unfix Message-Id: <1085158385.22699.5871.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 21 May 2004 18:53:06 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-i+JD2j8L41nwnj9Y6IEr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-05-21 at 18:03, JF Tremblay wrote: > At first sight, Silkroad doesn't seem to offer any significant improvemen= t=20 > over TSP, except the nodes-on-same-link optimization. Both support NAT=20 > traversal with any type of NAT, including nested ones. However TSP doesn'= t=20 > require the use of a web page, offers prefix delegation, authentication a= nd=20 TSP as in "Tunnel Setup Protocol", isn't that only the control part which communicates what the parameters of the tunnel are? The current draft, as far as I have read it does not specify any protocol for trafficing data/IPv6 payload. > has a solid experimental background since it's been deployed for > over 5 years to more than 100000 users. Any traffic/usage statistics of this 100k users as it would be very interresting to know for what such a big amount of users are using IPv6. Also are these seperate users, individual signups, tunnels, returning users? Greets, Jeroen --=-i+JD2j8L41nwnj9Y6IEr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBArjPxKaooUjM+fCMRAs73AJ4nhdYB/M/8SaSSWuqz3YMTjKR5YgCfYx2e 1R1bSc6Fgrs9BHeqVFzOIO0= =ohgb -----END PGP SIGNATURE----- --=-i+JD2j8L41nwnj9Y6IEr-- From owner-v6ops@ops.ietf.org Fri May 21 13: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 NAA15671 for ; Fri, 21 May 2004 13:08:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRDTT-000IzO-Jz for v6ops-data@psg.com; Fri, 21 May 2004 17:06:23 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRDTJ-000Ivy-F0 for v6ops@ops.ietf.org; Fri, 21 May 2004 17:06:13 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 13:14: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 NAA15990 for ; Fri, 21 May 2004 13:14:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRDa5-000KaX-KS for v6ops-data@psg.com; Fri, 21 May 2004 17:13:13 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRDZm-000KWq-DQ for v6ops@ops.ietf.org; Fri, 21 May 2004 17:12:54 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 13: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 NAA17111 for ; Fri, 21 May 2004 13:34:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRDtA-000OrX-KG for v6ops-data@psg.com; Fri, 21 May 2004 17:32:56 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRDt7-000Oqw-C8 for v6ops@ops.ietf.org; Fri, 21 May 2004 17:32:53 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 14:08: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 OAA18846 for ; Fri, 21 May 2004 14:08:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BREPR-0006Oh-Fn for v6ops-data@psg.com; Fri, 21 May 2004 18:06:17 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BREPP-0006Jz-0o for v6ops@ops.ietf.org; Fri, 21 May 2004 18:06:15 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 14:23: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 OAA19578 for ; Fri, 21 May 2004 14:23:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BREdi-0008sZ-Vt for v6ops-data@psg.com; Fri, 21 May 2004 18:21:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BREdh-0008sC-CJ for v6ops@ops.ietf.org; Fri, 21 May 2004 18:21:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4LIL0i02245; Fri, 21 May 2004 21:21:00 +0300 Date: Fri, 21 May 2004 21:21:00 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: huitema@microsoft.com Subject: WG Last Call: draft-ietf-v6ops-unmaneval-02.txt 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, (co-chair hat on) This is a second, shorter WG Last Call for comments on sending draft-ietf-v6ops-unmaneval-02.txt, "Evaluation of Transition Mechanisms for Unmanaged Networks" to the IESG for consideration as Informational: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-02.txt Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. The last call will end in a bit more than a week, on 30th May. Thanks, Pekka & Jonne From owner-v6ops@ops.ietf.org Fri May 21 14:35: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 OAA20559 for ; Fri, 21 May 2004 14:35:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BREqX-000BV7-3t for v6ops-data@psg.com; Fri, 21 May 2004 18:34:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BREqV-000BUX-Ki for v6ops@ops.ietf.org; Fri, 21 May 2004 18:34:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4LIYEV02496; Fri, 21 May 2004 21:34:14 +0300 Date: Fri, 21 May 2004 21:34:14 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: huitema@microsoft.com Subject: Re: WG Last Call: draft-ietf-v6ops-unmaneval-02.txt 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 21 May 2004, Pekka Savola wrote: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-02.txt As for my personal comments on -02, see below. substantial ----------- In a configured solution, a host or a router identifies itself to a tunneling service to set up a "configured tunnel" with an explicitly defined "tunnel router". The amount of actual configuration may vary from manually configured static tunnels to dynamic tunnel services requiring only the configuration of a "tunnel broker". ==> maybe add here something to the effect: , or even a completely automatic discovery of the tunnel router. (that's certainly an important goal, one that we're working towards!) .... When the local ISP is willing to provide a configured tunnel solution, we should make it easy for the host in case A to use it. ==> add here or in 2.3 something like: The requirements for such a service are presented in another document [TUNREQS]. (there TUNREQS is an informational reference to Alain and Florent's recent doc.) The IETF should quickly provide a recommended procedure for provisioning the DNS resolver in IPv6-only hosts, either by standardizing the proper DHCPv6 subset, or by recommending an alternate convention. ==> the DHCPv6 subset has already been standardized, so I think the original intent would be preserved if one just removed everything after ",either .." ... [TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs." Work in progress. [TSP] M. Blanchet, "IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)". work in progress. [DSTM] J. Bound, "Dual Stack Transition Mechanism". Work in progress. ==> these must be moved over to Informative section, otherwise they'd block the publication of this doc, and we don't want that. editorial --------- The requirements for unmanaged networks are expressed by analyzing four classes of application: local, client, peer to peer, and ==> s/application/applications/ ? Automatic tunnels generally cannot provide the same level of service. The IPv6 address is only as stable as the underlying IPv4 address, ==> s/address/address (and port)/ for Teredo case? These costs are largely inexistent when the tunnels are configured ==> s/in/non-/ ? v6-v6 path. (The native ISP do not have an incentive to provide relays for general use; they are expected to restrict access to ==> s/do/does/ ? native or 6to4 hosts are de-facto multi-homed to native and Teredo, ==> s/multi-homed/"multi-homed"/ (this is probably not a considered real multihoming...) require such mechanism, but they incur the risk of "head of queue blocking", which may translate in poor performances. Given the ==> s/performances/performance/ The automatic solutions have to rely on a "lower common denominator" ==> s/lower/lowest/ (or was this intentional?) today to carry IPv4, but in many cases could easily carry IPv6. For example, the IETF standard, L2TP, includes a PPP layer that can ==> s/, the IETF standard, L2TP,/L2TP,/ (it's not officially a standard, but proposed stanadard, and this seems irrelevant here) IPv6 capable hosts may be willing to provide services accessible from the global Internet. They will thus need to document their address in a server that is publicly available. IPv4 hosts in ==> s/document/publish/ A simplified form of case B occurs is a single host with a global ==> remove "occurs" ? [NAT-PT] Tsirtsis, G., and P. Srisuresh. "Network Address Translation - Protocol Translation (NAT-PT)." RFC 2766, February 2000. ==> this reference was not used in the body of the draft, so remove? -- 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-v6ops@ops.ietf.org Fri May 21 14: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 OAA20593 for ; Fri, 21 May 2004 14:35:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BREq8-000BRD-5K for v6ops-data@psg.com; Fri, 21 May 2004 18:33:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BREq5-000BQa-Li for v6ops@ops.ietf.org; Fri, 21 May 2004 18:33:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4LIWlx02447; Fri, 21 May 2004 21:32:47 +0300 Date: Fri, 21 May 2004 21:32:47 +0300 (EEST) From: Pekka Savola To: js.jason.lin@foxconn.com cc: v6ops@ops.ietf.org Subject: Re: Developing IP version-independent Applications 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk inline.. (I waited for other comments, but they didn't appear :) On Mon, 17 May 2004 js.jason.lin@foxconn.com wrote: > On Sat, 15 May 2004 js.jason.lin@foxconn.com wrote: > This allows eliminating the compile-time special casing from the code, > making the code simpler. > > > I am not sure whether most IPv4-only really support such getaddrinfo > or getnameinfo > API. But I am afraid to add a version of getaddrinfo/getnameinfo into > applications can be much > complicated than using conditional compilation. > <> Depends a lot on how the code is designed. If you create your own network connectivity manipulation functions, it should be quite easy to make them conditional. If you don't, you'll have to sprinkle conditional conditions all over your code. And that's a pain to maintain as well. There's no winner or loser here. I'm familiar with some open-source projects; most use only getaddrinfo and provide background compatibility code as appropriate. Some others provide conditionally either at compile time. It's a judgement call for the developer, and I'm not sure whether this needs text in this document. It might be good to spell it out. Do you have text suggestions? > Further, the IPv4-only operation is most important in practice for > nodes which already would be able to support IPv6, but the support is > turned off. The applications should continue to work under those > circumstances. > > > I think this is really a good reason for "version-independent" > programming. > In embedded system, whether to activate IPv6 or not is usually > determined in compilation time. > However, for PC, IPv6 really can be changed dynamically. > <> Totally agree here, and this was the most important original reason for adding this ipv4-only section. > Maybe the justification for this should be clarified a bit? Would you > have ideas how to do that? > > > IMHO, the key value of "version-independent" API is for the > situations where IPv6 can > be DYNAMICALLY disabled. And before we claim the application written > in "version-independent" API > can run in IPv4-only platform, we'd better make sure these > "version-independent" API is supported in > those legacy IPv4-only platform in advance. Yes, that's probably the most important case. > Finally, I have one more related question: > If my platform supported IPv4-mapped IPv6 address and the IPv6 won't > be disabled forever. > Then for TCP server application, do you think it is enough to create > one IPv6 socket to > server IPv4 and IPv6 TCP client? Or we still need to create two > sockets, one for each version, > like the sample code described in Sec 6.3.1? > <> The document takes no firm stance here, on purpose. You have to make that decision based on the tradeoffs such as portability (some systems don't support mapped addresses), how you tread the addresses (e.g., whether you want to parse mapped addresses or v4 addresses), etc. As for my personal opinion, I'd go for two sockets for long-term projects, and possibly for one socket in some limited short-term hacks. -- 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-v6ops@ops.ietf.org Fri May 21 14:54: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 OAA21421 for ; Fri, 21 May 2004 14:54:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRF8Z-000Eo3-QF for v6ops-data@psg.com; Fri, 21 May 2004 18:52:55 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRF8Y-000Enl-QG for v6ops@ops.ietf.org; Fri, 21 May 2004 18:52:54 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 15:55: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 PAA25732 for ; Fri, 21 May 2004 15:55:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRG4f-000P8D-VA for v6ops-data@psg.com; Fri, 21 May 2004 19:52:57 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRG4e-000P7n-Go for v6ops@ops.ietf.org; Fri, 21 May 2004 19:52:56 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 17:09: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 RAA03821 for ; Fri, 21 May 2004 17:09:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRHDf-000Bw3-AJ for v6ops-data@psg.com; Fri, 21 May 2004 21:06:19 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRHDc-000BvK-6B for v6ops@ops.ietf.org; Fri, 21 May 2004 21:06:16 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 18:35: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 SAA09958 for ; Fri, 21 May 2004 18:35:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRIZW-000PDd-5e for v6ops-data@psg.com; Fri, 21 May 2004 22:32:58 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRIZV-000PD8-2M for v6ops@ops.ietf.org; Fri, 21 May 2004 22:32:57 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 20:14: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 UAA14710 for ; Fri, 21 May 2004 20:14:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRK8J-000IK4-1P for v6ops-data@psg.com; Sat, 22 May 2004 00:12:59 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRK8H-000IJq-Q1 for v6ops@ops.ietf.org; Sat, 22 May 2004 00:12:57 +0000 Received: (qmail 26203 invoked from network); 21 May 2004 16:52:43 -0000 Received: from unknown (HELO lenny) (211.161.40.181) by mail.ict.ac.cn with SMTP; 21 May 2004 16:52:43 -0000 From: "liumin" To: "'JF Tremblay'" Cc: Subject: RE: Teredo vs Silkroad Date: Sat, 22 May 2004 01:12:01 +0800 Message-ID: <001d01c43f56$be36db60$b528a1d3@lenny> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <94101721.1085141039@SOUL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of JF Tremblay > Sent: Saturday, May 22, 2004 12:04 AM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad > > --On May 21, 2004 2:31 PM +0800 rengrong wang wrote: > > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that Silkroad wants to > > enable nodes located behind one or several IPv4 NATs to obtain IPv6 > > connectivity and it seems like a tunnel-broker solution. It is known > > that Teredo is a automatic tunnel mechanism that figures out the same > > problem. > > > > What's the difference between Silkroad and Teredo? > > IMHO, Silkroad is simply another protocol based on tunnel broker/server > model (RFC3053) with an optimization to make two hosts on the same link > realize they can talk directly. Teredo on the other hand allows hosts > implementing a Teredo client to exchange directly through NATs, except > symmetric ones. However traffic to hosts not implementing a Teredo client > must go through a relay. I don't think so. TSP is a tunnel broker solution, which is not presented to solve NAT transversal but to provide one easy way to configure and maintain many different tunnels. From this point, TSP has relation to all existing tunnel technologies. But it is a "pure procedure" management technology for tunnels. It is totally different from tunnel technologies which focus on methodology for tunnels. Silkroad is not an implementation of tunnel broker like TSP. > > At first sight, Silkroad doesn't seem to offer any significant improvement > over TSP, except the nodes-on-same-link optimization. Both support NAT > traversal with any type of NAT, including nested ones. However TSP doesn't > require the use of a web page, offers prefix delegation, authentication and > has a solid experimental background since it's been deployed for over 5 > years to more than 100000 users. Web pages is just one way for Silkroad client to learn its SAR, there are many other ways to reach this point, including XML presentation. > > The question sparking in my mind from this is whether of not the detection > of two tunneled hosts on the same link would be a desirable feature to > include in the tunnel broker model. It involves the broker telling a host > what is the public IPv4 address and port of another host, which may be a > security issue. However with Teredo this information is already included in > the IPv6 address, so I guess it would provide the same level of security. > > > Best regards, > > > > Crisy(Rengrong) Wang > > ======================================= > > USC,EE-Systems > > > > > > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than > astronomy is about telescopes" - E. W. Dijkstra > ------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri May 21 23:36: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 XAA23095 for ; Fri, 21 May 2004 23:36:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRNHz-0004cQ-Em for v6ops-data@psg.com; Sat, 22 May 2004 03:35:11 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRNHy-0004c8-G6 for v6ops@ops.ietf.org; Sat, 22 May 2004 03:35:10 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id C6D7DB3; Fri, 21 May 2004 23:35:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 23:35:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Teredo vs Silkroad Date: Fri, 21 May 2004 23:35:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C133@tayexc13.americas.cpqcorp.net> Thread-Topic: Teredo vs Silkroad Thread-Index: AcQ/O8TjNs3egtx3S+e4She7g+gITQADjmogABjuvCA= From: "Bound, Jim" To: "Christian Huitema" , "Eiffel Wu" , Cc: X-OriginalArrivalTime: 22 May 2004 03:35:09.0517 (UTC) FILETIME=[C84677D0:01C43FAD] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I don't see any relays in Silkroad? thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Christian Huitema > Sent: Friday, May 21, 2004 11:58 AM > To: Eiffel Wu; pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: Teredo vs Silkroad >=20 > From an analysis of the drafts, it appears that silkroad is=20 > closer to tunnel brokers than to Teredo. Silkroad relies on=20 > the deployment of a large number of relays and servers, that=20 > become part of the ISP > infrastructure: this is very similar to the deployment of=20 > tunnel servers by the ISP. It provides pretty much the same=20 > advantages as tunnel brokers, i.e. stable addresses and=20 > robust tunneling across different types of infrastructure. >=20 > The part of Silkroad that somewhat resemble Teredo is the=20 > routing optimization between the tunnel servers (called SAR=20 > in silkroad). I don't think that this is particularly=20 > valuable: once you have reached an ISP router, you would=20 > expect normal routing protocols to take over and route=20 > packets along the optimal path. In fact, this feature will be=20 > perceived as detrimental by many ISP, since it makes their=20 > network management more complex than necessary.=20 >=20 > -- Christian Huitema >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri May 21 23:36: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 XAA23113 for ; Fri, 21 May 2004 23:36:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRNJ2-0004pv-C6 for v6ops-data@psg.com; Sat, 22 May 2004 03:36:16 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRNJ1-0004pd-8E for v6ops@ops.ietf.org; Sat, 22 May 2004 03:36:15 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 90AAEA444; Fri, 21 May 2004 23:36:14 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 23:36:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Teredo vs Silkroad Date: Fri, 21 May 2004 23:36:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C134@tayexc13.americas.cpqcorp.net> Thread-Topic: Teredo vs Silkroad Thread-Index: AcQ/TX9BlBC8PrUxTCCDnCQIBLuxGAAYFwLA From: "Bound, Jim" To: "JF Tremblay" , "rengrong wang" , X-OriginalArrivalTime: 22 May 2004 03:36:14.0399 (UTC) FILETIME=[EEF2ACF0:01C43FAD] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Silkroad defines a protocol within UDP to discover routers. That is new IMO. And worth discussion. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JF Tremblay > Sent: Friday, May 21, 2004 12:04 PM > To: rengrong wang; v6ops@ops.ietf.org > Subject: Re: Teredo vs Silkroad >=20 > --On May 21, 2004 2:31 PM +0800 rengrong wang=20 > wrote: >=20 > > Hi, > > > > In draft-liumin-v6ops-silkroad-01.txt it is said that=20 > Silkroad wants=20 > > to enable nodes located behind one or several IPv4 NATs to=20 > obtain IPv6=20 > > connectivity and it seems like a tunnel-broker solution. =20 > It is known=20 > > that Teredo is a automatic tunnel mechanism that figures=20 > out the same=20 > > problem. > > > > What's the difference between Silkroad and Teredo? >=20 > IMHO, Silkroad is simply another protocol based on tunnel=20 > broker/server model (RFC3053) with an optimization to make=20 > two hosts on the same link realize they can talk directly.=20 > Teredo on the other hand allows hosts implementing a Teredo=20 > client to exchange directly through NATs, except symmetric=20 > ones. However traffic to hosts not implementing a Teredo=20 > client must go through a relay. >=20 > At first sight, Silkroad doesn't seem to offer any=20 > significant improvement over TSP, except the=20 > nodes-on-same-link optimization. Both support NAT traversal=20 > with any type of NAT, including nested ones. However TSP=20 > doesn't require the use of a web page, offers prefix=20 > delegation, authentication and has a solid experimental=20 > background since it's been deployed for over 5 years to more=20 > than 100000 users. >=20 > The question sparking in my mind from this is whether of not=20 > the detection of two tunneled hosts on the same link would be=20 > a desirable feature to include in the tunnel broker model. It=20 > involves the broker telling a host what is the public IPv4=20 > address and port of another host, which may be a security=20 > issue. However with Teredo this information is already=20 > included in the IPv6 address, so I guess it would provide the=20 > same level of security. >=20 > > Best regards, > > > > Crisy(Rengrong) Wang > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > USC,EE-Systems > > > > >=20 > Jean-Francois Tremblay > Hexago > ------------------------------------------------- > http://www.freenet6.net : Free IPv6 Connectivity > ------------------------------------------------- > "Computer Science is no more about computers than astronomy=20 > is about telescopes" - E. W. Dijkstra > ------------------------------------------------- >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri May 21 23:36: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 XAA23128 for ; Fri, 21 May 2004 23:36:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRNGt-0004Os-R1 for v6ops-data@psg.com; Sat, 22 May 2004 03:34:03 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRNGs-0004OW-C8 for v6ops@ops.ietf.org; Sat, 22 May 2004 03:34:02 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8209FA3E4; Fri, 21 May 2004 23:34:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 23:34:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43FAD.9F183795" Subject: RE: Teredo vs Silkroad Date: Fri, 21 May 2004 23:33:56 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C132@tayexc13.americas.cpqcorp.net> Thread-Topic: Teredo vs Silkroad Thread-Index: AcQ/OxxRZMq7zUzYSpSd4Hf47N9eSgAcf9Nw From: "Bound, Jim" To: "Eiffel Wu" , Cc: X-OriginalArrivalTime: 22 May 2004 03:34:01.0160 (UTC) FILETIME=[9F880480:01C43FAD] 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, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C43FAD.9F183795 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I saw that too in the draft via the http ability to the SN adding a tunnel broker like service was very good. I think this has merit and well written and clear technical specification. I also want to add the fact that silkroad does not require fixed or defined prefix is a big win for several current IPv6 deployment efforts. Many clients do not want anything but their aggregatable prefixes used within the network and for transition, and silkroad as one of the mechanisms we have do this too. It also has security benefit too. =20 /jim ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Eiffel Wu Sent: Friday, May 21, 2004 9:55 AM To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: Re:Teredo vs Silkroad =09 =09 =09 >> >On Fri, 21 May 2004, Eiffel Wu wrote: >> >> As compared with the Teredo, Silkroad has the following >> >> strongpoints: >> >> >> >> 2. Silkroad can deploy without the support of relay, while the >> >> Teredo needs the relay which advertises the reachability of Teredo >> >> Prefix. >> > >> >That's not really true, I think. You can deploy Teredo using your=20 >> >own, arbitrary prefix, ("internal Teredo server"), and to the rest of=20 >> >the Internet, it looks like native IPv6 service. >>=20 >> Cited from Teredo: >> Teredo relays are IPv6 routers that advertise reachability of the >> Teredo service IPv6 prefix through the IPv6 routing protocols. >>=20 >> Teredo address format: >> +-------------+-------------+-------+------+-------------+ >> | Prefix | Server IPv4 | Flags | Port | Client IPv4 | >> +-------------+-------------+-------+------+-------------+ >> =20 >> - Prefix: the 32 bit Teredo service prefix. >> - Server IPv4: the IPv4 address of a Teredo server. > >Yes, but look at the definitions: > >=3D=3D=3D=3D=3D=3D=3D=3D >2.5 Teredo IPv6 service prefix > =20 > An IPv6 addressing prefix which is used to construct the IPv6 > address of Teredo clients. > =20 >2.5.1 Global Teredo IPv6 service prefix > =20 > An IPv6 addressing prefix whose value is XXXX:XXXX:/32. > (TBD IANA; experiments use the value 3FFE:831F::/32, taken from a =20 > range of experimental IPv6 prefixes assigned to Microsoft.) >=3D=3D=3D=3D=3D=3D=3D=3D=3D > >in other words, there can be multiple Teredo IPv6 service prefixes. =20 >Anyone can establish one just if the operator has a /32 prefix to=20 >spare. Many probably don't :). How many ISPs have a /32 prefix ? As i know, now there are no ISPs that have a /32 prefix in China. Moreover, There are thousands of million NAT users in China, which will need=20 many of Teredo relays and corresponding Teredo /32 prefixes. When does Chinese ISPs have so many /32 prefixes ? i don't think the day will come soon. =20 >> >> 3. Silkroad supports all types of NATs, while Teredo doesn't support >> >> symmetric NATs. >> > >> >Obviously, this could be added very easily to Teredo as well, but it=20 >> >would require that Teredo servers would act as tunnel endpoints, and=20 >> >there would not be direct tunneling. That would burden the servers to=20 >> >that it would probably be undesirable. >> >> Whether or no, Teredo does not support symmetric NATs. > >See section 6. If you used Teredo just as a tunnel service, it would=20 >work with symmetric NATs as well. I don't think many people would=20 >want to deploy the servers like that though.. :) =20 The tunnel service is mentioned just as an idea and described simply in Teredo. Silkroad is a tunnel broken similar mechanism and it overcomes the known limitations=20 of tunnel broker that it can not work if the user is using private IPv4 addresses=20 behind a NAT box. ------_=_NextPart_001_01C43FAD.9F183795 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I saw that too in the draft via the http = ability to the SN=20 adding a tunnel broker like service was very good.  I think this = has merit=20 and well written and clear technical specification.  I also want to = add the=20 fact that silkroad does not require fixed or defined prefix is a big win = for=20 several current IPv6 deployment efforts.   Many clients do not = want=20 anything but their aggregatable prefixes used within the network and for = transition, and silkroad as one of the mechanisms we have do this = too.  It=20 also has security benefit too.
 
/jim

From: owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Eiffel=20 Wu
Sent: Friday, May 21, 2004 9:55 AM
To:=20 pekkas@netcore.fi
Cc: v6ops@ops.ietf.org
Subject:=20 Re:Teredo vs Silkroad


>> >On Fri, 21 May 2004, Eiffel Wu = wrote:
>>=20 >> As compared with the Teredo, Silkroad has the = following
>>=20 >> strongpoints:
>> >>
>> >> 2. = Silkroad=20 can deploy without the support of relay, while the
>> = >> Teredo=20 needs the relay which advertises the reachability of = Teredo
>>=20 >> Prefix.
>> >
>> >That's not really = true, I=20 think.  You can deploy Teredo using your
>> >own, = arbitrary=20 prefix, ("internal Teredo server"), and to the rest of
>> = >the=20 Internet, it looks like native IPv6 service.
>>
>> = Cited=20 from Teredo:
>> Teredo relays are IPv6 routers that advertise = reachability of the
>> Teredo service IPv6 prefix through the = IPv6=20 routing protocols.
>>
>> Teredo address=20 format:
>>  =20 = +-------------+-------------+-------+------+-------------+
>>&nb= sp; =20 | Prefix      | Server IPv4 | Flags | Port | = Client=20 IPv4 |
>>  =20 = +-------------+-------------+-------+------+-------------+
>>&nb= sp;  =20
>>    - Prefix: the 32 bit Teredo service=20 prefix.
>>    - Server IPv4: the IPv4 address = of a=20 Teredo server.
>
>Yes, but look at the=20 = definitions:
>
>=3D=3D=3D=3D=3D=3D=3D=3D
>2.5 &nbs= p;   Teredo=20 IPv6 service prefix
>  
>   An IPv6=20 addressing prefix which is used to construct the = IPv6
>  =20 address of Teredo clients.
>   =
>2.5.1  =20 Global Teredo IPv6 service prefix
>   =
>   An=20 IPv6 addressing prefix whose value is = XXXX:XXXX:/32.
>   (TBD=20 IANA; experiments use the value 3FFE:831F::/32, taken from = a  =20
>   range of experimental IPv6 prefixes assigned to=20 Microsoft.)
>=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>in other = words, there can be=20 multiple Teredo IPv6 service prefixes. 
>Anyone can = establish one=20 just if the operator has a /32 prefix to
>spare. Many probably = don't=20 :).
How many ISPs have a /32 prefix ?
As i know, now there are = no ISPs=20 that have a /32 prefix in China.
Moreover, There are thousands of = million=20 NAT users in China, which will need
many of Teredo relays and=20 corresponding Teredo /32 prefixes. When does Chinese
ISPs have so = many /32=20 prefixes ? i don't think the day will come soon.
 

>> >> 3. Silkroad supports all types of NATs, = while=20 Teredo doesn't support
>> >> symmetric = NATs.
>>=20 >
>> >Obviously, this could be added very easily to = Teredo as=20 well, but it
>> >would require that Teredo servers would = act as=20 tunnel endpoints, and
>> >there would not be direct=20 tunneling.  That would burden the servers to
>> = >that it=20 would probably be undesirable.
>>
>> Whether or no, = Teredo=20 does not support symmetric NATs.
>
>See section 6.  = If you=20 used Teredo just as a tunnel service, it would
>work with = symmetric=20 NATs as well.  I don't think many people would
>want to = deploy the=20 servers like that though.. :)
 
The tunnel service is mentioned just as an idea and described = simply in=20 Teredo.
Silkroad is a tunnel broken similar mechanism and it = overcomes the=20 known limitations
of tunnel broker that it can not work if the = user is=20 using private IPv4 addresses
behind a NAT=20 box.
------_=_NextPart_001_01C43FAD.9F183795-- From owner-v6ops@ops.ietf.org Sat May 22 04:32: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 EAA20554 for ; Sat, 22 May 2004 04:32:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRRst-00026N-OL for v6ops-data@psg.com; Sat, 22 May 2004 08:29:35 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRRsg-00022k-6V for v6ops@ops.ietf.org; Sat, 22 May 2004 08:29:22 +0000 Received: (qmail 30167 invoked from network); 22 May 2004 08:15:43 -0000 Received: from unknown (HELO wxg) (159.226.39.69) by mail.ict.ac.cn with SMTP; 22 May 2004 08:15:43 -0000 Message-ID: <002801c43fd7$53346e00$4527e29f@wxg> From: "Eiffel Wu" To: Cc: , Subject: Re:Teredo vs Silkroad Date: Sat, 22 May 2004 16:32:31 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C4401A.614BC720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00, FORGED_OUTLOOK_TAGS,MIME_BASE64_TEXT,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C4401A.614BC720 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciB1c2VmdWwgaW5mb3JtYXRpb24uDQppIGRvbid0IGtub3cgdGhlIGFsbG9j YXRpb24gb2YgSVB2NiBhZGRyZXNzIGV4YWN0bHkgYmVmb3JlLCBub3cgaSBhbSBjbGVhciBhYm91 dCBpdC46KQ0KDQpBIC8zMiBwcmVmaXggaGFzIGEgbGFyZ2UgYWRkcmVzcyBzcGFjZSwgd2hpY2gg Y2FuIGRpdmlkZWQgaW50byBtYW55IGJsb2NrcyB0byBhc3NpZ24gdG8gc3ViLUlTUHMuDQpGcm9t IGxhcmdlIElTUHMnIHBvaW50LCBpIHRoaW5rIHRoZSBkZXBsb3ltZW50IG9mIFRlcmVkbyBuZWVk cyBjYXV0aW91cyBjb25zaWRlcmF0aW9uLg== ------=_NextPart_000_0025_01C4401A.614BC720 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFuayB5b3UgZm9yJm5i c3A7dXNlZnVsIGluZm9ybWF0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmkg ZG9uJ3Qga25vdyB0aGUgYWxsb2NhdGlvbiBvZiBJUHY2IGFkZHJlc3MgZXhhY3RseSBiZWZvcmUs IA0Kbm93IGkgYW0gY2xlYXIgYWJvdXQgaXQuOik8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5BIC8zMiBwcmVmaXgg aGFzIGEgbGFyZ2UgYWRkcmVzcyBzcGFjZSwgd2hpY2ggY2FuIGRpdmlkZWQgaW50byANCm1hbnkg YmxvY2tzIHRvIGFzc2lnbiB0byBzdWItSVNQcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5Gcm9tIGxhcmdlIElTUHMnIHBvaW50LCBpIHRoaW5rIHRoZSBkZXBsb3ltZW50IG9mIFRl cmVkbyBuZWVkcyANCmNhdXRpb3VzIGNvbnNpZGVyYXRpb24uPC9GT05UPjwvRElWPjwvQk9EWT48 L0hUTUw+DQo= ------=_NextPart_000_0025_01C4401A.614BC720-- From owner-v6ops@ops.ietf.org Sat May 22 04:37: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 EAA20692 for ; Sat, 22 May 2004 04:37:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRRzq-00038W-E9 for v6ops-data@psg.com; Sat, 22 May 2004 08:36:46 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRRzn-00038C-0B for v6ops@ops.ietf.org; Sat, 22 May 2004 08:36:43 +0000 Received: (qmail 30721 invoked from network); 22 May 2004 08:23:04 -0000 Received: from unknown (HELO wxg) (159.226.39.69) by mail.ict.ac.cn with SMTP; 22 May 2004 08:23:04 -0000 Message-ID: <003301c43fd8$5a4b59f0$4527e29f@wxg> From: "Eiffel Wu" To: Cc: Subject: Re:Teredo vs Silkroad Date: Sat, 22 May 2004 16:39:53 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C4401B.6869DF00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00, FORGED_OUTLOOK_TAGS,MIME_BASE64_TEXT,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C4401B.6869DF00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 PkZyb20gYW4gYW5hbHlzaXMgb2YgdGhlIGRyYWZ0cywgaXQgYXBwZWFycyB0aGF0IHNpbGtyb2Fk IGlzIGNsb3NlciB0bw0KPnR1bm5lbCBicm9rZXJzIHRoYW4gdG8gVGVyZWRvLiBTaWxrcm9hZCBy ZWxpZXMgb24gdGhlIGRlcGxveW1lbnQgb2YgYQ0KPmxhcmdlIG51bWJlciBvZiByZWxheXMgYW5k IHNlcnZlcnMsIHRoYXQgYmVjb21lIHBhcnQgb2YgdGhlIElTUA0KPmluZnJhc3RydWN0dXJlOiB0 aGlzIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgZGVwbG95bWVudCBvZiB0dW5uZWwgc2VydmVycw0K PmJ5IHRoZSBJU1AuIEl0IHByb3ZpZGVzIHByZXR0eSBtdWNoIHRoZSBzYW1lIGFkdmFudGFnZXMg YXMgdHVubmVsDQo+YnJva2VycywgaS5lLiBzdGFibGUgYWRkcmVzc2VzIGFuZCByb2J1c3QgdHVu bmVsaW5nIGFjcm9zcyBkaWZmZXJlbnQNCj50eXBlcyBvZiBpbmZyYXN0cnVjdHVyZS4NCj4NCj5U aGUgcGFydCBvZiBTaWxrcm9hZCB0aGF0IHNvbWV3aGF0IHJlc2VtYmxlIFRlcmVkbyBpcyB0aGUg cm91dGluZw0KPm9wdGltaXphdGlvbiBiZXR3ZWVuIHRoZSB0dW5uZWwgc2VydmVycyAoY2FsbGVk IFNBUiBpbiBzaWxrcm9hZCkuIEkNCj5kb24ndCB0aGluayB0aGF0IHRoaXMgaXMgcGFydGljdWxh cmx5IHZhbHVhYmxlOiBvbmNlIHlvdSBoYXZlIHJlYWNoZWQgYW4NCj5JU1Agcm91dGVyLCB5b3Ug d291bGQgZXhwZWN0IG5vcm1hbCByb3V0aW5nIHByb3RvY29scyB0byB0YWtlIG92ZXIgYW5kDQo+ cm91dGUgcGFja2V0cyBhbG9uZyB0aGUgb3B0aW1hbCBwYXRoLiBJbiBmYWN0LCB0aGlzIGZlYXR1 cmUgd2lsbCBiZQ0KPnBlcmNlaXZlZCBhcyBkZXRyaW1lbnRhbCBieSBtYW55IElTUCwgc2luY2Ug aXQgbWFrZXMgdGhlaXIgbmV0d29yaw0KPm1hbmFnZW1lbnQgbW9yZSBjb21wbGV4IHRoYW4gbmVj ZXNzYXJ5LiANCg0KVGhhbmtzIGZvciB5b3VyIGFkdmljZSwgd2Ugd2lsbCB0YWtlIGl0IGludG8g YWNjb3VudC4NCkkgdGhpbmsgaXQncyBub3QgY29udHJhZGljdGlvbiBiZXR3ZWVuIFRlcmVkbyBh bmQgU2lsa3JvYWQuIFRoZXkgY2FuIGJlIGNvbXBsZW1lbnRlZCB3aXRoIGVhY2ggb3RoZXIuDQoN CkVpZmZlbCBXdQ== ------=_NextPart_000_0030_01C4401B.6869DF00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4mZ3Q7RnJvbSBhbiBhbmFs eXNpcyBvZiB0aGUgZHJhZnRzLCBpdCBhcHBlYXJzIHRoYXQgc2lsa3JvYWQgDQppcyBjbG9zZXIg dG88QlI+Jmd0O3R1bm5lbCBicm9rZXJzIHRoYW4gdG8gVGVyZWRvLiBTaWxrcm9hZCByZWxpZXMg b24gdGhlIA0KZGVwbG95bWVudCBvZiBhPEJSPiZndDtsYXJnZSBudW1iZXIgb2YgcmVsYXlzIGFu ZCBzZXJ2ZXJzLCB0aGF0IGJlY29tZSBwYXJ0IG9mIA0KdGhlIElTUDxCUj4mZ3Q7aW5mcmFzdHJ1 Y3R1cmU6IHRoaXMgaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBkZXBsb3ltZW50IG9mIHR1bm5lbCAN CnNlcnZlcnM8QlI+Jmd0O2J5IHRoZSBJU1AuIEl0IHByb3ZpZGVzIHByZXR0eSBtdWNoIHRoZSBz YW1lIGFkdmFudGFnZXMgYXMgDQp0dW5uZWw8QlI+Jmd0O2Jyb2tlcnMsIGkuZS4gc3RhYmxlIGFk ZHJlc3NlcyBhbmQgcm9idXN0IHR1bm5lbGluZyBhY3Jvc3MgDQpkaWZmZXJlbnQ8QlI+Jmd0O3R5 cGVzIG9mIGluZnJhc3RydWN0dXJlLjxCUj4mZ3Q7PEJSPiZndDtUaGUgcGFydCBvZiBTaWxrcm9h ZCANCnRoYXQgc29tZXdoYXQgcmVzZW1ibGUgVGVyZWRvIGlzIHRoZSByb3V0aW5nPEJSPiZndDtv cHRpbWl6YXRpb24gYmV0d2VlbiB0aGUgDQp0dW5uZWwgc2VydmVycyAoY2FsbGVkIFNBUiBpbiBz aWxrcm9hZCkuIEk8QlI+Jmd0O2Rvbid0IHRoaW5rIHRoYXQgdGhpcyBpcyANCnBhcnRpY3VsYXJs eSB2YWx1YWJsZTogb25jZSB5b3UgaGF2ZSByZWFjaGVkIGFuPEJSPiZndDtJU1Agcm91dGVyLCB5 b3Ugd291bGQgDQpleHBlY3Qgbm9ybWFsIHJvdXRpbmcgcHJvdG9jb2xzIHRvIHRha2Ugb3ZlciBh bmQ8QlI+Jmd0O3JvdXRlIHBhY2tldHMgYWxvbmcgdGhlIA0Kb3B0aW1hbCBwYXRoLiBJbiBmYWN0 LCB0aGlzIGZlYXR1cmUgd2lsbCBiZTxCUj4mZ3Q7cGVyY2VpdmVkIGFzIGRldHJpbWVudGFsIGJ5 IA0KbWFueSBJU1AsIHNpbmNlIGl0IG1ha2VzIHRoZWlyIG5ldHdvcms8QlI+Jmd0O21hbmFnZW1l bnQgbW9yZSBjb21wbGV4IHRoYW4gDQpuZWNlc3NhcnkuIDxCUj48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5UaGFua3MgZm9yIHlvdXIgYWR2aWNlLCB3ZSB3aWxsIHRha2UgaXQgaW50 byANCmFjY291bnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSB0aGluayBpdCdz IG5vdCBjb250cmFkaWN0aW9uIGJldHdlZW4gVGVyZWRvIGFuZCBTaWxrcm9hZC4gDQpUaGV5IGNh biBiZSBjb21wbGVtZW50ZWQgd2l0aCBlYWNoIG90aGVyLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkVpZmZlbCBX dTwvRElWPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0030_01C4401B.6869DF00-- From owner-v6ops@ops.ietf.org Sat May 22 04:39: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 EAA20775 for ; Sat, 22 May 2004 04:39:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRS27-0003QM-CK for v6ops-data@psg.com; Sat, 22 May 2004 08:39:07 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRS25-0003Pw-Gs for v6ops@ops.ietf.org; Sat, 22 May 2004 08:39:05 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000113152.msg for ; Sat, 22 May 2004 10:40:15 +0200 Message-ID: <160401c43fd8$2b5b3520$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <002801c43fd7$53346e00$4527e29f@wxg> Subject: Re: Re:Teredo vs Silkroad Date: Sat, 22 May 2004 10:38:33 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sat, 22 May 2004 10:40:15 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Sat, 22 May 2004 10:40:18 +0200 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Eiffel, I'm not sure what do you mean with sub-ISPs, but probably is worth to read RFC3177 (ftp://ftp.rfc-editor.org/in-notes/rfc3177.txt) and RIR IPv6 policy documents. I guess the sub-ISPs will get also a minimum of /32, as bigger prefixes can be allocated (see http://www.eu.ipv6tf.org/PublicDocuments/deployment_plans_behind_larger_ipv6_allocations_v5.pdf). Regards, Jordi ----- Original Message -----=20 From: "Eiffel Wu" To: Cc: ; Sent: Saturday, May 22, 2004 10:32 AM Subject: Re:Teredo vs Silkroad > Thank you for useful information. > i don't know the allocation of IPv6 address exactly before, now i am clear about it.:) >=20 > A /32 prefix has a large address space, which can divided into many blocks to assign to sub-ISPs. > From large ISPs' point, i think the deployment of Teredo needs cautious consideration. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sat May 22 07:55: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 HAA01666 for ; Sat, 22 May 2004 07:55:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRV31-000AUj-89 for v6ops-data@psg.com; Sat, 22 May 2004 11:52:15 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRV2z-000AUH-FC for v6ops@ops.ietf.org; Sat, 22 May 2004 11:52:13 +0000 Received: (qmail 93542 invoked by uid 1007); 22 May 2004 11:52:12 -0000 Date: Sat, 22 May 2004 13:52:12 +0200 From: Gert Doering To: Eiffel Wu Cc: v6ops@ops.ietf.org Subject: Re: Teredo vs Silkroad Message-ID: <20040522115212.GX13090@Space.Net> References: <002801c43fd7$53346e00$4527e29f@wxg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002801c43fd7$53346e00$4527e29f@wxg> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space 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-v6ops@ops.ietf.org Precedence: bulk Hi, On Sat, May 22, 2004 at 04:32:31PM +0800, Eiffel Wu wrote: > i don't know the allocation of IPv6 address exactly before, now i am clear about it.:) > > A /32 prefix has a large address space, which can divided into many blocks to assign to sub-ISPs. Just as a side note, to complete the picture: if an ISP has sufficient customers (or a sufficiently large deployment plan), even larger address blocks than a /32 can be allocated by the regional registries. Currently, most ISPs do not need more than a /32, but at least in RIPE land, one /31, /27 and even one /20 have been allocated to big Telco-ISPs (with many broadband customers). The same rules apply to APNIC ISPs, so "getting large enough address space" for chinese ISPs is mostly a question of actually talking to APNIC and explaining their deployment plans. For details on the APNIC IPv6 allocation policy, please see: http://www.apnic.net/services/ipv6_guide.html http://ftp.apnic.net/apnic/docs/ipv6-address-policy Gert Doering -- RIPE Address Policy WG Co-Chair -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Sat May 22 08:56: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 IAA04949 for ; Sat, 22 May 2004 08:56:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRW0n-000M3z-0L for v6ops-data@psg.com; Sat, 22 May 2004 12:54:01 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRW0l-000M3g-NZ for v6ops@ops.ietf.org; Sat, 22 May 2004 12:53:59 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 389FF666B for ; Sat, 22 May 2004 08:53:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 22 May 2004 08:53:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Enterprise Scenarios WG Last Call Input Alaii Durand - Section 4 Date: Sat, 22 May 2004 08:53:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C14A@tayexc13.americas.cpqcorp.net> Thread-Topic: Enterprise Scenarios WG Last Call Input Alaii Durand - Section 4 Thread-Index: AcQ/+X8uIHlP2obCQSq2rmDxm21rwAAASBOQ From: "Bound, Jim" To: Cc: X-OriginalArrivalTime: 22 May 2004 12:53:59.0036 (UTC) FILETIME=[D96D0BC0:01C43FFB] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Alain, I think we should just remove Section 4 and it does not really affect the specs objective. We can discuss solution space for this space in the analysis for sure. I will send you offline mail on your diatribe below as we both have a client that completely disagrees with your assumptions below on Ipv6 dominant networks for multiple reasons. No point in using up IETF cycles and will send you private mail. Thanks for Your Input, /jim > I think that the document has matured a lot, however I'm a=20 > bit puzzled by section 4, and specially 4.2 & 4.3 that I=20 > found not very well articulated. >=20 > 4.2 IPv6 Tunnels to Encapsulate IPv4 >=20 >=20 >=20 > An IPv6 capable node, on an IPv6 link within an IPv6=20 > routing domain, > wants to communicate with a legacy IPv4 application. >=20 >=20 > =3D=3D> I'm not sure how an IPv6 over IPv4 tunnel by itself is=20 > going to solve this, unless you assume a model like DSTM=20 > where the v6 node and applications are v4 aware, but the=20 > infrastructure is not.... This is not spelled out in the scenario. >=20 > In other words, I think 4.2 is not describing a scenario but=20 > showing a solution. >=20 >=20 >=20 > 4.3 IPv6 only communicating with IPv4 >=20 >=20 >=20 > An IPv6 capable node wants to communicate with an IPv4 service, but > the node is operating as IPv6 only. In order to continue=20 > support for > communications with IPv4 services an IPv6 to IPv4=20 > translator or IPv6 > proxy is required. Introduction of such software may prevent usage > of end-to-end security trust models and applications carrying > embedded IP addressing information. Bi-directional=20 > establishment of > connections might be difficult to achieve. >=20 >=20 > =3D=3D> somehow similar comment, this is solution space, not=20 > scenario space. >=20 > So I believe that section 4 is not quiet ready and should=20 > describe the problem more, that is, from what I understand,=20 > how to interoperate between v4 & v6 services (not nodes), or=20 > more specifically, how to access legacy v4 service. >=20 > the 3 sub-cases are IMHO: >=20 > a) v4 only or dual stack client app on dual stack node in=20 > dual protocol network accessing a v4-only service (solution=20 > hint: use the v4 stack.) >=20 > b) v4 only or dual stack client app on dual stack node on=20 > mono protocol v6 network accessing a v4-only service i.e. the=20 > network on which the client sits has no IPv4 native routing (=20 > solution hint: use the v4 stack, but tunnel v4 over v6 to=20 > regain IPv4 connectivity) >=20 >=20 > c) v6 only client app accessing a v4-only service > (solution hint: failure or translation or relay) >=20 >=20 > There is of course the reverse scenario, of legacy v4 clients=20 > accessing new v6 services. >=20 > The real challenge of this document is now to explain in each=20 > of the example scenarios which of those cases really apply=20 > and thus MUST be solved, versus saying everything MUST be solved. >=20 > So, as a conclusion, I think that section 4 is not ready for=20 > publication. > Note: I think the rest of the document is. Would removing=20 > section 4 entirely be an option? >=20 > Alain. >=20 >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun May 23 21:49: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 VAA19543 for ; Sun, 23 May 2004 21:49:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS4XW-0000io-St for v6ops-data@psg.com; Mon, 24 May 2004 01:46:06 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BS4XT-0000iL-9T for v6ops@ops.ietf.org; Mon, 24 May 2004 01:46:03 +0000 Received: (qmail 8927 invoked from network); 24 May 2004 01:31:56 -0000 Received: from unknown (HELO Amy) (159.226.39.104) by mail.ict.ac.cn with SMTP; 24 May 2004 01:31:56 -0000 From: "Liu Min" To: "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Mon, 24 May 2004 09:45:22 +0800 Message-ID: <008b01c44130$c6cfcf80$7774a8c0@Amy> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Christian Huitema > Sent: Friday, May 21, 2004 11:58 PM > To: Eiffel Wu; pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: Teredo vs Silkroad > > From an analysis of the drafts, it appears that silkroad is closer to > tunnel brokers than to Teredo. Silkroad relies on the deployment of a > large number of relays and servers, that become part of the ISP > infrastructure: this is very similar to the deployment of tunnel servers > by the ISP. It provides pretty much the same advantages as tunnel > brokers, i.e. stable addresses and robust tunneling across different > types of infrastructure. There is no relay in Silkroad. Is Teredo the mechanism to be used by the ISP to provide v6 to his customers, or is it meant to be used by those users whose ISP/3GPP operator does not support v6 (or these mechanisms) at all? > > The part of Silkroad that somewhat resemble Teredo is the routing > optimization between the tunnel servers (called SAR in silkroad). I > don't think that this is particularly valuable: once you have reached an > ISP router, you would expect normal routing protocols to take over and > route packets along the optimal path. In fact, this feature will be > perceived as detrimental by many ISP, since it makes their network > management more complex than necessary. > > -- Christian Huitema > From owner-v6ops@ops.ietf.org Mon May 24 00:58: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 AAA26753 for ; Mon, 24 May 2004 00:58:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS7Vw-000G4l-8C for v6ops-data@psg.com; Mon, 24 May 2004 04:56:40 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS7Vu-000G4A-CQ for v6ops@ops.ietf.org; Mon, 24 May 2004 04:56:38 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 23 May 2004 21:56:39 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sun, 23 May 2004 21:56:24 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 23 May 2004 21:56:37 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 23 May 2004 21:56:35 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 23 May 2004 21:56:36 -0700 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); Sun, 23 May 2004 21:57:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Teredo vs Silkroad Date: Sun, 23 May 2004 21:56:34 -0700 Message-ID: Thread-Topic: Teredo vs Silkroad Thread-Index: AcRBMQb7QPbe6A6ITkqbxGMDdCZejQAGbE5w From: "Christian Huitema" To: "Liu Min" , "Eiffel Wu" , Cc: X-OriginalArrivalTime: 24 May 2004 04:57:07.0261 (UTC) FILETIME=[904E26D0:01C4414B] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > There is no relay in Silkroad. What? The figure in section 4.1 (Silkroad Model) of draft-liumin-v6ops-silkroad-01.txt clearly shows a "SAR'" in the path between a regular IPv6 node and a node using the silkroad scheme. This is exactly the same role as a Teredo relay, or a 6to4 relay.=20 -- Christian Huitema From owner-v6ops@ops.ietf.org Mon May 24 01:45: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 BAA29196 for ; Mon, 24 May 2004 01:45:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS8G4-000PbG-7Z for v6ops-data@psg.com; Mon, 24 May 2004 05:44:20 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BS8G2-000Pax-VR for v6ops@ops.ietf.org; Mon, 24 May 2004 05:44:19 +0000 Received: (qmail 1085 invoked from network); 24 May 2004 05:30:16 -0000 Received: from unknown (HELO Amy) (159.226.39.104) by mail.ict.ac.cn with SMTP; 24 May 2004 05:30:16 -0000 From: "Liu Min" To: "'Christian Huitema'" Cc: Subject: RE: Teredo vs Silkroad Date: Mon, 24 May 2004 13:43:44 +0800 Message-ID: <000201c44152$137efe70$7774a8c0@Amy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The SAR is not the same role as a Teredo relay, or a 6to4 relay. It is more like a tunnel server than a relay. Best Wishes, Liu Min Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240 E-mail: liumin@ict.ac.cn > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Monday, May 24, 2004 12:57 PM > To: Liu Min; Eiffel Wu; pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: Teredo vs Silkroad > > > There is no relay in Silkroad. > > What? The figure in section 4.1 (Silkroad Model) of > draft-liumin-v6ops-silkroad-01.txt clearly shows a "SAR'" in the path > between a regular IPv6 node and a node using the silkroad scheme. This > is exactly the same role as a Teredo relay, or a 6to4 relay. > > -- Christian Huitema From owner-v6ops@ops.ietf.org Mon May 24 01:53: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 BAA29457 for ; Mon, 24 May 2004 01:53:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS8OH-00018x-JJ for v6ops-data@psg.com; Mon, 24 May 2004 05:52:49 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BS8O8-000175-BB for v6ops@ops.ietf.org; Mon, 24 May 2004 05:52:40 +0000 Received: (qmail 1416 invoked from network); 24 May 2004 05:31:55 -0000 Received: from unknown (HELO Amy) (159.226.39.104) by mail.ict.ac.cn with SMTP; 24 May 2004 05:31:55 -0000 From: "Liu Min" To: "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Mon, 24 May 2004 13:45:23 +0800 Message-ID: <000301c44152$4ea9c890$7774a8c0@Amy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Christian Huitema > Sent: Friday, May 21, 2004 11:58 PM > To: Eiffel Wu; pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: Teredo vs Silkroad > > From an analysis of the drafts, it appears that silkroad is closer to > tunnel brokers than to Teredo. Silkroad relies on the deployment of a > large number of relays and servers, that become part of the ISP > infrastructure: this is very similar to the deployment of tunnel servers > by the ISP. It provides pretty much the same advantages as tunnel > brokers, i.e. stable addresses and robust tunneling across different > types of infrastructure. Why do you think Silkroad need more relays and servers than Teredo? > > The part of Silkroad that somewhat resemble Teredo is the routing > optimization between the tunnel servers (called SAR in silkroad). I > don't think that this is particularly valuable: once you have reached an > ISP router, you would expect normal routing protocols to take over and > route packets along the optimal path. In fact, this feature will be > perceived as detrimental by many ISP, since it makes their network > management more complex than necessary. > > -- Christian Huitema > From owner-v6ops@ops.ietf.org Mon May 24 02:00: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 CAA00590 for ; Mon, 24 May 2004 02:00:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS8Uj-0002mf-Sc for v6ops-data@psg.com; Mon, 24 May 2004 05:59:29 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS8Uj-0002mG-0e for v6ops@ops.ietf.org; Mon, 24 May 2004 05:59:29 +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); Sun, 23 May 2004 22:59:40 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 23 May 2004 22:59:28 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 23 May 2004 22:59:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 23 May 2004 22:59:41 -0700 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); Sun, 23 May 2004 22:59:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Teredo vs Silkroad Date: Sun, 23 May 2004 22:59:25 -0700 Message-ID: Thread-Topic: Teredo vs Silkroad Thread-Index: AcRBUnOGjloJh59eQz2+wHffrXR58wAATlrw From: "Christian Huitema" To: "Liu Min" , "Eiffel Wu" , Cc: X-OriginalArrivalTime: 24 May 2004 05:59:58.0361 (UTC) FILETIME=[580E5890:01C44154] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Why do you think Silkroad need more relays and servers than Teredo? The SAR's relay packets, while Teredo servers don't. It implies that you will need more SAR servers than Teredo servers. The number of relays is different. Depending how you count, there are currently maybe 1 or 2 Teredo relays, or 2 millions. This is because every host that is aware of Teredo can act as a "host specific relay". I suspect that the number of relays required for silkroad is similar to the number required for 6to4.=20 -- Christian Huitema From owner-v6ops@ops.ietf.org Mon May 24 02:10: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 CAA10564 for ; Mon, 24 May 2004 02:10:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS8fB-0005iy-BW for v6ops-data@psg.com; Mon, 24 May 2004 06:10:17 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BS8fA-0005iI-3U for v6ops@ops.ietf.org; Mon, 24 May 2004 06:10:16 +0000 Received: (qmail 6912 invoked from network); 24 May 2004 05:56:04 -0000 Received: from unknown (HELO Amy) (159.226.39.104) by mail.ict.ac.cn with SMTP; 24 May 2004 05:56:04 -0000 From: "Liu Min" To: "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Mon, 24 May 2004 14:09:32 +0800 Message-ID: <000601c44155$ae853e90$7774a8c0@Amy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Monday, May 24, 2004 1:59 PM > To: Liu Min; Eiffel Wu; pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: Teredo vs Silkroad > > > Why do you think Silkroad need more relays and servers than Teredo? > > The SAR's relay packets, while Teredo servers don't. It implies that you > will need more SAR servers than Teredo servers. No. Although Teredo servers don't relay packets, Teredo need separate relays. SAR's role includes the role of Teredo server and Teredo relay. You should compare the number of SAR with the number of Teredo servers + Teredo relays. > > The number of relays is different. Depending how you count, there are > currently maybe 1 or 2 Teredo relays, or 2 millions. This is because > every host that is aware of Teredo can act as a "host specific relay". I > suspect that the number of relays required for silkroad is similar to > the number required for 6to4. > > -- Christian Huitema From owner-v6ops@ops.ietf.org Mon May 24 08:25: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 IAA01544 for ; Mon, 24 May 2004 08:25:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSEU1-000NZk-16 for v6ops-data@psg.com; Mon, 24 May 2004 12:23:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSETx-000NYf-Pp for v6ops@ops.ietf.org; Mon, 24 May 2004 12:23:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4OCN4g28976 for ; Mon, 24 May 2004 15:23:04 +0300 Date: Mon, 24 May 2004 15:23:04 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt In-Reply-To: <1084375210.11297.10.camel@localhost.localdomain> 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.8 required=5.0 tests=AWL,BAYES_00,CASHCASHCASH autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 12 May 2004, Jonne Soininen wrote: > Hi everybody, > > this is a WG Last Call for comments on sending > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network > Scenarios" to the IESG for consideration as Informational: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt Personal comments below. Seems to be ready after a revision for clarifications etc. -- in any case, the most important thing is the _next_ document.. I think Example network C, a security defense network, is not mainstream enough to be applicable to be investigated in the scenarios. There are probably 1, 5 or 10 such networks in the world. We should be focusing on more common scenarios (even addressing "80/20" would be good). [I have a few specific comments for clarification within this example, but I'll send them if this example is not replaced by something else.] I also thought that section 4 could possibly be removed at this point. If it wouldn't be, there are a few clarifications I have scribbed up, omitting them now.. substantial: ------------ [Network Infrastructure Component 1, sect 3.2] Enterprise Provider Requirements - One site vs. multiple sites? ==> do you refer to _geographical_ sites here, or something else (e.g., in the multi6 WG sense)? Maybe add 'geographical' here? - Leased lines or VPN? ==> spell out, e.g. to: - If multiple sites, how is the traffic exchanged securely between them? ... - What is the IPv6 address assignment plan available from the provider? ==> this should possibly be spelled out a bit, like: - Do the provider(s) delegate a stable /48 prefix? Does the enterprise need more? ... - Will clients be Multihomed? ==> 'clients'? Spell out a bit, maybe like: - Is the enterprise multihomed? Which multihoming techniques are supported by the Service provider? ... - Is there an external data-center? ==> I think this needs to be spelled out a bit. Did you mean like: - Would some enterprise server(s) be housed in the service providers' data centers? ... ==> add an additional requirement, like: - Is IPv6 available using the same access links as IPv4, or differently? ... [Network Infrastructure Component 2] ==> add a couple of requirements, like: - Are applications only run in the internal networks? - Are ALGs or proxies being used for some applications? Would using such be feasible? - Are there applications which cannot be proxied or upgraded to support IPv6? [Network Infrastructure Component 3] - Is a Tele-commuter work force supported? ==> reword to be more generic, maybe like: - Is working remotely (e.g., through VPNs) supported? ... - Is inter-site communications required? ==> I don't quite understand this requirement, because I fail to see _any_ scenario where you wouldn't need to communicate between sites? Could you clarify? - Is network mobility used or required for IPv6? ==> This requirement seems to need a bit more spelling out, as it isn't 100% obvious what you're referring to (MIPv6 vs NEMO?), what's the usage case? - What are the requirements of the IPv6 address plan? ==> maybe add a couple of clarifying points here: - Is there a detailed asset management database, including hosts, IP/MAC addresses, etc.? - What is the enterprise' approach to numbering geographically separate sites which have their own Service Providers? ... - What will be the IPv6 Security policy/procedure? ==> there should probably be a bit more on this..? maybe at least like: - Are separate or same firewalls, IDS systems, etc. used for IPv6? Which part of the traffic is encrypted using IPsec and how? Network Infrastructure Component 4 Enterprise Network Management System - Performance Management Required? - Network Management Applications Required? - Configuration Management Required? - Policy Management and Enforcement Required? - Security Management Required? - Management of Transition Tools and Mechanisms? ==> these should probably be spelled out a bit more, because at least I didn't have much idea what all of these included? [Example Network A, sect 3.3] - ISP does not offer IPv6 service. - Private Leased Lines no Service Provider Used ==> is the first really often the case? If you're a suffiently big enterprise, I think at least in Europe there are already quite a few ISPs willing to give you service. (note: s/ISP does/ISPs do/ .. as it has multiple ISPs?) ==> I don't quite understand the second bullet point? do you mean that the site has just one ISP, and the rest are connected using leased lines to the "primary" ISP, and they don't have a direct connectivity at all? I'm not sure if this is any longer the "mainstream" scenario, because the net traffic is probably so high that the enterprises don't want to pay $$$$ for transporting all their traffic to their HQ using leased lines, but to throw it out to their ISP immediately (and tunnel internal traffic with VPNs, or leased lines). - All routers and switches are upgradeable to IPv6. - Existing firewalls can be upgraded to support IPv6 rules. ==> are these mainstream scenarios? What does a switch's IPv6 upgrade mean (is it L3 switch? or management functions?) - IPv4 Private address space is used within the enterprise. ==> the enterprise already had PI space (from the above), but still uses private address space internally -- any particular reason why? DNS will now have to support both IPv4 and IPv6 DNS records and the enterprise will need to determine how the DNS is to be managed and accessed, and secured. The range of DNS operational issues are out of scope for this work. [...] ==> here, it would be good to refer to draft-ietf-dnsop-ipv6-dns-issues-07.txt, and possibly add at the end something like: These operations include at least: - configuring IPv6 DNS servers as resolvers on IPv6(-only) hosts, - selecting a method to insert AAAA/PTR records in the DNS, - managing the DDNS reverse/forward updates processes, if used, - providing IPv6 transport capability in the recursive internal DNS servers, and - managing the IPv6 capability in the authoritative servers, and configuring the AAAA records at the delegator of the DNS zones. .... The choice of interior routing protocols have an impact on how the routing tables will be handled: some such as OSPF will have the ships-in-the-night paradigm, others such as ISIS are integrated. This has an impact on the topology and the management of the network. ==> I don't really understand what you mean with the sentence about OSPF vs ISIS. Do you mean that w/ OSPF you'd use separately OSPFv2 and OSPFv3, and with IS-IS just one process? Note that this discussion could probably be just a summary of draft-ietf-v6ops-isp-scenarios-analysis-02.txt section 4.3.1 and the Appendix A. (We should refer to that document here at least.) IPv6 capable routers should be monitored to ensure the router has sufficient storage for both IPv6 and IPv4 route tables. Existing network design principles to limit the number of routes in the network, such as prefix aggregation, become more critical with the addition of IPv6 to an existing IPv4 network. ==> I do not think monitoring the routers for sufficient v4/v6 route table storage is an operationally important issue, clearly not more son than monitoring v4 route tables today, at least. Maybe just remove this first sentence or even the whole paragraph. ==> maybe add at the end add something like: Decisions wrt. routing include at least: - whether IPv4 and IPv6 routing topologies will be different, affecting the decision on which routing protocols to use, - how redundancy is ensured if tunneling is used, and - which tools are to be used to monitor the IPv6 infrastructure. 5.3 Autoconfiguration IPv6 introduces the concept of stateless autoconfiguration in addition to stateful autoconfiguration. The enterprise will have to determine the best method of autoconfiguration, for their network. The enterprise will need to determine if they are to use stateless or stateful autoconfiguration, and how autoconfiguration is to operate for DNS updates. The enterprise will need to determine how prefix delegation is done from their upstream provider and how those prefixes are cascaded down to the enterprise IPv6 network. The policy for DNS or choice of autoconfiguration is out of scope for this document. ==> this section should probably be generalized to be something like 'Configuration of Hosts [or: .. of Infrastructure and Hosts]' (and generalize the autoconfiguration a bit more in the rest of the paragraph as well) ==> remove ", for their network", as everything is done for their network in any case. ==> dynamic prefix delegation inside the enterprise may not be a really feasible option, but in any case, I'd probably add something like: "; the choices are to do this manually, or using a dynamic protocol" to better spell it out. ==> One might consider adding at the end something on whether an asset management database is being used, and the choices for configuring other information on the hosts (e.g., DNS servers, proxy servers, etc.etc.). 5.4 Security Current existing mechanisms used for IPv4 to provide security need to be supported for IPv6 within the enterprise. IPv6 should create no * new security concerns for IPv4. The entire security infrastructure * currently used in the enterprise needs to be analyzed against IPv6 * deployment effect and determine what is supported in IPv6. Users should review other security IPv6 network infrastructure work in the * IETF and within the industry on going at this time. Users will have * to work with their platform and software providers to determine what * IPv6 security network infrastructure components are supported. The security filters and firewall requirments for IPv6 need to be determined by the enterprise. The policy choice of users for security is out of scope for this document. ==> there is considerable overlap with two sentences above, marked with '*'. I suggest removing one of them and expanding the other slightly. ==> you should probably refer to some security documents here, e.g., draft-savola-v6ops-security-overview-02.txt ==> add at the end maybe something like: At the very least, one has to consider for example: - whether the same access control/IDS policies are to be used for IPv6 as with IPv4, and whether these are to be handled by the same or different equipment/software, - how keying and/or certificates are managed, - how VPNs are controlled, - whether RFC3041 temporary addresses are to be used and to what extent if so, - whether there are to be internal access control points, and - if tunneling techniques are used, how this affects the site security, and how site must be secured to make tunneling secure. 5.6 Network Management The addition of IPv6 network infrastructure components will need to be managed by the enterprise network operations center. Users will need to work with their network management platform providers to determine what for IPv6 is supported during their planning for IPv6 adoption, and what tools are available in the market to monitor the network. ==> remove 'in the market' -- appears redundant here? ==> maybe add something like: At least, one should consider: - whether IPv6-capable devices can be managed or monitored using IPv4, and what must be done if that is not possible, and - how IPv6 infrastructures are being monitored? 5.7 Address Planning The address space within the enterprise will need to be defined and coordinated with the routing topology of the enterprise network. It is also important to identify the pool of IPv4 address space available to the enterprise to assist with IPv6 transition methods. ==> I don't think the "pool of IPv4 address space" is all that relevant consideration here, as it hints at the use of IPv6-only infrastructures, NAT-PT, and the like. ==> in any case, I think there is one thing that should be explicitly called out: Whether the site wants to consider whether this new kind of local addressing is used for v6 or not. For inter-domain use, sites may choose to migrate IPv4 multicast applications to SSM, for which no reverse path discovery method is required. ==> ", for ..." part is incorrect and out of context, replace with something like: ", which simplifies the multicast architecture, but requires that the applications specify the multicast transmission source(s). ==> Maybe add a new paragraph: The enterprises also need to consider whether IGMP/MLD snooping or similar solutions to reduce the multicast flooding is required: this may be especially important if the subnets are large, or multicast is used extensively. 5.9 Multihoming At this time, current IPv6 allocation policies are mandating the allocation of IPv6 address space from the upstream provider. If an enterprise is multihomed, the enterprise will have to determine how they wish to support multihoming. This also is an area of study within the IETF and work in progress. ==> I think it would be appropriate to describe RFC3178 model of multihoming very briefly, e.g., like in section 5.6 in draft-ietf-v6ops-isp-scenarios-analysis-02.txt 7. References 7.1 Normative References None at this time. [...] ==> please add a lot more explicit informative / normative references to the subject which were discussed. semi-editorial -------------- [Scenario 2 in sect 3.1] Scenario 2: Enterprise with an existing IPv4 network wants to deploy a set of particular IPv6 "applications" (application is voluntarily loosely defined here, e.g. peer to peer). The IPv6 deployment is limited to the minimum required to operate this set of applications. ==> I don't think it's good to say "minimum" here, because there is no reason to restrict it to the absolute minimum required. The point here is just that v6 deployment doesn't need to be _larger_ than required to operate the set of applications. Maybe reword: s/is limited to/does not need to be more extensive than/ editorial --------- IPv6 Enterprise Network Scenarios ==> maybe rename to something like 'Enterprise Networks IPv6 Transition Scenarios' to be more in line with the rest of the document? Enterprise Network - A network that has multiple internal links, one or more router connections, to one or more Providers and is actively managed by a network operations entity. ==> align the text for those lines which were broken to multiple lines by originally too many chars/line? (same also later) Provider - An entity that provides services and connectivity to the Internet or other private external networks for the enterprise network. ==> isn't 'Provider' a slightly too terse (and ambiguous) term? Maybe 'Service Provider' or abbreviated SP if necessary, instead? IPv6 only - A node or network capable of supporting only IPv6. This does not imply an IPv6 only stack, in this document. ==> the last sentence should probably be reworded to be clearer. Did you mean something like: In the context of this document, a dual-stack node which has disabled IPv4 is considered IPv6 only. 3.2 Scenarios Network Infrastructure Components ==> reword to: 'Network Infrastructure Components for Scenarios' ? - Are the nodes moving within the enterprise network? - Are the nodes moving outside and inside the enterprise network? ==> these should probably be shifted left about 3-4 spaces? - The DHCP server to update naming records for dynamic desktops uses ==> reword maybe to: - The DHCP server updates the DNS records for dynamic desktops with DDNS. Document Acknowledgments ==> s/Document // Authors-Design Team Contact Information ==> maybe reword to "Authors' Addresses" as it's the regular format? ==> this is pretty long. Two possibilities to summarize this a bit: a) add an "Editor's Address" section, with just Jim's contact info, in full; Keep "Authors' Addresses" section for the rest, but mention only names, affiliations and the email addresses. b) just take out other info for the non-editors as names, affiliations and email addresses. -- 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-v6ops@ops.ietf.org Mon May 24 08:29: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 IAA01713 for ; Mon, 24 May 2004 08:29:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSEZw-000OTn-0p for v6ops-data@psg.com; Mon, 24 May 2004 12:29:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSEZu-000OTZ-Oy for v6ops@ops.ietf.org; Mon, 24 May 2004 12:29:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4OCT7n29063; Mon, 24 May 2004 15:29:07 +0300 Date: Mon, 24 May 2004 15:29:07 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt In-Reply-To: <20040512224942.GJ16007@login.ecs.soton.ac.uk> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 12 May 2004, Tim Chown wrote: > I believe this is ready. > > Alain's point is valid, but I don't believe changes would impact the > usefulness of the draft as is. If section 4 were removed a requirement > subsection would be needed in section 5 to state that legacy interworking > is required for four main modes: > > a) dual-stack <-> v4 or v6 only > b) v4 only <-> v6 only > c) v4 <-> v4 over v6 infrastructure > d) v6 <-> v6 over v4 infrastructure Isn't this a list of all the possible combinations? The point here is, do we need to care for all of these combinations? For example, in the unmanaged networks, b) was considered out of scope, and that's also recommended against in the 3GPP. c) is also something that I'm not sure there is yet consensus whether this is a reasonable approach at this point. One goal of the scenarios/analysis work is to try to identify the actual, critical, mainstream scenarios which call of certain kind of interworking or mechanisms. I think at least a) or d) fulfill these criteria, but b) and c) might be so-and-so, depending on how you phrase it and which kind of techniques one might have in mind applying.. > On Wed, May 12, 2004 at 06:20:11PM +0300, Jonne Soininen wrote: > > Hi everybody, > > > > this is a WG Last Call for comments on sending > > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network > > Scenarios" to the IESG for consideration as Informational: > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt > > > > > > Please review these documents, and send your feedback to the > > list. Please also indicate whether or not you believe that this > > document is ready to go to the IESG. > > > > The last call will end in two weeks, on May 26th. > > > > Pekka & Jonne > > > > > -- 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-v6ops@ops.ietf.org Mon May 24 09:02: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 JAA03298 for ; Mon, 24 May 2004 09:02:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSF5F-0004fC-Uf for v6ops-data@psg.com; Mon, 24 May 2004 13:01:37 +0000 Received: from [209.123.233.212] (helo=smtp-out2.oct.nac.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSF5A-0004aU-F5 for v6ops@ops.ietf.org; Mon, 24 May 2004 13:01:32 +0000 Received: (qmail 19863 invoked by uid 0); 24 May 2004 09:01:31 -0400 Received: from rfgraveman@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.027874 secs); 24 May 2004 13:01:31 -0000 Received: from unknown (HELO webmail.nac.net) (64.21.52.85) by smtp-out2.oct.nac.net with SMTP; 24 May 2004 09:01:31 -0400 Received: from 67.84.243.204 (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Mon, 24 May 2004 09:01:31 -0400 (EDT) Message-ID: <33639.67.84.243.204.1085403691.squirrel@webmail.nac.net> In-Reply-To: References: <1084375210.11297.10.camel@localhost.localdomain> Date: Mon, 24 May 2004 09:01:31 -0400 (EDT) Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt From: rfgraveman@nac.net To: "Pekka Savola" Cc: v6ops@ops.ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,NO_REAL_NAME, PRIORITY_NO_NAME,RCVD_IN_NJABL,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Pekka, > ... > I think Example network C, a security defense network, is not > mainstream enough to be applicable to be investigated in the > scenarios. There are probably 1, 5 or 10 such networks in the world. > We should be focusing on more common scenarios (even addressing > "80/20" would be good). [I have a few specific comments for > clarification within this example, but I'll send them if this example > is not replaced by something else.] > ... OTOH, some of these networks are large, and they buy a lot of equipment, so some major vendors take their requirements quite seriously. Therefore, I would be against dropping this case. We can discuss further whether this is exactly the right characterization, however. Regards, Richard From owner-v6ops@ops.ietf.org Mon May 24 09:31: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 JAA05120 for ; Mon, 24 May 2004 09:31:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSFWI-000BLt-7D for v6ops-data@psg.com; Mon, 24 May 2004 13:29:34 +0000 Received: from [66.218.79.79] (helo=web80509.mail.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSFWD-000BL2-Dm for v6ops@ops.ietf.org; Mon, 24 May 2004 13:29:29 +0000 Message-ID: <20040524132928.1321.qmail@web80509.mail.yahoo.com> Received: from [63.197.18.101] by web80509.mail.yahoo.com via HTTP; Mon, 24 May 2004 06:29:28 PDT Date: Mon, 24 May 2004 06:29:28 -0700 (PDT) From: Fred Templin Subject: RE: Teredo vs Silkroad To: Liu Min , "'Christian Huitema'" , "'Eiffel Wu'" , pekkas@netcore.fi Cc: v6ops@ops.ietf.org In-Reply-To: <000601c44155$ae853e90$7774a8c0@Amy> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1158099757-1085405368=:99884" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1158099757-1085405368=:99884 Content-Type: text/plain; charset=us-ascii Liu Min wrote: No. Although Teredo servers don't relay packets, Teredo need separate relays. I don't think "separate relay" is is an accurate way to characterize a relay that occurs on the end host? Fred osprey67@yahoo.com --0-1158099757-1085405368=:99884 Content-Type: text/html; charset=us-ascii
Liu Min <liumin@ict.ac.cn> wrote:

No. Although Teredo servers don't relay packets, Teredo need separate
relays.

I don't think "separate relay" is is an accurate way to characterize
a relay that occurs on the end host?
 
Fred
--0-1158099757-1085405368=:99884-- From owner-v6ops@ops.ietf.org Mon May 24 14:33: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 OAA22391 for ; Mon, 24 May 2004 14:33:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSKDK-0002cd-Oe for v6ops-data@psg.com; Mon, 24 May 2004 18:30:18 +0000 Received: from [4.14.91.19] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSKD2-0002YN-Uz for v6ops@ops.ietf.org; Mon, 24 May 2004 18:30:01 +0000 Received: from eaglet (127.0.0.1:3696) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 24 May 2004 11:30:01 -0700 From: "Tony Hain" To: "'Liu Min'" , "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Mon, 24 May 2004 11:29:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <000601c44155$ae853e90$7774a8c0@Amy> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRBVhWvHGKWj9l6SeqwIzuvF+80EwAWubFA X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Liu Min wrote: > ... > No. Although Teredo servers don't relay packets, Teredo need separate > relays. > SAR's role includes the role of Teredo server and Teredo relay. You > should compare the number of SAR with the number of Teredo servers + > Teredo relays. This whole discussion has completely ignored the broken concept of the Silkroad Navigator. That device is essentially a route reflector, without any mechanism to secure the updates to it, or a distribution protocol for consistency (assuming there is intended to be more than one in the world). Also there is an unstated assumption that the Silkroad clients just know how to find the navigator (if IPv4 anycast is assumed, that should be explicitly stated). Any fair comparison should be to tunnel broker schemes, but if one insists on relating this to Teredo, the navigator is functionally the same as the Teredo server, while the access router is functionally the same as the Teredo relay. The primary difference is that Silkroad provides the address stability of a tunnel broker at the expense of client automation. As for security, the idea that an RA could come from an arbitrary navigator pointing to some random Silkroad access router is a security hole big enough to drive an army through (never mind that it fails by using an IPv6 function to provide IPv4 information). Of course, a SC can determine the address or domain name of a SAR through other means. For example, the SC could get the address of SAR by sending Router Solicitation message over UDP to the SN. The SN replies with a Router Advertisement over UDP containing the address of available SAR. The whole lifetime discussion is confused. All prefixes will have a lifetime, it may be very long, but it will be there. Any discussion about 'permanent' only invites people to believe the prefix will move with them when they leave Slikroad behind, but that can't happen if the prefix is part of the SAR aggregate. Moreover, if the SC is an IPv6 router willing to provide IPv6 connectivity to several hosts, it should provide some information about how many IPv6 addresses are required. This allows the SAR to allocate the SC an IPv6 prefix that fits its address needs. That is a nice concept, but unnecessary complexity. Given that there is an authentication step at the navigator to find the SAR to begin with, the appropriate prefix length for this subscriber is already available and doesn't need to be included in the protocol between the client and SAR. 4.2.3 is useless clutter since the base assumption is that there may be multiple nats in the path. Why is there an assumption that they will all be the same type, or that any optimization for the first hop nat will actually be useful along a path full of nats? The whole discussion misses the point that many transfers will be over before an optimization determination could be made. Figure 2 is very ambiguous (and actually supports Christian's note about the number of SARs). It appears that R1 & R2 should really be SAR1 & SAR2, with a collection of routers (IPv4 Rn) not shown. If R1 has never forwarded an packet towards this IPv6 destination address and has no route information in its local route table, it will connect to SN to search the list of SARs that can forward IPv6 packets to the specific IPv6 network and get the IPv4 addresses of these SARs. No, any router without a route will drop the packet. Anything else will kill the router. Clearly there is need for a periodic routing update here, but the overall specification assumes a small lab environment style network where scale and time delays don't matter. For example: the SC can specify the transmission method in Control Option domain No ISP would allow their customers to define the transmission path choice between its routers. It would appear that the authors don't really have a grasp on operational realities: When B wants to transmit an IPv6 packet to A, B simply follows IPv6 rules. The packet will be forwarded to one SAR close to B in the IPv6 Internet topology, R2, over IPv6. Why would this happen? The only reason would be that a routing prefix for A is announced by B into the IPv6 routing domain. But this unreasonable assumption is followed with: If R2 has no route information in its local route table, it will connect to SN to search the IPv4 address of the SAR that can forward IPv6 packets to the specific IPv6 address. If R2 has no route information, why would it be telling the IPv6 domain that it does? Teredo can do this because it uses a unique prefix for all Teredo reachable destinations and assumes the IPv4 network is contiguous. Silkroad can't do this unless all SARs have full routing tables for all clients. Another example: All SARs could configure static routes between each other Static configuration is a lab class concept; not useful in the real world. In the simplest case, when the Silkroad clients are very few, one SAR may be enough, only if the SAR has connected to IPv6 Internet. One thing I haven't seen on the list are all the traditional complaints about open relays and spoofing. There is nothing magic about a SAR that would prevent spoofing. If someone really intends to deploy this, a robust mechanism for limiting access and verifying correct IPv4 / IPv6 mappings will be needed. Since the single SN in the world is the only one that the correct mappings, it will clearly need to be consulted for mapping coherence on each cache miss. In the simplest case, when the Silkroad clients and Silkroad access routers are very few, there is no need to configure Silkroad navigator. Wait, I thought the SN was necessary for client authentication up front. How can the system get by without one? It really doesn't matter because the assumption that the world can do with ONE is a clear indication that the spec is a lab effort that is never intended to be deployed. In short Silkroad is nothing more than trying to provide a scaling front end for the forwarding function of the tunnel broker model. While that function is an admirable goal, this spec will need major rework before it even comes close to something that is operationally deployable. A reasonable trust model and fully dynamic routing update system are the first steps. In any case Silkroad should not be compared to Teredo because it is fundamentally a tunnel broker (albeit a broken one in the current spec) so section 7.4 should simply be removed. Tony From owner-v6ops@ops.ietf.org Mon May 24 16:20: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 QAA25768 for ; Mon, 24 May 2004 16:20:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSLsd-000PP6-I8 for v6ops-data@psg.com; Mon, 24 May 2004 20:17:03 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSLsY-000POb-6x for v6ops@ops.ietf.org; Mon, 24 May 2004 20:16:58 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4OKGso26186; Mon, 24 May 2004 23:16:54 +0300 (EET DST) X-Scanned: Mon, 24 May 2004 23:16:39 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4OKGdkX023429; Mon, 24 May 2004 23:16:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00q2Xtjp; Mon, 24 May 2004 23:16:39 EEST 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 i4OKGbH23244; Mon, 24 May 2004 23:16:37 +0300 (EET DST) Received: from localhost.localdomain ([10.162.252.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 23:16:32 +0300 Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt From: Jonne Soininen To: ext Pekka Savola Cc: Tim Chown , v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1085429789.4626.51.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Mon, 24 May 2004 23:16:30 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2004 20:16:32.0930 (UTC) FILETIME=[019B3820:01C441CC] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, these are scenarios and the scenarios should describe the possible scenarios that do make technically sense and hence, are possible to be deployed. I do not see why not all of the scenarios would not make sense. Cheers, Jonne. On Mon, 2004-05-24 at 15:29, ext Pekka Savola wrote: > On Wed, 12 May 2004, Tim Chown wrote: > > I believe this is ready. > > > > Alain's point is valid, but I don't believe changes would impact the > > usefulness of the draft as is. If section 4 were removed a requirement > > subsection would be needed in section 5 to state that legacy interworking > > is required for four main modes: > > > > a) dual-stack <-> v4 or v6 only > > b) v4 only <-> v6 only > > c) v4 <-> v4 over v6 infrastructure > > d) v6 <-> v6 over v4 infrastructure > > Isn't this a list of all the possible combinations? > > The point here is, do we need to care for all of these combinations? > For example, in the unmanaged networks, b) was considered out of > scope, and that's also recommended against in the 3GPP. c) is also > something that I'm not sure there is yet consensus whether this is a > reasonable approach at this point. > > One goal of the scenarios/analysis work is to try to identify the > actual, critical, mainstream scenarios which call of certain kind of > interworking or mechanisms. I think at least a) or d) fulfill these > criteria, but b) and c) might be so-and-so, depending on how you > phrase it and which kind of techniques one might have in mind > applying.. > > > On Wed, May 12, 2004 at 06:20:11PM +0300, Jonne Soininen wrote: > > > Hi everybody, > > > > > > this is a WG Last Call for comments on sending > > > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network > > > Scenarios" to the IESG for consideration as Informational: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt > > > > > > > > > Please review these documents, and send your feedback to the > > > list. Please also indicate whether or not you believe that this > > > document is ready to go to the IESG. > > > > > > The last call will end in two weeks, on May 26th. > > > > > > Pekka & Jonne > > > > > > > > From owner-v6ops@ops.ietf.org Mon May 24 16:43: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 QAA26820 for ; Mon, 24 May 2004 16:43:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSMFV-0003pT-Cm for v6ops-data@psg.com; Mon, 24 May 2004 20:40:41 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSMFS-0003mU-Jj for v6ops@ops.ietf.org; Mon, 24 May 2004 20:40:38 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 389DD1977; Mon, 24 May 2004 16:40:38 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 16:40:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Date: Mon, 24 May 2004 16:40:35 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C1AF@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Thread-Index: AcRBj31NmmjmPFLpRGSoHp0QuwtXPgAP9GOg From: "Bound, Jim" To: , "Pekka Savola" Cc: X-OriginalArrivalTime: 24 May 2004 20:40:38.0053 (UTC) FILETIME=[5EF77D50:01C441CF] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree with Richard and this is not being dropped at all. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of rfgraveman@nac.net > Sent: Monday, May 24, 2004 9:02 AM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt >=20 > Pekka, >=20 > > ... > > I think Example network C, a security defense network, is not=20 > > mainstream enough to be applicable to be investigated in the=20 > > scenarios. There are probably 1, 5 or 10 such networks in=20 > the world. > > We should be focusing on more common scenarios (even addressing=20 > > "80/20" would be good). [I have a few specific comments for=20 > > clarification within this example, but I'll send them if=20 > this example=20 > > is not replaced by something else.] ... >=20 > OTOH, some of these networks are large, and they buy a lot of=20 > equipment, so some major vendors take their requirements=20 > quite seriously. Therefore, I would be against dropping this=20 > case. We can discuss further whether this is exactly the=20 > right characterization, however. >=20 > Regards, Richard >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon May 24 18:07: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 SAA11355 for ; Mon, 24 May 2004 18:07:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSNWP-000K1d-HF for v6ops-data@psg.com; Mon, 24 May 2004 22:02:13 +0000 Received: from [161.114.112.28] (helo=zdemail04.zdem.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSNQn-000IyM-Fe for v6ops@ops.ietf.org; Mon, 24 May 2004 21:56:27 +0000 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.138]) by zdemail04.zdem.compaq.com (Postfix) with ESMTP id 20F5FA4; Mon, 24 May 2004 23:56:13 +0200 (CEST) Received: from vbeexc02.emea.cpqcorp.net ([16.188.146.229]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 23:56:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6529.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: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Date: Mon, 24 May 2004 23:56:10 +0200 Message-ID: <06CAA4D3753C53408D2CE6340B68444205A593F1@vbeexc02.emea.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Thread-Index: AcRBimv4/8YLLpuiT5uaTjK4AcgmTwATwNlg From: "Pouffary, Yanick" To: "Pekka Savola" , X-OriginalArrivalTime: 24 May 2004 21:56:11.0851 (UTC) FILETIME=[ED5229B0:01C441D9] 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,CASHCASHCASH autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi=20 Thanks for the review. Comments in-line. Yanick > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > Behalf Of Pekka Savola > Sent: Monday, May 24, 2004 2:23 PM > To: v6ops@ops.ietf.org > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt >=20 > On 12 May 2004, Jonne Soininen wrote: > > Hi everybody, > > > > this is a WG Last Call for comments on sending=20 > > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network=20 > > Scenarios" to the IESG for consideration as Informational: > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios- > 02.txt >=20 > Personal comments below. >=20 > Seems to be ready after a revision for clarifications etc. -- in any=20 > case, the most important thing is the _next_ document.. >=20 > I think Example network C, a security defense network, is not=20 > mainstream enough to be applicable to be investigated in the=20 > scenarios. There are probably 1, 5 or 10 such networks in the world.=20 > We should be focusing on more common scenarios (even addressing=20 > "80/20" would be good). [I have a few specific comments for=20 > clarification within this example, but I'll send them if this example=20 > is not replaced by something else.] >=20 [YP] I agree with Richard Graveman to keep this example. Please send you're your comments.=20 > I also thought that section 4 could possibly be removed at this point. > If it wouldn't be, there are a few clarifications I have scribbed up,=20 > omitting them now.. >=20 [YP] We all agree > substantial: > ------------ >=20 > [Network Infrastructure Component 1, sect 3.2] > Enterprise Provider Requirements > - One site vs. multiple sites? >=20 > =3D=3D> do you refer to _geographical_ sites here, or something else=20 > (e.g., in the multi6 WG sense)? Maybe add 'geographical' here? >=20 [YP] ok > - Leased lines or VPN? >=20 > =3D=3D> spell out, e.g. to: >=20 > - If multiple sites, how is the traffic exchanged securely between > them? > ... > - What is the IPv6 address assignment plan available > from the provider? >=20 > =3D=3D> this should possibly be spelled out a bit, like: >=20 > - Do the provider(s) delegate a stable /48 prefix? > Does the enterprise need more? >=20 [YP] ok > ... > - Will clients be Multihomed? >=20 > =3D=3D> 'clients'? Spell out a bit, maybe like: >=20 > - Is the enterprise multihomed? Which multihoming techniques are > supported by the Service provider? >=20 [YP] ok > ... >=20 > - Is there an external data-center? >=20 > =3D=3D> I think this needs to be spelled out a bit. Did you mean = like: >=20 > - Would some enterprise server(s) be housed in the service > providers' data centers? >=20 [YP] ok > ... >=20 > =3D=3D> add an additional requirement, like: >=20 > - Is IPv6 available using the same access links as IPv4, > or differently? >=20 [YP] ok > ... >=20 > [Network Infrastructure Component 2] >=20 > =3D=3D> add a couple of requirements, like: >=20 > - Are applications only run in the internal networks? [YP] ok > - Are ALGs or proxies being used for some applications? > Would using such be feasible? > - Are there applications which cannot be proxied or > upgraded to support IPv6? [YP] I think we have this already covered. >=20 > [Network Infrastructure Component 3] >=20 > - Is a Tele-commuter work force supported? >=20 > =3D=3D> reword to be more generic, maybe like: >=20 > - Is working remotely (e.g., through VPNs) supported? >=20 [YP] ok > ... >=20 > - Is inter-site communications required? >=20 > =3D=3D> I don't quite understand this requirement, because I fail to = see _any_ > scenario where you wouldn't need to communicate between sites? Could you > clarify? >=20 [YP] The enterprise may want to deploy IPv6 within a single site. > - Is network mobility used or required for IPv6? >=20 > =3D=3D> This requirement seems to need a bit more spelling out, as it isn't > 100% > obvious what you're referring to (MIPv6 vs NEMO?), what's the usage case? >=20 > - What are the requirements of the IPv6 address plan? >=20 > =3D=3D> maybe add a couple of clarifying points here: >=20 > - Is there a detailed asset management database, including hosts, > IP/MAC addresses, etc.? > - What is the enterprise' approach to numbering geographically > separate sites which have their own Service Providers? >=20 [YP] ok - may be > ... >=20 > - What will be the IPv6 Security policy/procedure? >=20 > =3D=3D> there should probably be a bit more on this..? maybe at least like: >=20 > - Are separate or same firewalls, IDS systems, etc. used for IPv6? > Which part of the traffic is encrypted using IPsec and how? >=20 [YP] your clarifications are useful but do we need to be that specific? > Network Infrastructure Component 4 > Enterprise Network Management System > - Performance Management Required? > - Network Management Applications Required? > - Configuration Management Required? > - Policy Management and Enforcement Required? > - Security Management Required? > - Management of Transition Tools and Mechanisms? >=20 > =3D=3D> these should probably be spelled out a bit more, because at = least I > didn't have much idea what all of these included? >=20 > [Example Network A, sect 3.3] >=20 > - ISP does not offer IPv6 service. > - Private Leased Lines no Service Provider Used >=20 > =3D=3D> is the first really often the case? If you're a suffiently = big > enterprise, I think at least in Europe there are already quite a few ISPs > willing to give you service. (note: s/ISP does/ISPs do/ .. as it has > multiple ISPs?) >=20 [YP] yes it is the case. We have a lot of enterprises out there which are far behind with regard to internet revolution. > =3D=3D> I don't quite understand the second bullet point? do you mean that > the > site has just one ISP, and the rest are connected using leased lines to > the > "primary" ISP, and they don't have a direct connectivity at all? >=20 > I'm not sure if this is any longer the "mainstream" scenario, because the > net traffic is probably so high that the enterprises don't want to pay > $$$$ > for transporting all their traffic to their HQ using leased lines, but to > throw it out to their ISP immediately (and tunnel internal traffic with > VPNs, or leased lines). >=20 [YP] I don't agree. Yes this is a cost issue hence why they are looking at deploying IPv6 as a replacement solution. > - All routers and switches are upgradeable to IPv6. > - Existing firewalls can be upgraded to support IPv6 rules. >=20 > =3D=3D> are these mainstream scenarios? What does a switch's IPv6 = upgrade > mean > (is it L3 switch? or management functions?) >=20 > - IPv4 Private address space is used within the enterprise. >=20 > =3D=3D> the enterprise already had PI space (from the above), but = still uses > private address space internally -- any particular reason why? >=20 > DNS will now have to support both IPv4 and IPv6 DNS records and the > enterprise will need to determine how the DNS is to be managed and > accessed, and secured. The range of DNS operational issues are out > of scope for this work. [...] >=20 > =3D=3D> here, it would be good to refer to > draft-ietf-dnsop-ipv6-dns-issues-07.txt, and possibly add at the end > something like: >=20 [YP] ok > These operations include at least: > - configuring IPv6 DNS servers as resolvers on IPv6(-only) hosts, > - selecting a method to insert AAAA/PTR records in the DNS, > - managing the DDNS reverse/forward updates processes, if used, > - providing IPv6 transport capability in the recursive internal > DNS servers, and > - managing the IPv6 capability in the authoritative servers, and > configuring the AAAA records at the delegator of the DNS zones. >=20 > .... >=20 > The choice of interior routing protocols have an impact on how the > routing tables will be handled: some such as OSPF will have the > ships-in-the-night paradigm, others such as ISIS are integrated. This > has an impact on the topology and the management of the network. >=20 > =3D=3D> I don't really understand what you mean with the sentence = about OSPF > vs > ISIS. Do you mean that w/ OSPF you'd use separately OSPFv2 and OSPFv3, > and with IS-IS just one process? >=20 > Note that this discussion could probably be just a summary of > draft-ietf-v6ops-isp-scenarios-analysis-02.txt section 4.3.1 and the > Appendix A. (We should refer to that document here at least.) >=20 > IPv6 capable routers should be monitored to ensure the router has > sufficient storage for both IPv6 and IPv4 route tables. Existing > network design principles to limit the number of routes in the > network, such as prefix aggregation, become more critical with the > addition of IPv6 to an existing IPv4 network. >=20 > =3D=3D> I do not think monitoring the routers for sufficient v4/v6 = route > table storage is an operationally important issue, clearly not more son > than > monitoring v4 route tables today, at least. Maybe just remove this first > sentence or even the whole paragraph. >=20 [YP] Exactly the point is you need to do the same. I think we should keep the paragraph as is. > =3D=3D> maybe add at the end add something like: >=20 > Decisions wrt. routing include at least: > - whether IPv4 and IPv6 routing topologies will be different, > affecting the decision on which routing protocols to use, > - how redundancy is ensured if tunneling is used, and > - which tools are to be used to monitor the IPv6 infrastructure. >=20 [YP] ok > 5.3 Autoconfiguration >=20 > IPv6 introduces the concept of stateless autoconfiguration in > addition to stateful autoconfiguration. The enterprise will have to > determine the best method of autoconfiguration, for their network. > The enterprise will need to determine if they are to use stateless or > stateful autoconfiguration, and how autoconfiguration is to operate > for DNS updates. The enterprise will need to determine how prefix > delegation is done from their upstream provider and how those > prefixes are cascaded down to the enterprise IPv6 network. The > policy for DNS or choice of autoconfiguration is out of scope for > this document. >=20 > =3D=3D> this section should probably be generalized to be something = like > 'Configuration of Hosts [or: .. of Infrastructure and Hosts]' > (and generalize the autoconfiguration a bit more > in the rest of the paragraph as well) [YP] ok > =3D=3D> remove ", for their network", as everything is done for their network > in > any case. > =3D=3D> dynamic prefix delegation inside the enterprise may not be a really > feasible option, but in any case, I'd probably add something like: > "; the choices are to do this manually, or using a dynamic protocol" > to better spell it out. > =3D=3D> One might consider adding at the end something on whether an = asset > management database is being used, and the choices for configuring other > information on the hosts (e.g., DNS servers, proxy servers, etc.etc.). >=20 [YP] We will try to rework this > 5.4 Security >=20 > Current existing mechanisms used for IPv4 to provide security need to > be supported for IPv6 within the enterprise. IPv6 should create no > * new security concerns for IPv4. The entire security infrastructure > * currently used in the enterprise needs to be analyzed against IPv6 > * deployment effect and determine what is supported in IPv6. Users > should review other security IPv6 network infrastructure work in the > * IETF and within the industry on going at this time. Users will have > * to work with their platform and software providers to determine what > * IPv6 security network infrastructure components are supported. The > security filters and firewall requirments for IPv6 need to be > determined by the enterprise. The policy choice of users for security > is out of scope for this document. >=20 > =3D=3D> there is considerable overlap with two sentences above, marked with > '*'. > I suggest removing one of them and expanding the other slightly. >=20 > =3D=3D> you should probably refer to some security documents here, = e.g., > draft-savola-v6ops-security-overview-02.txt >=20 > =3D=3D> add at the end maybe something like: >=20 > At the very least, one has to consider for example: > - whether the same access control/IDS policies are to be used for > IPv6 as with IPv4, and whether these are to be handled by the > same or different equipment/software, > - how keying and/or certificates are managed, > - how VPNs are controlled, > - whether RFC3041 temporary addresses are to be used and to > what extent if so, > - whether there are to be internal access control points, and > - if tunneling techniques are used, how this affects the site > security, and how site must be secured to make tunneling secure. >=20 [YP] ok > 5.6 Network Management >=20 >=20 > The addition of IPv6 network infrastructure components will need to > be managed by the enterprise network operations center. Users will > need to work with their network management platform providers to > determine what for IPv6 is supported during their planning for IPv6 > adoption, and what tools are available in the market to monitor the > network. >=20 > =3D=3D> remove 'in the market' -- appears redundant here? > =3D=3D> maybe add something like: >=20 > At least, one should consider: > - whether IPv6-capable devices can be managed or monitored using > IPv4, and what must be done if that is not possible, and > - how IPv6 infrastructures are being monitored? >=20 >=20 > 5.7 Address Planning >=20 > The address space within the enterprise will need to be defined and > coordinated with the routing topology of the enterprise network. It > is also important to identify the pool of IPv4 address space > available to the enterprise to assist with IPv6 transition methods. >=20 > =3D=3D> I don't think the "pool of IPv4 address space" is all that > relevant consideration here, as it hints at the use of IPv6-only > infrastructures, NAT-PT, and the like. [YP] don't agree. The availability of IPv4 address space will trigger the choice of deployment techniques. It is very relevant. > =3D=3D> in any case, I think there is one thing that should be = explicitly > called > out: Whether the site wants to consider whether this new kind of local > addressing is used for v6 or not. >=20 [YP] ok > For inter-domain use, sites may choose to migrate IPv4 multicast > applications to SSM, for which no reverse path discovery method is > required. >=20 > =3D=3D> ", for ..." part is incorrect and out of context, replace with > something > like: ", which simplifies the multicast architecture, but requires that > the > applications specify the multicast transmission source(s). >=20 > =3D=3D> Maybe add a new paragraph: >=20 > The enterprises also need to consider whether IGMP/MLD snooping or > similar solutions to reduce the multicast flooding is > required: this may be especially important if the subnets are large, > or multicast is used extensively. >=20 > 5.9 Multihoming >=20 >=20 > At this time, current IPv6 allocation policies are mandating the > allocation of IPv6 address space from the upstream provider. If an > enterprise is multihomed, the enterprise will have to determine how > they wish to support multihoming. This also is an area of study > within the IETF and work in progress. >=20 > =3D=3D> I think it would be appropriate to describe RFC3178 model of > multihoming > very briefly, e.g., like in section 5.6 in > draft-ietf-v6ops-isp-scenarios-analysis-02.txt >=20 [YP] ok > 7. References > 7.1 Normative References >=20 > None at this time. > [...] >=20 > =3D=3D> please add a lot more explicit informative / normative = references to > the > subject which were discussed. >=20 [YP] ok >=20 >=20 > semi-editorial > -------------- >=20 > [Scenario 2 in sect 3.1] > Scenario 2: Enterprise with an existing IPv4 network wants to deploy a > set of particular IPv6 "applications" (application is > voluntarily loosely defined here, e.g. peer to peer). > The IPv6 deployment is limited to the minimum required to > operate this set of applications. >=20 > =3D=3D> I don't think it's good to say "minimum" here, because there = is no > reason to restrict it to the absolute minimum required. The point here is > just that v6 deployment doesn't need to be _larger_ than required to > operate > the set of applications. >=20 > Maybe reword: s/is limited to/does not need to be more extensive than/ >=20 [YP] ok > editorial > --------- >=20 > IPv6 Enterprise Network Scenarios >=20 > =3D=3D> maybe rename to something like 'Enterprise Networks IPv6 Transition > Scenarios' to be more in line with the rest of the document? >=20 > Enterprise Network - A network that has multiple internal links, > one or more router connections, to one or > more > Providers and is actively managed by a > network > operations entity. >=20 > =3D=3D> align the text for those lines which were broken to multiple = lines > by originally too many chars/line? (same also later) >=20 > Provider - An entity that provides services and > connectivity to the Internet or > other private external networks for the > enterprise network. >=20 > =3D=3D> isn't 'Provider' a slightly too terse (and ambiguous) term? > Maybe 'Service Provider' or abbreviated SP if necessary, instead? >=20 > IPv6 only - A node or network capable of supporting only > IPv6. This does not imply an IPv6 only > stack, in this document. >=20 > =3D=3D> the last sentence should probably be reworded to be clearer. = Did you > mean something like: > In the context of this document, a > dual-stack node which has disabled IPv4 is > considered IPv6 only. >=20 > 3.2 Scenarios Network Infrastructure Components >=20 > =3D=3D> reword to: 'Network Infrastructure Components for Scenarios' ? >=20 > - Are the nodes moving within the enterprise network? > - Are the nodes moving outside and inside the enterprise > network? >=20 > =3D=3D> these should probably be shifted left about 3-4 spaces? >=20 > - The DHCP server to update naming records for dynamic desktops > uses >=20 > =3D=3D> reword maybe to: >=20 > - The DHCP server updates the DNS records for dynamic desktops > with DDNS. >=20 > Document Acknowledgments >=20 > =3D=3D> s/Document // >=20 > Authors-Design Team Contact Information >=20 > =3D=3D> maybe reword to "Authors' Addresses" as it's the regular = format? >=20 > =3D=3D> this is pretty long. Two possibilities to summarize this a = bit: > a) add an "Editor's Address" section, with just Jim's contact info, in > full; Keep "Authors' Addresses" section for the rest, but mention only > names, affiliations and the email addresses. > b) just take out other info for the non-editors as names, affiliations > and > email addresses. >=20 >=20 > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 Thanks Yanick From owner-v6ops@ops.ietf.org Mon May 24 21:50: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 VAA22081 for ; Mon, 24 May 2004 21:50:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSR1k-000J8O-7H for v6ops-data@psg.com; Tue, 25 May 2004 01:46:48 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSR1g-000J6y-Lh for v6ops@ops.ietf.org; Tue, 25 May 2004 01:46:44 +0000 Received: (qmail 695 invoked from network); 25 May 2004 01:32:21 -0000 Received: from unknown (HELO wxg) (159.226.39.69) by mail.ict.ac.cn with SMTP; 25 May 2004 01:32:21 -0000 Message-ID: <000a01c441fa$918af910$4527e29f@wxg> From: "Eiffel Wu" To: Cc: , , Subject: RE: Teredo vs Silkroad Date: Tue, 25 May 2004 09:49:51 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C4423D.9F9FE130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00, FORGED_OUTLOOK_TAGS,MIME_BASE64_TEXT,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C4423D.9F9FE130 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo+VGhlIHdob2xlIGxpZmV0aW1lIGRpc2N1c3Npb24gaXMgY29uZnVzZWQuIEFsbCBwcmVmaXhl cyB3aWxsIGhhdmUgYQ0KPmxpZmV0aW1lLCBpdCBtYXkgYmUgdmVyeSBsb25nLCBidXQgaXQgd2ls bCBiZSB0aGVyZS4gQW55IGRpc2N1c3Npb24gYWJvdXQNCj4ncGVybWFuZW50JyBvbmx5IGludml0 ZXMgcGVvcGxlIHRvIGJlbGlldmUgdGhlIHByZWZpeCB3aWxsIG1vdmUgd2l0aCB0aGVtDQo+d2hl biB0aGV5IGxlYXZlIFNsaWtyb2FkIGJlaGluZCwgYnV0IHRoYXQgY2FuJ3QgaGFwcGVuIGlmIHRo ZSBwcmVmaXggaXMgcGFydA0KPm9mIHRoZSBTQVIgYWdncmVnYXRlLiANCg0KInBlcm1hbmVudCIg bWVhbnMgdGhhdCB0aGUgU0MgY2FuIGdldCB0aGUgc2FtZSBJUHY2IGFkZHJlc3MgYXMgb25lIHVz ZWQgaW4gbGFzdCB0aW1lLg0KQWRkcmVzcyBvZiBTQyB3aWxsIG5vdCBjaGFuZ2UsIGV4Y2VwdCB0 aGUgdXNlcnMgd2FudCB0byBhIHJhbmRvbSBhZGRyZXNzIGJlY2F1c2UNCm9mIHNlY3VyaXR5IGlz c3VlLiANCkFzIGEgY29tcGFyaXNvbiwgVGVyZWRvIGFkZHJlc3MgY29uc2lzdHMgb2YgY2xpbmV0 IGlwdjQgYWRkcmVzcyBhbmQgdWRwIHBvcnQsIHdoaWNoDQptdXN0IGJlIGRpZmZlcmVudCB3aXRo IGxhc3Qgb25lLiBIb3cgY2FuIFRlcmVkbyBDbGllbnQgYmUgZm91bmQgaWYgdGhlcmUgaXMgbm8g DQphcHByb3ByaWF0ZSBuYW1pbmcgc2VydmljZSA/IFRlcmVkbyBkb2VzIG5vdCBwcm92aWRlIHN1 Y2ggYSBuYW1pbmcgc2VydmljZS4NCg0KDQo+SW4gc2hvcnQgU2lsa3JvYWQgaXMgbm90aGluZyBt b3JlIHRoYW4gdHJ5aW5nIHRvIHByb3ZpZGUgYSBzY2FsaW5nIGZyb250IGVuZA0KPmZvciB0aGUg Zm9yd2FyZGluZyBmdW5jdGlvbiBvZiB0aGUgdHVubmVsIGJyb2tlciBtb2RlbC4gV2hpbGUgdGhh dCBmdW5jdGlvbg0KPmlzIGFuIGFkbWlyYWJsZSBnb2FsLCB0aGlzIHNwZWMgd2lsbCBuZWVkIG1h am9yIHJld29yayBiZWZvcmUgaXQgZXZlbiBjb21lcw0KPmNsb3NlIHRvIHNvbWV0aGluZyB0aGF0 IGlzIG9wZXJhdGlvbmFsbHkgZGVwbG95YWJsZS4gQSByZWFzb25hYmxlIHRydXN0DQo+bW9kZWwg YW5kIGZ1bGx5IGR5bmFtaWMgcm91dGluZyB1cGRhdGUgc3lzdGVtIGFyZSB0aGUgZmlyc3Qgc3Rl cHMuIEluIGFueQ0KPmNhc2UgU2lsa3JvYWQgc2hvdWxkIG5vdCBiZSBjb21wYXJlZCB0byBUZXJl ZG8gYmVjYXVzZSBpdCBpcyBmdW5kYW1lbnRhbGx5IGENCj50dW5uZWwgYnJva2VyIChhbGJlaXQg YSBicm9rZW4gb25lIGluIHRoZSBjdXJyZW50IHNwZWMpIHNvIHNlY3Rpb24gNy40DQo+c2hvdWxk IHNpbXBseSBiZSByZW1vdmVkLiANCg0KSSBoYXZlIHRvbGQgdGhhdCBTaWxrcm9hZCBpcyBhIHR1 bm5lbCBicm9rZXIgc2ltaWxhciBtZWNoYW5pc20uIEl0IGhhcyB0aGUgc2FtZSBnb2FsIA0KYnV0 IGRpZmZlcmVudCB3YXkgYXMgVGVyZWRvIGhhcy4gSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBhIHR1 bm5lbCBicm9rZXIgc2ltaWxhciANCm1lY2hhbmlzbSBzaG91bGQgbm90IGJlIGNvbXBhcmVkIHRv IFRlcmVkby4NCg0KRWlmZmVsIFd1DQoNCg0K ------=_NextPart_000_0007_01C4423D.9F9FE130 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+PEZPTlQgc2l6ZT0yPg0KPERJVj48QlI+Jmd0O1RoZSB3aG9s ZSBsaWZldGltZSBkaXNjdXNzaW9uIGlzIGNvbmZ1c2VkLiBBbGwgcHJlZml4ZXMgd2lsbCBoYXZl IA0KYTxCUj4mZ3Q7bGlmZXRpbWUsIGl0IG1heSBiZSB2ZXJ5IGxvbmcsIGJ1dCBpdCB3aWxsIGJl IHRoZXJlLiBBbnkgZGlzY3Vzc2lvbiANCmFib3V0PEJSPiZndDsncGVybWFuZW50JyBvbmx5IGlu dml0ZXMgcGVvcGxlIHRvIGJlbGlldmUgdGhlIHByZWZpeCB3aWxsIG1vdmUgDQp3aXRoIHRoZW08 QlI+Jmd0O3doZW4gdGhleSBsZWF2ZSBTbGlrcm9hZCBiZWhpbmQsIGJ1dCB0aGF0IGNhbid0IGhh cHBlbiBpZiB0aGUgDQpwcmVmaXggaXMgcGFydDxCUj4mZ3Q7b2YgdGhlIFNBUiBhZ2dyZWdhdGUu IDxCUj48L0RJVj4NCjxESVY+InBlcm1hbmVudCIgbWVhbnMgdGhhdCB0aGUgU0MgY2FuIGdldCB0 aGUgc2FtZSBJUHY2IGFkZHJlc3MgYXMmbmJzcDtvbmUgDQp1c2VkIGluIGxhc3QgdGltZS48L0RJ Vj4NCjxESVY+QWRkcmVzcyBvZiBTQyB3aWxsIG5vdCBjaGFuZ2UsIGV4Y2VwdCB0aGUgdXNlcnMg d2FudCB0byBhIHJhbmRvbSBhZGRyZXNzIA0KYmVjYXVzZTwvRElWPg0KPERJVj5vZiBzZWN1cml0 eSBpc3N1ZS4gPC9ESVY+DQo8RElWPkFzIGEgY29tcGFyaXNvbiwgVGVyZWRvIGFkZHJlc3MgY29u c2lzdHMgb2YgY2xpbmV0IGlwdjQgYWRkcmVzcyBhbmQgdWRwIA0KcG9ydCwgd2hpY2g8L0RJVj4N CjxESVY+bXVzdCBiZSBkaWZmZXJlbnQgd2l0aCBsYXN0IG9uZS4gSG93IGNhbiBUZXJlZG8gQ2xp ZW50IGJlIGZvdW5kIGlmIHRoZXJlIGlzIA0Kbm8gPC9ESVY+DQo8RElWPmFwcHJvcHJpYXRlIG5h bWluZyBzZXJ2aWNlID8gVGVyZWRvIGRvZXMgbm90IHByb3ZpZGUgc3VjaCBhIG5hbWluZyANCnNl cnZpY2UuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48QlI+Jmd0O0luIHNob3J0IFNp bGtyb2FkIGlzIG5vdGhpbmcgbW9yZSB0aGFuIHRyeWluZyB0byBwcm92aWRlIGEgc2NhbGluZyAN CmZyb250IGVuZDxCUj4mZ3Q7Zm9yIHRoZSBmb3J3YXJkaW5nIGZ1bmN0aW9uIG9mIHRoZSB0dW5u ZWwgYnJva2VyIG1vZGVsLiBXaGlsZSANCnRoYXQgZnVuY3Rpb248QlI+Jmd0O2lzIGFuIGFkbWly YWJsZSBnb2FsLCB0aGlzIHNwZWMgd2lsbCBuZWVkIG1ham9yIHJld29yayANCmJlZm9yZSBpdCBl dmVuIGNvbWVzPEJSPiZndDtjbG9zZSB0byBzb21ldGhpbmcgdGhhdCBpcyBvcGVyYXRpb25hbGx5 IGRlcGxveWFibGUuIA0KQSByZWFzb25hYmxlIHRydXN0PEJSPiZndDttb2RlbCBhbmQgZnVsbHkg ZHluYW1pYyByb3V0aW5nIHVwZGF0ZSBzeXN0ZW0gYXJlIHRoZSANCmZpcnN0IHN0ZXBzLiBJbiBh bnk8QlI+Jmd0O2Nhc2UgU2lsa3JvYWQgc2hvdWxkIG5vdCBiZSBjb21wYXJlZCB0byBUZXJlZG8g DQpiZWNhdXNlIGl0IGlzIGZ1bmRhbWVudGFsbHkgYTxCUj4mZ3Q7dHVubmVsIGJyb2tlciAoYWxi ZWl0IGEgYnJva2VuIG9uZSBpbiB0aGUgDQpjdXJyZW50IHNwZWMpIHNvIHNlY3Rpb24gNy40PEJS PiZndDtzaG91bGQgc2ltcGx5IGJlIHJlbW92ZWQuIDxCUj48L0RJVj4NCjxESVY+SSBoYXZlIHRv bGQgdGhhdCBTaWxrcm9hZCBpcyBhIHR1bm5lbCBicm9rZXIgc2ltaWxhciBtZWNoYW5pc20uIEl0 IGhhcyB0aGUgDQpzYW1lIGdvYWwgPC9ESVY+DQo8RElWPmJ1dCBkaWZmZXJlbnQgd2F5IGFzIFRl cmVkbyBoYXMuIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkmbmJzcDthIHR1bm5lbCANCmJyb2tlciBz aW1pbGFyIDwvRElWPg0KPERJVj5tZWNoYW5pc20mbmJzcDtzaG91bGQgbm90IGJlIGNvbXBhcmVk IHRvIFRlcmVkby48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkVpZmZlbCBXdTwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW PjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0007_01C4423D.9F9FE130-- From owner-v6ops@ops.ietf.org Tue May 25 01:46: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 BAA02140 for ; Tue, 25 May 2004 01:46:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSUiu-000JEm-Ro for v6ops-data@psg.com; Tue, 25 May 2004 05:43:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSUit-000JDn-9A for v6ops@ops.ietf.org; Tue, 25 May 2004 05:43:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4P5hH712268; Tue, 25 May 2004 08:43:17 +0300 Date: Tue, 25 May 2004 08:43:17 +0300 (EEST) From: Pekka Savola To: Jonne Soininen cc: Tim Chown , Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt In-Reply-To: <1085429789.4626.51.camel@localhost.localdomain> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 24 May 2004, Jonne Soininen wrote: > these are scenarios and the scenarios should describe the possible > scenarios that do make technically sense and hence, are possible to > be deployed. I do not see why not all of the scenarios would not > make sense. Enumerating the possibilities is of course fine. I was mainly objecting to Tim's wording: If section 4 were removed a requirement subsection would be needed in section 5 to state that legacy interworking **is required** for four main modes: (emphasis mine) s/is required/needs to be considered/ (for example) and it would be fine by me.. > On Mon, 2004-05-24 at 15:29, ext Pekka Savola wrote: > > On Wed, 12 May 2004, Tim Chown wrote: > > > I believe this is ready. > > > > > > Alain's point is valid, but I don't believe changes would impact the > > > usefulness of the draft as is. If section 4 were removed a requirement > > > subsection would be needed in section 5 to state that legacy interworking > > > is required for four main modes: > > > > > > a) dual-stack <-> v4 or v6 only > > > b) v4 only <-> v6 only > > > c) v4 <-> v4 over v6 infrastructure > > > d) v6 <-> v6 over v4 infrastructure > > > > Isn't this a list of all the possible combinations? > > > > The point here is, do we need to care for all of these combinations? > > For example, in the unmanaged networks, b) was considered out of > > scope, and that's also recommended against in the 3GPP. c) is also > > something that I'm not sure there is yet consensus whether this is a > > reasonable approach at this point. > > > > One goal of the scenarios/analysis work is to try to identify the > > actual, critical, mainstream scenarios which call of certain kind of > > interworking or mechanisms. I think at least a) or d) fulfill these > > criteria, but b) and c) might be so-and-so, depending on how you > > phrase it and which kind of techniques one might have in mind > > applying.. > > > > > On Wed, May 12, 2004 at 06:20:11PM +0300, Jonne Soininen wrote: > > > > Hi everybody, > > > > > > > > this is a WG Last Call for comments on sending > > > > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network > > > > Scenarios" to the IESG for consideration as Informational: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt > > > > > > > > > > > > Please review these documents, and send your feedback to the > > > > list. Please also indicate whether or not you believe that this > > > > document is ready to go to the IESG. > > > > > > > > The last call will end in two weeks, on May 26th. > > > > > > > > Pekka & Jonne > > > > > > > > > > > > -- 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-v6ops@ops.ietf.org Tue May 25 02:11: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 CAA14505 for ; Tue, 25 May 2004 02:11:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSV8b-0002EG-1E for v6ops-data@psg.com; Tue, 25 May 2004 06:10:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSV8Y-0002Ct-DF for v6ops@ops.ietf.org; Tue, 25 May 2004 06:10:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4P69q612726; Tue, 25 May 2004 09:09:52 +0300 Date: Tue, 25 May 2004 09:09:52 +0300 (EEST) From: Pekka Savola To: "Pouffary, Yanick" cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt In-Reply-To: <06CAA4D3753C53408D2CE6340B68444205A593F1@vbeexc02.emea.cpqcorp.net> 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.8 required=5.0 tests=AWL,BAYES_00,CASHCASHCASH autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 24 May 2004, Pouffary, Yanick wrote: > Thanks for the review. Comments in-line. A few remainders inline.. One thing I forgot in the review: Network Infrastructure Component 3 -- What network operations software will be impacted by IPv6? should probably also include 'Backup/restore software(s) used' (or something like that). At least in our enterprise, we're using a network-based backup software which cannot be proxied/translated, and if we want to do backups, we'd stuck with IPv4.. It might be good to raise this out explicitly in case this would turn out the be a issue. Another possible consideration in the same category would be file-sharing (NFS, CIFS, etc.) from centralized file servers to other servers, if that's being done. > > I think Example network C, a security defense network, is not > > mainstream enough to be applicable to be investigated in the > > scenarios. There are probably 1, 5 or 10 such networks in the world. > > We should be focusing on more common scenarios (even addressing > > "80/20" would be good). [I have a few specific comments for > > clarification within this example, but I'll send them if this example > > is not replaced by something else.] > > > > [YP] I agree with Richard Graveman to keep this example. Please send > you're your comments. will do in a separate message. > > - Are ALGs or proxies being used for some applications? > > Would using such be feasible? > > - Are there applications which cannot be proxied or > > upgraded to support IPv6? > > [YP] I think we have this already covered. I'm not sure if I see that. I think there are two related, more generic points: - Can the application be upgraded to IPv6? - Do the applications have issues with NAT v4-v4 and NAT v4-v6? .. but these (IMHO) may not spell it out sufficiently to the reader. In the end, I think the the two points I proposed are good, because: a) it raises the question whether proxies are already being used, or whether using them would be feasible. If that's the case, application transition is significantly easier, as one can interoperate between v4 and v6 using the proxies (if the enterprise network's goal is to move predominatly to v6). b) the second raises the question about the "remainder apps" for which some other, more difficult strategy must be considered. It would be good if the enterprises would have to map these themselves.. > > - Is inter-site communications required? > > > > ==> I don't quite understand this requirement, because I fail to see > _any_ > > scenario where you wouldn't need to communicate between sites? Could > you > > clarify? > > > > [YP] The enterprise may want to deploy IPv6 within a single site. Oh ok -- maybe reword to something like: "Would IPv6 be deployed on multiple geographical sites?" or the like ? > > ... > > > > - What will be the IPv6 Security policy/procedure? > > > > ==> there should probably be a bit more on this..? maybe at least > like: > > > > - Are separate or same firewalls, IDS systems, etc. used for > IPv6? > > Which part of the traffic is encrypted using IPsec and how? > > > > [YP] your clarifications are useful but do we need to be that specific? That's a good question. My interpretation of the current list is that it's purpose is to wake up the thinking process of the enterprise managers and/or transition planners. If the points are generic, it may be that these wouldn't spark thoughts. On the other hand, if one could go through the list similar to a "checklist", it would be easier not to forget anything important. In that light, it would probably be useful to add "pointers" triggering the people to think about the details.. as long as it doesn't get too detailed. > > [Example Network A, sect 3.3] > > > > - ISP does not offer IPv6 service. > > - Private Leased Lines no Service Provider Used > > > > ==> is the first really often the case? If you're a suffiently big > > enterprise, I think at least in Europe there are already quite a few > ISPs > > willing to give you service. (note: s/ISP does/ISPs do/ .. as it has > > multiple ISPs?) > > [YP] yes it is the case. We have a lot of enterprises out there which > are far behind with regard to internet revolution. OK.. I guess such enterprises will be out of luck wrt. external IPv6 connectivity unless an ISP in their area is willing to provide it. (IMHO, using e.g. 6to4 to get connectivity is not good enough for enterprises.) > > ==> I don't quite understand the second bullet point? do you mean > that > > the > > site has just one ISP, and the rest are connected using leased lines > to > > the > > "primary" ISP, and they don't have a direct connectivity at all? > > > > I'm not sure if this is any longer the "mainstream" scenario, because > the > > net traffic is probably so high that the enterprises don't want to pay > > $$$$ > > for transporting all their traffic to their HQ using leased lines, but > to > > throw it out to their ISP immediately (and tunnel internal traffic > with > > VPNs, or leased lines). > > [YP] I don't agree. Yes this is a cost issue hence why they are looking > at deploying IPv6 as a replacement solution. I'm not sure if I understood your point. Did you mean ("replacement solution") that by deploying IPv6, they'd also get rid of the leased lines, or start doing VPNs, etc. ? > > IPv6 capable routers should be monitored to ensure the router has > > sufficient storage for both IPv6 and IPv4 route tables. Existing > > network design principles to limit the number of routes in the > > network, such as prefix aggregation, become more critical with the > > addition of IPv6 to an existing IPv4 network. > > > > ==> I do not think monitoring the routers for sufficient v4/v6 route > > table storage is an operationally important issue, clearly not more > son > > than > > monitoring v4 route tables today, at least. Maybe just remove this > first > > sentence or even the whole paragraph. > > [YP] Exactly the point is you need to do the same. I think we should > keep the paragraph as is. OK -- but I think the paragraph should make it clearer that this is not an IPv6-specific issue; in other words: If the enterprise is already doing it, they're encouraged to keep doing it. If they aren't doing it, there's no strong incentive to start doing it now. > > 5.7 Address Planning > > > > The address space within the enterprise will need to be defined and > > coordinated with the routing topology of the enterprise network. > It > > is also important to identify the pool of IPv4 address space > > available to the enterprise to assist with IPv6 transition methods. > > > > ==> I don't think the "pool of IPv4 address space" is all that > > relevant consideration here, as it hints at the use of IPv6-only > > infrastructures, NAT-PT, and the like. > > [YP] don't agree. The availability of IPv4 address space will trigger > the choice of deployment techniques. It is very relevant. I don't dispute the availability of IPv4 address space, but IPv4 address space dedicated to transition methods :). So maybe this: It is also important to identify the pool of IPv4 address space available to the enterprise to assist with IPv6 transition methods. could be reworded to something like: The amount of available and used public IPv4 addresses is an important factor when considering the deployment techniques. -- 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-v6ops@ops.ietf.org Tue May 25 02:29: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 CAA17655 for ; Tue, 25 May 2004 02:29:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSVPh-0008to-K6 for v6ops-data@psg.com; Tue, 25 May 2004 06:27:49 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSVPe-0008tH-Rx for v6ops@ops.ietf.org; Tue, 25 May 2004 06:27:46 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 23:27:46 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 24 May 2004 23:27:41 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 May 2004 23:27:45 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 23:27:46 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 23:27:56 -0700 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, 24 May 2004 23:28:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Teredo vs Silkroad Date: Mon, 24 May 2004 23:27:43 -0700 Message-ID: Thread-Topic: Teredo vs Silkroad Thread-Index: AcRB+jJkLiofTWDCSHe8jqNvm4XJwgAJkpJA From: "Christian Huitema" To: "Eiffel Wu" , Cc: , X-OriginalArrivalTime: 25 May 2004 06:28:15.0382 (UTC) FILETIME=[75F8F360:01C44221] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > As a comparison, Teredo address consists of clinet ipv4 address and udp=20 > port, which must be different with last one. How can Teredo Client be > found if there is no appropriate naming service ? Teredo does not=20 > provide such a naming service. Yes, this is a trade-off. The advantage of building the IPv6 address from the IPv4 address is that you don't need strong security to prevent spoofing: you just need to make sure that packets are routed to the embedded IPv4 address. If you make the IPv6 address independent of the underlying IPv4 address the address may become long-lived, but the tunnel servers must implement a strong security procedure to make sure that the address is not spoofed. Then, as you mention, if the address is not long-lived, you need some form of name resolution to associate the short lived address with a long-lived name. There are some obvious choices: dynamic DNS or SIP, for example. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue May 25 02:30: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 CAA17716 for ; Tue, 25 May 2004 02:30:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSVRX-0009Hb-Qv for v6ops-data@psg.com; Tue, 25 May 2004 06:29:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSVRW-0009H0-Ge for v6ops@ops.ietf.org; Tue, 25 May 2004 06:29:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4P6TSG13035; Tue, 25 May 2004 09:29:29 +0300 Date: Tue, 25 May 2004 09:29:28 +0300 (EEST) From: Pekka Savola To: rfgraveman@nac.net cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt In-Reply-To: <33639.67.84.243.204.1085403691.squirrel@webmail.nac.net> 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 24 May 2004 rfgraveman@nac.net wrote: > > I think Example network C, a security defense network, is not > > mainstream enough to be applicable to be investigated in the > > scenarios. There are probably 1, 5 or 10 such networks in the world. > > We should be focusing on more common scenarios (even addressing > > "80/20" would be good). [I have a few specific comments for > > clarification within this example, but I'll send them if this example > > is not replaced by something else.] > > ... > > OTOH, some of these networks are large, and they buy a lot of equipment, > so some major vendors take their requirements quite seriously. Therefore, > I would be against dropping this case. We can discuss further whether this > is exactly the right characterization, however. I can see the argument why this needs to be considered .. money is a language everybody understands .. but I'm concerned that this would be painted as a "model" for v6 deployment, i.e., that other enterprises which have very little in common with such defense networks would start mimicking their deployment strategies just because those are the ones described in our documents. This is why I'm worried about keeping this here. But let's hear if there are more opinions about this. In any case, if it stays, this could probably be clarified a bit, like: A Security Defense Network Operation: ==> add here something like: Note that these kind of networks are uncommon and unfit to be a model or example for deployment for enterprises in general. However, due to their importance to the vendor community, their requirements should be considered explicitly. ... - External network required at secure specific points. ==> I had hard time parsing this, "at secure"? Did you mean: - External network is required, but only at specific, secure, exit points. ... - Network must be able to absorb ad-hoc creation of sub-Networks. ==> I didn't quite understand what this meant, please clarify. (I've a hunch, but..) - Entire parts of the Network are completely mobile. ==> are we talking about a mobile network (NEMO sense), or nomadic network (network de-attaches, moves, network re-attaches) ? The latter would at least be feasible, while the former may be a bit more problematic. Maybe worth clarifying a bit.. - Network must be able to bolt on to the Internet to share bandwidth as required from Providers. ==> "bolt on to the Internet" ? I wasn't sure what this was trying to say -- that the network must be able to multihome for load-sharing purposes, or...? - Nodes must be able to access IPv4 legacy applications over IPv6 network. ==> are these internal legacy apps, external ones, or possibly both? Isn't this assumptive about IPv6 deployment ("v6-only") and unfit for requirements? -- 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-v6ops@ops.ietf.org Tue May 25 02:56: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 CAA19145 for ; Tue, 25 May 2004 02:56:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSVph-000FeC-F1 for v6ops-data@psg.com; Tue, 25 May 2004 06:54:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSVpf-000Fdo-Nh for v6ops@ops.ietf.org; Tue, 25 May 2004 06:54:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4P6sYe13350; Tue, 25 May 2004 09:54:34 +0300 Date: Tue, 25 May 2004 09:54:34 +0300 (EEST) From: Pekka Savola To: js.jason.lin@foxconn.com cc: v6ops@ops.ietf.org Subject: Re: Developing IP version-independent Applications 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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Unless I hear otherwise shortly, I'm suggesting we address your comments by adding a new paragraph after the 1st in section 4.4: The most important case is the application support on systems where IPv6 support can be dynamically enabled or disabled by the users. Applications on such a system should be able to able to handle the situation where IPv6 would not be enabled. The secondary scenario is when an application could be deployed on older systems which do not support IPv6 at all (even the basic getaddrinfo etc. APIs). In that case the application designer has to make a case-by-case judgement call whether it makes sense to have compile-time toggle between an older and newer API (having to support both in the code), or whether to provide getaddrinfo etc. function support on older platforms as part of the application libraries. .. would this satisfy your concerns, Jason? On Fri, 21 May 2004, Pekka Savola wrote: > (I waited for other comments, but they didn't appear :) > On Mon, 17 May 2004 js.jason.lin@foxconn.com wrote: > > On Sat, 15 May 2004 js.jason.lin@foxconn.com wrote: > > This allows eliminating the compile-time special casing from the code, > > making the code simpler. > > > > > > I am not sure whether most IPv4-only really support such getaddrinfo > > or getnameinfo > > API. But I am afraid to add a version of getaddrinfo/getnameinfo into > > applications can be much > > complicated than using conditional compilation. > > <> > > Depends a lot on how the code is designed. If you create your own > network connectivity manipulation functions, it should be quite easy > to make them conditional. If you don't, you'll have to sprinkle > conditional conditions all over your code. And that's a pain to > maintain as well. > > There's no winner or loser here. I'm familiar with some open-source > projects; most use only getaddrinfo and provide background > compatibility code as appropriate. Some others provide conditionally > either at compile time. > > It's a judgement call for the developer, and I'm not sure whether this > needs text in this document. It might be good to spell it out. Do > you have text suggestions? > > > Further, the IPv4-only operation is most important in practice for > > nodes which already would be able to support IPv6, but the support is > > turned off. The applications should continue to work under those > > circumstances. > > > > > > I think this is really a good reason for "version-independent" > > programming. > > In embedded system, whether to activate IPv6 or not is usually > > determined in compilation time. > > However, for PC, IPv6 really can be changed dynamically. > > <> > > Totally agree here, and this was the most important original reason > for adding this ipv4-only section. > > > Maybe the justification for this should be clarified a bit? Would you > > have ideas how to do that? > > > > > > IMHO, the key value of "version-independent" API is for the > > situations where IPv6 can > > be DYNAMICALLY disabled. And before we claim the application written > > in "version-independent" API > > can run in IPv4-only platform, we'd better make sure these > > "version-independent" API is supported in > > those legacy IPv4-only platform in advance. > > Yes, that's probably the most important case. > > > Finally, I have one more related question: > > If my platform supported IPv4-mapped IPv6 address and the IPv6 won't > > be disabled forever. > > Then for TCP server application, do you think it is enough to create > > one IPv6 socket to > > server IPv4 and IPv6 TCP client? Or we still need to create two > > sockets, one for each version, > > like the sample code described in Sec 6.3.1? > > <> > > The document takes no firm stance here, on purpose. You have to make > that decision based on the tradeoffs such as portability (some systems > don't support mapped addresses), how you tread the addresses (e.g., > whether you want to parse mapped addresses or v4 addresses), etc. > > As for my personal opinion, I'd go for two sockets for long-term > projects, and possibly for one socket in some limited short-term > hacks. > > -- 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-v6ops@ops.ietf.org Tue May 25 03:06: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 DAA19712 for ; Tue, 25 May 2004 03:06:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSW03-000Hs5-3z for v6ops-data@psg.com; Tue, 25 May 2004 07:05:23 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSW01-000HrQ-WC for v6ops@ops.ietf.org; Tue, 25 May 2004 07:05:22 +0000 Received: (qmail 11562 invoked from network); 25 May 2004 06:51:05 -0000 Received: from unknown (HELO wxg) (159.226.39.69) by mail.ict.ac.cn with SMTP; 25 May 2004 06:51:05 -0000 Message-ID: <002101c44227$19fbd9f0$4527e29f@wxg> From: "Eiffel Wu" To: "Christian Huitema" , Cc: , References: Subject: Re: Teredo vs Silkroad Date: Tue, 25 May 2004 15:08:37 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_LATIN,MIME_BASE64_TEXT,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzdGlhbiBIdWl0ZW1h IiA8aHVpdGVtYUB3aW5kb3dzLm1pY3Jvc29mdC5jb20+DQpUbzogIkVpZmZlbCBXdSIgPHhnd3VA aWN0LmFjLmNuPjsgPGFsaC1pZXRmQHRuZGgubmV0Pg0KQ2M6IDxwZWtrYXNAbmV0Y29yZS5maT47 IDx2Nm9wc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBNYXkgMjUsIDIwMDQgMjoyNyBQ TQ0KU3ViamVjdDogUkU6IFRlcmVkbyB2cyBTaWxrcm9hZA0KDQoNCj4gQXMgYSBjb21wYXJpc29u LCBUZXJlZG8gYWRkcmVzcyBjb25zaXN0cyBvZiBjbGluZXQgaXB2NCBhZGRyZXNzIGFuZA0KdWRw IA0KPiBwb3J0LCB3aGljaCBtdXN0IGJlIGRpZmZlcmVudCB3aXRoIGxhc3Qgb25lLiBIb3cgY2Fu IFRlcmVkbyBDbGllbnQgYmUNCj4gZm91bmQgaWYgdGhlcmUgaXMgbm8gYXBwcm9wcmlhdGUgbmFt aW5nIHNlcnZpY2UgPyBUZXJlZG8gZG9lcyBub3QgDQo+IHByb3ZpZGUgc3VjaCBhIG5hbWluZyBz ZXJ2aWNlLg0KDQpZZXMsIHRoaXMgaXMgYSB0cmFkZS1vZmYuIFRoZSBhZHZhbnRhZ2Ugb2YgYnVp bGRpbmcgdGhlIElQdjYgYWRkcmVzcw0KZnJvbSB0aGUgSVB2NCBhZGRyZXNzIGlzIHRoYXQgeW91 IGRvbid0IG5lZWQgc3Ryb25nIHNlY3VyaXR5IHRvIHByZXZlbnQNCnNwb29maW5nOiB5b3UganVz dCBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHBhY2tldHMgYXJlIHJvdXRlZCB0byB0aGUNCmVtYmVk ZGVkIElQdjQgYWRkcmVzcy4gSWYgeW91IG1ha2UgdGhlIElQdjYgYWRkcmVzcyBpbmRlcGVuZGVu dCBvZiB0aGUNCnVuZGVybHlpbmcgSVB2NCBhZGRyZXNzIHRoZSBhZGRyZXNzIG1heSBiZWNvbWUg bG9uZy1saXZlZCwgYnV0IHRoZQ0KdHVubmVsIHNlcnZlcnMgbXVzdCBpbXBsZW1lbnQgYSBzdHJv bmcgc2VjdXJpdHkgcHJvY2VkdXJlIHRvIG1ha2Ugc3VyZQ0KdGhhdCB0aGUgYWRkcmVzcyBpcyBu b3Qgc3Bvb2ZlZC4NCg0KSnVzdCBhcyB0aGUgcXVhbGlmaWNhdGlvbiBwcm9jZWR1cmUgb2YgVGVy ZWRvIENsaWVudCwgdGhlIGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZSANCmJldHdlZW4gU0MgYW5k IFNBUiB3aWxsIGJlIGFkZGVkIGluIGxhdGVyIHZlcnNpb25zLiBEbyB5b3UgdGhpbmsgaXQgaXMg ZW5vdWdoDQp0byAgcHJldmVudCB0aGUgU0FSIGJlaW5nIHNwb29mZWQ/IEFueSBjb21tZW50cyBv ciBhZHZpY2Ugb24gc2VjdXJpdHkgY29uc2lkZXJhdGlvbg0KYWJvdXQgU2lsa3JvYWQgYXJlIHdl bGNvbWUuDQoNCg0KVGhlbiwgYXMgeW91IG1lbnRpb24sIGlmIHRoZSBhZGRyZXNzIGlzIG5vdCBs b25nLWxpdmVkLCB5b3UgbmVlZCBzb21lDQpmb3JtIG9mIG5hbWUgcmVzb2x1dGlvbiB0byBhc3Nv Y2lhdGUgdGhlIHNob3J0IGxpdmVkIGFkZHJlc3Mgd2l0aCBhDQpsb25nLWxpdmVkIG5hbWUuIFRo ZXJlIGFyZSBzb21lIG9idmlvdXMgY2hvaWNlczogZHluYW1pYyBETlMgb3IgU0lQLCBmb3INCmV4 YW1wbGUuDQoNCldoYXQgY2hvaWNlcyBkb2VzIFRlcmVkbyBhZHZpc2UsIGR5bmFtaWMgRE5TIG9y IFNJUCwgb3Igc29tZSBvdGhlcnMgPw0KDQpFaWZmZWwgV3UNCg0K From owner-v6ops@ops.ietf.org Tue May 25 05:33: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 FAA26637 for ; Tue, 25 May 2004 05:33:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSYGy-000MDO-10 for v6ops-data@psg.com; Tue, 25 May 2004 09:31:00 +0000 Received: from [220.130.44.251] (helo=smtp2.ambit.com.tw) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSYGu-000MCt-73 for v6ops@ops.ietf.org; Tue, 25 May 2004 09:30:56 +0000 Subject: Re: Developing IP version-independent Applications To: Pekka Savola Cc: v6ops@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: js.jason.lin@foxconn.com Date: Tue, 25 May 2004 17:32:57 +0800 X-MIMETrack: Serialize by Router on smtp2/Ambit(Release 5.0.10 |March 22, 2002) at 2004/05/25 05:29:12 PM 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=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, I think it's good to add your suggestion. It directly addresses the major reason why we should consider the "IPv4-only" node. Thank you. Regards, Jason. Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: Developing IP version-independent Applications 2004/05/25 02:54 PM Hi, Unless I hear otherwise shortly, I'm suggesting we address your comments by adding a new paragraph after the 1st in section 4.4: The most important case is the application support on systems where IPv6 support can be dynamically enabled or disabled by the users. Applications on such a system should be able to able to handle the situation where IPv6 would not be enabled. The secondary scenario is when an application could be deployed on older systems which do not support IPv6 at all (even the basic getaddrinfo etc. APIs). In that case the application designer has to make a case-by-case judgement call whether it makes sense to have compile-time toggle between an older and newer API (having to support both in the code), or whether to provide getaddrinfo etc. function support on older platforms as part of the application libraries. .. would this satisfy your concerns, Jason? On Fri, 21 May 2004, Pekka Savola wrote: > (I waited for other comments, but they didn't appear :) > On Mon, 17 May 2004 js.jason.lin@foxconn.com wrote: > > On Sat, 15 May 2004 js.jason.lin@foxconn.com wrote: > > This allows eliminating the compile-time special casing from the code, > > making the code simpler. > > > > > > I am not sure whether most IPv4-only really support such getaddrinfo > > or getnameinfo > > API. But I am afraid to add a version of getaddrinfo/getnameinfo into > > applications can be much > > complicated than using conditional compilation. > > <> > > Depends a lot on how the code is designed. If you create your own > network connectivity manipulation functions, it should be quite easy > to make them conditional. If you don't, you'll have to sprinkle > conditional conditions all over your code. And that's a pain to > maintain as well. > > There's no winner or loser here. I'm familiar with some open-source > projects; most use only getaddrinfo and provide background > compatibility code as appropriate. Some others provide conditionally > either at compile time. > > It's a judgement call for the developer, and I'm not sure whether this > needs text in this document. It might be good to spell it out. Do > you have text suggestions? > > > Further, the IPv4-only operation is most important in practice for > > nodes which already would be able to support IPv6, but the support is > > turned off. The applications should continue to work under those > > circumstances. > > > > > > I think this is really a good reason for "version-independent" > > programming. > > In embedded system, whether to activate IPv6 or not is usually > > determined in compilation time. > > However, for PC, IPv6 really can be changed dynamically. > > <> > > Totally agree here, and this was the most important original reason > for adding this ipv4-only section. > > > Maybe the justification for this should be clarified a bit? Would you > > have ideas how to do that? > > > > > > IMHO, the key value of "version-independent" API is for the > > situations where IPv6 can > > be DYNAMICALLY disabled. And before we claim the application written > > in "version-independent" API > > can run in IPv4-only platform, we'd better make sure these > > "version-independent" API is supported in > > those legacy IPv4-only platform in advance. > > Yes, that's probably the most important case. > > > Finally, I have one more related question: > > If my platform supported IPv4-mapped IPv6 address and the IPv6 won't > > be disabled forever. > > Then for TCP server application, do you think it is enough to create > > one IPv6 socket to > > server IPv4 and IPv6 TCP client? Or we still need to create two > > sockets, one for each version, > > like the sample code described in Sec 6.3.1? > > <> > > The document takes no firm stance here, on purpose. You have to make > that decision based on the tradeoffs such as portability (some systems > don't support mapped addresses), how you tread the addresses (e.g., > whether you want to parse mapped addresses or v4 addresses), etc. > > As for my personal opinion, I'd go for two sockets for long-term > projects, and possibly for one socket in some limited short-term > hacks. > > -- 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-v6ops@ops.ietf.org Tue May 25 09: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 JAA09200 for ; Tue, 25 May 2004 09:14:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSbhy-000EV6-Gj for v6ops-data@psg.com; Tue, 25 May 2004 13:11:06 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSbhr-000EUK-Cw for v6ops@ops.ietf.org; Tue, 25 May 2004 13:10:59 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4PDAov20731 for ; Tue, 25 May 2004 16:10:50 +0300 (EET DST) X-Scanned: Tue, 25 May 2004 16:10:36 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4PDAaVg021051 for ; Tue, 25 May 2004 16:10:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00Mo0NDp; Tue, 25 May 2004 16:10:35 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4PDAYH01999 for ; Tue, 25 May 2004 16:10:34 +0300 (EET DST) Received: from essat-vlan154-2-224132.ntc.nokia.com ([172.21.224.132]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 25 May 2004 16:10:24 +0300 Subject: Reminder: WG last call about to end: draft-ietf-v6ops-ent-scenarios-02.txt From: Jonne Soininen To: v6ops@ops.ietf.org Content-Type: text/plain Message-Id: <1085490625.4543.38.camel@essat-vlan154-2-224132.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Tue, 25 May 2004 16:10:25 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2004 13:10:24.0596 (UTC) FILETIME=[A41AD140:01C44259] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody, the last call for the document "IPv6 Enterprise Network Scenarios" is about to end tomorrow May 26th. Please, provide comments if you have any. Here is the link to the document for your convenience: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt Pekka & Jonne From owner-v6ops@ops.ietf.org Tue May 25 10:49: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 KAA16317 for ; Tue, 25 May 2004 10:49:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSdBu-000815-71 for v6ops-data@psg.com; Tue, 25 May 2004 14:46:06 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSdBl-00080U-Im for v6ops@ops.ietf.org; Tue, 25 May 2004 14:45:57 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 101634880; Tue, 25 May 2004 10:45:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 May 2004 10:45:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Date: Tue, 25 May 2004 10:45:53 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C226@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Thread-Index: AcRCIc3dvb95NzB1SzuuBi6FBwTiIAARI87Q From: "Bound, Jim" To: "Pekka Savola" , Cc: X-OriginalArrivalTime: 25 May 2004 14:45:56.0870 (UTC) FILETIME=[FCCE6A60:01C44266] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This will never be added to this document your out of control but thanks for your opinion. You continue to miss the point of Native IPv6 deployment. And realize as you say your are ONE person here not a GATE to our hard work and efforts to work on specifications. To even say that this scenarios is unfit in a mail on this honoroable list of highly techncial and well informed, long time, engieers, architects and many of us who have been implementing, shipping, and deploying Ipv6 for many years and you the IETF spec reviewer to say that a scenario is unfit when you have nothing more in bullets clearly demonstrates your bias and continued denial of a deployment model that is not just for defense networks but Telcos, Enterprises you don't know anytbing about is beyond my comprehension. I am so tired of your biased input I am uclear if I can even work with you anymore as one of the true leaders and workers of IPv6 that does more than sit around and pontificate on specifications. It is unfortunate that you are a co-chair of the working group with such a bias. =20 /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Tuesday, May 25, 2004 2:29 AM > To: rfgraveman@nac.net > Cc: v6ops@ops.ietf.org > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt >=20 > On Mon, 24 May 2004 rfgraveman@nac.net wrote: > > > I think Example network C, a security defense network, is not=20 > > > mainstream enough to be applicable to be investigated in the=20 > > > scenarios. There are probably 1, 5 or 10 such networks=20 > in the world. > > > We should be focusing on more common scenarios (even addressing=20 > > > "80/20" would be good). [I have a few specific comments for=20 > > > clarification within this example, but I'll send them if this=20 > > > example is not replaced by something else.] ... > >=20 > > OTOH, some of these networks are large, and they buy a lot of=20 > > equipment, so some major vendors take their requirements quite=20 > > seriously. Therefore, I would be against dropping this case. We can=20 > > discuss further whether this is exactly the right=20 > characterization, however. >=20 > I can see the argument why this needs to be considered ..=20 > money is a language everybody understands .. but I'm=20 > concerned that this would be painted as a "model" for v6=20 > deployment, i.e., that other enterprises which have very=20 > little in common with such defense networks would start=20 > mimicking their deployment strategies just because those are=20 > the ones described in our documents. This is why I'm worried=20 > about keeping this here. >=20 > But let's hear if there are more opinions about this. >=20 > In any case, if it stays, this could probably be clarified a bit, > like: >=20 > A Security Defense Network Operation: > =20 > =20 > =3D=3D> add here something like: >=20 > Note that these kind of networks are uncommon and unfit to be a > model or example for deployment for enterprises in general. =20 > However, due to their importance to the vendor community, their > requirements should be considered explicitly. >=20 > ... >=20 > - External network required at secure specific points. > =20 > =3D=3D> I had hard time parsing this, "at secure"? Did you mean: >=20 > - External network is required, but only at specific, secure,=20 > exit points. > =20 > ... >=20 > - Network must be able to absorb ad-hoc creation of sub-Networks. > =20 > =3D=3D> I didn't quite understand what this meant, please=20 > clarify. (I've a hunch, but..) >=20 > - Entire parts of the Network are completely mobile. > =20 > =3D=3D> are we talking about a mobile network (NEMO sense), or=20 > nomadic network (network de-attaches, moves, network=20 > re-attaches) ? The latter would at least be feasible, while=20 > the former may be a bit more problematic. Maybe worth=20 > clarifying a bit.. >=20 > - Network must be able to bolt on to the Internet to share > bandwidth as required from Providers. >=20 > =3D=3D> "bolt on to the Internet" ? I wasn't sure what this was=20 > trying to say -- that the network must be able to multihome=20 > for load-sharing purposes, or...? >=20 > - Nodes must be able to access IPv4 legacy applications over IPv6 > network. >=20 > =3D=3D> are these internal legacy apps, external ones, or possibly = both? =20 > Isn't this assumptive about IPv6 deployment ("v6-only") and=20 > unfit for requirements? >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue May 25 11:14: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 LAA17731 for ; Tue, 25 May 2004 11:14:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSdc4-000E6q-Fg for v6ops-data@psg.com; Tue, 25 May 2004 15:13:08 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSdbm-000E2i-4P for v6ops@ops.ietf.org; Tue, 25 May 2004 15:12:50 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A21C919D0; Tue, 25 May 2004 11:12:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 May 2004 11:12:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Date: Tue, 25 May 2004 11:12:45 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C22E@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Thread-Index: AcRCIc3dvb95NzB1SzuuBi6FBwTiIAARI87QAAEE+0A= From: "Bound, Jim" To: "Bound, Jim" , "Pekka Savola" , Cc: X-OriginalArrivalTime: 25 May 2004 15:12:49.0102 (UTC) FILETIME=[BDC57EE0:01C4426A] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Of course we will reword/add clarity per the input to make clear network c scenario. Also realize users are seeing the benefit for cost reasons to move to IPv6 native networks sooner rather than later and this is affecting transition planning in process now. But your bias is clear in all discussion. /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim > Sent: Tuesday, May 25, 2004 10:46 AM > To: Pekka Savola; rfgraveman@nac.net > Cc: v6ops@ops.ietf.org > Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt >=20 > This will never be added to this document your out of control=20 > but thanks for your opinion. You continue to miss the point=20 > of Native IPv6 deployment. And realize as you say your are=20 > ONE person here not a GATE to our hard work and efforts to=20 > work on specifications. To even say that this scenarios is=20 > unfit in a mail on this honoroable list of highly techncial=20 > and well informed, long time, engieers, architects and many=20 > of us who have been implementing, shipping, and deploying=20 > Ipv6 for many years and you the IETF spec reviewer to say=20 > that a scenario is unfit when you have nothing more in=20 > bullets clearly demonstrates your bias and continued denial=20 > of a deployment model that is not just for defense networks=20 > but Telcos, Enterprises you don't know anytbing about is=20 > beyond my comprehension. I am so tired of your biased input=20 > I am uclear if I can even work with you anymore as one of the=20 > true leaders and workers of > IPv6 that does more than sit around and pontificate on specifications. > It is unfortunate that you are a co-chair of the working=20 > group with such a bias. =20 >=20 > /jim=20 >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > > Sent: Tuesday, May 25, 2004 2:29 AM > > To: rfgraveman@nac.net > > Cc: v6ops@ops.ietf.org > > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt > >=20 > > On Mon, 24 May 2004 rfgraveman@nac.net wrote: > > > > I think Example network C, a security defense network, is not=20 > > > > mainstream enough to be applicable to be investigated in the=20 > > > > scenarios. There are probably 1, 5 or 10 such networks > > in the world. > > > > We should be focusing on more common scenarios (even addressing=20 > > > > "80/20" would be good). [I have a few specific comments for=20 > > > > clarification within this example, but I'll send them if this=20 > > > > example is not replaced by something else.] ... > > >=20 > > > OTOH, some of these networks are large, and they buy a lot of=20 > > > equipment, so some major vendors take their requirements quite=20 > > > seriously. Therefore, I would be against dropping this=20 > case. We can=20 > > > discuss further whether this is exactly the right > > characterization, however. > >=20 > > I can see the argument why this needs to be considered ..=20 > > money is a language everybody understands .. but I'm concerned that=20 > > this would be painted as a "model" for v6 deployment, i.e.,=20 > that other=20 > > enterprises which have very little in common with such defense=20 > > networks would start mimicking their deployment strategies just=20 > > because those are the ones described in our documents. This is why=20 > > I'm worried about keeping this here. > >=20 > > But let's hear if there are more opinions about this. > >=20 > > In any case, if it stays, this could probably be clarified a bit, > > like: > >=20 > > A Security Defense Network Operation: > > =20 > > =20 > > =3D=3D> add here something like: > >=20 > > Note that these kind of networks are uncommon and unfit to be a > > model or example for deployment for enterprises in general. =20 > > However, due to their importance to the vendor community, their > > requirements should be considered explicitly. > >=20 > > ... > >=20 > > - External network required at secure specific points. > > =20 > > =3D=3D> I had hard time parsing this, "at secure"? Did you mean: > >=20 > > - External network is required, but only at specific, secure,=20 > > exit points. > > =20 > > ... > >=20 > > - Network must be able to absorb ad-hoc creation of=20 > sub-Networks. > > =20 > > =3D=3D> I didn't quite understand what this meant, please=20 > clarify. (I've=20 > > a hunch, but..) > >=20 > > - Entire parts of the Network are completely mobile. > > =20 > > =3D=3D> are we talking about a mobile network (NEMO sense), or = nomadic=20 > > network (network de-attaches, moves, network > > re-attaches) ? The latter would at least be feasible, while the=20 > > former may be a bit more problematic. Maybe worth=20 > clarifying a bit.. > >=20 > > - Network must be able to bolt on to the Internet to share > > bandwidth as required from Providers. > >=20 > > =3D=3D> "bolt on to the Internet" ? I wasn't sure what this=20 > was trying to=20 > > say -- that the network must be able to multihome for load-sharing=20 > > purposes, or...? > >=20 > > - Nodes must be able to access IPv4 legacy=20 > applications over IPv6 > > network. > >=20 > > =3D=3D> are these internal legacy apps, external ones, or=20 > possibly both? =20 > > Isn't this assumptive about IPv6 deployment ("v6-only") and=20 > unfit for=20 > > requirements? > >=20 > > --=20 > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue May 25 12:33: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 MAA25772 for ; Tue, 25 May 2004 12:33:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSepb-0002Nu-2t for v6ops-data@psg.com; Tue, 25 May 2004 16:31:11 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSepJ-0002K4-3n for v6ops@ops.ietf.org; Tue, 25 May 2004 16:30:53 +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); Tue, 25 May 2004 09:30:54 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 May 2004 09:30:48 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 May 2004 09:30:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 May 2004 09:30:55 -0700 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, 25 May 2004 09:31:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Teredo vs Silkroad Date: Tue, 25 May 2004 09:30:50 -0700 Message-ID: Thread-Topic: Teredo vs Silkroad Thread-Index: AcRCJroSLUp3wqEZRzazj1PUNNwsVgATnx9g From: "Christian Huitema" To: "Eiffel Wu" , Cc: , X-OriginalArrivalTime: 25 May 2004 16:31:21.0695 (UTC) FILETIME=[B6B21EF0:01C44275] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > What choices does Teredo advise, dynamic DNS or SIP, or some others ? I don't think IP level technologies should make any recommendation about specific name services. The choice of the name service is independent of the transport in use. The only requirement is that the update rate of the name service be compatible with the lifetime of the address.=20 -- Christian Huitema From owner-v6ops@ops.ietf.org Tue May 25 13:28: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 NAA01919 for ; Tue, 25 May 2004 13:28:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSfhI-000DUq-6U for v6ops-data@psg.com; Tue, 25 May 2004 17:26:40 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSfh1-000DSc-Ki for v6ops@ops.ietf.org; Tue, 25 May 2004 17:26:23 +0000 Received: (qmail 19962 invoked from network); 25 May 2004 17:12:01 -0000 Received: from unknown (HELO ThinkPadX31) (211.161.40.150) by mail.ict.ac.cn with SMTP; 25 May 2004 17:12:01 -0000 From: "Liu Min" To: "'Tony Hain'" , "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Wed, 26 May 2004 01:26:16 +0800 Message-ID: <00a701c4427d$65b36f60$9628a1d3@ThinkPadX31> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thank you for your comments. You have mentioned some problems which are common to NAT transversal mechanism, such as the security and multiple = NATs in a path. I will try to answer the questions in-line. Any suggestions = will be appreciated. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > Behalf Of Tony Hain > Sent: Tuesday, May 25, 2004 2:30 AM > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: Teredo vs Silkroad >=20 =20 > This whole discussion has completely ignored the broken concept of the = > Silkroad Navigator. That device is essentially a route reflector,=20 > without any mechanism to secure the updates to it, or a distribution=20 > protocol for consistency (assuming there is intended to be more than=20 > one in the world). Also there is an unstated assumption that the=20 > Silkroad clients just know how to find the navigator (if IPv4 anycast=20 > is assumed, that should be explicitly stated). Any fair comparison=20 > should be to tunnel broker schemes, but if one insists on relating=20 > this to Teredo, the navigator is functionally the same as the Teredo=20 > server, while the access router is functionally the same as the Teredo = > relay. The primary difference is that Silkroad provides the address=20 > stability of a tunnel broker at the expense of client automation. >=20 > As for security, the idea that an RA could come from an arbitrary=20 > navigator pointing to some random Silkroad access router is a security = > hole big enough to drive an army through (never mind that it fails by=20 > using an IPv6 function to provide IPv4 information). SARs are expected to make access control. What's your meaning by saying that it fails by using an IPv6 function to provide IPv4 information? > Of course, a SC can determine the address or domain name of a SAR > through other means. For example, the SC could get the address of > SAR by sending Router Solicitation message over UDP to the SN. The = SN > replies with a Router Advertisement over UDP containing the address > of available SAR. >=20 >=20 > The whole lifetime discussion is confused. All prefixes will have a=20 > lifetime, it may be very long, but it will be there. Any discussion=20 > about 'permanent' only invites people to believe the prefix will move=20 > with them when they leave Slikroad behind, but that can't happen if=20 > the prefix is part of the SAR aggregate. Do you think it will be better to change "permanent" to "stable"? >=20 >=20 > Moreover, if the SC is an IPv6 router willing to provide IPv6 > connectivity to several hosts, it should provide some information > about how many IPv6 addresses are required. This allows the SAR to > allocate the SC an IPv6 prefix that fits its address needs. >=20 > That is a nice concept, but unnecessary complexity. Given that there=20 > is an authentication step at the navigator to find the SAR to begin=20 > with, the appropriate prefix length for this subscriber is already=20 > available and doesn't need to be included in the protocol between the=20 > client and SAR. =20 SN only helps SC who doesn't have a default SAR to choose its SAR, and = what SN provide to SC is the SAR's IPv4 address. The SC should ask for IPv6 address space from SAR and SAR will allocate IPv6 prefix that fits SC's address need. If a SC already has its default SAR, it will not connect = to SN again. > 4.2.3 is useless clutter since the base assumption is that there may=20 > be multiple nats in the path. Why is there an assumption that they=20 > will all be the same type, or that any optimization for the first hop=20 > nat will actually be useful along a path full of nats? The whole=20 > discussion misses the point that many transfers will be over before an = > optimization determination could be made. There is no assumption that the NATs will be the same type.When there = are multiple NATs in the path, silkroad will still work, although the performance may be influenced. For example, if there are two NATs, one = is cone NAT and the other is symmetric, the NAT type determining process = will judge the NAT type as symmetric. In other words, the NAT type will be = the one with more route optimization constraints. This is a problem common = to all NAT transversal mechanism. But it will not influence silkroad's functions. >=20 > Figure 2 is very ambiguous (and actually supports Christian's note=20 > about the number of SARs). It appears that R1 & R2 should really be=20 > SAR1 & SAR2, with a collection of routers (IPv4 Rn) not shown. R1 and R2 may be the same SARs. >=20 >=20 > If R1 has never forwarded an packet towards this > IPv6 destination address and has no route information in its local > route table, it will connect to SN to search the list of SARs that > can forward IPv6 packets to the specific IPv6 network and get the > IPv4 addresses of these SARs. >=20 > No, any router without a route will drop the packet. Anything else=20 > will kill the router. Clearly there is need for a periodic routing=20 > update here, but the overall specification assumes a small lab=20 > environment style network where scale and time delays don't matter. In this process, the role of SN is just like a DNS. When the SAR has no route information in its local cache, it will connect SN to 'resolve' = the destination address. This process will leave a record in its cache. So = when the SAR forward packets to the same destination address next time, it = will have the route information and need not connect to SN. SARs should = announce its address space to SN. > For example: > the SC can specify the transmission method in Control Option domain >=20 > No ISP would allow their customers to define the transmission path=20 > choice between its routers. > SARs may not be provided by ISPs. For example, it could be an enabler = for a game that requires direct IPv6 communication between client hosts. SARs could be provided by the third party. SC could choose appropriate SAR = based on location, performance, cost or other consideration. =20 > It would appear that the authors don't really have a grasp on=20 > operational > realities: > When B wants to transmit an IPv6 packet to A, B simply follows IPv6 > rules. The packet will be forwarded to one SAR close to B in the = IPv6 > Internet topology, R2, over IPv6. > Why would this happen? The only reason would be that a routing prefix = for A > is announced by B into the IPv6 routing domain. But this unreasonable > assumption is followed with: > If R2 has no route information in its local route table, it > will connect to SN to search the IPv4 address of the SAR that can > forward IPv6 packets to the specific IPv6 address. > If R2 has no route information, why would it be telling the IPv6 = domain that > it does? Teredo can do this because it uses a unique prefix for all = Teredo > reachable destinations and assumes the IPv4 network is contiguous. Silkroad > can't do this unless all SARs have full routing tables for all = clients. It may be clearer to remove the R2. When a regular IPv6 node B wants to transmit an IPv6 packet to a SC A, B simply follows IPv6 rules. And = because A's address is belonging to R1' address space, the packet will be = forwarded to R1. > Another example: > All SARs could configure static routes between each other Static=20 > configuration is a lab class concept; not useful in the real world. Sorry, it should be static tunnels, not static routes. >=20 >=20 > In the simplest case, when the Silkroad clients are very few, one = SAR > may be enough, only if the SAR has connected to IPv6 Internet. > One thing I haven't seen on the list are all the traditional=20 > complaints about open relays and spoofing. There is nothing magic=20 > about a SAR that would prevent spoofing. If someone really intends to=20 > deploy this, a robust mechanism for limiting access and verifying=20 > correct IPv4 / IPv6 mappings will be needed. Since the single SN in=20 > the world is the only one that the correct mappings, it will clearly=20 > need to be consulted for mapping coherence on each cache miss. Security consideration is necessary to all NAT transversal mechanisms. = In the first version of silkroad, both the SC's request and the SAR's = response will be protected by an authentication token, carried in the UDP = message. We call them Shared Secret Request and Shared Secret Response. But it's = not clear whether a shared-secret cryptography is useful in a mechanism like this, and second, we didn't make it clearer whether the SAR has only one shared secret or one for each SC. So the shared secret mechanism is = removed in this version. We are working on detailed security mechanisms now. And related contents will appear in the next version.=20 > In the simplest case, when the Silkroad clients and Silkroad access > routers are very few, there is no need to configure Silkroad > navigator. >=20 > Wait, I thought the SN was necessary for client authentication up=20 > front. How can the system get by without one? It really doesn't matter = > because the assumption that the world can do with ONE is a clear=20 > indication that the spec is a lab effort that is never intended to be=20 > deployed. >=20 SN only helps SC who doesn't have a default SAR to choose its SAR. What = SN provides to SC is the IPv4 address of available SAR. SC should ask appropriate SAR for service. SARs are expected to perform access = control. So SN is not necessary for client authentication.=20 As mentioned in the draft, in the initial deployment of the Silkroad service, there may be only one globally accessible Silkroad navigator. However, along with the increase in the size of the route database in SN = and frequency of updates, it may demand a distributed manner with local = caching to improve performance. But at this time, it is recommended to offer = native IPv6 instead of deploying many SNs. In fact, when all SARs have easy = access to IPv6 Internet, SN could be omitted. >=20 >=20 > In short Silkroad is nothing more than trying to provide a scaling=20 > front end for the forwarding function of the tunnel broker model.=20 > While that function is an admirable goal, this spec will need major=20 > rework before it even comes close to something that is operationally=20 > deployable. A reasonable trust model and fully dynamic routing update=20 > system are the first steps. In any case Silkroad should not be=20 > compared to Teredo because it is fundamentally a tunnel broker (albeit = > a broken one in the current spec) so section 7.4 should simply be=20 > removed. Silkroad and Teredo are two solutions to the same problem. It is very natural to make a comparison between them. >=20 > Tony >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue May 25 15: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 PAA13183 for ; Tue, 25 May 2004 15:55:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BShzM-0001L7-L0 for v6ops-data@psg.com; Tue, 25 May 2004 19:53:28 +0000 Received: from [4.14.91.19] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BShz4-0001J0-Fa for v6ops@ops.ietf.org; Tue, 25 May 2004 19:53:10 +0000 Received: from eaglet (127.0.0.1:3368) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 25 May 2004 12:53:05 -0700 From: "Tony Hain" To: "'Liu Min'" , "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Tue, 25 May 2004 12:53:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <00a701c4427d$65b36f60$9628a1d3@ThinkPadX31> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRCfe0iTnKeGxkIRLuD5EHCnmiTXAAB336w X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Liu Min wrote: > Thank you for your comments. You have mentioned some problems which are > common to NAT transversal mechanism, such as the security and multiple > NATs > in a path. I will try to answer the questions in-line. Any suggestions > will > be appreciated. > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > > Behalf Of Tony Hain > > Sent: Tuesday, May 25, 2004 2:30 AM > > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > > Cc: v6ops@ops.ietf.org > > Subject: RE: Teredo vs Silkroad > > > > > This whole discussion has completely ignored the broken concept of the > > Silkroad Navigator. That device is essentially a route reflector, > > without any mechanism to secure the updates to it, or a distribution > > protocol for consistency (assuming there is intended to be more than > > one in the world). Also there is an unstated assumption that the > > Silkroad clients just know how to find the navigator (if IPv4 anycast > > is assumed, that should be explicitly stated). Any fair comparison > > should be to tunnel broker schemes, but if one insists on relating > > this to Teredo, the navigator is functionally the same as the Teredo > > server, while the access router is functionally the same as the Teredo > > relay. The primary difference is that Silkroad provides the address > > stability of a tunnel broker at the expense of client automation. > > > > As for security, the idea that an RA could come from an arbitrary > > navigator pointing to some random Silkroad access router is a security > > hole big enough to drive an army through (never mind that it fails by > > using an IPv6 function to provide IPv4 information). > > SARs are expected to make access control. It would be useful to see some text before commenting about how that could possibly work. > What's your meaning by saying that it fails by using an IPv6 function to > provide IPv4 information? The text says that the SN can indicate the SA to the SC via an IPv6 RA. Since the RA is an IPv6 mechanism, it doesn't have any capability to provide an IPv4 address of the SA to the SC. > > > Of course, a SC can determine the address or domain name of a SAR > > through other means. For example, the SC could get the address of > > SAR by sending Router Solicitation message over UDP to the SN. The SN > > replies with a Router Advertisement over UDP containing the address > > of available SAR. > > > > > > The whole lifetime discussion is confused. All prefixes will have a > > lifetime, it may be very long, but it will be there. Any discussion > > about 'permanent' only invites people to believe the prefix will move > > with them when they leave Slikroad behind, but that can't happen if > > the prefix is part of the SAR aggregate. > > Do you think it will be better to change "permanent" to "stable"? Yes. > > > > > > > Moreover, if the SC is an IPv6 router willing to provide IPv6 > > connectivity to several hosts, it should provide some information > > about how many IPv6 addresses are required. This allows the SAR to > > allocate the SC an IPv6 prefix that fits its address needs. > > > > That is a nice concept, but unnecessary complexity. Given that there > > is an authentication step at the navigator to find the SAR to begin > > with, the appropriate prefix length for this subscriber is already > > available and doesn't need to be included in the protocol between the > > client and SAR. > > SN only helps SC who doesn't have a default SAR to choose its SAR, and > what > SN provide to SC is the SAR's IPv4 address. The SC should ask for IPv6 > address space from SAR and SAR will allocate IPv6 prefix that fits SC's > address need. If a SC already has its default SAR, it will not connect to > SN > again. So when the SAR is dead, there is no way to choose an alternative... Since there is no detail about the client authentication process, there is no way to comment about mechanisms for allocating prefixes. The one thing that is clear from the ISPs I have talked to is that they want to control that prefix length through their business process, so having a dynamic protocol for requesting an arbitrary length is pointless. Figure out how to use DHCP-PD to accomplish this task. > > > 4.2.3 is useless clutter since the base assumption is that there may > > be multiple nats in the path. Why is there an assumption that they > > will all be the same type, or that any optimization for the first hop > > nat will actually be useful along a path full of nats? The whole > > discussion misses the point that many transfers will be over before an > > optimization determination could be made. > There is no assumption that the NATs will be the same type.When there are > multiple NATs in the path, silkroad will still work, although the > performance may be influenced. For example, if there are two NATs, one is > cone NAT and the other is symmetric, the NAT type determining process will > judge the NAT type as symmetric. In other words, the NAT type will be the > one with more route optimization constraints. This is a problem common to > all NAT transversal mechanism. But it will not influence silkroad's > functions. Yes the mechanism will find the least common capabilities, but what was the point? The result is limited to a very specific address (and possibly port) over a short period of time. Every transfer will required a different decision, so the SC is very likely to spend more time trying to figure out the optimization than actually transferring data. The whole mechanism will be simpler if you just assume that the SA will be in the path, because it will be more often than not. > > > > > > Figure 2 is very ambiguous (and actually supports Christian's note > > about the number of SARs). It appears that R1 & R2 should really be > > SAR1 & SAR2, with a collection of routers (IPv4 Rn) not shown. > > R1 and R2 may be the same SARs. That was not the point of my comment. The figure is showing architectural components, but there is no 'SAR' in the picture (they are designated R1 & R2 rather than SAR1 & SAR2). Yes SC's may attach to the same SAR, but they are just as likely to be attached to different ones. The mechanism has to work for the more complex case, leaving the simple one as just an optimization. > > > > > > > > If R1 has never forwarded an packet towards this > > IPv6 destination address and has no route information in its local > > route table, it will connect to SN to search the list of SARs that > > can forward IPv6 packets to the specific IPv6 network and get the > > IPv4 addresses of these SARs. > > > > No, any router without a route will drop the packet. Anything else > > will kill the router. Clearly there is need for a periodic routing > > update here, but the overall specification assumes a small lab > > environment style network where scale and time delays don't matter. > > In this process, the role of SN is just like a DNS. When the SAR has no > route information in its local cache, it will connect SN to 'resolve' the > destination address. This process will leave a record in its cache. So > when > the SAR forward packets to the same destination address next time, it will > have the route information and need not connect to SN. SARs should > announce > its address space to SN. So every time a SAR restarts it will beat on the SN until it rebuilds its cache... Clearly you are assuming that a collection of IPv6 prefixes will be routed through a single IPv4 address for an extended period of time. What mechanism allows that IPv4 address to change? When a SAR has a stale mapping it will just forward packets into oblivion, or worse end up DOSing the new device that was unfortunate enough to have been assigned an old SAR address. > > > For example: > > the SC can specify the transmission method in Control Option domain > > > > No ISP would allow their customers to define the transmission path > > choice between its routers. > > > SARs may not be provided by ISPs. For example, it could be an enabler for > a > game that requires direct IPv6 communication between client hosts. SARs > could be provided by the third party. SC could choose appropriate SAR > based > on location, performance, cost or other consideration. Clearly this is not intended for real deployment. As a simple example, if a node can only have one SAR, but it wants to optimize itself for different gaming environments it would need the ability to attach to different ones depending on the application. Yes there is SAR-SAR tunneling, but for the serious gamer that hop is unacceptable. In any case you missed the point. It doesn't matter who provides the SAR, there is no way the operator of that device will allow the clients to direct its routing decisions. The document appears to be hacking in a QoS mechanism by increasing the overhead in every packet. If that is the goal, it would be better to simply require mapping the QoS from the IPv6 header to the IPv4 tunnel header. > > > It would appear that the authors don't really have a grasp on > > operational > > realities: > > When B wants to transmit an IPv6 packet to A, B simply follows IPv6 > > rules. The packet will be forwarded to one SAR close to B in the IPv6 > > Internet topology, R2, over IPv6. > > Why would this happen? The only reason would be that a routing prefix > for > A > > is announced by B into the IPv6 routing domain. But this unreasonable > > assumption is followed with: > > If R2 has no route information in its local route table, it > > will connect to SN to search the IPv4 address of the SAR that can > > forward IPv6 packets to the specific IPv6 address. > > If R2 has no route information, why would it be telling the IPv6 domain > that > > it does? Teredo can do this because it uses a unique prefix for all > Teredo > > reachable destinations and assumes the IPv4 network is contiguous. > Silkroad > > can't do this unless all SARs have full routing tables for all clients. > > It may be clearer to remove the R2. When a regular IPv6 node B wants to > transmit an IPv6 packet to a SC A, B simply follows IPv6 rules. And > because > A's address is belonging to R1' address space, the packet will be > forwarded > to R1. ...Some serious hand waving going on here... R1 (really SAR1) is not connected to B by a native IPv6 path, so your forwarding comment makes no sense. In any case, it is not better to remove R2 (really SAR2) because you have to make the complex case work, and this spec doesn't even come close. The only reason B would send a packet to SAR2 is if it believed SAR2 was the path to A. For that to happen, SAR2 would have to announce SAR1's prefix into the IPv6 routing system that B is attached to. Since the scenario described in the document claims that SAR2 has no information about SAR1, there is no reason for it to make that announcement. > > > > Another example: > > All SARs could configure static routes between each other Static > > configuration is a lab class concept; not useful in the real world. > > Sorry, it should be static tunnels, not static routes. The point was that 'static' is not practical in the global production Internet. It doesn't matter if that is tunnels or routes. > > > > > > > In the simplest case, when the Silkroad clients are very few, one SAR > > may be enough, only if the SAR has connected to IPv6 Internet. > > > One thing I haven't seen on the list are all the traditional > > complaints about open relays and spoofing. There is nothing magic > > about a SAR that would prevent spoofing. If someone really intends to > > deploy this, a robust mechanism for limiting access and verifying > > correct IPv4 / IPv6 mappings will be needed. Since the single SN in > > the world is the only one that the correct mappings, it will clearly > > need to be consulted for mapping coherence on each cache miss. > > Security consideration is necessary to all NAT transversal mechanisms. In > the first version of silkroad, both the SC's request and the SAR's > response > will be protected by an authentication token, carried in the UDP message. > We call them Shared Secret Request and Shared Secret Response. But it's > not > clear whether a shared-secret cryptography is useful in a mechanism like > this, and second, we didn't make it clearer whether the SAR has only one > shared secret or one for each SC. So the shared secret mechanism is > removed > in this version. We are working on detailed security mechanisms now. And > related contents will appear in the next version. Shared secret between all clients is also know as WEP. While the architecture works between a small trusted set, it fails miserably in the real world. Whatever the process is, it needs to provide a scalable way to distribute & change the auth token (hint: shared key across 1M clients will never work). > > > > In the simplest case, when the Silkroad clients and Silkroad access > > routers are very few, there is no need to configure Silkroad > > navigator. > > > > Wait, I thought the SN was necessary for client authentication up > > front. How can the system get by without one? It really doesn't matter > > because the assumption that the world can do with ONE is a clear > > indication that the spec is a lab effort that is never intended to be > > deployed. > > > SN only helps SC who doesn't have a default SAR to choose its SAR. What SN > provides to SC is the IPv4 address of available SAR. SC should ask > appropriate SAR for service. SARs are expected to perform access control. > So > SN is not necessary for client authentication. It really doesn't matter where the auth is done until there is an unambiguous way to identify the client. Even when there is a way to identify the client, the SC will need a way to verify the authenticity of the list the SN is providing. Also it is wrong to claim there is no need for a SN when SAR's are expected to use it to find each other, and for that each SAR will need a way to verify that the list from the SN is valid. > > As mentioned in the draft, in the initial deployment of the Silkroad > service, there may be only one globally accessible Silkroad navigator. > However, along with the increase in the size of the route database in SN > and > frequency of updates, it may demand a distributed manner with local > caching > to improve performance. But at this time, it is recommended to offer > native > IPv6 instead of deploying many SNs. In fact, when all SARs have easy > access > to IPv6 Internet, SN could be omitted. Since the SARs require the SN to find each other having only one (or even a handful) in the world is a guarantee that this proposal will go nowhere. Simply connecting some of the SARs to the native IPv6 network does not obviate the need for the SN so they can all find the ones that are isolated. > > > > > > In short Silkroad is nothing more than trying to provide a scaling > > front end for the forwarding function of the tunnel broker model. > > While that function is an admirable goal, this spec will need major > > rework before it even comes close to something that is operationally > > deployable. A reasonable trust model and fully dynamic routing update > > system are the first steps. In any case Silkroad should not be > > compared to Teredo because it is fundamentally a tunnel broker (albeit > > a broken one in the current spec) so section 7.4 should simply be > > removed. > > Silkroad and Teredo are two solutions to the same problem. It is very > natural to make a comparison between them. They are not solving the same problem. Silkroad is a tunnel broker, requiring explicit manual intervention at setup, while Teredo requires no manual action at the client. Silkroad is an enhancement to the tunnel broker concept in that it attempts to optimize routing away from the prefix allocation point. The only similarity with Teredo is due to this routing optimization, and the need to punch arbitrary holes in NATs. Since the fundamental point of any tunneling mechanism is providing basic connectivity to isolated IPv6 nodes, the primary comparison has to be on that point. The secondary issue about optimizations may be helpful in terms of sharing best practices, but optimizations are not the place to make primary comparisons. If Silkroad incorporates a trust model that is simple enough to deploy and operate at Internet scale, there might be reason to continue working on it. Once there is a trust model, the whole demand based query to the SN will need to be replaced by a dynamic protocol between the distributed SN's, with some form of dynamic update out to the SARs. Without those capabilities, there is no value over any of the existing Tunnel Broker schemes. Tony From owner-v6ops@ops.ietf.org Tue May 25 20:47: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 UAA10549 for ; Tue, 25 May 2004 20:47:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSmXy-000Ff2-8G for v6ops-data@psg.com; Wed, 26 May 2004 00:45:30 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSmXw-000FeO-M3 for v6ops@ops.ietf.org; Wed, 26 May 2004 00:45:28 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 8E62F3F; Wed, 26 May 2004 07:33:56 +0900 (JST) To: pekkas@netcore.fi Cc: js.jason.lin@foxconn.com, v6ops@ops.ietf.org Subject: Re: Developing IP version-independent Applications In-Reply-To: Your message of "Tue, 25 May 2004 09:54:34 +0300 (EEST)" References: X-Mailer: Cue version 0.8 (040507-1428/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040525223356.8E62F3F@coconut.itojun.org> Date: Wed, 26 May 2004 07:33:56 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) 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-v6ops@ops.ietf.org Precedence: bulk > Hi, > > Unless I hear otherwise shortly, I'm suggesting we address your > comments by adding a new paragraph after the 1st in section 4.4: > > The most important case is the application support on > systems where IPv6 support can be dynamically enabled or disabled > by the users. Applications on such a system should be able to able to > handle the situation where IPv6 would not be enabled. The secondary > scenario is when an application could be deployed on older systems > which do not support IPv6 at all (even the basic getaddrinfo > etc. APIs). In that case the application designer has to make a > case-by-case judgement call whether it makes sense to have compile-time > toggle between an older and newer API (having to support both in the > code), or whether to provide getaddrinfo etc. function support on > older platforms as part of the application libraries. > > .. would this satisfy your concerns, Jason? it looks ok to me, and reflects current practice. itojun From owner-v6ops@ops.ietf.org Wed May 26 03:55: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 DAA27308 for ; Wed, 26 May 2004 03:55:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BStD4-000Oqy-4P for v6ops-data@psg.com; Wed, 26 May 2004 07:52:22 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BStD2-000OqJ-KP; Wed, 26 May 2004 07:52:20 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4Q7q9E28283; Wed, 26 May 2004 10:52:09 +0300 (EET DST) X-Scanned: Wed, 26 May 2004 10:51:26 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4Q7pQm2005729; Wed, 26 May 2004 10:51:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00iy2rsE; Wed, 26 May 2004 10:51:24 EEST 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 i4Q7pNH24615; Wed, 26 May 2004 10:51:23 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 May 2004 10:51:23 +0300 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: 3GPP Analysis revision -10 (resolving IESG comments) Date: Wed, 26 May 2004 10:51:22 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE392@esebe005.ntc.nokia.com> Thread-Topic: 3GPP Analysis revision -10 (resolving IESG comments) Thread-Index: AcRC9jw3iHMBKOMKRsecd8eQLcKPMw== From: To: Cc: , , , , , , , X-OriginalArrivalTime: 26 May 2004 07:51:23.0664 (UTC) FILETIME=[3DA22100:01C442F6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, I finally managed to compose revision -10 of the 3GPP Analysis document. = The draft can be found here: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt= The document now *should* resolve IESG discuss comments, the major = changes compared to -09 are the following: - summary/recommendations section - IMS scenario 1 text (based on Allison Mankin's text) - I am still a = bit unsure about the text... - editorial changes / proofreading done by Spencer Dawkins This is what I wrote in the summary/recommendations section: ------------ This document has analyzed five GPRS and two IMS IPv6 transition=20 scenarios. Numerous 3GPP networks are using private IPv4 addresses=20 today, and introducing IPv6 is an important thing. The two first=20 GPRS scenarios and both IMS scenarios are seen the most relevant.=20 The authors summarize some main recommendations here:=20 - Dual-stack UEs are recommended instead of IPv4-only or IPv6- only UEs. It is important to take care that the applications=20 in the UEs support IPv6. IPv6-only UEs can become feasible=20 when IPv6 is widely deployed in the networks, and most=20 services work on IPv6.=20 - It is recommended to activate an IPv6 PDP context when=20 communicating with an IPv6 peer node and an IPv4 PDP context=20 when communicating with an IPv4 peer node.=20 - IPv6 communication is preferred to IPv4 communication going=20 through IPv4 NATs to the same dual stack peer node.=20 - This document strongly recommends the 3GPP operators to deploy=20 basic IPv6 support in their GPRS networks as soon as possible.=20 That makes it possible to lessen the transition effects in the=20 UEs.=20 - A tunneling mechanism in the UE may be needed during the early=20 phases of the IPv6 transition process. A lightweight,=20 automatic tunneling mechanism should be standardized in the=20 IETF.=20 - Tunneling mechanisms can be used in 3GPP networks, and only=20 generic recommendations are given in this document. More=20 details can be found, for example, in [ISP-sa].=20 - We recommend that a detailed solution for the general=20 SIP/SDP/media IPv4/IPv6 transition problem will be specified=20 as soon as possible as a task within the SIP WGs in the IETF.=20 ----------- Rgds, -Juha W.- From owner-v6ops@ops.ietf.org Wed May 26 11:48: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 LAA24984 for ; Wed, 26 May 2004 11:48:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT0Zh-000LHV-VO for v6ops-data@psg.com; Wed, 26 May 2004 15:44:13 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BT0Yv-000L03-V5 for v6ops@ops.ietf.org; Wed, 26 May 2004 15:43:26 +0000 Received: (qmail 20767 invoked from network); 26 May 2004 15:28:47 -0000 Received: from unknown (HELO ThinkPadX31) (211.161.40.175) by mail.ict.ac.cn with SMTP; 26 May 2004 15:28:47 -0000 From: "Liu Min" To: "'Tony Hain'" , "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Wed, 26 May 2004 23:43:09 +0800 Message-ID: <000a01c44338$2b74c900$af28a1d3@ThinkPadX31> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I omit the previous letters since it has been a chaos of multiple = re-mail. My answers are as following: 1. Although silkroad is similar as tunnel broker based solution, it is = not a tunnel broker. Tunnel broker is not presented to solve NAT transversal = but to provide one easy way to configure and maintain many different = tunnels. Tunnel broker focuses on the lifecycle management of tunnels, not the = tunnel technologies. From this point, silkroad can also be managed by tunnel broker. If you really want to compare it to tunnel broker, the SAR will = play the role of both TB and TS in tunnel broker. SN can help SARs route = between each other, which is a novel entity in tunnel broker scheme. 2. Silkroad and Teredo are two solutions to the same problem: tunneling = IPv6 packets through NAT devices. Silkroad assumes the SC know the IPv4 = address of the SN. And Teredo also needs some configuration at setup. "Before = using the Teredo service, the client must be configured with: =20 - the IPv4 address of a server. If secure discovery is required, the client must also be = configured with: - a client identifier, - a secret value, shared with the server." 3. In your letter you said "Yes the mechanism will find the least common capabilities, but what was the point? The result is limited to a very specific address (and possibly port) over a short period of time. Every transfer will required a different decision, so the SC is very likely to spend more time trying to figure out the optimization than actually transferring data. The whole mechanism will be simpler if you just = assume that the SA will be in the path, because it will be more often than = not." I think you misunderstand my point. Not every transfer will required a different decision. No matter how many NATs there are, you need not = judge each NAT's type.=20 The NAT type determining process will only work once. Then you will know could you receive a packet from an arbitrary address or only an address = to which you have sent a packet, or something like this. In our draft, the process is a reference to STUN. In Teredo, the process is similar. In addition, SC only needs to determine the NAT type when it starts = silkroad service for the first time. Anyway, the route optimization is optional. = It is recommended for cone NAT users to do optimization. Other NAT users = are recommended to choose to do route optimization only if they want to = transmit large bulk traffic.=20 4. Silkroad Router Advertisement is a private packet format defined in silkroad for SN to indicate the IPv4 address of SAR to SC. It is not the IPv6 RA in RFC2461. So it is not using IPv6 function to provide IPv4 information. If it causes some confusion, I will change the packet name = in the next version. In fact, the interaction between the SC and the SN = could go on different means, such as http. Silkroad Router Advertisement is = just one alternative way, which is not a necessary part in silkroad. 5. There are many works ongoing for silkroad. We will refine our draft/prototype in the following versions and you and anyone else are welcome to give any comments and suggestions. Liu Min > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, May 26, 2004 3:53 AM > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: Teredo vs Silkroad >=20 > Liu Min wrote: > > Thank you for your comments. You have mentioned some problems which=20 > > are common to NAT transversal mechanism, such as the security and=20 > > multiple NATs in a path. I will try to answer the questions in-line. = > > Any suggestions will > > be appreciated. > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]=20 > > > On Behalf Of Tony Hain > > > Sent: Tuesday, May 25, 2004 2:30 AM > > > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > > > Cc: v6ops@ops.ietf.org > > > Subject: RE: Teredo vs Silkroad From owner-v6ops@ops.ietf.org Wed May 26 13:19: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 NAA00571 for ; Wed, 26 May 2004 13:19:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT22i-000HI5-UJ for v6ops-data@psg.com; Wed, 26 May 2004 17:18:16 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT21r-000HBG-33 for v6ops@ops.ietf.org; Wed, 26 May 2004 17:17:23 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 May 2004 10:17:57 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 26 May 2004 10:17:21 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 May 2004 10:17:19 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 May 2004 10:17:18 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 May 2004 10:17:17 -0700 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); Wed, 26 May 2004 10:17:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: draft-ietf-ngtrans-isatap-21.txt Date: Wed, 26 May 2004 10:17:17 -0700 Message-ID: Thread-Topic: draft-ietf-ngtrans-isatap-21.txt Thread-Index: AcQ9nKDmxKnuqMdtR4eBL0oNN8yxngFqCLeg From: "Dave Thaler" To: "Jonne Soininen" , Cc: "Karen E. Nielsen \"\"\(AH/TED\)" , "Markku Savela" , "Mohit Talwar" , , "ext Fred Templin" X-OriginalArrivalTime: 26 May 2004 17:17:46.0585 (UTC) FILETIME=[5D085C90:01C44345] 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Jonne Soininen wrote: >=20 > Fred et al., >=20 > so have reached agreement on the edits needed (if any) to the -21? Is a > new revision needed based on the comments? The co-authors have reached agreement on the edits needed to the -21 draft as a result of feedback from Karen Nielsen and Markku Savela and some editorial nits discovered. The non-editorial items are as described at the end of issues 14, 21, and 22 on http://www.geocities.com/osprey67/isatap/isatap_issues.htm and are briefly: 14) Move existing text from elsewhere in the document into a new=20 Encapsulation subsection, for better readability. No technical impact. 22) Remove mention of "neighbor cache entries". This approach is consistent with that taken in the 6to4 RFC. This is trivial as well, as only two sentences are affected. 23) Trivial wording change from "point-to-multipoint" to "non-broadcast multi-access (NBMA)" in the terminology section. The authors had been waiting to see if any additional issues were raised before resubmitting an update, but since a month has now passed since -21 was issued and no further issues have come up we believe we can go ahead and submit -22. =20 > According the agreement reached in Seoul, as soon as you get this ready > you can pursue this as individual experimental submission for > publication. >=20 > I think it would be worth while moving forward as soon as you reach > agreement on the draft. We will work with the WG chairs and ADs in taking the next steps forward in a timely fashion. The ISATAP co-authors. > Cheers, >=20 > Jonne. From owner-v6ops@ops.ietf.org Wed May 26 13:35: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 NAA01376 for ; Wed, 26 May 2004 13:35:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT2Ii-000JrJ-IA for v6ops-data@psg.com; Wed, 26 May 2004 17:34:48 +0000 Received: from [216.193.194.222] (helo=aaryn.lunarpages.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT2HE-000Jgd-DC for v6ops@ops.ietf.org; Wed, 26 May 2004 17:33:16 +0000 Received: from h87.s239.netsol.com ([216.168.239.87] helo=dul1shollenbl1) by aaryn.lunarpages.com with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BT2JQ-0000wv-5t; Wed, 26 May 2004 10:35:32 -0700 From: "Scott Hollenbeck" To: , Cc: , , , , , , Subject: RE: 3GPP Analysis revision -10 (resolving IESG comments) Date: Wed, 26 May 2004 13:33:40 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F4EB@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE392@esebe005.ntc.nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - aaryn.lunarpages.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - 428cobrajet.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,BIZ_TLD autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've cleared my discuss. -Scott- > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: Wednesday, May 26, 2004 3:51 AM > To: v6ops@ops.ietf.org > Cc: mankin@psg.com; sah@428cobrajet.net; hardie@qualcomm.com; > housley@vigilsec.com; david.kessens@nokia.com; > bwijnen@lucent.com; jon.peterson@neustar.biz; spencer@mcsr-labs.org > Subject: 3GPP Analysis revision -10 (resolving IESG comments) > > > > Hi all, > > I finally managed to compose revision -10 of the 3GPP > Analysis document. The draft can be found here: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-anal > ysis-10.txt > > The document now *should* resolve IESG discuss comments, the > major changes compared to -09 are the following: > - summary/recommendations section > - IMS scenario 1 text (based on Allison Mankin's text) - I am > still a bit unsure about the text... > - editorial changes / proofreading done by Spencer Dawkins > > This is what I wrote in the summary/recommendations section: > ------------ > This document has analyzed five GPRS and two IMS IPv6 transition > scenarios. Numerous 3GPP networks are using private IPv4 > addresses > today, and introducing IPv6 is an important thing. The two first > GPRS scenarios and both IMS scenarios are seen the most relevant. > The authors summarize some main recommendations here: > - Dual-stack UEs are recommended instead of IPv4-only or IPv6- > only UEs. It is important to take care that the applications > in the UEs support IPv6. IPv6-only UEs can become feasible > when IPv6 is widely deployed in the networks, and most > services work on IPv6. > - It is recommended to activate an IPv6 PDP context when > communicating with an IPv6 peer node and an IPv4 PDP context > when communicating with an IPv4 peer node. > - IPv6 communication is preferred to IPv4 communication going > through IPv4 NATs to the same dual stack peer node. > - This document strongly recommends the 3GPP operators > to deploy > basic IPv6 support in their GPRS networks as soon as > possible. > That makes it possible to lessen the transition > effects in the > UEs. > - A tunneling mechanism in the UE may be needed during > the early > phases of the IPv6 transition process. A lightweight, > automatic tunneling mechanism should be standardized in the > IETF. > - Tunneling mechanisms can be used in 3GPP networks, and only > generic recommendations are given in this document. More > details can be found, for example, in [ISP-sa]. > - We recommend that a detailed solution for the general > SIP/SDP/media IPv4/IPv6 transition problem will be specified > as soon as possible as a task within the SIP WGs in > the IETF. > ----------- > > Rgds, > -Juha W.- > From owner-v6ops@ops.ietf.org Wed May 26 13:45: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 NAA01724 for ; Wed, 26 May 2004 13:45:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT2Rt-000LCS-Cy for v6ops-data@psg.com; Wed, 26 May 2004 17:44:17 +0000 Received: from [4.14.91.19] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT2Ro-000LAm-0W for v6ops@ops.ietf.org; Wed, 26 May 2004 17:44:12 +0000 Received: from eaglet (127.0.0.1:3706) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 May 2004 10:44:10 -0700 From: "Tony Hain" To: "'Liu Min'" , "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Wed, 26 May 2004 10:44:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <000a01c44338$2b74c900$af28a1d3@ThinkPadX31> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRDOPKQzbCahx3ZR9yYKuDf730oSAAB4bnQ X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Liu Min wrote: > I omit the previous letters since it has been a chaos of multiple re-mail. > My answers are as following: > > 1. Although silkroad is similar as tunnel broker based solution, it is not > a > tunnel broker. Tunnel broker is not presented to solve NAT transversal but > to provide one easy way to configure and maintain many different tunnels. > Tunnel broker focuses on the lifecycle management of tunnels, not the > tunnel > technologies. From this point, silkroad can also be managed by tunnel > broker. If you really want to compare it to tunnel broker, the SAR will > play > the role of both TB and TS in tunnel broker. SN can help SARs route > between > each other, which is a novel entity in tunnel broker scheme. > > 2. Silkroad and Teredo are two solutions to the same problem: tunneling > IPv6 > packets through NAT devices. Silkroad is a tunnel broker, though it tries to optimize the path. The earlier messages on the thread made the case that Silkroad handles symmetric nat, so it is better than Teredo. In the claimed high value case of symmetric nat, there appears to be no architectural difference between Silkroad and any other generic tunnel broker. When it is not possible to optimize the path, and a stable prefix forces all packets for a given node have to flow through a specific tunnel endpoint, it is a tunnel broker. Please provide a clear problem statement, with an explanation of what is different between Silkroad and a generic tunnel broker. You are focused on nat traversal, and seem to be ignoring the point that tunnel brokers also solve that problem. In other words, nat traversal is not a problem that needs solving, so Silkroad brings nothing to the table if that is all it is intended to do. > Silkroad assumes the SC know the IPv4 address > of the SN. And Teredo also needs some configuration at setup. "Before > using > the Teredo service, the client must be configured with: > - the IPv4 address of a server. > If secure discovery is required, the client must also be configured > with: > - a client identifier, > - a secret value, shared with the server." > > 3. In your letter you said "Yes the mechanism will find the least common > capabilities, but what was the point? The result is limited to a very > specific address (and possibly port) over a short period of time. Every > transfer will required a different decision, so the SC is very likely to > spend more time trying to figure out the optimization than actually > transferring data. The whole mechanism will be simpler if you just assume > that the SA will be in the path, because it will be more often than not." > > I think you misunderstand my point. Not every transfer will required a > different decision. No matter how many NATs there are, you need not judge > each NAT's type. > The NAT type determining process will only work once. That assumes there is only one nat in the path and it is close to the SC. When routing changes upstream, the new path may include a different type of nat which invalidates the earlier decision (consider a nat connection to a network that uses address space from a primary provider, then uses a nat connection to a backup provider, which nat was the decision based on? How do you know? Was the backup path in use when the SC started? What if adjacent SCs start under different routing and make different decisions?). Your perspective also seems to ignore the fact that there are two ends to every conversation, and the decision at one end will not automatically be valid for all other potential endpoints. > Then you will know > could you receive a packet from an arbitrary address or only an address to > which you have sent a packet, or something like this. In our draft, the > process is a reference to STUN. In Teredo, the process is similar. In > addition, SC only needs to determine the NAT type when it starts silkroad > service for the first time. Anyway, the route optimization is optional. It > is recommended for cone NAT users to do optimization. Other NAT users are > recommended to choose to do route optimization only if they want to > transmit > large bulk traffic. Like I said, there is no point in the optimization since it will take longer to set up than the vast majority of transfers. Since the only real value Silkroad provides over every other tunnel broker is this path optimization, it needs to do that efficiently enough to make a difference. > > 4. Silkroad Router Advertisement is a private packet format defined in > silkroad for SN to indicate the IPv4 address of SAR to SC. It is not the > IPv6 RA in RFC2461. So it is not using IPv6 function to provide IPv4 > information. If it causes some confusion, I will change the packet name in > the next version. In fact, the interaction between the SC and the SN could > go on different means, such as http. Silkroad Router Advertisement is just > one alternative way, which is not a necessary part in silkroad. > > 5. There are many works ongoing for silkroad. We will refine our > draft/prototype in the following versions and you and anyone else are > welcome to give any comments and suggestions. A major problem with the Silkroad draft is that basic required steps are very unclear due to the array of optional ideas. In the email thread, the claimed problem is nat traversal, but that is not a problem that needs solving in yet another different way from the existing mechanisms. As far as I can tell, what Silkroad does provide is the prefix stability of a tunnel broker, coupled with the route optimization characteristic of Teredo. As a concept that appears to have value. The actual mechanics described in the draft completely ignore the operational realities of routing changes, and the need for path determination on every connection due to untested topology. The Internet is not a contained, strictly hierarchical, low latency lab scale network, so deployable mechanisms are required to deal with the messy details of continually shifting topology, planned & unplanned outages of single nodes, abuse tracking and mitigation, and such non-technical details as irrational business necessities. While the idea of route optimized tunnel brokers has merit, the current Silkroad draft appears to be lacking in all those areas. For the Silkroad draft to make progress, it needs to clearly state its goal and differences from existing technologies, sort all the mandatory basics up front, then get realistic about continuous change and scale. Tony > > Liu Min > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Wednesday, May 26, 2004 3:53 AM > > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > > Cc: v6ops@ops.ietf.org > > Subject: RE: Teredo vs Silkroad > > > > Liu Min wrote: > > > Thank you for your comments. You have mentioned some problems which > > > are common to NAT transversal mechanism, such as the security and > > > multiple NATs in a path. I will try to answer the questions in-line. > > > Any suggestions will > > > be appreciated. > > > > > > > -----Original Message----- > > > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] > > > > On Behalf Of Tony Hain > > > > Sent: Tuesday, May 25, 2004 2:30 AM > > > > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > > > > Cc: v6ops@ops.ietf.org > > > > Subject: RE: Teredo vs Silkroad > From owner-v6ops@ops.ietf.org Wed May 26 17:06: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 RAA16762 for ; Wed, 26 May 2004 17:06:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT5Ze-0007nb-AJ for v6ops-data@psg.com; Wed, 26 May 2004 21:04:30 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT5ZY-0007mO-Vo for v6ops@ops.ietf.org; Wed, 26 May 2004 21:04:25 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4QL4OWE005230 for ; Wed, 26 May 2004 22:04:24 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA07293 for ; Wed, 26 May 2004 22:04:22 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4QL4LU17686 for v6ops@ops.ietf.org; Wed, 26 May 2004 22:04:21 +0100 Date: Wed, 26 May 2004 22:04:21 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Message-ID: <20040526210421.GJ10112@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1085429789.4626.51.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, I think all four cases should be considered. Whether you consider b) and c) depends on whether you think an IPv6-only nodes will be deployed or IPv6-only network infrastructure might be deployed. I think both are happening in some networks now. Not many, but it is happening and that volume will only grow, so we should cater for it. I agree a) and d) are mainstream, and perhaps the wording can reflect that, but we should consider all four possibilities in ent-scenarios. Tim On Tue, May 25, 2004 at 08:43:17AM +0300, Pekka Savola wrote: > On Mon, 24 May 2004, Jonne Soininen wrote: > > these are scenarios and the scenarios should describe the possible > > scenarios that do make technically sense and hence, are possible to > > be deployed. I do not see why not all of the scenarios would not > > make sense. > > Enumerating the possibilities is of course fine. > > I was mainly objecting to Tim's wording: > > If section 4 were removed a requirement subsection would be needed in > section 5 to state that legacy interworking **is required** for four > main modes: > > (emphasis mine) > > s/is required/needs to be considered/ (for example) and it would be > fine by me.. > > > On Mon, 2004-05-24 at 15:29, ext Pekka Savola wrote: > > > On Wed, 12 May 2004, Tim Chown wrote: > > > > I believe this is ready. > > > > > > > > Alain's point is valid, but I don't believe changes would impact the > > > > usefulness of the draft as is. If section 4 were removed a requirement > > > > subsection would be needed in section 5 to state that legacy interworking > > > > is required for four main modes: > > > > > > > > a) dual-stack <-> v4 or v6 only > > > > b) v4 only <-> v6 only > > > > c) v4 <-> v4 over v6 infrastructure > > > > d) v6 <-> v6 over v4 infrastructure > > > > > > Isn't this a list of all the possible combinations? > > > > > > The point here is, do we need to care for all of these combinations? > > > For example, in the unmanaged networks, b) was considered out of > > > scope, and that's also recommended against in the 3GPP. c) is also > > > something that I'm not sure there is yet consensus whether this is a > > > reasonable approach at this point. > > > > > > One goal of the scenarios/analysis work is to try to identify the > > > actual, critical, mainstream scenarios which call of certain kind of > > > interworking or mechanisms. I think at least a) or d) fulfill these > > > criteria, but b) and c) might be so-and-so, depending on how you > > > phrase it and which kind of techniques one might have in mind > > > applying.. > > > > > > > On Wed, May 12, 2004 at 06:20:11PM +0300, Jonne Soininen wrote: > > > > > Hi everybody, > > > > > > > > > > this is a WG Last Call for comments on sending > > > > > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network > > > > > Scenarios" to the IESG for consideration as Informational: > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-02.txt > > > > > > > > > > > > > > > Please review these documents, and send your feedback to the > > > > > list. Please also indicate whether or not you believe that this > > > > > document is ready to go to the IESG. > > > > > > > > > > The last call will end in two weeks, on May 26th. > > > > > > > > > > Pekka & Jonne > > > > > > > > > > > > > > > > > > -- > 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-v6ops@ops.ietf.org Wed May 26 17:18: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 RAA17974 for ; Wed, 26 May 2004 17:18:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT5mQ-000A9A-Kr for v6ops-data@psg.com; Wed, 26 May 2004 21:17:42 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT5mM-000A77-Vo for v6ops@ops.ietf.org; Wed, 26 May 2004 21:17:39 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4QLHcWE005413 for ; Wed, 26 May 2004 22:17:38 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA07476 for ; Wed, 26 May 2004 22:17:37 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4QLHb917979 for v6ops@ops.ietf.org; Wed, 26 May 2004 22:17:37 +0100 Date: Wed, 26 May 2004 22:17:37 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Message-ID: <20040526211737.GL10112@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <33639.67.84.243.204.1085403691.squirrel@webmail.nac.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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-v6ops@ops.ietf.org Precedence: bulk Pekka, I think ent-scenarios as a draft has been floating around for some time, and anyone could have offered new or different scenarios if the ones included weren't deemed representative. I'm not sure that changing a scenario would make a significant difference. The draft is a difficult one. The scope is simply *huge*, and thus the text can always be expanded or improved. I think what we have, and the specific scenarios, are good enough. Let's move on. Regards your queries, the meanings seem clear to me, re "at secure", "ad hoc creation" and "bolt on". The language could perhaps be expanded, but I don't think the meaning is ambiguous, so again let's move on? I do plan to write up a campus scenario (and analysis) separately (so I don't hold up the main thrust), which will be drawn from 6NET experience (you can look at D2.3.3-bis from 6NET yourself if curious as to the nature of that scenario text). Tim On Tue, May 25, 2004 at 09:29:28AM +0300, Pekka Savola wrote: > On Mon, 24 May 2004 rfgraveman@nac.net wrote: > > > I think Example network C, a security defense network, is not > > > mainstream enough to be applicable to be investigated in the > > > scenarios. There are probably 1, 5 or 10 such networks in the world. > > > We should be focusing on more common scenarios (even addressing > > > "80/20" would be good). [I have a few specific comments for > > > clarification within this example, but I'll send them if this example > > > is not replaced by something else.] > > > ... > > > > OTOH, some of these networks are large, and they buy a lot of equipment, > > so some major vendors take their requirements quite seriously. Therefore, > > I would be against dropping this case. We can discuss further whether this > > is exactly the right characterization, however. > > I can see the argument why this needs to be considered .. money is a > language everybody understands .. but I'm concerned that this would be > painted as a "model" for v6 deployment, i.e., that other enterprises > which have very little in common with such defense networks would > start mimicking their deployment strategies just because those are the > ones described in our documents. This is why I'm worried about > keeping this here. > > But let's hear if there are more opinions about this. > > In any case, if it stays, this could probably be clarified a bit, > like: > > A Security Defense Network Operation: > > ==> add here something like: > > Note that these kind of networks are uncommon and unfit to be a > model or example for deployment for enterprises in general. > However, due to their importance to the vendor community, their > requirements should be considered explicitly. > > ... > > - External network required at secure specific points. > > ==> I had hard time parsing this, "at secure"? Did you mean: > > - External network is required, but only at specific, secure, > exit points. > > ... > > - Network must be able to absorb ad-hoc creation of sub-Networks. > > ==> I didn't quite understand what this meant, please clarify. (I've > a hunch, but..) > > - Entire parts of the Network are completely mobile. > > ==> are we talking about a mobile network (NEMO sense), or nomadic > network (network de-attaches, moves, network re-attaches) ? The > latter would at least be feasible, while the former may be a bit more > problematic. Maybe worth clarifying a bit.. > > - Network must be able to bolt on to the Internet to share > bandwidth as required from Providers. > > ==> "bolt on to the Internet" ? I wasn't sure what this was trying to > say -- that the network must be able to multihome for load-sharing > purposes, or...? > > - Nodes must be able to access IPv4 legacy applications over IPv6 > network. > > ==> are these internal legacy apps, external ones, or possibly both? > Isn't this assumptive about IPv6 deployment ("v6-only") and unfit for > requirements? > > -- > 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-v6ops@ops.ietf.org Wed May 26 17:24: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 RAA18659 for ; Wed, 26 May 2004 17:24:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT5s4-000B21-4n for v6ops-data@psg.com; Wed, 26 May 2004 21:23:32 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT5s2-000B1g-08 for v6ops@ops.ietf.org; Wed, 26 May 2004 21:23:30 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4QLNTWE005483 for ; Wed, 26 May 2004 22:23:29 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA07573 for ; Wed, 26 May 2004 22:23:25 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4QLNPP18118 for v6ops@ops.ietf.org; Wed, 26 May 2004 22:23:25 +0100 Date: Wed, 26 May 2004 22:23:25 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt Message-ID: <20040526212325.GM10112@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <06CAA4D3753C53408D2CE6340B68444205A593F1@vbeexc02.emea.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CAA4D3753C53408D2CE6340B68444205A593F1@vbeexc02.emea.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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,CASHCASHCASH autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I agree with Yanick's points in line (the ones that aren't just "OK" :) Tim On Mon, May 24, 2004 at 11:56:10PM +0200, Pouffary, Yanick wrote: > Hi > > Thanks for the review. Comments in-line. > > Yanick > > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > > Behalf Of Pekka Savola > > Sent: Monday, May 24, 2004 2:23 PM > > To: v6ops@ops.ietf.org > > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt > > > > On 12 May 2004, Jonne Soininen wrote: > > > Hi everybody, > > > > > > this is a WG Last Call for comments on sending > > > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network > > > Scenarios" to the IESG for consideration as Informational: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios- > > 02.txt > > > > Personal comments below. > > > > Seems to be ready after a revision for clarifications etc. -- in any > > case, the most important thing is the _next_ document.. > > > > I think Example network C, a security defense network, is not > > mainstream enough to be applicable to be investigated in the > > scenarios. There are probably 1, 5 or 10 such networks in the world. > > We should be focusing on more common scenarios (even addressing > > "80/20" would be good). [I have a few specific comments for > > clarification within this example, but I'll send them if this example > > is not replaced by something else.] > > > > [YP] I agree with Richard Graveman to keep this example. Please send > you're your comments. > > > I also thought that section 4 could possibly be removed at this point. > > > If it wouldn't be, there are a few clarifications I have scribbed up, > > omitting them now.. > > > > [YP] We all agree > > > substantial: > > ------------ > > > > [Network Infrastructure Component 1, sect 3.2] > > Enterprise Provider Requirements > > - One site vs. multiple sites? > > > > ==> do you refer to _geographical_ sites here, or something else > > (e.g., in the multi6 WG sense)? Maybe add 'geographical' here? > > > > [YP] ok > > > - Leased lines or VPN? > > > > ==> spell out, e.g. to: > > > > - If multiple sites, how is the traffic exchanged securely > between > > them? > > ... > > - What is the IPv6 address assignment plan available > > from the provider? > > > > ==> this should possibly be spelled out a bit, like: > > > > - Do the provider(s) delegate a stable /48 prefix? > > Does the enterprise need more? > > > > [YP] ok > > > ... > > - Will clients be Multihomed? > > > > ==> 'clients'? Spell out a bit, maybe like: > > > > - Is the enterprise multihomed? Which multihoming techniques > are > > supported by the Service provider? > > > > [YP] ok > > > ... > > > > - Is there an external data-center? > > > > ==> I think this needs to be spelled out a bit. Did you mean like: > > > > - Would some enterprise server(s) be housed in the service > > providers' data centers? > > > > [YP] ok > > > ... > > > > ==> add an additional requirement, like: > > > > - Is IPv6 available using the same access links as IPv4, > > or differently? > > > > [YP] ok > > > ... > > > > [Network Infrastructure Component 2] > > > > ==> add a couple of requirements, like: > > > > - Are applications only run in the internal networks? > > [YP] ok > > > - Are ALGs or proxies being used for some applications? > > Would using such be feasible? > > - Are there applications which cannot be proxied or > > upgraded to support IPv6? > > [YP] I think we have this already covered. > > > > > [Network Infrastructure Component 3] > > > > - Is a Tele-commuter work force supported? > > > > ==> reword to be more generic, maybe like: > > > > - Is working remotely (e.g., through VPNs) supported? > > > > [YP] ok > > > ... > > > > - Is inter-site communications required? > > > > ==> I don't quite understand this requirement, because I fail to see > _any_ > > scenario where you wouldn't need to communicate between sites? Could > you > > clarify? > > > > [YP] The enterprise may want to deploy IPv6 within a single site. > > > - Is network mobility used or required for IPv6? > > > > ==> This requirement seems to need a bit more spelling out, as it > isn't > > 100% > > obvious what you're referring to (MIPv6 vs NEMO?), what's the usage > case? > > > > - What are the requirements of the IPv6 address plan? > > > > ==> maybe add a couple of clarifying points here: > > > > - Is there a detailed asset management database, including > hosts, > > IP/MAC addresses, etc.? > > - What is the enterprise' approach to numbering geographically > > separate sites which have their own Service Providers? > > > > [YP] ok - may be > > > ... > > > > - What will be the IPv6 Security policy/procedure? > > > > ==> there should probably be a bit more on this..? maybe at least > like: > > > > - Are separate or same firewalls, IDS systems, etc. used for > IPv6? > > Which part of the traffic is encrypted using IPsec and how? > > > > [YP] your clarifications are useful but do we need to be that specific? > > > Network Infrastructure Component 4 > > Enterprise Network Management System > > - Performance Management Required? > > - Network Management Applications Required? > > - Configuration Management Required? > > - Policy Management and Enforcement Required? > > - Security Management Required? > > - Management of Transition Tools and Mechanisms? > > > > ==> these should probably be spelled out a bit more, because at least > I > > didn't have much idea what all of these included? > > > > [Example Network A, sect 3.3] > > > > - ISP does not offer IPv6 service. > > - Private Leased Lines no Service Provider Used > > > > ==> is the first really often the case? If you're a suffiently big > > enterprise, I think at least in Europe there are already quite a few > ISPs > > willing to give you service. (note: s/ISP does/ISPs do/ .. as it has > > multiple ISPs?) > > > > [YP] yes it is the case. We have a lot of enterprises out there which > are far behind with regard to internet revolution. > > > ==> I don't quite understand the second bullet point? do you mean > that > > the > > site has just one ISP, and the rest are connected using leased lines > to > > the > > "primary" ISP, and they don't have a direct connectivity at all? > > > > I'm not sure if this is any longer the "mainstream" scenario, because > the > > net traffic is probably so high that the enterprises don't want to pay > > $$$$ > > for transporting all their traffic to their HQ using leased lines, but > to > > throw it out to their ISP immediately (and tunnel internal traffic > with > > VPNs, or leased lines). > > > > [YP] I don't agree. Yes this is a cost issue hence why they are looking > at deploying IPv6 as a replacement solution. > > > - All routers and switches are upgradeable to IPv6. > > - Existing firewalls can be upgraded to support IPv6 rules. > > > > ==> are these mainstream scenarios? What does a switch's IPv6 upgrade > > mean > > (is it L3 switch? or management functions?) > > > > - IPv4 Private address space is used within the enterprise. > > > > ==> the enterprise already had PI space (from the above), but still > uses > > private address space internally -- any particular reason why? > > > > > DNS will now have to support both IPv4 and IPv6 DNS records and the > > enterprise will need to determine how the DNS is to be managed and > > accessed, and secured. The range of DNS operational issues are out > > of scope for this work. [...] > > > > ==> here, it would be good to refer to > > draft-ietf-dnsop-ipv6-dns-issues-07.txt, and possibly add at the end > > something like: > > > > [YP] ok > > > These operations include at least: > > - configuring IPv6 DNS servers as resolvers on IPv6(-only) hosts, > > - selecting a method to insert AAAA/PTR records in the DNS, > > - managing the DDNS reverse/forward updates processes, if used, > > - providing IPv6 transport capability in the recursive internal > > DNS servers, and > > - managing the IPv6 capability in the authoritative servers, and > > configuring the AAAA records at the delegator of the DNS zones. > > > > .... > > > > The choice of interior routing protocols have an impact on how the > > routing tables will be handled: some such as OSPF will have the > > ships-in-the-night paradigm, others such as ISIS are integrated. > This > > has an impact on the topology and the management of the network. > > > > ==> I don't really understand what you mean with the sentence about > OSPF > > vs > > ISIS. Do you mean that w/ OSPF you'd use separately OSPFv2 and > OSPFv3, > > and with IS-IS just one process? > > > > Note that this discussion could probably be just a summary of > > draft-ietf-v6ops-isp-scenarios-analysis-02.txt section 4.3.1 and the > > Appendix A. (We should refer to that document here at least.) > > > > IPv6 capable routers should be monitored to ensure the router has > > sufficient storage for both IPv6 and IPv4 route tables. Existing > > network design principles to limit the number of routes in the > > network, such as prefix aggregation, become more critical with the > > addition of IPv6 to an existing IPv4 network. > > > > ==> I do not think monitoring the routers for sufficient v4/v6 route > > table storage is an operationally important issue, clearly not more > son > > than > > monitoring v4 route tables today, at least. Maybe just remove this > first > > sentence or even the whole paragraph. > > > > [YP] Exactly the point is you need to do the same. I think we should > keep the paragraph as is. > > > ==> maybe add at the end add something like: > > > > Decisions wrt. routing include at least: > > - whether IPv4 and IPv6 routing topologies will be different, > > affecting the decision on which routing protocols to use, > > - how redundancy is ensured if tunneling is used, and > > - which tools are to be used to monitor the IPv6 infrastructure. > > > > [YP] ok > > > 5.3 Autoconfiguration > > > > IPv6 introduces the concept of stateless autoconfiguration in > > addition to stateful autoconfiguration. The enterprise will have > to > > determine the best method of autoconfiguration, for their network. > > The enterprise will need to determine if they are to use stateless > or > > stateful autoconfiguration, and how autoconfiguration is to operate > > for DNS updates. The enterprise will need to determine how prefix > > delegation is done from their upstream provider and how those > > prefixes are cascaded down to the enterprise IPv6 network. The > > policy for DNS or choice of autoconfiguration is out of scope for > > this document. > > > > ==> this section should probably be generalized to be something like > > 'Configuration of Hosts [or: .. of Infrastructure and Hosts]' > > (and generalize the autoconfiguration a bit more > > in the rest of the paragraph as well) > > > [YP] ok > > > ==> remove ", for their network", as everything is done for their > network > > in > > any case. > > ==> dynamic prefix delegation inside the enterprise may not be a > really > > feasible option, but in any case, I'd probably add something like: > > "; the choices are to do this manually, or using a dynamic protocol" > > to better spell it out. > > ==> One might consider adding at the end something on whether an asset > > management database is being used, and the choices for configuring > other > > information on the hosts (e.g., DNS servers, proxy servers, etc.etc.). > > > > [YP] We will try to rework this > > > > 5.4 Security > > > > Current existing mechanisms used for IPv4 to provide security need > to > > be supported for IPv6 within the enterprise. IPv6 should create no > > * new security concerns for IPv4. The entire security infrastructure > > * currently used in the enterprise needs to be analyzed against IPv6 > > * deployment effect and determine what is supported in IPv6. Users > > should review other security IPv6 network infrastructure work in > the > > * IETF and within the industry on going at this time. Users will > have > > * to work with their platform and software providers to determine > what > > * IPv6 security network infrastructure components are supported. The > > security filters and firewall requirments for IPv6 need to be > > determined by the enterprise. The policy choice of users for > security > > is out of scope for this document. > > > > ==> there is considerable overlap with two sentences above, marked > with > > '*'. > > I suggest removing one of them and expanding the other slightly. > > > > ==> you should probably refer to some security documents here, e.g., > > draft-savola-v6ops-security-overview-02.txt > > > > ==> add at the end maybe something like: > > > > At the very least, one has to consider for example: > > - whether the same access control/IDS policies are to be used for > > IPv6 as with IPv4, and whether these are to be handled by the > > same or different equipment/software, > > - how keying and/or certificates are managed, > > - how VPNs are controlled, > > - whether RFC3041 temporary addresses are to be used and to > > what extent if so, > > - whether there are to be internal access control points, and > > - if tunneling techniques are used, how this affects the site > > security, and how site must be secured to make tunneling > secure. > > > > [YP] ok > > > 5.6 Network Management > > > > > > The addition of IPv6 network infrastructure components will need to > > be managed by the enterprise network operations center. Users will > > need to work with their network management platform providers to > > determine what for IPv6 is supported during their planning for IPv6 > > adoption, and what tools are available in the market to monitor the > > network. > > > > ==> remove 'in the market' -- appears redundant here? > > ==> maybe add something like: > > > > At least, one should consider: > > - whether IPv6-capable devices can be managed or monitored using > > IPv4, and what must be done if that is not possible, and > > - how IPv6 infrastructures are being monitored? > > > > > > 5.7 Address Planning > > > > The address space within the enterprise will need to be defined and > > coordinated with the routing topology of the enterprise network. > It > > is also important to identify the pool of IPv4 address space > > available to the enterprise to assist with IPv6 transition methods. > > > > ==> I don't think the "pool of IPv4 address space" is all that > > relevant consideration here, as it hints at the use of IPv6-only > > infrastructures, NAT-PT, and the like. > > [YP] don't agree. The availability of IPv4 address space will trigger > the choice of deployment techniques. It is very relevant. > > > ==> in any case, I think there is one thing that should be explicitly > > called > > out: Whether the site wants to consider whether this new kind of local > > addressing is used for v6 or not. > > > > [YP] ok > > > For inter-domain use, sites may choose to migrate IPv4 multicast > > applications to SSM, for which no reverse path discovery method is > > required. > > > > ==> ", for ..." part is incorrect and out of context, replace with > > something > > like: ", which simplifies the multicast architecture, but requires > that > > the > > applications specify the multicast transmission source(s). > > > > ==> Maybe add a new paragraph: > > > > The enterprises also need to consider whether IGMP/MLD snooping or > > similar solutions to reduce the multicast flooding is > > required: this may be especially important if the subnets are > large, > > or multicast is used extensively. > > > > 5.9 Multihoming > > > > > > At this time, current IPv6 allocation policies are mandating the > > allocation of IPv6 address space from the upstream provider. If an > > enterprise is multihomed, the enterprise will have to determine how > > they wish to support multihoming. This also is an area of study > > within the IETF and work in progress. > > > > ==> I think it would be appropriate to describe RFC3178 model of > > multihoming > > very briefly, e.g., like in section 5.6 in > > draft-ietf-v6ops-isp-scenarios-analysis-02.txt > > > > [YP] ok > > > 7. References > > 7.1 Normative References > > > > None at this time. > > [...] > > > > ==> please add a lot more explicit informative / normative references > to > > the > > subject which were discussed. > > > > [YP] ok > > > > > > semi-editorial > > -------------- > > > > [Scenario 2 in sect 3.1] > > Scenario 2: Enterprise with an existing IPv4 network wants to > deploy a > > set of particular IPv6 "applications" (application is > > voluntarily loosely defined here, e.g. peer to peer). > > The IPv6 deployment is limited to the minimum required > to > > operate this set of applications. > > > > ==> I don't think it's good to say "minimum" here, because there is no > > reason to restrict it to the absolute minimum required. The point > here is > > just that v6 deployment doesn't need to be _larger_ than required to > > operate > > the set of applications. > > > > Maybe reword: s/is limited to/does not need to be more extensive than/ > > > > [YP] ok > > > editorial > > --------- > > > > IPv6 Enterprise Network Scenarios > > > > ==> maybe rename to something like 'Enterprise Networks IPv6 > Transition > > Scenarios' to be more in line with the rest of the document? > > > > Enterprise Network - A network that has multiple internal links, > > one or more router connections, to one or > > more > > Providers and is actively managed by a > > network > > operations entity. > > > > ==> align the text for those lines which were broken to multiple lines > > by originally too many chars/line? (same also later) > > > > Provider - An entity that provides services and > > connectivity to the Internet or > > other private external networks for the > > enterprise network. > > > > ==> isn't 'Provider' a slightly too terse (and ambiguous) term? > > Maybe 'Service Provider' or abbreviated SP if necessary, instead? > > > > IPv6 only - A node or network capable of supporting > only > > IPv6. This does not imply an IPv6 only > > stack, in this document. > > > > ==> the last sentence should probably be reworded to be clearer. Did > you > > mean something like: > > In the context of this document, a > > dual-stack node which has disabled IPv4 is > > considered IPv6 only. > > > > 3.2 Scenarios Network Infrastructure Components > > > > ==> reword to: 'Network Infrastructure Components for Scenarios' ? > > > > - Are the nodes moving within the enterprise network? > > - Are the nodes moving outside and inside the enterprise > > network? > > > > ==> these should probably be shifted left about 3-4 spaces? > > > > - The DHCP server to update naming records for dynamic desktops > > uses > > > > ==> reword maybe to: > > > > - The DHCP server updates the DNS records for dynamic desktops > > with DDNS. > > > > Document Acknowledgments > > > > ==> s/Document // > > > > Authors-Design Team Contact Information > > > > ==> maybe reword to "Authors' Addresses" as it's the regular format? > > > > ==> this is pretty long. Two possibilities to summarize this a bit: > > a) add an "Editor's Address" section, with just Jim's contact info, > in > > full; Keep "Authors' Addresses" section for the rest, but mention only > > names, affiliations and the email addresses. > > b) just take out other info for the non-editors as names, > affiliations > > and > > email addresses. > > > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > Thanks > Yanick > From owner-v6ops@ops.ietf.org Thu May 27 03:39: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 DAA05492 for ; Thu, 27 May 2004 03:39:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTFSO-000Ay3-8y for v6ops-data@psg.com; Thu, 27 May 2004 07:37:40 +0000 Received: from [159.226.39.4] (helo=mail.ict.ac.cn) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BTFSM-000AxD-DW for v6ops@ops.ietf.org; Thu, 27 May 2004 07:37:38 +0000 Received: (qmail 931 invoked from network); 27 May 2004 07:22:55 -0000 Received: from unknown (HELO ThinkPadX31) (159.226.39.104) by mail.ict.ac.cn with SMTP; 27 May 2004 07:22:55 -0000 From: "Liu Min" To: "'Tony Hain'" Cc: Subject: RE: Teredo vs Silkroad Date: Thu, 27 May 2004 15:37:31 +0800 Message-ID: <000b01c443bd$7b3a8850$4b74a8c0@ThinkPadX31> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Tony Hain > Sent: Thursday, May 27, 2004 1:44 AM > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: Teredo vs Silkroad > > Liu Min wrote: > > I omit the previous letters since it has been a chaos of multiple > > re-mail. My answers are as following: > > > > 1. Although silkroad is similar as tunnel broker based solution, it > > is not a tunnel broker. Tunnel broker is not presented to solve NAT > > transversal but to provide one easy way to configure and maintain > > many different tunnels. Tunnel broker focuses on the lifecycle > > management of tunnels, not the tunnel > > technologies. From this point, silkroad can also be managed by tunnel > > broker. If you really want to compare it to tunnel broker, the SAR will > > play > > the role of both TB and TS in tunnel broker. SN can help SARs route > > between > > each other, which is a novel entity in tunnel broker scheme. > > > > 2. Silkroad and Teredo are two solutions to the same problem: > > tunneling IPv6 packets through NAT devices. > > Silkroad is a tunnel broker, though it tries to optimize the path. The > earlier messages on the thread made the case that Silkroad handles > symmetric nat, so it is better than Teredo. In the claimed high value > case of symmetric nat, there appears to be no architectural difference > between Silkroad and any other generic tunnel broker. When it is not > possible to optimize the path, and a stable prefix forces all packets > for a given node have to flow through a specific tunnel endpoint, it > is a tunnel broker. > > Please provide a clear problem statement, with an explanation of what > is different between Silkroad and a generic tunnel broker. You are > focused on nat traversal, and seem to be ignoring the point that > tunnel brokers also solve that problem. In other words, nat traversal > is not a problem that needs solving, so Silkroad brings nothing to the > table if that is all it is intended to do. From earlier discussion in this mailing list about whether to go forward with Teredo, many people think that NAT traversal in IPv6 transition is a very important issue and should be solved. I don't think if silkroad tries to solve this problem, it will bring nothing to the table. > > > Silkroad assumes the SC know the IPv4 address > > of the SN. And Teredo also needs some configuration at setup. > > "Before using the Teredo service, the client must be configured > > with: > > - the IPv4 address of a server. > > If secure discovery is required, the client must also be configured > > with: > > - a client identifier, > > - a secret value, shared with the server." > > > > 3. In your letter you said "Yes the mechanism will find the least > > common capabilities, but what was the point? The result is limited > > to a very specific address (and possibly port) over a short period > > of time. Every transfer will required a different decision, so the > > SC is very likely to spend more time trying to figure out the > > optimization than actually transferring data. The whole mechanism > > will be simpler if you just assume that the SA will be in the path, > > because it will be more often than not." > > > > I think you misunderstand my point. Not every transfer will required > > a different decision. No matter how many NATs there are, you need > > not judge each NAT's type. The NAT type determining process will > > only work once. > > That assumes there is only one nat in the path and it is close to the > SC. No, I never assume there is only one NAT in the path. > When routing changes upstream, the new path may include a different > type of nat which invalidates the earlier decision (consider a nat > connection to a network that uses address space from a primary > provider, then uses a nat connection to a backup provider, which nat > was the decision based on? How do you know? Was the backup path in use > when the SC started? What if adjacent SCs start under different > routing and make different decisions?). Your perspective also seems to > ignore the fact that there are two ends to every conversation, and the > decision at one end will not automatically be valid for all other > potential endpoints. > > > Then you will know > > could you receive a packet from an arbitrary address or only an > > address to which you have sent a packet, or something like this. In > > our draft, the process is a reference to STUN. In Teredo, the > > process is similar. In addition, SC only needs to determine the NAT > > type when it starts silkroad service for the first time. Anyway, the > > route optimization is optional. It is recommended for cone NAT users > > to do optimization. Other NAT users are recommended to choose to do > > route optimization only if they want to transmit large bulk traffic. > > Like I said, there is no point in the optimization since it will take > longer to set up than the vast majority of transfers. Since the only > real value Silkroad provides over every other tunnel broker is this > path optimization, it needs to do that efficiently enough to make a > difference. If the SC is behind a Full cone NAT, it could finish route optimization immediately. For other NAT types, there should be more actions to setup the corresponding mapping in the NAT. For the same reason, Teredo needs to send bubbles when the NAT type is not Full cone NAT. It comes from the inherent characteristics of these NAT types. > > > > > 4. Silkroad Router Advertisement is a private packet format defined > > in silkroad for SN to indicate the IPv4 address of SAR to SC. It is > > not the IPv6 RA in RFC2461. So it is not using IPv6 function to > > provide IPv4 information. If it causes some confusion, I will change > > the packet name in the next version. In fact, the interaction > > between the SC and the SN could go on different means, such as http. > > Silkroad Router Advertisement is just one alternative way, which is > > not a necessary part in silkroad. > > > > 5. There are many works ongoing for silkroad. We will refine our > > draft/prototype in the following versions and you and anyone else > > are welcome to give any comments and suggestions. > > A major problem with the Silkroad draft is that basic required steps > are very unclear due to the array of optional ideas. In the email > thread, the claimed problem is nat traversal, but that is not a > problem that needs solving in yet another different way from the > existing mechanisms. As far as I can tell, what Silkroad does provide > is the prefix stability of a tunnel broker, coupled with the route > optimization characteristic of Teredo. As a concept that appears to > have value. The actual mechanics described in the draft completely > ignore the operational realities of routing changes, and the need for > path determination on every connection due to untested topology. The > Internet is not a contained, strictly hierarchical, low latency lab > scale network, so deployable mechanisms are required to deal with the > messy details of continually shifting topology, planned & unplanned > outages of single nodes, abuse tracking and mitigation, and such > non-technical details as irrational business necessities. While the > idea of route optimized tunnel brokers has merit, the current Silkroad > draft appears to be lacking in all those areas. For the Silkroad draft > to make progress, it needs to clearly state its goal and differences > from existing technologies, sort all the mandatory basics up front, > then get realistic about continuous change and scale. Ok, we will explicitly indicate the mandatory basics for Silkroad and improve the security consideration in the next version. Liu Min From owner-v6ops@ops.ietf.org Thu May 27 08:05: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 IAA18786 for ; Thu, 27 May 2004 08:05:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTJap-000JED-O7 for v6ops-data@psg.com; Thu, 27 May 2004 12:02:39 +0000 Received: from [193.81.246.11] (helo=eins.siemens.at) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTJTm-000HVn-Jx for v6ops@ops.ietf.org; Thu, 27 May 2004 11:55:22 +0000 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i4RBtLEP018931 for ; Thu, 27 May 2004 13:55:21 +0200 Received: from vies141a.sie.siemens.at (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i4RBtKgP020345 for ; Thu, 27 May 2004 13:55:21 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 27 May 2004 13:55:38 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AB9B@viee10pa.erd.siemens.at> From: Grubmair Peter To: "V6ops_Discussion (E-mail)" Subject: draft-daniel-dhc-ipv6in4-opt-03.txt Date: Thu, 27 May 2004 13:51:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,DEAR_SOMETHING autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Dear Sirs, I highly appreciated finding your draft concerning "DHCP Option for Configuring IPv6-over-IPv4 Tunnels" at IETF. To my mind this is one of the simplest form of a first transition for mobile (GPRS) operators to supply IPv6 to their customers. After finding the tunnel endpoint via your DHCP option a dual stack mobile phone can do autoconfiguration (or DHCPv6) accros the tunnel and obtain a globally unique IPv6 address, allthough its IPv4 address is only private. (no DAD is needed as link-local address is constructed from IPv4 address, which is unique within operators area). tunnel establishment at operator side could be done with adhoc mode as described in >>Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)<< (draft-savola-v6ops-conftun-setup-02.txt) this could be the m I hope that your suggestion evolves to an RFC soon. Best regards Peter Grubmair From owner-v6ops@ops.ietf.org Thu May 27 08:28: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 IAA20551 for ; Thu, 27 May 2004 08:28:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTJyj-000Mr3-9H for v6ops-data@psg.com; Thu, 27 May 2004 12:27:21 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTJyh-000Mqj-Sp for v6ops@ops.ietf.org; Thu, 27 May 2004 12:27:20 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4RCR2S14139; Thu, 27 May 2004 15:27:02 +0300 (EET DST) X-Scanned: Thu, 27 May 2004 15:27:01 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4RCR1UZ032443; Thu, 27 May 2004 15:27:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00GfWnB9; Thu, 27 May 2004 15:26:20 EEST 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 i4RCQJH10402; Thu, 27 May 2004 15:26:19 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 May 2004 15:26:18 +0300 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: draft-daniel-dhc-ipv6in4-opt-03.txt Date: Thu, 27 May 2004 15:26:17 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE3A5@esebe005.ntc.nokia.com> Thread-Topic: draft-daniel-dhc-ipv6in4-opt-03.txt Thread-Index: AcRD451fIyLRmkp9SgqqKCuJSDHXywAAVY4A From: To: , X-OriginalArrivalTime: 27 May 2004 12:26:18.0060 (UTC) FILETIME=[CF78F8C0:01C443E5] 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,DEAR_SOMETHING, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Peter! There is also a simpler, usable mechanism if v6-in-v4 tunneling is = needed in a 3GPP UE: ISATAP. That does not require DHCP implementation = in the UE. See Dave's comments here: http://ops.ietf.org/lists/v6ops/v6ops.2004/msg00814.html BR, -Juha- -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Grubmair Peter Sent: 27 May, 2004 14:52 To: V6ops_Discussion (E-mail) Subject: draft-daniel-dhc-ipv6in4-opt-03.txt Dear Sirs,=20 I highly appreciated finding your draft=20 concerning "DHCP Option for Configuring IPv6-over-IPv4 Tunnels"=20 at IETF.=20 To my mind this is one of the simplest form of a first transition=20 for mobile (GPRS) operators to supply IPv6 to=20 their customers.=20 After finding the tunnel endpoint via your DHCP option=20 a dual stack mobile phone can do autoconfiguration (or DHCPv6)=20 accros the tunnel and obtain a globally unique IPv6 address,=20 allthough its IPv4 address is only private.=20 (no DAD is needed as link-local address is constructed from=20 IPv4 address, which is unique within operators area).=20 tunnel establishment at operator side could be done with adhoc mode as described in >>Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)<< (draft-savola-v6ops-conftun-setup-02.txt) this could be the m I hope that your suggestion evolves to an RFC soon.=20 Best regards=20 Peter Grubmair=20 From owner-v6ops@ops.ietf.org Thu May 27 22:30: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 WAA12990 for ; Thu, 27 May 2004 22:30:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTX6N-000BNO-PP for v6ops-data@psg.com; Fri, 28 May 2004 02:28:07 +0000 Received: from [61.144.161.41] (helo=huawei.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTX5p-000BI7-Ks for v6ops@ops.ietf.org; Fri, 28 May 2004 02:27:46 +0000 Received: from l04955 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HYE00IF9K422V@mta0.huawei.com> for v6ops@ops.ietf.org; Fri, 28 May 2004 10:26:27 +0800 (CST) Date: Fri, 28 May 2004 10:28:43 +0800 From: lidefeng <77cronux.leed0621@huawei.com> Subject: Re: Teredo vs Silkroad To: Tony Hain , "'Liu Min'" , "'Christian Huitema'" , "'Eiffel Wu'" , pekkas@netcore.fi Cc: v6ops@ops.ietf.org Message-id: <001801c4445b$7f9c9f20$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:92.03150 C:7 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Please read in lines. ----- Original Message ----- From: "Tony Hain" To: "'Liu Min'" ; "'Christian Huitema'" ; "'Eiffel Wu'" ; Cc: Sent: Thursday, May 27, 2004 1:44 AM Subject: RE: Teredo vs Silkroad > >Liu Min wrote: > > I omit the previous letters since it has been a chaos of multiple re-mail. > > My answers are as following: > > > > 1. Although silkroad is similar as tunnel broker based solution, it is not > > a > > tunnel broker. Tunnel broker is not presented to solve NAT transversal but > > to provide one easy way to configure and maintain many different tunnels. > > Tunnel broker focuses on the lifecycle management of tunnels, not the > > tunnel > > technologies. From this point, silkroad can also be managed by tunnel > > broker. If you really want to compare it to tunnel broker, the SAR will > > play > > the role of both TB and TS in tunnel broker. SN can help SARs route > > between > > each other, which is a novel entity in tunnel broker scheme. > > > > 2. Silkroad and Teredo are two solutions to the same problem: tunneling > > IPv6 > > packets through NAT devices. > "Tony wrote:" > Silkroad is a tunnel broker, though it tries to optimize the path. The > earlier messages on the thread made the case that Silkroad handles symmetric > nat, so it is better than Teredo. In the claimed high value case of > symmetric nat, there appears to be no architectural difference between > Silkroad and any other generic tunnel broker. When it is not possible to > optimize the path, and a stable prefix forces all packets for a given node > have to flow through a specific tunnel endpoint, it is a tunnel broker. > > Please provide a clear problem statement, with an explanation of what is > different between Silkroad and a generic tunnel broker. You are focused on > nat traversal, and seem to be ignoring the point that tunnel brokers also > solve that problem. In other words, nat traversal is not a problem that > needs solving, so Silkroad brings nothing to the table if that is all it is > intended to do. Defeng Li: I think what we concern is not whether Silkroad is tunnel broker or not,but how to resolve the problem met in the IPv4-IPv6 transition,even Silkroad have some similarity with tunnel broker, it doesn't mean that tunnel broker can resolve the problem which is addressed by Silkroad,in fact, RFC 3053(IPv6 Tunnel Broker, which should be Tunnel Broker Mechanism you always mentioned in your mails) explicitly stated in section "3. Known limitations" that "This mechanism may not work if the user is using private IPv4 addresses behind a NAT box." And Silkroad can resolve the Nat traversal problem very well, I think "the problem statement and the difference between silkroad and a generic tunnel broker" is very very clear. Another point you missed very far is that you insist that "nat traversal is not a problem that needs solving, so Silkroad brings nothing to the table if that is all it is intended to do",maybe it is right only in the scope of United States,where the IPv4 addresses are abundant, however in Asia IPv4 addresses is so scarce that almost every ISP access their customers with private IPv4 addresses. > >Liu Min wrote: > > Silkroad assumes the SC know the IPv4 address > > of the SN. And Teredo also needs some configuration at setup. "Before > > using > > the Teredo service, the client must be configured with: > > - the IPv4 address of a server. > > If secure discovery is required, the client must also be configured > > with: > > - a client identifier, > > - a secret value, shared with the server." > > > > 3. In your letter you said "Yes the mechanism will find the least common > > capabilities, but what was the point? The result is limited to a very > > specific address (and possibly port) over a short period of time. Every > > transfer will required a different decision, so the SC is very likely to > > spend more time trying to figure out the optimization than actually > > transferring data. The whole mechanism will be simpler if you just assume > > that the SA will be in the path, because it will be more often than not." > > > > I think you misunderstand my point. Not every transfer will required a > > different decision. No matter how many NATs there are, you need not judge > > each NAT's type. > > The NAT type determining process will only work once. > "Tony wrote:" > That assumes there is only one nat in the path and it is close to the SC. > When routing changes upstream, the new path may include a different type of > nat which invalidates the earlier decision (consider a nat connection to a > network that uses address space from a primary provider, then uses a nat > connection to a backup provider, which nat was the decision based on? How do > you know? Was the backup path in use when the SC started? What if adjacent > SCs start under different routing and make different decisions?). Your > perspective also seems to ignore the fact that there are two ends to every > conversation, and the decision at one end will not automatically be valid > for all other potential endpoints. Defeng Li: Though there is only one NAT is displayed in the figures of the Silkroad document, is doesn't mean that silkroad only assume there is only one NAT in the path,as long as the NAT can transfer the different IPv4 addresses correctly, several NAT can be deployed in the path,in this case, the IPv6 packet are encapsulated in UDP payload. When routing changes upstream during the session, and the new path may include a different type of NAT,then Silkroad can setup another UDP tunnel which cater for this different type of NAT and delete the old UDP tunnel and the relevant information will be updated in SC and SAR and the IPv6 domain where B belongs,then following IPv6 packets of the session will tunneled in the new UDP tunnel, it is the same as when one route for a destination is failure, then another route is selected to forward the packets. Though the convergence of such information is needed,it isn't be problem can't be resolved, and some of the updation will be done by routing protocols of IPv4/IPv6 domains,Silkroad just need to setup the new tunnel and delete the old tunnel according the updated information. > > Liu Min wrote: > > Then you will know > > could you receive a packet from an arbitrary address or only an address to > > which you have sent a packet, or something like this. In our draft, the > > process is a reference to STUN. In Teredo, the process is similar. In > > addition, SC only needs to determine the NAT type when it starts silkroad > > service for the first time. Anyway, the route optimization is optional. It > > is recommended for cone NAT users to do optimization. Other NAT users are > > recommended to choose to do route optimization only if they want to > > transmit > > large bulk traffic. > "Tony wrote:" > Like I said, there is no point in the optimization since it will take longer > to set up than the vast majority of transfers. Since the only real value > Silkroad provides over every other tunnel broker is this path optimization, > it needs to do that efficiently enough to make a difference. Defeng Li: As stated in the above text,Silkroad not only optimizes the path, but goes beyond the limitation of tunnel broker. It makes differences. > > > Liu Min wrote: > > 4. Silkroad Router Advertisement is a private packet format defined in > > silkroad for SN to indicate the IPv4 address of SAR to SC. It is not the > > IPv6 RA in RFC2461. So it is not using IPv6 function to provide IPv4 > > information. If it causes some confusion, I will change the packet name in > > the next version. In fact, the interaction between the SC and the SN could > > go on different means, such as http. Silkroad Router Advertisement is just > > one alternative way, which is not a necessary part in silkroad. > > > > 5. There are many works ongoing for silkroad. We will refine our > > draft/prototype in the following versions and you and anyone else are > > welcome to give any comments and suggestions. > "Tony wrote:" > A major problem with the Silkroad draft is that basic required steps are > very unclear due to the array of optional ideas. In the email thread, the > claimed problem is nat traversal, but that is not a problem that needs > solving in yet another different way from the existing mechanisms. Defeng Li: Though there is another existing mechanism (Teredo) to resolve the NAT traversal problem,if this mechanism is difficult to deploy and will make the network more complex, why shouldn't we solve it in another simple way,moreover,who said Teredo mechanism is widely accepted? I think it will be better not to make the dicision so hasty.I hope those service providers deployed NAT widely in their network can help to input some information. >"Tony wrote:" > As far as I can tell, what Silkroad does provide is the prefix stability of a tunnel > broker, coupled with the route optimization characteristic of Teredo. As a > concept that appears to have value. The actual mechanics described in the > draft completely ignore the operational realities of routing changes, and > the need for path determination on every connection due to untested > topology. The Internet is not a contained, strictly hierarchical, low > latency lab scale network, so deployable mechanisms are required to deal > with the messy details of continually shifting topology, planned & unplanned > outages of single nodes, abuse tracking and mitigation, and such > non-technical details as irrational business necessities. While the idea of > route optimized tunnel brokers has merit, the current Silkroad draft appears > to be lacking in all those areas. For the Silkroad draft to make progress, > it needs to clearly state its goal and differences from existing > technologies, sort all the mandatory basics up front, then get realistic > about continuous change and scale. > > Tony Defeng Li: I think the route optimization can be done by route protocols, route protocol should solve the problem of multi-homing and the route change or updation,the Silkroad just utilize the optimized route information to maintain(setup or delete) the Silkroad tunnel,fo course Silkroad should cooperate with the route optimization to solve the NAT traversal problem better, but it make no sense to enable Silkroad to do all the work. Defeng Li > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: Wednesday, May 26, 2004 3:53 AM > > > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > > > Cc: v6ops@ops.ietf.org > > > Subject: RE: Teredo vs Silkroad > > > > > > Liu Min wrote: > > > > Thank you for your comments. You have mentioned some problems which > > > > are common to NAT transversal mechanism, such as the security and > > > > multiple NATs in a path. I will try to answer the questions in-line. > > > > Any suggestions will > > > > be appreciated. > > > > > > > > > -----Original Message----- > > > > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] > > > > > On Behalf Of Tony Hain > > > > > Sent: Tuesday, May 25, 2004 2:30 AM > > > > > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi > > > > > Cc: v6ops@ops.ietf.org > > > > > Subject: RE: Teredo vs Silkroad > > > > > From owner-v6ops@ops.ietf.org Fri May 28 03: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 DAA08603 for ; Fri, 28 May 2004 03:07:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTbQj-000AfY-VZ for v6ops-data@psg.com; Fri, 28 May 2004 07:05:25 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTbQh-000AeW-PQ for v6ops@ops.ietf.org; Fri, 28 May 2004 07:05:24 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.0.R) with ESMTP id md50000127753.msg for ; Fri, 28 May 2004 09:06:46 +0200 Message-ID: <60ef01c44482$0e5efd40$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , , , Subject: ICANN Board to implement IPv6 in root servers Date: Fri, 28 May 2004 09:04:43 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 28 May 2004 09:06:46 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Fri, 28 May 2004 09:06:47 +0200 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-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Darticle&sid=3D567 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri May 28 07:45: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 HAA22160 for ; Fri, 28 May 2004 07:45:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTfjr-000AZP-9H for v6ops-data@psg.com; Fri, 28 May 2004 11:41:27 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTfjo-000AYy-LB for v6ops@ops.ietf.org; Fri, 28 May 2004 11:41:24 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 2B4E07F60 for ; Fri, 28 May 2004 13:41:22 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 01490-73 for ; Fri, 28 May 2004 13:41:09 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 7FD8A8036 for ; Fri, 28 May 2004 13:40:53 +0200 (CEST) Subject: draft-massar-v6ops-ayiya-00 From: Jeroen Massar To: v6ops@ops.ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dSwNVXeiTI9vX+AIwzW/" Organization: Unfix Message-Id: <1085744443.9018.267.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 28 May 2004 13:40:45 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org 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-v6ops@ops.ietf.org Precedence: bulk --=-dSwNVXeiTI9vX+AIwzW/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, For the folks that don't follow the i-d-announce@ietf list, below is the announcement and I like to receive comments, especially about: - should the header allow for multiple signature/identity types (and thus lengths) like the current proposal. - or should these be fixed. - formatting/language use (send those to me directly though) a number of them have already been pointed out to me by Christian Stra= uff. I was already pointed out by some quick folks that the use of 'identity' wasn't entirely clear. The identity field 'identifies' the host that is sending the packets to the server side of the tunnel. This allows one to distinguish between multiple hosts behind the same NAT and also allows to be able to not know what the source of the packets would be. The 'password' mentioned in some parts is actually a 'shared secret'. It was pointed out to me that passwords usually are crypted on the remote host so can't be used for MD5-HMAC, thus read 'shared secret' there. Apparently it wasn't clear why to send a hash of the complete packet also from the draft: main reason is to be able to verify that the identity sending this packet really is sending it and that it is unaltered, if people want crypted packets do that in the payload or use a different 'Next Header' which could include an additional small header for specifying a crypto method, but that is out of scope for this protocol. To avoid the "AYIYA vs $name" discussions: it is a additional protocol for Tunnel Broker setups to allow those to tunnel to endusers behind NAT's. Greets, Jeroen -----Forwarded Message----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-massar-v6ops-ayiya-00.txt Date: Thu, 27 May 2004 15:40:05 -0400 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : AYIYA: Anything In Anything Author(s) : J. Massar Filename : draft-massar-v6ops-ayiya-00.txt Pages : 10 Date : 2004-5-27 =09 This document defines a tunneling protocol that can be encapsulated in any other protocol. Using authentication tokens multiple tunnels can be created from behind the same NAT. The tokens allow one to identify the sender of the packet thus making it possible to automatically switch over the endpoint. This protocol is intended as an alternative to the proto-41 protocol in use for tunneling IPv6 over IPv4 packets over the internet. Due to the authentication this protocol is especially useful for dynamic non-24/7 endnodes which are located behind NATs and want to use for instance a IPv6 Tunnel Broker. The protocol can carry any payload and thus is not limited to only IPv6 over IPv4 but can also be used for IPv4 over IPv6 and many other combinations of protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-massar-v6ops-ayiya-00.txt --=-dSwNVXeiTI9vX+AIwzW/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBAtyU7KaooUjM+fCMRAgTUAJ0Y5P3Su6gJpUqAm/Cpr9cv9OewQQCfS//g zNmNqaG6pjLIWepii8XD/b4= =9OmZ -----END PGP SIGNATURE----- --=-dSwNVXeiTI9vX+AIwzW/-- From owner-v6ops@ops.ietf.org Fri May 28 07:46: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 HAA22264 for ; Fri, 28 May 2004 07:46:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTfmn-000BA7-GR for v6ops-data@psg.com; Fri, 28 May 2004 11:44:29 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTfmm-000B94-7a for v6ops@ops.ietf.org; Fri, 28 May 2004 11:44:28 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4SBiLW4013588; Fri, 28 May 2004 11:44:21 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4SBiK35013585; Fri, 28 May 2004 11:44:20 GMT Date: Fri, 28 May 2004 11:44:20 +0000 From: bmanning@vacation.karoshi.com To: JORDI PALET MARTINEZ Cc: ietf@ietf.org, v6ops@ops.ietf.org, ipv6@rediris.es, ipv6@ietf.org Subject: Re: ICANN Board to implement IPv6 in root servers Message-ID: <20040528114420.GB13184@vacation.karoshi.com.> References: <60ef01c44482$0e5efd40$8700000a@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60ef01c44482$0e5efd40$8700000a@consulintel.es> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The headline is misleading. The recommendation is to support IPv6 registration of TLD servers in the root zone. The root servers themselves still need some testing before registration of their IPv6 capabilities. --bill manning From owner-v6ops@ops.ietf.org Fri May 28 11:54: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 LAA11874 for ; Fri, 28 May 2004 11:54:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTjeX-000Awl-BQ for v6ops-data@psg.com; Fri, 28 May 2004 15:52:13 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTjeV-000AwG-Oy; Fri, 28 May 2004 15:52:11 +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 i4SFq6S19068; Fri, 28 May 2004 18:52:06 +0300 (EET DST) X-Scanned: Fri, 28 May 2004 18:51:47 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4SFplmq031284; Fri, 28 May 2004 18:51:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00U8wZry; Fri, 28 May 2004 18:51:45 EEST 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 i4SFpiH18847; Fri, 28 May 2004 18:51:44 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 May 2004 18:51:42 +0300 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 May 2004 18:51:40 +0300 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: 3GPP Analysis revision -10 (resolving IESG comments) Date: Fri, 28 May 2004 17:51:39 +0200 Message-ID: Thread-Topic: 3GPP Analysis revision -10 (resolving IESG comments) thread-index: AcRC9jw3iHMBKOMKRsecd8eQLcKPMwBzu3Rg From: To: , Cc: , , , , , , , X-OriginalArrivalTime: 28 May 2004 15:51:40.0831 (UTC) FILETIME=[AAD45AF0:01C444CB] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,BIZ_TLD,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, A few questions to the text in the draft: In section 4.1 it is written: "... this approach would not take = advantage of SIP's ability to use proxy routing" I can not really see what kind of ability is lost here. What exactly the = authors think it is lost? Further down in the same section: "IMS data is time-sensitive ... Alternatives include=20 routing to a transcoder, whose task is to terminate an IPv6 stream=20 and start an IPv4 stream" I failed to understand the advantage of a transcoder to a NAT-PT. Why is = an alternative to process a packet also at application layer when you = can do it at IP layer? Also, time sensitiveness is not always an = issue... Then: "The authors=20 recommend that a detailed solution for the general SIP/SDP/media=20 IPv4/IPv6 transition problem will be specified as soon as possible=20 as a task within the SIP WGs in the IETF. " The above statement sounds strange for me. It could be instead said that = this document describes a solution based on SIP-ALG and NAT-PT, and = other solutions might (or might not) become available later. /Gabor -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext=20 Sent: Wednesday, May 26, 2004 9:51 AM To: v6ops@ops.ietf.org Cc: mankin@psg.com; sah@428cobrajet.net; hardie@qualcomm.com; housley@vigilsec.com; Kessens David (Nokia-NET/MtView); bwijnen@lucent.com; jon.peterson@neustar.biz; spencer@mcsr-labs.org Subject: 3GPP Analysis revision -10 (resolving IESG comments) Hi all, I finally managed to compose revision -10 of the 3GPP Analysis document. = The draft can be found here: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt= The document now *should* resolve IESG discuss comments, the major = changes compared to -09 are the following: - summary/recommendations section - IMS scenario 1 text (based on Allison Mankin's text) - I am still a = bit unsure about the text... - editorial changes / proofreading done by Spencer Dawkins This is what I wrote in the summary/recommendations section: ------------ This document has analyzed five GPRS and two IMS IPv6 transition=20 scenarios. Numerous 3GPP networks are using private IPv4 addresses=20 today, and introducing IPv6 is an important thing. The two first=20 GPRS scenarios and both IMS scenarios are seen the most relevant.=20 The authors summarize some main recommendations here:=20 - Dual-stack UEs are recommended instead of IPv4-only or IPv6- only UEs. It is important to take care that the applications=20 in the UEs support IPv6. IPv6-only UEs can become feasible=20 when IPv6 is widely deployed in the networks, and most=20 services work on IPv6.=20 - It is recommended to activate an IPv6 PDP context when=20 communicating with an IPv6 peer node and an IPv4 PDP context=20 when communicating with an IPv4 peer node.=20 - IPv6 communication is preferred to IPv4 communication going=20 through IPv4 NATs to the same dual stack peer node.=20 - This document strongly recommends the 3GPP operators to deploy=20 basic IPv6 support in their GPRS networks as soon as possible.=20 That makes it possible to lessen the transition effects in the=20 UEs.=20 - A tunneling mechanism in the UE may be needed during the early=20 phases of the IPv6 transition process. A lightweight,=20 automatic tunneling mechanism should be standardized in the=20 IETF.=20 - Tunneling mechanisms can be used in 3GPP networks, and only=20 generic recommendations are given in this document. More=20 details can be found, for example, in [ISP-sa].=20 - We recommend that a detailed solution for the general=20 SIP/SDP/media IPv4/IPv6 transition problem will be specified=20 as soon as possible as a task within the SIP WGs in the IETF.=20 ----------- Rgds, -Juha W.- From owner-v6ops@ops.ietf.org Fri May 28 15:18: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 PAA26568 for ; Fri, 28 May 2004 15:18:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTmqQ-0008JK-M8 for v6ops-data@psg.com; Fri, 28 May 2004 19:16:42 +0000 Received: from [4.14.88.197] (helo=tndh.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTmqP-0008Iz-5y for v6ops@ops.ietf.org; Fri, 28 May 2004 19:16:41 +0000 Received: from eaglet (127.0.0.1:4881) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 28 May 2004 12:16:43 -0700 From: "Tony Hain" To: "'lidefeng'" <77cronux.leed0621@huawei.com>, "'Liu Min'" , "'Christian Huitema'" , "'Eiffel Wu'" , Cc: Subject: RE: Teredo vs Silkroad Date: Fri, 28 May 2004 12:16:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <001801c4445b$7f9c9f20$07436e0a@HUAWEI.COM> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcREbKsLrwB/TXbNQ2SOWEFxc7SnSAAagfWw X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit lidefeng wrote: > ... > Defeng Li: > I think what we concern is not whether Silkroad is tunnel broker or > not,but > how to resolve the problem met in the IPv4-IPv6 transition,even Silkroad > have some similarity with tunnel broker, it doesn't mean that tunnel > broker > can resolve the problem which is addressed by Silkroad,in fact, RFC > 3053(IPv6 Tunnel Broker, which should be Tunnel Broker Mechanism you > always > mentioned in your mails) explicitly stated in section "3. Known > limitations" > that "This mechanism may not work if the user is using private IPv4 > addresses behind a NAT box." And Silkroad can resolve the Nat traversal > problem very well, I think "the problem statement and the difference > between > silkroad and a generic tunnel broker" is very very clear. There are several proposed tunnel broker mechanisms. RFC 3053 only outlines the broad class of solution, so it should not be taken as the mechanism I referenced in earlier mail. The nat issue in known limitations is there to point out that specific tunnel brokers that expect the client to provide an address in the protocol will fail when the client is behind a nat. If instead the implementation pulls the address from the IPv4 header it will work through a nat. To be very clear, Silkroad is a tunnel broker primarily because a 'broker' is required to acquire an IPv6 prefix, and there is a fixed mapping to the endpoint of the non-optimized tunnel. That is the fundamental characteristic of Silkroad. What sets it apart from other tunnel brokers is the innovative approach to tunnel optimization. The fact that this optimization is targeted to work in nat environments is an additional enhancement. > > Another point you missed very far is that you insist that "nat traversal > is > not a problem that needs solving, so Silkroad brings nothing to the table > if > that is all it is intended to do",maybe it is right only in the scope of > United States,where the IPv4 addresses are abundant, however in Asia IPv4 > addresses is so scarce that almost every ISP access their customers with > private IPv4 addresses. > That was a poor choice of words which assumed a significant amount of context. Yes, mechanisms need to work in nat rich environments. The point I was trying to make was that other proposals work through nat, so if that is the only thing Silkroad does, it brings nothing NEW to the table. That said, Silkroad does bring the route optimization characteristics of Teredo to the tunnel broker environment, so it does add value, just not in the area you appear to be focused on. To be clear, while the U.S. has a large number of IPv4 addresses, there is an even greater abundance of nat. Even in the U.S. I spend more time connected through nat than otherwise. I submitted RFC 2993 while my home network was connected through 2 different nat implementations (now down to 1). My machines on the corporate network are in 10.x space. Every airport lounge, coffee shop, and hotel I get network access through have deployed nat. I also maintain some distribution statistics at: www.nav6tf.org/RIR_eNations/e-Nations-data.pdf so I am acutely aware of both the lack of address space and the abundance of nat around the world. > > > >Liu Min wrote: > > > ... > > > I think you misunderstand my point. Not every transfer will required a > > > different decision. No matter how many NATs there are, you need not > judge > > > each NAT's type. > > > The NAT type determining process will only work once. > > > ... > > Defeng Li: > Though there is only one NAT is displayed in the figures of the Silkroad > document, is doesn't mean that silkroad only assume there is only one NAT > in > the path,as long as the NAT can transfer the different IPv4 addresses > correctly, several NAT can be deployed in the path,in this case, the IPv6 > packet are encapsulated in UDP payload. > > When routing changes upstream during the session, and the new path may > include a different type of NAT,then Silkroad can setup another UDP tunnel > which cater for this different type of NAT and delete the old UDP tunnel > and > the relevant information will be updated in SC and SAR and the IPv6 domain > where B belongs,then following IPv6 packets of the session will tunneled > in > the new UDP tunnel, it is the same as when one route for a destination is > failure, then another route is selected to forward the packets. Though the > convergence of such information is needed,it isn't be problem can't be > resolved, and some of the updation will be done by routing protocols of > IPv4/IPv6 domains,Silkroad just need to setup the new tunnel and delete > the > old tunnel according the updated information. Your statements contradict each other. The process will only work once, or it will have to run continually because the SC has no real-time feedback about routing changes upstream. This is where the optimization brings considerably more complexity to the picture than a simple tunnel broker. The simple tunnel broker model has only one point where the association between IPv4 & IPv6 headers needs to be maintained. Therefore it has a relatively easy job of authenticating any updates to that which result from routing changes (a periodic authentication would both keep the nat open and provide updated IPv4 address information due to nat path changes). Silkroad on the other hand has to figure out how to do a distributed trust model so that new tunnel mappings can happen for all the route optimized endpoints. To really be successful this tunnel mapping update will have to happen for all the active tunnels within the timeout of any TCP connections to keep the applications on the SC nodes unaware of the change. > ... > Defeng Li: > As stated in the above text,Silkroad not only optimizes the path, but goes > beyond the limitation of tunnel broker. It makes differences. You are reading too much into the RFC. See these drafts for more: www.ietf.org/internet-drafts/draft-massar-v6ops-heartbeat-00.txt www.ietf.org/internet-drafts/draft-blanchet-v6ops-tunnelbroker-tsp-00.txt www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt www.ietf.org/internet-drafts/draft-massar-v6ops-ayiya-00.txt There are undoubtedly others I missed, as well as implementations of drafts which may have expired. The point is you need to take the informational RFC in context as just that, information. It does not specify an implementation, therefore you can't assume Silkroad is providing something new. NOTE TO AD & CHAIR: this confusion is yet another example of why we need to get the mechanism documents out the door. > ... > > "Tony wrote:" > > A major problem with the Silkroad draft is that basic required steps are > > very unclear due to the array of optional ideas. In the email thread, > the > > claimed problem is nat traversal, but that is not a problem that needs > > solving in yet another different way from the existing mechanisms. > > Defeng Li: > Though there is another existing mechanism (Teredo) to resolve the NAT > traversal problem,if this mechanism is difficult to deploy and will make > the > network more complex, why shouldn't we solve it in another simple > way,moreover,who said Teredo mechanism is widely accepted? I think it will > be better not to make the dicision so hasty.I hope those service providers > deployed NAT widely in their network can help to input some information. > If you are going to figure out how to make Silkroad work correctly you need to stop comparing Silkroad to Teredo. Silkroad provides a managed IPv6 prefix via a broker, while Teredo provides an automated IPv6 prefix as a derivative of the IPv4 address. The issue of working through nat is a design goal of each, but Teredo is primarily a way to make 6to4 style automation work through nat, while Silkroad is one way to make a managed tunnel broker work through nat. If you focus on the nat part you will miss the broader context and never get the mechanics right to make the approach work at scale. Market acceptance is not something I am worried about in an IETF context. There are many different problems to be solved in the deployment space, and it is clear to everyone (except the past and current IESG) that we need more than one tool to solve the individual cases. We don't need a vast array of niche specific tools, but one hammer will not work either. If Silkroad provides value to those who are looking for managed prefixes, it will be for its route optimization. By design it will never solve the automated prefix case that Teredo is dealing with, so it is best to stop worrying about Teredo and stop making comparisons. Due to their different target clients, they are complementary rather than competing technologies. > >"Tony wrote:" > > As far as I can tell, what Silkroad does provide is the prefix stability > of a tunnel > > broker, coupled with the route optimization characteristic of Teredo. As > a > > concept that appears to have value. The actual mechanics described in > the > > draft completely ignore the operational realities of routing changes, > and > > the need for path determination on every connection due to untested > > topology. The Internet is not a contained, strictly hierarchical, low > > latency lab scale network, so deployable mechanisms are required to deal > > with the messy details of continually shifting topology, planned & > unplanned > > outages of single nodes, abuse tracking and mitigation, and such > > non-technical details as irrational business necessities. While the idea > of > > route optimized tunnel brokers has merit, the current Silkroad draft > appears > > to be lacking in all those areas. For the Silkroad draft to make > progress, > > it needs to clearly state its goal and differences from existing > > technologies, sort all the mandatory basics up front, then get realistic > > about continuous change and scale. > > > > Tony > > Defeng Li: > I think the route optimization can be done by route protocols, route > protocol should solve the problem of multi-homing and the route change or > updation,the Silkroad just utilize the optimized route information to > maintain(setup or delete) the Silkroad tunnel,fo course Silkroad should > cooperate with the route optimization to solve the NAT traversal problem > better, but it make no sense to enable Silkroad to do all the work. We have an overload of 'routing' by mixing IPv4 & IPv6. I was not expecting Silkroad to be aware of the underlying IPv4 routing, but to build the direct path tunnels, Silkroad clients will explicitly need IPv6 routing information. They will need at least enough to know which IPv6 prefixes are on the IPv4-logical-link vs. connected behind their designated access router. The process for updating this client side routing cache needs to be very dynamic, and at the same time secured against intentional pollution from malicious clients. This is not 'making Silkroad do all the work', but making Silkroad do the work that is necessary to achieve its design goals. While having the SC poll the SAR may be the most effective ND-proxy, the whole 'poll the SN' concept is not scalable, so effectively Silkroad needs to run a routing protocol between all the SARs so they can have a real-time perspective on which IPv6 prefixes are accessed through which neighbors on the IPv4-logical-link. IGPs are not designed to run on the global scale of the Internet, and they are not designed to run between a massive number of independent trust boundaries. This effectively leads to BGP with a massive number of peers on the IPv4-logical-link. Since we know N^2 trust even between the SARs will never happen, the SN will need to take on the role of the trusted route reflector, where the independently operated SNs can have a more manageable trust infrastructure. In short, step back from the current draft and rethink the overall problem statement. While nat traversal is a necessity, it is not the fundamental characteristic here. Silkroad is providing managed IPv6 prefixes with path optimized routing directly between clients. As a secondary issue it also includes appropriate hooks to allow those clients to be connected via nat. Once the concept is reframed in that context, the next step will be to revisit all the operating environment assumptions and make sure they take into account the scale, trust relationships, and continual change that are the reality of the global Internet. Tony From owner-v6ops@ops.ietf.org Sat May 29 01: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 BAA03377 for ; Sat, 29 May 2004 01:56:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTwki-000J1h-3B for v6ops-data@psg.com; Sat, 29 May 2004 05:51:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTwkg-000Izb-0r for v6ops@ops.ietf.org; Sat, 29 May 2004 05:51:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4T5pHS11958; Sat, 29 May 2004 08:51:17 +0300 Date: Sat, 29 May 2004 08:51:17 +0300 (EEST) From: Pekka Savola To: juha.wiljakka@nokia.com cc: peter.grubmair@siemens.com, Subject: RE: draft-daniel-dhc-ipv6in4-opt-03.txt In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE3A5@esebe005.ntc.nokia.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=-3.7 required=5.0 tests=AWL,BAYES_00,DEAR_SOMETHING autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 27 May 2004 juha.wiljakka@nokia.com wrote: > There is also a simpler, usable mechanism if v6-in-v4 tunneling is > needed in a 3GPP UE: ISATAP. That does not require DHCP > implementation in the UE. See Dave's comments here: > http://ops.ietf.org/lists/v6ops/v6ops.2004/msg00814.html While ISATAP may be slightly simpler from the server's implementation point-of-view, it has problems of its own. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Grubmair Peter > Sent: 27 May, 2004 14:52 > To: V6ops_Discussion (E-mail) > Subject: draft-daniel-dhc-ipv6in4-opt-03.txt > > > Dear Sirs, > I highly appreciated finding your draft > concerning "DHCP Option for Configuring IPv6-over-IPv4 Tunnels" > at IETF. > To my mind this is one of the simplest form of a first transition > for mobile (GPRS) operators to supply IPv6 to > their customers. > After finding the tunnel endpoint via your DHCP option > a dual stack mobile phone can do autoconfiguration (or DHCPv6) > accros the tunnel and obtain a globally unique IPv6 address, > allthough its IPv4 address is only private. > (no DAD is needed as link-local address is constructed from > IPv4 address, which is unique within operators area). > tunnel establishment at operator side could be done with adhoc mode > as described in >>Simple IPv6-in-IPv4 Tunnel Establishment Procedure > (STEP)<< > (draft-savola-v6ops-conftun-setup-02.txt) > this could be the m > I hope that your suggestion evolves to an RFC soon. > Best regards > Peter Grubmair > -- 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-v6ops@ops.ietf.org Mon May 31 20:08: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 UAA23725 for ; Mon, 31 May 2004 20:08:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUwlM-000NSQ-3M for v6ops-data@psg.com; Tue, 01 Jun 2004 00:04:16 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUwlH-000NQp-4U for v6ops@ops.ietf.org; Tue, 01 Jun 2004 00:04:11 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HYL00D1DS6V39@mailout1.samsung.com> for v6ops@ops.ietf.org; Tue, 01 Jun 2004 09:04:07 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HYL00KOJS6MXA@mailout1.samsung.com> for v6ops@ops.ietf.org; Tue, 01 Jun 2004 09:03:58 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HYL00IJ2S6LWO@mmp2.samsung.com> for v6ops@ops.ietf.org; Tue, 01 Jun 2004 09:03:57 +0900 (KST) Date: Tue, 01 Jun 2004 09:04:38 +0900 From: Soohong Daniel Park Subject: RE: draft-daniel-dhc-ipv6in4-opt-03.txt In-reply-to: <245DBCAEEC4F074CB77B3F984FF9834F020CE3A5@esebe005.ntc.nokia.com> To: juha.wiljakka@nokia.com, peter.grubmair@siemens.com, v6ops@ops.ietf.org Cc: soohong.park@samsung.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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,DEAR_SOMETHING autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Both drafts need some means to get IPv4 address of tunnel server. DHCPv4 fits best for this purpose. This proposal would be directly applycable to the ad-hoc tunnel servers in this draft Above all, my original approach is for ISP aspect to provide IPv6 connectivity though it's a temporary connection.So far almost ISPs do not need to change their current network for the IPv6 service, thus as stated, this mechanism can be used to provide the IPv6 services without upgrading all their (ISPs) infrastructure to support IPv6 on day one. We implemented it and this mechanism is very useful for us to connect IPv6 services from our IPv4 networks (host has a dual stack of course) - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org]On Behalf Of juha.wiljakka@nokia.com > Sent: Thursday, May 27, 2004 9:26 PM > To: peter.grubmair@siemens.com; v6ops@ops.ietf.org > Subject: RE: draft-daniel-dhc-ipv6in4-opt-03.txt > > > > Hi, Peter! > > There is also a simpler, usable mechanism if v6-in-v4 tunneling > is needed in a 3GPP UE: ISATAP. That does not require DHCP > implementation in the UE. See Dave's comments here: > http://ops.ietf.org/lists/v6ops/v6ops.2004/msg00814.html > > BR, > -Juha- > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Grubmair Peter > Sent: 27 May, 2004 14:52 > To: V6ops_Discussion (E-mail) > Subject: draft-daniel-dhc-ipv6in4-opt-03.txt > > > Dear Sirs, > I highly appreciated finding your draft > concerning "DHCP Option for Configuring IPv6-over-IPv4 Tunnels" > at IETF. > To my mind this is one of the simplest form of a first transition > for mobile (GPRS) operators to supply IPv6 to > their customers. > After finding the tunnel endpoint via your DHCP option > a dual stack mobile phone can do autoconfiguration (or DHCPv6) > accros the tunnel and obtain a globally unique IPv6 address, > allthough its IPv4 address is only private. > (no DAD is needed as link-local address is constructed from > IPv4 address, which is unique within operators area). > tunnel establishment at operator side could be done with adhoc mode > as described in >>Simple IPv6-in-IPv4 Tunnel Establishment Procedure > (STEP)<< > (draft-savola-v6ops-conftun-setup-02.txt) > this could be the m > I hope that your suggestion evolves to an RFC soon. > Best regards > Peter Grubmair > >