From Fred.L.Templin@boeing.com Thu Jul 5 11:30:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C7021F86C9 for ; Thu, 5 Jul 2012 11:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wWqIqxcJ2n5 for ; Thu, 5 Jul 2012 11:30:49 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2F221F861F for ; Thu, 5 Jul 2012 11:30:49 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q65IUxIP008478 for ; Thu, 5 Jul 2012 11:30:59 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q65IUxVK008475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Jul 2012 11:30:59 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q65IUxuk007079 for ; Thu, 5 Jul 2012 13:30:59 -0500 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q65IUwgW007056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 5 Jul 2012 13:30:59 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 5 Jul 2012 11:30:58 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Date: Thu, 5 Jul 2012 11:30:57 -0700 Subject: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Topic: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqA Message-ID: References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> In-Reply-To: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 18:30:50 -0000 Hello, I have posted a new draft that calls for an update to RFC2460. The document proposes to enlist the support of IPv6 hosts in offloading the burden carried by links that must perform link-specific fragmentation/reassembly per RFC2460, Section 5: "IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6." The draft announcement appears below. Please review and send comments to the list. Fred fred.l.templin@boeing.com --- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Source Fragmentation for Link Adaptation Avoidance Author(s) : Fred L. Templin Filename : draft-generic-6man-tunfrag-02.txt Pages : 5 Date : 2012-07-05 Abstract: IPv6 intentionally deprecates fragmentation by routers in the network. Instead, links with restricting MTUs must either drop each too-large packet and return an ICMP Packet Too Big message or perform link-specific fragmentation (also known as "link adaptation") at a layer below IPv6. This latter category of links is often performance-challenged to accommodate steady-state link-specific fragmentation to the point that it would be highly desirable to push the fragmentation burden back to the IPv6 source. A common case that exhibits these link characteristics is seen for IPv6-within-IP tunnels. This document therefore proposes an update to the base IPv6 specification to support link adaptation avoidance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag There's also a htmlized version available at: http://tools.ietf.org/html/draft-generic-6man-tunfrag-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-generic-6man-tunfrag-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dthaler@microsoft.com Thu Jul 5 18:28:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD4E11E8122 for ; Thu, 5 Jul 2012 18:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaseCsHsxufB for ; Thu, 5 Jul 2012 18:28:48 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2903C11E8120 for ; Thu, 5 Jul 2012 18:28:48 -0700 (PDT) Received: from mail16-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 01:26:56 +0000 Received: from mail16-ch1 (localhost [127.0.0.1]) by mail16-ch1-R.bigfish.com (Postfix) with ESMTP id D22E52C0187; Fri, 6 Jul 2012 01:26:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zz9371Ic89bh936eI542M1432Izz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail16-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail16-ch1 (localhost.localdomain [127.0.0.1]) by mail16-ch1 (MessageSwitch) id 1341538014157878_25747; Fri, 6 Jul 2012 01:26:54 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail16-ch1.bigfish.com (Postfix) with ESMTP id 1A42812004B; Fri, 6 Jul 2012 01:26:54 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 01:26:53 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 6 Jul 2012 01:28:58 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Thu, 5 Jul 2012 18:28:58 -0700 From: Dave Thaler To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "ipv6@ietf.org Mailing List" Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Thread-Topic: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Thread-Index: AQHNSV6WE3ShC1aRY0CMvMGykLyPMZcbk/Dg Date: Fri, 6 Jul 2012 01:28:57 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> In-Reply-To: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-uri-zoneid@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 01:28:49 -0000 I know it's after the designated end of WGLC, but here's my feedback... The document appears to call out existing practice in several places, such = as in section 1: > Some versions of some browsers accept the RFC 4007 syntax for scoped > IPv6 addresses embedded in URIs, i.e., they have been coded to > interpret the "%" sign according to RFC 4007 instead of RFC 3986. and in Appendix A point 1: > Advantage: works today. However, it's missing discussion of other alternatives already in common pr= actice. For example alternative 3 (escaping the escape character as allowed by RFC = 3986) has: > Advantage: allows use of browser. > > Disadvantage: ugly and confusing, doesn't allow simple cut and > paste. The disadvantage is certainly true. However the main advantage are notably lacking, which is that it's already in common practice in many places (to t= he extent that using a zone id at all is common practice anyway). You'll see at=20 http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=3Dvs.85)= .aspx that alternative 3 is what is supported in IE7 and above, and the APIs are = generally available to Windows applications (i.e. not just IE7). The document does not state whether the existing legal use is suddenly=20 declared to be illegal, or just another legal way of doing the same thing. If you're telling existing applications and OS's that use alternative 3 tha= t they have to change, that doesn't sound like a good thing. That's because many= apps want to be OS-version-independent and use URI parsing libraries provided by the OS. We don't want apps to code their own URI parsing (it's very easy = to get wrong, especially when you add various internationalization issues).=20 As a result, apps will tend to code to the lowest common denominator of OS's they want to work on. That means I expect to see apps coding to alternative 3 for the foreseeable future. When they don't use them in=20 edit boxes, the disadvantage of not being able to cut and paste is not a real disadvantage. Personally I don't have an issue with allowing both formats if the WG feels strongly that a cut-and-paste-friendly format is needed in addition to what's existing practice, though having two does affect the rules for=20 comparison (see draft-iab-identifier-comparison section 3.1.2) but not noticeably. Finally, the stated disadvantage of alternative 3 is only a disadvantage if= the specified scheme in section 2 *does* allow cut-and-paste. For that to happen, it means the zone id separator has to work outside the context of URIs. That is, section 2 says: > Thus, the scoped address fe80::a%en1 would appear in a URI as > http://[fe80::a-en1]. To support cut-and-paste, that means that "ping fe80::a-en1"=20 needs to work. But this document is titled " Representing IPv6 Zone Identifiers in Uniform Resource Identifiers" and similarly the abstract limits its scope to URIs. Hence section 2 is in contradiction with the analysis of alternative 3. The document already says it "updates 4007" so it seems that what's lacking is a section specifically updating RFC 4007 section 11 which would declare that both '%' and '-' are acceptable separators in the textual representation. -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ole Tr=F8an > Sent: Wednesday, June 13, 2012 5:18 AM > To: ipv6@ietf.org Mailing List > Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- > zoneid@tools.ietf.org > Subject: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt >=20 > All, >=20 > This message starts a one-week 6MAN Working Group Last Call on advancing: > Title : Representing IPv6 Zone Identifiers in Uniform > Resource Identifiers > Author(s) : Brian Carpenter > Robert M. Hinden > Filename : draft-ietf-6man-uri-zoneid-01.txt > Pages : 9 > Date : 2012-05-29 >=20 >=20 > as a Proposed Standard. Substantive comments should be directed to the > mailing list or the co-chairs. Editorial suggestions can be sent to the a= uthors. > This last call will end on June 20, 2012. > Regards, > Bob, & Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Aleksi.Suhonen@tut.fi Fri Jul 6 00:41:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9192721F8749 for ; Fri, 6 Jul 2012 00:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-QfRF06PYIp for ; Fri, 6 Jul 2012 00:41:23 -0700 (PDT) Received: from mail-gw-out2.cc.tut.fi (mail-gw-out2.cc.tut.fi [130.230.160.33]) by ietfa.amsl.com (Postfix) with ESMTP id 03A7B21F8738 for ; Fri, 6 Jul 2012 00:41:22 -0700 (PDT) X-AuditID: 82e6a021-b7f236d000000a82-7f-4ff696b0080f Received: from mail1.tut.fi (mail1.tut.fi [130.230.162.19]) by mail-gw-out2.cc.tut.fi (Symantec Messaging Gateway) with SMTP id 74.FE.02690.0B696FF4; Fri, 6 Jul 2012 10:41:36 +0300 (EEST) Received: from [IPv6:2001:708:310:52:21a:6bff:fe61:167] (pool46.nat64.trex.fi [195.140.194.46]) by mail1.tut.fi (Postfix) with ESMTPSA id D1AD840135; Fri, 6 Jul 2012 10:41:36 +0300 (EEST) Message-ID: <4FF696AA.3050508@tut.fi> Date: Fri, 06 Jul 2012 10:41:30 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Department of Communications Engineering User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: sunqiong@ctbri.com.cn, niu.qibo@zte.com.cn Subject: draft-chen-v6ops-nat64-experience-02 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsXS9GyRsO7Gad/8DT4yWbw8+57J4kNnC6vF n89v2B2YPeY8es/qsWTJTyaPNft+sAQwR3HZpKTmZJalFunbJXBl3Pp7n7HgIl9F4828BsZb 3F2MnBwSAiYSz15OZ4WwxSQu3FvP1sXIxSEksI9RorXtFzOEc4BRYtetrUAZDg5eAVWJ7Vt1 QRpYgMymc0dZQGw2AR2JK1232EBsfoFoidfn/rKD2KICIRLTmw8ygdi8AoISJ2c+AasXEdCT mNd7jhnEZgaKPzv8gxVkvLCArsSf9+YQYRuJvycWsUDY8hLb385hnsDIPwvJpFlIymYhKVvA yLyKUSw3MTNHN71cN7+0xEgvOVmvpLRELy1zEyM4HBco7mA8NUP/EKMAB6MSD29mwjd/IdbE suLK3EOMkhxMSqK8qZOBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4ezO++gvxpiRWVqUW5cOk ZDg4lCR4WYCxIyRYlJqeWpGWmQOMOpg0EwcnSDsPUPurqUA1vMUFibnFmekQ+VOMilLivA9B EgIgiYzSPLheUMzX/////xWjONCxwrwMICt4gOkCrvsV0GAmoMF5iz+BDC5JREhJNTDudNh4 fk7g6tT9h7gqPjk1PQnes2vCsbOnls3ZqtgcqJwYtULF6sDGDrZ/3MfaupXXG2hI9zJfD608 65ltfEpy5qofjwo3d33webM7aH+XyFUZV8H02RKrTu5ZtubTlW+yJ77WBV644Cq15+bX1LaV al/4bH8q3tXc1XZZ0O3vacsalw9WfrsclViKMxINtZiLihMByNn/odQCAAA= Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 07:41:24 -0000 Hi, We've been running a NAT64/DNS64 setup at TREX Tampere Region Exchange for over a year now and I'd like to submit the following experience for your draft: IPv6 Privacy Extensions are a big problem with stateless NAT64. A single device with priv exts enabled will use up several IPv4 addresses from the NAT64 pool. And since the IPv4 Internet is full of malware probing for vulnerabilities, the whole IPv4 address pool for the stateless NAT64 will periodically get random traffic from the Internet. Even if the priv ext addresses have expired, the network will generate an ICMPv6 unreachable message which will travel through the NAT64 device and thus refresh timers for the IPv4 mapping. Some firewalls will also generate TCP RST messages for such probes to non-existent IPv6 addresses. In fact, our worst experience has been with an Apple iPad which was left alone in an IPv6 only WLAN which was using our DNS64 service. The iPad thought that the WLAN was broken because it only got an IPv6 address and no DHCPv4 response. It had time to send some packets using IPv6 through the NAT64 which created the mapping. Then it reset its WLAN and tried to associate with the same SSID again. Every time it created a new privacy extension based IPv6 address and a new mapping in the stateless NAT64 device. Within an hour, all the IPv4 addresses in the pool for our NAT64 were registered to this one device. It would be my recommendation that there was either a Router Advertisement Flags Option for "do not use privacy extensions here" and that this was used in all setups that use DNS64 name servers, or that all such setups should use Managed Address Configuration aka DHCPv6 address configuration. -- Aleksi Suhonen, Researcher Department of Communications Engineering Tampere University of Technology From brian.e.carpenter@gmail.com Fri Jul 6 06:01:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BEE21F8763 for ; Fri, 6 Jul 2012 06:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.042 X-Spam-Level: X-Spam-Status: No, score=-101.042 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQoM3P3X1xfJ for ; Fri, 6 Jul 2012 06:01:03 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE0021F8758 for ; Fri, 6 Jul 2012 06:01:02 -0700 (PDT) Received: by eekd4 with SMTP id d4so3891808eek.31 for ; Fri, 06 Jul 2012 06:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zQias1aQloww3yLybtl/Pfb4JkwgxqibqStLqbXb7is=; b=l5Y6cTjpqztz4hGl54gPEAl+zYF/AMPsoC2fEnHDfNSaqeOX+P7iq5+2v1qlwxLzeX B9J9uuSsuEz8VGR/IgX8+z0swU/JkwbusUQquc85cS31DRgPsqARTGNcoHjv4aDHm41S PUF40bHJluiyNr9nSw/KJfvYSW6uSpmbhbk+Ra/oCepItO7dmQAosm+c4Y3HzWd53mbA gS+98sfhxvmEmKTE+ZufGnn5vYPpgGe/Eq8AcuVbOqRDqZYju+0EnfpG/JZT79Z8Swnv RE/B27rHSZ+qMVA7qFfXAJlxFC9Vx5US1/CAjii8Y95XdI+xIH4IMo+Nel822CRBiBW5 AoAA== Received: by 10.14.47.5 with SMTP id s5mr7075672eeb.191.1341579678743; Fri, 06 Jul 2012 06:01:18 -0700 (PDT) Received: from [192.168.1.67] (host-2-102-219-21.as13285.net. [2.102.219.21]) by mx.google.com with ESMTPS id o16sm71339638eeb.13.2012.07.06.06.01.15 (version=SSLv3 cipher=OTHER); Fri, 06 Jul 2012 06:01:17 -0700 (PDT) Message-ID: <4FF6E199.5020007@gmail.com> Date: Fri, 06 Jul 2012 14:01:13 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-uri-zoneid@tools.ietf.org" , "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 13:01:04 -0000 Dave, 1) FYI, the deadline we gave the URI list to comment on this has just passed, with only one (positive) reply. 2) It's for the WG Chairs to say if they want another version in view of your comments. 3) I don't see how the % format is currently legal. There's no provision for any characters after the IPv6 address, whether percent-encoded or not. We heard of browsers that previously allowed full RFC 4007 syntax (% *not* treated as an escape) but this is the first I've heard of IE allowing a zone index at all. Regards Brian On 2012-07-06 02:28, Dave Thaler wrote: > I know it's after the designated end of WGLC, but here's my feedback...= >=20 > The document appears to call out existing practice in several places, s= uch as in section 1: >> Some versions of some browsers accept the RFC 4007 syntax for scoped= >> IPv6 addresses embedded in URIs, i.e., they have been coded to >> interpret the "%" sign according to RFC 4007 instead of RFC 3986. > and in Appendix A point 1: >> Advantage: works today. >=20 > However, it's missing discussion of other alternatives already in commo= n practice. > For example alternative 3 (escaping the escape character as allowed by = RFC 3986) has: >> Advantage: allows use of browser. >> >> Disadvantage: ugly and confusing, doesn't allow simple cut and >> paste. >=20 > The disadvantage is certainly true. However the main advantage are not= ably > lacking, which is that it's already in common practice in many places (= to the extent > that using a zone id at all is common practice anyway). >=20 > You'll see at=20 > http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=3Dvs= =2E85).aspx > that alternative 3 is what is supported in IE7 and above, and the APIs = are generally > available to Windows applications (i.e. not just IE7). >=20 > The document does not state whether the existing legal use is suddenly = > declared to be illegal, or just another legal way of doing the same thi= ng. >=20 > If you're telling existing applications and OS's that use alternative 3= that they > have to change, that doesn't sound like a good thing. That's because = many apps > want to be OS-version-independent and use URI parsing libraries provide= d by > the OS. We don't want apps to code their own URI parsing (it's very e= asy to > get wrong, especially when you add various internationalization issues)= =2E=20 > As a result, apps will tend to code to the lowest common denominator of= > OS's they want to work on. That means I expect to see apps coding to= > alternative 3 for the foreseeable future. When they don't use them in= =20 > edit boxes, the disadvantage of not being able to cut and paste is not = a > real disadvantage. >=20 > Personally I don't have an issue with allowing both formats if the WG f= eels > strongly that a cut-and-paste-friendly format is needed in addition to > what's existing practice, though having two does affect the rules for=20 > comparison (see draft-iab-identifier-comparison section 3.1.2) but not > noticeably. >=20 > Finally, the stated disadvantage of alternative 3 is only a disadvantag= e if the > specified scheme in section 2 *does* allow cut-and-paste. For that to= > happen, it means the zone id separator has to work outside the context = of > URIs. That is, section 2 says: >> Thus, the scoped address fe80::a%en1 would appear in a URI as >> http://[fe80::a-en1]. >=20 > To support cut-and-paste, that means that > "ping fe80::a-en1"=20 > needs to work. But this document is titled > " Representing IPv6 Zone Identifiers in Uniform Resource Identifiers" > and similarly the abstract limits its scope to URIs. >=20 > Hence section 2 is in contradiction with the analysis of alternative 3.= > The document already says it "updates 4007" so it seems that what's > lacking is a section specifically updating RFC 4007 section 11 which wo= uld > declare that both '%' and '-' are acceptable separators in the textual > representation. >=20 > -Dave >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf O= f >> Ole Tr=C3=B8an >> Sent: Wednesday, June 13, 2012 5:18 AM >> To: ipv6@ietf.org Mailing List >> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >> zoneid@tools.ietf.org >> Subject: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt= >> >> All, >> >> This message starts a one-week 6MAN Working Group Last Call on advanci= ng: >> Title : Representing IPv6 Zone Identifiers in Uniform >> Resource Identifiers >> Author(s) : Brian Carpenter >> Robert M. Hinden >> Filename : draft-ietf-6man-uri-zoneid-01.txt >> Pages : 9 >> Date : 2012-05-29 >> >> >> as a Proposed Standard. Substantive comments should be directed to the= >> mailing list or the co-chairs. Editorial suggestions can be sent to th= e authors. >> This last call will end on June 20, 2012. >> Regards, >> Bob, & Ole >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From bob.hinden@gmail.com Fri Jul 6 07:00:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5B421F86B6 for ; Fri, 6 Jul 2012 07:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pxf7HmBVCcSP for ; Fri, 6 Jul 2012 07:00:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2146D21F86B4 for ; Fri, 6 Jul 2012 07:00:16 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so16948485obb.31 for ; Fri, 06 Jul 2012 07:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PZDH57s5t2+FY5++juqdX4ID9Spaiw9G3p7iDrdAIiU=; b=nMo25fYkkCGQDuU/UQFe3t6RUqWhtK87xhb3YSw6YV1fMzPfX8chU7ZQ91GiKCigB6 IgbDV7I+Nj5C+DGgdKNVzXfUxNqBIdOnKD7/X02htsPGm1U+IirkrrKZ1lHC4Ou6suNC YCZtA88xVyYgVyDRiY5ei0PSde0C7ccS6xTNKYHgYVlSq8i5oKonfLFLGXofBPd+ZlYT fbCXncCG+F2gAeXJ3z7Yi27bUgtV9txsPxrC2sEJll6DtxvR7Tbh6aAJi+bwRGRFNo8/ yBpOnevpiOfIQbOAe3tP3DyHhEjR8XmvfZbtE9e0uBDCOFMPTfBVPKd9NvB6PcFeCYIQ U32A== Received: by 10.182.14.36 with SMTP id m4mr26106550obc.71.1341583232323; Fri, 06 Jul 2012 07:00:32 -0700 (PDT) Received: from [10.242.26.102] (mbc0f36d0.tmodns.net. [208.54.15.188]) by mx.google.com with ESMTPS id g8sm3143474obz.16.2012.07.06.07.00.29 (version=SSLv3 cipher=OTHER); Fri, 06 Jul 2012 07:00:31 -0700 (PDT) Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Bob Hinden In-Reply-To: <4FF6E199.5020007@gmail.com> Date: Fri, 6 Jul 2012 07:00:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> To: Dave Thaler X-Mailer: Apple Mail (2.1084) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, draft-ietf-6man-uri-zoneid@tools.ietf.org, Bob Hinden , "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:00:17 -0000 With my co-author hat on, would it help to include a description of what = IE supports in Section 3. Web Browsers? Bob On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: > Dave, >=20 > 1) FYI, the deadline we gave the URI list to comment on this has just > passed, with only one (positive) reply. >=20 > 2) It's for the WG Chairs to say if they want another version > in view of your comments. >=20 > 3) I don't see how the % format is currently legal. There's > no provision for any characters after the IPv6 address, whether > percent-encoded or not. We heard of browsers that previously > allowed full RFC 4007 syntax (% *not* treated as an escape) > but this is the first I've heard of IE allowing a zone index > at all. >=20 > Regards > Brian >=20 > On 2012-07-06 02:28, Dave Thaler wrote: >> I know it's after the designated end of WGLC, but here's my = feedback... >>=20 >> The document appears to call out existing practice in several places, = such as in section 1: >>> Some versions of some browsers accept the RFC 4007 syntax for = scoped >>> IPv6 addresses embedded in URIs, i.e., they have been coded to >>> interpret the "%" sign according to RFC 4007 instead of RFC 3986. >> and in Appendix A point 1: >>> Advantage: works today. >>=20 >> However, it's missing discussion of other alternatives already in = common practice. >> For example alternative 3 (escaping the escape character as allowed = by RFC 3986) has: >>> Advantage: allows use of browser. >>>=20 >>> Disadvantage: ugly and confusing, doesn't allow simple cut and >>> paste. >>=20 >> The disadvantage is certainly true. However the main advantage are = notably >> lacking, which is that it's already in common practice in many places = (to the extent >> that using a zone id at all is common practice anyway). >>=20 >> You'll see at=20 >> = http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=3Dvs.85= ).aspx >> that alternative 3 is what is supported in IE7 and above, and the = APIs are generally >> available to Windows applications (i.e. not just IE7). >>=20 >> The document does not state whether the existing legal use is = suddenly=20 >> declared to be illegal, or just another legal way of doing the same = thing. >>=20 >> If you're telling existing applications and OS's that use alternative = 3 that they >> have to change, that doesn't sound like a good thing. That's = because many apps >> want to be OS-version-independent and use URI parsing libraries = provided by >> the OS. We don't want apps to code their own URI parsing (it's very = easy to >> get wrong, especially when you add various internationalization = issues).=20 >> As a result, apps will tend to code to the lowest common denominator = of >> OS's they want to work on. That means I expect to see apps coding = to >> alternative 3 for the foreseeable future. When they don't use them = in=20 >> edit boxes, the disadvantage of not being able to cut and paste is = not a >> real disadvantage. >>=20 >> Personally I don't have an issue with allowing both formats if the WG = feels >> strongly that a cut-and-paste-friendly format is needed in addition = to >> what's existing practice, though having two does affect the rules for=20= >> comparison (see draft-iab-identifier-comparison section 3.1.2) but = not >> noticeably. >>=20 >> Finally, the stated disadvantage of alternative 3 is only a = disadvantage if the >> specified scheme in section 2 *does* allow cut-and-paste. For that = to >> happen, it means the zone id separator has to work outside the = context of >> URIs. That is, section 2 says: >>> Thus, the scoped address fe80::a%en1 would appear in a URI as >>> http://[fe80::a-en1]. >>=20 >> To support cut-and-paste, that means that >> "ping fe80::a-en1"=20 >> needs to work. But this document is titled >> " Representing IPv6 Zone Identifiers in Uniform Resource Identifiers" >> and similarly the abstract limits its scope to URIs. >>=20 >> Hence section 2 is in contradiction with the analysis of alternative = 3. >> The document already says it "updates 4007" so it seems that what's >> lacking is a section specifically updating RFC 4007 section 11 which = would >> declare that both '%' and '-' are acceptable separators in the = textual >> representation. >>=20 >> -Dave >>=20 >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of >>> Ole Tr=F8an >>> Sent: Wednesday, June 13, 2012 5:18 AM >>> To: ipv6@ietf.org Mailing List >>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >>> zoneid@tools.ietf.org >>> Subject: 6MAN WG [second] Last Call: = draft-ietf-6man-uri-zoneid-01.txt >>>=20 >>> All, >>>=20 >>> This message starts a one-week 6MAN Working Group Last Call on = advancing: >>> Title : Representing IPv6 Zone Identifiers in Uniform >>> Resource Identifiers >>> Author(s) : Brian Carpenter >>> Robert M. Hinden >>> Filename : draft-ietf-6man-uri-zoneid-01.txt >>> Pages : 9 >>> Date : 2012-05-29 >>>=20 >>>=20 >>> as a Proposed Standard. Substantive comments should be directed to = the >>> mailing list or the co-chairs. Editorial suggestions can be sent to = the authors. >>> This last call will end on June 20, 2012. >>> Regards, >>> Bob, & Ole >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From mcr@sandelman.ca Fri Jul 6 07:59:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4AD21F85C5 for ; Fri, 6 Jul 2012 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEjlF6beODk4 for ; Fri, 6 Jul 2012 07:59:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3D53521F85A1 for ; Fri, 6 Jul 2012 07:59:11 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id A65A781E0; Fri, 6 Jul 2012 10:56:09 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4F83D98C40; Fri, 6 Jul 2012 10:59:25 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 37B689811D; Fri, 6 Jul 2012 10:59:25 -0400 (EDT) From: Michael Richardson To: Aleksi Suhonen Subject: Re: draft-chen-v6ops-nat64-experience-02 In-Reply-To: <4FF696AA.3050508@tut.fi> References: <4FF696AA.3050508@tut.fi> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 06 Jul 2012 10:59:25 -0400 Message-ID: <23986.1341586765@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: sunqiong@ctbri.com.cn, ipv6@ietf.org, niu.qibo@zte.com.cn X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:59:12 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Aleksi" =3D=3D Aleksi Suhonen writes: Aleksi> Within an hour, all the IPv4 addresses in the pool for our Aleksi> NAT64 were registered to this one device. Do I understand that you attempt to provide a single IPv4 address 1:1 with a an internal IPv6 address? (NAT vs NAPT) Can you tell me what your expiry time is for reclaiming the IPv4 address? Would IPv6 ping'ing the internal device help? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT/b9TIqHRg3pndX9AQJ58gQAz/Y/l8jI5YpWUJ38Eu0G0KRanBYxLBWd dNJf+v0rT4fcUoar1atszWPRe2yFrtxJfvDxrxRwRS7qc8IHcm9xeBfS/Qt1UWDH 0s5amv07O1p1UPEMetOhWcwaA72SuymSAHDnRY1vZPCOEREiQKrRgOQC8HJ1QAft ExKERy7+d3M= =Ui4i -----END PGP SIGNATURE----- --=-=-=-- From brian.e.carpenter@gmail.com Fri Jul 6 09:56:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FD021F8736 for ; Fri, 6 Jul 2012 09:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.066 X-Spam-Level: X-Spam-Status: No, score=-101.066 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmKwkzgyniS1 for ; Fri, 6 Jul 2012 09:56:30 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5801C21F8685 for ; Fri, 6 Jul 2012 09:56:29 -0700 (PDT) Received: by eekd4 with SMTP id d4so3975497eek.31 for ; Fri, 06 Jul 2012 09:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+0mlBTD1mwSNFoi1yJMWJ6vsYMuCCXOy/HWC565pWzQ=; b=o0GJgbVQXrIvjJXJVD0Net8qxFDwk4MZcjbRkpj1gTJP8INAWmvi9HagEkY+f39kL7 DL/iWZvb2WhroK9O89paJD3nRFrvAaOo91sVok+FejTQ3xEwn5VFj1/UuUWV54GjPG9n 1rD0lhqIvi3E7cAv4GVz8Al/5oD0vOYAqlG4D6NarXXmovqcRvpgAk5idvimtPiWHCtU zkPuw1pUYknvIANrXY2HZjTcyLIIDkIZNbsfUmlbUorTj/urKTTd95vzPTs2MteD3Ez5 GLjQFlK1J78q/JDqx6dXz69cwdfmqIug6Fq+78n6bwreZQPP0lD0iiFRaH4YBVDKP4Br Cwug== Received: by 10.14.101.72 with SMTP id a48mr7692780eeg.120.1341593805144; Fri, 06 Jul 2012 09:56:45 -0700 (PDT) Received: from [192.168.1.67] (host-2-102-219-21.as13285.net. [2.102.219.21]) by mx.google.com with ESMTPS id e48sm72947280eea.12.2012.07.06.09.56.42 (version=SSLv3 cipher=OTHER); Fri, 06 Jul 2012 09:56:43 -0700 (PDT) Message-ID: <4FF718C7.5060206@gmail.com> Date: Fri, 06 Jul 2012 17:56:39 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bob Hinden Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, draft-ietf-6man-uri-zoneid@tools.ietf.org, "ipv6@ietf.org Mailing List" , Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 16:56:31 -0000 I'd be happy with that, or a small appendix. Dave, is it documented anywh= ere? Regards Brian On 2012-07-06 15:00, Bob Hinden wrote: > With my co-author hat on, would it help to include a description of wha= t IE supports in Section 3. Web Browsers? >=20 > Bob >=20 >=20 > On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: >=20 >> Dave, >> >> 1) FYI, the deadline we gave the URI list to comment on this has just >> passed, with only one (positive) reply. >> >> 2) It's for the WG Chairs to say if they want another version >> in view of your comments. >> >> 3) I don't see how the % format is currently legal. There's >> no provision for any characters after the IPv6 address, whether >> percent-encoded or not. We heard of browsers that previously >> allowed full RFC 4007 syntax (% *not* treated as an escape) >> but this is the first I've heard of IE allowing a zone index >> at all. >> >> Regards >> Brian >> >> On 2012-07-06 02:28, Dave Thaler wrote: >>> I know it's after the designated end of WGLC, but here's my feedback.= =2E. >>> >>> The document appears to call out existing practice in several places,= such as in section 1: >>>> Some versions of some browsers accept the RFC 4007 syntax for scope= d >>>> IPv6 addresses embedded in URIs, i.e., they have been coded to >>>> interpret the "%" sign according to RFC 4007 instead of RFC 3986. >>> and in Appendix A point 1: >>>> Advantage: works today. >>> However, it's missing discussion of other alternatives already in com= mon practice. >>> For example alternative 3 (escaping the escape character as allowed b= y RFC 3986) has: >>>> Advantage: allows use of browser. >>>> >>>> Disadvantage: ugly and confusing, doesn't allow simple cut and >>>> paste. >>> The disadvantage is certainly true. However the main advantage are n= otably >>> lacking, which is that it's already in common practice in many places= (to the extent >>> that using a zone id at all is common practice anyway). >>> >>> You'll see at=20 >>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=3D= vs.85).aspx >>> that alternative 3 is what is supported in IE7 and above, and the API= s are generally >>> available to Windows applications (i.e. not just IE7). >>> >>> The document does not state whether the existing legal use is suddenl= y=20 >>> declared to be illegal, or just another legal way of doing the same t= hing. >>> >>> If you're telling existing applications and OS's that use alternative= 3 that they >>> have to change, that doesn't sound like a good thing. That's becaus= e many apps >>> want to be OS-version-independent and use URI parsing libraries provi= ded by >>> the OS. We don't want apps to code their own URI parsing (it's very= easy to >>> get wrong, especially when you add various internationalization issue= s).=20 >>> As a result, apps will tend to code to the lowest common denominator = of >>> OS's they want to work on. That means I expect to see apps coding = to >>> alternative 3 for the foreseeable future. When they don't use them = in=20 >>> edit boxes, the disadvantage of not being able to cut and paste is no= t a >>> real disadvantage. >>> >>> Personally I don't have an issue with allowing both formats if the WG= feels >>> strongly that a cut-and-paste-friendly format is needed in addition t= o >>> what's existing practice, though having two does affect the rules for= =20 >>> comparison (see draft-iab-identifier-comparison section 3.1.2) but no= t >>> noticeably. >>> >>> Finally, the stated disadvantage of alternative 3 is only a disadvant= age if the >>> specified scheme in section 2 *does* allow cut-and-paste. For that = to >>> happen, it means the zone id separator has to work outside the contex= t of >>> URIs. That is, section 2 says: >>>> Thus, the scoped address fe80::a%en1 would appear in a URI as >>>> http://[fe80::a-en1]. >>> To support cut-and-paste, that means that >>> "ping fe80::a-en1"=20 >>> needs to work. But this document is titled >>> " Representing IPv6 Zone Identifiers in Uniform Resource Identifiers"= >>> and similarly the abstract limits its scope to URIs. >>> >>> Hence section 2 is in contradiction with the analysis of alternative = 3. >>> The document already says it "updates 4007" so it seems that what's >>> lacking is a section specifically updating RFC 4007 section 11 which = would >>> declare that both '%' and '-' are acceptable separators in the textua= l >>> representation. >>> >>> -Dave >>> >>>> -----Original Message----- >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf= Of >>>> Ole Tr=C3=B8an >>>> Sent: Wednesday, June 13, 2012 5:18 AM >>>> To: ipv6@ietf.org Mailing List >>>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >>>> zoneid@tools.ietf.org >>>> Subject: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.t= xt >>>> >>>> All, >>>> >>>> This message starts a one-week 6MAN Working Group Last Call on advan= cing: >>>> Title : Representing IPv6 Zone Identifiers in Uniform >>>> Resource Identifiers >>>> Author(s) : Brian Carpenter >>>> Robert M. Hinden >>>> Filename : draft-ietf-6man-uri-zoneid-01.txt >>>> Pages : 9 >>>> Date : 2012-05-29 >>>> >>>> >>>> as a Proposed Standard. Substantive comments should be directed to t= he >>>> mailing list or the co-chairs. Editorial suggestions can be sent to = the authors. >>>> This last call will end on June 20, 2012. >>>> Regards, >>>> Bob, & Ole >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> --------------------------------------------------------------------= >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 From dthaler@microsoft.com Fri Jul 6 10:29:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C15121F86B1 for ; Fri, 6 Jul 2012 10:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.721 X-Spam-Level: X-Spam-Status: No, score=-103.721 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSwEdGY3pFFc for ; Fri, 6 Jul 2012 10:29:30 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id B4B2D21F8622 for ; Fri, 6 Jul 2012 10:29:29 -0700 (PDT) Received: from mail80-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:27:37 +0000 Received: from mail80-am1 (localhost [127.0.0.1]) by mail80-am1-R.bigfish.com (Postfix) with ESMTP id 612C0220099; Fri, 6 Jul 2012 17:27:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VS-39(zz98dI9371Ic89bh936eI1b0bM542M1432Izz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839h93fhd25hf0ah107ah) Received-SPF: pass (mail80-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail80-am1 (localhost.localdomain [127.0.0.1]) by mail80-am1 (MessageSwitch) id 1341595655458248_11127; Fri, 6 Jul 2012 17:27:35 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.226]) by mail80-am1.bigfish.com (Postfix) with ESMTP id 6B8FA480043; Fri, 6 Jul 2012 17:27:35 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:27:35 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 6 Jul 2012 17:29:26 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 10:29:26 -0700 From: Dave Thaler To: Brian E Carpenter Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Thread-Topic: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Thread-Index: AQHNSV6WE3ShC1aRY0CMvMGykLyPMZcbk/DggAE9goD//9OmIA== Date: Fri, 6 Jul 2012 17:29:26 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B6909AE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> In-Reply-To: <4FF6E199.5020007@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-uri-zoneid@tools.ietf.org" , "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:29:31 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVy IFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBTZW50OiBGcmlkYXksIEp1 bHkgMDYsIDIwMTIgNjowMSBBTQ0KPiBUbzogRGF2ZSBUaGFsZXINCj4gQ2M6IE9sZSBUcsO4YW47 IGlwdjZAaWV0Zi5vcmcgTWFpbGluZyBMaXN0OyA2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZyBD aGFpcnM7DQo+IGRyYWZ0LWlldGYtNm1hbi11cmktem9uZWlkQHRvb2xzLmlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiA2TUFOIFdHIFtzZWNvbmRdIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi02bWFuLXVy aS16b25laWQtMDEudHh0DQo+IA0KPiBEYXZlLA0KPiANCj4gMSkgRllJLCB0aGUgZGVhZGxpbmUg d2UgZ2F2ZSB0aGUgVVJJIGxpc3QgdG8gY29tbWVudCBvbiB0aGlzIGhhcyBqdXN0IHBhc3NlZCwg d2l0aA0KPiBvbmx5IG9uZSAocG9zaXRpdmUpIHJlcGx5Lg0KPiANCj4gMikgSXQncyBmb3IgdGhl IFdHIENoYWlycyB0byBzYXkgaWYgdGhleSB3YW50IGFub3RoZXIgdmVyc2lvbiBpbiB2aWV3IG9m IHlvdXINCj4gY29tbWVudHMuDQo+IA0KPiAzKSBJIGRvbid0IHNlZSBob3cgdGhlICUgZm9ybWF0 IGlzIGN1cnJlbnRseSBsZWdhbC4gVGhlcmUncyBubyBwcm92aXNpb24gZm9yIGFueQ0KPiBjaGFy YWN0ZXJzIGFmdGVyIHRoZSBJUHY2IGFkZHJlc3MsIHdoZXRoZXIgcGVyY2VudC1lbmNvZGVkIG9y IG5vdC4gV2UgaGVhcmQNCj4gb2YgYnJvd3NlcnMgdGhhdCBwcmV2aW91c2x5IGFsbG93ZWQgZnVs bCBSRkMgNDAwNyBzeW50YXggKCUgKm5vdCogdHJlYXRlZCBhcyBhbg0KPiBlc2NhcGUpIGJ1dCB0 aGlzIGlzIHRoZSBmaXJzdCBJJ3ZlIGhlYXJkIG9mIElFIGFsbG93aW5nIGEgem9uZSBpbmRleCBh dCBhbGwuDQoNCkl0J3Mgbm90IGN1cnJlbnRseSBsZWdhbCBpbiBhIFVSSSwgYW5kIEkgbWVhbnQg dG8gZml4IG9uZSBzZW50ZW5jZSBvZiBtaW5lIGJlZm9yZQ0Kc2VuZGluZywgYnV0IG1pc3NlZCBp dC4gICBCdXQgdGhhdCdzIHdoeSB0aGUgcGFnZSBzYXlzDQoiVGhlIFVSSSBzdGFuZGFyZCwgZG9j dW1lbnRlZCBpbiBSRkMgMzk4NiwgZG9lcyBub3QgZGVmaW5lIHRoZSBzeW50YXggZm9yIHRoZSAN CnNjb3BlIElELCBhbmQgdGhlIFVSSSBpcyBjb25zaWRlcmVkIG5vbi11bmlmb3JtIHdoZW4gdGhl IHNjb3BlIElEIGlzIHByZXNlbnQuIg0KSSBtaWdodCBxdWliYmxlIHdpdGggdGhlIGxhbmd1YWdl IGJ1dCB0aGUgIm5vbi11bmlmb3JtIiBtZWFucyBpdCdzIG5vdCBhIHN0YW5kYXJkDQpVUkkuICAg SXQncyBub3QgbGVnYWwgdG8gYXBwZWFyIG9uIHRoZSB3aXJlIGluIGFueSBwcm90b2NvbCB0aGF0 IHBhc3NlcyBVUklzLiBIb3dldmVyLA0KdGhlcmUgYXJlIEFQSXMgdGhhdCB0YWtlIHN0cmluZ3Mg dGhhdCBuZWVkIG5vdCBiZSB3ZWxsLWZvcm1lZCBVUklzLCBlLmcuDQoiaHR0cDovL2Zvby9IZWxs byBXb3JsZCIgaXMgbm90IGEgbGVnYWwgVVJJIGJlY2F1c2UgIiAiIHdvdWxkIGJlICUyMCBpbiBh IFVSSS4NClNvIHRoZSAlMjUgc3ludGF4IGlzIHVzZWQgaW4gc3VjaCBBUElzIHRoYXQgcGFzcyBh cm91bmQgdGhpbmdzIHRoYXQgYXJlIFVSSS1saWtlDQpzdHJpbmdzLiAgIEkgb25seSBqdXN0IGZv dW5kIHRoYXQgcGFnZSBteXNlbGYsIGJ1dCB0aGVyZSdzIGEgYnVuY2ggb2YgdGhpbmdzIGluIFdp bmRvd3MNCnRoYXQgcGFzcyBhcm91bmQgVVJJLWxpa2Ugc3RyaW5ncyB3aXRoIHpvbmUgSURzIHZp YSBBUElzIChub3Qgb24gdGhlIHdpcmUpLg0KDQotRGF2ZQ0KDQo+IA0KPiBSZWdhcmRzDQo+ICAg IEJyaWFuDQo+IA0KPiBPbiAyMDEyLTA3LTA2IDAyOjI4LCBEYXZlIFRoYWxlciB3cm90ZToNCj4g PiBJIGtub3cgaXQncyBhZnRlciB0aGUgZGVzaWduYXRlZCBlbmQgb2YgV0dMQywgYnV0IGhlcmUn cyBteSBmZWVkYmFjay4uLg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50IGFwcGVhcnMgdG8gY2FsbCBv dXQgZXhpc3RpbmcgcHJhY3RpY2UgaW4gc2V2ZXJhbCBwbGFjZXMsIHN1Y2ggYXMgaW4NCj4gc2Vj dGlvbiAxOg0KPiA+PiAgIFNvbWUgdmVyc2lvbnMgb2Ygc29tZSBicm93c2VycyBhY2NlcHQgdGhl IFJGQyA0MDA3IHN5bnRheCBmb3Igc2NvcGVkDQo+ID4+ICAgSVB2NiBhZGRyZXNzZXMgZW1iZWRk ZWQgaW4gVVJJcywgaS5lLiwgdGhleSBoYXZlIGJlZW4gY29kZWQgdG8NCj4gPj4gICBpbnRlcnBy ZXQgdGhlICIlIiBzaWduIGFjY29yZGluZyB0byBSRkMgNDAwNyBpbnN0ZWFkIG9mIFJGQyAzOTg2 Lg0KPiA+IGFuZCBpbiBBcHBlbmRpeCBBIHBvaW50IDE6DQo+ID4+IEFkdmFudGFnZTogd29ya3Mg dG9kYXkuDQo+ID4NCj4gPiBIb3dldmVyLCBpdCdzIG1pc3NpbmcgZGlzY3Vzc2lvbiBvZiBvdGhl ciBhbHRlcm5hdGl2ZXMgYWxyZWFkeSBpbiBjb21tb24NCj4gcHJhY3RpY2UuDQo+ID4gRm9yIGV4 YW1wbGUgYWx0ZXJuYXRpdmUgMyAoZXNjYXBpbmcgdGhlIGVzY2FwZSBjaGFyYWN0ZXIgYXMgYWxs b3dlZCBieSBSRkMNCj4gMzk4NikgaGFzOg0KPiA+PiAgICAgICBBZHZhbnRhZ2U6IGFsbG93cyB1 c2Ugb2YgYnJvd3Nlci4NCj4gPj4NCj4gPj4gICAgICAgRGlzYWR2YW50YWdlOiB1Z2x5IGFuZCBj b25mdXNpbmcsIGRvZXNuJ3QgYWxsb3cgc2ltcGxlIGN1dCBhbmQNCj4gPj4gICAgICAgcGFzdGUu DQo+ID4NCj4gPiBUaGUgZGlzYWR2YW50YWdlIGlzIGNlcnRhaW5seSB0cnVlLiAgSG93ZXZlciB0 aGUgbWFpbiBhZHZhbnRhZ2UgYXJlDQo+ID4gbm90YWJseSBsYWNraW5nLCB3aGljaCBpcyB0aGF0 IGl0J3MgYWxyZWFkeSBpbiBjb21tb24gcHJhY3RpY2UgaW4gbWFueQ0KPiA+IHBsYWNlcyAodG8g dGhlIGV4dGVudCB0aGF0IHVzaW5nIGEgem9uZSBpZCBhdCBhbGwgaXMgY29tbW9uIHByYWN0aWNl IGFueXdheSkuDQo+ID4NCj4gPiBZb3UnbGwgc2VlIGF0DQo+ID4gaHR0cDovL21zZG4ubWljcm9z b2Z0LmNvbS9lbi11cy9saWJyYXJ5L3dpbmRvd3MvZGVza3RvcC9hYTM4NTMyNSh2PXZzLg0KPiA+ IDg1KS5hc3B4IHRoYXQgYWx0ZXJuYXRpdmUgMyBpcyB3aGF0IGlzIHN1cHBvcnRlZCBpbiBJRTcg YW5kIGFib3ZlLCBhbmQNCj4gPiB0aGUgQVBJcyBhcmUgZ2VuZXJhbGx5IGF2YWlsYWJsZSB0byBX aW5kb3dzIGFwcGxpY2F0aW9ucyAoaS5lLiBub3QNCj4gPiBqdXN0IElFNykuDQo+ID4NCj4gPiBU aGUgZG9jdW1lbnQgZG9lcyBub3Qgc3RhdGUgd2hldGhlciB0aGUgZXhpc3RpbmcgbGVnYWwgdXNl IGlzIHN1ZGRlbmx5DQo+ID4gZGVjbGFyZWQgdG8gYmUgaWxsZWdhbCwgb3IganVzdCBhbm90aGVy IGxlZ2FsIHdheSBvZiBkb2luZyB0aGUgc2FtZSB0aGluZy4NCg0KQWJvdmUgaXMgdGhlIHNlbnRl bmNlIEkgbWVhbnQgdG8gZGVsZXRlLCBpdCdzIG5vdCBjb3JyZWN0IDopDQoNCj4gPg0KPiA+IElm IHlvdSdyZSB0ZWxsaW5nIGV4aXN0aW5nIGFwcGxpY2F0aW9ucyBhbmQgT1MncyB0aGF0IHVzZSBh bHRlcm5hdGl2ZSAzIHRoYXQgdGhleQ0KPiA+IGhhdmUgdG8gY2hhbmdlLCB0aGF0IGRvZXNuJ3Qg c291bmQgbGlrZSBhIGdvb2QgdGhpbmcuICAgVGhhdCdzIGJlY2F1c2UgbWFueQ0KPiBhcHBzDQo+ ID4gd2FudCB0byBiZSBPUy12ZXJzaW9uLWluZGVwZW5kZW50IGFuZCB1c2UgVVJJIHBhcnNpbmcg bGlicmFyaWVzIHByb3ZpZGVkIGJ5DQo+ID4gdGhlIE9TLiAgIFdlIGRvbid0IHdhbnQgYXBwcyB0 byBjb2RlIHRoZWlyIG93biBVUkkgcGFyc2luZyAoaXQncyB2ZXJ5IGVhc3kgdG8NCj4gPiBnZXQg d3JvbmcsIGVzcGVjaWFsbHkgd2hlbiB5b3UgYWRkIHZhcmlvdXMgaW50ZXJuYXRpb25hbGl6YXRp b24gaXNzdWVzKS4NCj4gPiBBcyBhIHJlc3VsdCwgYXBwcyB3aWxsIHRlbmQgdG8gY29kZSB0byB0 aGUgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBvZg0KPiA+IE9TJ3MgdGhleSB3YW50IHRvIHdv cmsgb24uICAgIFRoYXQgbWVhbnMgSSBleHBlY3QgdG8gc2VlIGFwcHMgY29kaW5nIHRvDQo+ID4g YWx0ZXJuYXRpdmUgMyBmb3IgdGhlIGZvcmVzZWVhYmxlIGZ1dHVyZS4gICBXaGVuIHRoZXkgZG9u J3QgdXNlIHRoZW0gaW4NCj4gPiBlZGl0IGJveGVzLCB0aGUgZGlzYWR2YW50YWdlIG9mIG5vdCBi ZWluZyBhYmxlIHRvIGN1dCBhbmQgcGFzdGUgaXMgbm90DQo+ID4gYSByZWFsIGRpc2FkdmFudGFn ZS4NCj4gPg0KPiA+IFBlcnNvbmFsbHkgSSBkb24ndCBoYXZlIGFuIGlzc3VlIHdpdGggYWxsb3dp bmcgYm90aCBmb3JtYXRzIGlmIHRoZSBXRw0KPiA+IGZlZWxzIHN0cm9uZ2x5IHRoYXQgYSBjdXQt YW5kLXBhc3RlLWZyaWVuZGx5IGZvcm1hdCBpcyBuZWVkZWQgaW4NCj4gPiBhZGRpdGlvbiB0byB3 aGF0J3MgZXhpc3RpbmcgcHJhY3RpY2UsIHRob3VnaCBoYXZpbmcgdHdvIGRvZXMgYWZmZWN0DQo+ ID4gdGhlIHJ1bGVzIGZvciBjb21wYXJpc29uIChzZWUgZHJhZnQtaWFiLWlkZW50aWZpZXItY29t cGFyaXNvbiBzZWN0aW9uDQo+ID4gMy4xLjIpIGJ1dCBub3Qgbm90aWNlYWJseS4NCj4gPg0KPiA+ IEZpbmFsbHksIHRoZSBzdGF0ZWQgZGlzYWR2YW50YWdlIG9mIGFsdGVybmF0aXZlIDMgaXMgb25s eSBhIGRpc2FkdmFudGFnZSBpZiB0aGUNCj4gPiBzcGVjaWZpZWQgc2NoZW1lIGluIHNlY3Rpb24g MiAqZG9lcyogYWxsb3cgY3V0LWFuZC1wYXN0ZS4gICBGb3IgdGhhdCB0bw0KPiA+IGhhcHBlbiwg aXQgbWVhbnMgdGhlIHpvbmUgaWQgc2VwYXJhdG9yIGhhcyB0byB3b3JrIG91dHNpZGUgdGhlIGNv bnRleHQgb2YNCj4gPiBVUklzLiAgIFRoYXQgaXMsIHNlY3Rpb24gMiBzYXlzOg0KPiA+PiAgIFRo dXMsIHRoZSBzY29wZWQgYWRkcmVzcyBmZTgwOjphJWVuMSB3b3VsZCBhcHBlYXIgaW4gYSBVUkkg YXMNCj4gPj4gICBodHRwOi8vW2ZlODA6OmEtZW4xXS4NCj4gPg0KPiA+IFRvIHN1cHBvcnQgY3V0 LWFuZC1wYXN0ZSwgdGhhdCBtZWFucyB0aGF0ICJwaW5nIGZlODA6OmEtZW4xIg0KPiA+IG5lZWRz IHRvIHdvcmsuICAgQnV0IHRoaXMgZG9jdW1lbnQgaXMgdGl0bGVkDQo+ID4gIiBSZXByZXNlbnRp bmcgSVB2NiBab25lIElkZW50aWZpZXJzIGluIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllcnMi DQo+ID4gYW5kIHNpbWlsYXJseSB0aGUgYWJzdHJhY3QgbGltaXRzIGl0cyBzY29wZSB0byBVUklz Lg0KPiA+DQo+ID4gSGVuY2Ugc2VjdGlvbiAyIGlzIGluIGNvbnRyYWRpY3Rpb24gd2l0aCB0aGUg YW5hbHlzaXMgb2YgYWx0ZXJuYXRpdmUgMy4NCj4gPiBUaGUgZG9jdW1lbnQgYWxyZWFkeSBzYXlz IGl0ICJ1cGRhdGVzIDQwMDciIHNvIGl0IHNlZW1zIHRoYXQgd2hhdCdzDQo+ID4gbGFja2luZyBp cyBhIHNlY3Rpb24gc3BlY2lmaWNhbGx5IHVwZGF0aW5nIFJGQyA0MDA3IHNlY3Rpb24gMTEgd2hp Y2gNCj4gPiB3b3VsZCBkZWNsYXJlIHRoYXQgYm90aCAnJScgYW5kICctJyBhcmUgYWNjZXB0YWJs ZSBzZXBhcmF0b3JzIGluIHRoZQ0KPiA+IHRleHR1YWwgcmVwcmVzZW50YXRpb24uDQo+ID4NCj4g PiAtRGF2ZQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206 IGlwdjYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQo+ID4+IE9mIE9sZSBUcsO4YW4NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDEz LCAyMDEyIDU6MTggQU0NCj4gPj4gVG86IGlwdjZAaWV0Zi5vcmcgTWFpbGluZyBMaXN0DQo+ID4+ IENjOiA2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZyBDaGFpcnM7IGRyYWZ0LWlldGYtNm1hbi11 cmktDQo+ID4+IHpvbmVpZEB0b29scy5pZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiA2TUFOIFdHIFtz ZWNvbmRdIExhc3QgQ2FsbDoNCj4gPj4gZHJhZnQtaWV0Zi02bWFuLXVyaS16b25laWQtMDEudHh0 DQo+ID4+DQo+ID4+IEFsbCwNCj4gPj4NCj4gPj4gVGhpcyBtZXNzYWdlIHN0YXJ0cyBhIG9uZS13 ZWVrIDZNQU4gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24NCj4gYWR2YW5jaW5nOg0KPiA+PiAg ICAgIFRpdGxlICAgICA6IFJlcHJlc2VudGluZyBJUHY2IFpvbmUgSWRlbnRpZmllcnMgaW4gVW5p Zm9ybQ0KPiA+PiAgICAgICAgICAgICAgICAgIFJlc291cmNlIElkZW50aWZpZXJzDQo+ID4+ICAg ICAgQXV0aG9yKHMpIDogQnJpYW4gQ2FycGVudGVyDQo+ID4+ICAgICAgICAgICAgICAgICAgUm9i ZXJ0IE0uIEhpbmRlbg0KPiA+PiAgICAgIEZpbGVuYW1lICA6IGRyYWZ0LWlldGYtNm1hbi11cmkt em9uZWlkLTAxLnR4dA0KPiA+PiAgICAgIFBhZ2VzICAgICA6IDkNCj4gPj4gICAgICBEYXRlICAg ICAgOiAyMDEyLTA1LTI5DQo+ID4+DQo+ID4+DQo+ID4+IGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQu IFN1YnN0YW50aXZlIGNvbW1lbnRzIHNob3VsZCBiZSBkaXJlY3RlZCB0bw0KPiA+PiB0aGUgbWFp bGluZyBsaXN0IG9yIHRoZSBjby1jaGFpcnMuIEVkaXRvcmlhbCBzdWdnZXN0aW9ucyBjYW4gYmUg c2VudCB0byB0aGUNCj4gYXV0aG9ycy4NCj4gPj4gVGhpcyBsYXN0IGNhbGwgd2lsbCBlbmQgb24g SnVuZSAyMCwgMjAxMi4NCj4gPj4gUmVnYXJkcywNCj4gPj4gQm9iLCAmIE9sZQ0KPiA+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPj4g aXB2NkBpZXRmLm9yZw0KPiA+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4g Pg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+ID4gaXB2NkBpZXRmLm9yZw0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+DQo+IA0KDQo= From dthaler@microsoft.com Fri Jul 6 10:32:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF5621F869F for ; Fri, 6 Jul 2012 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.717 X-Spam-Level: X-Spam-Status: No, score=-103.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leXx-MoW34rN for ; Fri, 6 Jul 2012 10:32:37 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 24CEF21F85CF for ; Fri, 6 Jul 2012 10:32:37 -0700 (PDT) Received: from mail139-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:30:45 +0000 Received: from mail139-ch1 (localhost [127.0.0.1]) by mail139-ch1-R.bigfish.com (Postfix) with ESMTP id 791662002A3; Fri, 6 Jul 2012 17:30:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VS-39(zz98dI9371Ic89bh936eI1b0bM542M1432Izz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839h93fhd25hf0ah107ah) Received-SPF: pass (mail139-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail139-ch1 (localhost.localdomain [127.0.0.1]) by mail139-ch1 (MessageSwitch) id 134159584426792_22978; Fri, 6 Jul 2012 17:30:44 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail139-ch1.bigfish.com (Postfix) with ESMTP id EED98340049; Fri, 6 Jul 2012 17:30:43 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:30:43 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 6 Jul 2012 17:32:49 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 10:32:49 -0700 From: Dave Thaler To: Brian E Carpenter , Bob Hinden Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Thread-Topic: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Thread-Index: AQHNSV6WE3ShC1aRY0CMvMGykLyPMZcbk/DggAE9goCAABCNgIAAMTuA//+TqrA= Date: Fri, 6 Jul 2012 17:32:49 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B690A00@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> <4FF718C7.5060206@gmail.com> In-Reply-To: <4FF718C7.5060206@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-uri-zoneid@tools.ietf.org" , "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:32:38 -0000 SXQncyBkb2N1bWVudGVkIG9uIHRoZSBwYWdlIGluIG15IG9yaWdpbmFsIGVtYWlsLg0KDQpIb3dl dmVyIGl0J3Mgbm90IHN1ZmZpY2llbnQuICBSZW1lbWJlciBteSBzZWNvbmQgcGllY2Ugb2YgZmVl ZGJhY2sgd2FzDQp0aGF0IHRoZSBkb2N1bWVudCBjb250cmFkaWN0cyBpdHNlbGYsIGltcGx5aW5n IHRoZSBzcGVjaWZpZWQgc3ludGF4IHN1cHBvcnRzDQpjdXQgYW5kIHBhc3RlLCBidXQgdGhlbiBk b2Vzbid0IHByb3ZpZGUgYSBzZWN0aW9uIHVwZGF0aW5nIFJGQyA0MDA3IHNlY3Rpb24gMTEuDQoN CklmIHRoZSBkb2N1bWVudCBib3RoIG1lbnRpb25zIHRoYXQgYWx0ZXJuYXRpdmUgMyBpcyB1c2Vk IGJ5IG1hbnkgdGhpbmdzIHRvZGF5DQooSUUsIFdpbmRvd3MsIGFwcGxpY2F0aW9ucykgd2l0aGlu IEFQSXMgdGhhdCB0YWtlIFVSSS1saWtlIHN0cmluZ3MsIGFuZCBhbHNvIGFkZHMNCmEgc2VjdGlv biB1cGRhdGluZyBSRkMgNDAwNyBzZWN0aW9uIDExLCB0aGVuIEknZCBiZSBoYXBweSB3aXRoIGl0 Lg0KDQotRGF2ZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFu IEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBTZW50 OiBGcmlkYXksIEp1bHkgMDYsIDIwMTIgOTo1NyBBTQ0KPiBUbzogQm9iIEhpbmRlbg0KPiBDYzog RGF2ZSBUaGFsZXI7IDZtYW4tY2hhaXJzQHRvb2xzLmlldGYub3JnIENoYWlyczsgZHJhZnQtaWV0 Zi02bWFuLXVyaS0NCj4gem9uZWlkQHRvb2xzLmlldGYub3JnOyBpcHY2QGlldGYub3JnIE1haWxp bmcgTGlzdA0KPiBTdWJqZWN0OiBSZTogNk1BTiBXRyBbc2Vjb25kXSBMYXN0IENhbGw6IGRyYWZ0 LWlldGYtNm1hbi11cmktem9uZWlkLTAxLnR4dA0KPiANCj4gSSdkIGJlIGhhcHB5IHdpdGggdGhh dCwgb3IgYSBzbWFsbCBhcHBlbmRpeC4gRGF2ZSwgaXMgaXQgZG9jdW1lbnRlZCBhbnl3aGVyZT8N Cj4gDQo+IFJlZ2FyZHMNCj4gICAgQnJpYW4NCj4gDQo+IE9uIDIwMTItMDctMDYgMTU6MDAsIEJv YiBIaW5kZW4gd3JvdGU6DQo+ID4gV2l0aCBteSBjby1hdXRob3IgaGF0IG9uLCB3b3VsZCBpdCBo ZWxwIHRvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBvZiB3aGF0IElFDQo+IHN1cHBvcnRzIGluIFNl Y3Rpb24gMy4gV2ViIEJyb3dzZXJzPw0KPiA+DQo+ID4gQm9iDQo+ID4NCj4gPg0KPiA+IE9uIEp1 bCA2LCAyMDEyLCBhdCA2OjAxIEFNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gPg0KPiA+ PiBEYXZlLA0KPiA+Pg0KPiA+PiAxKSBGWUksIHRoZSBkZWFkbGluZSB3ZSBnYXZlIHRoZSBVUkkg bGlzdCB0byBjb21tZW50IG9uIHRoaXMgaGFzIGp1c3QNCj4gPj4gcGFzc2VkLCB3aXRoIG9ubHkg b25lIChwb3NpdGl2ZSkgcmVwbHkuDQo+ID4+DQo+ID4+IDIpIEl0J3MgZm9yIHRoZSBXRyBDaGFp cnMgdG8gc2F5IGlmIHRoZXkgd2FudCBhbm90aGVyIHZlcnNpb24gaW4gdmlldw0KPiA+PiBvZiB5 b3VyIGNvbW1lbnRzLg0KPiA+Pg0KPiA+PiAzKSBJIGRvbid0IHNlZSBob3cgdGhlICUgZm9ybWF0 IGlzIGN1cnJlbnRseSBsZWdhbC4gVGhlcmUncyBubw0KPiA+PiBwcm92aXNpb24gZm9yIGFueSBj aGFyYWN0ZXJzIGFmdGVyIHRoZSBJUHY2IGFkZHJlc3MsIHdoZXRoZXINCj4gPj4gcGVyY2VudC1l bmNvZGVkIG9yIG5vdC4gV2UgaGVhcmQgb2YgYnJvd3NlcnMgdGhhdCBwcmV2aW91c2x5IGFsbG93 ZWQNCj4gPj4gZnVsbCBSRkMgNDAwNyBzeW50YXggKCUgKm5vdCogdHJlYXRlZCBhcyBhbiBlc2Nh cGUpIGJ1dCB0aGlzIGlzIHRoZQ0KPiA+PiBmaXJzdCBJJ3ZlIGhlYXJkIG9mIElFIGFsbG93aW5n IGEgem9uZSBpbmRleCBhdCBhbGwuDQo+ID4+DQo+ID4+IFJlZ2FyZHMNCj4gPj4gICBCcmlhbg0K PiA+Pg0KPiA+PiBPbiAyMDEyLTA3LTA2IDAyOjI4LCBEYXZlIFRoYWxlciB3cm90ZToNCj4gPj4+ IEkga25vdyBpdCdzIGFmdGVyIHRoZSBkZXNpZ25hdGVkIGVuZCBvZiBXR0xDLCBidXQgaGVyZSdz IG15IGZlZWRiYWNrLi4uDQo+ID4+Pg0KPiA+Pj4gVGhlIGRvY3VtZW50IGFwcGVhcnMgdG8gY2Fs bCBvdXQgZXhpc3RpbmcgcHJhY3RpY2UgaW4gc2V2ZXJhbCBwbGFjZXMsIHN1Y2ggYXMNCj4gaW4g c2VjdGlvbiAxOg0KPiA+Pj4+ICBTb21lIHZlcnNpb25zIG9mIHNvbWUgYnJvd3NlcnMgYWNjZXB0 IHRoZSBSRkMgNDAwNyBzeW50YXggZm9yDQo+ID4+Pj4gc2NvcGVkDQo+ID4+Pj4gIElQdjYgYWRk cmVzc2VzIGVtYmVkZGVkIGluIFVSSXMsIGkuZS4sIHRoZXkgaGF2ZSBiZWVuIGNvZGVkIHRvDQo+ ID4+Pj4gaW50ZXJwcmV0IHRoZSAiJSIgc2lnbiBhY2NvcmRpbmcgdG8gUkZDIDQwMDcgaW5zdGVh ZCBvZiBSRkMgMzk4Ni4NCj4gPj4+IGFuZCBpbiBBcHBlbmRpeCBBIHBvaW50IDE6DQo+ID4+Pj4g QWR2YW50YWdlOiB3b3JrcyB0b2RheS4NCj4gPj4+IEhvd2V2ZXIsIGl0J3MgbWlzc2luZyBkaXNj dXNzaW9uIG9mIG90aGVyIGFsdGVybmF0aXZlcyBhbHJlYWR5IGluIGNvbW1vbg0KPiBwcmFjdGlj ZS4NCj4gPj4+IEZvciBleGFtcGxlIGFsdGVybmF0aXZlIDMgKGVzY2FwaW5nIHRoZSBlc2NhcGUg Y2hhcmFjdGVyIGFzIGFsbG93ZWQgYnkgUkZDDQo+IDM5ODYpIGhhczoNCj4gPj4+PiAgICAgIEFk dmFudGFnZTogYWxsb3dzIHVzZSBvZiBicm93c2VyLg0KPiA+Pj4+DQo+ID4+Pj4gICAgICBEaXNh ZHZhbnRhZ2U6IHVnbHkgYW5kIGNvbmZ1c2luZywgZG9lc24ndCBhbGxvdyBzaW1wbGUgY3V0IGFu ZA0KPiA+Pj4+ICAgICAgcGFzdGUuDQo+ID4+PiBUaGUgZGlzYWR2YW50YWdlIGlzIGNlcnRhaW5s eSB0cnVlLiAgSG93ZXZlciB0aGUgbWFpbiBhZHZhbnRhZ2UgYXJlDQo+ID4+PiBub3RhYmx5IGxh Y2tpbmcsIHdoaWNoIGlzIHRoYXQgaXQncyBhbHJlYWR5IGluIGNvbW1vbiBwcmFjdGljZSBpbg0K PiA+Pj4gbWFueSBwbGFjZXMgKHRvIHRoZSBleHRlbnQgdGhhdCB1c2luZyBhIHpvbmUgaWQgYXQg YWxsIGlzIGNvbW1vbiBwcmFjdGljZQ0KPiBhbnl3YXkpLg0KPiA+Pj4NCj4gPj4+IFlvdSdsbCBz ZWUgYXQNCj4gPj4+IGh0dHA6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS93aW5k b3dzL2Rlc2t0b3AvYWEzODUzMjUodj12DQo+ID4+PiBzLjg1KS5hc3B4IHRoYXQgYWx0ZXJuYXRp dmUgMyBpcyB3aGF0IGlzIHN1cHBvcnRlZCBpbiBJRTcgYW5kIGFib3ZlLA0KPiA+Pj4gYW5kIHRo ZSBBUElzIGFyZSBnZW5lcmFsbHkgYXZhaWxhYmxlIHRvIFdpbmRvd3MgYXBwbGljYXRpb25zIChp LmUuDQo+ID4+PiBub3QganVzdCBJRTcpLg0KPiA+Pj4NCj4gPj4+IFRoZSBkb2N1bWVudCBkb2Vz IG5vdCBzdGF0ZSB3aGV0aGVyIHRoZSBleGlzdGluZyBsZWdhbCB1c2UgaXMNCj4gPj4+IHN1ZGRl bmx5IGRlY2xhcmVkIHRvIGJlIGlsbGVnYWwsIG9yIGp1c3QgYW5vdGhlciBsZWdhbCB3YXkgb2Yg ZG9pbmcgdGhlIHNhbWUNCj4gdGhpbmcuDQo+ID4+Pg0KPiA+Pj4gSWYgeW91J3JlIHRlbGxpbmcg ZXhpc3RpbmcgYXBwbGljYXRpb25zIGFuZCBPUydzIHRoYXQgdXNlIGFsdGVybmF0aXZlIDMgdGhh dCB0aGV5DQo+ID4+PiBoYXZlIHRvIGNoYW5nZSwgdGhhdCBkb2Vzbid0IHNvdW5kIGxpa2UgYSBn b29kIHRoaW5nLiAgIFRoYXQncyBiZWNhdXNlIG1hbnkNCj4gYXBwcw0KPiA+Pj4gd2FudCB0byBi ZSBPUy12ZXJzaW9uLWluZGVwZW5kZW50IGFuZCB1c2UgVVJJIHBhcnNpbmcgbGlicmFyaWVzIHBy b3ZpZGVkDQo+IGJ5DQo+ID4+PiB0aGUgT1MuICAgV2UgZG9uJ3Qgd2FudCBhcHBzIHRvIGNvZGUg dGhlaXIgb3duIFVSSSBwYXJzaW5nIChpdCdzIHZlcnkgZWFzeSB0bw0KPiA+Pj4gZ2V0IHdyb25n LCBlc3BlY2lhbGx5IHdoZW4geW91IGFkZCB2YXJpb3VzIGludGVybmF0aW9uYWxpemF0aW9uIGlz c3VlcykuDQo+ID4+PiBBcyBhIHJlc3VsdCwgYXBwcyB3aWxsIHRlbmQgdG8gY29kZSB0byB0aGUg bG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBvZg0KPiA+Pj4gT1MncyB0aGV5IHdhbnQgdG8gd29y ayBvbi4gICAgVGhhdCBtZWFucyBJIGV4cGVjdCB0byBzZWUgYXBwcyBjb2RpbmcgdG8NCj4gPj4+ IGFsdGVybmF0aXZlIDMgZm9yIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUuICAgV2hlbiB0aGV5IGRv bid0IHVzZSB0aGVtIGluDQo+ID4+PiBlZGl0IGJveGVzLCB0aGUgZGlzYWR2YW50YWdlIG9mIG5v dCBiZWluZyBhYmxlIHRvIGN1dCBhbmQgcGFzdGUgaXMNCj4gPj4+IG5vdCBhIHJlYWwgZGlzYWR2 YW50YWdlLg0KPiA+Pj4NCj4gPj4+IFBlcnNvbmFsbHkgSSBkb24ndCBoYXZlIGFuIGlzc3VlIHdp dGggYWxsb3dpbmcgYm90aCBmb3JtYXRzIGlmIHRoZQ0KPiA+Pj4gV0cgZmVlbHMgc3Ryb25nbHkg dGhhdCBhIGN1dC1hbmQtcGFzdGUtZnJpZW5kbHkgZm9ybWF0IGlzIG5lZWRlZCBpbg0KPiA+Pj4g YWRkaXRpb24gdG8gd2hhdCdzIGV4aXN0aW5nIHByYWN0aWNlLCB0aG91Z2ggaGF2aW5nIHR3byBk b2VzIGFmZmVjdA0KPiA+Pj4gdGhlIHJ1bGVzIGZvciBjb21wYXJpc29uIChzZWUgZHJhZnQtaWFi LWlkZW50aWZpZXItY29tcGFyaXNvbg0KPiA+Pj4gc2VjdGlvbiAzLjEuMikgYnV0IG5vdCBub3Rp Y2VhYmx5Lg0KPiA+Pj4NCj4gPj4+IEZpbmFsbHksIHRoZSBzdGF0ZWQgZGlzYWR2YW50YWdlIG9m IGFsdGVybmF0aXZlIDMgaXMgb25seSBhIGRpc2FkdmFudGFnZSBpZiB0aGUNCj4gPj4+IHNwZWNp ZmllZCBzY2hlbWUgaW4gc2VjdGlvbiAyICpkb2VzKiBhbGxvdyBjdXQtYW5kLXBhc3RlLiAgIEZv ciB0aGF0IHRvDQo+ID4+PiBoYXBwZW4sIGl0IG1lYW5zIHRoZSB6b25lIGlkIHNlcGFyYXRvciBo YXMgdG8gd29yayBvdXRzaWRlIHRoZSBjb250ZXh0IG9mDQo+ID4+PiBVUklzLiAgIFRoYXQgaXMs IHNlY3Rpb24gMiBzYXlzOg0KPiA+Pj4+ICBUaHVzLCB0aGUgc2NvcGVkIGFkZHJlc3MgZmU4MDo6 YSVlbjEgd291bGQgYXBwZWFyIGluIGEgVVJJIGFzDQo+ID4+Pj4gaHR0cDovL1tmZTgwOjphLWVu MV0uDQo+ID4+PiBUbyBzdXBwb3J0IGN1dC1hbmQtcGFzdGUsIHRoYXQgbWVhbnMgdGhhdCAicGlu ZyBmZTgwOjphLWVuMSINCj4gPj4+IG5lZWRzIHRvIHdvcmsuICAgQnV0IHRoaXMgZG9jdW1lbnQg aXMgdGl0bGVkDQo+ID4+PiAiIFJlcHJlc2VudGluZyBJUHY2IFpvbmUgSWRlbnRpZmllcnMgaW4g VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVycyINCj4gPj4+IGFuZCBzaW1pbGFybHkgdGhlIGFi c3RyYWN0IGxpbWl0cyBpdHMgc2NvcGUgdG8gVVJJcy4NCj4gPj4+DQo+ID4+PiBIZW5jZSBzZWN0 aW9uIDIgaXMgaW4gY29udHJhZGljdGlvbiB3aXRoIHRoZSBhbmFseXNpcyBvZiBhbHRlcm5hdGl2 ZSAzLg0KPiA+Pj4gVGhlIGRvY3VtZW50IGFscmVhZHkgc2F5cyBpdCAidXBkYXRlcyA0MDA3IiBz byBpdCBzZWVtcyB0aGF0IHdoYXQncw0KPiA+Pj4gbGFja2luZyBpcyBhIHNlY3Rpb24gc3BlY2lm aWNhbGx5IHVwZGF0aW5nIFJGQyA0MDA3IHNlY3Rpb24gMTEgd2hpY2gNCj4gPj4+IHdvdWxkIGRl Y2xhcmUgdGhhdCBib3RoICclJyBhbmQgJy0nIGFyZSBhY2NlcHRhYmxlIHNlcGFyYXRvcnMgaW4g dGhlDQo+ID4+PiB0ZXh0dWFsIHJlcHJlc2VudGF0aW9uLg0KPiA+Pj4NCj4gPj4+IC1EYXZlDQo+ ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogaXB2 Ni1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+ Pj4+IEJlaGFsZiBPZiBPbGUgVHLDuGFuDQo+ID4+Pj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDEz LCAyMDEyIDU6MTggQU0NCj4gPj4+PiBUbzogaXB2NkBpZXRmLm9yZyBNYWlsaW5nIExpc3QNCj4g Pj4+PiBDYzogNm1hbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgQ2hhaXJzOyBkcmFmdC1pZXRmLTZt YW4tdXJpLQ0KPiA+Pj4+IHpvbmVpZEB0b29scy5pZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IDZN QU4gV0cgW3NlY29uZF0gTGFzdCBDYWxsOg0KPiA+Pj4+IGRyYWZ0LWlldGYtNm1hbi11cmktem9u ZWlkLTAxLnR4dA0KPiA+Pj4+DQo+ID4+Pj4gQWxsLA0KPiA+Pj4+DQo+ID4+Pj4gVGhpcyBtZXNz YWdlIHN0YXJ0cyBhIG9uZS13ZWVrIDZNQU4gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24NCj4g YWR2YW5jaW5nOg0KPiA+Pj4+ICAgICBUaXRsZSAgICAgOiBSZXByZXNlbnRpbmcgSVB2NiBab25l IElkZW50aWZpZXJzIGluIFVuaWZvcm0NCj4gPj4+PiAgICAgICAgICAgICAgICAgUmVzb3VyY2Ug SWRlbnRpZmllcnMNCj4gPj4+PiAgICAgQXV0aG9yKHMpIDogQnJpYW4gQ2FycGVudGVyDQo+ID4+ Pj4gICAgICAgICAgICAgICAgIFJvYmVydCBNLiBIaW5kZW4NCj4gPj4+PiAgICAgRmlsZW5hbWUg IDogZHJhZnQtaWV0Zi02bWFuLXVyaS16b25laWQtMDEudHh0DQo+ID4+Pj4gICAgIFBhZ2VzICAg ICA6IDkNCj4gPj4+PiAgICAgRGF0ZSAgICAgIDogMjAxMi0wNS0yOQ0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+PiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkLiBTdWJzdGFudGl2ZSBjb21tZW50cyBzaG91 bGQgYmUgZGlyZWN0ZWQgdG8NCj4gPj4+PiB0aGUgbWFpbGluZyBsaXN0IG9yIHRoZSBjby1jaGFp cnMuIEVkaXRvcmlhbCBzdWdnZXN0aW9ucyBjYW4gYmUgc2VudCB0byB0aGUNCj4gYXV0aG9ycy4N Cj4gPj4+PiBUaGlzIGxhc3QgY2FsbCB3aWxsIGVuZCBvbiBKdW5lIDIwLCAyMDEyLg0KPiA+Pj4+ IFJlZ2FyZHMsDQo+ID4+Pj4gQm9iLCAmIE9sZQ0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+PiAt IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2QGlldGYub3JnIEFkbWlu aXN0cmF0aXZlDQo+ID4+Pj4gUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+PiAtDQo+ID4+Pg0KPiA+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBp cHY2QGlldGYub3JnIEFkbWluaXN0cmF0aXZlDQo+ID4+PiBSZXF1ZXN0czogaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4N Cj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+ID4+IGlwdjZAaWV0Zi5vcmcNCj4gPj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+DQo+ID4NCj4gDQoNCg== From simon.perreault@viagenie.ca Sat Jul 7 14:22:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DAC21F869F for ; Sat, 7 Jul 2012 14:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL+HQlvp2DNk for ; Sat, 7 Jul 2012 14:22:20 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3121F8685 for ; Sat, 7 Jul 2012 14:22:20 -0700 (PDT) Received: from eeepc.viagenie.ca (211.17-ppp.3menatwork.com [72.0.211.17]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AD8C7425E8 for ; Sat, 7 Jul 2012 17:22:39 -0400 (EDT) Message-ID: <4FF8AA14.8070201@viagenie.ca> Date: Sat, 07 Jul 2012 14:28:52 -0700 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:9.0) Gecko/20120207 Thunderbird/9.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: draft-chen-v6ops-nat64-experience-02 References: <4FF696AA.3050508@tut.fi> In-Reply-To: <4FF696AA.3050508@tut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 21:22:20 -0000 On 07/06/12 00:41, Aleksi Suhonen wrote: > It would be my recommendation that there was either a Router > Advertisement Flags Option for "do not use privacy extensions here" and > that this was used in all setups that use DNS64 name servers, or that > all such setups should use Managed Address Configuration aka DHCPv6 > address configuration. ...only when your NAT64 is configured to provide 1:1 mapping between IPv4 and IPv6 addresses. Privacy extensions have been working fine for us with n:1 mapping. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From sarikaya2012@gmail.com Mon Jul 9 10:17:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A0A11E80C8 for ; Mon, 9 Jul 2012 10:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7NmU5kYBRKc for ; Mon, 9 Jul 2012 10:17:51 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5EC411E8140 for ; Mon, 9 Jul 2012 10:17:47 -0700 (PDT) Received: by ggnc4 with SMTP id c4so11332316ggn.31 for ; Mon, 09 Jul 2012 10:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XYvPtWdQjLvpRRc4kC7YDBDBaR0hRla4YyfbQzqw17o=; b=urvlKCjg2U5lmZu4N6LFNuHWR9KqdsIZj/ZloKbAYFevZ7FnLTZgz12l1D8U9EbvF5 f1KgBA84CiankOj2h3T0Ox6LC0duOF7fYutLGLrkZrCc2u8zJNINCn3SGZy01wIoGKcL T7U14s0zAJP6Pmu80aMMWrTIifrqEhxKOuZ7ketK7kmes9HzTthSE0k4bLjhe25pia53 i3XOXG2ymWm6jEAMUoKHwKL3LPeJTRkx4NcvubN79V9EsL8ni/7sYe4KnC9LZmHDHafT eex2dtLdNCJmHtBab/sFCuzNwy+ZNI9M2bmvaQu+0dci2yt9ZMRcunxl0/0PQzwCoJcj IqUQ== MIME-Version: 1.0 Received: by 10.42.130.68 with SMTP id u4mr20941268ics.17.1341854292337; Mon, 09 Jul 2012 10:18:12 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Mon, 9 Jul 2012 10:18:12 -0700 (PDT) In-Reply-To: <23986.1341586765@marajade.sandelman.ca> References: <4FF696AA.3050508@tut.fi> <23986.1341586765@marajade.sandelman.ca> Date: Mon, 9 Jul 2012 12:18:12 -0500 Message-ID: Subject: Re: draft-chen-v6ops-nat64-experience-02 From: Behcet Sarikaya To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:17:52 -0000 On Fri, Jul 6, 2012 at 9:59 AM, Michael Richardson wrote: > >>>>>> "Aleksi" == Aleksi Suhonen writes: > Aleksi> Within an hour, all the IPv4 addresses in the pool for our > Aleksi> NAT64 were registered to this one device. > > Do I understand that you attempt to provide a single IPv4 address 1:1 > with a an internal IPv6 address? (NAT vs NAPT) It seems like this is what is called stateless NAT64. I am not sure if there is any document specifying stateless NAT64? Regards, Behcet From cb.list6@gmail.com Mon Jul 9 10:38:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A633611E80C9 for ; Mon, 9 Jul 2012 10:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D755JG41vZrl for ; Mon, 9 Jul 2012 10:38:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E080911E809C for ; Mon, 9 Jul 2012 10:38:09 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so20142753pbc.31 for ; Mon, 09 Jul 2012 10:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aDyOUYvGYWTpJgkclRU6v5tMdKJErpbInyYFh9Wo5P4=; b=LmZ5KSrJIBEhdg338eXzr9kH75bTTbDQbMK9Mwp9rEs2Gsq4lXf4oy3kT3GC/TNqhS i2kfdypYsban5cFpfW7PHkFz3zsoXosBEhiZymdN96ypKA0SabMYeIWf8H2vgtzZCmuQ EDl8LpCt2l7neiYtJFW2xNRg8bpm3+0wOfPbjJNd6PHshq7ZZK6hLF3K4QBYnjc2AHoz 6rdZt13ru2DxhavEwNdhp/3w1v1p38Xiyfbi1yZhYt0SUIWX8qGu7+bZv7PQvINHDrnt cd8RaGYzKZxMxDdVuuUsNoSf0cDRgtw75jtJrpGDGWdIh6r/MFqhyQrzG/I7coC924NB ag4A== MIME-Version: 1.0 Received: by 10.68.239.9 with SMTP id vo9mr62277544pbc.41.1341855515132; Mon, 09 Jul 2012 10:38:35 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Mon, 9 Jul 2012 10:38:35 -0700 (PDT) In-Reply-To: References: <4FF696AA.3050508@tut.fi> <23986.1341586765@marajade.sandelman.ca> Date: Mon, 9 Jul 2012 10:38:35 -0700 Message-ID: Subject: Re: draft-chen-v6ops-nat64-experience-02 From: Cameron Byrne To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:38:10 -0000 On Mon, Jul 9, 2012 at 10:18 AM, Behcet Sarikaya wrote: > On Fri, Jul 6, 2012 at 9:59 AM, Michael Richardson > wrote: >> >>>>>>> "Aleksi" == Aleksi Suhonen writes: >> Aleksi> Within an hour, all the IPv4 addresses in the pool for our >> Aleksi> NAT64 were registered to this one device. >> >> Do I understand that you attempt to provide a single IPv4 address 1:1 >> with a an internal IPv6 address? (NAT vs NAPT) > > It seems like this is what is called stateless NAT64. > I am not sure if there is any document specifying stateless NAT64? > > Regards, > > Behcet Stateless = http://tools.ietf.org/html/rfc6145 Stateful = http://tools.ietf.org/html/rfc6146 If the goal is providing a dynamic access from an IPv6-only network toward IPv4-only internet, RFC 6146 is the optimal choice. RFC 6145 has limited use for the cases for IPv6 - > IPv4 since it is 1:1 mapping. Most people do IPv6 because IPv4 is limited, so ... doing 1:1 mapping does not really buy you anything. You can just use IPv4 and achieve the same scale. The best use case i have seen for RFC 6145 is for the data center environment http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf as well as the mapping of the entire IPv4 internet into IPv6 as is the case of 464XLAT CLAT in the IPv4->IPv6 scenario. CB From sarikaya2012@gmail.com Mon Jul 9 11:41:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AF221F8830 for ; Mon, 9 Jul 2012 11:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCykAY+xnn0T for ; Mon, 9 Jul 2012 11:41:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 309C021F883F for ; Mon, 9 Jul 2012 11:41:19 -0700 (PDT) Received: by yhq56 with SMTP id 56so13008912yhq.31 for ; Mon, 09 Jul 2012 11:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ULODcj5pBlQPzzin2wnVAaLCXsYPGa3vNStIYbkanqw=; b=Nwacj/O+cpDR7bW7B1tdtSBGMDvgpRQj1zUL5GEu4Vd3lRo8m21iYMqOuuKLZw7RjJ C/mOH62ql5/F4YdC7T60gMgef33m836acKZqD3AU5VaCMPhFAWluh3GY8IfoICU7J0gp ywaop+iA22cn7H1Sopf4V1VdV9rYLpQNyXBwpxGFH8v9QEKyUNt1FAnuUYjsarbIpZXw 6IC17nCVKmZ6bNHzUK38UZYwFiECp3xq2JO+SlhZBXaJC3pvQ/gXrw94JMcZYuWX0wDm t1kKj+puQpuLO+iY1tYNz9ixrcnfSspr922qtjCGEXmFkJ47uNSpLm9MQelQ9vsBFTPG cg3g== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr9382499igc.63.1341859304397; Mon, 09 Jul 2012 11:41:44 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Mon, 9 Jul 2012 11:41:44 -0700 (PDT) In-Reply-To: References: <4FF696AA.3050508@tut.fi> <23986.1341586765@marajade.sandelman.ca> Date: Mon, 9 Jul 2012 13:41:44 -0500 Message-ID: Subject: Re: draft-chen-v6ops-nat64-experience-02 From: Behcet Sarikaya To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:41:20 -0000 On Mon, Jul 9, 2012 at 12:38 PM, Cameron Byrne wrote: > On Mon, Jul 9, 2012 at 10:18 AM, Behcet Sarikaya wrote: >> On Fri, Jul 6, 2012 at 9:59 AM, Michael Richardson >> wrote: >>> >>>>>>>> "Aleksi" == Aleksi Suhonen writes: >>> Aleksi> Within an hour, all the IPv4 addresses in the pool for our >>> Aleksi> NAT64 were registered to this one device. >>> >>> Do I understand that you attempt to provide a single IPv4 address 1:1 >>> with a an internal IPv6 address? (NAT vs NAPT) >> >> It seems like this is what is called stateless NAT64. >> I am not sure if there is any document specifying stateless NAT64? >> >> Regards, >> >> Behcet > > Stateless = http://tools.ietf.org/html/rfc6145 Are you sure? Here is a quote from 6146: Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice versa. The translation is done by translating the packet headers according to the IP/ICMP Translation Algorithm defined in [RFC6145]. Regards, Behcet > > Stateful = http://tools.ietf.org/html/rfc6146 > > If the goal is providing a dynamic access from an IPv6-only network > toward IPv4-only internet, RFC 6146 is the optimal choice. > > RFC 6145 has limited use for the cases for IPv6 - > IPv4 since it is > 1:1 mapping. Most people do IPv6 because IPv4 is limited, so ... > doing 1:1 mapping does not really buy you anything. You can just use > IPv4 and achieve the same scale. > > The best use case i have seen for RFC 6145 is for the data center > environment http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf > as well as the mapping of the entire IPv4 internet into IPv6 as is > the case of 464XLAT CLAT in the IPv4->IPv6 scenario. > > CB From simon.perreault@viagenie.ca Mon Jul 9 11:49:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C458611E80D3 for ; Mon, 9 Jul 2012 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdG-PiGEtPfH for ; Mon, 9 Jul 2012 11:49:22 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id AA48F11E80CF for ; Mon, 9 Jul 2012 11:49:22 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:21aa:2a3f:6536:e26d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EEA54412C4 for ; Mon, 9 Jul 2012 14:49:46 -0400 (EDT) Message-ID: <4FFB27CA.5070002@viagenie.ca> Date: Mon, 09 Jul 2012 14:49:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: draft-chen-v6ops-nat64-experience-02 References: <4FF696AA.3050508@tut.fi> <23986.1341586765@marajade.sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:49:27 -0000 On 2012-07-09 14:41, Behcet Sarikaya wrote: > On Mon, Jul 9, 2012 at 12:38 PM, Cameron Byrne wrote: >> On Mon, Jul 9, 2012 at 10:18 AM, Behcet Sarikaya wrote: >>> It seems like this is what is called stateless NAT64. >>> I am not sure if there is any document specifying stateless NAT64? >> >> Stateless = http://tools.ietf.org/html/rfc6145 > > Are you sure? > > Here is a quote from 6146: > Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 > packets and vice versa. The translation is done by translating the > packet headers according to the IP/ICMP Translation Algorithm defined > in [RFC6145]. Cameron is right. RFC6145 is often referred to as "stateless NAT64". Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dthaler@microsoft.com Mon Jul 9 11:54:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0212611E80F3 for ; Mon, 9 Jul 2012 11:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.211 X-Spam-Level: X-Spam-Status: No, score=-105.211 tagged_above=-999 required=5 tests=[AWL=1.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZArhgrruTVU for ; Mon, 9 Jul 2012 11:54:55 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id A8DFE11E80E2 for ; Mon, 9 Jul 2012 11:54:55 -0700 (PDT) Received: from mail136-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Jul 2012 18:53:03 +0000 Received: from mail136-tx2 (localhost [127.0.0.1]) by mail136-tx2-R.bigfish.com (Postfix) with ESMTP id 7F05C6014D; Mon, 9 Jul 2012 18:53:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VS-39(zz98dI9371Ic89bh936eI1b0bM542M1432Izz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839h93fhd25hf0ah107ah) Received-SPF: pass (mail136-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail136-tx2 (localhost.localdomain [127.0.0.1]) by mail136-tx2 (MessageSwitch) id 134185996679579_3630; Mon, 9 Jul 2012 18:52:46 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.235]) by mail136-tx2.bigfish.com (Postfix) with ESMTP id 066532029D; Mon, 9 Jul 2012 18:52:46 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Jul 2012 18:52:45 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 9 Jul 2012 18:54:53 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 9 Jul 2012 11:54:52 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.191]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Mon, 9 Jul 2012 11:54:52 -0700 From: Dave Thaler To: Dave Thaler , Brian E Carpenter , Bob Hinden Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Thread-Topic: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Thread-Index: AQHNSV6WE3ShC1aRY0CMvMGykLyPMZcbk/DggAE9goCAABCNgIAAMTuA//+TqrCABM4kMA== Date: Mon, 9 Jul 2012 18:54:51 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B6A4C51@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> <4FF718C7.5060206@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B690A00@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B690A00@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-uri-zoneid@tools.ietf.org" , "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:54:57 -0000 T25lIGFkZGl0aW9uYWwgZ2FwIHRoYXQgSSB0aGluayBTSE9VTEQgYmUgYWRkcmVzc2VkLiAgUkZD IDM5ODYgc2F5czoNCg0KICAgVVJJcyBoYXZlIGEgZ2xvYmFsIHNjb3BlIGFuZCBhcmUgaW50ZXJw cmV0ZWQgY29uc2lzdGVudGx5IHJlZ2FyZGxlc3MNCiAgIG9mIGNvbnRleHQsIHRob3VnaCB0aGUg cmVzdWx0IG9mIHRoYXQgaW50ZXJwcmV0YXRpb24gbWF5IGJlIGluDQogICByZWxhdGlvbiB0byB0 aGUgZW5kLXVzZXIncyBjb250ZXh0LiAgRm9yIGV4YW1wbGUsICJodHRwOi8vbG9jYWxob3N0LyIN CiAgIGhhcyB0aGUgc2FtZSBpbnRlcnByZXRhdGlvbiBmb3IgZXZlcnkgdXNlciBvZiB0aGF0IHJl ZmVyZW5jZSwgZXZlbg0KICAgdGhvdWdoIHRoZSBuZXR3b3JrIGludGVyZmFjZSBjb3JyZXNwb25k aW5nIHRvICJsb2NhbGhvc3QiIG1heSBiZQ0KICAgZGlmZmVyZW50IGZvciBlYWNoIGVuZC11c2Vy OiBpbnRlcnByZXRhdGlvbiBpcyBpbmRlcGVuZGVudCBvZiBhY2Nlc3MuDQogICBIb3dldmVyLCBh biBhY3Rpb24gbWFkZSBvbiB0aGUgYmFzaXMgb2YgdGhhdCByZWZlcmVuY2Ugd2lsbCB0YWtlDQog ICBwbGFjZSBpbiByZWxhdGlvbiB0byB0aGUgZW5kLXVzZXIncyBjb250ZXh0LCB3aGljaCBpbXBs aWVzIHRoYXQgYW4NCiAgIGFjdGlvbiBpbnRlbmRlZCB0byByZWZlciB0byBhIGdsb2JhbGx5IHVu aXF1ZSB0aGluZyBtdXN0IHVzZSBhIFVSSQ0KICAgdGhhdCBkaXN0aW5ndWlzaGVzIHRoYXQgcmVz b3VyY2UgZnJvbSBhbGwgb3RoZXIgdGhpbmdzLiAgVVJJcyB0aGF0DQogICBpZGVudGlmeSBpbiBy ZWxhdGlvbiB0byB0aGUgZW5kLXVzZXIncyBsb2NhbCBjb250ZXh0IHNob3VsZCBvbmx5IGJlDQog ICB1c2VkIHdoZW4gdGhlIGNvbnRleHQgaXRzZWxmIGlzIGEgZGVmaW5pbmcgYXNwZWN0IG9mIHRo ZSByZXNvdXJjZSwNCiAgIHN1Y2ggYXMgd2hlbiBhbiBvbi1saW5lIGhlbHAgbWFudWFsIHJlZmVy cyB0byBhIGZpbGUgb24gdGhlIGVuZC0NCiAgIHVzZXIncyBmaWxlIHN5c3RlbSAoZS5nLiwgImZp bGU6Ly8vZXRjL2hvc3RzIikuDQoNCkl0IHNob3VsZCBiZSBwb2ludGVkIG91dCBpbiB0aGUgem9u ZWlkIGRvY3VtZW50IHRoYXQgYWRkaW5nIGEgem9uZSBpZA0KY2hhbmdlcyB0aGUgc2NvcGUgdG8g YmUgbG9jYWxob3N0IHJhdGhlciB0aGFuIHRoZSBzY29wZSBvZiB0aGUgYWRkcmVzcy4NCg0KU28g Imh0dHA6Ly9bZmU4MDo6MV0vYmxhaCIgaXMgdmFsaWQgYW55d2hlcmUgb24gdGhlIHNhbWUgbGlu ay4NCkJ1dCAiaHR0cDovL1tmZTgwOjoxLWlkXS9ibGFoIiBpcyB2YWxpZCBvbmx5IHdpdGhpbiB0 aGUgc2FtZSBob3N0Lg0KDQotRGF2ZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mDQo+IERhdmUgVGhhbGVyDQo+IFNlbnQ6IEZyaWRheSwgSnVseSA2LCAy MDEyIDEwOjMzIEFNDQo+IFRvOiBCcmlhbiBFIENhcnBlbnRlcjsgQm9iIEhpbmRlbg0KPiBDYzog Nm1hbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgQ2hhaXJzOyBkcmFmdC1pZXRmLTZtYW4tdXJpLQ0K PiB6b25laWRAdG9vbHMuaWV0Zi5vcmc7IGlwdjZAaWV0Zi5vcmcgTWFpbGluZyBMaXN0DQo+IFN1 YmplY3Q6IFJFOiA2TUFOIFdHIFtzZWNvbmRdIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi02bWFuLXVy aS16b25laWQtMDEudHh0DQo+IA0KPiBJdCdzIGRvY3VtZW50ZWQgb24gdGhlIHBhZ2UgaW4gbXkg b3JpZ2luYWwgZW1haWwuDQo+IA0KPiBIb3dldmVyIGl0J3Mgbm90IHN1ZmZpY2llbnQuICBSZW1l bWJlciBteSBzZWNvbmQgcGllY2Ugb2YgZmVlZGJhY2sgd2FzDQo+IHRoYXQgdGhlIGRvY3VtZW50 IGNvbnRyYWRpY3RzIGl0c2VsZiwgaW1wbHlpbmcgdGhlIHNwZWNpZmllZCBzeW50YXggc3VwcG9y dHMNCj4gY3V0IGFuZCBwYXN0ZSwgYnV0IHRoZW4gZG9lc24ndCBwcm92aWRlIGEgc2VjdGlvbiB1 cGRhdGluZyBSRkMgNDAwNyBzZWN0aW9uDQo+IDExLg0KPiANCj4gSWYgdGhlIGRvY3VtZW50IGJv dGggbWVudGlvbnMgdGhhdCBhbHRlcm5hdGl2ZSAzIGlzIHVzZWQgYnkgbWFueSB0aGluZ3MNCj4g dG9kYXkgKElFLCBXaW5kb3dzLCBhcHBsaWNhdGlvbnMpIHdpdGhpbiBBUElzIHRoYXQgdGFrZSBV UkktbGlrZSBzdHJpbmdzLCBhbmQNCj4gYWxzbyBhZGRzIGEgc2VjdGlvbiB1cGRhdGluZyBSRkMg NDAwNyBzZWN0aW9uIDExLCB0aGVuIEknZCBiZSBoYXBweSB3aXRoIGl0Lg0KPiANCj4gLURhdmUN Cj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBCcmlhbiBFIENh cnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gPiBTZW50OiBG cmlkYXksIEp1bHkgMDYsIDIwMTIgOTo1NyBBTQ0KPiA+IFRvOiBCb2IgSGluZGVuDQo+ID4gQ2M6 IERhdmUgVGhhbGVyOyA2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZyBDaGFpcnM7DQo+ID4gZHJh ZnQtaWV0Zi02bWFuLXVyaS0gem9uZWlkQHRvb2xzLmlldGYub3JnOyBpcHY2QGlldGYub3JnIE1h aWxpbmcgTGlzdA0KPiA+IFN1YmplY3Q6IFJlOiA2TUFOIFdHIFtzZWNvbmRdIExhc3QgQ2FsbDoN Cj4gPiBkcmFmdC1pZXRmLTZtYW4tdXJpLXpvbmVpZC0wMS50eHQNCj4gPg0KPiA+IEknZCBiZSBo YXBweSB3aXRoIHRoYXQsIG9yIGEgc21hbGwgYXBwZW5kaXguIERhdmUsIGlzIGl0IGRvY3VtZW50 ZWQNCj4gYW55d2hlcmU/DQo+ID4NCj4gPiBSZWdhcmRzDQo+ID4gICAgQnJpYW4NCj4gPg0KPiA+ IE9uIDIwMTItMDctMDYgMTU6MDAsIEJvYiBIaW5kZW4gd3JvdGU6DQo+ID4gPiBXaXRoIG15IGNv LWF1dGhvciBoYXQgb24sIHdvdWxkIGl0IGhlbHAgdG8gaW5jbHVkZSBhIGRlc2NyaXB0aW9uIG9m DQo+ID4gPiB3aGF0IElFDQo+ID4gc3VwcG9ydHMgaW4gU2VjdGlvbiAzLiBXZWIgQnJvd3NlcnM/ DQo+ID4gPg0KPiA+ID4gQm9iDQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9uIEp1bCA2LCAyMDEyLCBh dCA2OjAxIEFNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gPiA+DQo+ID4gPj4gRGF2ZSwN Cj4gPiA+Pg0KPiA+ID4+IDEpIEZZSSwgdGhlIGRlYWRsaW5lIHdlIGdhdmUgdGhlIFVSSSBsaXN0 IHRvIGNvbW1lbnQgb24gdGhpcyBoYXMNCj4gPiA+PiBqdXN0IHBhc3NlZCwgd2l0aCBvbmx5IG9u ZSAocG9zaXRpdmUpIHJlcGx5Lg0KPiA+ID4+DQo+ID4gPj4gMikgSXQncyBmb3IgdGhlIFdHIENo YWlycyB0byBzYXkgaWYgdGhleSB3YW50IGFub3RoZXIgdmVyc2lvbiBpbg0KPiA+ID4+IHZpZXcg b2YgeW91ciBjb21tZW50cy4NCj4gPiA+Pg0KPiA+ID4+IDMpIEkgZG9uJ3Qgc2VlIGhvdyB0aGUg JSBmb3JtYXQgaXMgY3VycmVudGx5IGxlZ2FsLiBUaGVyZSdzIG5vDQo+ID4gPj4gcHJvdmlzaW9u IGZvciBhbnkgY2hhcmFjdGVycyBhZnRlciB0aGUgSVB2NiBhZGRyZXNzLCB3aGV0aGVyDQo+ID4g Pj4gcGVyY2VudC1lbmNvZGVkIG9yIG5vdC4gV2UgaGVhcmQgb2YgYnJvd3NlcnMgdGhhdCBwcmV2 aW91c2x5DQo+ID4gPj4gYWxsb3dlZCBmdWxsIFJGQyA0MDA3IHN5bnRheCAoJSAqbm90KiB0cmVh dGVkIGFzIGFuIGVzY2FwZSkgYnV0DQo+ID4gPj4gdGhpcyBpcyB0aGUgZmlyc3QgSSd2ZSBoZWFy ZCBvZiBJRSBhbGxvd2luZyBhIHpvbmUgaW5kZXggYXQgYWxsLg0KPiA+ID4+DQo+ID4gPj4gUmVn YXJkcw0KPiA+ID4+ICAgQnJpYW4NCj4gPiA+Pg0KPiA+ID4+IE9uIDIwMTItMDctMDYgMDI6Mjgs IERhdmUgVGhhbGVyIHdyb3RlOg0KPiA+ID4+PiBJIGtub3cgaXQncyBhZnRlciB0aGUgZGVzaWdu YXRlZCBlbmQgb2YgV0dMQywgYnV0IGhlcmUncyBteQ0KPiBmZWVkYmFjay4uLg0KPiA+ID4+Pg0K PiA+ID4+PiBUaGUgZG9jdW1lbnQgYXBwZWFycyB0byBjYWxsIG91dCBleGlzdGluZyBwcmFjdGlj ZSBpbiBzZXZlcmFsDQo+ID4gPj4+IHBsYWNlcywgc3VjaCBhcw0KPiA+IGluIHNlY3Rpb24gMToN Cj4gPiA+Pj4+ICBTb21lIHZlcnNpb25zIG9mIHNvbWUgYnJvd3NlcnMgYWNjZXB0IHRoZSBSRkMg NDAwNyBzeW50YXggZm9yDQo+ID4gPj4+PiBzY29wZWQNCj4gPiA+Pj4+ICBJUHY2IGFkZHJlc3Nl cyBlbWJlZGRlZCBpbiBVUklzLCBpLmUuLCB0aGV5IGhhdmUgYmVlbiBjb2RlZCB0bw0KPiA+ID4+ Pj4gaW50ZXJwcmV0IHRoZSAiJSIgc2lnbiBhY2NvcmRpbmcgdG8gUkZDIDQwMDcgaW5zdGVhZCBv ZiBSRkMgMzk4Ni4NCj4gPiA+Pj4gYW5kIGluIEFwcGVuZGl4IEEgcG9pbnQgMToNCj4gPiA+Pj4+ IEFkdmFudGFnZTogd29ya3MgdG9kYXkuDQo+ID4gPj4+IEhvd2V2ZXIsIGl0J3MgbWlzc2luZyBk aXNjdXNzaW9uIG9mIG90aGVyIGFsdGVybmF0aXZlcyBhbHJlYWR5IGluDQo+ID4gPj4+IGNvbW1v bg0KPiA+IHByYWN0aWNlLg0KPiA+ID4+PiBGb3IgZXhhbXBsZSBhbHRlcm5hdGl2ZSAzIChlc2Nh cGluZyB0aGUgZXNjYXBlIGNoYXJhY3RlciBhcw0KPiA+ID4+PiBhbGxvd2VkIGJ5IFJGQw0KPiA+ IDM5ODYpIGhhczoNCj4gPiA+Pj4+ICAgICAgQWR2YW50YWdlOiBhbGxvd3MgdXNlIG9mIGJyb3dz ZXIuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gICAgICBEaXNhZHZhbnRhZ2U6IHVnbHkgYW5kIGNvbmZ1 c2luZywgZG9lc24ndCBhbGxvdyBzaW1wbGUgY3V0IGFuZA0KPiA+ID4+Pj4gICAgICBwYXN0ZS4N Cj4gPiA+Pj4gVGhlIGRpc2FkdmFudGFnZSBpcyBjZXJ0YWlubHkgdHJ1ZS4gIEhvd2V2ZXIgdGhl IG1haW4gYWR2YW50YWdlDQo+ID4gPj4+IGFyZSBub3RhYmx5IGxhY2tpbmcsIHdoaWNoIGlzIHRo YXQgaXQncyBhbHJlYWR5IGluIGNvbW1vbiBwcmFjdGljZQ0KPiA+ID4+PiBpbiBtYW55IHBsYWNl cyAodG8gdGhlIGV4dGVudCB0aGF0IHVzaW5nIGEgem9uZSBpZCBhdCBhbGwgaXMNCj4gPiA+Pj4g Y29tbW9uIHByYWN0aWNlDQo+ID4gYW55d2F5KS4NCj4gPiA+Pj4NCj4gPiA+Pj4gWW91J2xsIHNl ZSBhdA0KPiA+ID4+PiBodHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2VuLQ0KPiB1cy9saWJyYXJ5 L3dpbmRvd3MvZGVza3RvcC9hYTM4NTMyNSh2DQo+ID4gPj4+ID12IHMuODUpLmFzcHggdGhhdCBh bHRlcm5hdGl2ZSAzIGlzIHdoYXQgaXMgc3VwcG9ydGVkIGluIElFNyBhbmQNCj4gPiA+Pj4gYWJv dmUsIGFuZCB0aGUgQVBJcyBhcmUgZ2VuZXJhbGx5IGF2YWlsYWJsZSB0byBXaW5kb3dzDQo+ID4g Pj4+IGFwcGxpY2F0aW9ucyAoaS5lLg0KPiA+ID4+PiBub3QganVzdCBJRTcpLg0KPiA+ID4+Pg0K PiA+ID4+PiBUaGUgZG9jdW1lbnQgZG9lcyBub3Qgc3RhdGUgd2hldGhlciB0aGUgZXhpc3Rpbmcg bGVnYWwgdXNlIGlzDQo+ID4gPj4+IHN1ZGRlbmx5IGRlY2xhcmVkIHRvIGJlIGlsbGVnYWwsIG9y IGp1c3QgYW5vdGhlciBsZWdhbCB3YXkgb2YNCj4gPiA+Pj4gZG9pbmcgdGhlIHNhbWUNCj4gPiB0 aGluZy4NCj4gPiA+Pj4NCj4gPiA+Pj4gSWYgeW91J3JlIHRlbGxpbmcgZXhpc3RpbmcgYXBwbGlj YXRpb25zIGFuZCBPUydzIHRoYXQgdXNlIGFsdGVybmF0aXZlIDMgdGhhdA0KPiB0aGV5DQo+ID4g Pj4+IGhhdmUgdG8gY2hhbmdlLCB0aGF0IGRvZXNuJ3Qgc291bmQgbGlrZSBhIGdvb2QgdGhpbmcu ICAgVGhhdCdzIGJlY2F1c2UNCj4gbWFueQ0KPiA+IGFwcHMNCj4gPiA+Pj4gd2FudCB0byBiZSBP Uy12ZXJzaW9uLWluZGVwZW5kZW50IGFuZCB1c2UgVVJJIHBhcnNpbmcgbGlicmFyaWVzDQo+ID4g Pj4+IHByb3ZpZGVkDQo+ID4gYnkNCj4gPiA+Pj4gdGhlIE9TLiAgIFdlIGRvbid0IHdhbnQgYXBw cyB0byBjb2RlIHRoZWlyIG93biBVUkkgcGFyc2luZyAoaXQncyB2ZXJ5DQo+IGVhc3kgdG8NCj4g PiA+Pj4gZ2V0IHdyb25nLCBlc3BlY2lhbGx5IHdoZW4geW91IGFkZCB2YXJpb3VzIGludGVybmF0 aW9uYWxpemF0aW9uDQo+IGlzc3VlcykuDQo+ID4gPj4+IEFzIGEgcmVzdWx0LCBhcHBzIHdpbGwg dGVuZCB0byBjb2RlIHRvIHRoZSBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yDQo+IG9mDQo+ID4g Pj4+IE9TJ3MgdGhleSB3YW50IHRvIHdvcmsgb24uICAgIFRoYXQgbWVhbnMgSSBleHBlY3QgdG8g c2VlIGFwcHMgY29kaW5nIHRvDQo+ID4gPj4+IGFsdGVybmF0aXZlIDMgZm9yIHRoZSBmb3Jlc2Vl YWJsZSBmdXR1cmUuICAgV2hlbiB0aGV5IGRvbid0IHVzZSB0aGVtIGluDQo+ID4gPj4+IGVkaXQg Ym94ZXMsIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygbm90IGJlaW5nIGFibGUgdG8gY3V0IGFuZCBwYXN0 ZSBpcw0KPiA+ID4+PiBub3QgYSByZWFsIGRpc2FkdmFudGFnZS4NCj4gPiA+Pj4NCj4gPiA+Pj4g UGVyc29uYWxseSBJIGRvbid0IGhhdmUgYW4gaXNzdWUgd2l0aCBhbGxvd2luZyBib3RoIGZvcm1h dHMgaWYgdGhlDQo+ID4gPj4+IFdHIGZlZWxzIHN0cm9uZ2x5IHRoYXQgYSBjdXQtYW5kLXBhc3Rl LWZyaWVuZGx5IGZvcm1hdCBpcyBuZWVkZWQNCj4gPiA+Pj4gaW4gYWRkaXRpb24gdG8gd2hhdCdz IGV4aXN0aW5nIHByYWN0aWNlLCB0aG91Z2ggaGF2aW5nIHR3byBkb2VzDQo+ID4gPj4+IGFmZmVj dCB0aGUgcnVsZXMgZm9yIGNvbXBhcmlzb24gKHNlZQ0KPiA+ID4+PiBkcmFmdC1pYWItaWRlbnRp Zmllci1jb21wYXJpc29uIHNlY3Rpb24gMy4xLjIpIGJ1dCBub3Qgbm90aWNlYWJseS4NCj4gPiA+ Pj4NCj4gPiA+Pj4gRmluYWxseSwgdGhlIHN0YXRlZCBkaXNhZHZhbnRhZ2Ugb2YgYWx0ZXJuYXRp dmUgMyBpcyBvbmx5IGEgZGlzYWR2YW50YWdlDQo+IGlmIHRoZQ0KPiA+ID4+PiBzcGVjaWZpZWQg c2NoZW1lIGluIHNlY3Rpb24gMiAqZG9lcyogYWxsb3cgY3V0LWFuZC1wYXN0ZS4gICBGb3IgdGhh dCB0bw0KPiA+ID4+PiBoYXBwZW4sIGl0IG1lYW5zIHRoZSB6b25lIGlkIHNlcGFyYXRvciBoYXMg dG8gd29yayBvdXRzaWRlIHRoZQ0KPiBjb250ZXh0IG9mDQo+ID4gPj4+IFVSSXMuICAgVGhhdCBp cywgc2VjdGlvbiAyIHNheXM6DQo+ID4gPj4+PiAgVGh1cywgdGhlIHNjb3BlZCBhZGRyZXNzIGZl ODA6OmElZW4xIHdvdWxkIGFwcGVhciBpbiBhIFVSSSBhcw0KPiA+ID4+Pj4gaHR0cDovL1tmZTgw OjphLWVuMV0uDQo+ID4gPj4+IFRvIHN1cHBvcnQgY3V0LWFuZC1wYXN0ZSwgdGhhdCBtZWFucyB0 aGF0ICJwaW5nIGZlODA6OmEtZW4xIg0KPiA+ID4+PiBuZWVkcyB0byB3b3JrLiAgIEJ1dCB0aGlz IGRvY3VtZW50IGlzIHRpdGxlZA0KPiA+ID4+PiAiIFJlcHJlc2VudGluZyBJUHY2IFpvbmUgSWRl bnRpZmllcnMgaW4gVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVycyINCj4gPiA+Pj4gYW5kIHNp bWlsYXJseSB0aGUgYWJzdHJhY3QgbGltaXRzIGl0cyBzY29wZSB0byBVUklzLg0KPiA+ID4+Pg0K PiA+ID4+PiBIZW5jZSBzZWN0aW9uIDIgaXMgaW4gY29udHJhZGljdGlvbiB3aXRoIHRoZSBhbmFs eXNpcyBvZiBhbHRlcm5hdGl2ZSAzLg0KPiA+ID4+PiBUaGUgZG9jdW1lbnQgYWxyZWFkeSBzYXlz IGl0ICJ1cGRhdGVzIDQwMDciIHNvIGl0IHNlZW1zIHRoYXQNCj4gPiA+Pj4gd2hhdCdzIGxhY2tp bmcgaXMgYSBzZWN0aW9uIHNwZWNpZmljYWxseSB1cGRhdGluZyBSRkMgNDAwNyBzZWN0aW9uDQo+ ID4gPj4+IDExIHdoaWNoIHdvdWxkIGRlY2xhcmUgdGhhdCBib3RoICclJyBhbmQgJy0nIGFyZSBh Y2NlcHRhYmxlDQo+ID4gPj4+IHNlcGFyYXRvcnMgaW4gdGhlIHRleHR1YWwgcmVwcmVzZW50YXRp b24uDQo+ID4gPj4+DQo+ID4gPj4+IC1EYXZlDQo+ID4gPj4+DQo+ID4gPj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+Pj4gRnJvbTogaXB2Ni1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+ID4+Pj4gQmVoYWxmIE9mIE9sZSBU csO4YW4NCj4gPiA+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxMywgMjAxMiA1OjE4IEFNDQo+ ID4gPj4+PiBUbzogaXB2NkBpZXRmLm9yZyBNYWlsaW5nIExpc3QNCj4gPiA+Pj4+IENjOiA2bWFu LWNoYWlyc0B0b29scy5pZXRmLm9yZyBDaGFpcnM7IGRyYWZ0LWlldGYtNm1hbi11cmktDQo+ID4g Pj4+PiB6b25laWRAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+Pj4+IFN1YmplY3Q6IDZNQU4gV0cgW3Nl Y29uZF0gTGFzdCBDYWxsOg0KPiA+ID4+Pj4gZHJhZnQtaWV0Zi02bWFuLXVyaS16b25laWQtMDEu dHh0DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gQWxsLA0KPiA+ID4+Pj4NCj4gPiA+Pj4+IFRoaXMgbWVz c2FnZSBzdGFydHMgYSBvbmUtd2VlayA2TUFOIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uDQo+ ID4gYWR2YW5jaW5nOg0KPiA+ID4+Pj4gICAgIFRpdGxlICAgICA6IFJlcHJlc2VudGluZyBJUHY2 IFpvbmUgSWRlbnRpZmllcnMgaW4gVW5pZm9ybQ0KPiA+ID4+Pj4gICAgICAgICAgICAgICAgIFJl c291cmNlIElkZW50aWZpZXJzDQo+ID4gPj4+PiAgICAgQXV0aG9yKHMpIDogQnJpYW4gQ2FycGVu dGVyDQo+ID4gPj4+PiAgICAgICAgICAgICAgICAgUm9iZXJ0IE0uIEhpbmRlbg0KPiA+ID4+Pj4g ICAgIEZpbGVuYW1lICA6IGRyYWZ0LWlldGYtNm1hbi11cmktem9uZWlkLTAxLnR4dA0KPiA+ID4+ Pj4gICAgIFBhZ2VzICAgICA6IDkNCj4gPiA+Pj4+ICAgICBEYXRlICAgICAgOiAyMDEyLTA1LTI5 DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQuIFN1 YnN0YW50aXZlIGNvbW1lbnRzIHNob3VsZCBiZSBkaXJlY3RlZA0KPiA+ID4+Pj4gdG8gdGhlIG1h aWxpbmcgbGlzdCBvciB0aGUgY28tY2hhaXJzLiBFZGl0b3JpYWwgc3VnZ2VzdGlvbnMgY2FuDQo+ ID4gPj4+PiBiZSBzZW50IHRvIHRoZQ0KPiA+IGF1dGhvcnMuDQo+ID4gPj4+PiBUaGlzIGxhc3Qg Y2FsbCB3aWxsIGVuZCBvbiBKdW5lIDIwLCAyMDEyLg0KPiA+ID4+Pj4gUmVnYXJkcywNCj4gPiA+ Pj4+IEJvYiwgJiBPbGUNCj4gPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPj4+PiAtLQ0KPiA+ID4+Pj4g LSBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZw0KPiA+ ID4+Pj4gQWRtaW5pc3RyYXRpdmUNCj4gPiA+Pj4+IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPj4+PiAt LQ0KPiA+ID4+Pj4gLQ0KPiA+ID4+Pg0KPiA+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+Pj4gLS0gSUVU RiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5vcmcNCj4gPiA+Pj4g QWRtaW5pc3RyYXRpdmUNCj4gPiA+Pj4gUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+Pj4gLS0NCj4gPiA+ Pj4NCj4gPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPj4gLSBJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZyBBZG1pbmlzdHJhdGl2ZQ0KPiA+ID4+IFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiA+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gPj4gLQ0KPiA+ID4NCj4gPiA+DQo+ID4NCj4gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+ IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From sarikaya2012@gmail.com Mon Jul 9 12:47:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868DA11E8215 for ; Mon, 9 Jul 2012 12:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1VnKAZy9ucc for ; Mon, 9 Jul 2012 12:47:52 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08A1811E8214 for ; Mon, 9 Jul 2012 12:47:51 -0700 (PDT) Received: by yhq56 with SMTP id 56so13084925yhq.31 for ; Mon, 09 Jul 2012 12:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=64DmnrJZaBZyU4HucuHyIaJB/1ZSd2x39XidrDX+HnE=; b=KoKJgt8UF5daHRdKQ10nHzcM6N75uV33KwEL/ctzYPlrM5oa9NSU+zFSXdq53ahrwr 16f5JxFfkf0820Op0XuzXDVnArby6Q2qbaStJsSrYYss58vowykLSmvDN3VN8FfrOasN x0r/7XINS48+S6GIswPfnQgqnh9UtBd/jkBxTLzqcoDaZjxM54ulRlve/xJaoWXXlwP5 ns6GLlauFcGPEpvg/qjtVGpNTPuehW9uZQrwlaj5qyfCthYjZY57Ep1d+ZetzdecAi6u CaTKZtwgDkdJNkd9sZ1aOeq5yJUfvN5CJUM1KZ+grqeRBV6hZ8L76IhmbLF6TZ77KZQW OgxQ== MIME-Version: 1.0 Received: by 10.50.160.198 with SMTP id xm6mr9597700igb.0.1341863297081; Mon, 09 Jul 2012 12:48:17 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Mon, 9 Jul 2012 12:48:17 -0700 (PDT) In-Reply-To: <4FFB27CA.5070002@viagenie.ca> References: <4FF696AA.3050508@tut.fi> <23986.1341586765@marajade.sandelman.ca> <4FFB27CA.5070002@viagenie.ca> Date: Mon, 9 Jul 2012 14:48:17 -0500 Message-ID: Subject: Re: draft-chen-v6ops-nat64-experience-02 From: Behcet Sarikaya To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:47:52 -0000 On Mon, Jul 9, 2012 at 1:49 PM, Simon Perreault wrote: > On 2012-07-09 14:41, Behcet Sarikaya wrote: >> >> On Mon, Jul 9, 2012 at 12:38 PM, Cameron Byrne wrote: >>> >>> On Mon, Jul 9, 2012 at 10:18 AM, Behcet Sarikaya >>> wrote: >>>> >>>> It seems like this is what is called stateless NAT64. >>>> >>>> I am not sure if there is any document specifying stateless NAT64? >>> >>> >>> Stateless = http://tools.ietf.org/html/rfc6145 >> >> >> Are you sure? >> >> Here is a quote from 6146: >> Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 >> packets and vice versa. The translation is done by translating the >> packet headers according to the IP/ICMP Translation Algorithm defined >> in [RFC6145]. > > > Cameron is right. RFC6145 is often referred to as "stateless NAT64". > That means stateless NAT64 is not defined maybe it is a myth. Regards, Behcet From brian@innovationslab.net Mon Jul 9 17:35:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B7B11E8161 for ; Mon, 9 Jul 2012 17:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnod5PfDeYtw for ; Mon, 9 Jul 2012 17:35:56 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1BF11E8135 for ; Mon, 9 Jul 2012 17:35:56 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 23F6488097; Mon, 9 Jul 2012 17:36:20 -0700 (PDT) Received: from clemson.local (h147.118.178.64.static.ip.windstream.net [64.178.118.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6A869130017; Mon, 9 Jul 2012 17:36:19 -0700 (PDT) Message-ID: <4FFB7918.9080806@innovationslab.net> Date: Mon, 09 Jul 2012 20:36:40 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: 6man WG , 6man Chairs <6man-chairs@tools.ietf.org>, Barry Leiba , Pete Resnick , Ralph Droms Subject: Status of draft-ietf-6man-lineid Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 00:35:56 -0000 All, During the IESG discussion of draft-ietf-6man-lineid, the question was raised as to its appropriate status. The WG decided to advance the draft as Experimental since it had documented limitations and was targeted to a limited deployment scenario. Several ADs raised the issue that the above reasons do not necessarily make the draft inappropriate for Proposed Standard, To quote feedback from one of the ADs (Barry Leiba): "If the limitations are clearly documented and if that document can be used to target implementations correctly, then I think PS is completely appropriate. If experimentation is needed to *determine* the limitations, or to determine how to implement the specification to as not to interfere with inapplicable situations, then Experimental is best." In my view, there is a clear understanding of what the limitations of this approach are and they can be clearly defined in an applicability statement within the draft. Additionally, we know the deployment scenario (N:1 VLAN usage in broadband networks) where this approach will be used. My question is whether there is opposition or support within the community to move the document to Proposed Standard as long as there is a sufficient applicability statement included in the draft. Please provide feedback to the mailing list (and the cc:'ed ADs) on this proposed change. Regards, Brian From jiangsheng@huawei.com Mon Jul 9 20:31:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C5D11E8137 for ; Mon, 9 Jul 2012 20:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbb5zGgolFXl for ; Mon, 9 Jul 2012 20:31:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2292C11E8125 for ; Mon, 9 Jul 2012 20:31:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHP68305; Mon, 09 Jul 2012 23:31:29 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 20:28:27 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 20:28:27 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 11:28:22 +0800 From: Sheng Jiang To: "ipv6@ietf.org" Subject: FW: New Version Notification for draft-jiang-semantic-prefix-00.txt Thread-Topic: New Version Notification for draft-jiang-semantic-prefix-00.txt Thread-Index: AQHNXaP3eifIRoHPo02wGSDOlR2P6pch3Hmg Date: Tue, 10 Jul 2012 03:28:21 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF716C@szxeml545-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 03:31:04 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgZHJhZnQtamlhbmctc2Vt YW50aWMtcHJlZml4LCAiU2VtYW50aWMgSVB2NiBQcmVmaXgiLiBJdCBwcm9wb3NlcyBhIGZyYW1l d29yayB0byBhbGxvdyBzZW1hbnRpY3MgdG8gYmUgZW1iZWRkZWQgaW50byBwcmVmaXggc28gdGhh dCBJU1BzIGNhbiBlYXNpbHkgYXBwbHkgcmVsZXZhbnQgb3BlcmF0aW9ucyBhY2NvcmRpbmdseS4N Cg0KQWxsIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBNb25kYXks IEp1bHkgMDksIDIwMTIgMzoyNSBQTQ0KPiBUbzogU2hlbmcgSmlhbmcNCj4gU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qaWFuZy1zZW1hbnRpYy1wcmVmaXgtMDAu dHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWppYW5nLXNlbWFudGlj LXByZWZpeC0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTaGVu ZyBKaWFuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxl bmFtZToJIGRyYWZ0LWppYW5nLXNlbWFudGljLXByZWZpeA0KPiBSZXZpc2lvbjoJIDAwDQo+IFRp dGxlOgkJIFNlbWFudGljIElQdjYgUHJlZml4DQo+IENyZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTA5 DQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDkN Cj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qaWFu Zy1zZW1hbnRpYy1wcmVmaXgtMDAudHh0DQo+IFN0YXR1czoNCj4gaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1qaWFuZy1zZW1hbnRpYy1wcmVmaXgNCj4gSHRtbGl6ZWQ6ICAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaWFuZy1zZW1hbnRpYy1wcmVm aXgtMDANCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgU29tZSBJbnRlcm5ldCBTZXJ2aWNlIFBy b3ZpZGVycyBkZXNpcmUgdG8gYmUgYXdhcmUgb2YgbW9yZQ0KPiAgICBpbmZvcm1hdGlvbiBhYm91 dCBlYWNoIHBhY2tldCwgc28gdGhhdCBwYWNrZXRzIGNhbiBiZSB0cmVhdGVkDQo+ICAgIGRpZmZl cmVudGx5IGFuZCBlZmZpY2llbnRseS4gSVB2Niwgd2l0aCBhIGxhcmdlIGFkZHJlc3Mgc3BhY2Us IGFsbG93cw0KPiAgICBzZW1hbnRpY3MgdG8gYmUgZW1iZWRkZWQgaW50byBhZGRyZXNzZXMuIFJv dXRlcnMgY2FuIGVhc2lseSBhcHBseQ0KPiAgICByZWxldmFudCBvcGVyYXRpb25zIGFjY29yZGlu Z2x5LiBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuYWx5c2lzIG9uDQo+ICAgIGhvdyB0byBmb3Jt IHNlbWFudGljIHByZWZpeCBhbmQgY29ycmVzcG9uZGluZyB1c2UgY2FzZXMsIGFuZA0KPiAgICBp ZGVudGlmaWVzIHRoZSB0ZWNobmljYWwgcmVxdWlyZW1lbnRzIHRvIG1heGltaXplIHRoZSBiZW5l Zml0cyBvZiB0aGUNCj4gICAgc2VtYW50aWMgcHJlZml4IGFwcHJvYWNoLiBJdCBpcyByZWNvbW1l bmRlZCB0byB1c2UgNH4xMiBiaXRzIGluDQo+ICAgIHByZWZpeCBmb3IgZW1iZWRkZWQgc2VtYW50 aWNzLg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From brian.e.carpenter@gmail.com Tue Jul 10 00:13:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2C21F843F for ; Tue, 10 Jul 2012 00:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.132 X-Spam-Level: X-Spam-Status: No, score=-101.132 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HKTncF9rMi3 for ; Tue, 10 Jul 2012 00:13:03 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9232011E8122 for ; Tue, 10 Jul 2012 00:12:58 -0700 (PDT) Received: by eekd4 with SMTP id d4so4766689eek.31 for ; Tue, 10 Jul 2012 00:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HWqZsXfN/+g+vnWiLtvP4fNFhCzf8tcPpnUzxOZxEn8=; b=TwVdtXwp2nAV3iuDfB+I4lerOJY0LCAh4BfaO198j43ULvJC6FIpv8r5BkfVlmbv5S iSZDh4PQl3NsS4YhMuxOE5CBPBF4UR3hXqdNrWQoKre+sWC648kjVbS3pcszEYjU4Qmi OOk/OL/1fY9If0PoNPNXyi4iGOhfHfqw1Ra+tnJG8pUsrT63Z9if777XGxKd0N+E5bhE jN+IBDbK+fWrBDhodeV9CnbplBohGAjGe5tj6TW7LL64DDLmHl4GcO+cEWTS/GqRkbL4 eTIBm4CC8JhYs1YTOlTGKnfkoozb7ooghR1QtGcXDfBSXQc1/ZFH1xsLW+G9LSE2wnfQ bmrw== Received: by 10.14.22.2 with SMTP id s2mr10579835ees.55.1341904405081; Tue, 10 Jul 2012 00:13:25 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-176.as13285.net. [2.102.218.176]) by mx.google.com with ESMTPS id a4sm92647346een.14.2012.07.10.00.13.22 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 00:13:23 -0700 (PDT) Message-ID: <4FFBD616.4050208@gmail.com> Date: Tue, 10 Jul 2012 08:13:26 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> <4FF718C7.5060206@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B690A00@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B6A4C51@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B6A4C51@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-uri-zoneid@tools.ietf.org" , Bob Hinden , "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 07:13:04 -0000 Dave, we do of course make the point that it's only locally significant, = but a reference to that paragraph of 3986 would complete the story. Regards Brian On 09/07/2012 19:54, Dave Thaler wrote: > One additional gap that I think SHOULD be addressed. RFC 3986 says: >=20 > URIs have a global scope and are interpreted consistently regardless= > of context, though the result of that interpretation may be in > relation to the end-user's context. For example, "http://localhost/= " > has the same interpretation for every user of that reference, even > though the network interface corresponding to "localhost" may be > different for each end-user: interpretation is independent of access= =2E > However, an action made on the basis of that reference will take > place in relation to the end-user's context, which implies that an > action intended to refer to a globally unique thing must use a URI > that distinguishes that resource from all other things. URIs that > identify in relation to the end-user's local context should only be > used when the context itself is a defining aspect of the resource, > such as when an on-line help manual refers to a file on the end- > user's file system (e.g., "file:///etc/hosts"). >=20 > It should be pointed out in the zoneid document that adding a zone id > changes the scope to be localhost rather than the scope of the address.= >=20 > So "http://[fe80::1]/blah" is valid anywhere on the same link. > But "http://[fe80::1-id]/blah" is valid only within the same host. >=20 > -Dave >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf O= f >> Dave Thaler >> Sent: Friday, July 6, 2012 10:33 AM >> To: Brian E Carpenter; Bob Hinden >> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >> zoneid@tools.ietf.org; ipv6@ietf.org Mailing List >> Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01= =2Etxt >> >> It's documented on the page in my original email. >> >> However it's not sufficient. Remember my second piece of feedback was= >> that the document contradicts itself, implying the specified syntax su= pports >> cut and paste, but then doesn't provide a section updating RFC 4007 se= ction >> 11. >> >> If the document both mentions that alternative 3 is used by many thing= s >> today (IE, Windows, applications) within APIs that take URI-like strin= gs, and >> also adds a section updating RFC 4007 section 11, then I'd be happy wi= th it. >> >> -Dave >> >>> -----Original Message----- >>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>> Sent: Friday, July 06, 2012 9:57 AM >>> To: Bob Hinden >>> Cc: Dave Thaler; 6man-chairs@tools.ietf.org Chairs; >>> draft-ietf-6man-uri- zoneid@tools.ietf.org; ipv6@ietf.org Mailing Lis= t >>> Subject: Re: 6MAN WG [second] Last Call: >>> draft-ietf-6man-uri-zoneid-01.txt >>> >>> I'd be happy with that, or a small appendix. Dave, is it documented >> anywhere? >>> Regards >>> Brian >>> >>> On 2012-07-06 15:00, Bob Hinden wrote: >>>> With my co-author hat on, would it help to include a description of >>>> what IE >>> supports in Section 3. Web Browsers? >>>> Bob >>>> >>>> >>>> On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: >>>> >>>>> Dave, >>>>> >>>>> 1) FYI, the deadline we gave the URI list to comment on this has >>>>> just passed, with only one (positive) reply. >>>>> >>>>> 2) It's for the WG Chairs to say if they want another version in >>>>> view of your comments. >>>>> >>>>> 3) I don't see how the % format is currently legal. There's no >>>>> provision for any characters after the IPv6 address, whether >>>>> percent-encoded or not. We heard of browsers that previously >>>>> allowed full RFC 4007 syntax (% *not* treated as an escape) but >>>>> this is the first I've heard of IE allowing a zone index at all. >>>>> >>>>> Regards >>>>> Brian >>>>> >>>>> On 2012-07-06 02:28, Dave Thaler wrote: >>>>>> I know it's after the designated end of WGLC, but here's my >> feedback... >>>>>> The document appears to call out existing practice in several >>>>>> places, such as >>> in section 1: >>>>>>> Some versions of some browsers accept the RFC 4007 syntax for >>>>>>> scoped >>>>>>> IPv6 addresses embedded in URIs, i.e., they have been coded to >>>>>>> interpret the "%" sign according to RFC 4007 instead of RFC 3986.= >>>>>> and in Appendix A point 1: >>>>>>> Advantage: works today. >>>>>> However, it's missing discussion of other alternatives already in >>>>>> common >>> practice. >>>>>> For example alternative 3 (escaping the escape character as >>>>>> allowed by RFC >>> 3986) has: >>>>>>> Advantage: allows use of browser. >>>>>>> >>>>>>> Disadvantage: ugly and confusing, doesn't allow simple cut a= nd >>>>>>> paste. >>>>>> The disadvantage is certainly true. However the main advantage >>>>>> are notably lacking, which is that it's already in common practice= >>>>>> in many places (to the extent that using a zone id at all is >>>>>> common practice >>> anyway). >>>>>> You'll see at >>>>>> http://msdn.microsoft.com/en- >> us/library/windows/desktop/aa385325(v >>>>>> =3Dv s.85).aspx that alternative 3 is what is supported in IE7 and= >>>>>> above, and the APIs are generally available to Windows >>>>>> applications (i.e. >>>>>> not just IE7). >>>>>> >>>>>> The document does not state whether the existing legal use is >>>>>> suddenly declared to be illegal, or just another legal way of >>>>>> doing the same >>> thing. >>>>>> If you're telling existing applications and OS's that use alternat= ive 3 that >> they >>>>>> have to change, that doesn't sound like a good thing. That's bec= ause >> many >>> apps >>>>>> want to be OS-version-independent and use URI parsing libraries >>>>>> provided >>> by >>>>>> the OS. We don't want apps to code their own URI parsing (it's v= ery >> easy to >>>>>> get wrong, especially when you add various internationalization >> issues). >>>>>> As a result, apps will tend to code to the lowest common denominat= or >> of >>>>>> OS's they want to work on. That means I expect to see apps codi= ng to >>>>>> alternative 3 for the foreseeable future. When they don't use th= em in >>>>>> edit boxes, the disadvantage of not being able to cut and paste is= >>>>>> not a real disadvantage. >>>>>> >>>>>> Personally I don't have an issue with allowing both formats if the= >>>>>> WG feels strongly that a cut-and-paste-friendly format is needed >>>>>> in addition to what's existing practice, though having two does >>>>>> affect the rules for comparison (see >>>>>> draft-iab-identifier-comparison section 3.1.2) but not noticeably.= >>>>>> >>>>>> Finally, the stated disadvantage of alternative 3 is only a disadv= antage >> if the >>>>>> specified scheme in section 2 *does* allow cut-and-paste. For th= at to >>>>>> happen, it means the zone id separator has to work outside the >> context of >>>>>> URIs. That is, section 2 says: >>>>>>> Thus, the scoped address fe80::a%en1 would appear in a URI as >>>>>>> http://[fe80::a-en1]. >>>>>> To support cut-and-paste, that means that "ping fe80::a-en1" >>>>>> needs to work. But this document is titled >>>>>> " Representing IPv6 Zone Identifiers in Uniform Resource Identifie= rs" >>>>>> and similarly the abstract limits its scope to URIs. >>>>>> >>>>>> Hence section 2 is in contradiction with the analysis of alternati= ve 3. >>>>>> The document already says it "updates 4007" so it seems that >>>>>> what's lacking is a section specifically updating RFC 4007 section= >>>>>> 11 which would declare that both '%' and '-' are acceptable >>>>>> separators in the textual representation. >>>>>> >>>>>> -Dave >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >>>>>>> Behalf Of Ole Tr=C3=B8an >>>>>>> Sent: Wednesday, June 13, 2012 5:18 AM >>>>>>> To: ipv6@ietf.org Mailing List >>>>>>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >>>>>>> zoneid@tools.ietf.org >>>>>>> Subject: 6MAN WG [second] Last Call: >>>>>>> draft-ietf-6man-uri-zoneid-01.txt >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> This message starts a one-week 6MAN Working Group Last Call on >>> advancing: >>>>>>> Title : Representing IPv6 Zone Identifiers in Uniform >>>>>>> Resource Identifiers >>>>>>> Author(s) : Brian Carpenter >>>>>>> Robert M. Hinden >>>>>>> Filename : draft-ietf-6man-uri-zoneid-01.txt >>>>>>> Pages : 9 >>>>>>> Date : 2012-05-29 >>>>>>> >>>>>>> >>>>>>> as a Proposed Standard. Substantive comments should be directed >>>>>>> to the mailing list or the co-chairs. Editorial suggestions can >>>>>>> be sent to the >>> authors. >>>>>>> This last call will end on June 20, 2012. >>>>>>> Regards, >>>>>>> Bob, & Ole >>>>>>> -----------------------------------------------------------------= >>>>>>> -- >>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>> Administrative >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -----------------------------------------------------------------= >>>>>>> -- >>>>>>> - >>>>>> ------------------------------------------------------------------= >>>>>> -- IETF IPv6 working group mailing list ipv6@ietf.org >>>>>> Administrative >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> ------------------------------------------------------------------= >>>>>> -- >>>>>> >>>>> -------------------------------------------------------------------= >>>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative= >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------= >>>>> - >>>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Tue Jul 10 07:21:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323F521F8766 for ; Tue, 10 Jul 2012 07:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.736 X-Spam-Level: X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef4mjaYrTxxZ for ; Tue, 10 Jul 2012 07:21:43 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A254C21F8777 for ; Tue, 10 Jul 2012 07:21:42 -0700 (PDT) Received: by eekd4 with SMTP id d4so10715eek.31 for ; Tue, 10 Jul 2012 07:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2afyPwt6HfIKZrBwNMBgt6V020+nl5cbVV0ifGaVtBA=; b=A9adGttOpUESdW9yZpuOQg+TMBWpeDKDD4mMRMDdsu8rBgt7RJZIBcMblWdYgzrjOm mlsqVZb7ENX/vSrgeABwbBZsGavEWnRDDLzUHUvKt3+2DPwWwQVLc/8Ck+cd+bczhHe9 fD0bM1ESmdVbiWkXZLV5SKyukIcpILTLBOWFQJ3iSteXGPYbWFfzwvC86uzOAfQQ4XMD nNhY4o3AX/z36TFpsPUKQQMxpkfJn7lCsevYPXcFSvGvP12UPBT67CqmI+zVFzWuxSgx OVoThDmc/R/PwpeDTWBX0HrzZUJmJLQUVNJaJPEjT6HoBVP3vfKdrFDp1aOWc9pOfudj SRPQ== Received: by 10.14.96.10 with SMTP id q10mr10390829eef.14.1341930129578; Tue, 10 Jul 2012 07:22:09 -0700 (PDT) Received: from [128.232.100.215] (c0215.aw.cl.cam.ac.uk. [128.232.100.215]) by mx.google.com with ESMTPS id h53sm103030747eea.1.2012.07.10.07.22.07 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 07:22:08 -0700 (PDT) Message-ID: <4FFC3A94.4070501@gmail.com> Date: Tue, 10 Jul 2012 15:22:12 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 CC: "ipv6@ietf.org Mailing List" Subject: Re: Candidate draft-ietf-6man-uri-zoneid-02 References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> <4FF718C7.5060206@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B690A00@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B6A4C51@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4FFBD616.4050208@gmail.com> <4FFC3406.30604@gmail.com> In-Reply-To: <4FFC3406.30604@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:21:44 -0000 Sorry - thought I'd deleted the cc to the list. Regards Brian Carpenter On 10/07/2012 14:54, Brian E Carpenter wrote: > Bob (as co-author) and Dave (as reviewer), >=20 > Here's a proposed update and a diff file. >=20 > Please let me know ASAP if this is OK for you, as the cutoff is approac= hing. >=20 > Regards > Brian >=20 > On 10/07/2012 08:13, Brian E Carpenter wrote: >> Dave, we do of course make the point that it's only locally significan= t, but >> a reference to that paragraph of 3986 would complete the story. >> >> Regards >> Brian >> >> >> On 09/07/2012 19:54, Dave Thaler wrote: >>> One additional gap that I think SHOULD be addressed. RFC 3986 says: >>> >>> URIs have a global scope and are interpreted consistently regardle= ss >>> of context, though the result of that interpretation may be in >>> relation to the end-user's context. For example, "http://localhos= t/" >>> has the same interpretation for every user of that reference, even= >>> though the network interface corresponding to "localhost" may be >>> different for each end-user: interpretation is independent of acce= ss. >>> However, an action made on the basis of that reference will take >>> place in relation to the end-user's context, which implies that an= >>> action intended to refer to a globally unique thing must use a URI= >>> that distinguishes that resource from all other things. URIs that= >>> identify in relation to the end-user's local context should only b= e >>> used when the context itself is a defining aspect of the resource,= >>> such as when an on-line help manual refers to a file on the end- >>> user's file system (e.g., "file:///etc/hosts"). >>> >>> It should be pointed out in the zoneid document that adding a zone id= >>> changes the scope to be localhost rather than the scope of the addres= s. >>> >>> So "http://[fe80::1]/blah" is valid anywhere on the same link. >>> But "http://[fe80::1-id]/blah" is valid only within the same host. >>> >>> -Dave >>> >>>> -----Original Message----- >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf= Of >>>> Dave Thaler >>>> Sent: Friday, July 6, 2012 10:33 AM >>>> To: Brian E Carpenter; Bob Hinden >>>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >>>> zoneid@tools.ietf.org; ipv6@ietf.org Mailing List >>>> Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-= 01.txt >>>> >>>> It's documented on the page in my original email. >>>> >>>> However it's not sufficient. Remember my second piece of feedback w= as >>>> that the document contradicts itself, implying the specified syntax = supports >>>> cut and paste, but then doesn't provide a section updating RFC 4007 = section >>>> 11. >>>> >>>> If the document both mentions that alternative 3 is used by many thi= ngs >>>> today (IE, Windows, applications) within APIs that take URI-like str= ings, and >>>> also adds a section updating RFC 4007 section 11, then I'd be happy = with it. >>>> >>>> -Dave >>>> >>>>> -----Original Message----- >>>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>>> Sent: Friday, July 06, 2012 9:57 AM >>>>> To: Bob Hinden >>>>> Cc: Dave Thaler; 6man-chairs@tools.ietf.org Chairs; >>>>> draft-ietf-6man-uri- zoneid@tools.ietf.org; ipv6@ietf.org Mailing L= ist >>>>> Subject: Re: 6MAN WG [second] Last Call: >>>>> draft-ietf-6man-uri-zoneid-01.txt >>>>> >>>>> I'd be happy with that, or a small appendix. Dave, is it documented= >>>> anywhere? >>>>> Regards >>>>> Brian >>>>> >>>>> On 2012-07-06 15:00, Bob Hinden wrote: >>>>>> With my co-author hat on, would it help to include a description o= f >>>>>> what IE >>>>> supports in Section 3. Web Browsers? >>>>>> Bob >>>>>> >>>>>> >>>>>> On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: >>>>>> >>>>>>> Dave, >>>>>>> >>>>>>> 1) FYI, the deadline we gave the URI list to comment on this has >>>>>>> just passed, with only one (positive) reply. >>>>>>> >>>>>>> 2) It's for the WG Chairs to say if they want another version in >>>>>>> view of your comments. >>>>>>> >>>>>>> 3) I don't see how the % format is currently legal. There's no >>>>>>> provision for any characters after the IPv6 address, whether >>>>>>> percent-encoded or not. We heard of browsers that previously >>>>>>> allowed full RFC 4007 syntax (% *not* treated as an escape) but >>>>>>> this is the first I've heard of IE allowing a zone index at all. >>>>>>> >>>>>>> Regards >>>>>>> Brian >>>>>>> >>>>>>> On 2012-07-06 02:28, Dave Thaler wrote: >>>>>>>> I know it's after the designated end of WGLC, but here's my >>>> feedback... >>>>>>>> The document appears to call out existing practice in several >>>>>>>> places, such as >>>>> in section 1: >>>>>>>>> Some versions of some browsers accept the RFC 4007 syntax for >>>>>>>>> scoped >>>>>>>>> IPv6 addresses embedded in URIs, i.e., they have been coded to= >>>>>>>>> interpret the "%" sign according to RFC 4007 instead of RFC 398= 6. >>>>>>>> and in Appendix A point 1: >>>>>>>>> Advantage: works today. >>>>>>>> However, it's missing discussion of other alternatives already i= n >>>>>>>> common >>>>> practice. >>>>>>>> For example alternative 3 (escaping the escape character as >>>>>>>> allowed by RFC >>>>> 3986) has: >>>>>>>>> Advantage: allows use of browser. >>>>>>>>> >>>>>>>>> Disadvantage: ugly and confusing, doesn't allow simple cut= and >>>>>>>>> paste. >>>>>>>> The disadvantage is certainly true. However the main advantage >>>>>>>> are notably lacking, which is that it's already in common practi= ce >>>>>>>> in many places (to the extent that using a zone id at all is >>>>>>>> common practice >>>>> anyway). >>>>>>>> You'll see at >>>>>>>> http://msdn.microsoft.com/en- >>>> us/library/windows/desktop/aa385325(v >>>>>>>> =3Dv s.85).aspx that alternative 3 is what is supported in IE7 a= nd >>>>>>>> above, and the APIs are generally available to Windows >>>>>>>> applications (i.e. >>>>>>>> not just IE7). >>>>>>>> >>>>>>>> The document does not state whether the existing legal use is >>>>>>>> suddenly declared to be illegal, or just another legal way of >>>>>>>> doing the same >>>>> thing. >>>>>>>> If you're telling existing applications and OS's that use altern= ative 3 that >>>> they >>>>>>>> have to change, that doesn't sound like a good thing. That's b= ecause >>>> many >>>>> apps >>>>>>>> want to be OS-version-independent and use URI parsing libraries >>>>>>>> provided >>>>> by >>>>>>>> the OS. We don't want apps to code their own URI parsing (it's= very >>>> easy to >>>>>>>> get wrong, especially when you add various internationalization >>>> issues). >>>>>>>> As a result, apps will tend to code to the lowest common denomin= ator >>>> of >>>>>>>> OS's they want to work on. That means I expect to see apps co= ding to >>>>>>>> alternative 3 for the foreseeable future. When they don't use = them in >>>>>>>> edit boxes, the disadvantage of not being able to cut and paste = is >>>>>>>> not a real disadvantage. >>>>>>>> >>>>>>>> Personally I don't have an issue with allowing both formats if t= he >>>>>>>> WG feels strongly that a cut-and-paste-friendly format is needed= >>>>>>>> in addition to what's existing practice, though having two does >>>>>>>> affect the rules for comparison (see >>>>>>>> draft-iab-identifier-comparison section 3.1.2) but not noticeabl= y. >>>>>>>> >>>>>>>> Finally, the stated disadvantage of alternative 3 is only a disa= dvantage >>>> if the >>>>>>>> specified scheme in section 2 *does* allow cut-and-paste. For = that to >>>>>>>> happen, it means the zone id separator has to work outside the >>>> context of >>>>>>>> URIs. That is, section 2 says: >>>>>>>>> Thus, the scoped address fe80::a%en1 would appear in a URI as >>>>>>>>> http://[fe80::a-en1]. >>>>>>>> To support cut-and-paste, that means that "ping fe80::a-en1" >>>>>>>> needs to work. But this document is titled >>>>>>>> " Representing IPv6 Zone Identifiers in Uniform Resource Identif= iers" >>>>>>>> and similarly the abstract limits its scope to URIs. >>>>>>>> >>>>>>>> Hence section 2 is in contradiction with the analysis of alterna= tive 3. >>>>>>>> The document already says it "updates 4007" so it seems that >>>>>>>> what's lacking is a section specifically updating RFC 4007 secti= on >>>>>>>> 11 which would declare that both '%' and '-' are acceptable >>>>>>>> separators in the textual representation. >>>>>>>> >>>>>>>> -Dave >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >>>>>>>>> Behalf Of Ole Tr=C3=B8an >>>>>>>>> Sent: Wednesday, June 13, 2012 5:18 AM >>>>>>>>> To: ipv6@ietf.org Mailing List >>>>>>>>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >>>>>>>>> zoneid@tools.ietf.org >>>>>>>>> Subject: 6MAN WG [second] Last Call: >>>>>>>>> draft-ietf-6man-uri-zoneid-01.txt >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> This message starts a one-week 6MAN Working Group Last Call on >>>>> advancing: >>>>>>>>> Title : Representing IPv6 Zone Identifiers in Uniform >>>>>>>>> Resource Identifiers >>>>>>>>> Author(s) : Brian Carpenter >>>>>>>>> Robert M. Hinden >>>>>>>>> Filename : draft-ietf-6man-uri-zoneid-01.txt >>>>>>>>> Pages : 9 >>>>>>>>> Date : 2012-05-29 >>>>>>>>> >>>>>>>>> >>>>>>>>> as a Proposed Standard. Substantive comments should be directed= >>>>>>>>> to the mailing list or the co-chairs. Editorial suggestions can= >>>>>>>>> be sent to the >>>>> authors. >>>>>>>>> This last call will end on June 20, 2012. >>>>>>>>> Regards, >>>>>>>>> Bob, & Ole >>>>>>>>> ---------------------------------------------------------------= -- >>>>>>>>> -- >>>>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>>> Administrative >>>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>> ---------------------------------------------------------------= -- >>>>>>>>> -- >>>>>>>>> - >>>>>>>> ----------------------------------------------------------------= -- >>>>>>>> -- IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>> Administrative >>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> ----------------------------------------------------------------= -- >>>>>>>> -- >>>>>>>> >>>>>>> -----------------------------------------------------------------= -- >>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrati= ve >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -----------------------------------------------------------------= -- >>>>>>> - >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> --------------------------------------------------------------------= >> From brian.e.carpenter@gmail.com Tue Jul 10 06:53:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECD421F85D3 for ; Tue, 10 Jul 2012 06:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTvFuVpRBQ6V for ; Tue, 10 Jul 2012 06:53:46 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC1121F85D5 for ; Tue, 10 Jul 2012 06:53:45 -0700 (PDT) Received: by eekd4 with SMTP id d4so4936289eek.31 for ; Tue, 10 Jul 2012 06:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=ovCzscIerIVLnVqXFJUZHek7XsY3nMIMyN7SmVWqhsk=; b=Oy0TVbZfsktTcC4Q+J7kLYokWv/V0sooQRj6g/mivVbksaYlX3DxonO794vPUdgRRZ 1WN9x2ylNhRPgYv4FG+k65qBD7xea4mywtUxhOrRp0Ilc91Xi+r9CxepAsmchyewFmUM axEJLy+qtpfApqey/PGC+dPKUyLFCnEwqd7aE0cYFKRI+Ftj9g1AcZxbXIzt92w0o3iD YkZOhgEnBihcbMzEdCQ1MFgHu9KWtq8UYaJLTnmG8Kuod3yrAVZT7cnPnJhkitCMOa+u snik2ZwREjpIeGFVYj+Tc82Tv3UTEQ8zU498lFjotXm9CvRy1AEmjRygjA0q6STK2k7J JdKA== Received: by 10.14.27.202 with SMTP id e50mr10551623eea.186.1341928452129; Tue, 10 Jul 2012 06:54:12 -0700 (PDT) Received: from [128.232.100.215] (c0215.aw.cl.cam.ac.uk. [128.232.100.215]) by mx.google.com with ESMTPS id o16sm102772774eeb.13.2012.07.10.06.54.09 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 06:54:10 -0700 (PDT) Message-ID: <4FFC3406.30604@gmail.com> Date: Tue, 10 Jul 2012 14:54:14 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter , Dave Thaler , Bob Hinden Subject: Candidate draft-ietf-6man-uri-zoneid-02 References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> <4FF718C7.5060206@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B690A00@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B6A4C51@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4FFBD616.4050208@gmail.com> In-Reply-To: <4FFBD616.4050208@gmail.com> Content-Type: multipart/mixed; boundary="------------040705010003080007000700" X-Mailman-Approved-At: Tue, 10 Jul 2012 07:59:02 -0700 Cc: "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 13:53:49 -0000 This is a multi-part message in MIME format. --------------040705010003080007000700 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bob (as co-author) and Dave (as reviewer), Here's a proposed update and a diff file. Please let me know ASAP if this is OK for you, as the cutoff is approachi= ng. Regards Brian On 10/07/2012 08:13, Brian E Carpenter wrote: > Dave, we do of course make the point that it's only locally significant= , but > a reference to that paragraph of 3986 would complete the story. >=20 > Regards > Brian >=20 >=20 > On 09/07/2012 19:54, Dave Thaler wrote: >> One additional gap that I think SHOULD be addressed. RFC 3986 says: >> >> URIs have a global scope and are interpreted consistently regardles= s >> of context, though the result of that interpretation may be in >> relation to the end-user's context. For example, "http://localhost= /" >> has the same interpretation for every user of that reference, even >> though the network interface corresponding to "localhost" may be >> different for each end-user: interpretation is independent of acces= s. >> However, an action made on the basis of that reference will take >> place in relation to the end-user's context, which implies that an >> action intended to refer to a globally unique thing must use a URI >> that distinguishes that resource from all other things. URIs that >> identify in relation to the end-user's local context should only be= >> used when the context itself is a defining aspect of the resource, >> such as when an on-line help manual refers to a file on the end- >> user's file system (e.g., "file:///etc/hosts"). >> >> It should be pointed out in the zoneid document that adding a zone id >> changes the scope to be localhost rather than the scope of the address= =2E >> >> So "http://[fe80::1]/blah" is valid anywhere on the same link. >> But "http://[fe80::1-id]/blah" is valid only within the same host. >> >> -Dave >> >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of >>> Dave Thaler >>> Sent: Friday, July 6, 2012 10:33 AM >>> To: Brian E Carpenter; Bob Hinden >>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >>> zoneid@tools.ietf.org; ipv6@ietf.org Mailing List >>> Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-0= 1.txt >>> >>> It's documented on the page in my original email. >>> >>> However it's not sufficient. Remember my second piece of feedback wa= s >>> that the document contradicts itself, implying the specified syntax s= upports >>> cut and paste, but then doesn't provide a section updating RFC 4007 s= ection >>> 11. >>> >>> If the document both mentions that alternative 3 is used by many thin= gs >>> today (IE, Windows, applications) within APIs that take URI-like stri= ngs, and >>> also adds a section updating RFC 4007 section 11, then I'd be happy w= ith it. >>> >>> -Dave >>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: Friday, July 06, 2012 9:57 AM >>>> To: Bob Hinden >>>> Cc: Dave Thaler; 6man-chairs@tools.ietf.org Chairs; >>>> draft-ietf-6man-uri- zoneid@tools.ietf.org; ipv6@ietf.org Mailing Li= st >>>> Subject: Re: 6MAN WG [second] Last Call: >>>> draft-ietf-6man-uri-zoneid-01.txt >>>> >>>> I'd be happy with that, or a small appendix. Dave, is it documented >>> anywhere? >>>> Regards >>>> Brian >>>> >>>> On 2012-07-06 15:00, Bob Hinden wrote: >>>>> With my co-author hat on, would it help to include a description of= >>>>> what IE >>>> supports in Section 3. Web Browsers? >>>>> Bob >>>>> >>>>> >>>>> On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: >>>>> >>>>>> Dave, >>>>>> >>>>>> 1) FYI, the deadline we gave the URI list to comment on this has >>>>>> just passed, with only one (positive) reply. >>>>>> >>>>>> 2) It's for the WG Chairs to say if they want another version in >>>>>> view of your comments. >>>>>> >>>>>> 3) I don't see how the % format is currently legal. There's no >>>>>> provision for any characters after the IPv6 address, whether >>>>>> percent-encoded or not. We heard of browsers that previously >>>>>> allowed full RFC 4007 syntax (% *not* treated as an escape) but >>>>>> this is the first I've heard of IE allowing a zone index at all. >>>>>> >>>>>> Regards >>>>>> Brian >>>>>> >>>>>> On 2012-07-06 02:28, Dave Thaler wrote: >>>>>>> I know it's after the designated end of WGLC, but here's my >>> feedback... >>>>>>> The document appears to call out existing practice in several >>>>>>> places, such as >>>> in section 1: >>>>>>>> Some versions of some browsers accept the RFC 4007 syntax for >>>>>>>> scoped >>>>>>>> IPv6 addresses embedded in URIs, i.e., they have been coded to >>>>>>>> interpret the "%" sign according to RFC 4007 instead of RFC 3986= =2E >>>>>>> and in Appendix A point 1: >>>>>>>> Advantage: works today. >>>>>>> However, it's missing discussion of other alternatives already in= >>>>>>> common >>>> practice. >>>>>>> For example alternative 3 (escaping the escape character as >>>>>>> allowed by RFC >>>> 3986) has: >>>>>>>> Advantage: allows use of browser. >>>>>>>> >>>>>>>> Disadvantage: ugly and confusing, doesn't allow simple cut = and >>>>>>>> paste. >>>>>>> The disadvantage is certainly true. However the main advantage >>>>>>> are notably lacking, which is that it's already in common practic= e >>>>>>> in many places (to the extent that using a zone id at all is >>>>>>> common practice >>>> anyway). >>>>>>> You'll see at >>>>>>> http://msdn.microsoft.com/en- >>> us/library/windows/desktop/aa385325(v >>>>>>> =3Dv s.85).aspx that alternative 3 is what is supported in IE7 an= d >>>>>>> above, and the APIs are generally available to Windows >>>>>>> applications (i.e. >>>>>>> not just IE7). >>>>>>> >>>>>>> The document does not state whether the existing legal use is >>>>>>> suddenly declared to be illegal, or just another legal way of >>>>>>> doing the same >>>> thing. >>>>>>> If you're telling existing applications and OS's that use alterna= tive 3 that >>> they >>>>>>> have to change, that doesn't sound like a good thing. That's be= cause >>> many >>>> apps >>>>>>> want to be OS-version-independent and use URI parsing libraries >>>>>>> provided >>>> by >>>>>>> the OS. We don't want apps to code their own URI parsing (it's = very >>> easy to >>>>>>> get wrong, especially when you add various internationalization >>> issues). >>>>>>> As a result, apps will tend to code to the lowest common denomina= tor >>> of >>>>>>> OS's they want to work on. That means I expect to see apps cod= ing to >>>>>>> alternative 3 for the foreseeable future. When they don't use t= hem in >>>>>>> edit boxes, the disadvantage of not being able to cut and paste i= s >>>>>>> not a real disadvantage. >>>>>>> >>>>>>> Personally I don't have an issue with allowing both formats if th= e >>>>>>> WG feels strongly that a cut-and-paste-friendly format is needed >>>>>>> in addition to what's existing practice, though having two does >>>>>>> affect the rules for comparison (see >>>>>>> draft-iab-identifier-comparison section 3.1.2) but not noticeably= =2E >>>>>>> >>>>>>> Finally, the stated disadvantage of alternative 3 is only a disad= vantage >>> if the >>>>>>> specified scheme in section 2 *does* allow cut-and-paste. For t= hat to >>>>>>> happen, it means the zone id separator has to work outside the >>> context of >>>>>>> URIs. That is, section 2 says: >>>>>>>> Thus, the scoped address fe80::a%en1 would appear in a URI as >>>>>>>> http://[fe80::a-en1]. >>>>>>> To support cut-and-paste, that means that "ping fe80::a-en1" >>>>>>> needs to work. But this document is titled >>>>>>> " Representing IPv6 Zone Identifiers in Uniform Resource Identifi= ers" >>>>>>> and similarly the abstract limits its scope to URIs. >>>>>>> >>>>>>> Hence section 2 is in contradiction with the analysis of alternat= ive 3. >>>>>>> The document already says it "updates 4007" so it seems that >>>>>>> what's lacking is a section specifically updating RFC 4007 sectio= n >>>>>>> 11 which would declare that both '%' and '-' are acceptable >>>>>>> separators in the textual representation. >>>>>>> >>>>>>> -Dave >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >>>>>>>> Behalf Of Ole Tr=C3=B8an >>>>>>>> Sent: Wednesday, June 13, 2012 5:18 AM >>>>>>>> To: ipv6@ietf.org Mailing List >>>>>>>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- >>>>>>>> zoneid@tools.ietf.org >>>>>>>> Subject: 6MAN WG [second] Last Call: >>>>>>>> draft-ietf-6man-uri-zoneid-01.txt >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> This message starts a one-week 6MAN Working Group Last Call on >>>> advancing: >>>>>>>> Title : Representing IPv6 Zone Identifiers in Uniform >>>>>>>> Resource Identifiers >>>>>>>> Author(s) : Brian Carpenter >>>>>>>> Robert M. Hinden >>>>>>>> Filename : draft-ietf-6man-uri-zoneid-01.txt >>>>>>>> Pages : 9 >>>>>>>> Date : 2012-05-29 >>>>>>>> >>>>>>>> >>>>>>>> as a Proposed Standard. Substantive comments should be directed >>>>>>>> to the mailing list or the co-chairs. Editorial suggestions can >>>>>>>> be sent to the >>>> authors. >>>>>>>> This last call will end on June 20, 2012. >>>>>>>> Regards, >>>>>>>> Bob, & Ole >>>>>>>> ----------------------------------------------------------------= - >>>>>>>> -- >>>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>> Administrative >>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> ----------------------------------------------------------------= - >>>>>>>> -- >>>>>>>> - >>>>>>> -----------------------------------------------------------------= - >>>>>>> -- IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>> Administrative >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -----------------------------------------------------------------= - >>>>>>> -- >>>>>>> >>>>>> ------------------------------------------------------------------= - >>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrativ= e >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> ------------------------------------------------------------------= - >>>>>> - >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >=20 >=20 --------------040705010003080007000700 Content-Type: text/plain; name="draft-ietf-6man-uri-zoneid-02A.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-6man-uri-zoneid-02A.txt" CgoKNk1BTiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQi4gQ2FycGVudGVyCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBVbml2LiBvZiBBdWNrbGFuZApVcGRhdGVzOiAzOTg2 LCA0MDA3IChpZiBhcHByb3ZlZCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBI aW5kZW4KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENoZWNrIFBvaW50CkV4cGlyZXM6IEphbnVhcnkgMTIsIDIwMTMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVseSAxMSwgMjAxMgoKCiAgIFJlcHJl c2VudGluZyBJUHY2IFpvbmUgSWRlbnRpZmllcnMgaW4gVW5pZm9ybSBSZXNvdXJjZSBJZGVu dGlmaWVycwogICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLTZtYW4tdXJpLXpvbmVp ZC0wMQoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0aGUgWm9u ZSBJZGVudGlmaWVyIG9mIGFuIElQdjYgc2NvcGVkCiAgIGFkZHJlc3MgY2FuIGJlIHJlcHJl c2VudGVkIGluIGEgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIHRoYXQKICAgaW5jbHVk ZXMgYSBsaXRlcmFsIElQdjYgYWRkcmVzcy4gIEl0IHVwZGF0ZXMgUkZDIDM5ODYgYW5kIFJG QyA0MDA3LgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBp cyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25z IG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAo SUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3Vy cmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBh dCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy YWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRo YW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiBKYW51YXJ5IDEyLCAyMDEzLgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29w eXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQg YXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAg VGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3Qn cyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgICho dHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUg ZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmll dyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1l bnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0 CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJl IHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1w bGlmaWVkIEJTRCBMaWNlbnNlLgoKCgoKQ2FycGVudGVyICYgSGluZGVuICAgICAgRXhwaXJl cyBKYW51YXJ5IDEyLCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgSVB2NiBab25lIElEIGluIFVSSSAgICAgICAgICAgICAgICAg SnVseSAyMDEyCgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICAy LiAgU3BlY2lmaWNhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDQKICAgMy4gIFdlYiBCcm93c2VycyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1CiAgIDQuICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNgog ICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDYKICAgNi4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgIDcuICBDaGFuZ2UgbG9n IFtSRkMgRWRpdG9yOiBQbGVhc2UgcmVtb3ZlXSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NwogICA4LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDcKICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3CiAgICAgOC4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNwogICBBcHBlbmRpeCBBLiAgQWx0ZXJuYXRpdmVzIENvbnNpZGVyZWQgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA5CgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDYXJwZW50ZXIgJiBIaW5kZW4gICAgICBFeHBp cmVzIEphbnVhcnkgMTIsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICBJUHY2IFpvbmUgSUQgaW4gVVJJICAgICAgICAgICAgICAg ICBKdWx5IDIwMTIKCgoxLiAgSW50cm9kdWN0aW9uCgogICBbUkZDMzk4Nl0gZGVmaW5lZCBo b3cgYSBsaXRlcmFsIElQdjYgYWRkcmVzcyBjYW4gYmUgcmVwcmVzZW50ZWQgaW4KICAgdGhl ICJob3N0IiBwYXJ0IG9mIGEgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpLgog ICBTdWJzZXF1ZW50bHksIFtSRkM0MDA3XSBleHRlbmRlZCB0aGUgdGV4dCByZXByZXNlbnRh dGlvbiBvZiBsaW1pdGVkLQogICBzY29wZSBJUHY2IGFkZHJlc3NlcyBzdWNoIHRoYXQgYSB6 b25lIGlkZW50aWZpZXIgbWF5IGJlIGNvbmNhdGVuYXRlZAogICB0byBhbiBhZGRyZXNzLCBm b3IgcHVycG9zZXMgZGVzY3JpYmVkIGluIHRoYXQgUkZDLiAgWm9uZSBpZGVudGlmaWVycwog ICBhcmUgZXNwZWNpYWxseSB1c2VmdWwgaW4gY29udGV4dHMgd2hlcmUgbGl0ZXJhbCBhZGRy ZXNzZXMgYXJlCiAgIHR5cGljYWxseSB1c2VkLCBmb3IgZXhhbXBsZSBkdXJpbmcgZmF1bHQg ZGlhZ25vc2lzLCB3aGVuIGl0IG1heSBiZQogICBlc3NlbnRpYWwgdG8gc3BlY2lmeSB3aGlj aCBpbnRlcmZhY2UgaXMgdXNlZCBmb3Igc2VuZGluZyB0byBhIGxpbmsKICAgbG9jYWwgYWRk cmVzcy4gIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHpvbmUgaWRlbnRpZmllcnMgaGF2ZSBw dXJlbHkKICAgbG9jYWwgbWVhbmluZyB3aXRoaW4gdGhlIGhvc3Qgd2hlcmUgdGhleSBhcmUg ZGVmaW5lZCwgYW5kIHRoZXkgYXJlCiAgIGNvbXBsZXRlbHkgbWVhbmluZ2xlc3MgZm9yIGFu eSBvdGhlciBob3N0LiAgVG9kYXksIHRoZXkgYXJlIG9ubHkKICAgbWVhbmluZ2Z1bCB3aGVu IGF0dGFjaGVkIHRvIGFkZHJlc3NlcyB3aXRoIGxpbmsgbG9jYWwgc2NvcGUsIGJ1dCBpdAog ICBpcyBwb3NzaWJsZSB0aGF0IG90aGVyIHVzZXMgbWlnaHQgYmUgZGVmaW5lZCBpbiB0aGUg ZnV0dXJlLgoKICAgUkZDIDQwMDcgZG9lcyBub3Qgc3BlY2lmeSBob3cgem9uZSBpZGVudGlm aWVycyBhcmUgdG8gYmUgcmVwcmVzZW50ZWQKICAgaW4gVVJJcy4gIFByYWN0aWNhbCBleHBl cmllbmNlIGhhcyBzaG93biB0aGF0IHRoaXMgZmVhdHVyZSBpcyB1c2VmdWwsCiAgIGluIHBh cnRpY3VsYXIgd2hlbiB1c2luZyBhIHdlYiBicm93c2VyIGZvciBkZWJ1Z2dpbmcgd2l0aCBs aW5rIGxvY2FsCiAgIGFkZHJlc3NlcywgYnV0IGFzIGl0IGlzIHVuZGVmaW5lZCwgaXQgaXMg bm90IGltcGxlbWVudGVkIGNvbnNpc3RlbnRseQogICBpbiBVUkkgcGFyc2VycyBvciBpbiBi cm93c2Vycy4KCiAgIFNvbWUgdmVyc2lvbnMgb2Ygc29tZSBicm93c2VycyBhY2NlcHQgdGhl IFJGQyA0MDA3IHN5bnRheCBmb3Igc2NvcGVkCiAgIElQdjYgYWRkcmVzc2VzIGVtYmVkZGVk IGluIFVSSXMsIGkuZS4sIHRoZXkgaGF2ZSBiZWVuIGNvZGVkIHRvCiAgIGludGVycHJldCB0 aGUgIiUiIHNpZ24gYWNjb3JkaW5nIHRvIFJGQyA0MDA3IGluc3RlYWQgb2YgUkZDIDM5ODYu CiAgIENsZWFybHkgdGhpcyBhcHByb2FjaCBpcyB2ZXJ5IGNvbnZlbmllbnQgZm9yIHVzZXJz LCBhbHRob3VnaCBpdAogICBmb3JtYWxseSBicmVhY2hlcyB0aGUgc3ludGF4IHJ1bGVzIG9m IFJGQyAzOTg2LiAgVGhlIHByZXNlbnQgZG9jdW1lbnQKICAgZGVmaW5lcyBhbiBhbHRlcm5h dGl2ZSBhcHByb2FjaCB0aGF0IHJlc3BlY3RzIGFuZCBleHRlbmRzIHRoZSBydWxlcwogICBv ZiBVUkkgc3ludGF4LgoKICAgVGh1cywgdGhpcyBkb2N1bWVudCB1cGRhdGVzIFtSRkMzOTg2 XSBieSBhZGRpbmcgc3ludGF4IHRvIGFsbG93IGEKICAgem9uZSBpZGVudGlmaWVyIHRvIGJl IGluY2x1ZGVkIGluIGEgbGl0ZXJhbCBJUHY2IGFkZHJlc3Mgd2l0aGluIGEKICAgVVJJLiAg SXQgYWxzbyB1cGRhdGVzIFtSRkM0MDA3XSwgaW4gcGFydGljdWxhciBieSBhZGRpbmcgYSBz ZWNvbmQKICAgYWxsb3dlZCBkZWxpbWl0ZXIgZm9yIHpvbmUgaWRlbnRpZmllcnMuCgogICBJ dCBzaG91bGQgYmUgbm90ZWQgdGhhdCBpbiBvdGhlciBjb250ZXh0cyB0aGFuIGEgdXNlciBp bnRlcmZhY2UsIGEKICAgem9uZSBpZGVudGlmaWVyIGlzIG1hcHBlZCBpbnRvIGEgbnVtZXJp YyB6b25lIGluZGV4IG9yIGludGVyZmFjZQogICBudW1iZXIuICBUaGUgTUlCIHRleHR1YWwg Y29udmVudGlvbiBbUkZDNDAwMV0gYW5kIHRoZSBzb2NrZXQKICAgaW50ZXJmYWNlIFtSRkMz NDkzXSBkZWZpbmUgdGhpcyBhcyBhIDMyIGJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgVGhlCiAg IG1hcHBpbmcgYmV0d2VlbiB0aGUgaHVtYW4tcmVhZGFibGUgem9uZSBpZGVudGlmaWVyIHN0 cmluZyBhbmQgdGhlCiAgIG51bWVyaWMgdmFsdWUgaXMgYSBob3N0LXNwZWNpZmljIGZ1bmN0 aW9uIHRoYXQgdmFyaWVzIGJldHdlZW4KICAgb3BlcmF0aW5nIHN5c3RlbXMuICBUaGUgcHJl c2VudCBkb2N1bWVudCBpcyBjb25jZXJuZWQgb25seSB3aXRoIHRoZQogICBodW1hbi1yZWFk YWJsZSBzdHJpbmcuCgogICBTZXZlcmFsIGFsdGVybmF0aXZlIHNvbHV0aW9ucyB3ZXJlIGNv bnNpZGVyZWQgd2hpbGUgdGhpcyBkb2N1bWVudCB3YXMKICAgZGV2ZWxvcGVkLiAgVGhlIEFw cGVuZGl4IGJyaWVmbHkgZGVzY3JpYmVzIHRoZSBhbHRlcm5hdGl2ZXMgYW5kIHRoZWlyCiAg IGFkdmFudGFnZXMgYW5kIGRpc2FkdmFudGFnZXMuCgoKCgpDYXJwZW50ZXIgJiBIaW5kZW4g ICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgM10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJUHY2IFpvbmUgSUQgaW4gVVJJICAgICAg ICAgICAgICAgICBKdWx5IDIwMTIKCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1Qg Tk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0 aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4g W1JGQzIxMTldLgoKCjIuICBTcGVjaWZpY2F0aW9uCgogICBBY2NvcmRpbmcgdG8gUkZDIDQw MDcsIGEgem9uZSBpZGVudGlmaWVyIGlzIGF0dGFjaGVkIHRvIHRoZSB0ZXh0dWFsCiAgIHJl cHJlc2VudGF0aW9uIG9mIGFuIElQdjYgYWRkcmVzcyBieSBjb25jYXRlbmF0aW5nICIlIiBm b2xsb3dlZCBieQogICA8em9uZV9pZD4sIHdoZXJlIDx6b25lX2lkPiBpcyBhIHN0cmluZyBp ZGVudGlmeWluZyB0aGUgem9uZSBvZiB0aGUKICAgYWRkcmVzcy4gIEhvd2V2ZXIsIFJGQyA0 MDA3IGdpdmVzIG5vIHByZWNpc2UgZGVmaW5pdGlvbiBvZiB0aGUKICAgY2hhcmFjdGVyIHNl dCBhbGxvd2VkIGluIDx6b25lX2lkPi4gIFRoZXJlIGFyZSBubyBydWxlcyBvciBkZSBmYWN0 bwogICBzdGFuZGFyZHMgZm9yIHRoaXMuICBGb3IgZXhhbXBsZSwgdGhlIGZpcnN0IEV0aGVy bmV0IGludGVyZmFjZSBpbiBhCiAgIGhvc3QgbWlnaHQgYmUgY2FsbGVkICUwLCAlMSwgJWVu MSwgJWV0aDAsIG9yIHdoYXRldmVyIHRoZSBpbXBsZW1lbnRlcgogICBoYXBwZW5lZCB0byBj aG9vc2UuCgogICBJbiBhIFVSSSwgYSBsaXRlcmFsIElQdjYgYWRkcmVzcyBpcyBhbHdheXMg ZW1iZWRkZWQgYmV0d2VlbiAiWyIgYW5kCiAgICJdIi4gIFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIGhvdyBhIDx6b25lX2lkPiBjYW4gYmUgYXBwZW5kZWQgdG8gdGhlCiAgIGFkZHJlc3Mu ICBBIDx6b25lX2lkPiBTSE9VTEQgY29udGFpbiBvbmx5IEFTQ0lJIGNoYXJhY3RlcnMgY2xh c3NpZmllZAogICBpbiBSRkMgMzk4NiBhcyAidW5yZXNlcnZlZCIsIHdoaWNoIGNvbnZlbmll bnRseSBleGNsdWRlcyAiXSIgaW4gb3JkZXIKICAgdG8gc2ltcGxpZnkgcGFyc2luZy4KCiAg IFVuZm9ydHVuYXRlbHkgIiUiIGlzIGFsd2F5cyB0cmVhdGVkIGFzIGFuIGVzY2FwZSBjaGFy YWN0ZXIgaW4gYSBVUkksCiAgIGFuZCBhY2NvcmRpbmcgdG8gUkZDIDM5ODYgaXQgTVVTVCB0 aGVyZWZvcmUgaXRzZWxmIGJlIGVzY2FwZWQgaW4gYQogICBVUkksIGluIHRoZSBmb3JtICIl MjUiLiAgRm9yIHRoaXMgcmVhc29uLCAiLSIgKGh5cGhlbikgaXMgdXNlZAogICBpbnN0ZWFk IGFzIHRoZSBzZXBhcmF0b3Igd2hlbiBhIDx6b25lX2lkPiBpcyBpbmNsdWRlZCBpbiBhIFVS SS4KICAgVGh1cywgdGhlIHNjb3BlZCBhZGRyZXNzIGZlODA6OmElZW4xIHdvdWxkIGFwcGVh ciBpbiBhIFVSSSBhcwogICBodHRwOi8vW2ZlODA6OmEtZW4xXS4KCiAgIElmIGFuIG9wZXJh dGluZyBzeXN0ZW0gdXNlcyBhbnkgb3RoZXIgY2hhcmFjdGVycyBpbiB6b25lIG9yIGludGVy ZmFjZQogICBpZGVudGlmaWVycyB0aGF0IGFyZSBub3QgaW4gdGhlICJ1bnJlc2VydmVkIiBj aGFyYWN0ZXIgc2V0LCB0aGV5IE1VU1QKICAgYmUgZXNjYXBlZCB3aXRoIGEgIiUiIHNpZ24g YWNjb3JkaW5nIHRvIFJGQyAzOTg2LgoKICAgV2Ugbm93IHByZXNlbnQgdGhlIG5lY2Vzc2Fy eSBmb3JtYWwgc3ludGF4LgoKICAgSW4gUkZDIDM5ODYsIHRoZSBJUHY2IGxpdGVyYWwgZm9y bWF0IGlzIGZvcm1hbGx5IGRlZmluZWQgaW4gQUJORgogICBbUkZDNTIzNF0gYnkgdGhlIGZv bGxvd2luZyBydWxlOgoKICAgICAgSVAtbGl0ZXJhbCA9ICJbIiAoIElQdjZhZGRyZXNzIC8g SVB2RnV0dXJlICApICJdIgoKICAgVG8gcHJvdmlkZSBzdXBwb3J0IGZvciBhIHpvbmUgaWRl bnRpZmllciwgdGhlIGV4aXN0aW5nIHN5bnRheCBvZgogICBJUHY2YWRkcmVzcyBpcyByZXRh aW5lZCwgYW5kIGEgem9uZSBpZGVudGlmaWVyIG1heSBiZSBhZGRlZAogICBvcHRpb25hbGx5 IHRvIGFueSBsaXRlcmFsIGFkZHJlc3MuICBUaGlzIGFsbG93cyBmbGV4aWJpbGl0eSBmb3IK ICAgdW5rbm93biBmdXR1cmUgdXNlcy4gIFRoZSBydWxlIHF1b3RlZCBhYm92ZSBmcm9tIFJG QyAzOTg2IGlzIHJlcGxhY2VkCiAgIGJ5IHRocmVlIHJ1bGVzOgoKCgoKCgpDYXJwZW50ZXIg JiBIaW5kZW4gICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMTMgICAgICAgICAgICAgICAg W1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJUHY2IFpvbmUgSUQgaW4g VVJJICAgICAgICAgICAgICAgICBKdWx5IDIwMTIKCgogICAgICBJUC1saXRlcmFsID0gIlsi ICggSVB2NmFkZHJ6IC8gSVB2RnV0dXJlICApICJdIgoKICAgICAgWm9uZUlEID0gMSooIHVu cmVzZXJ2ZWQgLyBwY3QtZW5jb2RlZCApCgogICAgICBJUHY2YWRkcnogPSBJUHY2YWRkcmVz cyBbICItIiBab25lSUQgXQoKICAgU2VjdGlvbiAxMSBvZiBSRkMgNDAwNyBpcyB1cGRhdGVk IHRvIGFsbG93ICItIiBhcyB3ZWxsIGFzICIlIiBhcyB0aGUKICAgcHJlY2VkaW5nIGRlbGlt aXRlciBvZiBhIFpvbmVJRC4KCiAgIFRoZSBydWxlcyBpbiBbUkZDNTk1Ml0gU0hPVUxEIGJl IGFwcGxpZWQgaW4gcHJvZHVjaW5nIFVSSXMuCgogICBSRkMgMzk4NiBzdGF0ZXMgdGhhdCBV UklzIGhhdmUgYSBnbG9iYWwgc2NvcGUsIGJ1dCB0aGF0IGluIHNvbWUgY2FzZXMKICAgdGhl aXIgaW50ZXJwcmV0YXRpb24gZGVwZW5kcyBvbiB0aGUgZW5kLXVzZXIncyBjb250ZXh0LiAg VVJJcwogICBpbmNsdWRpbmcgYSBab25lSUQgYXJlIHRvIGJlIGludGVycHJldGVkIG9ubHkg aW4gdGhlIGNvbnRleHQgb2YgdGhlCiAgIGhvc3Qgd2hlcmUgdGhleSBvcmlnaW5hdGUsIHNp bmNlIHRoZSBab25lSUQgaXMgb2YgbG9jYWwgc2lnbmlmYW5jZQogICBvbmx5LgoKICAgVGhl IDZtYW4gV0cgZGlzY3Vzc2VkIGFuZCByZWplY3RlZCBhbiBhbHRlcm5hdGl2ZSBpbiB3aGlj aCB0aGUKICAgZXhpc3Rpbmcgc3ludGF4IG9mIElQdjZhZGRyZXNzIHdvdWxkIGJlIGV4dGVu ZGVkIGJ5IGFuIG9wdGlvbiB0byBhZGQKICAgdGhlIFpvbmVJRCBvbmx5IGZvciB0aGUgY2Fz ZSBvZiBsaW5rLWxvY2FsIGFkZHJlc3Nlcy4gIEl0IHdhcyBmZWx0CiAgIHRoYXQgdGhlIHBy ZXNlbnQgc29sdXRpb24gb2ZmZXJzIG1vcmUgZmxleGliaWxpdHkgZm9yIGZ1dHVyZSB1c2Vz IGFuZAogICBpcyBtb3JlIHN0cmFpZ2h0Zm9yd2FyZCB0byBpbXBsZW1lbnQuCgogICBSRkMg NDAwNyBvZmZlcnMgZ3VpZGFuY2Ugb24gaG93IHRoZSBab25lSUQgYWZmZWN0cyBpbnRlcmZh Y2UvYWRkcmVzcwogICBzZWxlY3Rpb24gaW5zaWRlIHRoZSBJUHY2IHN0YWNrLiAgTm90ZSB0 aGF0IHRoZSBiZWhhdmlvdXIgb2YgYW4gSVB2NgogICBzdGFjayBpZiBwYXNzZWQgYSBub24t emVybyB6b25lIGluZGV4IGZvciBhbiBhZGRyZXNzIG90aGVyIHRoYW4gbGluay0KICAgbG9j YWwgaXMgdW5kZWZpbmVkLgoKCjMuICBXZWIgQnJvd3NlcnMKCiAgIER1ZSB0byB0aGUgbGFj ayBvZiBhIHN0YW5kYXJkIGluIHRoaXMgYXJlYSwgd2ViIGJyb3dzZXJzIGhhdmUgYmVlbgog ICBpbmNvbnNpc3RlbnQgaW4gcHJvdmlkaW5nIGZvciBab25lSURzLiAgTWFueSBoYXZlIG5v IHN1cHBvcnQsIGJ1dAogICB0aGVyZSBhcmUgZXhhbXBsZXMgb2YgYWQgaG9jIHN1cHBvcnQu ICBGb3IgZXhhbXBsZSwgb2xkZXIgdmVyc2lvbnMgb2YKICAgRmlyZWZveCBhbGxvd2VkIHRo ZSB1c2Ugb2YgYSBab25lSUQgcHJlY2VkZWQgYnkgYW4gdW5lc2NhcGVkICIlIgogICBjaGFy YWN0ZXIsIGJ1dCB0aGlzIHdhcyByZW1vdmVkIGZvciBjb25zaXN0ZW5jeSB3aXRoIFJGQyAz OTg2LiAgQXMKICAgYW5vdGhlciBleGFtcGxlLCByZWNlbnQgdmVyc2lvbnMgb2YgSW50ZXJu ZXQgRXhwbG9yZXIgYWxsb3cgdXNlIG9mIGEKICAgWm9uZUlEIHByZWNlZGVkIGJ5IGEgIiUi IGNoYXJhY3RlciBlc2NhcGVkIGFzICIlMjUiLCBzdGlsbCBiZXlvbmQgdGhlCiAgIHN5bnRh eCBhbGxvd2VkIGJ5IFJGQyAzOTg2LiAgVGhpcyBzeW50YXggZXh0ZW5zaW9uIGlzIGluIGZh Y3QgdXNlZAogICBpbnRlcm5hbGx5IGluIHRoZSBXaW5kb3dzIG9wZXJhdGluZyBzeXN0ZW0g YW5kIHNvbWUgb2YgaXRzIEFQSXMuCgogICBJbiByZWNlbnQgeWVhcnMsIHdlYiBicm93c2Vy cyBoYXZlIGV2b2x2ZWQgY29uc2lkZXJhYmx5IGFuZCBub3cKICAgYWNjZXB0IGFuZCBwYXJz ZSBtYW55IGZvcm1zIG9mIGlucHV0IHRoYXQgYXJlIG5vdCBhIGZvcm1hbCBVUkkuCiAgIEV4 YW1wbGVzIG9mIHRoaXMgaW5jbHVkZSBob3N0IG5hbWVzLCBzZWFyY2ggaXRlbXMsIGJvb2tt YXJrcywgc2VhcmNoCiAgIGhpc3RvcnksIGV0Yy4gIEZvciBleGFtcGxlIHRoZSBHb29nbGUg Q2hyb21lIGJyb3dzZXIgbm93IGNhbGxzIHRoZQogICAiYWRkcmVzcyBiYXIiIHRoZSAib21u aWJveCIgW2Nocm9tZV0uICBUaGUgYXV0aG9ycyBiZWxpZXZlIGl0IGlzCiAgIGZlYXNpYmxl LCBhbmQgdmVyeSBjb252ZW5pZW50IGZvciB1c2VycywgaWYgYnJvd3NlcnMgYWxzbyBhbGxv dyAoaW4KICAgYWRkaXRpb24gdG8gdGhlIGZvcm1hbCBVUkkgc3ludGF4IGRlZmluZWQgaW4g dGhpcyBkb2N1bWVudCkgYSBzeW50YXgKCgoKQ2FycGVudGVyICYgSGluZGVuICAgICAgRXhw aXJlcyBKYW51YXJ5IDEyLCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgSVB2NiBab25lIElEIGluIFVSSSAgICAgICAgICAgICAg ICAgSnVseSAyMDEyCgoKICAgdGhhdCB3aWxsIGVuYWJsZSBjdXQgYW5kIHBhc3RlLiAgRm9y IGV4YW1wbGU6CgogICAgIGh0dHA6Ly9bZmU4MDo6YSVlbjFdCgogICBJdCBzZWVtcyB0aGF0 IG1vZGVybiBicm93c2VycyBjYW4gYmUgYWRhcHRlZCB0byBwYXJzZSB0aGlzIGJlY2F1c2Ug aXQKICAgaXMgaW5zaWRlIG9mIHRoZSAiWyIgIl0iJ3MuICBUaGlzIHdvdWxkIHBlcm1pdCB0 aGUgb3V0cHV0IG9mIGNvbW1hbmRzCiAgIGxpa2UgcGluZzYgLXcgZmYwMjo6MSVlbjEgdG8g YmUgImN1dCBhbmQgcGFzdGVkIiBpbnRvIGEgYnJvd3NlcgogICBhZGRyZXNzIGJhci4gIENv bnNlcXVlbnRseSB0aGlzIGRvY3VtZW50IHJlY29tbWVuZHMgdGhhdCBicm93c2VycwogICBz dXBwb3J0IHRoaXMgc3ludGF4IGluIGFkZGl0aW9uIHRvIHRoZSBmb3JtYWwgVVJJIHN5bnRh eCBkZWZpbmVkCiAgIGFib3ZlLgoKCjQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAg VGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIFtSRkMzOTg2XSBhbmQgW1JGQzQwMDdd IGFwcGx5LiAgSW4KICAgcGFydGljdWxhciwgdGhpcyBVUkkgZm9ybWF0IGNyZWF0ZXMgYSBz cGVjaWZpYyBwYXRod2F5IGJ5IHdoaWNoIGEKICAgZGVjZWl0ZnVsIHpvbmUgaW5kZXggbWln aHQgYmUgY29tbXVuaWNhdGVkLCBhcyBtZW50aW9uZWQgaW4gdGhlIGZpbmFsCiAgIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb24gb2YgUkZDIDQwMDcuICBJdCBpcyBlbXBoYXNpc2VkIHRoYXQg dGhlIGZvcm1hdAogICBpcyBpbnRlbmRlZCBvbmx5IGZvciBkZWJ1Z2dpbmcgcHVycG9zZXMs IGJ1dCBvZiBjb3Vyc2UgdGhpcyBpbnRlbnRpb24KICAgZG9lcyBub3QgcHJldmVudCBtaXN1 c2UuCgogICBUbyBsaW1pdCB0aGlzIHJpc2ssIGltcGxlbWVudGF0aW9ucyBTSE9VTEQgTk9U IGFsbG93IHVzZSBvZiB0aGlzCiAgIGZvcm1hdCBleGNlcHQgZm9yIHdlbGwtZGVmaW5lZCB1 c2FnZXMgc3VjaCBhcyBzZW5kaW5nIHRvIGxpbmsgbG9jYWwKICAgYWRkcmVzc2VzIHVuZGVy IHByZWZpeCBmZTgwOjovMTAuCgogICBBbiBIVFRQIHNlcnZlciBvciBwcm94eSBNVVNUIGln bm9yZSBhbnkgWm9uZUlEIGF0dGFjaGVkIHRvIGFuCiAgIGluY29taW5nIFVSSSwgYXMgaXQg b25seSBoYXMgbG9jYWwgc2lnbmlmaWNhbmNlIGF0IHRoZSBzZW5kaW5nIGhvc3QuCgoKNS4g IElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgcmVxdWVzdHMgbm8gYWN0 aW9uIGJ5IElBTkEuCgoKNi4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoZSBsYWNrIG9mIHRo aXMgZm9ybWF0IHdhcyBmaXJzdCBwb2ludGVkIG91dCBieSBNYXJnYXJldCBXYXNzZXJtYW4K ICAgc29tZSB5ZWFycyBhZ28sIGFuZCBtb3JlIHJlY2VudGx5IGJ5IEtlcnJ5IEx5bm4uICBB IHByZXZpb3VzIGRyYWZ0CiAgIGRvY3VtZW50IGJ5IE1hcnRpbiBEdWVyc3QgYW5kIEJpbGwg RmVubmVyIFtJLUQuZmVubmVyLWxpdGVyYWwtem9uZV0KICAgZGlzY3Vzc2VkIHRoaXMgdG9w aWMgYnV0IHdhcyBub3QgZmluYWxpc2VkLgoKICAgVmFsdWFibGUgY29tbWVudHMgYW5kIGNv bnRyaWJ1dGlvbnMgd2VyZSBtYWRlIGJ5IEthcmwgQXVlciwgQ2Fyc3RlbgogICBCb3JtYW5u LCBCcmlhbiBIYWJlcm1hbiwgVGF0dXlhIEppbm1laSwgVG9tIFBldGNoLCBUb21veXVraSBT YWhhcmEsCiAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciwgRGF2ZSBUaGFsZXIsIGFuZCBPbGUg VHJvYW4uCgogICBCcmlhbiBDYXJwZW50ZXIgd2FzIGEgdmlzaXRvciBhdCB0aGUgQ29tcHV0 ZXIgTGFib3JhdG9yeSwgQ2FtYnJpZGdlCiAgIFVuaXZlcnNpdHkgZHVyaW5nIHBhcnQgb2Yg dGhpcyB3b3JrLgoKCgoKQ2FycGVudGVyICYgSGluZGVuICAgICAgRXhwaXJlcyBKYW51YXJ5 IDEyLCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgSVB2NiBab25lIElEIGluIFVSSSAgICAgICAgICAgICAgICAgSnVseSAyMDEy CgoKICAgVGhpcyBkb2N1bWVudCB3YXMgcHJvZHVjZWQgdXNpbmcgdGhlIHhtbDJyZmMgdG9v bCBbUkZDMjYyOV0uCgoKNy4gIENoYW5nZSBsb2cgW1JGQyBFZGl0b3I6IFBsZWFzZSByZW1v dmVdCgogICBkcmFmdC1pZXRmLTZtYW4tdXJpLXpvbmVpZC0wMjogYWRkaXRpb25hbCBXRyBj b21tZW50cywgMjAxMi0wNy0xMS4KCiAgIGRyYWZ0LWlldGYtNm1hbi11cmktem9uZWlkLTAx OiB1c2UgIi0iIGluc3RlYWQgb2YgJTI1LCBsaXN0ZWQKICAgYWx0ZXJuYXRpdmVzIGluIEFw cGVuZGl4LCBhY2NvcmRpbmcgdG8gV0cgZGViYXRlLCBhZGRlZCBzdWdnZXN0aW9uCiAgIGZv ciBicm93c2VyIGRldmVsb3BlcnMsIDIwMTItMDUtMjkuCgogICBkcmFmdC1pZXRmLTZtYW4t dXJpLXpvbmVpZC0wMDogYWRvcHRlZCBieSBXRywgZml4ZWQgc3ludGF4IHRvIGFsbG93CiAg IGZvciAlIGVuY29kZWQgY2hhcmFjdGVycywgMjAxMi0wMi0xNy4KCiAgIGRyYWZ0LWNhcnBl bnRlci02bWFuLXVyaS16b25laWQtMDE6IGNob3NlIE9wdGlvbiAyLCByZW1vdmVkIDE1CiAg IGNoYXJhY3RlciBsaW1pdCwgYWRkZWQgZXhwbGFuYXRpb24gb2YgSUQvbnVtYmVyIG1hcHBp bmcgYW5kIG90aGVyCiAgIGNsYXJpZmljYXRpb25zLCAyMDEyLTAyLTA4LgoKICAgZHJhZnQt Y2FycGVudGVyLTZtYW4tdXJpLXpvbmVpZC0wMDogb3JpZ2luYWwgdmVyc2lvbiwgMjAxMS0x Mi0wNy4KCgo4LiAgUmVmZXJlbmNlcwoKOC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAg IFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRv IEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBS RkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkMzOTg2XSAgQmVybmVycy1MZWUsIFQuLCBG aWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0KICAgICAgICAgICAgICBS ZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCIsIFNURCA2NiwKICAg ICAgICAgICAgICBSRkMgMzk4NiwgSmFudWFyeSAyMDA1LgoKICAgW1JGQzQwMDddICBEZWVy aW5nLCBTLiwgSGFiZXJtYW4sIEIuLCBKaW5tZWksIFQuLCBOb3JkbWFyaywgRS4sIGFuZAog ICAgICAgICAgICAgIEIuIFppbGwsICJJUHY2IFNjb3BlZCBBZGRyZXNzIEFyY2hpdGVjdHVy ZSIsIFJGQyA0MDA3LAogICAgICAgICAgICAgIE1hcmNoIDIwMDUuCgogICBbUkZDNTIzNF0g IENyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3ludGF4 CiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBTVEQgNjgsIFJGQyA1MjM0 LCBKYW51YXJ5IDIwMDguCgogICBbUkZDNTk1Ml0gIEthd2FtdXJhLCBTLiBhbmQgTS4gS2F3 YXNoaW1hLCAiQSBSZWNvbW1lbmRhdGlvbiBmb3IgSVB2NgogICAgICAgICAgICAgIEFkZHJl c3MgVGV4dCBSZXByZXNlbnRhdGlvbiIsIFJGQyA1OTUyLCBBdWd1c3QgMjAxMC4KCjguMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJLUQuZmVubmVyLWxpdGVyYWwtem9uZV0K ICAgICAgICAgICAgICBGZW5uZXIsIEIuIGFuZCBNLiBEdWVyc3QsICJGb3JtYXRzIGZvciBJ UHY2IFNjb3BlIFpvbmUKICAgICAgICAgICAgICBJZGVudGlmaWVycyBpbiBMaXRlcmFsIEFk ZHJlc3MgRm9ybWF0cyIsCiAgICAgICAgICAgICAgZHJhZnQtZmVubmVyLWxpdGVyYWwtem9u ZS0wMiAod29yayBpbiBwcm9ncmVzcyksCgoKCkNhcnBlbnRlciAmIEhpbmRlbiAgICAgIEV4 cGlyZXMgSmFudWFyeSAxMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgIElQdjYgWm9uZSBJRCBpbiBVUkkgICAgICAgICAgICAg ICAgIEp1bHkgMjAxMgoKCiAgICAgICAgICAgICAgT2N0b2JlciAyMDA1LgoKICAgW1JGQzI2 MjldICBSb3NlLCBNLiwgIldyaXRpbmcgSS1EcyBhbmQgUkZDcyB1c2luZyBYTUwiLCBSRkMg MjYyOSwKICAgICAgICAgICAgICBKdW5lIDE5OTkuCgogICBbUkZDMzQ5M10gIEdpbGxpZ2Fu LCBSLiwgVGhvbXNvbiwgUy4sIEJvdW5kLCBKLiwgTWNDYW5uLCBKLiwgYW5kIFcuCiAgICAg ICAgICAgICAgU3RldmVucywgIkJhc2ljIFNvY2tldCBJbnRlcmZhY2UgRXh0ZW5zaW9ucyBm b3IgSVB2NiIsCiAgICAgICAgICAgICAgUkZDIDM0OTMsIEZlYnJ1YXJ5IDIwMDMuCgogICBb UkZDNDAwMV0gIERhbmllbGUsIE0uLCBIYWJlcm1hbiwgQi4sIFJvdXRoaWVyLCBTLiwgYW5k IEouCiAgICAgICAgICAgICAgU2Nob2Vud2FlbGRlciwgIlRleHR1YWwgQ29udmVudGlvbnMg Zm9yIEludGVybmV0IE5ldHdvcmsKICAgICAgICAgICAgICBBZGRyZXNzZXMiLCBSRkMgNDAw MSwgRmVicnVhcnkgMjAwNS4KCiAgIFtjaHJvbWVdICAgR29vZ2xlLCAiVXNlIHRoZSBhZGRy ZXNzIGJhciAob21uaWJveCkiLCAyMDEyLCA8aHR0cDovLwogICAgICAgICAgICAgIHN1cHBv cnQuZ29vZ2xlLmNvbS9jaHJvbWUvYmluL2Fuc3dlci5weT9hbnN3ZXI9OTU0NDA+LgoKCkFw cGVuZGl4IEEuICBBbHRlcm5hdGl2ZXMgQ29uc2lkZXJlZAoKICAgMS4gIExlYXZlIHRoZSBw cm9ibGVtIHVuc29sdmVkLgoKICAgICAgIFRoaXMgd291bGQgbWVhbiB0aGF0IHBlci1pbnRl cmZhY2UgZGlhZ25vc3RpY3Mgd291bGQgc3RpbGwgaGF2ZQogICAgICAgdG8gYmUgcGVyZm9y bWVkIHVzaW5nIHBpbmcgb3IgcGluZzY6CgogICAgICAgcGluZyBmZTgwOjphJWVuMQoKICAg ICAgIEFkdmFudGFnZTogd29ya3MgdG9kYXkuCgogICAgICAgRGlzYWR2YW50YWdlOiBsZXNz IGNvbnZlbmllbnQgdGhhbiB1c2luZyBhIGJyb3dzZXIuCgogICAyLiAgU2ltcGx5IHVzaW5n IHRoZSBwZXJjZW50IGNoYXJhY3Rlci4KCiAgICAgICBodHRwOi8vW2ZlODA6OmElZW4xXQoK ICAgICAgIEFkdmFudGFnZTogYWxsb3dzIHVzZSBvZiBicm93c2VyLCBhbGxvd3MgY3V0IGFu ZCBwYXN0ZS4KCiAgICAgICBEaXNhZHZhbnRhZ2U6IGludmFsaWQgc3ludGF4IHVuZGVyIFJG QyAzOTg2OyBub3QgYWNjZXB0YWJsZSB0bwogICAgICAgVVJJIGNvbW11bml0eS4KCiAgIDMu ICBFc2NhcGluZyB0aGUgZXNjYXBlIGNoYXJhY3RlciBhcyBhbGxvd2VkIGJ5IFJGQyAzOTg2 OgoKICAgICAgIGh0dHA6Ly9bZmU4MDo6YSUyNWVuMV0KCiAgICAgICBBZHZhbnRhZ2U6IGFs bG93cyB1c2Ugb2YgYnJvd3Nlci4KCiAgICAgICBEaXNhZHZhbnRhZ2U6IHVnbHkgYW5kIGNv bmZ1c2luZywgZG9lc24ndCBhbGxvdyBzaW1wbGUgY3V0IGFuZAogICAgICAgcGFzdGUuCgoK CgpDYXJwZW50ZXIgJiBIaW5kZW4gICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMTMgICAg ICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJUHY2 IFpvbmUgSUQgaW4gVVJJICAgICAgICAgICAgICAgICBKdWx5IDIwMTIKCgogICA0LiAgQWx0 ZXJuYXRpdmUgc2VwYXJhdG9yCgogICAgICAgaHR0cDovL1tmZTgwOjphLWVuMV0KCiAgICAg ICBBZHZhbnRhZ2U6IGFsbG93cyB1c2Ugb2YgYnJvd3Nlciwgc2ltcGxlIHN5bnRheAoKICAg ICAgIERpc2FkdmFudGFnZTogZG9lc24ndCBhbGxvdyBzaW1wbGUgY3V0IGFuZCBwYXN0ZS4K CiAgICAgICBOb3RlOiB0aGUgaW5pdGlhbCBwcm9wb3NhbCBmb3IgdGhpcyBjaG9pY2Ugd2Fz IHRvIHVzZSBhbgogICAgICAgdW5kZXJzY29yZSBhcyB0aGUgc2VwYXJhdG9yLCBidXQgaXQg d2FzIG5vdGVkIHRoYXQgdGhpcyBiZWNvbWVzCiAgICAgICBlZmZlY3RpdmVseSBpbnZpc2li bGUgd2hlbiBhIHVzZXIgaW50ZXJmYWNlIGF1dG9tYXRpY2FsbHkKICAgICAgIHVuZGVybGlu ZXMgVVJMcy4KCiAgIDUuICBXaXRoIHRoZSAiSVB2RnV0dXJlIiBzeW50YXggbGVmdCBvcGVu IGluIFJGQyAzOTg2OgoKICAgICAgIGh0dHA6Ly9bdjYuZmU4MDo6YV9lbjFdCgogICAgICAg QWR2YW50YWdlOiBhbGxvd3MgdXNlIG9mIGJyb3dzZXIuCgogICAgICAgRGlzYWR2YW50YWdl OiB1Z2x5IGFuZCByZWR1bmRhbnQsIGRvZXNuJ3QgYWxsb3cgc2ltcGxlIGN1dCBhbmQKICAg ICAgIHBhc3RlLgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgQnJpYW4gQ2FycGVudGVyCiAg IERlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZQogICBVbml2ZXJzaXR5IG9mIEF1Y2ts YW5kCiAgIFBCIDkyMDE5CiAgIEF1Y2tsYW5kLCAgIDExNDIKICAgTmV3IFplYWxhbmQKCiAg IEVtYWlsOiBicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20KCgogICBSb2JlcnQgTS4gSGlu ZGVuCiAgIENoZWNrIFBvaW50IFNvZnR3YXJlIFRlY2hub2xvZ2llcywgSW5jLgogICA4MDAg QnJpZGdlIFBhcmt3YXkKICAgUmVkd29vZCBDaXR5LCBDQSAgOTQwNjUKICAgVVMKCiAgIEVt YWlsOiBib2IuaGluZGVuQGdtYWlsLmNvbQoKCgoKCgoKCgpDYXJwZW50ZXIgJiBIaW5kZW4g ICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgOV0K DAo= --------------040705010003080007000700 Content-Type: text/html; charset=ISO-8859-1; name="ZoneIDdiffs.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ZoneIDdiffs.html" CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRp b25hbC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFu c2l0aW9uYWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS4zOXAxOiByZmNk aWZmICAtLT4gCjwhLS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1M IDQuMDEgVHJhbnNpdGlvbmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogTGludXggaWV0ZmEgMi42 LjI3LjQ1LTAuMS14ZW4gIzEgU01QIDIwMTAtMDItMjIgMTY6NDk6NDcgKzAxMDAgeDg2XzY0 IHg4Nl82NCB4ODZfNjQgR05VL0xpbnV4IC0tPiAKPCEtLSBVc2luZyBhd2s6IC9iaW4vZ2F3 azogR05VIEF3ayAzLjEuNiAtLT4gCjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjog ZGlmZiAoR05VIGRpZmZ1dGlscykgMi44LjctY3ZzIC0tPiAKPCEtLSBVc2luZyB3ZGlmZjog L3Vzci9iaW4vd2RpZmY6IEdOVSAwLjUuMiBMMyAtLT4gCjxodG1sPiAKPGhlYWQ+IAogIDxt ZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFy c2V0PWlzby04ODU5LTEiIC8+IAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUt VHlwZSIgY29udGVudD0idGV4dC9jc3MiIC8+IAogIDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRm LTZtYW4tdXJpLXpvbmVpZC0wMS50eHQgLSBkcmFmdC1pZXRmLTZtYW4tdXJpLXpvbmVpZC0w MkEudHh0PC90aXRsZT4gCiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gCiAgICBib2R5ICAg IHsgbWFyZ2luOiAwLjRleDsgbWFyZ2luLXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAgICB7 IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9z cGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07fSAKICAgIHRo ICAgICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAKICAgIC5zbWFsbCAgeyBmb250LXNpemU6 IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVmdCAgIHsgYmFja2dyb3VuZC1jb2xvcjog I0VFRTsgfSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyB9IAogICAg LmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAgICAubGJsb2NrIHsgYmFj a2dyb3VuZC1jb2xvcjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjRkY4OyB9IAogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0gCiAg ICAuZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52b2lkICAgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29s b3I6ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAK ICAgIC5saW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250 LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAycHg7IH0gCiAg ICAuZWxpcHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5sZWZ0IC5jb250 IHsgYmFja2dyb3VuZC1jb2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAuY29udCB7IGJhY2tn cm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1j b2xvcjogIzlEOTsgfSAKICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj REQ2OyB9IAogICAgLmluc2VydCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0g CiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5z dGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBw YWRkaW5nOiAycHggMDsgfSAKICA8L3N0eWxlPiAKPC9oZWFkPiAKPGJvZHkgPiAKICA8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dHIg Ymdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+PGEgaHJlZj0iL3Rvb2xzL3JmY2RpZmYv cmZjZGlmZi5weWh0P3VybDI9ZHJhZnQtaWV0Zi02bWFuLXVyaS16b25laWQtMDEudHh0IiBz dHlsZT0iY29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4mbHQ7PC9hPiZuYnNw OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi11 cmktem9uZWlkLTAxLnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtNm1hbi11 cmktem9uZWlkLTAxLnR4dDwvYT4mbmJzcDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXVyaS16 b25laWQtMDJBLnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtNm1hbi11cmkt em9uZWlkLTAyQS50eHQ8L2E+Jm5ic3A7PGEgaHJlZj0iL3Rvb2xzL3JmY2RpZmYvcmZjZGlm Zi5weWh0P3VybDE9ZHJhZnQtaWV0Zi02bWFuLXVyaS16b25laWQtMDJBLnR4dCIgc3R5bGU9 ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmd0OzwvYT48L3RoPjx0aD48 L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjZNQU4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEIuIENhcnBlbnRlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjZNQU4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEIuIENhcnBlbnRlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgVW5pdi4gb2YgQXVja2xhbmQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVW5pdi4gb2YgQXVja2xhbmQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+VXBkYXRlczogMzk4 NiwgNDAwNyAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4g SGluZGVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VXBkYXRlczogMzk4Niwg NDAwNyAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gSGlu ZGVuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDaGVjayBQb2ludDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDaGVjayBQb2ludDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiIC8+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5Ob3Zl bWJlciAzMCwgMjAxMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXkgMjk8 L3NwYW4+LCAyMDEyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPkV4cGlyZXM6 IDxzcGFuIGNsYXNzPSJpbnNlcnQiPkphbnVhcnkgMTIsIDIwMTMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSnVseSAxMTwvc3Bhbj4sIDIwMTI8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJlcHJlc2VudGluZyBJUHY2IFpvbmUgSWRl bnRpZmllcnMgaW4gVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJlcHJlc2VudGluZyBJUHY2IFpvbmUgSWRlbnRpZmll cnMgaW4gVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAg ICAgICBkcmFmdC1pZXRmLTZtYW4tdXJpLXpvbmVpZC0wMTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtNm1hbi11cmkt em9uZWlkLTAxPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0 cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBob3cgdGhlIFpvbmUgSWRlbnRpZmllciBvZiBhbiBJUHY2IHNjb3BlZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhv dyB0aGUgWm9uZSBJZGVudGlmaWVyIG9mIGFuIElQdjYgc2NvcGVkPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFkZHJlc3Mg Y2FuIGJlIHJlcHJlc2VudGVkIGluIGEgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIHRo YXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhZGRyZXNzIGNhbiBiZSBy ZXByZXNlbnRlZCBpbiBhIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciB0aGF0PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGluY2x1ZGVzIGEgbGl0ZXJhbCBJUHY2IGFkZHJlc3MuICBJdCB1cGRhdGVzIFJGQyAzOTg2 IGFuZCBSRkMgNDAwNy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmNs dWRlcyBhIGxpdGVyYWwgSVB2NiBhZGRyZXNzLiAgSXQgdXBkYXRlcyBSRkMgMzk4NiBhbmQg UkZDIDQwMDcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMiIg Lz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMSwgbGlu ZSAzMzwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjIiIC8+PHNtYWxs PnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDEsIGxpbmUgMzM8L2Vt PjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUg d29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGFzayBGb3Jj ZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50 IEludGVybmV0LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdvcmtpbmcg ZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERy YWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQv LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9u dGhzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBi eSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUg dG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAyIiAvPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5Ob3ZlbWJlciAzMCwgMjAxMjwvc3Bhbj4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gPHNw YW4gY2xhc3M9Imluc2VydCI+SmFudWFyeSAxMiwgMjAxMzwvc3Bhbj4uPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJpZ2h0IChjKSAyMDEyIElFVEYg VHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5k IHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhvcnMu ICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJq ZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1Ag NzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlzaW9ucyBSZWxhdGlu ZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHA6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9m PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHA6Ly90cnVzdGVlLmll dGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3Vt ZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1YmxpY2F0aW9uIG9m IHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMyIg Lz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMiwgbGlu ZSAxMDwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjMiIC8+PHNtYWxs PnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDIsIGxpbmUgMTA8L2Vt PjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUg Q29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3Q8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5j bHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gNC5lIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5jbHVkZSBT aW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5l IG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQg d2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3 YXJyYW50eSBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vu c2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzY3JpYmVkIGluIHRo ZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+VGFibGUgb2YgQ29udGVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDIuICBTcGVjaWZpY2F0aW9uIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDIuICBTcGVjaWZpY2F0aW9uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAz LiAgV2ViIEJyb3dzZXJzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzLiAg V2ViIEJyb3dzZXJzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAzIiAvPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj41PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA0LiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxz cGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDUuICBJQU5BIENvbnNpZGVyYXRp b25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25z IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA2 LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA2LiAg QWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA0IiAvPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgNy4gIENoYW5nZSBsb2cgW1JGQyBFZGl0b3I6IFBsZWFzZSByZW1vdmVd ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj42PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA3LiAgQ2hhbmdlIGxvZyBb UkZDIEVkaXRvcjogUGxlYXNlIHJlbW92ZV0gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxz cGFuIGNsYXNzPSJpbnNlcnQiPjc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDguICBSZWZlcmVuY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDguICBSZWZlcmVuY2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg IDguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDgu MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICA4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICA4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAw NSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEFwcGVuZGl4IEEuICBBbHRlcm5hdGl2 ZXMgQ29uc2lkZXJlZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xh c3M9ImRlbGV0ZSI+Nzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgQXBwZW5kaXggQS4gIEFsdGVybmF0aXZlcyBDb25zaWRlcmVkICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij44PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBB dXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRo b3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEu ICBJbnRyb2R1Y3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xLiAgSW50 cm9kdWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBb UkZDMzk4Nl0gZGVmaW5lZCBob3cgYSBsaXRlcmFsIElQdjYgYWRkcmVzcyBjYW4gYmUgcmVw cmVzZW50ZWQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMzk4 Nl0gZGVmaW5lZCBob3cgYSBsaXRlcmFsIElQdjYgYWRkcmVzcyBjYW4gYmUgcmVwcmVzZW50 ZWQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdGhlICJob3N0IiBwYXJ0IG9mIGEgVW5pZm9ybSBSZXNvdXJjZSBJZGVu dGlmaWVyIChVUkkpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSAi aG9zdCIgcGFydCBvZiBhIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKS48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgU3Vic2VxdWVudGx5LCBbUkZDNDAwN10gZXh0ZW5kZWQgdGhlIHRleHQgcmVwcmVzZW50 YXRpb24gb2YgbGltaXRlZC08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBT dWJzZXF1ZW50bHksIFtSRkM0MDA3XSBleHRlbmRlZCB0aGUgdGV4dCByZXByZXNlbnRhdGlv biBvZiBsaW1pdGVkLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBzY29wZSBJUHY2IGFkZHJlc3NlcyBzdWNoIHRoYXQgYSB6 b25lIGlkZW50aWZpZXIgbWF5IGJlIGNvbmNhdGVuYXRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHNjb3BlIElQdjYgYWRkcmVzc2VzIHN1Y2ggdGhhdCBhIHpvbmUg aWRlbnRpZmllciBtYXkgYmUgY29uY2F0ZW5hdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIGFuIGFkZHJlc3MsIGZv ciBwdXJwb3NlcyBkZXNjcmliZWQgaW4gdGhhdCBSRkMuICBab25lIGlkZW50aWZpZXJzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gYW4gYWRkcmVzcywgZm9yIHB1 cnBvc2VzIGRlc2NyaWJlZCBpbiB0aGF0IFJGQy4gIFpvbmUgaWRlbnRpZmllcnM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg YXJlIGVzcGVjaWFsbHkgdXNlZnVsIGluIGNvbnRleHRzIHdoZXJlIGxpdGVyYWwgYWRkcmVz c2VzIGFyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFyZSBlc3BlY2lh bGx5IHVzZWZ1bCBpbiBjb250ZXh0cyB3aGVyZSBsaXRlcmFsIGFkZHJlc3NlcyBhcmU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQt bDQiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDMs IGxpbmUgMzc8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI0IiAvPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAzLCBsaW5lIDM3 PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBTb21lIHZlcnNpb25zIG9m IHNvbWUgYnJvd3NlcnMgYWNjZXB0IHRoZSBSRkMgNDAwNyBzeW50YXggZm9yIHNjb3BlZDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNvbWUgdmVyc2lvbnMgb2Ygc29t ZSBicm93c2VycyBhY2NlcHQgdGhlIFJGQyA0MDA3IHN5bnRheCBmb3Igc2NvcGVkPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IElQdjYgYWRkcmVzc2VzIGVtYmVkZGVkIGluIFVSSXMsIGkuZS4sIHRoZXkgaGF2ZSBiZWVu IGNvZGVkIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSVB2NiBhZGRy ZXNzZXMgZW1iZWRkZWQgaW4gVVJJcywgaS5lLiwgdGhleSBoYXZlIGJlZW4gY29kZWQgdG88 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgaW50ZXJwcmV0IHRoZSAiJSIgc2lnbiBhY2NvcmRpbmcgdG8gUkZDIDQwMDcgaW5z dGVhZCBvZiBSRkMgMzk4Ni48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBp bnRlcnByZXQgdGhlICIlIiBzaWduIGFjY29yZGluZyB0byBSRkMgNDAwNyBpbnN0ZWFkIG9m IFJGQyAzOTg2LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBDbGVhcmx5IHRoaXMgYXBwcm9hY2ggaXMgdmVyeSBjb252ZW5p ZW50IGZvciB1c2VycywgYWx0aG91Z2ggaXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBDbGVhcmx5IHRoaXMgYXBwcm9hY2ggaXMgdmVyeSBjb252ZW5pZW50IGZvciB1 c2VycywgYWx0aG91Z2ggaXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZm9ybWFsbHkgYnJlYWNoZXMgdGhlIHN5bnRheCBy dWxlcyBvZiBSRkMgMzk4Ni4gIFRoZSBwcmVzZW50IGRvY3VtZW50PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgZm9ybWFsbHkgYnJlYWNoZXMgdGhlIHN5bnRheCBydWxl cyBvZiBSRkMgMzk4Ni4gIFRoZSBwcmVzZW50IGRvY3VtZW50PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlZmluZXMgYW4g YWx0ZXJuYXRpdmUgYXBwcm9hY2ggdGhhdCByZXNwZWN0cyBhbmQgZXh0ZW5kcyB0aGUgcnVs ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZWZpbmVzIGFuIGFsdGVy bmF0aXZlIGFwcHJvYWNoIHRoYXQgcmVzcGVjdHMgYW5kIGV4dGVuZHMgdGhlIHJ1bGVzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIG9mIFVSSSBzeW50YXguPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg b2YgVVJJIHN5bnRheC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFRodXMsIHRoaXMgZG9jdW1lbnQgdXBkYXRlcyBbUkZDMzk4Nl0gYnkgYWRkaW5nIHN5 bnRheCB0byBhbGxvdyBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGh1 cywgdGhpcyBkb2N1bWVudCB1cGRhdGVzIFtSRkMzOTg2XSBieSBhZGRpbmcgc3ludGF4IHRv IGFsbG93IGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgem9uZSBpZGVudGlmaWVyIHRvIGJlIGluY2x1ZGVkIGluIGEgbGl0 ZXJhbCBJUHY2IGFkZHJlc3Mgd2l0aGluIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICB6b25lIGlkZW50aWZpZXIgdG8gYmUgaW5jbHVkZWQgaW4gYSBsaXRlcmFsIElQ djYgYWRkcmVzcyB3aXRoaW4gYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDYiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBVUkkuICBJdCBhbHNvIDxzcGFuIGNsYXNzPSJkZWxldGUi PmNsYXJpZmllcyBzb21lIHN0YXRlbWVudHM8L3NwYW4+IGluIDxzcGFuIGNsYXNzPSJkZWxl dGUiPltSRkM0MDA3XS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIFVSSS4gIEl0IGFsc28gPHNwYW4gY2xhc3M9Imluc2VydCI+dXBkYXRlcyBbUkZDNDAw N10sPC9zcGFuPiBpbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wYXJ0aWN1bGFyIGJ5IGFkZGlu ZyBhIHNlY29uZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgYWxsb3dlZCBkZWxpbWl0ZXIgZm9yIHpvbmUg aWRlbnRpZmllcnMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgaW4gb3RoZXIgY29udGV4dHMgdGhh biBhIHVzZXIgaW50ZXJmYWNlLCBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgaW4gb3RoZXIgY29udGV4dHMgdGhhbiBhIHVz ZXIgaW50ZXJmYWNlLCBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHpvbmUgaWRlbnRpZmllciBpcyBtYXBwZWQgaW50byBh IG51bWVyaWMgem9uZSBpbmRleCBvciBpbnRlcmZhY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB6b25lIGlkZW50aWZpZXIgaXMgbWFwcGVkIGludG8gYSBudW1lcmlj IHpvbmUgaW5kZXggb3IgaW50ZXJmYWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG51bWJlci4gIFRoZSBNSUIgdGV4dHVh bCBjb252ZW50aW9uIFtSRkM0MDAxXSBhbmQgdGhlIHNvY2tldDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIG51bWJlci4gIFRoZSBNSUIgdGV4dHVhbCBjb252ZW50aW9u IFtSRkM0MDAxXSBhbmQgdGhlIHNvY2tldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbnRlcmZhY2UgW1JGQzM0OTNdIGRl ZmluZSB0aGlzIGFzIGEgMzIgYml0IHVuc2lnbmVkIGludGVnZXIuICBUaGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbnRlcmZhY2UgW1JGQzM0OTNdIGRlZmluZSB0 aGlzIGFzIGEgMzIgYml0IHVuc2lnbmVkIGludGVnZXIuICBUaGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWFwcGluZyBi ZXR3ZWVuIHRoZSBodW1hbi1yZWFkYWJsZSB6b25lIGlkZW50aWZpZXIgc3RyaW5nIGFuZCB0 aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXBwaW5nIGJldHdlZW4g dGhlIGh1bWFuLXJlYWRhYmxlIHpvbmUgaWRlbnRpZmllciBzdHJpbmcgYW5kIHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBudW1lcmljIHZhbHVlIGlzIGEgaG9zdC1zcGVjaWZpYyBmdW5jdGlvbiB0aGF0IHZhcmll cyBiZXR3ZWVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbnVtZXJpYyB2 YWx1ZSBpcyBhIGhvc3Qtc3BlY2lmaWMgZnVuY3Rpb24gdGhhdCB2YXJpZXMgYmV0d2Vlbjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBvcGVyYXRpbmcgc3lzdGVtcy4gIFRoZSBwcmVzZW50IGRvY3VtZW50IGlzIGNvbmNl cm5lZCBvbmx5IHdpdGggdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg b3BlcmF0aW5nIHN5c3RlbXMuICBUaGUgcHJlc2VudCBkb2N1bWVudCBpcyBjb25jZXJuZWQg b25seSB3aXRoIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBodW1hbi1yZWFkYWJsZSBzdHJpbmcuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaHVtYW4tcmVhZGFibGUgc3RyaW5nLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJn cmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDUiIC8+PHNtYWxsPnNraXBwaW5n IHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUsIGxpbmUgMTE8L2VtPjwvdGg+PHRo PiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI1IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA1LCBsaW5lIDExPC9lbT48L3RoPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBvcHRpb25hbGx5IHRvIGFueSBsaXRlcmFsIGFkZHJlc3MuICBU aGlzIGFsbG93cyBmbGV4aWJpbGl0eSBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBvcHRpb25hbGx5IHRvIGFueSBsaXRlcmFsIGFkZHJlc3MuICBUaGlzIGFsbG93 cyBmbGV4aWJpbGl0eSBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdW5rbm93biBmdXR1cmUgdXNlcy4gIFRoZSBydWxl IHF1b3RlZCBhYm92ZSBmcm9tIFJGQyAzOTg2IGlzIHJlcGxhY2VkPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgdW5rbm93biBmdXR1cmUgdXNlcy4gIFRoZSBydWxlIHF1 b3RlZCBhYm92ZSBmcm9tIFJGQyAzOTg2IGlzIHJlcGxhY2VkPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJ5IHRocmVlIHJ1 bGVzOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJ5IHRocmVlIHJ1bGVz OjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgSVAtbGl0 ZXJhbCA9ICJbIiAoIElQdjZhZGRyeiAvIElQdkZ1dHVyZSAgKSAiXSI8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBJUC1saXRlcmFsID0gIlsiICggSVB2NmFkZHJ6 IC8gSVB2RnV0dXJlICApICJdIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgWm9uZUlEID0gMSooIHVucmVzZXJ2ZWQgLyBwY3QtZW5jb2RlZCApPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgWm9uZUlEID0gMSooIHVucmVz ZXJ2ZWQgLyBwY3QtZW5jb2RlZCApPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICBJUHY2YWRkcnogPSBJUHY2YWRkcmVzcyBbICItIiBab25lSUQgXTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIElQdjZhZGRyeiA9IElQdjZh ZGRyZXNzIFsgIi0iIFpvbmVJRCBdPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDciIC8+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imlu c2VydCI+U2VjdGlvbiAxMSBvZiBSRkMgNDAwNyBpcyB1cGRhdGVkIHRvIGFsbG93ICItIiBh cyB3ZWxsIGFzICIlIiBhcyB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHByZWNlZGluZyBkZWxpbWl0 ZXIgb2YgYSBab25lSUQuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBydWxlcyBpbiBbUkZDNTk1 Ml0gU0hPVUxEIGJlIGFwcGxpZWQgaW4gcHJvZHVjaW5nIFVSSXMuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHJ1bGVzIGluIFtSRkM1OTUyXSBTSE9VTEQgYmUg YXBwbGllZCBpbiBwcm9kdWNpbmcgVVJJcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOCIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5SRkMgMzk4NiBzdGF0ZXMgdGhhdCBVUklzIGhhdmUgYSBnbG9iYWwgc2Nv cGUsIGJ1dCB0aGF0IGluIHNvbWUgY2FzZXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRoZWlyIGludGVy cHJldGF0aW9uIGRlcGVuZHMgb24gdGhlIGVuZC11c2VyJ3MgY29udGV4dC4gIFVSSXM8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIGluY2x1ZGluZyBhIFpvbmVJRCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg b25seSBpbiB0aGUgY29udGV4dCBvZiB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGhvc3Qgd2hlcmUg dGhleSBvcmlnaW5hdGUsIHNpbmNlIHRoZSBab25lSUQgaXMgb2YgbG9jYWwgc2lnbmlmYW5j ZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgb25seS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIDZtYW4gV0cg ZGlzY3Vzc2VkIGFuZCByZWplY3RlZCBhbiBhbHRlcm5hdGl2ZSBpbiB3aGljaCB0aGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgNm1hbiBXRyBkaXNjdXNzZWQg YW5kIHJlamVjdGVkIGFuIGFsdGVybmF0aXZlIGluIHdoaWNoIHRoZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBleGlzdGlu ZyBzeW50YXggb2YgSVB2NmFkZHJlc3Mgd291bGQgYmUgZXh0ZW5kZWQgYnkgYW4gb3B0aW9u IHRvIGFkZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4aXN0aW5nIHN5 bnRheCBvZiBJUHY2YWRkcmVzcyB3b3VsZCBiZSBleHRlbmRlZCBieSBhbiBvcHRpb24gdG8g YWRkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRoZSBab25lSUQgb25seSBmb3IgdGhlIGNhc2Ugb2YgbGluay1sb2NhbCBh ZGRyZXNzZXMuICBJdCB3YXMgZmVsdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHRoZSBab25lSUQgb25seSBmb3IgdGhlIGNhc2Ugb2YgbGluay1sb2NhbCBhZGRyZXNz ZXMuICBJdCB3YXMgZmVsdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGF0IHRoZSBwcmVzZW50IHNvbHV0aW9uIG9mZmVy cyBtb3JlIGZsZXhpYmlsaXR5IGZvciBmdXR1cmUgdXNlcyBhbmQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGF0IHRoZSBwcmVzZW50IHNvbHV0aW9uIG9mZmVycyBt b3JlIGZsZXhpYmlsaXR5IGZvciBmdXR1cmUgdXNlcyBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaXMgbW9yZSBzdHJh aWdodGZvcndhcmQgdG8gaW1wbGVtZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGlzIG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRvIGltcGxlbWVudC48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJGQyA0MDA3IG9mZmVycyBndWlk YW5jZSBvbiBob3cgdGhlIFpvbmVJRCBhZmZlY3RzIGludGVyZmFjZS9hZGRyZXNzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUkZDIDQwMDcgb2ZmZXJzIGd1aWRhbmNl IG9uIGhvdyB0aGUgWm9uZUlEIGFmZmVjdHMgaW50ZXJmYWNlL2FkZHJlc3M8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2Vs ZWN0aW9uIGluc2lkZSB0aGUgSVB2NiBzdGFjay4gIE5vdGUgdGhhdCB0aGUgYmVoYXZpb3Vy IG9mIGFuIElQdjY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZWxlY3Rp b24gaW5zaWRlIHRoZSBJUHY2IHN0YWNrLiAgTm90ZSB0aGF0IHRoZSBiZWhhdmlvdXIgb2Yg YW4gSVB2NjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBzdGFjayBpZiBwYXNzZWQgYSBub24temVybyB6b25lIGluZGV4IGZv ciBhbiBhZGRyZXNzIG90aGVyIHRoYW4gbGluay08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBzdGFjayBpZiBwYXNzZWQgYSBub24temVybyB6b25lIGluZGV4IGZvciBh biBhZGRyZXNzIG90aGVyIHRoYW4gbGluay08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbG9jYWwgaXMgdW5kZWZpbmVkLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxvY2FsIGlzIHVuZGVmaW5lZC48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuICBXZWIgQnJvd3Nl cnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLiAgV2ViIEJyb3dzZXJzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm ZjAwMDkiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+RHVlIHRvIHRoZSBsYWNrIG9m IGEgc3RhbmRhcmQgaW4gdGhpcyBhcmVhLCB3ZWIgYnJvd3NlcnMgaGF2ZSBiZWVuPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBpbmNvbnNpc3RlbnQgaW4gcHJvdmlkaW5nIGZvciBab25lSURzLiAgTWFu eSBoYXZlIG5vIHN1cHBvcnQsIGJ1dDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdGhlcmUgYXJlIGV4YW1w bGVzIG9mIGFkIGhvYyBzdXBwb3J0LiAgRm9yIGV4YW1wbGUsIG9sZGVyIHZlcnNpb25zIG9m PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICBGaXJlZm94IGFsbG93ZWQgdGhlIHVzZSBvZiBhIFpvbmVJRCBw cmVjZWRlZCBieSBhbiB1bmVzY2FwZWQgIiUiPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBjaGFyYWN0ZXIs IGJ1dCB0aGlzIHdhcyByZW1vdmVkIGZvciBjb25zaXN0ZW5jeSB3aXRoIFJGQyAzOTg2LiAg QXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIGFub3RoZXIgZXhhbXBsZSwgcmVjZW50IHZlcnNpb25zIG9m IEludGVybmV0IEV4cGxvcmVyIGFsbG93IHVzZSBvZiBhPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBab25l SUQgcHJlY2VkZWQgYnkgYSAiJSIgY2hhcmFjdGVyIGVzY2FwZWQgYXMgIiUyNSIsIHN0aWxs IGJleW9uZCB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHN5bnRheCBhbGxvd2VkIGJ5IFJGQyAzOTg2 LiAgVGhpcyBzeW50YXggZXh0ZW5zaW9uIGlzIGluIGZhY3QgdXNlZDwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgaW50ZXJuYWxseSBpbiB0aGUgV2luZG93cyBvcGVyYXRpbmcgc3lzdGVtIGFuZCBzb21l IG9mIGl0cyBBUElzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbiByZWNlbnQgeWVhcnMsIHdlYiBi cm93c2VycyBoYXZlIGV2b2x2ZWQgY29uc2lkZXJhYmx5IGFuZCBub3c8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbiByZWNlbnQgeWVhcnMsIHdlYiBicm93c2VycyBo YXZlIGV2b2x2ZWQgY29uc2lkZXJhYmx5IGFuZCBub3c8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWNjZXB0IGFuZCBwYXJz ZSBtYW55IGZvcm1zIG9mIGlucHV0IHRoYXQgYXJlIG5vdCBhIGZvcm1hbCBVUkkuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWNjZXB0IGFuZCBwYXJzZSBtYW55IGZv cm1zIG9mIGlucHV0IHRoYXQgYXJlIG5vdCBhIGZvcm1hbCBVUkkuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEV4YW1wbGVz IG9mIHRoaXMgaW5jbHVkZSBob3N0IG5hbWVzLCBzZWFyY2ggaXRlbXMsIGJvb2ttYXJrcywg c2VhcmNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRXhhbXBsZXMgb2Yg dGhpcyBpbmNsdWRlIGhvc3QgbmFtZXMsIHNlYXJjaCBpdGVtcywgYm9va21hcmtzLCBzZWFy Y2g8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgaGlzdG9yeSwgZXRjLiAgRm9yIGV4YW1wbGUgdGhlIEdvb2dsZSBDaHJvbWUg YnJvd3NlciBub3cgY2FsbHMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgaGlzdG9yeSwgZXRjLiAgRm9yIGV4YW1wbGUgdGhlIEdvb2dsZSBDaHJvbWUgYnJvd3Nl ciBub3cgY2FsbHMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICJhZGRyZXNzIGJhciIgdGhlICJvbW5pYm94IiBbY2hy b21lXS4gIFRoZSBhdXRob3JzIGJlbGlldmUgaXQgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAiYWRkcmVzcyBiYXIiIHRoZSAib21uaWJveCIgW2Nocm9tZV0uICBU aGUgYXV0aG9ycyBiZWxpZXZlIGl0IGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZlYXNpYmxlLCBhbmQgdmVyeSBjb252 ZW5pZW50IGZvciB1c2VycywgaWYgYnJvd3NlcnMgYWxzbyBhbGxvdyAoaW48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmZWFzaWJsZSwgYW5kIHZlcnkgY29udmVuaWVu dCBmb3IgdXNlcnMsIGlmIGJyb3dzZXJzIGFsc28gYWxsb3cgKGluPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1l PSJkaWZmMDAxMCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGFkZGl0aW9uIHRvIHRo ZSBmb3JtYWwgVVJJIHN5bnRheCBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQpIGE8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYWRkaXRpb24gdG8gdGhlIGZvcm1hbCBV Ukkgc3ludGF4IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCkgYSBzeW50YXg8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBz eW50YXggdGhhdCB3aWxsIGVuYWJsZSBjdXQgYW5kIHBhc3RlLiAgRm9yIGV4YW1wbGU6PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoYXQgd2lsbCBlbmFibGUgY3V0 IGFuZCBwYXN0ZS4gIEZvciBleGFtcGxlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICBodHRwOi8vW2ZlODA6OmElZW4xXTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgaHR0cDovL1tmZTgwOjphJWVuMV08L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEl0IHNlZW1zIHRoYXQgbW9kZXJuIGJy b3dzZXJzIGNhbiBiZSBhZGFwdGVkIHRvIHBhcnNlIHRoaXMgYmVjYXVzZSBpdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEl0IHNlZW1zIHRoYXQgbW9kZXJuIGJyb3dz ZXJzIGNhbiBiZSBhZGFwdGVkIHRvIHBhcnNlIHRoaXMgYmVjYXVzZSBpdDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpcyBp bnNpZGUgb2YgdGhlICJbIiAiXSIncy4gIFRoaXMgd291bGQgcGVybWl0IHRoZSBvdXRwdXQg b2YgY29tbWFuZHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpcyBpbnNp ZGUgb2YgdGhlICJbIiAiXSIncy4gIFRoaXMgd291bGQgcGVybWl0IHRoZSBvdXRwdXQgb2Yg Y29tbWFuZHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgbGlrZSBwaW5nNiAtdyBmZjAyOjoxJWVuMSB0byBiZSAiY3V0IGFu ZCBwYXN0ZWQiIGludG8gYSBicm93c2VyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgbGlrZSBwaW5nNiAtdyBmZjAyOjoxJWVuMSB0byBiZSAiY3V0IGFuZCBwYXN0ZWQi IGludG8gYSBicm93c2VyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFkZHJlc3MgYmFyLiAgQ29uc2VxdWVudGx5IHRoaXMg ZG9jdW1lbnQgcmVjb21tZW5kcyB0aGF0IGJyb3dzZXJzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgYWRkcmVzcyBiYXIuICBDb25zZXF1ZW50bHkgdGhpcyBkb2N1bWVu dCByZWNvbW1lbmRzIHRoYXQgYnJvd3NlcnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc3VwcG9ydCB0aGlzIHN5bnRheCBp biBhZGRpdGlvbiB0byB0aGUgZm9ybWFsIFVSSSBzeW50YXggZGVmaW5lZDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHN1cHBvcnQgdGhpcyBzeW50YXggaW4gYWRkaXRp b24gdG8gdGhlIGZvcm1hbCBVUkkgc3ludGF4IGRlZmluZWQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWJvdmUuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWJvdmUuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+ PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNiIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48ZW0+IHBhZ2UgNiwgbGluZSAyNjwvZW0+PC90aD48dGg+IDwvdGg+PHRo PjxhIG5hbWU9InBhcnQtcjYiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGVtPiBwYWdlIDYsIGxpbmUgNDQ8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LiAgQWNrbm93bGVk Z2VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjYuICBBY2tub3dsZWRn ZW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUg bGFjayBvZiB0aGlzIGZvcm1hdCB3YXMgZmlyc3QgcG9pbnRlZCBvdXQgYnkgTWFyZ2FyZXQg V2Fzc2VybWFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGxhY2sg b2YgdGhpcyBmb3JtYXQgd2FzIGZpcnN0IHBvaW50ZWQgb3V0IGJ5IE1hcmdhcmV0IFdhc3Nl cm1hbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBzb21lIHllYXJzIGFnbywgYW5kIG1vcmUgcmVjZW50bHkgYnkgS2Vycnkg THlubi4gIEEgcHJldmlvdXMgZHJhZnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBzb21lIHllYXJzIGFnbywgYW5kIG1vcmUgcmVjZW50bHkgYnkgS2VycnkgTHlubi4g IEEgcHJldmlvdXMgZHJhZnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYnkgTWFydGluIER1ZXJzdCBhbmQg QmlsbCBGZW5uZXIgW0ktRC5mZW5uZXItbGl0ZXJhbC16b25lXTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3VtZW50IGJ5IE1hcnRpbiBEdWVyc3QgYW5kIEJpbGwg RmVubmVyIFtJLUQuZmVubmVyLWxpdGVyYWwtem9uZV08L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGlzY3Vzc2VkIHRoaXMg dG9waWMgYnV0IHdhcyBub3QgZmluYWxpc2VkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGRpc2N1c3NlZCB0aGlzIHRvcGljIGJ1dCB3YXMgbm90IGZpbmFsaXNlZC48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFZhbHVhYmxlIGNv bW1lbnRzIGFuZCBjb250cmlidXRpb25zIHdlcmUgbWFkZSBieSBLYXJsIEF1ZXIsIENhcnN0 ZW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBWYWx1YWJsZSBjb21tZW50 cyBhbmQgY29udHJpYnV0aW9ucyB3ZXJlIG1hZGUgYnkgS2FybCBBdWVyLCBDYXJzdGVuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEJvcm1hbm4sIEJyaWFuIEhhYmVybWFuLCBUYXR1eWEgSmlubWVpLCBUb20gUGV0Y2gs IFRvbW95dWtpIFNhaGFyYSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBC b3JtYW5uLCBCcmlhbiBIYWJlcm1hbiwgVGF0dXlhIEppbm1laSwgVG9tIFBldGNoLCBUb21v eXVraSBTYWhhcmEsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxMSIgLz48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciwgYW5kIE9sZSBUcm9hbi48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgSnVlcmdlbiBTY2hvZW53YWVsZGVy LCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5EYXZlIFRoYWxlciwgPC9zcGFuPmFuZCBPbGUgVHJv YW4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCcmlhbiBD YXJwZW50ZXIgd2FzIGEgdmlzaXRvciBhdCB0aGUgQ29tcHV0ZXIgTGFib3JhdG9yeSwgQ2Ft YnJpZGdlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQnJpYW4gQ2FycGVu dGVyIHdhcyBhIHZpc2l0b3IgYXQgdGhlIENvbXB1dGVyIExhYm9yYXRvcnksIENhbWJyaWRn ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBVbml2ZXJzaXR5IGR1cmluZyBwYXJ0IG9mIHRoaXMgd29yay48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBVbml2ZXJzaXR5IGR1cmluZyBwYXJ0IG9mIHRo aXMgd29yay48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRo aXMgZG9jdW1lbnQgd2FzIHByb2R1Y2VkIHVzaW5nIHRoZSB4bWwycmZjIHRvb2wgW1JGQzI2 MjldLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQg d2FzIHByb2R1Y2VkIHVzaW5nIHRoZSB4bWwycmZjIHRvb2wgW1JGQzI2MjldLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ny4gIENoYW5nZSBsb2cgW1JGQyBF ZGl0b3I6IFBsZWFzZSByZW1vdmVdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ Ny4gIENoYW5nZSBsb2cgW1JGQyBFZGl0b3I6IFBsZWFzZSByZW1vdmVdPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTIiIC8+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ZHJhZnQtaWV0Zi02bWFuLXVyaS16b25laWQt MDI6IGFkZGl0aW9uYWwgV0cgY29tbWVudHMsIDIwMTItMDctMTEuPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGRyYWZ0LWlldGYtNm1hbi11cmktem9uZWlkLTAxOiB1c2UgIi0iIGluc3RlYWQgb2Yg JTI1LCBsaXN0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkcmFmdC1p ZXRmLTZtYW4tdXJpLXpvbmVpZC0wMTogdXNlICItIiBpbnN0ZWFkIG9mICUyNSwgbGlzdGVk PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGFsdGVybmF0aXZlcyBpbiBBcHBlbmRpeCwgYWNjb3JkaW5nIHRvIFdHIGRlYmF0 ZSwgYWRkZWQgc3VnZ2VzdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGFsdGVybmF0aXZlcyBpbiBBcHBlbmRpeCwgYWNjb3JkaW5nIHRvIFdHIGRlYmF0ZSwgYWRk ZWQgc3VnZ2VzdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb3IgYnJvd3NlciBkZXZlbG9wZXJzLCAyMDEyLTA1LTI5 LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZvciBicm93c2VyIGRldmVs b3BlcnMsIDIwMTItMDUtMjkuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBkcmFmdC1pZXRmLTZtYW4tdXJpLXpvbmVpZC0wMDogYWRvcHRlZCBieSBXRywg Zml4ZWQgc3ludGF4IHRvIGFsbG93PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgZHJhZnQtaWV0Zi02bWFuLXVyaS16b25laWQtMDA6IGFkb3B0ZWQgYnkgV0csIGZpeGVk IHN5bnRheCB0byBhbGxvdzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb3IgJSBlbmNvZGVkIGNoYXJhY3RlcnMsIDIwMTIt MDItMTcuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZm9yICUgZW5jb2Rl ZCBjaGFyYWN0ZXJzLCAyMDEyLTAyLTE3LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgZHJhZnQtY2FycGVudGVyLTZtYW4tdXJpLXpvbmVpZC0wMTogY2hv c2UgT3B0aW9uIDIsIHJlbW92ZWQgMTU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBkcmFmdC1jYXJwZW50ZXItNm1hbi11cmktem9uZWlkLTAxOiBjaG9zZSBPcHRpb24g MiwgcmVtb3ZlZCAxNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBjaGFyYWN0ZXIgbGltaXQsIGFkZGVkIGV4cGxhbmF0aW9u IG9mIElEL251bWJlciBtYXBwaW5nIGFuZCBvdGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGNoYXJhY3RlciBsaW1pdCwgYWRkZWQgZXhwbGFuYXRpb24gb2YgSUQv bnVtYmVyIG1hcHBpbmcgYW5kIG90aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNsYXJpZmljYXRpb25zLCAyMDEyLTAy LTA4LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNsYXJpZmljYXRpb25z LCAyMDEyLTAyLTA4LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgYmdj b2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxhIG5hbWU9ImVu ZCI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDEyIGNoYW5nZSBibG9ja3MuJm5ic3A7PC9hPjwv dGg+PC90cj4KICAgICA8dHIgY2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+OSBsaW5l cyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0aD48aT4z MSBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICA8 dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJzbWFsbCI+PGJyLz5U aGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjM5cDEuIFRoZSBsYXRl c3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8vd3d3LnRvb2xz LmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvIiA+aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xz L3JmY2RpZmYvPC9hPiA8L3RkPjwvdHI+CiAgIDwvdGFibGU+CiAgIDwvYm9keT4KICAgPC9o dG1sPgo= --------------040705010003080007000700-- From george+ipng@m5p.com Tue Jul 10 17:49:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43AF11E8113 for ; Tue, 10 Jul 2012 17:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQS92L4v7OXQ for ; Tue, 10 Jul 2012 17:49:13 -0700 (PDT) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by ietfa.amsl.com (Postfix) with ESMTP id F0BF311E80DE for ; Tue, 10 Jul 2012 17:49:12 -0700 (PDT) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id q6B0nUaq065839 for ; Tue, 10 Jul 2012 20:49:36 -0400 (EDT) (envelope-from george+ipng@m5p.com) Message-ID: <4FFCCD9A.10605@m5p.com> Date: Tue, 10 Jul 2012 20:49:30 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Yes, I know this is the wrong mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 10 Jul 2012 20:49:36 -0400 (EDT) X-Scanned-By: MIMEDefang 2.72 on 10.100.0.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 00:49:13 -0000 So I was trying to browse the list of IETF mailing lists at www.ietf.org to see who might be interested in my failures to browse sites like yahoo.com and netflix.com following the onset of World IPv6 Day. Except that I can't browse www.ietf.org either. It did work previously. I have a packet capture of the failing "telnet www.ietf.org 80" session, if anyone is interested. It looks fine and proper, all the expected SYNs and ACKs as I sent my HTTP request, except for the failure to return any HTTP response. I'm running FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt you can reach www.m5p.com over IPv6; it's been working for years. Would one of you be able to tell me which mailing should I be using? My apologies for the inappropriate message. -- George Mitchell From marka@isc.org Tue Jul 10 18:35:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3600F11E80B3 for ; Tue, 10 Jul 2012 18:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OScrVh3clUES for ; Tue, 10 Jul 2012 18:35:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90211E8079 for ; Tue, 10 Jul 2012 18:35:17 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id C9A0FC94C5; Wed, 11 Jul 2012 01:35:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fcde:c4be:362d:388a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 452F3216C33; Wed, 11 Jul 2012 01:35:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9966D2250F19; Wed, 11 Jul 2012 11:35:29 +1000 (EST) To: George Mitchell From: Mark Andrews References: <4FFCCD9A.10605@m5p.com> Subject: Re: Yes, I know this is the wrong mailing list In-reply-to: Your message of "Tue, 10 Jul 2012 20:49:30 -0400." <4FFCCD9A.10605@m5p.com> Date: Wed, 11 Jul 2012 11:35:29 +1000 Message-Id: <20120711013529.9966D2250F19@drugs.dv.isc.org> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 01:35:18 -0000 In message <4FFCCD9A.10605@m5p.com>, George Mitchell writes: > So I was trying to browse the list of IETF mailing lists at www.ietf.org > to see who might be interested in my failures to browse sites like > yahoo.com and netflix.com following the onset of World IPv6 Day. > > Except that I can't browse www.ietf.org either. > > It did work previously. I have a packet capture of the failing "telnet > www.ietf.org 80" session, if anyone is interested. It looks fine and > proper, all the expected SYNs and ACKs as I sent my HTTP request, > except for the failure to return any HTTP response. I'm running > FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt you > can reach www.m5p.com over IPv6; it's been working for years. > > Would one of you be able to tell me which mailing should I be using? > My apologies for the inappropriate message. -- George Mitchell > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- This sort of failure is usually a PMTUD failure. If you are using a tunnel you need to ensure that your tunnel provider sends back PTB's. The IETF servers do see the PTB's. www.ietf.org does work over tunnels. You can test this theory by lowering the local mtu using "route change -inet6 :: -mtu 1280" (from memory). This will change the advertised mss from 1440. "route -n get -inet6 ::" will show you the current values. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From george+ipng@m5p.com Tue Jul 10 19:04:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754D411E80E4 for ; Tue, 10 Jul 2012 19:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO0EEkEIp+bO for ; Tue, 10 Jul 2012 19:04:55 -0700 (PDT) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by ietfa.amsl.com (Postfix) with ESMTP id ADD0311E8072 for ; Tue, 10 Jul 2012 19:04:53 -0700 (PDT) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id q6B25Gwv066348; Tue, 10 Jul 2012 22:05:21 -0400 (EDT) (envelope-from george+ipng@m5p.com) Message-ID: <4FFCDF5C.80809@m5p.com> Date: Tue, 10 Jul 2012 22:05:16 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Andrews Subject: Re: Yes, I know this is the wrong mailing list References: <4FFCCD9A.10605@m5p.com> <20120711013529.9966D2250F19@drugs.dv.isc.org> In-Reply-To: <20120711013529.9966D2250F19@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 10 Jul 2012 22:05:22 -0400 (EDT) X-Scanned-By: MIMEDefang 2.72 on 10.100.0.3 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 02:04:56 -0000 On 07/10/12 21:35, Mark Andrews wrote: > In message <4FFCCD9A.10605@m5p.com>, George Mitchell writes: >> So I was trying to browse the list of IETF mailing lists at www.ietf.org >> to see who might be interested in my failures to browse sites like >> yahoo.com and netflix.com following the onset of World IPv6 Day. >> >> Except that I can't browse www.ietf.org either. >> >> It did work previously. I have a packet capture of the failing "telnet >> www.ietf.org 80" session, if anyone is interested. It looks fine and >> proper, all the expected SYNs and ACKs as I sent my HTTP request, >> except for the failure to return any HTTP response. I'm running >> FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt you >> can reach www.m5p.com over IPv6; it's been working for years. >> >> Would one of you be able to tell me which mailing should I be using? >> My apologies for the inappropriate message. -- George Mitchell >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > This sort of failure is usually a PMTUD failure. If you are using > a tunnel you need to ensure that your tunnel provider sends back > PTB's. The IETF servers do see the PTB's. www.ietf.org does work > over tunnels. > > You can test this theory by lowering the local mtu using "route > change -inet6 :: -mtu 1280" (from memory). This will change the > advertised mss from 1440. "route -n get -inet6 ::" will show you > the current values. > And so I don't have to do it repeatedly, I can change /etc/rc.conf from: ipv6_defaultrouter="2001:418:3fd::fd" to: ipv6_defaultrouter="2001:418:3fd::fd -mtu 1280" I appreciate all the help! -- George From marka@isc.org Tue Jul 10 19:54:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EFC11E8100 for ; Tue, 10 Jul 2012 19:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuR40vfSJzGG for ; Tue, 10 Jul 2012 19:54:14 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 765D211E80F4 for ; Tue, 10 Jul 2012 19:54:14 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id A7E56C9478; Wed, 11 Jul 2012 02:54:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fcde:c4be:362d:388a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 46FE7216C33; Wed, 11 Jul 2012 02:54:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1E57B22517A8; Wed, 11 Jul 2012 12:54:22 +1000 (EST) To: George Mitchell From: Mark Andrews References: <4FFCCD9A.10605@m5p.com> <20120711013529.9966D2250F19@drugs.dv.isc.org> <4FFCDF5C.80809@m5p.com> Subject: Re: Yes, I know this is the wrong mailing list In-reply-to: Your message of "Tue, 10 Jul 2012 22:05:16 -0400." <4FFCDF5C.80809@m5p.com> Date: Wed, 11 Jul 2012 12:54:21 +1000 Message-Id: <20120711025422.1E57B22517A8@drugs.dv.isc.org> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 02:54:15 -0000 In message <4FFCDF5C.80809@m5p.com>, George Mitchell writes: > On 07/10/12 21:35, Mark Andrews wrote: > > In message <4FFCCD9A.10605@m5p.com>, George Mitchell writes: > >> So I was trying to browse the list of IETF mailing lists at www.ietf.org > >> to see who might be interested in my failures to browse sites like > >> yahoo.com and netflix.com following the onset of World IPv6 Day. > >> > >> Except that I can't browse www.ietf.org either. > >> > >> It did work previously. I have a packet capture of the failing "telnet > >> www.ietf.org 80" session, if anyone is interested. It looks fine and > >> proper, all the expected SYNs and ACKs as I sent my HTTP request, > >> except for the failure to return any HTTP response. I'm running > >> FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt you > >> can reach www.m5p.com over IPv6; it's been working for years. > >> > >> Would one of you be able to tell me which mailing should I be using? > >> My apologies for the inappropriate message. -- George Mitchell > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > This sort of failure is usually a PMTUD failure. If you are using > > a tunnel you need to ensure that your tunnel provider sends back > > PTB's. The IETF servers do see the PTB's. www.ietf.org does work > > over tunnels. > > > > You can test this theory by lowering the local mtu using "route > > change -inet6 :: -mtu 1280" (from memory). This will change the > > advertised mss from 1440. "route -n get -inet6 ::" will show you > > the current values. > > > > And so I don't have to do it repeatedly, I can change /etc/rc.conf from: > ipv6_defaultrouter="2001:418:3fd::fd" > to: > ipv6_defaultrouter="2001:418:3fd::fd -mtu 1280" > > I appreciate all the help! -- George You really should talk to your tunnel provider and get this fixed as this only helps TCP connections. It does not help UDP based protocols. Once your tunnel provider has fixed the tunnel ingress to correctly sent PTB's you will then be in a position to report broken web sites. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From geeohgeegeeoh@gmail.com Tue Jul 10 18:38:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D952911E80F9 for ; Tue, 10 Jul 2012 18:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4714pPFW0tE for ; Tue, 10 Jul 2012 18:38:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2855D11E80E9 for ; Tue, 10 Jul 2012 18:38:08 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1221271pbc.31 for ; Tue, 10 Jul 2012 18:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=N3Aa1JyFk6Y5vIdEwNmt2h9PoMsgQiGeNTt9fhpKgRU=; b=WhiObOwEZZglbInQDRf2RtpewSB9EYPU1MkVruGZYV6drhSnCqNUAOCDN+zIkGMJTo 1d31Xf3d4MMVsq28Tu1YJvIAlZZi58vT2qn1qitHpe9WgPl8RdjB7XD1l0Yc8r+bl+13 1xY4ND3nRKU3X9WbIIft9nBAMx8qL+5omDruVEFOTJyXH9+HeQTW8jBRGQvgDKX0Hl3l R7JGvW0OLTxLfaxtbPFJLw2dLLYuNuziEnckr4eg0F6vDNRh/ORmpxCAGr17/1kFbzYL GyJ4NmxeEqE8G9OBmcVDqBbKxuRTrecfYBEdkNSULqcy9utXJiWD1gkAenTqnCBKQw9q +Z/Q== Received: by 10.68.221.106 with SMTP id qd10mr36072297pbc.42.1341970717352; Tue, 10 Jul 2012 18:38:37 -0700 (PDT) Received: from ?IPv6:2402:6000:203:300:90d2:b340:32be:8aa3? ([2402:6000:203:300:90d2:b340:32be:8aa3]) by mx.google.com with ESMTPS id io2sm624467pbc.24.2012.07.10.18.38.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 18:38:36 -0700 (PDT) Sender: George Michaelson Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) Subject: Re: Yes, I know this is the wrong mailing list From: George Michaelson In-Reply-To: <20120711013529.9966D2250F19@drugs.dv.isc.org> Date: Wed, 11 Jul 2012 13:38:31 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A91F39C-2CC3-4442-9402-CF9D034D76C9@algebras.org> References: <4FFCCD9A.10605@m5p.com> <20120711013529.9966D2250F19@drugs.dv.isc.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Wed, 11 Jul 2012 02:07:49 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 01:38:09 -0000 IETF should be running on a clamped MSS. The only benefits of floating = MTU upwards is an efficiency gain which is almost irrelevant for a = text-mainly website of this nature. It would be lovely if they could rely on the other end, but a governance = body should be reachable all the time. -G (in my HO, and a private opinion unrelated to my employer) On 11/07/2012, at 1:35 PM, Mark Andrews wrote: >=20 > In message <4FFCCD9A.10605@m5p.com>, George Mitchell writes: >> So I was trying to browse the list of IETF mailing lists at = www.ietf.org >> to see who might be interested in my failures to browse sites like >> yahoo.com and netflix.com following the onset of World IPv6 Day. >>=20 >> Except that I can't browse www.ietf.org either. >>=20 >> It did work previously. I have a packet capture of the failing = "telnet >> www.ietf.org 80" session, if anyone is interested. It looks fine and >> proper, all the expected SYNs and ACKs as I sent my HTTP request, >> except for the failure to return any HTTP response. I'm running >> FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt = you >> can reach www.m5p.com over IPv6; it's been working for years. >>=20 >> Would one of you be able to tell me which mailing should I be using? >> My apologies for the inappropriate message. -- George = Mitchell >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > This sort of failure is usually a PMTUD failure. If you are using > a tunnel you need to ensure that your tunnel provider sends back > PTB's. The IETF servers do see the PTB's. www.ietf.org does work > over tunnels. >=20 > You can test this theory by lowering the local mtu using "route > change -inet6 :: -mtu 1280" (from memory). This will change the > advertised mss from 1440. "route -n get -inet6 ::" will show you > the current values. >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From glen@amsl.com Tue Jul 10 19:39:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C2B11E80E0 for ; Tue, 10 Jul 2012 19:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-FvjLC9RsIp for ; Tue, 10 Jul 2012 19:39:38 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id DFEFA11E80A1 for ; Tue, 10 Jul 2012 19:39:38 -0700 (PDT) Received: by c8a.amsl.com (Postfix, from userid 1000) id 1438712CD4C; Tue, 10 Jul 2012 19:40:07 -0700 (PDT) Date: Tue, 10 Jul 2012 19:40:07 -0700 From: Glen To: George Mitchell Subject: Re: Yes, I know this is the wrong mailing list Message-ID: <20120711024007.GA5672@amsl.com> References: <4FFCCD9A.10605@m5p.com> <20120711013529.9966D2250F19@drugs.dv.isc.org> <4FFCDB23.9000109@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFCDB23.9000109@m5p.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 11 Jul 2012 02:07:49 -0700 Cc: ipv6@ietf.org, Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 02:39:39 -0000 On Tue, Jul 10, 2012 at 09:47:15PM -0400, George Mitchell wrote: > We now return you to your normal working group traffic. -- George Thank you all! I'm glad it's working. I'll be here if you need anything else - See you all in Vancouver! Glen From jeroen@unfix.org Wed Jul 11 02:13:11 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35DE21F853E for ; Wed, 11 Jul 2012 02:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs5aEbfOuMkH for ; Wed, 11 Jul 2012 02:13:08 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67221F8525 for ; Wed, 11 Jul 2012 02:13:08 -0700 (PDT) Received: from kami.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 39825801C2A9; Wed, 11 Jul 2012 11:13:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1341998017; bh=4JbGU8K6O6ELcLPg6d64IkvvNLN9i1OjAdOWp7u9oug=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=o5rN2OxGrIF2bt2rhtimCK7L2d1bc3aSYJltq0Wp9pMIQP738gUfO6NZkTdkHr4tH jo8Xot1fO1JcB3YDQhZ/SNu8u6W7HYRutWan1n2Wri6Vy5K3pY1P0OR4zJBAbg5QC/ wfWvwct4nvlyGGxuu9Vo4IdW9z0SQezHugXjfBarJf6Bs72+9CvCrJORnBfvzAXk6d vfkEjHF/uvW4afk4Mv21hHy8OFfL54KNRD5NYFW1cqM1TX4iG/N6NTMgCZeZjRJFwo QycmD5/PIWgCkd8F+OiTB/KEz4xkJZn51YbfkfeannV4Dy4BNWrrPhtPutc0Waewl0 GL5PkhtgqXmtw== Message-ID: <4FFD43BF.8080206@unfix.org> Date: Wed, 11 Jul 2012 11:13:35 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Andrews Subject: Re: Yes, I know this is the wrong mailing list References: <4FFCCD9A.10605@m5p.com> <20120711013529.9966D2250F19@drugs.dv.isc.org> <4FFCDF5C.80809@m5p.com> <20120711025422.1E57B22517A8@drugs.dv.isc.org> In-Reply-To: <20120711025422.1E57B22517A8@drugs.dv.isc.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, George Mitchell , George Michaelson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 09:13:11 -0000 On 2012-07-11 04:54, Mark Andrews wrote: [..] >> And so I don't have to do it repeatedly, I can change /etc/rc.conf from: >> ipv6_defaultrouter="2001:418:3fd::fd" >> to: >> ipv6_defaultrouter="2001:418:3fd::fd -mtu 1280" >> >> I appreciate all the help! -- George > > You really should talk to your tunnel provider and get this fixed as > this only helps TCP connections. It does not help UDP based > protocols. Once your tunnel provider has fixed the tunnel ingress > to correctly sent PTB's you will then be in a position to report > broken web sites. I am fairly sure that NTT does generate and pass through PTBs, if the user filters them incoming is a different question though. The problem in this case seems to be the forgetting to configure an MTU on an tunnel. A better thing is to ask/check what the real MTU of the tunnel is. Likely it is even up to 1480 depending on the underlying path. Of course even better is to get rid of the tunnel and go native ;) On 2012-07-11 03:38, George Michaelson wrote: > IETF should be running on a clamped MSS. The only benefits of > floating MTU upwards is an efficiency gain which is almost irrelevant > for a text-mainly website of this nature. > > It would be lovely if they could rely on the other end, but a > governance body should be reachable all the time. No, the connectivity on the side of the user should be configured properly. Adding hacks is not the way to go and does not solve the general problem of misconfiguration that one can't hack around. Greets, Jeroen From george@m5p.com Tue Jul 10 18:46:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E6811E8079 for ; Tue, 10 Jul 2012 18:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql+b1UcNhBPo for ; Tue, 10 Jul 2012 18:46:53 -0700 (PDT) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by ietfa.amsl.com (Postfix) with ESMTP id A46F211E8072 for ; Tue, 10 Jul 2012 18:46:53 -0700 (PDT) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id q6B1lFbp066234; Tue, 10 Jul 2012 21:47:20 -0400 (EDT) (envelope-from george@m5p.com) Message-ID: <4FFCDB23.9000109@m5p.com> Date: Tue, 10 Jul 2012 21:47:15 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Andrews Subject: Re: Yes, I know this is the wrong mailing list References: <4FFCCD9A.10605@m5p.com> <20120711013529.9966D2250F19@drugs.dv.isc.org> In-Reply-To: <20120711013529.9966D2250F19@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 10 Jul 2012 21:47:20 -0400 (EDT) X-Scanned-By: MIMEDefang 2.72 on 10.100.0.3 X-Mailman-Approved-At: Wed, 11 Jul 2012 03:46:23 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 10:41:08 -0000 On 07/10/12 21:35, Mark Andrews wrote: > In message <4FFCCD9A.10605@m5p.com>, George Mitchell writes: >> So I was trying to browse the list of IETF mailing lists at www.ietf.org >> to see who might be interested in my failures to browse sites like >> yahoo.com and netflix.com following the onset of World IPv6 Day. >> >> Except that I can't browse www.ietf.org either. >> >> It did work previously. I have a packet capture of the failing "telnet >> www.ietf.org 80" session, if anyone is interested. It looks fine and >> proper, all the expected SYNs and ACKs as I sent my HTTP request, >> except for the failure to return any HTTP response. I'm running >> FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt you >> can reach www.m5p.com over IPv6; it's been working for years. >> >> Would one of you be able to tell me which mailing should I be using? >> My apologies for the inappropriate message. -- George Mitchell >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > This sort of failure is usually a PMTUD failure. If you are using > a tunnel you need to ensure that your tunnel provider sends back > PTB's. The IETF servers do see the PTB's. www.ietf.org does work > over tunnels. > > You can test this theory by lowering the local mtu using "route > change -inet6 :: -mtu 1280" (from memory). This will change the > advertised mss from 1440. "route -n get -inet6 ::" will show you > the current values. > Thanks very much -- your diagnosis is correct! Using "route change -inet6 :: -mtu 1280" fixed the problem for www.ietf.org and all the other sites I've been having problems with, too. We now return you to your normal working group traffic. -- George From internet-drafts@ietf.org Wed Jul 11 05:23:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE22121F859B; Wed, 11 Jul 2012 05:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKUSuJ38QyVL; Wed, 11 Jul 2012 05:23:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C46121F842E; Wed, 11 Jul 2012 05:23:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-uri-zoneid-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120711122352.18154.98341.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 05:23:52 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 12:23:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Representing IPv6 Zone Identifiers in Address Literals a= nd Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-02.txt Pages : 10 Date : 2012-07-11 Abstract: This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates RFC 3986 and RFC 4007 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-uri-zoneid-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Wed Jul 11 05:29:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E369D21F861E for ; Wed, 11 Jul 2012 05:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.196 X-Spam-Level: X-Spam-Status: No, score=-101.196 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gbjw7XDRDwWz for ; Wed, 11 Jul 2012 05:29:39 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D36521F861C for ; Wed, 11 Jul 2012 05:29:38 -0700 (PDT) Received: by eaaq13 with SMTP id q13so380201eaa.31 for ; Wed, 11 Jul 2012 05:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=DCqbMlpwV6HNJqTPKMGRerF3ZgoHKBHU4TzjVUmejAU=; b=VghWNq46LtBhDDXHOLuyxNIuQLmMG1uYI++US15b6NoKS4F9uT1bhGfjNTLZJDtj85 /59hR/ct9mcfqNEYX2xV3YpGMGcSyXduCQKxBc3q3F86ScmT8q+HfW/jhxiziy5JaOq7 3vD1GCScOzE5QTuWw4hAgeVAQ+a3PX11jzSZ9E+bhifRrc5rltU7wnu2IDn4WZss2UoD D5AtdTM1O0l7dMLVevlTiSvo+2orb2ZR18hJnZ+ZGzo9S/EjS0vYh/bnTM7mVXDzZGGz 5GYeer4IUqWPIFBMZf6eS7DZ0bo06cd+Xzc8UqRRiZ6uNJF43+mx/bja14CfaYRvv6Do 9nlA== Received: by 10.14.94.201 with SMTP id n49mr2950115eef.158.1342009808852; Wed, 11 Jul 2012 05:30:08 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-124.as13285.net. [2.102.219.124]) by mx.google.com with ESMTPS id y54sm5357262eef.10.2012.07.11.05.30.07 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 05:30:08 -0700 (PDT) Message-ID: <4FFD71D7.4070209@gmail.com> Date: Wed, 11 Jul 2012 13:30:15 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 12:29:40 -0000 This version includes changes for the recent comments from Dave Thaler. It needs a check by the WG that we still have consensus. We did not delete one sentence in section 3 that Dave objects to: "Consequently this document recommends that browsers support this syntax in addition to the formal URI syntax defined above." The URI list raised no objection to the formal syntax change. Brian + Bob (as author) -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-uri-zoneid-02.txt Date: Wed, 11 Jul 2012 05:23:52 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-02.txt Pages : 10 Date : 2012-07-11 Abstract: This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates RFC 3986 and RFC 4007 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-uri-zoneid-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From simon.perreault@viagenie.ca Wed Jul 11 05:43:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8FA21F84F7 for ; Wed, 11 Jul 2012 05:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUHk80nZpCkX for ; Wed, 11 Jul 2012 05:43:18 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7695721F84F6 for ; Wed, 11 Jul 2012 05:43:18 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5066F40037 for ; Wed, 11 Jul 2012 08:43:48 -0400 (EDT) Message-ID: <4FFD7503.20902@viagenie.ca> Date: Wed, 11 Jul 2012 08:43:47 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Yes, I know this is the wrong mailing list References: <4FFCCD9A.10605@m5p.com> <20120711013529.9966D2250F19@drugs.dv.isc.org> <3A91F39C-2CC3-4442-9402-CF9D034D76C9@algebras.org> In-Reply-To: <3A91F39C-2CC3-4442-9402-CF9D034D76C9@algebras.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 12:43:19 -0000 On 07/10/2012 09:38 PM, George Michaelson wrote: > IETF should be running on a clamped MSS. The only benefits of floating MTU upwards is an efficiency gain which is almost irrelevant for a text-mainly website of this nature. > > It would be lovely if they could rely on the other end, but a governance body should be reachable all the time. Are you suggesting we stop eating our own delicious dog food? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tdineen@ix.netcom.com Wed Jul 11 09:22:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DFD21F8665 for ; Wed, 11 Jul 2012 09:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QvutcdxT1va for ; Wed, 11 Jul 2012 09:22:16 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id DF93321F85F0 for ; Wed, 11 Jul 2012 09:22:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ZrB81J+LLb393dATQfxzFFQK8jgdtKOhPqDWwGkkPnaqr4PCw9OX1SCNbkluhvRe; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [71.94.23.76] (helo=[192.168.0.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SozgG-0006wR-O6; Wed, 11 Jul 2012 12:22:24 -0400 Message-ID: <4FFDA840.6080609@ix.netcom.com> Date: Wed, 11 Jul 2012 09:22:24 -0700 From: Thomas Dineen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: George Mitchell Subject: Re: Yes, I know this is the wrong mailing list References: <4FFCCD9A.10605@m5p.com> <20120711013529.9966D2250F19@drugs.dv.isc.org> <4FFCDB23.9000109@m5p.com> In-Reply-To: <4FFCDB23.9000109@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 8fd196f32229d336776432462e451d7bb721073b08cf141fe1e7b2145cf0c0c86ec8acde450591e7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.94.23.76 Cc: ipv6@ietf.org, Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:22:17 -0000 Why don't you just use IPv4 and stop bothering us???????? We are busy to busy with the next boondoogle to worry about IPv6 Bugs!!!!!! Thomas Dineen On 7/10/2012 6:47 PM, George Mitchell wrote: > On 07/10/12 21:35, Mark Andrews wrote: >> In message <4FFCCD9A.10605@m5p.com>, George Mitchell writes: >>> So I was trying to browse the list of IETF mailing lists at >>> www.ietf.org >>> to see who might be interested in my failures to browse sites like >>> yahoo.com and netflix.com following the onset of World IPv6 Day. >>> >>> Except that I can't browse www.ietf.org either. >>> >>> It did work previously. I have a packet capture of the failing "telnet >>> www.ietf.org 80" session, if anyone is interested. It looks fine and >>> proper, all the expected SYNs and ACKs as I sent my HTTP request, >>> except for the failure to return any HTTP response. I'm running >>> FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt you >>> can reach www.m5p.com over IPv6; it's been working for years. >>> >>> Would one of you be able to tell me which mailing should I be using? >>> My apologies for the inappropriate message. -- George Mitchell >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> This sort of failure is usually a PMTUD failure. If you are using >> a tunnel you need to ensure that your tunnel provider sends back >> PTB's. The IETF servers do see the PTB's. www.ietf.org does work >> over tunnels. >> >> You can test this theory by lowering the local mtu using "route >> change -inet6 :: -mtu 1280" (from memory). This will change the >> advertised mss from 1440. "route -n get -inet6 ::" will show you >> the current values. >> > > Thanks very much -- your diagnosis is correct! Using > "route change -inet6 :: -mtu 1280" fixed the problem for www.ietf.org > and all the other sites I've been having problems with, too. > > We now return you to your normal working group traffic. -- George > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From dwing@cisco.com Wed Jul 11 18:09:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED8711E80E5 for ; Wed, 11 Jul 2012 18:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.477 X-Spam-Level: X-Spam-Status: No, score=-110.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAJX7ZT4h3ov for ; Wed, 11 Jul 2012 18:09:11 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E376911E80CA for ; Wed, 11 Jul 2012 18:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3733; q=dns/txt; s=iport; t=1342055384; x=1343264984; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=FuVWNjaeQUUglAGk4uELsQPJtQrTbQe2gkds+rpF+u0=; b=J1ukNzk6PPIv1TQou1gE+l6ET2W1ejIKjU0IJGzvWBUPg/+Br5QMOBq7 /thBLGnEkfvD1u5b48M5aEAKm7Ib+ojNJ4+l01g4M5wIXBVxgwC4gXag5 JC4zkRkqyDEnIgsJ7FE1qzv7KHego/vwsMZKZQyfQNp2DnCG/mIgEunOL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEcj/k+rRDoH/2dsb2JhbABFqE6PLIEHgiABAQEDAQEBAQUKARUCEC0HEAcBAwIJDwIEAQEoBxkOFQoJCAEBBAESCQIXh2UFDJ1RoCeLQIVuA4hLhQWIfIl1gxmBZoJ/ X-IronPort-AV: E=Sophos;i="4.77,571,1336348800"; d="scan'208";a="49116974" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 12 Jul 2012 01:09:31 +0000 Received: from dwingWS (sjc-vpn3-1085.cisco.com [10.21.68.61]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6C19VaC025362; Thu, 12 Jul 2012 01:09:31 GMT From: "Dan Wing" To: "'Templin, Fred L'" , References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> In-Reply-To: Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Date: Wed, 11 Jul 2012 18:09:31 -0700 Message-ID: <00db01cd5fca$fe6ed000$fb4c7000$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqAATul3YA= Content-Language: en-us X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 01:09:12 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Thursday, July 05, 2012 11:31 AM > To: ipv6@ietf.org > Subject: New draft: "IPv6 Source Fragmentation for Link Adaptation > Avoidance" > > Hello, > > I have posted a new draft that calls for an update to RFC2460. > The document proposes to enlist the support of IPv6 hosts in > offloading the burden carried by links that must perform > link-specific fragmentation/reassembly per RFC2460, Section 5: > > "IPv6 requires that every link in the internet have an MTU of 1280 > octets or greater. On any link that cannot convey a 1280-octet > packet in one piece, link-specific fragmentation and reassembly must > be provided at a layer below IPv6." > > The draft announcement appears below. Please review and send > comments to the list. The draft adds a paragraph to the IPv6 spec which says, effectively, if an ICMPv6 PTB is received with a certain MTU, the IPv6 host should try to send packets of that size. The existing IPv6 specification (RFC2460) and its predecessor (RFC1883) have an existing paragraph that says something different should happen when such an IPv6 PTB is received. The existing text says a 1280 byte packet can be sent, but needs a fragmentation header added. How does a host reconcile those two paragraphs, and know which to do? Or are you proposing to replace the existing paragraph with the new paragraph? -d > Fred > fred.l.templin@boeing.com > > --- > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 Source Fragmentation for Link Adaptation > Avoidance > Author(s) : Fred L. Templin > Filename : draft-generic-6man-tunfrag-02.txt > Pages : 5 > Date : 2012-07-05 > > Abstract: > IPv6 intentionally deprecates fragmentation by routers in the > network. Instead, links with restricting MTUs must either drop each > too-large packet and return an ICMP Packet Too Big message or > perform > link-specific fragmentation (also known as "link adaptation") at a > layer below IPv6. This latter category of links is often > performance-challenged to accommodate steady-state link-specific > fragmentation to the point that it would be highly desirable to push > the fragmentation burden back to the IPv6 source. A common case > that > exhibits these link characteristics is seen for IPv6-within-IP > tunnels. This document therefore proposes an update to the base > IPv6 > specification to support link adaptation avoidance. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-generic-6man-tunfrag-02 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-generic-6man-tunfrag-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Thu Jul 12 08:39:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417FF21F8707 for ; Thu, 12 Jul 2012 08:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EVyD2PTiK5D for ; Thu, 12 Jul 2012 08:39:39 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4F221F8701 for ; Thu, 12 Jul 2012 08:39:39 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6CFeCeT026410 for ; Thu, 12 Jul 2012 10:40:12 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6CFeBQW026392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jul 2012 10:40:12 -0500 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6CFeB5f030459; Thu, 12 Jul 2012 08:40:11 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6CFeBlE030452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 Jul 2012 08:40:11 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Thu, 12 Jul 2012 08:40:11 -0700 From: "Templin, Fred L" To: Dan Wing , "ipv6@ietf.org" Date: Thu, 12 Jul 2012 08:40:09 -0700 Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Topic: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqAATul3YAAHogyEA== Message-ID: References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> <00db01cd5fca$fe6ed000$fb4c7000$@com> In-Reply-To: <00db01cd5fca$fe6ed000$fb4c7000$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 15:39:40 -0000 Hi Dan, > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, July 11, 2012 6:10 PM > To: Templin, Fred L; ipv6@ietf.org > Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation > Avoidance" >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > > Templin, Fred L > > Sent: Thursday, July 05, 2012 11:31 AM > > To: ipv6@ietf.org > > Subject: New draft: "IPv6 Source Fragmentation for Link Adaptation > > Avoidance" > > > > Hello, > > > > I have posted a new draft that calls for an update to RFC2460. > > The document proposes to enlist the support of IPv6 hosts in > > offloading the burden carried by links that must perform > > link-specific fragmentation/reassembly per RFC2460, Section 5: > > > > "IPv6 requires that every link in the internet have an MTU of 1280 > > octets or greater. On any link that cannot convey a 1280-octet > > packet in one piece, link-specific fragmentation and reassembly must > > be provided at a layer below IPv6." > > > > The draft announcement appears below. Please review and send > > comments to the list. >=20 > The draft adds a paragraph to the IPv6 spec which says, effectively, > if an ICMPv6 PTB is received with a certain MTU, the IPv6 host should > try to send packets of that size. The paragraph is asking the host to treat MTU sizes less than 1280 for IPv6 destinations as an indication of the maximum fragment size it should use, and then use IPv6 fragmentation when sending future packets to the IPv6 destination.=20 > The existing IPv6 specification (RFC2460) and its predecessor (RFC1883) > have an existing paragraph that says something different should happen > when such an IPv6 PTB is received. The existing text says a 1280 > byte packet can be sent, but needs a fragmentation header added. The existing paragraph says: "In response to an IPv6 packet that is sent to an IPv4 destination ..." ^^^^ > How does a host reconcile those two paragraphs, and know which to > do? My proposed paragraph tells what to do for packets sent to *IPv6* destinations, whereas the existing paragraph tells what to do for packets sent to *IPv4* destinations. So, the destination's IP protocol version is used to reconcile the two paragraphs. > Or are you proposing to replace the existing paragraph with > the new paragraph? No; keep it as two paragraphs - i.e., leave the existing paragraph alone. Thanks - Fred fred.l.templin@boeing.com > -d >=20 >=20 >=20 > > Fred > > fred.l.templin@boeing.com > > > > --- > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : IPv6 Source Fragmentation for Link Adaptation > > Avoidance > > Author(s) : Fred L. Templin > > Filename : draft-generic-6man-tunfrag-02.txt > > Pages : 5 > > Date : 2012-07-05 > > > > Abstract: > > IPv6 intentionally deprecates fragmentation by routers in the > > network. Instead, links with restricting MTUs must either drop each > > too-large packet and return an ICMP Packet Too Big message or > > perform > > link-specific fragmentation (also known as "link adaptation") at a > > layer below IPv6. This latter category of links is often > > performance-challenged to accommodate steady-state link-specific > > fragmentation to the point that it would be highly desirable to push > > the fragmentation burden back to the IPv6 source. A common case > > that > > exhibits these link characteristics is seen for IPv6-within-IP > > tunnels. This document therefore proposes an update to the base > > IPv6 > > specification to support link adaptation avoidance. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-generic-6man-tunfrag-02 > > > > A diff from previous version is available at: > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-generic-6man-tunfrag-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- From dwing@cisco.com Thu Jul 12 09:00:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA08B11E80B5 for ; Thu, 12 Jul 2012 09:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3OyrLCTVzbt for ; Thu, 12 Jul 2012 09:00:16 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EC12721F8762 for ; Thu, 12 Jul 2012 09:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6186; q=dns/txt; s=iport; t=1342108849; x=1343318449; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=cEfqhmWnNmWBFKVvLI3evoRgNW1QJM/ZjHhByfz29f4=; b=YTpqR3sdFNIypoR1EcVMQjuA/QDhfSXPbmvM++ZAlImGMsw+0t+6iXy/ qhoE7+SiHyY0mS+ZgY7B93B1c2RBw+63j8lJz+8C6gpHwghhqwpyAuOki k0KXd2z+yVyitlrsnV75wOqBpCqxn0W6OgrJBNoSeFlkoZwqW2+vvlDCS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAIv0/k+rRDoH/2dsb2JhbABFqFaPM4EHgiABAQEDAQEBAQUKARcQLQcXAQMCCQ8CBAEBKAcZDhUKCQgBAQQBEgkCF4dlBQydSaAri0CFfAOIS4UFiHyJdYMZgWaCfw X-IronPort-AV: E=Sophos;i="4.77,573,1336348800"; d="scan'208";a="48635696" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 12 Jul 2012 16:00:39 +0000 Received: from dwingWS ([10.21.71.92]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6CG0dYt002367; Thu, 12 Jul 2012 16:00:39 GMT From: "Dan Wing" To: "'Templin, Fred L'" , References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> <00db01cd5fca$fe6ed000$fb4c7000$@com> In-Reply-To: Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Date: Thu, 12 Jul 2012 09:00:39 -0700 Message-ID: <01db01cd6047$7ba38170$72ea8450$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqAATul3YAAHogyEAAAqYKQ Content-Language: en-us X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 16:00:18 -0000 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Thursday, July 12, 2012 8:40 AM > To: Dan Wing; ipv6@ietf.org > Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation > Avoidance" > > Hi Dan, > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Wednesday, July 11, 2012 6:10 PM > > To: Templin, Fred L; ipv6@ietf.org > > Subject: RE: New draft: "IPv6 Source Fragmentation for Link > Adaptation > > Avoidance" > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > > > Templin, Fred L > > > Sent: Thursday, July 05, 2012 11:31 AM > > > To: ipv6@ietf.org > > > Subject: New draft: "IPv6 Source Fragmentation for Link Adaptation > > > Avoidance" > > > > > > Hello, > > > > > > I have posted a new draft that calls for an update to RFC2460. > > > The document proposes to enlist the support of IPv6 hosts in > > > offloading the burden carried by links that must perform > > > link-specific fragmentation/reassembly per RFC2460, Section 5: > > > > > > "IPv6 requires that every link in the internet have an MTU of > 1280 > > > octets or greater. On any link that cannot convey a 1280-octet > > > packet in one piece, link-specific fragmentation and reassembly > must > > > be provided at a layer below IPv6." > > > > > > The draft announcement appears below. Please review and send > > > comments to the list. > > > > The draft adds a paragraph to the IPv6 spec which says, effectively, > > if an ICMPv6 PTB is received with a certain MTU, the IPv6 host should > > try to send packets of that size. > > The paragraph is asking the host to treat MTU sizes less > than 1280 for IPv6 destinations as an indication of the > maximum fragment size it should use, and then use IPv6 > fragmentation when sending future packets to the IPv6 > destination. > > > The existing IPv6 specification (RFC2460) and its predecessor > (RFC1883) > > have an existing paragraph that says something different should > happen > > when such an IPv6 PTB is received. The existing text says a 1280 > > byte packet can be sent, but needs a fragmentation header added. > > The existing paragraph says: "In response to an IPv6 packet > that is sent to an IPv4 destination ..." > ^^^^ > > > How does a host reconcile those two paragraphs, and know which to > > do? > > My proposed paragraph tells what to do for packets sent > to *IPv6* destinations, whereas the existing paragraph > tells what to do for packets sent to *IPv4* destinations. > So, the destination's IP protocol version is used to > reconcile the two paragraphs. I can see two ways to detect that -- the NAT64 well known prefix or detection with draft-ietf-behave-nat64-discovery-heuristic being used to determine if the destination is IPv4 or IPv6. Neither of those are in IP stacks today. That is, existing stacks -- if they follow that last paragraph in Section 5 of RFC2460 at all -- simply treat all destinations the same and do not discriminate that it is "an IPv4 destination". I could sortof see that working for translators within the same administrative domain, where those two techniques are viable (those two techniques being WKP and NAT64 discovery heuristic). But translators that are in other networks cannot be detected using those techniques. -d > > Or are you proposing to replace the existing paragraph with > > the new paragraph? > > No; keep it as two paragraphs - i.e., leave the existing > paragraph alone. > > Thanks - Fred > fred.l.templin@boeing.com > > > -d > > > > > > > > > Fred > > > fred.l.templin@boeing.com > > > > > > --- > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : IPv6 Source Fragmentation for Link Adaptation > > > Avoidance > > > Author(s) : Fred L. Templin > > > Filename : draft-generic-6man-tunfrag-02.txt > > > Pages : 5 > > > Date : 2012-07-05 > > > > > > Abstract: > > > IPv6 intentionally deprecates fragmentation by routers in the > > > network. Instead, links with restricting MTUs must either drop > each > > > too-large packet and return an ICMP Packet Too Big message or > > > perform > > > link-specific fragmentation (also known as "link adaptation") at > a > > > layer below IPv6. This latter category of links is often > > > performance-challenged to accommodate steady-state link-specific > > > fragmentation to the point that it would be highly desirable to > push > > > the fragmentation burden back to the IPv6 source. A common case > > > that > > > exhibits these link characteristics is seen for IPv6-within-IP > > > tunnels. This document therefore proposes an update to the base > > > IPv6 > > > specification to support link adaptation avoidance. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-generic-6man-tunfrag-02 > > > > > > A diff from previous version is available at: > > > http://tools.ietf.org/rfcdiff?url2=draft-generic-6man-tunfrag-02 > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > ------------------------------------------------------------------- > - > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > ------------------------------------------------------------------- > - From Fred.L.Templin@boeing.com Thu Jul 12 09:36:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE60921F876F for ; Thu, 12 Jul 2012 09:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JwnVbW2h0IX for ; Thu, 12 Jul 2012 09:36:36 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id C221821F872A for ; Thu, 12 Jul 2012 09:36:36 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6CGbAE5002750 for ; Thu, 12 Jul 2012 09:37:10 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6CGb9cQ002745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jul 2012 09:37:09 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6CGb9q4030986; Thu, 12 Jul 2012 11:37:09 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6CGb8Pd030922 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 Jul 2012 11:37:09 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 12 Jul 2012 09:37:07 -0700 From: "Templin, Fred L" To: Dan Wing , "ipv6@ietf.org" Date: Thu, 12 Jul 2012 09:37:07 -0700 Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Topic: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqAATul3YAAHogyEAAAqYKQAAFsgDA= Message-ID: References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> <00db01cd5fca$fe6ed000$fb4c7000$@com> <01db01cd6047$7ba38170$72ea8450$@com> In-Reply-To: <01db01cd6047$7ba38170$72ea8450$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 16:36:37 -0000 Hi Dan, > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, July 12, 2012 9:01 AM > To: Templin, Fred L; ipv6@ietf.org > Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation > Avoidance" >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Thursday, July 12, 2012 8:40 AM > > To: Dan Wing; ipv6@ietf.org > > Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation > > Avoidance" > > > > Hi Dan, > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Wednesday, July 11, 2012 6:10 PM > > > To: Templin, Fred L; ipv6@ietf.org > > > Subject: RE: New draft: "IPv6 Source Fragmentation for Link > > Adaptation > > > Avoidance" > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf Of > > > > Templin, Fred L > > > > Sent: Thursday, July 05, 2012 11:31 AM > > > > To: ipv6@ietf.org > > > > Subject: New draft: "IPv6 Source Fragmentation for Link Adaptation > > > > Avoidance" > > > > > > > > Hello, > > > > > > > > I have posted a new draft that calls for an update to RFC2460. > > > > The document proposes to enlist the support of IPv6 hosts in > > > > offloading the burden carried by links that must perform > > > > link-specific fragmentation/reassembly per RFC2460, Section 5: > > > > > > > > "IPv6 requires that every link in the internet have an MTU of > > 1280 > > > > octets or greater. On any link that cannot convey a 1280-octet > > > > packet in one piece, link-specific fragmentation and reassembly > > must > > > > be provided at a layer below IPv6." > > > > > > > > The draft announcement appears below. Please review and send > > > > comments to the list. > > > > > > The draft adds a paragraph to the IPv6 spec which says, effectively, > > > if an ICMPv6 PTB is received with a certain MTU, the IPv6 host should > > > try to send packets of that size. > > > > The paragraph is asking the host to treat MTU sizes less > > than 1280 for IPv6 destinations as an indication of the > > maximum fragment size it should use, and then use IPv6 > > fragmentation when sending future packets to the IPv6 > > destination. > > > > > The existing IPv6 specification (RFC2460) and its predecessor > > (RFC1883) > > > have an existing paragraph that says something different should > > happen > > > when such an IPv6 PTB is received. The existing text says a 1280 > > > byte packet can be sent, but needs a fragmentation header added. > > > > The existing paragraph says: "In response to an IPv6 packet > > that is sent to an IPv4 destination ..." > > ^^^^ > > > > > How does a host reconcile those two paragraphs, and know which to > > > do? > > > > My proposed paragraph tells what to do for packets sent > > to *IPv6* destinations, whereas the existing paragraph > > tells what to do for packets sent to *IPv4* destinations. > > So, the destination's IP protocol version is used to > > reconcile the two paragraphs. >=20 > I can see two ways to detect that -- the NAT64 well known > prefix or detection with draft-ietf-behave-nat64-discovery-heuristic > being used to determine if the destination is IPv4 or IPv6. > Neither of those are in IP stacks today. That is, existing > stacks -- if they follow that last paragraph in Section 5 > of RFC2460 at all -- simply treat all destinations the same > and do not discriminate that it is "an IPv4 destination". >=20 > I could sortof see that working for translators within the > same administrative domain, where those two techniques > are viable (those two techniques being WKP and NAT64 > discovery heuristic). >=20 > But translators that are in other networks cannot be > detected using those techniques. Thanks for clarifying that. But then, maybe we need to take a closer look at the final paragraph of Section 5 of RFC2460. It goes on to say that: "In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments." But, the IPv6 node has no way of knowing whether the IPv4 destination is capable of reassembling as much as 1280, because IPv4 nodes are only required to reassemble 576 at the minimum. Also, the IPv6 Identification value chosen by the host would not be fully reflected in the IPv4 Identification value produced by the translator, since there is no way to squeeze 32 bits into 16. So then, maybe what my draft should be shooting for is a replacement of the final paragraph of Section 5? Thanks - Fred fred.l.templin@boeing.com > -d >=20 > > > Or are you proposing to replace the existing paragraph with > > > the new paragraph? > > > > No; keep it as two paragraphs - i.e., leave the existing > > paragraph alone. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -d > > > > > > > > > > > > > Fred > > > > fred.l.templin@boeing.com > > > > > > > > --- > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > > > > > Title : IPv6 Source Fragmentation for Link > Adaptation > > > > Avoidance > > > > Author(s) : Fred L. Templin > > > > Filename : draft-generic-6man-tunfrag-02.txt > > > > Pages : 5 > > > > Date : 2012-07-05 > > > > > > > > Abstract: > > > > IPv6 intentionally deprecates fragmentation by routers in the > > > > network. Instead, links with restricting MTUs must either drop > > each > > > > too-large packet and return an ICMP Packet Too Big message or > > > > perform > > > > link-specific fragmentation (also known as "link adaptation") at > > a > > > > layer below IPv6. This latter category of links is often > > > > performance-challenged to accommodate steady-state link-specific > > > > fragmentation to the point that it would be highly desirable to > > push > > > > the fragmentation burden back to the IPv6 source. A common case > > > > that > > > > exhibits these link characteristics is seen for IPv6-within-IP > > > > tunnels. This document therefore proposes an update to the base > > > > IPv6 > > > > specification to support link adaptation avoidance. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag > > > > > > > > There's also a htmlized version available at: > > > > http://tools.ietf.org/html/draft-generic-6man-tunfrag-02 > > > > > > > > A diff from previous version is available at: > > > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-generic-6man-tunfrag-02 > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > ------------------------------------------------------------------- > > - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > ------------------------------------------------------------------- > > - From dwing@cisco.com Thu Jul 12 10:58:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81AE21F85C7 for ; Thu, 12 Jul 2012 10:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.484 X-Spam-Level: X-Spam-Status: No, score=-110.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blHtDbmrZzh6 for ; Thu, 12 Jul 2012 10:58:28 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C153621F8570 for ; Thu, 12 Jul 2012 10:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=11406; q=dns/txt; s=iport; t=1342115929; x=1343325529; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=k2nEBS4OC8xhn8k7NJV4C+GKFAiu2EveCrQguC0YXzs=; b=dGBRO3z5IaQFBItVkZrkrMRyScvfEE/G57qSftJLJakSH0c5kkhUFNse u+qjUfaqvD6Vo8VuKDT67t2l4WRP6DU0JbRnFIRewG8OnNFTT3nUy4Zec DUwSkXY5HBFQGct1EtuJ937FS5Yc10a3Vw+VjO5mu97p+jisoOkdt7So9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFACkP/0+rRDoG/2dsb2JhbABFqFmPM4EHgiABAQEDAQEBAQUKARQDEC0HEAcBAwIJDwIEAQEoBxkOFQoJCAIEARIJAheHZQUMnVygJotAhXwDiEuFBYh8iXWDGYFmgn8 X-IronPort-AV: E=Sophos;i="4.77,575,1336348800"; d="scan'208";a="51675769" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 12 Jul 2012 17:58:46 +0000 Received: from dwingWS ([10.21.71.92]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6CHwkUF027531; Thu, 12 Jul 2012 17:58:46 GMT From: "Dan Wing" To: "'Templin, Fred L'" , References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> <00db01cd5fca$fe6ed000$fb4c7000$@com> <01db01cd6047$7ba38170$72ea8450$@com> In-Reply-To: Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Date: Thu, 12 Jul 2012 10:58:46 -0700 Message-ID: <02ba01cd6057$fbbab170$f3301450$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqAATul3YAAHogyEAAAqYKQAAFsgDAAAlqBkA== Content-Language: en-us X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 17:58:29 -0000 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Thursday, July 12, 2012 9:37 AM > To: Dan Wing; ipv6@ietf.org > Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation > Avoidance" > > Hi Dan, > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Thursday, July 12, 2012 9:01 AM > > To: Templin, Fred L; ipv6@ietf.org > > Subject: RE: New draft: "IPv6 Source Fragmentation for Link > Adaptation > > Avoidance" > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Thursday, July 12, 2012 8:40 AM > > > To: Dan Wing; ipv6@ietf.org > > > Subject: RE: New draft: "IPv6 Source Fragmentation for Link > Adaptation > > > Avoidance" > > > > > > Hi Dan, > > > > > > > -----Original Message----- > > > > From: Dan Wing [mailto:dwing@cisco.com] > > > > Sent: Wednesday, July 11, 2012 6:10 PM > > > > To: Templin, Fred L; ipv6@ietf.org > > > > Subject: RE: New draft: "IPv6 Source Fragmentation for Link > > > Adaptation > > > > Avoidance" > > > > > > > > > -----Original Message----- > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > > Behalf Of > > > > > Templin, Fred L > > > > > Sent: Thursday, July 05, 2012 11:31 AM > > > > > To: ipv6@ietf.org > > > > > Subject: New draft: "IPv6 Source Fragmentation for Link > Adaptation > > > > > Avoidance" > > > > > > > > > > Hello, > > > > > > > > > > I have posted a new draft that calls for an update to RFC2460. > > > > > The document proposes to enlist the support of IPv6 hosts in > > > > > offloading the burden carried by links that must perform > > > > > link-specific fragmentation/reassembly per RFC2460, Section 5: > > > > > > > > > > "IPv6 requires that every link in the internet have an MTU > of > > > 1280 > > > > > octets or greater. On any link that cannot convey a 1280- > octet > > > > > packet in one piece, link-specific fragmentation and > reassembly > > > must > > > > > be provided at a layer below IPv6." > > > > > > > > > > The draft announcement appears below. Please review and send > > > > > comments to the list. > > > > > > > > The draft adds a paragraph to the IPv6 spec which says, > effectively, > > > > if an ICMPv6 PTB is received with a certain MTU, the IPv6 host > should > > > > try to send packets of that size. > > > > > > The paragraph is asking the host to treat MTU sizes less > > > than 1280 for IPv6 destinations as an indication of the > > > maximum fragment size it should use, and then use IPv6 > > > fragmentation when sending future packets to the IPv6 > > > destination. > > > > > > > The existing IPv6 specification (RFC2460) and its predecessor > > > (RFC1883) > > > > have an existing paragraph that says something different should > > > happen > > > > when such an IPv6 PTB is received. The existing text says a 1280 > > > > byte packet can be sent, but needs a fragmentation header added. > > > > > > The existing paragraph says: "In response to an IPv6 packet > > > that is sent to an IPv4 destination ..." > > > ^^^^ > > > > > > > How does a host reconcile those two paragraphs, and know which to > > > > do? > > > > > > My proposed paragraph tells what to do for packets sent > > > to *IPv6* destinations, whereas the existing paragraph > > > tells what to do for packets sent to *IPv4* destinations. > > > So, the destination's IP protocol version is used to > > > reconcile the two paragraphs. > > > > I can see two ways to detect that -- the NAT64 well known > > prefix or detection with draft-ietf-behave-nat64-discovery-heuristic > > being used to determine if the destination is IPv4 or IPv6. > > Neither of those are in IP stacks today. That is, existing > > stacks -- if they follow that last paragraph in Section 5 > > of RFC2460 at all -- simply treat all destinations the same > > and do not discriminate that it is "an IPv4 destination". > > > > I could sortof see that working for translators within the > > same administrative domain, where those two techniques > > are viable (those two techniques being WKP and NAT64 > > discovery heuristic). > > > > But translators that are in other networks cannot be > > detected using those techniques. > > Thanks for clarifying that. But then, maybe we need to > take a closer look at the final paragraph of Section 5 > of RFC2460. It goes on to say that: > > "In that case, the IPv6 node > is not required to reduce the size of subsequent packets to less > than > 1280, but must include a Fragment header in those packets so that > the > IPv6-to-IPv4 translating router can obtain a suitable Identification > value to use in resulting IPv4 fragments." > > But, the IPv6 node has no way of knowing whether the > IPv4 destination is capable of reassembling as much > as 1280, because IPv4 nodes are only required to > reassemble 576 at the minimum. Yep. That problem is also pointed out in draft-ietf-intarea-ipv4-id-update. That final paragraph in Section 5 of RFC2460 is nearly identical to the paragraph in its predecssors, RFC1883. In RFC1883 the IPv6 minimum MTU was 576 (which matched IPv4's reassembly minimum). One of the many changes between RFC1883 and RFC2460 was changing IPv6's minimum MTU from 576 to 1280. See http://tools.ietf.org/rfcdiff?url1=rfc1883.txt&url2=rfc2460.txt#diff0059 I believe this MTU mismatch between IPv6 and IPv4 was not deeply considered when RFC2460 was updated from MTU 576 to 1280. But, I wasn't there at the time. No matter how it occurred, we have two immovable objects at this point in time. > Also, the IPv6 Identification value chosen by the host would > not be fully reflected in the IPv4 Identification value > produced by the translator, since there is no way > to squeeze 32 bits into 16. Sure. But there is also no encouragement in RFC2460 for the IPv6 host to try to make the lower 16 bits unique. A problem that the IPv6 host cannot overcome is that the IPv4 address might be shared amongst several IPv6 hosts. This problem is described in draft-ietf-intarea-ipv4-id-update, and does not solely affect IPv6->IPv4 translation, but any sort of IPv4 address sharing. I don't see a way to solve that with stateless translation. And solving that at scale with stateful translation appears to be a significant challenge. > So then, maybe what my draft should be shooting for > is a replacement of the final paragraph of Section 5? That may well help towards fixing the problem identified by draft-ietf-intarea-ipv4-id-update related to stateless IPv6/IPv4 translators. It still won't be a perfect fix, but it can improve the situation. Returning an ICMP message back to the IPv6 node, as draft-generic-6man-tunfrag proposes, hinting that the IPv4 address is shared, perhaps combined with ways to assign bits to (what will become) the IPv4 IPID field, might be an avenue worth considering. RFC4884 could be used to convey which fragmentation behavior is desired. The engineering effort to improve this situation is closely tied to how severe the problem really is, and how often we hit the small MTU layer 2 links (that draft-generic-6man-tunfrag is trying to fix) and how often we hit IPv6/IPv4 translators (that the last paragraph of Section 5 of RFC2460 is trying to fix, but doesn't quite handle well with stateless IPv6/IPv4 translators). Myself, I am frustrated with layer 2 networks that have smaller than 1500 byte MTUs, because we know anything that looks like Ethernet succeeds (even if it isn't Ethernet, e.g., WiFi), and technologies that don't look like Ethernet have enjoyed less success. Can we expect those networks to fail in the market, or to look enough like Ethernet that IP works well on top of them, making draft-generic-6man-tunfrag unnecessary? There is a similar question for IPv6/IPv4 translators -- will they persist long enough to make the engineering effort to improve that last paragraph in Section 5 of RFC2460 worth while, and will we see deployment in IPv6 hosts while there are still IPv6/IPv4 translators? -d > Thanks - Fred > fred.l.templin@boeing.com > > > -d > > > > > > Or are you proposing to replace the existing paragraph with > > > > the new paragraph? > > > > > > No; keep it as two paragraphs - i.e., leave the existing > > > paragraph alone. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > -d > > > > > > > > > > > > > > > > > Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > --- > > > > > A New Internet-Draft is available from the on-line Internet- > Drafts > > > > > directories. > > > > > > > > > > > > > > > Title : IPv6 Source Fragmentation for Link > > Adaptation > > > > > Avoidance > > > > > Author(s) : Fred L. Templin > > > > > Filename : draft-generic-6man-tunfrag-02.txt > > > > > Pages : 5 > > > > > Date : 2012-07-05 > > > > > > > > > > Abstract: > > > > > IPv6 intentionally deprecates fragmentation by routers in > the > > > > > network. Instead, links with restricting MTUs must either > drop > > > each > > > > > too-large packet and return an ICMP Packet Too Big message > or > > > > > perform > > > > > link-specific fragmentation (also known as "link > adaptation") at > > > a > > > > > layer below IPv6. This latter category of links is often > > > > > performance-challenged to accommodate steady-state link- > specific > > > > > fragmentation to the point that it would be highly desirable > to > > > push > > > > > the fragmentation burden back to the IPv6 source. A common > case > > > > > that > > > > > exhibits these link characteristics is seen for IPv6-within- > IP > > > > > tunnels. This document therefore proposes an update to the > base > > > > > IPv6 > > > > > specification to support link adaptation avoidance. > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag > > > > > > > > > > There's also a htmlized version available at: > > > > > http://tools.ietf.org/html/draft-generic-6man-tunfrag-02 > > > > > > > > > > A diff from previous version is available at: > > > > > http://tools.ietf.org/rfcdiff?url2=draft-generic-6man-tunfrag- > 02 > > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > _______________________________________________ > > > > > I-D-Announce mailing list > > > > > I-D-Announce@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > --------------------------------------------------------------- > ---- > > > - > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > --------------------------------------------------------------- > ---- > > > - From dthaler@microsoft.com Thu Jul 12 12:15:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684AF11E80FF for ; Thu, 12 Jul 2012 12:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.7 X-Spam-Level: X-Spam-Status: No, score=-103.7 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jslADLSfPGcJ for ; Thu, 12 Jul 2012 12:15:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 32A6D11E80E9 for ; Thu, 12 Jul 2012 12:15:52 -0700 (PDT) Received: from mail53-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Jul 2012 19:16:23 +0000 Received: from mail53-am1 (localhost [127.0.0.1]) by mail53-am1-R.bigfish.com (Postfix) with ESMTP id 1BCCC4A04B9; Thu, 12 Jul 2012 19:16:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zf7Iz9371I936eI542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail53-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail53-am1 (localhost.localdomain [127.0.0.1]) by mail53-am1 (MessageSwitch) id 1342120581362345_3605; Thu, 12 Jul 2012 19:16:21 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.241]) by mail53-am1.bigfish.com (Postfix) with ESMTP id 5479B2004A; Thu, 12 Jul 2012 19:16:21 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Jul 2012 19:16:20 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 12 Jul 2012 19:16:15 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.79]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Thu, 12 Jul 2012 12:16:15 -0700 From: Dave Thaler To: Brian E Carpenter , 6man Subject: RE: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Thread-Topic: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Thread-Index: AQHNX2DzeUGxz0UIhkC9N9TBFxf2fZcmBI2A Date: Thu, 12 Jul 2012 19:16:15 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <4FFD71D7.4070209@gmail.com> In-Reply-To: <4FFD71D7.4070209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:15:53 -0000 Brian and Bob already heard this but wanted list discussion before making any changes to the doc, so posting publically... Section 3 states: > For example: > > http://[fe80::a%en1] > > It seems that modern browsers can be adapted to parse this because it > is inside of the "[" "]"'s. =20 The sentence above isn't true (claim is way too broad). The counter exampl= e is that IE is a modern browser. It cannot "be adapted" to treat http://[fe80::1%251]/ as fe80::1%251 without breaking backwards=20 compatibility with all the code that treats it as fe80::1%1. > This would permit the output of commands > like ping6 -w ff02::1%en1 to be "cut and pasted" into a browser > address bar. The sentence above is misleading, because the use of the "-" syntax specified by this draft would already permit the output of commands like ping6 -w ff02::1-en1 to be "cut and pasted" into a browser address bar. The "would permit" implies that it wouldn't otherwise permit, which is not true with draft -02. > Consequently this document recommends that browsers > support this syntax in addition to the formal URI syntax defined > above. The above sentence is harmful. =20 Consider http://[fe80::1%251]/ Is the embedded address fe80::1%1 or fe80::1%251 ? In Firefox apparently it's the latter, and in IE it's the former. I see no reason to "recommend" one over the other, especially given=20 that the market share (i.e. how commonly deployed) would be in favor=20 of fe80::1%1 so you can't take that as an argument for the latter. Because it's completely unpredictable without having=20 browser-specific knowledge which I think is inappropriate here, I=20 don't think it should recommend either one. Making a recommendation in this document will just increase the likelihood of interoperability problems as people start passing URIs like "http://[fe80::1%251]/" into APIs and files without knowing how it'll be interpreted by the broad base of already deployed apps and libraries. We don't want to make the situation worse, and this sort of recommendation just makes the current bad situation worse. -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Wednesday, July 11, 2012 5:30 AM > To: 6man > Subject: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] >=20 > This version includes changes for the recent comments from Dave Thaler. > It needs a check by the WG that we still have consensus. >=20 > We did not delete one sentence in section 3 that Dave objects to: > "Consequently this document recommends that browsers support this > syntax in addition to the formal URI syntax defined above." >=20 > The URI list raised no objection to the formal syntax change. >=20 > Brian + Bob (as author) >=20 > -------- Original Message -------- > Subject: I-D Action: draft-ietf-6man-uri-zoneid-02.txt > Date: Wed, 11 Jul 2012 05:23:52 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ipv6@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Maintenance Working Group of the I= ETF. >=20 > Title : Representing IPv6 Zone Identifiers in Address Literals= and > Uniform Resource Identifiers > Author(s) : Brian Carpenter > Robert M. Hinden > Filename : draft-ietf-6man-uri-zoneid-02.txt > Pages : 10 > Date : 2012-07-11 >=20 > Abstract: > This document describes how the Zone Identifier of an IPv6 scoped > address can be represented in a a literal IPv6 address and in a > Uniform Resource Identifier that includes such a literal address. It > updates RFC 3986 and RFC 4007 accordingly. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-02 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-uri-zoneid-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From simon.perreault@viagenie.ca Thu Jul 12 12:47:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFFF21F8688 for ; Thu, 12 Jul 2012 12:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSMjOofeq7J4 for ; Thu, 12 Jul 2012 12:47:13 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 427C221F861A for ; Thu, 12 Jul 2012 12:47:13 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 052D4414A7 for ; Thu, 12 Jul 2012 15:47:46 -0400 (EDT) Message-ID: <4FFF29E2.6090909@viagenie.ca> Date: Thu, 12 Jul 2012 15:47:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:47:17 -0000 On 07/12/2012 03:16 PM, Dave Thaler wrote: > Because it's completely unpredictable without having > browser-specific knowledge which I think is inappropriate here, I > don't think it should recommend either one. Making a recommendation > in this document will just increase the likelihood of interoperability > problems as people start passing URIs like "http://[fe80::1%251]/" > into APIs and files without knowing how it'll be interpreted by the > broad base of already deployed apps and libraries. We don't want > to make the situation worse, and this sort of recommendation just > makes the current bad situation worse. Suggestion: On input, applications MUST accept the formal syntax and MAY accept another syntax. On output, applications MUST use the formal syntax and MUST NOT use another syntax. For example, when a user pastes "http://[fe80::1%251]", the browser interprets however it wants, turns it into either "http://[fe80::1-251]" or "http://[fe80::1-1]", and displays that in the address bar. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Fred.L.Templin@boeing.com Thu Jul 12 13:01:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57EF21F86EA for ; Thu, 12 Jul 2012 13:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2Ro17yRQzTD for ; Thu, 12 Jul 2012 13:01:40 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAB921F86E8 for ; Thu, 12 Jul 2012 13:01:39 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6CK2D0m019636 for ; Thu, 12 Jul 2012 15:02:13 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6CK2Dng019632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jul 2012 15:02:13 -0500 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6CK2DN2016644; Thu, 12 Jul 2012 15:02:13 -0500 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6CK2Cn5016261 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 Jul 2012 15:02:13 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Thu, 12 Jul 2012 13:02:12 -0700 From: "Templin, Fred L" To: Dan Wing , "ipv6@ietf.org" Date: Thu, 12 Jul 2012 13:02:10 -0700 Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Topic: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqAATul3YAAHogyEAAAqYKQAAFsgDAAAlqBkAAExMAg Message-ID: References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> <00db01cd5fca$fe6ed000$fb4c7000$@com> <01db01cd6047$7ba38170$72ea8450$@com> <02ba01cd6057$fbbab170$f3301450$@com> In-Reply-To: <02ba01cd6057$fbbab170$f3301450$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:01:40 -0000 Hi Dan, > The engineering effort to improve this situation is closely tied > to how severe the problem really is, and how often we hit the > small MTU layer 2 links (that draft-generic-6man-tunfrag is > trying to fix) and how often we hit IPv6/IPv4 translators (that > the last paragraph of Section 5 of RFC2460 is trying to fix, but > doesn't quite handle well with stateless IPv6/IPv4 translators). >=20 > Myself, I am frustrated with layer 2 networks that have smaller > than 1500 byte MTUs, because we know anything that looks like > Ethernet succeeds (even if it isn't Ethernet, e.g., WiFi), and > technologies that don't look like Ethernet have enjoyed less > success. Can we expect those networks to fail in the market, > or to look enough like Ethernet that IP works well on top of > them, making draft-generic-6man-tunfrag unnecessary? There > is a similar question for IPv6/IPv4 translators -- will they > persist long enough to make the engineering effort to improve > that last paragraph in Section 5 of RFC2460 worth while, and > will we see deployment in IPv6 hosts while there are still > IPv6/IPv4 translators? About this, one thing I think we can agree on is that the value 1280 is in no way significant to IPv4 nodes. So, the final paragraph in Section 5 of RFC2460 might just as well be adjusted to say that the node is not required to reduce the size of its subsequent packets to less than 1500 bytes (not 1280). Thanks - Fred From Fred.L.Templin@boeing.com Thu Jul 12 14:00:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F50411E80CF for ; Thu, 12 Jul 2012 14:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28bJg9kdNnl0 for ; Thu, 12 Jul 2012 14:00:38 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4111E8103 for ; Thu, 12 Jul 2012 14:00:38 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6CL1C38018202 for ; Thu, 12 Jul 2012 16:01:12 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6CL1BI1018197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jul 2012 16:01:11 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6CL1Asi011749; Thu, 12 Jul 2012 14:01:10 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6CL1A57011704 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 Jul 2012 14:01:10 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Thu, 12 Jul 2012 14:01:09 -0700 From: "Templin, Fred L" To: Dan Wing , "ipv6@ietf.org" Date: Thu, 12 Jul 2012 14:01:08 -0700 Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Topic: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance" Thread-Index: Ac1WNYo/0OvDVERIS26CDhdrdE+GHwEpSHqAATul3YAAHogyEAAAqYKQAAFsgDAAAlqBkAAG6bQg Message-ID: References: <20120629202644.28011.19919.idtracker@ietfa.amsl.com> <00db01cd5fca$fe6ed000$fb4c7000$@com> <01db01cd6047$7ba38170$72ea8450$@com> <02ba01cd6057$fbbab170$f3301450$@com> In-Reply-To: <02ba01cd6057$fbbab170$f3301450$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 21:00:39 -0000 Hi Dan, > The engineering effort to improve this situation is closely tied > to how severe the problem really is, and how often we hit the > small MTU layer 2 links (that draft-generic-6man-tunfrag is > trying to fix) and how often we hit IPv6/IPv4 translators (that > the last paragraph of Section 5 of RFC2460 is trying to fix, but > doesn't quite handle well with stateless IPv6/IPv4 translators). >=20 > Myself, I am frustrated with layer 2 networks that have smaller > than 1500 byte MTUs, because we know anything that looks like > Ethernet succeeds (even if it isn't Ethernet, e.g., WiFi), and > technologies that don't look like Ethernet have enjoyed less > success. Can we expect those networks to fail in the market, > or to look enough like Ethernet that IP works well on top of > them, making draft-generic-6man-tunfrag unnecessary? There > is a similar question for IPv6/IPv4 translators -- will they > persist long enough to make the engineering effort to improve > that last paragraph in Section 5 of RFC2460 worth while, and > will we see deployment in IPv6 hosts while there are still > IPv6/IPv4 translators? One other thing to note is that, while IPv6/IPv4 translators may not be around long enough to matter, IPv6-over-IP tunnels will be around for the long term. And, encapsulation always reduces the size of the available MTU (to (1500-HLEN) in the case of Ethernet). Since even ICMPv6 PMTUD messages may be lost, and since Ethernet MTUs prevail, we really need to find a way to get tunnels to configure an MTU of 1500 or larger. That is the problem space that draft-generic-6man-tunfrag is addressing. Thanks - Fred fred.l.templin@boeing.com From sm@resistor.net Thu Jul 12 15:36:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531F11E80A5 for ; Thu, 12 Jul 2012 15:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU0ITJmz6iO5 for ; Thu, 12 Jul 2012 15:36:47 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE88D11E8098 for ; Thu, 12 Jul 2012 15:36:47 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6CMbFYU002656; Thu, 12 Jul 2012 15:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342132641; bh=vTKbqwg8ekuL95lxzrG4SNYUak04blk6YB0zt6XVGag=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IZ2nd/tYrVYf5scC5wb3ZstremSu2Ghusw6IP0ohiS3Bdh/8c8jR3csQYKHzsdZa+ wTFr2RthX+24k6Wty3tjHj3N/+eWS+4h3J1ma0QuUdca88fSnjeUDxJVJIJ/ya9lDR l6ItUxcnxd678g5coTRfhMGrJ/a85S8TLNNp+ekc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1342132641; i=@resistor.net; bh=vTKbqwg8ekuL95lxzrG4SNYUak04blk6YB0zt6XVGag=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mUxkZtwTankj6Z2namfhjEQext7m479UioXauz/jACRh/l4tsg5CSfPshPjyjEvEd Kdy1VgXyjMr44ZdUtmz1D64MJJ8LKWDkn1FZFrJgLItagcj0WhwUxE8rD+4VDvK8k0 TlHxxRzuhBXfLLXhWnRvRfcuw4vWZ7kPlo5fZbLM= Message-Id: <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Jul 2012 15:34:48 -0700 To: Simon Perreault From: SM Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] In-Reply-To: <4FFF29E2.6090909@viagenie.ca> References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 22:36:50 -0000 Hi Simon, At 12:47 12-07-2012, Simon Perreault wrote: >Suggestion: >On input, applications MUST accept the formal syntax and MAY accept >another syntax. >On output, applications MUST use the formal syntax and MUST NOT use >another syntax. As long as an implementation supports the formal syntax, there is interoperability. Telling people what not to use sounds appropriate if there is a good reason to do so. The requirements seem redundant to me. Regards, -sm From simon.perreault@viagenie.ca Fri Jul 13 05:34:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961C621F8778 for ; Fri, 13 Jul 2012 05:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSlcX4HjWjVE for ; Fri, 13 Jul 2012 05:34:56 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C79AE21F8770 for ; Fri, 13 Jul 2012 05:34:56 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 35F754581E; Fri, 13 Jul 2012 08:35:32 -0400 (EDT) Message-ID: <50001613.2090203@viagenie.ca> Date: Fri, 13 Jul 2012 08:35:31 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: SM Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> In-Reply-To: <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:34:57 -0000 On 07/12/2012 06:34 PM, SM wrote: > Hi Simon, > At 12:47 12-07-2012, Simon Perreault wrote: >> Suggestion: >> On input, applications MUST accept the formal syntax and MAY accept >> another syntax. >> On output, applications MUST use the formal syntax and MUST NOT use >> another syntax. > > As long as an implementation supports the formal syntax, there is > interoperability. Telling people what not to use sounds appropriate if > there is a good reason to do so. The requirements seem redundant to me. Have you heard of Postel's law? (semi joking) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From sm@resistor.net Fri Jul 13 09:08:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0E211E80C1 for ; Fri, 13 Jul 2012 09:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITR-37OfsBg9 for ; Fri, 13 Jul 2012 09:08:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4F11E8091 for ; Fri, 13 Jul 2012 09:08:55 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6DG9PPG019045; Fri, 13 Jul 2012 09:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342195770; bh=xBX/W0HVfN9HcSnHAfilF4M/TdYLNfENTLmSbaD7CrE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kiwqbvc8XfohiJTDj1rC4TrYZ+4mKs6ZkJozAZaY/lILDJiOYOG6KwcoDJ/KW2etK YrX44BhK9ILzN4NarjfK/kCQNM7jPAa01gSQSrNMPR/fRTptf0DYC1P0ERw5NMjoCe khB5AEdsWHW4X2p4BwlWv/F8A99OclCiorvAyzBc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1342195770; i=@resistor.net; bh=xBX/W0HVfN9HcSnHAfilF4M/TdYLNfENTLmSbaD7CrE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wPhmqARkTAQy3mJuwPowjDJdwcJiREK5NIhuLqOeypJqC6hvKeSl36DKmQTmHNNc4 7xQn66WE2C8GZZcbqw5Ns0YDR+SeFG+c+s9+NT/hVhDRdvmSG7JRGw9a9rotmibAQf V3TYvXD7tArTJmGm3m8pB0yx3s8nLQ54YguBW1cE= Message-Id: <6.2.5.6.2.20120713085321.095aaf60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Jul 2012 09:00:57 -0700 To: Simon Perreault From: SM Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] In-Reply-To: <50001613.2090203@viagenie.ca> References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <50001613.2090203@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 16:08:58 -0000 Hi Simon, At 05:35 13-07-2012, Simon Perreault wrote: >Have you heard of Postel's law? I try to be liberal in accepting arguments arguments from by implementers. I am conservative when it comes to usage of RFC 2119 key words. Regards, -sm From simon.perreault@viagenie.ca Fri Jul 13 09:12:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559D411E8091 for ; Fri, 13 Jul 2012 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaBa8KbNJmgv for ; Fri, 13 Jul 2012 09:12:35 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1E96A11E8087 for ; Fri, 13 Jul 2012 09:12:35 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 48952415D6; Fri, 13 Jul 2012 12:13:11 -0400 (EDT) Message-ID: <50004916.4000206@viagenie.ca> Date: Fri, 13 Jul 2012 12:13:10 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: SM Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <50001613.2090203@viagenie.ca> <6.2.5.6.2.20120713085321.095aaf60@resistor.net> In-Reply-To: <6.2.5.6.2.20120713085321.095aaf60@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 16:12:36 -0000 On 07/13/2012 12:00 PM, SM wrote: > Hi Simon, > At 05:35 13-07-2012, Simon Perreault wrote: >> Have you heard of Postel's law? > > I try to be liberal in accepting arguments arguments from by > implementers. My proposal stemmed from Dave Thaler's argument... not sure what you're implying. > I am conservative when it comes to usage of RFC 2119 key > words. The problem with RFCs these days is definitely not that they use too many RFC 2119 key words! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Fred.L.Templin@boeing.com Fri Jul 13 10:25:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7528721F8722 for ; Fri, 13 Jul 2012 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXWioTUDwcw7 for ; Fri, 13 Jul 2012 10:25:03 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8755021F8710 for ; Fri, 13 Jul 2012 10:25:03 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6DHPcHS024191 for ; Fri, 13 Jul 2012 10:25:38 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6DHPbek024182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Jul 2012 10:25:38 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6DHPcPb031676 for ; Fri, 13 Jul 2012 12:25:38 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6DHPcuf031651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 13 Jul 2012 12:25:38 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 13 Jul 2012 10:25:38 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Date: Fri, 13 Jul 2012 10:25:37 -0700 Subject: RFC2460 violation of RFC1122 Thread-Topic: RFC2460 violation of RFC1122 Thread-Index: Ac1hEmwMLtHdYpWrR1OmCc0H7ZCScwAB72nw Message-ID: References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <50001613.2090203@viagenie.ca> <6.2.5.6.2.20120713085321.095aaf60@resistor.net> <50004916.4000206@viagenie.ca> In-Reply-To: <50004916.4000206@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 17:25:04 -0000 Section 5 of RFC2460 states: "In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used." RFC2460 therefore requires the IPv4 destination to be able to reassemble at least 1280 bytes minus 28 (since the translation from an IPv6 header plus fragment header to an IPv4 header incurs a 28 byte size reduction). However, section 3.3.2 of RFC1122 states: "We designate the largest datagram size that can be reassembled by EMTU_R ("Effective MTU to receive"); this is sometimes called the "reassembly buffer size". EMTU_R MUST be greater than or equal to 576, SHOULD be either configurable or indefinite, and SHOULD be greater than or equal to the MTU of the connected network(s)." By assuming an EMTU_R of greater than 576 bytes, RFC2460 is therefore in violation of RFC1122, which could lead to communication failures. How do we reconcile this? Thanks - Fred fred.l.templin@boeing.com From marka@isc.org Sat Jul 14 01:02:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996D521F86DD for ; Sat, 14 Jul 2012 01:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03pKAfaUMTkU for ; Sat, 14 Jul 2012 01:02:51 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D9F4B21F86D4 for ; Sat, 14 Jul 2012 01:02:50 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id CAFE1C950F; Sat, 14 Jul 2012 08:03:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:9d65:d60a:95f3:c3c2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3B73B216C33; Sat, 14 Jul 2012 08:03:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 08CC722675C5; Sat, 14 Jul 2012 18:02:55 +1000 (EST) To: "Templin, Fred L" From: Mark Andrews References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <50001613.2090203@viagenie.ca> <6.2.5.6.2.20120713085321.095aaf60@resistor.net> <50004916.4000206@viagenie.ca> Subject: Re: RFC2460 violation of RFC1122 In-reply-to: Your message of "Fri, 13 Jul 2012 10:25:37 MST." Date: Sat, 14 Jul 2012 18:02:54 +1000 Message-Id: <20120714080255.08CC722675C5@drugs.dv.isc.org> Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 08:02:51 -0000 In message , "Templin, Fred L" writes: > Section 5 of RFC2460 states: > > "In response to an IPv6 packet that is sent to an IPv4 destination > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node > is not required to reduce the size of subsequent packets to less than > 1280, but must include a Fragment header in those packets so that the > IPv6-to-IPv4 translating router can obtain a suitable Identification > value to use in resulting IPv4 fragments. Note that this means the > payload may have to be reduced to 1232 octets (1280 minus 40 for the > IPv6 header and 8 for the Fragment header), and smaller still if > additional extension headers are used." > > RFC2460 therefore requires the IPv4 destination to be able to > reassemble at least 1280 bytes minus 28 (since the translation > from an IPv6 header plus fragment header to an IPv4 header > incurs a 28 byte size reduction). However, section 3.3.2 of > RFC1122 states: > > "We designate the largest datagram size that can be reassembled > by EMTU_R ("Effective MTU to receive"); this is sometimes > called the "reassembly buffer size". EMTU_R MUST be greater > than or equal to 576, SHOULD be either configurable or > indefinite, and SHOULD be greater than or equal to the MTU of > the connected network(s)." > > By assuming an EMTU_R of greater than 576 bytes, RFC2460 > is therefore in violation of RFC1122, which could lead to > communication failures. How do we reconcile this? You live with it. Nobody has said that IPv6 to IPv4 translation will work in all circumstances. > Thanks - Fred > fred.l.templin@boeing.com > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Sat Jul 14 01:41:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7841521F8703 for ; Sat, 14 Jul 2012 01:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.256 X-Spam-Level: X-Spam-Status: No, score=-101.256 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9S-kv7d7ro0 for ; Sat, 14 Jul 2012 01:41:07 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 89CAE21F86F1 for ; Sat, 14 Jul 2012 01:41:07 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1042419wib.13 for ; Sat, 14 Jul 2012 01:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=54XB9rwP1RsQq7spBm8J90DlQCN71djqCO25mZjKLOM=; b=TpKJelNKUSTZwWNC6PWgT1FhsOkqDpkbfmIWKPj0pvc1IJrDufr5dc27wGp7PGmqSV 6CtoHnx54LS+3FcerB4KKhVx4DMxfmSC0EiakVkl4VCMaQIi+p8MpvIYkhcot/mGXae4 LYM2Z99+us0Ig3vdYD/S9zofPQf1O+3+gQoo1lJwJXOboyix525TG2kBSVPr1R/Ij5mY nYvj7Vq2hBNa9GuZ6E7KQlBugrjIBkd6odq/0aa12wyToxowyI8f22PY54il/exnKQiB I+dX3sRzfR2trwEWinEuKVKmve4aUD/j+8JzmxGsTncOX7E5NjwZ4ll6HA5LPds6C7Jv Jsvg== Received: by 10.180.76.135 with SMTP id k7mr3964286wiw.7.1342255305387; Sat, 14 Jul 2012 01:41:45 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-51.as13285.net. [2.102.216.51]) by mx.google.com with ESMTPS id j6sm12248538wiy.4.2012.07.14.01.41.40 (version=SSLv3 cipher=OTHER); Sat, 14 Jul 2012 01:41:41 -0700 (PDT) Message-ID: <500130D4.7050604@gmail.com> Date: Sat, 14 Jul 2012 09:41:56 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: SM Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> In-Reply-To: <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 08:41:08 -0000 On 12/07/2012 23:34, SM wrote: > Hi Simon, > At 12:47 12-07-2012, Simon Perreault wrote: >> Suggestion: >> On input, applications MUST accept the formal syntax and MAY accept >> another syntax. >> On output, applications MUST use the formal syntax and MUST NOT use >> another syntax. > > As long as an implementation supports the formal syntax, there is > interoperability. Telling people what not to use sounds appropriate if > there is a good reason to do so. The requirements seem redundant to me. Also, telling browser implementers what to do has very little chance of success. Speaking only for myself, I'm inclined to accept Dave Thaler's line of argument. The fact that some browsers in the past accepted a raw % and that IE today accepts an escaped % (i.e. %25) makes it very hard to suggest a consistent use of % at all. Maybe we just have to drop this point. Brian From narten@us.ibm.com Sat Jul 14 04:38:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F129121F86A1 for ; Sat, 14 Jul 2012 04:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.377 X-Spam-Level: X-Spam-Status: No, score=-110.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYFTRqN3nTYU for ; Sat, 14 Jul 2012 04:38:47 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id 57CAE21F85F9 for ; Sat, 14 Jul 2012 04:38:46 -0700 (PDT) Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 14 Jul 2012 05:39:24 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 14 Jul 2012 05:38:31 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id D19EC3E4004F for ; Sat, 14 Jul 2012 11:38:30 +0000 (WET) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6EBcU8u161896 for ; Sat, 14 Jul 2012 05:38:30 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6EBcUD1027134 for ; Sat, 14 Jul 2012 05:38:30 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-251-106.mts.ibm.com [9.65.251.106]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q6EBcTsL027119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2012 05:38:30 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q6EBcS6V014019; Sat, 14 Jul 2012 07:38:29 -0400 Message-Id: <201207141138.q6EBcS6V014019@cichlid.raleigh.ibm.com> To: "Templin, Fred L" Subject: Re: RFC2460 violation of RFC1122 In-reply-to: References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <50001613.2090203@viagenie.ca> <6.2.5.6.2.20120713085321.095aaf60@resistor.net> <50004916.4000206@viagenie.ca> Comments: In-reply-to "Templin, Fred L" message dated "Fri, 13 Jul 2012 10:25:37 -0700." Date: Sat, 14 Jul 2012 07:38:28 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12071411-5518-0000-0000-00000608917C Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 11:38:48 -0000 > By assuming an EMTU_R of greater than 576 bytes, RFC2460 > is therefore in violation of RFC1122, which could lead to > communication failures. How do we reconcile this? How many TCP/IP stacks exist today that cannot connect to an Ethernet, and thus, handle 1500 byte datagrams? I suspsect that platforms limited to accepting IP datagrams of max size 576 are gettign to be an extreme edge case these days. Thomas From simon.perreault@viagenie.ca Sat Jul 14 07:38:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D63921F865C for ; Sat, 14 Jul 2012 07:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1LkI3lLP8I1 for ; Sat, 14 Jul 2012 07:38:41 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B3A6221F865A for ; Sat, 14 Jul 2012 07:38:41 -0700 (PDT) Received: from porto.nomis80.org (modemcable212.59-179-173.mc.videotron.ca [173.179.59.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4FD2A415D4; Sat, 14 Jul 2012 10:39:20 -0400 (EDT) Message-ID: <50018497.2050809@viagenie.ca> Date: Sat, 14 Jul 2012 10:39:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> In-Reply-To: <500130D4.7050604@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 14:38:42 -0000 On 07/14/2012 04:41 AM, Brian E Carpenter wrote: > On 12/07/2012 23:34, SM wrote: >> Hi Simon, >> At 12:47 12-07-2012, Simon Perreault wrote: >>> Suggestion: >>> On input, applications MUST accept the formal syntax and MAY accept >>> another syntax. >>> On output, applications MUST use the formal syntax and MUST NOT use >>> another syntax. >> >> As long as an implementation supports the formal syntax, there is >> interoperability. Telling people what not to use sounds appropriate if >> there is a good reason to do so. The requirements seem redundant to me. > > Also, telling browser implementers what to do has very little chance > of success. So obviously browser implementers should be involved in this discussion? We shouldn't be "telling" them, we should be discussing with them. > Speaking only for myself, I'm inclined to accept Dave Thaler's > line of argument. The fact that some browsers in the past accepted > a raw % and that IE today accepts an escaped % (i.e. %25) makes it very > hard to suggest a consistent use of % at all. Maybe we just have to > drop this point. It looks like my suggestion wasn't clear. I too agree with Dave Thaler's argument. I was building on top of it... Not sure how to explain it or formulate it otherwise... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From brian.e.carpenter@gmail.com Sat Jul 14 10:03:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A35521F8686 for ; Sat, 14 Jul 2012 10:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.265 X-Spam-Level: X-Spam-Status: No, score=-101.265 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQaPcbH0mpMJ for ; Sat, 14 Jul 2012 10:03:39 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D873521F8681 for ; Sat, 14 Jul 2012 10:03:38 -0700 (PDT) Received: by weyu54 with SMTP id u54so3068343wey.31 for ; Sat, 14 Jul 2012 10:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xQTelPutaNUJPHiQeNJ5s8QFDxx8HCerQkEO0pvsHN8=; b=GXJfk/52dLrivRt5UO1UQa2sWbXPt84OYbY6PRzVmvUYfmlw9+2DEFLhRQNyaakdzB xCHvt+lJz7i/2EeEF5SeU2TFjekrE6EPXo0X5OaHP5ZhWMXIlqHcWaicMxmOG0YQTTfV jiD61d8yC4lbPSqhMk13T4ypV42inv887vW3hAta3RAUnMmStcMF2BSz1VPXbNcnNp5T g30l/DPcoxU8/1YaAD2swm/r+WQE53pXDWGtqO7LhpR0tu8w2TMEWh5ag1akP14tcMoh Nyw+Mi5+b0jFEmQauFTiTKPeYFVz2qSPWOmlyravuhNSLgHIxAAK1dfaivhTLkXL+/dz G/9g== Received: by 10.180.107.103 with SMTP id hb7mr6430444wib.3.1342285457610; Sat, 14 Jul 2012 10:04:17 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-51.as13285.net. [2.102.216.51]) by mx.google.com with ESMTPS id ex20sm9849392wid.7.2012.07.14.10.04.15 (version=SSLv3 cipher=OTHER); Sat, 14 Jul 2012 10:04:16 -0700 (PDT) Message-ID: <5001A6A1.4020109@gmail.com> Date: Sat, 14 Jul 2012 18:04:33 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> In-Reply-To: <50018497.2050809@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 17:03:39 -0000 On 14/07/2012 15:39, Simon Perreault wrote: > On 07/14/2012 04:41 AM, Brian E Carpenter wrote: >> On 12/07/2012 23:34, SM wrote: >>> Hi Simon, >>> At 12:47 12-07-2012, Simon Perreault wrote: >>>> Suggestion: >>>> On input, applications MUST accept the formal syntax and MAY accept >>>> another syntax. >>>> On output, applications MUST use the formal syntax and MUST NOT use >>>> another syntax. >>> >>> As long as an implementation supports the formal syntax, there is >>> interoperability. Telling people what not to use sounds appropriate if >>> there is a good reason to do so. The requirements seem redundant to me. >> >> Also, telling browser implementers what to do has very little chance >> of success. > > So obviously browser implementers should be involved in this discussion? > We shouldn't be "telling" them, we should be discussing with them. Yes, but I think that's outside the scope of the present draft. I understand that there is forum for such discussions over in W3C-land. > >> Speaking only for myself, I'm inclined to accept Dave Thaler's >> line of argument. The fact that some browsers in the past accepted >> a raw % and that IE today accepts an escaped % (i.e. %25) makes it very >> hard to suggest a consistent use of % at all. Maybe we just have to >> drop this point. > > It looks like my suggestion wasn't clear. I too agree with Dave Thaler's > argument. I was building on top of it... Not sure how to explain it or > formulate it otherwise... I think your suggestion was clear, just not (IMHO) a useful thing to put in an RFC. Brian From simon.perreault@viagenie.ca Sat Jul 14 10:16:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7DF21F8703 for ; Sat, 14 Jul 2012 10:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8ZQIgk8+3aC for ; Sat, 14 Jul 2012 10:16:00 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 89E6221F86CF for ; Sat, 14 Jul 2012 10:16:00 -0700 (PDT) Received: from porto.nomis80.org (modemcable212.59-179-173.mc.videotron.ca [173.179.59.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EFB81415D4; Sat, 14 Jul 2012 13:16:37 -0400 (EDT) Message-ID: <5001A974.3020908@viagenie.ca> Date: Sat, 14 Jul 2012 13:16:36 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:13.0) Gecko/20120712 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> In-Reply-To: <5001A6A1.4020109@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 17:16:01 -0000 On 07/14/12 13:04, Brian E Carpenter wrote: >> So obviously browser implementers should be involved in this discussion? >> We shouldn't be "telling" them, we should be discussing with them. > > Yes, but I think that's outside the scope of the present draft. > I understand that there is forum for such discussions over in > W3C-land. Ah ok. > I think your suggestion was clear, just not (IMHO) a useful thing to > put in an RFC. Thanks, at least that is clear. Simon From brian.e.carpenter@gmail.com Sun Jul 15 00:56:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212EF21F8615 for ; Sun, 15 Jul 2012 00:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.273 X-Spam-Level: X-Spam-Status: No, score=-101.273 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOZZmM5sUW9Z for ; Sun, 15 Jul 2012 00:56:57 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5130A21F860F for ; Sun, 15 Jul 2012 00:56:57 -0700 (PDT) Received: by weyu54 with SMTP id u54so3303386wey.31 for ; Sun, 15 Jul 2012 00:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p1g7MdSWi0HTgp1MiD/I65Hvqj4+8NTgZ1zP9E9+9Cc=; b=TLWhhxqxKbObwFk7KWaIH/lSuESyRi/Oy2AXyrHq0jHxcNT66BHRW6SMxQayxnbvOV TbWsNbz5VhoGW+GQJ7u4AMudNYI8sIsOwEJkABYmITmidrTeeyT8NAG6npFiktqP2C6O 7GSWUpcsPJR24TDnHFDQgOSoco+3MEZNa6uMeQPUkWzoAzaP+PJxo5YQ4YMXW1cnMFRL qQA9UAi58OYXDS4HyV+JqdjTZrG/vQTB5IYRrqTBX3jDpa7RURYL+bn/+2B1NMmqeSEO 5NepFWfqN/lepJQpYgJI7le2aIFScaC2IglBDJ8+EIjXAxt73OUxW2sRMg7QuD/LXE81 PXaQ== Received: by 10.180.96.3 with SMTP id do3mr9523269wib.5.1342339057828; Sun, 15 Jul 2012 00:57:37 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-138.as13285.net. [2.102.216.138]) by mx.google.com with ESMTPS id o2sm21051038wiz.11.2012.07.15.00.57.36 (version=SSLv3 cipher=OTHER); Sun, 15 Jul 2012 00:57:36 -0700 (PDT) Message-ID: <500277EF.9040302@gmail.com> Date: Sun, 15 Jul 2012 08:57:35 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> In-Reply-To: <5001A974.3020908@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 07:56:58 -0000 Without consulting my co-author, here's my personal suggestion for a change to the draft. There's just time to submit an update before the cutoff, if people respond immediately. OLD In recent years, web browsers have evolved considerably and now accept and parse many forms of input that are not a formal URI. Examples of this include host names, search items, bookmarks, search history, etc. For example the Google Chrome browser now calls the "address bar" the "omnibox" [chrome]. The authors believe it is feasible, and very convenient for users, if browsers also allow (in addition to the formal URI syntax defined in this document) a syntax that will enable cut and paste. For example: http://[fe80::a%en1] It seems that modern browsers can be adapted to parse this because it is inside of the "[" "]"'s. This would permit the output of commands like ping6 -w ff02::1%en1 to be "cut and pasted" into a browser address bar. Consequently this document recommends that browsers support this syntax in addition to the formal URI syntax defined above. NEW In recent years, web browsers have evolved considerably and now accept and parse many forms of input that are not a formal URI. Examples of this include host names, search items, bookmarks, search history, etc. For example the Google Chrome browser now calls the "address bar" the "omnibox" [chrome]. Thus, it seems that browsers can take a pragmatic approach to literal addresses including ZoneIDs. Unfortunately there is no way to resolve the discrepancy between the two approaches mentioned above (raw "%" versus "%25") and therefore we recommend general implementation of the new "-" syntax defined by this document. This will allow simple "cut and paste" between tools such as "ping6" and browser address bars. Brian From simon.perreault@viagenie.ca Sun Jul 15 04:33:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B977A21F8473 for ; Sun, 15 Jul 2012 04:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HocjP5PY3WdG for ; Sun, 15 Jul 2012 04:33:54 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9621F8472 for ; Sun, 15 Jul 2012 04:33:54 -0700 (PDT) Received: from porto.nomis80.org (modemcable212.59-179-173.mc.videotron.ca [173.179.59.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EEBDB40384 for ; Sun, 15 Jul 2012 07:34:33 -0400 (EDT) Message-ID: <5002AAC9.1000506@viagenie.ca> Date: Sun, 15 Jul 2012 07:34:33 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> In-Reply-To: <500277EF.9040302@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 11:33:54 -0000 On 07/15/2012 03:57 AM, Brian E Carpenter wrote: > Unfortunately there is no way to resolve the discrepancy between > the two approaches mentioned above (raw "%" versus "%25") and > therefore we recommend general implementation of the new "-" syntax > defined by this document. This will allow simple "cut and paste" > between tools such as "ping6" and browser address bars. How will browser support for "-" have any impact on cut-and-pastability with ping6? ping6 will still be "%"-only, both on input and output, as far as I can see. Same for all apps that operate on addresses, not URLs. My feeling that I'm missing something is growing... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fgont@si6networks.com Sun Jul 15 08:39:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097A621F8631 for ; Sun, 15 Jul 2012 08:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxnjNdwTFuGE for ; Sun, 15 Jul 2012 08:39:15 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2398B21F84C8 for ; Sun, 15 Jul 2012 08:39:15 -0700 (PDT) Received: from 201.230.137.78.rev.vodafone.pt ([78.137.230.201] helo=[10.0.0.114]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SqQvH-0006Bd-TZ; Sun, 15 Jul 2012 17:39:52 +0200 Message-ID: <5002E42E.6040400@si6networks.com> Date: Sun, 15 Jul 2012 16:39:26 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: IPv6 toolkit v1.2 X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 15:39:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, Thought you might be interested: We've released "IPv6 toolkit v1.2": a set of IPv6 security assessment tools that were produced as part of a project I carried out on behalf of the UK CPNI. The tools compile/run on Linux and *BSD (and most likely also on Mac OS). The tarball for version 1.2 of the tool is available at: http://www.si6networks.com/research/ipv6-toolkit-v1.2.tar.gz> Additionally, we have a git repository for the toolkit: This toolkit can be employed to perform assess IPv6 implementations, with respect to a number of issues related to Internet-Drafts I have authored (predictable Fragment IDs, IPv6 host scanning, etc). Any discussion on the tools should take place on the IPv6 hackers (ipv6hackers) mailing-list: Thanks! Best regards, - -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 - -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJQAuQgAAoJEK4lDVUdTnSSQ50P/2lbj4zjvDw2IbBamSN4N48W VEOxJwjq0VwVSovHfhLzStNKdldwot+qt+3I6hN4uX7YmRztyF9bZp6f6GJCqVK6 28ej8iQ7KWDXGxDRKK/8NrjQ2D/4xd28gjWz73XkvK0dfH/4WVSIYO//rnCJUTlF cVI4y2QBK5LfzY4DD3rXwT+H18xu57Fe37unxzRE+ZErKzQbx+3K6p2d+aF7+Xm7 Bi1++xR3tJ52rZdUVq5CigrWGBh8rhQXgqRCuzM7qIGyZIWwhZGbwJ9eR0++zHow YFr/mJmNHYogbQHNVSFfA+P135hUNN6iO+oKPIZxpa0RPrW07cr/x4EK6YaNfQ1n 1ODViYLpY1qIde7y3SaUSb/eZJRnRk/Jl67X8L56v9n4bAXO3mpERZGT1pjnce3Y UnwckbaJg+GdPEGm90eRl/Ll6w2RzVpHQv37cPyuy/NmJUtvoqLtISfxN93zTkQp kafiDcUdW+e0GaxPyZ2OyDQ/0+A5t0lmT/tEo1GAQzRiA6bvxmz3GP8ruGFHRwHk CK1dq+fARBqxj3mMhHf4zgukwqBFASyFrqgU+qcfC9qtVDz2708CbF33knHZAXOU 3mG7q/Vk3UbO3s1ZjiX4pobrokuhR4SeNkpX4Wn/u8tB1xzIhZJwz3uxzJNuwDeq 9tTQXOnijVry3e3/xROd =cF8+ -----END PGP SIGNATURE----- From brian.e.carpenter@gmail.com Sun Jul 15 09:19:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF4021F8568 for ; Sun, 15 Jul 2012 09:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.282 X-Spam-Level: X-Spam-Status: No, score=-101.282 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFCH6qno-Oyd for ; Sun, 15 Jul 2012 09:19:01 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84BE521F8549 for ; Sun, 15 Jul 2012 09:19:01 -0700 (PDT) Received: by weyu54 with SMTP id u54so3476675wey.31 for ; Sun, 15 Jul 2012 09:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iCX+oUXa542P+l7JCH3tGh2IVK3Wx2Zn5J5YQWzZp1U=; b=1EkMWpDrrTpoNdjcR4O9aU78pitDbhBaKkvk9UnEeKBama8yEk9NCAcM3ovWBsbhau 7Y1Lm7ux7cwbFhoEVAh75Vf1LQZPJGRGceCT4Dq+I2dSH9kfO4oeILo2fcxu7cRrFX3g Ed+8THZasvnvrqYLfYX7DncL/SWp3M5+XETN1+DU2nIfJ/V+2syyOFqz0F56pyVegGVl J6mcITjX0RppOgt+p5Op9aMdiCMv8hFh3WRKzgbGwptmfL2cZY6FWCQRYn5RcgmQZ7br TvRaEPIquh/rYEIgUoNKom3DaNRDVoBqVsiSLq3hqCR+EUXYVsKF/jXueB9Fv2uIe99q rgxA== Received: by 10.216.135.217 with SMTP id u67mr1870910wei.115.1342369182914; Sun, 15 Jul 2012 09:19:42 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-138.as13285.net. [2.102.216.138]) by mx.google.com with ESMTPS id fb20sm24387326wid.1.2012.07.15.09.19.40 (version=SSLv3 cipher=OTHER); Sun, 15 Jul 2012 09:19:42 -0700 (PDT) Message-ID: <5002ED98.3030907@gmail.com> Date: Sun, 15 Jul 2012 17:19:36 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> <5002AAC9.1000506@viagenie.ca> In-Reply-To: <5002AAC9.1000506@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 16:19:02 -0000 On 15/07/2012 12:34, Simon Perreault wrote: > On 07/15/2012 03:57 AM, Brian E Carpenter wrote: >> Unfortunately there is no way to resolve the discrepancy between >> the two approaches mentioned above (raw "%" versus "%25") and >> therefore we recommend general implementation of the new "-" syntax >> defined by this document. This will allow simple "cut and paste" >> between tools such as "ping6" and browser address bars. > > How will browser support for "-" have any impact on cut-and-pastability > with ping6? ping6 will still be "%"-only, both on input and output, as > far as I can see. Same for all apps that operate on addresses, not URLs. > > My feeling that I'm missing something is growing... Perhaps the draft is missing something that I imagined to be there... (pause while Brian reads the draft) ... OK, as a result of Dave's comments, we now say: " Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the preceding delimiter of a ZoneID." What we do *not* say is to recommend or suggest that all tools that support RFC 4007 should be updated. Should we also add that? Brian From j.schoenwaelder@jacobs-university.de Sun Jul 15 09:49:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CEE21F8534 for ; Sun, 15 Jul 2012 09:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlfYLlwqKYWf for ; Sun, 15 Jul 2012 09:49:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 81A9E21F852B for ; Sun, 15 Jul 2012 09:49:19 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA4B120BE1; Sun, 15 Jul 2012 18:50:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OgVw05g-3GYv; Sun, 15 Jul 2012 18:50:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F19A2092C; Sun, 15 Jul 2012 18:49:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A3972061F64; Sun, 15 Jul 2012 18:49:57 +0200 (CEST) Date: Sun, 15 Jul 2012 18:49:57 +0200 From: Juergen Schoenwaelder To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Message-ID: <20120715164957.GB685@elstar.local> Mail-Followup-To: Brian E Carpenter , Simon Perreault , ipv6@ietf.org References: <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> <5002AAC9.1000506@viagenie.ca> <5002ED98.3030907@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5002ED98.3030907@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 16:49:20 -0000 On Sun, Jul 15, 2012 at 05:19:36PM +0100, Brian E Carpenter wrote: > ... OK, as a result of Dave's comments, we now say: > > " Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the > preceding delimiter of a ZoneID." > > What we do *not* say is to recommend or suggest that all tools that > support RFC 4007 should be updated. Should we also add that? I believe this direction is wrong. Allowing "-" does not replace "%" anytime soon and hence we simply make the problem worse. The "%" separator is also embedded in other IETF standards-track specifications; I doubt they will all be revised soon to add "-". And then there is of course the question what the canonical format is for comparisions etc. I believe cut'n'paste from utilities to browsers and back to utilities is desirable (it is not just one direction). All utilities I have understand "%". How many years will cut'n'paste be a hassle if we allow both formats? >From a user experience point of view, the only really sensible thing to do for a browser is to accept %en1 literally. And apparently, this can be done. Changing all our standards to support "-" and then waiting years for this to be supported by all the system tools is from a users' perspective pretty much a disaster. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Mon Jul 16 00:02:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C305911E80A6 for ; Mon, 16 Jul 2012 00:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.29 X-Spam-Level: X-Spam-Status: No, score=-101.29 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDHAb0oW1qo0 for ; Mon, 16 Jul 2012 00:02:27 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBED11E8079 for ; Mon, 16 Jul 2012 00:02:26 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1609110eaa.31 for ; Mon, 16 Jul 2012 00:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YzTwMfQ5aTUv7SihkmXjvuryjJf66mPybmF6SZsaYFI=; b=r/o9g3Y54Oibr8CYP5N7DxrE0NejgBz6i6LOiLZD43UgpHoxEp4OL0kIkk3MLOfRYh 2ZKxJm6vznJUZuQgFgUwlfZ/IUcOjdfcAmIK9nLtufPXGSB85+tmf+PoRVIqZ1yWRU38 6b3clKSzxwxDjEcXqw1g6qo10bpXrbapFPhTIezs4sTterBcEuGPEfPe/BYO9yF6k5oH BlNnVzVj9GqCOw4f8F+sAzGYc3slwTFUR2H4GyA2kQHgQQORiWzQ/qcqb3gpqdZLs4jI k0UQc0H4k5i0mzK5bIA6eA0GQZHHFhTihMWKRIp0n3FBZgngxMyMi7HVkHONnOiIazLT UHRQ== Received: by 10.14.204.72 with SMTP id g48mr7771071eeo.36.1342422190290; Mon, 16 Jul 2012 00:03:10 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-126.as13285.net. [2.102.217.126]) by mx.google.com with ESMTPS id w3sm15980717eep.2.2012.07.16.00.03.08 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 00:03:09 -0700 (PDT) Message-ID: <5003BCA7.5070208@gmail.com> Date: Mon, 16 Jul 2012 08:03:03 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de, Simon Perreault , ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> <5002AAC9.1000506@viagenie.ca> <5002ED98.3030907@gmail.com> <20120715164957.GB685@elstar.local> In-Reply-To: <20120715164957.GB685@elstar.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 07:02:27 -0000 Juergen, > The "%" > separator is also embedded in other IETF standards-track specifications; Can you be specific about that? The context here is very specific and I am not aware of any other standards that are relevant to IPv6 literals. There clearly isn't consensus in the WG on a change to the draft that can be made before today's cutoff. More below: On 15/07/2012 17:49, Juergen Schoenwaelder wrote: > On Sun, Jul 15, 2012 at 05:19:36PM +0100, Brian E Carpenter wrote: >> ... OK, as a result of Dave's comments, we now say: >> >> " Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the >> preceding delimiter of a ZoneID." >> >> What we do *not* say is to recommend or suggest that all tools that >> support RFC 4007 should be updated. Should we also add that? > > I believe this direction is wrong. Allowing "-" does not replace "%" > anytime soon and hence we simply make the problem worse. The problem at the moment is the lack of *uniform* support for ZoneIDs in URIs. The cause of that problem is that the delimiter chosen some years ago is an escape charater in URIs. IMHO that was a collective error; we would never have chosen "$" as the delimiter because everybody knows that's an escape character in many CLIs; we just made a mistake by overlooking that "%" is also an escape character. The WG has already decided to fix this by adding a second delimiter "-". > The "%" > separator is also embedded in other IETF standards-track specifications; I > doubt they will all be revised soon to add "-". And then there is of > course the question what the canonical format is for comparisions etc. Correct, we have added a reference to the IAB draft on this topic, but comparison isn't very important for this case because the URIs concerned have no meaning outside the originating host. > > I believe cut'n'paste from utilities to browsers and back to utilities > is desirable (it is not just one direction). All utilities I have > understand "%". How many years will cut'n'paste be a hassle if we > allow both formats? Less than infinity, which is the problem today, since most browsers simply can't handle ZoneIDs at all. > >>From a user experience point of view, the only really sensible thing > to do for a browser is to accept %en1 literally. And apparently, this > can be done. Or not, according to which browser you consider. Remember that it was intentionally removed from Firefox because it violates the URI standard. And IE accepts %25en1, so we have an existing incompatibility. > Changing all our standards to support "-" and then > waiting years for this to be supported by all the system tools is from > a users' perspective pretty much a disaster. It is annoying, but seems better than having no solution at all. Brian From j.schoenwaelder@jacobs-university.de Mon Jul 16 02:57:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE6621F875B for ; Mon, 16 Jul 2012 02:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4vi61hdDWpc for ; Mon, 16 Jul 2012 02:57:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CA76C21F875A for ; Mon, 16 Jul 2012 02:57:57 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48F7D20BF2; Mon, 16 Jul 2012 11:58:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ieC4JUGc029J; Mon, 16 Jul 2012 11:58:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E6ED20BF0; Mon, 16 Jul 2012 11:58:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0F74F206C91F; Mon, 16 Jul 2012 11:58:37 +0200 (CEST) Date: Mon, 16 Jul 2012 11:58:37 +0200 From: Juergen Schoenwaelder To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Message-ID: <20120716095836.GA11013@elstar.local> Mail-Followup-To: Brian E Carpenter , Simon Perreault , ipv6@ietf.org References: <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> <5002AAC9.1000506@viagenie.ca> <5002ED98.3030907@gmail.com> <20120715164957.GB685@elstar.local> <5003BCA7.5070208@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5003BCA7.5070208@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 09:57:59 -0000 On Mon, Jul 16, 2012 at 08:03:03AM +0100, Brian E Carpenter wrote: > Juergen, > > > The "%" > > separator is also embedded in other IETF standards-track specifications; > > Can you be specific about that? The context here is very specific and > I am not aware of any other standards that are relevant to IPv6 literals. RFC 4001 and RFC 6021. These are the ones I have edited. There may be more. And RFC 4001 seems pretty widely used, pretty much in all more recent IP related MIB modules: http://www.arkko.com/tools/allstats/citations-rfc4001.html According to http://www.arkko.com/tools/allstats/citations-rfc4007.html RFC 4007 is used by 9 other RFCs. We could check whether any of the other 7 RFCs may use a literal IPv6 address format with a zone identifier. > There clearly isn't consensus in the WG on a change to the draft that can be > made before today's cutoff. > > More below: > > On 15/07/2012 17:49, Juergen Schoenwaelder wrote: > > On Sun, Jul 15, 2012 at 05:19:36PM +0100, Brian E Carpenter wrote: > >> ... OK, as a result of Dave's comments, we now say: > >> > >> " Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the > >> preceding delimiter of a ZoneID." > >> > >> What we do *not* say is to recommend or suggest that all tools that > >> support RFC 4007 should be updated. Should we also add that? > > > > I believe this direction is wrong. Allowing "-" does not replace "%" > > anytime soon and hence we simply make the problem worse. > > The problem at the moment is the lack of *uniform* support for ZoneIDs > in URIs. The cause of that problem is that the delimiter chosen some years > ago is an escape charater in URIs. IMHO that was a collective error; > we would never have chosen "$" as the delimiter because everybody knows > that's an escape character in many CLIs; we just made a mistake by > overlooking that "%" is also an escape character. > > The WG has already decided to fix this by adding a second delimiter "-". I am concerned that we are simply too late in the game for changing this delimiter, in particular if we start allowing both via an update to RFC 4007. Also note that RFC 4001 has a DISPLAY-HINT, hence the text in section 1 may be somewhat misleading. On the wire, SNMP ships a number but it is most likely presented as a rendered value to the user or databases. RFC 6021 clearly uses a textual format on the wire. > > The "%" > > separator is also embedded in other IETF standards-track specifications; I > > doubt they will all be revised soon to add "-". And then there is of > > course the question what the canonical format is for comparisions etc. > > Correct, we have added a reference to the IAB draft on this topic, but > comparison isn't very important for this case because the URIs concerned > have no meaning outside the originating host. I am not sure this is generally true. While the interpretation of the URI is certainly host specific (or even more precise specific to the nodes' interfaces), this does not necessarily mean those URIs are never compared outside the host. > > I believe cut'n'paste from utilities to browsers and back to utilities > > is desirable (it is not just one direction). All utilities I have > > understand "%". How many years will cut'n'paste be a hassle if we > > allow both formats? > > Less than infinity, which is the problem today, since most browsers simply > can't handle ZoneIDs at all. If it were that simple, we could simply recommend that browsers should be lenient and accept the %en1 format. The question is really whether Internet Explorer people would do so and whether Firefox people would go back to support what they apparently did before. This would enable round-trip cut'n'paste and we would be done. > >>From a user experience point of view, the only really sensible thing > > to do for a browser is to accept %en1 literally. And apparently, this > > can be done. > > Or not, according to which browser you consider. Remember that it was > intentionally removed from Firefox because it violates the URI standard. > And IE accepts %25en1, so we have an existing incompatibility. I understand. That is a standardization / implementation issue to solve. Solving it by introducing a new notation and pushing the conversions to users for years to come seems a not very user friendly resolution. > > Changing all our standards to support "-" and then > > waiting years for this to be supported by all the system tools is from > > a users' perspective pretty much a disaster. > > It is annoying, but seems better than having no solution at all. I am not even sure about that. The "%" notation works reasonably well across many applications today. I would be bad if side-effects of an attempt to settle the URI issue and the desire to support cut'n'paste at the end causes other things to start disagreeing about the separator. Bottom line: I guess my concern mostly boils down to an update of RFC 4007 that allows multiple separators and the effects this might have by system tools producing and consuming different notations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Mon Jul 16 03:50:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BBF21F8711 for ; Mon, 16 Jul 2012 03:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.297 X-Spam-Level: X-Spam-Status: No, score=-101.297 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW6mH6jfrmhv for ; Mon, 16 Jul 2012 03:50:32 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 185F821F86FD for ; Mon, 16 Jul 2012 03:50:31 -0700 (PDT) Received: by eekd4 with SMTP id d4so1705486eek.31 for ; Mon, 16 Jul 2012 03:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=s2GAlqVaGW9g33tSQaWk5b0DiolkX8TljGPnvZQ3UXw=; b=ltQTCBNXm2PsLzC5XALAP0IV7SG3qVseMaHZ3QDsbrP4NwFgde8k+UqTMzKAUb58tP luS7/qw0w6HaHtpjH0fujue6ddRLrDaDqMwlABpbaA8ThlL/rdtjRa4MJr5mTGVlWpxf +5cblvzcZqTZ6bEwap4WkNMVCkbD4w8D5MgdgMn9Hh63yBdURYVwYmbPzIF1hGO0ggFz IyT5zZZ0DTxBwLslKvGqGH7nZv4+u7kXjSLkBw6Grm3c+9MprAiJ112W0QXJAPScXRs5 O1CbKApfKrywV8oL3mAhDr4KbEzukfmgfJUAyaOSVKMRJivA7hL6I0GI6tF9l/R5S+AQ MQSg== Received: by 10.14.179.193 with SMTP id h41mr8702317eem.2.1342435875689; Mon, 16 Jul 2012 03:51:15 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-126.as13285.net. [2.102.217.126]) by mx.google.com with ESMTPS id k48sm17653121eep.13.2012.07.16.03.51.13 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 03:51:14 -0700 (PDT) Message-ID: <5003F221.3030008@gmail.com> Date: Mon, 16 Jul 2012 11:51:13 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de, ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] References: <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> <5002AAC9.1000506@viagenie.ca> <5002ED98.3030907@gmail.com> <20120715164957.GB685@elstar.local> <5003BCA7.5070208@gmail.com> <20120716095836.GA11013@elstar.local> In-Reply-To: <20120716095836.GA11013@elstar.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 10:50:33 -0000 Regards Brian Carpenter On 16/07/2012 10:58, Juergen Schoenwaelder wrote: > On Mon, Jul 16, 2012 at 08:03:03AM +0100, Brian E Carpenter wrote: >> Juergen, >> >>> The "%" >>> separator is also embedded in other IETF standards-track specifications; >> Can you be specific about that? The context here is very specific and >> I am not aware of any other standards that are relevant to IPv6 literals. > > RFC 4001 and RFC 6021. These are the ones I have edited. There may be > more. And RFC 4001 seems pretty widely used, pretty much in all more > recent IP related MIB modules: > > http://www.arkko.com/tools/allstats/citations-rfc4001.html > > According to > > http://www.arkko.com/tools/allstats/citations-rfc4007.html > > RFC 4007 is used by 9 other RFCs. We could check whether any of the > other 7 RFCs may use a literal IPv6 address format with a zone > identifier. >From a quick check, none of them do so. More below... > >> There clearly isn't consensus in the WG on a change to the draft that can be >> made before today's cutoff. >> >> More below: >> >> On 15/07/2012 17:49, Juergen Schoenwaelder wrote: >>> On Sun, Jul 15, 2012 at 05:19:36PM +0100, Brian E Carpenter wrote: >>>> ... OK, as a result of Dave's comments, we now say: >>>> >>>> " Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the >>>> preceding delimiter of a ZoneID." >>>> >>>> What we do *not* say is to recommend or suggest that all tools that >>>> support RFC 4007 should be updated. Should we also add that? >>> I believe this direction is wrong. Allowing "-" does not replace "%" >>> anytime soon and hence we simply make the problem worse. >> The problem at the moment is the lack of *uniform* support for ZoneIDs >> in URIs. The cause of that problem is that the delimiter chosen some years >> ago is an escape charater in URIs. IMHO that was a collective error; >> we would never have chosen "$" as the delimiter because everybody knows >> that's an escape character in many CLIs; we just made a mistake by >> overlooking that "%" is also an escape character. >> >> The WG has already decided to fix this by adding a second delimiter "-". > > I am concerned that we are simply too late in the game for changing > this delimiter, in particular if we start allowing both via an update > to RFC 4007. > > Also note that RFC 4001 has a DISPLAY-HINT, hence the text in section > 1 may be somewhat misleading. On the wire, SNMP ships a number but it > is most likely presented as a rendered value to the user or databases. Yes, but of course the name/number mapping is entirely local to the host in which it applies. At the other end of an SNMP transaction, that mapping is lost, so the rendered value is not very significant. I agree that the DISPLAY-HINT will generate a % delimiter (unless the community decides to update the textual convention). > RFC 6021 clearly uses a textual format on the wire. Yes, but there's a problem IMHO. 6021 says: " The canonical format for the zone index is the numerical format as described in RFC 4007, Section 11.2." That implies that 4007 does truly define a canonical format; but it doesn't. It says that a host SHOULD support numerical indices and MAY support other kinds of implementation-depedent non-null strings. That's underspecified when it comes to mapping into a strictly defined format such as a URI or yang. And (as in the SNMP case) the ASCII string is completely meaningless outside the originating host. "1" might not even refer to interface 1, as far as I can see. >>> The "%" >>> separator is also embedded in other IETF standards-track specifications; I >>> doubt they will all be revised soon to add "-". And then there is of >>> course the question what the canonical format is for comparisions etc. >> Correct, we have added a reference to the IAB draft on this topic, but >> comparison isn't very important for this case because the URIs concerned >> have no meaning outside the originating host. > > I am not sure this is generally true. While the interpretation of the > URI is certainly host specific (or even more precise specific to the > nodes' interfaces), this does not necessarily mean those URIs are > never compared outside the host. True; I just meant that it doesn't seem to matter much in practice. These URIs are intended to be of use during testing and diagnosis, and if they show up somewhere else in the network, they are garbage anyway. > >>> I believe cut'n'paste from utilities to browsers and back to utilities >>> is desirable (it is not just one direction). All utilities I have >>> understand "%". How many years will cut'n'paste be a hassle if we >>> allow both formats? >> Less than infinity, which is the problem today, since most browsers simply >> can't handle ZoneIDs at all. > > If it were that simple, we could simply recommend that browsers should > be lenient and accept the %en1 format. The question is really whether > Internet Explorer people would do so and whether Firefox people would > go back to support what they apparently did before. This would enable > round-trip cut'n'paste and we would be done. I am not interested personally in taking that fight to the URI community; that's why I pursued the current direction. Of course, the WG can decide otherwise. > >>> >From a user experience point of view, the only really sensible thing >>> to do for a browser is to accept %en1 literally. And apparently, this >>> can be done. >> Or not, according to which browser you consider. Remember that it was >> intentionally removed from Firefox because it violates the URI standard. >> And IE accepts %25en1, so we have an existing incompatibility. > > I understand. That is a standardization / implementation issue to > solve. Solving it by introducing a new notation and pushing the > conversions to users for years to come seems a not very user friendly > resolution. > >>> Changing all our standards to support "-" and then >>> waiting years for this to be supported by all the system tools is from >>> a users' perspective pretty much a disaster. >> It is annoying, but seems better than having no solution at all. > > I am not even sure about that. The "%" notation works reasonably well > across many applications today. I would be bad if side-effects of an > attempt to settle the URI issue and the desire to support cut'n'paste > at the end causes other things to start disagreeing about the > separator. > > Bottom line: I guess my concern mostly boils down to an update of RFC > 4007 that allows multiple separators and the effects this might have > by system tools producing and consuming different notations. > > /js > From j.schoenwaelder@jacobs-university.de Mon Jul 16 04:06:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4D21F87B9 for ; Mon, 16 Jul 2012 04:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MPl5HvFVYY6 for ; Mon, 16 Jul 2012 04:06:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 52A1321F87B6 for ; Mon, 16 Jul 2012 04:06:58 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5159320BE9; Mon, 16 Jul 2012 13:07:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2T1YeFW5a9Kg; Mon, 16 Jul 2012 13:07:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AC4120BC1; Mon, 16 Jul 2012 13:07:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3111F20860BD; Mon, 16 Jul 2012 13:07:38 +0200 (CEST) Date: Mon, 16 Jul 2012 13:07:37 +0200 From: Juergen Schoenwaelder To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Message-ID: <20120716110736.GA28076@elstar.local> Mail-Followup-To: Brian E Carpenter , ipv6@ietf.org References: <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> <5002AAC9.1000506@viagenie.ca> <5002ED98.3030907@gmail.com> <20120715164957.GB685@elstar.local> <5003BCA7.5070208@gmail.com> <20120716095836.GA11013@elstar.local> <5003F221.3030008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5003F221.3030008@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 11:06:59 -0000 On Mon, Jul 16, 2012 at 11:51:13AM +0100, Brian E Carpenter wrote: > > RFC 6021 clearly uses a textual format on the wire. > > Yes, but there's a problem IMHO. 6021 says: > > " The canonical format for the zone index is > the numerical format as described in RFC 4007, Section > 11.2." > > That implies that 4007 does truly define a canonical format; but it > doesn't. It says that a host SHOULD support numerical indices and > MAY support other kinds of implementation-depedent non-null strings. > That's underspecified when it comes to mapping into a strictly defined > format such as a URI or yang. And (as in the SNMP case) the ASCII string > is completely meaningless outside the originating host. "1" might not > even refer to interface 1, as far as I can see. Whatever other problems there might be, the typedef uses "%" on the wire - thats the point I was trying to make. Anyway, the intended reading of this text was: The canonical format for the zone index _in this typedef_ is the numerical format as described in RFC 4007, Section 11.2. That is the "canonical" applies to the YANG typedef, not to RFC 4007 (but we use the RFC 4007 SHOULD format as the canonical format. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Fred.L.Templin@boeing.com Mon Jul 16 08:57:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C0B11E80D9 for ; Mon, 16 Jul 2012 08:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqHb-NPrHSLX for ; Mon, 16 Jul 2012 08:57:08 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9211E80D2 for ; Mon, 16 Jul 2012 08:57:08 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6GFvuOq028517 for ; Mon, 16 Jul 2012 08:57:56 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6GFvuTQ028508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Jul 2012 08:57:56 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6GFvqba015689; Mon, 16 Jul 2012 10:57:52 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6GFvpWv015642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 16 Jul 2012 10:57:52 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 16 Jul 2012 08:57:51 -0700 From: "Templin, Fred L" To: Thomas Narten Date: Mon, 16 Jul 2012 08:57:49 -0700 Subject: RE: RFC2460 violation of RFC1122 Thread-Topic: RFC2460 violation of RFC1122 Thread-Index: Ac1htT53FcuhhOMyQuCkR5jAsG+qJQBtb3fA Message-ID: References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <50001613.2090203@viagenie.ca> <6.2.5.6.2.20120713085321.095aaf60@resistor.net> <50004916.4000206@viagenie.ca> <201207141138.q6EBcS6V014019@cichlid.raleigh.ibm.com> In-Reply-To: <201207141138.q6EBcS6V014019@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:57:09 -0000 Thomas, > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Saturday, July 14, 2012 4:38 AM > To: Templin, Fred L > Cc: ipv6@ietf.org > Subject: Re: RFC2460 violation of RFC1122 >=20 > > By assuming an EMTU_R of greater than 576 bytes, RFC2460 > > is therefore in violation of RFC1122, which could lead to > > communication failures. How do we reconcile this? >=20 > How many TCP/IP stacks exist today that cannot connect to an Ethernet, > and thus, handle 1500 byte datagrams? >=20 > I suspsect that platforms limited to accepting IP datagrams of max > size 576 are gettign to be an extreme edge case these days. Others might disagree, but I don't mind assuming 1500. But then, the size 1280 is in no way significant to IPv4 hosts so why stop there? Why not go all the way and say that IPv4 hosts are expected to reassemble at least 1500 the same as for IPv6 hosts? Thanks - Fred fred.l.templin@boeing.com =20 =20 > Thomas From narten@us.ibm.com Mon Jul 16 09:39:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79FA11E811F for ; Mon, 16 Jul 2012 09:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh9TJjPxzS+Z for ; Mon, 16 Jul 2012 09:39:30 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id E967621F8621 for ; Mon, 16 Jul 2012 09:39:29 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 16 Jul 2012 10:40:11 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 16 Jul 2012 10:37:51 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 4A28D19D8065 for ; Mon, 16 Jul 2012 16:37:45 +0000 (WET) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6GGbghS124120 for ; Mon, 16 Jul 2012 10:37:43 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6GGbenx021418 for ; Mon, 16 Jul 2012 10:37:40 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.27.204]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q6GGbUk5020367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 10:37:31 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q6GGbTne010588; Mon, 16 Jul 2012 12:37:29 -0400 Message-Id: <201207161637.q6GGbTne010588@cichlid.raleigh.ibm.com> To: "Templin, Fred L" Subject: Re: RFC2460 violation of RFC1122 In-reply-to: References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <50001613.2090203@viagenie.ca> <6.2.5.6.2.20120713085321.095aaf60@resistor.net> <50004916.4000206@viagenie.ca> <201207141138.q6EBcS6V014019@cichlid.raleigh.ibm.com> Comments: In-reply-to "Templin, Fred L" message dated "Mon, 16 Jul 2012 08:57:49 -0700." Date: Mon, 16 Jul 2012 12:37:29 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12071616-2356-0000-0000-0000006659DB Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:39:31 -0000 > Why not go all the way and say that IPv4 hosts are expected to > reassemble at least 1500 the same as for IPv6 hosts? We can say it, but how will we enforce it on the deployed base? Thomas From Fred.L.Templin@boeing.com Mon Jul 16 09:42:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AE911E8134 for ; Mon, 16 Jul 2012 09:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXVWpYOIgD2d for ; Mon, 16 Jul 2012 09:42:24 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id A6CDC11E80CD for ; Mon, 16 Jul 2012 09:42:23 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6GGh8HN026584 for ; Mon, 16 Jul 2012 09:43:08 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6GGh7Y1026575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Jul 2012 09:43:08 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6GGh7Fn009478; Mon, 16 Jul 2012 11:43:07 -0500 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6GGh2hn009265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 16 Jul 2012 11:43:07 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 16 Jul 2012 09:43:06 -0700 From: "Templin, Fred L" To: Thomas Narten Date: Mon, 16 Jul 2012 09:43:05 -0700 Subject: RE: RFC2460 violation of RFC1122 Thread-Topic: RFC2460 violation of RFC1122 Thread-Index: Ac1jcXxxMaeVMMp0Rpmf1/c1yFOXewAABXYw Message-ID: References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <50001613.2090203@viagenie.ca> <6.2.5.6.2.20120713085321.095aaf60@resistor.net> <50004916.4000206@viagenie.ca> <201207141138.q6EBcS6V014019@cichlid.raleigh.ibm.com> <201207161637.q6GGbTne010588@cichlid.raleigh.ibm.com> In-Reply-To: <201207161637.q6GGbTne010588@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:42:24 -0000 > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Monday, July 16, 2012 9:37 AM > To: Templin, Fred L > Cc: ipv6@ietf.org > Subject: Re: RFC2460 violation of RFC1122 >=20 > > Why not go all the way and say that IPv4 hosts are expected to > > reassemble at least 1500 the same as for IPv6 hosts? >=20 > We can say it, but how will we enforce it on the deployed base? We can't enforce it, just the same as that we can't enforce anything over 576. Once the standards are violated, we are already living in sin - so what does it hurt to magnify the sin ever so slightly? Thanks - Fred fred.l.templin@boeing.com From internet-drafts@ietf.org Mon Jul 16 11:38:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B21821F87BA; Mon, 16 Jul 2012 11:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVazamhovTek; Mon, 16 Jul 2012 11:38:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AB121F87AA; Mon, 16 Jul 2012 11:38:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716183820.5813.35159.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 11:38:20 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:38:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Jun-ya Kato Tim Chown Filename : draft-ietf-6man-addr-select-opt-04.txt Pages : 11 Date : 2012-07-16 Abstract: RFC 3484 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 3484 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 14:38:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F521F8608; Mon, 16 Jul 2012 14:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d0+Z+EnU+R2; Mon, 16 Jul 2012 14:38:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F93E11E8099; Mon, 16 Jul 2012 14:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716213830.29978.99834.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 14:38:30 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:38:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Security and Interoperability Implications of Oversized = IPv6 Header Chains Author(s) : Fernando Gont Vishwas Manral Filename : draft-ietf-6man-oversized-header-chain-01.txt Pages : 13 Date : 2012-07-16 Abstract: The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-oversized-header-chain= -01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fgont@si6networks.com Mon Jul 16 14:45:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67421F86DF for ; Mon, 16 Jul 2012 14:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NajnJ-SF0eq for ; Mon, 16 Jul 2012 14:45:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id C4F9E21F86DC for ; Mon, 16 Jul 2012 14:45:24 -0700 (PDT) Received: from bl10-131-211.dsl.telepac.pt ([85.243.131.211] helo=[192.168.1.84]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sqt7F-00051O-JS; Mon, 16 Jul 2012 23:46:05 +0200 Message-ID: <50048B84.7070204@si6networks.com> Date: Mon, 16 Jul 2012 22:45:40 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt References: <20120716213830.29978.99834.idtracker@ietfa.amsl.com> In-Reply-To: <20120716213830.29978.99834.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:45:25 -0000 Folks, I've posted a rev of draft-ietf-6man-oversized-header-chain. It incorporates a clarification of what we mean by "entire IPv6 header chain", as suggested by Suresh. Since this I-D is very simple and short, and has been pretty stable for a while, I personally think that it should be ready for WGLC. Thoughts? Best regards, Fernando On 07/16/2012 10:38 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : Security and Interoperability Implications of Oversized IPv6 Header Chains > Author(s) : Fernando Gont > Vishwas Manral > Filename : draft-ietf-6man-oversized-header-chain-01.txt > Pages : 13 > Date : 2012-07-16 > > Abstract: > The IPv6 specification allows IPv6 header chains of an arbitrary > size. The specification also allows options which can in turn extend > each of the headers. In those scenarios in which the IPv6 header > chain or options are unusually long and packets are fragmented, or > scenarios in which the fragment size is very small, the first > fragment of a packet may fail to include the entire IPv6 header > chain. This document discusses the interoperability and security > problems of such traffic, and updates RFC 2460 such that the first > fragment of a packet is required to contain the entire IPv6 header > chain. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-oversized-header-chain-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dthaler@microsoft.com Mon Jul 16 14:56:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CAB11E809B for ; Mon, 16 Jul 2012 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZBACpx-k3zZ for ; Mon, 16 Jul 2012 14:56:00 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id CB9E911E8251 for ; Mon, 16 Jul 2012 14:55:59 -0700 (PDT) Received: from mail15-db3-R.bigfish.com (10.3.81.253) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 16 Jul 2012 21:56:45 +0000 Received: from mail15-db3 (localhost [127.0.0.1]) by mail15-db3-R.bigfish.com (Postfix) with ESMTP id C8C9C10010C; Mon, 16 Jul 2012 21:56:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zf7Iz9371I542M1432Id4c4mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail15-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail15-db3 (localhost.localdomain [127.0.0.1]) by mail15-db3 (MessageSwitch) id 1342475803861557_28332; Mon, 16 Jul 2012 21:56:43 +0000 (UTC) Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.239]) by mail15-db3.bigfish.com (Postfix) with ESMTP id C6B18160047; Mon, 16 Jul 2012 21:56:43 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 16 Jul 2012 21:56:43 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Mon, 16 Jul 2012 21:56:26 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 16 Jul 2012 14:56:25 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Mon, 16 Jul 2012 14:56:25 -0700 From: Dave Thaler To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Thread-Topic: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Thread-Index: AQHNX2DzeUGxz0UIhkC9N9TBFxf2fZcmBI2AgACAdACAAC6sAIACO/YAgABj2oCAACiUgIAAA14AgAD2JYCAAf+tsA== Date: Mon, 16 Jul 2012 21:56:24 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B6F535A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> In-Reply-To: <500277EF.9040302@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:56:02 -0000 I'm ok with the updated text Brian posted. To comment on the other points others raised: * I agree that we should define either '%' or '-' as being the canonical fo= rm. RFC 5952 covers issues with not having one, and defines a canonical form for IPv6 literals, but does not mention the zone id at all. If we want= safe cut-and-paste, then '-' needs to be defined as canonical (i.e., what you= =20 output). However, you won't get cut-and-paste to things that haven't been updated to support it. So one conclusion you might draw is that you can't get cut-and-paste *everywhere* within our lifetime, and you sh= ould just get used to it. And if you're one of the people who draws that con= clusion then you might even go so far as to question the whole document, which=20 seems to be where Juergen is coming from. * Brian writes: "What we do *not* say is to recommend or suggest that all=20 tools that support RFC 4007 should be updated. Should we also add that?" If we really care about cut-and-paste, then yes. Which is why this doc= ument is so difficult to get benefit from, since it requires changing so many = things. (See last paragraph of [RFC5218] section 2.1.1.) * Juergen writes: "Changing all our standards to support "-" and then waiti= ng years for this to be supported by all the system tools is from a users'= =20 perspective pretty much a disaster." I'm actually fairly sympathetic to that point of view. The status quo without this document is basically that you cannot use zone IDs in URIs, although some apps and OSs support URI-like strings that do allow them but it may vary by app and OS. With this document, the story is that you can use them in some (updated) applications and=20 thus sometimes you can get cut-and-paste. That sounds like a small benefit to get from requiring changes to all IPv6 literal (including in = URIs)=20 parsers/generators. This doesn't seem to bode well from an RFC 5218 analysis standpoint. * Juergen writes: " If it were that simple, we could simply recommend that= =20 browsers should be lenient and accept the %en1 format. The question is= =20 really whether Internet Explorer people would do so and whether Firefox= =20 people would go back to support what they apparently did before." As I mentioned in my original email, it's not just IE 7 and up, it's als= o the=20 OS APIs so it's pretty pervasive (again, not on the wire just in APIs wi= thin the host) so I think you mean "whether IE and Windows people would do so= ". I think it's probably safe to assume the answer is "No" because it may r= esult=20 in breaking applications. That's not something that's worth it just to= get=20 "cut-and-paste" which is nowhere near as important as app compat. -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Sunday, July 15, 2012 12:58 AM > To: ipv6@ietf.org > Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] >=20 > Without consulting my co-author, here's my personal suggestion for a chan= ge to > the draft. There's just time to submit an update before the cutoff, if pe= ople > respond immediately. >=20 > OLD > In recent years, web browsers have evolved considerably and now > accept and parse many forms of input that are not a formal URI. > Examples of this include host names, search items, bookmarks, search > history, etc. For example the Google Chrome browser now calls the > "address bar" the "omnibox" [chrome]. The authors believe it is > feasible, and very convenient for users, if browsers also allow (in > addition to the formal URI syntax defined in this document) a syntax > that will enable cut and paste. For example: >=20 > http://[fe80::a%en1] >=20 > It seems that modern browsers can be adapted to parse this because it > is inside of the "[" "]"'s. This would permit the output of commands > like ping6 -w ff02::1%en1 to be "cut and pasted" into a browser > address bar. Consequently this document recommends that browsers > support this syntax in addition to the formal URI syntax defined > above. >=20 > NEW >=20 > In recent years, web browsers have evolved considerably and now > accept and parse many forms of input that are not a formal URI. > Examples of this include host names, search items, bookmarks, search > history, etc. For example the Google Chrome browser now calls the > "address bar" the "omnibox" [chrome]. Thus, it seems that browsers > can take a pragmatic approach to literal addresses including ZoneIDs. > Unfortunately there is no way to resolve the discrepancy between > the two approaches mentioned above (raw "%" versus "%25") and > therefore we recommend general implementation of the new "-" syntax > defined by this document. This will allow simple "cut and paste" > between tools such as "ping6" and browser address bars. >=20 > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From cheshire@apple.com Mon Jul 16 17:35:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CD911E809B for ; Mon, 16 Jul 2012 17:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SfB8Gfy6Afg for ; Mon, 16 Jul 2012 17:35:07 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE1311E8073 for ; Mon, 16 Jul 2012 17:35:01 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xtEdFOi8lAxCsFoQpEbj2A)" Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M7A00DWZ2AGXNO4@mail-out.apple.com> for ipv6@ietf.org; Mon, 16 Jul 2012 17:35:39 -0700 (PDT) X-AuditID: 1180711d-b7f406d000004330-35-5004b35b9909 Received: from [17.193.13.41] (chesh1.apple.com [17.193.13.41]) by relay13.apple.com (Apple SCV relay) with SMTP id D3.39.17200.B53B4005; Mon, 16 Jul 2012 17:35:39 -0700 (PDT) To: ipv6@ietf.org Message-id: <221B8D89-0B8E-498A-9C8C-74CC3D305FD1@apple.com> From: Stuart Cheshire Subject: draft-ietf-6man-uri-zoneid-02.txt Date: Mon, 16 Jul 2012 17:34:47 -0700 X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUieJBXUzd6M0uAwYWp0hYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoMDnWwFj5awV0xbuIu5gfF1M3sXIyeHhICJxKGnGxkhbDGJ C/fWs3UxcnEICWxklPi4+hwLSIJXwEji6uSpYA0iAoIS2x/8AIpzAMVtJPYdTQAJMws4SBx8 2QJWziagJfHi8xU2EFsYyH778SAriM0ioCpx5+EeJohdchKHT79inMDIPQvJhllIRkHY8hLb 385hhrC9JI51PmaCsBUlpnQ/hKr3ldjd1MAKYTtLXO9qZ8NU4y7RfHIfVI2txImT89lwmb+A kWcVo2BRak5ipaGxXmJBQU6qXnJ+7iZGUHA3FMruYNz/k/8QowAHoxIP7y0blgAh1sSy4src Q4wSHMxKIrzTZwGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85okAaUE0hNLUrNTUwtSi2CyTByc Ug2MixwOJKueuTfD65Nr8Z/o3oznk4N7Nkt73M10qp0vxZZ8NWpWeL783xea96Pn9MasY9wf +XKd7K6OOdftBHJmRi99fKT9Ruq+lkOLX57tfnVzmmt3Wnhga7CK3oetFTl+QoKr9nNnJL+6 9PbLzLhzx12nWJxMeh5xSOtd984Ds0L3qCrJRYbzKLEUZyQaajEXFScCAC6lkRRqAgAA X-Mailman-Approved-At: Mon, 16 Jul 2012 18:26:16 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 00:35:08 -0000 --Boundary_(ID_xtEdFOi8lAxCsFoQpEbj2A) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT I'm glad we're having this discussion about zone identifiers in IPv6 address literals, but I'm very disturbed by the direction the discussion seems to be going. To put it simply, today we don't have a problem, but publishing this document as it currently stands would be creating one. I'll explain what I mean by that: Escaping (e.g. "%" <-> "%25") or some other transformation (e.g. "%" <-> "-") is needed *only* when required to allow unambiguous parsing: when a delimiter character is also allowed as a data character, then escaping or some other data transformation is necessary to disambiguate data from delimiters. Using escaping when it's *not* necessary is a bad idea, because escaping is not free. Escaping has a cost, in terms of CPU cycles, in terms of increased data size, and -- most importantly -- in terms of cognitive cost. When data has different forms in different contexts, users and developers have a hard time remembering what goes where. Attached are a couple of examples from my daily life. What is "Magic% 20Bell"? What is "Gabbie's home"? In both cases here, internal data escaping has unintentionally leaked through into the user interface. --Boundary_(ID_xtEdFOi8lAxCsFoQpEbj2A) Content-type: image/png; x-unix-mode=0644; name="WhatisMagic%20Bell?.png" Content-transfer-encoding: base64 Content-disposition: inline; filename="What is Magic%20Bell?.png" iVBORw0KGgoAAAANSUhEUgAAAboAAAIKCAIAAADatx06AAAXNmlDQ1BJQ0MgUHJvZmlsZQAAWIW1 WQk0Vd3b3+fc+XJN1zzP8yxz5jljZiKueR4vIQ2GVGggRJRCxqIkJCWESslQKJQGISqFlPE7qvd9 /9+0vvWt9X3PWvuc33r2s589/e7ez3MuABzzlIiIEJgBgNAwapStiT6/s4srP24cQAANWAAdYKB4 R0fo2dhYgP9Wvg8j1ogMyWz7+u/t/kth9PGN9gYAskGwl0+0dyiCGwCA9b0joqgAoH4g+v591AgE ox8gmDkKGSCCx7ex/2+8sI29fmEM+peNva0BgtkBwNNSKFH+AJCEET1/rLc/4odkCACWKcwnMAwA sjOCtb0DKD4AcOQjNtKhoeHb+D6Cxb3+xY//v/Pp9bdPCsX/b/x7Lr8EbxgYHRFCif9fLsf/LKEh MX/1wYQU2rAQq+29YUXKjA/F0Bx5cyNlMyLk154hNhCnb5iD3R8sHeZlZf0Ha/tFGdv+bgvZRFD1 tzEyP8gvgmpj/0d/MCHAwGq7HwTn+EYb/eXnYhBl1/ae0SG4PirG1gHByBpA96Jj7YwQjDAKep8Q YO/0x2bJx9fwjx6G/QKNzf5gpkCq2XZfzAgWDA43t/3dF6wCzEEI8AUxIAp5hgEZYAEMgOGfpwzw AxSkJhapiwbB4AOCQ5EW4UibcATz/7Ez+E8a41/t/JF2/94jP/BG7GL+7vMv7T8eAoEP8v5LT/lT tz26aI/A5H96+Fd/v1rK18jPyq//VY8WRSuildH6aC20Nlod8KNZ0ZxABr0DrYbWQ+ugNZE6dWSU 73+N8s8Yt/2H1vvF5ofHazgG/JmD198zcPxlHfhfzujP2Pvmm+b/HiGg+sZRtwlkEB4RHxXoH0Dl 10N+ub7S/GZh3rLS/IryCor/57z9/5TtM+s3WrT9dRZBrE//0YWmAKCeg3Bqzz8670kAmr4CQPjw j04kGqFqIgDdc94xUbG/ddvHCcAAIqBHGMoBeIEQEEfWWRGoAE2gC4zALmAN7IEL2IusdgDCwSiw DySCJJAGMsBpkAvOgWJQCirBVVAPmkAraAfdoBf0g+dgDEyCKTAHFsB3sAZBEA4iQWSIA+KDRCAp SBFSg7QhI8gCsoVcIE/IHwqDYqBEKAXKgLKhc9AlqAq6Dt2C2qGH0AD0AnoDzULfoFUYBdPCzDAP LArLwWqwHmwO28PusD8cCSfAqfBJOB8uga/AjXA73As/hyfhOXgZBVA0KFaUAEoGpYYyQFmjXFF+ qCjUQVQ6Kg9VgqpFtaB6UEOoSdQ86icaiyaj+dEyCE9N0Q5ob3Qk+iA6E30OXYluRN9HD6HfoBfQ mxgShhsjhdHAmGGcMf6YfZg0TB6mHHMT04V5jpnCfMdisaxYMawq1hTrgg3C7sdmYs9j67D3sAPY d9hlHA7HgZPCaeGscRQcFZeGK8BdwbXhBnFTuB94GjwfXhFvjHfFh+GT8Xn4avxd/CB+Gr9GYCCI EDQI1gQfQjzhFKGM0EJ4SpgirBEZiWJELaI9MYiYRMwn1hK7iOPERRoaGkEadZrdNIE0h2nyaa7R PKB5Q/OTlolWktaA1o02hvYkbQXtPdoXtIskEkmUpEtyJVFJJ0lVpE7SK9IPOjKdLJ0ZnQ/dIbpC uka6QbrP9AR6EXo9+r30CfR59Dfon9LPMxAYRBkMGCgMBxkKGW4xjDAsM5IZFRitGUMZMxmrGR8y zjDhmESZjJh8mFKZSpk6md6RUWQhsgHZm5xCLiN3kaeYscxizGbMQcwZzFeZ+5gXWJhYdrA4ssSx FLLcYZlkRbGKspqxhrCeYq1nHWZdZeNh02PzZTvOVss2yLbCzsWuy+7Lns5ex/6cfZWDn8OII5gj i6OJY4ITzSnJuZtzH+cFzi7OeS5mLk0ub650rnqul9wwtyS3Lfd+7lLux9zLPLw8JjwRPAU8nTzz vKy8urxBvDm8d3ln+ch82nyBfDl8bXwf+Vn49fhD+PP57/MvCHALmArECFwS6BNYExQTdBBMFqwT nBAiCqkJ+QnlCHUILQjzCVsKJwrXCL8UIYioiQSInBXpEVkRFRN1Ej0q2iQ6I8YuZiaWIFYjNi5O EtcRjxQvEX8mgZVQkwiWOC/RLwlLKksGSBZKPpWCpVSkAqXOSw1IY6TVpcOkS6RHZGhl9GRiZWpk 3siyylrIJss2yX6WE5ZzlcuS65HblFeWD5Evkx9TYFLYpZCs0KLwTVFS0VuxUPGZEknJWOmQUrPS 1x1SO3x3XNgxqkxWtlQ+qtyhvKGiqhKlUqsyqyqs6qlapDqixqxmo5ap9kAdo66vfki9Vf2nhooG VaNe44umjGawZrXmzE6xnb47y3a+0xLUomhd0prU5tf21L6oPakjoEPRKdF5qyuk66NbrjutJ6EX pHdF77O+vH6U/k39FQMNgwMG9wxRhiaG6YZ9RkxGDkbnjF4ZCxr7G9cYL5gom+w3uWeKMTU3zTId MeMx8zarMlvYpbrrwK775rTmdubnzN9aSFpEWbRYwpa7LM9YjluJWIVZNVkDazPrM9YTNmI2kTa3 d2N32+wu3P3BVsE20bbHjmznYVdt991e3/6U/ZiDuEOMQ4cjvaObY5XjipOhU7bTpLOc8wHnXhdO l0CXZlecq6NruevyHqM9uXum3JTd0tyG3cXc49wf7uXcG7L3jge9B8XjhifG08mz2nOdYk0poSx7 mXkVeS14G3if9Z7z0fXJ8Zn11fLN9p320/LL9pvx1/I/4z8boBOQFzAfaBB4LvBrkGlQcdBKsHVw RfBWiFNIXSg+1DP0VhhTWHDY/XDe8LjwgQipiLSIyUiNyNzIhSjzqPJoKNo9upnKjASHj2PEY47E vInVji2M/bHPcd+NOMa4sLjH8ZLxx+OnE4wTLu9H7/fe35EokJiU+OaA3oFLB6GDXgc7DgkdSj00 ddjkcGUSMSk46UmyfHJ28lKKU0pLKk/q4dR3R0yO1KTRpUWljRzVPFp8DH0s8FjfcaXjBcc3033S H2XIZ+RlrGd6Zz46oXAi/8TWSb+TfadUTl04jT0ddno4SyerMpsxOyH73RnLM405/DnpOUu5HrkP 83bkFZ8lno05O5lvkd9cIFxwumD9XMC554X6hXVF3EXHi1bO+5wfvKB7obaYpzijePVi4MXRSyaX GktES/JKsaWxpR/KHMt6LqtdrirnLM8o36gIq5istK28X6VaVVXNXX2qBq6JqZm94nal/6rh1eZa mdpLdax1GdfAtZhrH697Xh+uN6/vuKF2o7ZBpKHoJvlmeiPUGN+40BTQNNns0jxwa9etjhbNlpu3 ZW9XtAq0Ft5huXPqLvFu6t2ttoS25XsR9+bb/dvfdXh0jHU6dz67v/t+X5d514Nu4+7OHr2etgda D1ofajy89UjtUVOvSm/jY+XHN58oP7nZp9LX+FT1aXO/en/LwM6Bu4M6g+1DhkPdz8ye9T63ej4w 7DA8OuI2MjnqMzrzIuTF15exL9fGDo9jxtMnGCbyXnG/Knkt8bpuUmXyzhvDN4/f2r0de+f9bu59 9Pv1qdQPpA9503zTVTOKM62zxrP9H/d8nJqLmFubT/vE+Knos/jnhi+6Xx4vOC9MfY36uvUtc5Fj sWJpx1LHss3yq++h39dW0n9w/Kj8qfazZ9VpdXpt3zpuPX9DYqNl03xzfCt0ayuCEkX5FQqgkAL7 +QHwrQKJ912Q3KEfACLd75zij6CQ4ANG3lgkBjdEooAhiBdyh6pgADvDt1FiqHNoNnQRRhrTgw3D 8eGG8LkET6IsDZrmFe1XOhK9EsMexmSm6+RpFm5WF7az7OOcIlwR3Hd56fn8+e8KcghFCbeKrIqp iEdIVEi+lMbJyMhayfnJxykkKR5RSt5xQJmq4q+6W01SHa3+SuOWZt7OGC0HbVUdLl1Yd15vRL/L 4KZhhVGRcbZJummy2f5dVPMwi0BLXysfax8bn90BtmF2VPsDDmmOJ53OOhe7VLjW7Wl0a3Xv2Nvt 0ev5lDLkNeI95vPW97PfZgA5UDrINNgv5FjolbD+8KVItii1aBdqXExmbOG+K3F34wcTZhPhA7wH tQ55HE5Jqk4eStk8wpumcNTgmNPx0PSjGWWZPSe+nOI5bZuVmd2bQ5/rkFdwdryA+5xr4dmi/gv4 Yt2LcZfqSmbKBC+7lUdVHK48XVVS3VwzeGWhllyneS3wemH90wb8TdVGxyZq8+lbNS0dt5+3Tt35 ene1basd1YHuxN4ndBG7cd0bPfMP+h9WPIrqVeidfpz1RPXJZF/N05h+nQH8wOBg4ZDPM9lnP593 DWePUEbVXnC+2Hj5Zuz++OWJtFe+r/UmuSeX3jx6W/wu9r3NlAzCsq/TL2cezrZ+bJi7Pn/t043P tV8qF65+7fy2sKS2XLTC++POavS69ibH1taviJED7ASRoBkiQobQMWgEloJT4CkktupA4v42jAVm Cnscp4L7gD9PcCMKEOdp5hAGAHoSgzCjGpMtmcqcy9LCOsXOxKHHuY/rKvcMrwifN/8lgX7B78Kc Ipqie8SixY9LFEiWSJVKX5A5I5ssFyJvq7BDkaw4rXQDYYKJCoPKC9UStRB1FQ2g8VAze6eblqjW F+0WnWO67npq+sz6Xwx6ETakGnuZ6JrymK6bje1qMS+wiLN0tdKxFrUh2Szvfm37yK7JvtQhyzHJ KcqZ4mLnarhH2U3EnXUvYe+Gx6LnHOW916T3hM+Y75jfuP9EwOvA10ETwWMhL0Nfho2FTyAn9VTU XPQidT0Wu48pjiteIEFsv2yiygGdg2aHHA57J1GT01IKU+uP9KbNHqM7rpTuknEgs+RE98mPpxmy VLLdz6Tl1OWO5H3JBwVM50QLtYqczlMv5BXfuThdwlJqUpaInH8PKqarsNWiNUZXfK6m1JbVdV+b rSfdUGywvRnYeKApq7nsVmNLz+3R1pk7P9uI97jbZTuUOkXuk7tA13z3SE/7g5qHOY8Se30fWz1R 6xN/KtDPPcAxyDHE+Yz3udCw+IjcqPILjZe6Y8bjVhOur4Jfp0yWIHzYeK8+deBDzwz7bPDH9nmx T5e+KCy8/XZjqeJ764/Pa6obOb/2H41kC/LAFZwB4xAP5AgVQO/hHXA6PIuyQrWg5dG1GGVMB9YZ u4TLwWviZwiXiXE0nrQWJDU6EXo2BhIjjgkio5gxLFhWejYudlEOZU4jLkfuQJ4QXi8+Z35zgZ2C 4kL0SETVK3JRNExMTeyn+E2JMEkRyRGpQ9L80vdkKLKQbJmcqdy8fLaCusIbxQwlVaW3O04payvP qZxV1Vf9pFagbqS+oFGoaaK5uLNYy0Lrh3aZjq3Olm6jXpS+ov6iQYNhjJGK0Ypxk0m8qabpmtmd XQfNdS2ARYdlqpWpNcn6mU3Rbn9bJTvYbgDhSIyjmROP02fnNpfTrt4IS/Bu4+7X9x7z8PBUo5Ap X7wee1/xOe0b4+firxUgEIgJnA16Enw9JDc0Psw9XD9CKpIjChe1HP2W+jSmJbZ0X0ZcZLxDgtp+ jkQocfUgdIhwmCmJM1koRSpV6YhGmu5R42Pmx23S3TOiMo+dKD5541T36ZGsqewvZ1Zy1nM38zbz iQXy51wKU4tqz48Ug4tilyxLokrzypovvyjfqlSo8qk+W/P4KqjdURd47cL1oRu4hp03IxsvN43c IrRo3A5uPXfnwd2le3ztph2Rnfn327re9mAeSDy0fhTfW/l4oo/z6d7+qoG1IdtnncMeo+wvVscl X7W9GZiizjZ9PrO49PPB9v7//ra0LVgVAEpLAHASBsDWEoAyaSTPRJJrUhsANiQA7NUBzFEAoI5T ADKp/fv+oAOSSGYZAk4hWeNzsIrcIoZQMHQGugE9h1ZgTlgH9kHYdA0eRXI3CZQd6gCqEvUMDdCy aDd0OroF/RHDhbHEJGFaMEtYeWwo9gr2E04eF4trwxPxLvgaAkxwI9wm8hBTkJNnD80IrQPtMMmZ NE7nRTdLH0m/ypDKSM9YyCTO1Eg2Ij9nDmBeZ8lmlWS9z+bBtsaez6HKMcwZy8XO1cK9lwfDc5XX mQ/D18DvJ8ApMCCYIWQijBHuFjkuai3GKjYmXizhJSks+UGqUjpIRlrms2y93D55HQWCwrDiZaV9 O+yUVVQ4VDZV3yFR9VWNbM19yDmlqy2iQ9D5ovtMr0W/AeHhTaMm41smt0xvmTXuum5ebVFsecYq 1Zpq473bxlbXTtFe1IHXkd2J1ZnVhdOVf4+4m5K7zl5Ljz2eQZQErxPe/b5kP0f//IAXQWzBdiGZ oZ1h3yPEIh2jjkTXU1/Fiu+LietO4NpPTRw6qHaoLIktOSuV6UjBUZFjjemGGaMnqMgtNZJdnVOc d7uArjD3gvpFr5Kssu7yrSrtmkNX26+h600ajjcWN99sedL6sY3UrtoZ3FXV8+2R0eOLfYsDBkMZ z3tH4Zey47tfhUwmvc1+f/FD98ynj9/n33y+uuD+dWmRuvT6u+ZK5o9nq4xrZusHNqo3h3+dHwxA DtiBOFAMusAcRIZ2Qn5QFtSA5PmbsAhsAcfAxfBDeAnJ2a1Qiaga1BiaBrlXwtEl6GEMDUYPE49p xCxjVbDx2Ds4DJJHF+Hm8Xr4c/gVggvhHlGKWEhDT3OClpn2AkmK1EpnQzdNn8TAx9DO6MtEYmoi uzNDzBUsNizrrNVsruwk9k6O/ZzKnItcN7ipPMo8K7y3+ZL4TQUYBMYEK4SowgYiLCIzonfF8sSj JWwkZaVIUp+k+2TqZLPkqPIuCtqKIkp0Sj93fFR+pTKk+lCtXb1F46bmtZ1XtKq0K3TKdcv1KvTr DG4bPjAaMZ42+WFG3MVtLmehZ2ln5WcdZ5Ox+7xtpV2DfafDkOMHp1UXRleJPQZu7u7xe/OQfGOQ 8tWb38fT96LfZAB/oEdQUfBoKGOYafjBiOuR76JZqEYxSbFP4jjjgxJaExkO+B28e5gtKTL5carY kZS0yWNax6szBDOLTnKeKsziyy7Pkc+9c9Yif+JceBHqfH6x5yX1Utayn+WTlU+q26401NZeq66v bChvzGyOaLFtVbrL1LbQ3td5tetET/hDh17tJxJPmfvXB18/axnOHLV/yTTWNRHxmjx57a3Zu/Gp 0GnMzJmPrHOZ88ufbb+cXxj7Rr+oumS7HPg9eiXhR8LPmNXQNc912w2dTektll/7zwzUgRc4AZrB e4gR0oUioAtQD/QV5oHN4QS4Gh5D0aH0ULGoq6j3aG60IzoL/QTZdzNMJmYYK4iNxHbiOHDRuEG8 Kr6UwErIIrIQi2kUaEZpU0nKpBm6YnpnBmaGQcYcJmeyAPkbcw/LJdZDbN7suzhUOEW5uLjJ3Bs8 H3gH+Nr5GwRqBMuFyoQrRK6KNol1i49KzEluSTPLSMjqyDnIhygcUSxWur1jUgWvqqjmoX5S467m gpaQtpNOpm6H3g8DScO9RnnG/aYkM6td2eYvLIWswq3bdjPautuV2y86GjrlO391tdnT4M6395Qn hpLk9dlHzTfFrz+ALzAyqCuEKzQmbDBCMTI3ap3qG9O5jzMuOr5vv0zi6QM/DvkdfplsnzJ8ZG/a 3LFDx6cy9DMvnYRO+Zx+mC1/pjCXkJdw9kuB/7l3RV7n3xXbXrxXIl966TK5/GjFRhW1+tMV/6vv 6ijX3tR73Zi6GdK40pzSwni79I7q3b57gR34zpqu3d1rDyofOT8mPul6mjSgM7j+rGk4bFTwxdOx 2AnWV9cnjd+MvPN5//mDw3TZzNxHwTmL+cBPQZ99vhgu8C28/Xr5m823n4vnl+SX7i87LI9+d/0+ seK48viH/o+mnyI/s35urAas9q8prxWsbax7rbdv8G0c3JjY1NzM3VzY2rVVtr3/0X5Kvz/AQrT6 SDD5amtrURQAXDYAG1lbW2slW1sbpUiyMQ7AvZDf/1f8umsYACiq30bdBqmH/+M30n8DKzqGkIWg ABAAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHic7N15QBR1/wfw9+7MXsByLXIIioqKioYm KuaqCT7mbXmVWR6VZvZgGVn61K98fCq1UiufSs3H48mjPPMAj+eBUvEMzWtVREAuAWFhYRd2dnZm 5/fHLMixwKrwaPp9/SOs8z1mdvbDd74z+/1IBEEAQRAE0Rjpg+4AQRDEnwMJlwRBEE4h4ZIgCMIp JFwSBEE4hYRLgiAIp5BwSRAE4RQSLgmCIJxCwiVBEIRTSLgkCIJwCgmXBEEQTiHhkiAIwikkXBIE QTiFhEuCIAinkHBJEAThFBIuCYIgnELCJUEQhFNIuCQIgnAKCZcEQRBOIeGSIAjCKSRcEgRBOIWE S4IgCKeQcEkQBOEUEi4JgiCcQsIlQRCEU0i4JAiCcAoJlwRBEE4h4ZIgCMIpJFwSBEE4hYRLgiAI p5BwSRAE4RQSLgmCIJxCP+gOOCAIwoPuAkH8KUkkkgfdhUfZQxEuBUHIzc0Vf6jyoDtFEH8ykmoA BAYGkujZtB58uBSDI8/zUqkUlW/5g+4UQfyJCYJgs9nEMQf5NDWhBxwuxVhps9k4jisrK3O4gc1m s1qtHMcJgiCRSGialslkUqm04fPAZrPxPG+z2Ww2m1QqlUqlFEWJEbmBztxbWwTxsHF3dxfPfJCI 2XQeZLisipU8z7Msa7PZ6m7AsqwhKytnf5w1N4cSBF4QZK1aBY0Y6RncWi6XOzwPxLFqSYkhPT29 vLycpimrlXd1cw1p187Ly5OiqPpKsSybezsr8cLBwrJ8iRQcZ/PzbBkdPjTQt962COLhxLIsz/MA SMRsQpIHOEtYFSutVmtqaqrVaq21gcViyT19OnfTpsCwsODeEa7+fqbcvJunz9y6ejVoypTAPn0U CkXdajmOy829de1aSsuWAX5+vkqVylxhLii4nZd3q1OnToGBLWnawR8Ji8Vy7vqZPad/8vcO6BbS o4WnX15x7sUb524bbo+NfPHJjr0dtuUYX3j0wMWOf4n2d7rEn5Dx/KFfDpzLCf3L9LER/k1WK194 7MClDn+JaqZDV3Lt2B9Mh6juTdfhu2TMOf/L3gM5CJ3++lh/qhkbkslkHTp0kMlk4kUVCZdN4gGP LqvCpdlsrvWO8jxfkpWVs2FjgFLZU6MJHDxY2T6EuXhZo7sq0LKsDRtcAgK8g4MpqsZJZ7PZDIbS 1NTU9u3bt2oV6OXtqVSqzGazl5enq6tramqqi4uLp6dHratynudzC7J2nd6kcnXpOaTr6PBxfq6B aYaruFiWFG/YdXqTn4d/kH/ttuwsKQufnnZI/Ln9M599+Nag1rffXbRgw6CTLR78zHBzKTr148z/ u7pk5URKLoijGOdUbHs5esWNO7/P3XB4Yqj6zu/mwthF85vv0N0+Fzuf3XCyW4tmqR2oSNsd/dLJ Db99Huo43Bf9OHbmydcXzWyjsrI8L2+mXgAAx3FWq1UMlOR+QFN58HOXPM9zHGexWGQyWfX/Ylk2 Jz7eTRCekki8r1yhN28RQkPpCxf909KeklKHBOTEx7u9+qpcXuOk4zguJyfH39+/TZvWKpWS523m CrPNxru6urZp09psrsjJyXZ1dak1wGRZ9siVBEjQbXA7Tm06czvBVxWYaUyVevLd/hLy+x7dkSsJ E7xfqtVW5T7IOODtHxOnd7QeXPHM+9M67P/1qT7oI+HvJow0PTZ+QdTByI3fjAmp/iqfGT9w8rGN iYtDnPus1rd9Wd5JvL9kxMAQgbeUlVuc7pVi9OpDgznQkOH2r8+8/I/WXnKeTV8wcHLkxsQxIXJI ZZGIlEma69C5eER2Msma740RaCXAguN5hx8sviIbnT55Y2woZWONZUxznh7iFDxN047/xhP35EE+ pl79Po/FYuHqkNxI66pSaSjKzWyWnTot/eln2R9/uFlZjYzqqlJJbqTVLcJxXHm5KSgoUKFQCAJ4 jrdarTxvA6BQKIKCAsvLyx2Wui3Jbd8zWOPrIaUkhZaca6VnjbxeTtE+vh7tI4JvS3IdluI4juN5 E6CUCWWcR++oqUBBmZkTIPA8x3EVZ378u1ar1Wq1MUt35Vs4juMs+RfXzZ8ivrjrupHjKs7tWqrV arXaKfsuFnEcx1WkfxXz1dET+2LsL6YfXRej1Wq183/MrOA4jqvIP7d0ilar1U5Zuq+I4zjOeHDp /J9PnFg3X6vVauevO2HkuMyErz47hnNfTNVql16vqOyqJX3Z5M+AY1OjtEv3Xec4Lv/cLrErS/dd 5DiO44wnKju867qx7vYi4/V9kz9PwdLnuj3xwan8ckv+xe9j7Hu571xu5S4sTUj4WavV/nilpPrB krt4+Hh4eHjIL+7+R58Pdj3tyyUsm3wM+GJq1JSlB40cL0DIPn9wvlar1Wp/PJpZ+2hX5O5aOkWr 1U6JmR+jjdl33chxxoSl839MSFiq1U758Yol98Tf7Uc3Zte5fLGM/QhPifns76c8ZHy9b+V943kb IFB85Zt4pvqOGPd98nwCrk3o3jV2fbKJrbi473t7R7/al1vReOV3RfxAiffHyWN5TeWBhUvxLRTv XIvX43xNgiBIzYxGoVC5ukq9vOHjA40Gvr5Sb2+VWq1RKKRmRhycVieeH2q1uvpliEgqlarV6qoZ gFptSZQ2/wAftdzFW6H2VXr5qTx9FZ5eSnc3uatfSx+J0la3rao23YCykqLSzFPfzdyIiQNayWwC BJuN53nBv8/0I+evXj39k2zf8mMZJp6/9a/xs9e1fC0h+Xzy8SMjW8tvn1ozZ7n/octXk/e8tnT2 dxksz3N88R87/vZezvtHjq+JabF09pRDLeYcP/LTqKTVx28YeP7WmvFzPN89dPXq6dfKl355OIPn YStPWvneey1eOXRkzxdJ69ZkmPg2Q2NiQhE6c83x5A87yCp7Kmkfsz4GCP0u7viHz3bgbx8bP2f5 uwnnrybvFJbOjs8287f/eG/1f9YcuXz1/OmRreW1t6+k6jRqfUxo6Mw1x08v6Ki69a/xs69HrU++ ejlh07Clc54/dovlOb74j30fb6rYmXBkakf3aseKYyrKTeXluaf+NW/X1E8nBBRXUINj1oQCM9fE bf1wuIq3+eL0/LfPvXLo+J6vJ67+23FDjUPNnlrz/PKCsQnnL29d/LIMf9gkHM/DUp60+uNN2p2H tk7taFW0ennFkatXr/70N9nyb06ZeP528sY5y8vXH0k+v/Xjp/vY35hmYrMJgMDbKt/Ed6rviGrU e2tCEbrm0PG/j2t7+9Sa2Uuvr09Ivnw+YVjW0udXHmObtCfiB0r8fIF89aOJPPjZtaoBJl/zEslm s3n4B0gEnvL2gqcXfDRwdYXZjCI9ZSiRAO5qtRj4apWiKIphGJVKVRUlq55BYxiGoqi6t+BtNlsr 99YKyD3kbm4yF0+FWkEpGI4pZU1l0nK9zdjKvVXdtux4mwr47o3nvwPGx37120u9mTwdAIHneZ5q 3VFzcd/GnwuMboBcwrHZN7YAX70aTZcWlUppqYS5cWoH0OvHT/9uqzgLpLLMu7xMMKHj+lPvtWaK mb79sDL68+c7V5SZu3dEmUrC5t3YAfT6z9q/H5XlJSKpA8vzPHIwZc1vz3eRllX494a3DHx5Ge/j AQ9PBVtq4ni+8rNiksjdAQ9XJWsq57Kv6gD8Z/3So7aK/UBQOcP7hUwEZk5/690Zk/7SO1jC1die t9mr4U0WucpDoBRsOcPeurEFHbc817k0O48OGf5xx8+OX83p8xRMwPp1Mf42g9nK8rWON5ux/O31 MT/+KrtttABmiSIQ8FTQ5aYKjrflA9/+tqSLVF/Roi1gq3HlzOec2oHYLSPporxyl05DO6JUsIm7 P3P9uih/wWhmac9W/gUXN676WV8EeMs5nr2ZvLlj7ObOQmlRuU+/Z3rvK63nfawHm33ss0/2IsDV 0X+Ww3/0+7P6q+6cCwIAG8/zlGCqvSOsRaLwgAdFsQzD3ji1o2Psls50aV4RPWr+3z4bezzn9T5B TTebWTW0bLIaiQd+q6f6s0S1TmJBEKSdQ4tSUtq3aEG18IW/H1xcYa6AXG6TyYoMBrpjqDjiq1VK rVbn5+d7e3uLj1uKQVP8M5ufn69Wq+ueRoIgtPfumGO44SJVecrVnnIPBaW0UGYAPG8zG6ztvB20 ZcfbyoF3tpx45Ql3jjHpC4o53iaI0dKU8tGQGOuMRbOHd7X881tGEKwyGoC1rKjCTQpYARtoIGro sAndYHlu/FQXVxnPczYBntbbt0plYFkpYMkvKJHDUgEIvE2sIWrYcz1dBdvYZ9919+B5xgJ4y0wF JRQ4iwDBxvM8x5oFCLyVYdnqnbWwDCBYjQyrgExmBUYOHv2cp5Uf++xUdw8VL3j97WxiVPyOLxe8 9uXz/9g/LYKrtn31fa7gBdisjMViBQBPs6GEpcAa9KwnLADP2QT0thryyhydX5e3fX6890dL2vIm Iw+At1iNAG9lLKwcvA3o7WrKLaFgsXAAOJ6/cwUkcdUAVnNZhVUGa3k5xKEiLIBKMBSV0QBu/uez N5ZbF/0wu1s5+8PvFilvtZbBM8haYmYB1mS1H55GTs1qZG0GLfrX07A5jDsSSCU2i6WqOt5mg9iA YBPq7AjLWQUInImxKKxWKyAxl1SwAFtUKgAW3NU9s8bwlVda5GK8CT34JTaq3tFaky82m81ncLRJ o8lSKAQvT7i7w10Nd3fByztLIS/38dUMjhaHpTUnj/iAgID8/PzCwkLxbmDVdxsKCwsLCgoCAgJ4 vvbslc1mC/V90kPhZiww05BRAiUVJFKBpgVZWZ7ZQ+7a2ffJum1VtWkCJKZbGRkZ2XmFFVaO42wA bBxnzElJBF4YP9iPL74BgOUpv9BXgVU7k/QWzmLU641C2MCXkHhEz7m39PdVK3gzy3EcDwic1d41 QDwyvAAIPE/5h74KnLpc5NWypV8Lb95i5jhOAHhWnP3iAfAcx3GCuy9+N9aeEqNkHoCh1GzhOM4v TAvsv54nadnSv4W3wmK2WIrTT140hg2etuT/BuHnIlPN7WscMQEQeI7jKP/O43HmpyM3OI4z3jy+ +Az+8kRL+y6wjo6W4cKqf6fNntXXWGKu7JMqGDBWlFX2X6iwiG+lULnvlaxuHUbgm083nbuRcmTT R8uuw4WHuPs2q1ib8freRLz0wuCOPqW5qYDAcFSrHr3OfLn/hqHCmH1u9eLfK+cujdk3so3ibLLx 9o2bt8U9NN7Ozr5trN4ma2ZsnP2qtg7eZmVqHBpeAGCpd0d4ADzPcRzVbeD461/+csPIcZzx5M7F GDG8ldTR4bpXJFA2hwcfLqvUmnzhOM4ql1PPDMk0M+k8b7By5azVYOXSeS7LzEj/Mtgql3McV3fW RhCENm3aXLlyJTU1tbS01GKxlJWVpaamXrlyJTg42OEUJMdxPGN7osWgUn3F7dyS4pLSklJjcUnp 7VslZcUV4X7RPGNz2JbYoCtAS2v03xWw2XiXTtFv98KbzzwVNW9f4IgOK2d/ea3YdeqBb0N/WvzS s6OenfjSsbwK+ROvr3vPZ87EoYMGDfrLiCUZZrFCQbDxPM/bBAEd7D/KBNgE3mpynXpgjeabOX8Z NGjQoMEfxWXwvE3mAZt9vwTBXlbaeeTbWDNn1Kgvr5vudMzW4on3BqXGTnr2k/h0k7zngTXvff3W hEGDBg0aPCIuw2wtvfzG9DH9+/Ye/49f31szWF1z++o7SAmCYBN4nrea3GN2f1nyRcyoUaMmvvH5 q19uH+DOVt+FWky3c9LQq6e/cGeqzub1zNuD1sx5edQnh02O9/2Ofu/v+7BvwQcxb6cHPT+7A4yC pebuu/SfOxub3nxq4F92ZQV2uL58efyNloPmze61I2bSuIkzd3j0gtht3py9OGZmBsPzPM/kHY15 42g5z/M8n3d05sz/Ztc8OdiKBphrTDnaBAFwpW31vYlV747Vpe8bX7+aFzNx1KhREz/Lf3V7bGRF 7dn7+/KgP82Ppgf2mLoYtliWNZvNRqMxOTm57jcUpVKph4eHqyAU/vqbh0Ti6u5ebjSVCnyLp58u l0hKS0vrzkICkEgkKpWKoqisrCyLxSKVSgVBkMvlrVu35nnebDY73GWxLRd31dX8ZIEqUyqlZrNN anPv7B9RUWaury0AoNStW/swhdm3TVxlXerWwd6G7MwyXuXfuoXAWFxUcpYHx7IVRQUVcq+W/mq2 wkIpXPiS7AKj4OEX4EFZLTwULoqS7CyjoG7d2tuQnVnGgXbza+WD7JsFHGjfNq2k+px8o5VSeQb4 u1srLKAUSr4ks8DsG9xKWpyTb7SCUge39i7JzizjoPD0b+kitQDG27eMXFV3FX6tW1IWi0Qoy71t Unn6+btTFRZe7EyRzbu1r7JC7FvZrQKDpdb2VbW4+QX7SIpv5hsB0K6aQF9XpsJCKVxQXnhLbwJ1 ZxdqodV+rXyU+hr/JfHwb+Uq5SDhbuebWzrY92psEs9WrbzkFJt/ZvbwWdGrf470Ud7ZfUDlFdBC ZbPARS5hwXEsV15QioBAb5upnHJ1oyRSKVOUWWAE5d6mtaYkO6OUA632b+WDnIx8K6D2b+sj0Wfk Ofg+rjNoN99WLZRF9b2J1d4dQObdsqUbGAtPuShReOuWqfa3NO6LzWaLiIhQq9UqlUoul9f3ZTbi rjxE4dJhTyQSiaurq0ajcXNzo2ma4ziTyaTX68vLyxvouUQikcvlrq6uSqWSoiie5xmGKS8vZ1m2 gVJSqVSlUvn4+FRvq6ioyGw21xsrGyehaYrjOEBC01Lxckx8UeC5qlswEoqmJOA5zuk3Q0LTFKpX 4RBFUbDxdbahaMpWVVJC0ZSkWk21+1Z7+/r702h37r6nteWfWTvny8MIBjLRfvrylRPbGI21Q7KE oilwHA8JTUvtXZLQMlrgrPfcvWYiHvvKs6JJa5ZISLhscg9RuKzvCkK8u1019hQnjZzptnifR1ws Q7yh1GiRe26L+N9waRHowZvLrRxkrj4u1qycojrjVwIAKIoi4bLJPfgHiar8/PPPD7oLxMOPdvN2 V1EUeHNhsanxzR9XL7744oPuwiPoIQqXa9eufdBdIIhHRGJi4oPuwiPoIbozThAE8TAj4ZIgCMIp JFwSBEE4hYRLgiAIp5BwSRAE4RQSLgmCIJxCwiVBEIRTSLgkCIJwCgmXBEEQTiHhkiAIwikkXBIE QTiFhEuCIAinkHBJEAThFBIuCYIgnELCJUEQhFMeovUum54le+XifRlmdBoxfuYA3wfdm0cQk3v5 y28OrNAZw9QKrxYdv/xiQgdF46WavhuZp//23SUAT8+cPDpE1ej2zU488YCAyFHzhrZ60L0hmsyf Plxe2fpd/8351V5QDI9oO3nSM0NDNeAsZ5Lz4wFtWBkJl02v/Mbbr2/bDgDQGS0wXtdzaIpwad7y /uIYnYP/WP31gvGOoiHHlGzUZQHoZH44UlFUnXjtLPMedF+IJvSnD5d1WOKTr8UnX9u8+uOhPnAF ALg/4C41CT715Knjqbflnfu92Mtx6OdKs/975HpWdnHrkSOHBt/XIMuZqkw5N8RYOeuvsz4d6leU q1e63k+b1WrOcvx6sZEDYEi7/N/zNzOK1ZOmDwx6OM9f+lE68Yg7Hs7T7e4F9L7wzyHKoqxd3/y8 QGcB8MuprKEjH3SvmhJ/fN2h2DxoJ3Z/sZfjLbh83eQ1JwAsHjzmPhtzpipTTjEAQD2qf0sAPoFN NX6XD5ozZrMVMvE3maLkt22vHwcAfy8FgFvHD7y+zQioh0ypGy5pAOB4jqYeyJnNcTxNU6CoB9E4 0ewelXCpoj0VcrfA9q/M7LngrRMAwNbdiE89+tuGuMvHdHqoFTojJkT1jH19aIeqMVFp9pZNh1Yd yNIBgCKsXcd/2SfjDAf/veezbWle7dRJ6ezcmePeHd1JCQBIPbh9UfytFhHad/owC2IPxQNQa1Z/ 8Mr4DoY1i39akGwEMHfmlA9Ht69so7GqQrV/G++64sMtq/IAqFd+8sqL3TUAe/DbtbF5AJB0YO8s nezJZ5+f2VdTY+dKr/3jy7Pij5u+XXtO1WLOogldGuw8YDy68+CyHZeSjAAQpta8u2Tm6GBV/VXd kZGwPWLFNbGSbxet3WBmh8dOHx2sAsyndu5fXFmnNqzTnJmjokPUAGDJ/uKjXWlm2ZOTRvUsTByy Jg3tnsr8Zqhb7beJ6tC3Z4c7vxpWrgOAqTNnjA6W5xzdPWubUWw3Zt7XEaGRi97sU7WpnMs/+O2B yQfyAUwYM+arGT2VcMyQdnrRkriNeQDUC2cOUN+4dKqgPGjQ2A+Htqqnn3/Ja/DkMaWd/WjJno15 ADTzx7TYXqfFjJMJS785st0IAMP7PbVoztC2TTQYJ/5nHpVwWbkn+TfFIQ9cvBRARc1NKg5+fmQV gAC11mQEsD3xxPabstxvopUAl3s66vW4ajNmFl26OBmnXznj64V5ABBWaASwYs2WlPIpP05qD8Ba cis+XY/0PRu3VZYz6l+f/8Xr1VpdsebfT4R/ODpYDjhX1YGqosaYD3/uvnN2FwWffz6/qv7tOuS1 L6wVLk3ZN1blWcSfden5OpTP4ICGOs8nLP9mYqIFANRqLYxJRn1KCYfg+qqqcSjNubeqfo7XZQF4 0sgB+jVzvl6QDrFOGI1JumtJb12b+95fPxzgC1gu6vTxwPZPf7CXLOQanWs8+++NC/OAsIGLRrcC UJabVfUe6dL1OnPJR9VO4tgP11cV3L5nT1Boqw8dzVkzaUdC3koQfw5TGxeuiRN/1oaJe+2wnw2d PEzm8eC3DlVWr1+yR1+rxQtbv4sSZ9jVChgt8cdPxF806rZO8G9s94mHyqPyIFFh8ZnLl7d8uzbc PuRRPNurZZ2NXIZ+MO7Uxg/1P8zbs3VR3DA1AKRfTikHYNy01B4rZ02fkrt/kf6XBRe+ntJegZyE /WK4WfbJvKNbFx0eowEQv/m3VPsH3X7JiHY9ElfPWBZWFVQ065fMipvcWvwl32gBnK4KrXd/PWv3 RPGjlJ+UagRU0354Z1k7ABg+8cWC/Yt2Tu9Ua9/cuo5M+biH+PPCj9/R73+np2vDLbIFBWJ08E/e Om/P1kW5m9+a3sGlvqpq6TLlr2JtgCZu48f6Xz6e2VWdk7BfjJXDx4wr2DpPv/HFqQCAFZ/vvWIB gKpqwvo9dXjZi9vmhNU3+hMxaQlDtukB9e73osVBaJdJbx2eKLarjtv4sf77oZ41i8yfOyX5k4Fh AIDfb5Y5qtW8f409Vi7++K2jWxfpPnlK3L5qqtFRPxs4edjD6+2xcuEHf9XvX3Th4941Giw4G7M5 H4B22Bj91g8Kvn0mDIDx0t7L5gb3nnjoPCqjS+O15+Zfq/xFsfiDGQM0gKXWRlSHvuGc/tapoxm3 K7jT4uWiqLwgwT4m6jF3XHslAFoVFNIKMO84nGZvQZ956nfaoBCDWnmZpfrBC0le/lxbGppBQdCl AYr1374xOlgOr25hm6tGQ+ZTTlXlf3jzaz09wCAU22rc8Zfbf6BpOH7flO72ezIKlQKgGm/R/mnN nzpn46wxfYYM7ORD11dVXZTKzR7fVUoKNAC2sjnNu1PCaQCaTq9N1mzcrAeyklKNXaousCOiDy8Y 2HCgBADu1j/eOgJg6swXBlQbSatkYrvyynbvmDX3r/OifcFRXXBEV9+dFkvuHvEtCXjqxV4aAP5d Q7vghINb8TX7We/JY8mKT7ZXOL2vL4CgHmETcKbqetxUmFdZOXP298vWshLx12Pncmd2bQ/iz+NR CZdq/2WTwuRWzrtlcMST7X0cP85iPvjtmskHal8oAXduZQ4f1s2n5v+YKkcAC1dsq/ay/lKOuWdo 5S3jdn4taADwaRsEpAFewf5yAPDx7QLo7q6q0FAPAOA4a4M73DDOmRZHx4448GZcPKBLT4tZkYYV imUfzJjW19dhVU7gK5vTF5nsF+/egS0BPaDwV995S4aHtm48VgJHV29eBQDd3hnt7KOLHYLUAMDz DW9mHzx6q+xnfz3b1+xn/ScPUN5ghVmX7Hf6kw4cGnJnpgWZlofjsSfCaY9KuGwR+sLoRgYspssJ 4uk+a/KYN4Z3TN+06rkDRojxgLOf8fHpBQzaV6/HrTKOrVzy1yEtwNjPcLlPYLXHayqjEgcxxllh n+yr8bFxrqpGomSZE58xuYx2pkW34D4//tLlwokz23acWpVuASyxn+7ot3N29Wcnq6pyRuX419+n 8vaNsbAQAGDJLLGgaqLO2kg4A8CkJIjvzvwPooKc7gBrdSIAVb7XKK582xgmz+GW1frZ8MljV+2p z/Jq1bTu1hrIBzB84sQVIwIYxl4t7VZrIoF42D0qc5fmxj8olX/kNWNH9wzyUBgK7ddTNA24ej2h BgAkH/rh5G17AQvLQNVzkH3+8ei5225+vkGBvkGBvp7KqtDjvPutSrzVn3TmhqGxLS+mFDnRIl+U e9tEq8MHRH/6zfyV7cQNrWWcw6qcoeo1WGwuf9+v4o0gw/Ez4nyCpldbtdP1ADD8+8sjAICQ8b00 tf7Pav+bxJYyd1NlFVev3mJf8k6sPHgtI+3CB5O3JTVWqKGTR+FiP8rp5/ZfNsCi3/Ht7vhqZZVe XuIP8cdSS5Qa8V0I8lE9KkOVx8ijEi4d4ur+kQegH/L8F2MmfTJdnG+CPmbe9lSLZsb79un5hZ/+ c8Ccte+8/7Vm3Cc/XDa2HTx8LgBg+7ZtgSO/mPX+d2MmfRQ8dfmPl6vNXtW5ZHUYAJ2sqh6UfaiY dyZk0qef7M2uu4VbUPvhAICNa34YMOnrHWnmBlus2PXuP4NHfjpr4ZZPFq9eJU7domWgq+OqnOgh OjzzjP3ezj9XjXl/7awZy2N1ADB88ohIj9pvRwO43JQFeQCgHdOnbZ2govESB2XG56Z+OmbO9tTa M9SNNqSZMKeb+NOSf26J2m+ilwAAIABJREFUeGvnKieKN3Ty8C0nTxdHzsbX5y/XjPv69UQjgLDK snRgv7gxagDI+yPy+Y/GvP/dyzM+1Yz7Yuy29Ia6STx8HpVw6fCLJwqF/c++DADcOmlX9xPHFcYk o//q9+yfbV36zTIOnt1HpiwbMVUtvpK1UacHFBoZDbrlhzv/unqY/fOwXZefZASgCfaqdsmqqnXJ WvsK1n5J61RV9n/pyhvllZfD8mffmTjL3n3L74a6QQJwbb/ovR7ip1Rn1BebuQZbVPg/oQYs25Ov rTierwO0YT2ObR7rX19Vdchc5XcOrkjRavnPM5ZFqAEk6bK2i081zp2+flJ7oPbb0QCmpET8IcDN wSR00NCx66PEIaclKf1WBVdVY+UMqcIlVN1QQ/59J1z44Cmt/bfWu5dNnFr9vx31s+GTp8u46ZuH 3RkFL547Zn4AdNVqiJzxzrG5PcQWk3T58XkWAENakQcv/2QkgiA8kIYFQeB5nmVZs9lsNBqTk5Oj oqL+B+0ypQYTR7lp1EoAFmO+gVe6qT1d79z8NZUaGA40rXDzqHG5xFnMBpMFNKVUurgp7utrG/dR FW/QGzlQbh5qZX3Xcpy5qNRC0y6eHvI7r9XXIscayi0cx9NKF09XuTNVOYMpN5o4gIP9ODcDptxo Ynilm/pe3gvOcCWNbRfqK/Yt5+j28M8vARg+2f4MbL2NNnjyMKVGE8dC6enjWl+XWIO+ggNFKxVu rvJmvRhPTEyMiIhQq9UqlUoul1MUJZFImrPBx8JjN3+i9PC88wFWqP39am/g5uFZ53smAEArVD6K plnt5j6qojw1jd0foFU+mtqV19siLW8oFDqqyhlK1+aKkjWauNfBGZN5tn/sEUAxPMwLWfnx9rkQ zdvDG3msp+GTR+nR6F7LPTV394eHeKg8duGSIGg3nwnAdljidZVPtrbrtDv2uZ4eD7RbxEOPhEvi sUP7ha/aH/5VqcFgYjmOo928/O9pEE08bki4JB5TSg9PfzKcJO7Go3JnnCAIopmR0WVDmjCrAVd+ W5daBkDTtm2QR0M3cx+6VAoAmrlXjVaekbB76eE8l9Y9F73Zxw0w5WanlFhomXtYqC/9sB4x4tFD wmVD7jarQZ1MGACAdgMzv4lGxpmoD88AWPjJvJjuDX3F5aFLpQCgmXvVaOXm21nbdXoUl3wEAEhL +GnINiPUvdO2jvR8WI8Y8egh4bJK49kd7lGhmQPoykfXA9SO1/8gGmR/4LvyfJUDgMMHvgii2ZBw WaXh7A53ldVAvW31X/t5Vn0VknIDEDpUv3/oXXbpAadSqMeD71X4lLf0Uxz+Dw2A43g8XEeMeET8 6U+qu0r/wOlvrNv4W9zvBUlGC4CwdiF/e3PM0FDPRrM7OJ/VQNzcx1NV6yFqJu34219fADD8reni /Fr++eMr151YlW4EEKZWdNEO/urNPtWrbaDR+jIZVLYiH/6KtviXnbHJlsVLFszsWnc6r560EwCA opTTq9YdXaGr6tjQr97s6Uyv8s8fX7nut1Xp4grtmsWvjZgSfWd5J06fsWnjgdhEcbJCMXWYNmba wHtLwJBxcPtHv95y9Yv48p1+1YeYcmPmloX7YpKNACYMe+aTN/uJy/HZT5Ju2neiuAVvxcWjdeLP 013O1p9MwkH+iV7ft8lOLEA5AhZ9+lzlN9kNWxZvOZAnn/HB9AF+JD/Po+9PHy7vKv0Dk3dpQWIW oBjeTh2fbtSlp02O/Xbbv+ZH+zWS3cHJrAaVZLI6F9wcZ9yeng/gSTMHwHT5YNiHJwAACm0AkvIs uqTCL9+sUaS+RhvIZFDVyvYPt4gFLQ7yO9SbdgLAlb1r+6+5k4lRZ7ToDmQtebNnowkeruxc2399 ln2P1JYko37Bin8vOBaduXCgW83cHmEBCl2eZeOBhI0HdIc3z76Hh8PNJbfidXoUG5fUfD320y13 +nbg0PZCOndhH2X1k2SP+J8FDSeTcJR/QhIYYd2eqAfye/8xKKaXJwDD+aSY4/lQd/uCxMrHw58+ XNZI//B+xB/f/DtWJy4/oVm/ZILvpfgRm7NgT/8gVwZExC0bEBmqAcBc3h84/wxgScuriPZTT/vh HcxZHpuO4RNfXD+lU901hebPnTJekzn1wyM6MatBQ+Eyf8EnG3u5ywBrscXvnXlD6+Z3TTuXAgBQ rP92/uhgCpy5qJSqOxfnoNFqmQz2vNmTyzwe9eYhnfHS3ssja40i584cN6o15d7WpU6t1dNOzG4L MKV6E+0CAAVnZ9ljpXrz17OGhqiZcn12PtyA6oulOezVLDFWBnRL/ueEtorKxXSTE74/2XVeX3ll bg/16iUzxnf1zD+5P+zTM0D+kO/OFizoibtWayqzinrlx5MHuGd/Ehu3HUDyf3/LjRgaSFVbLcN/ /cdDfDkuWOHi/sG4oR07d9DIAZz69osRB4xIv5xSHh3uCtTMP7FibBtDsaJnuxZh2+J0wMIduhm9 +ilhjl93BsDcN6JIyp3HxCMQLkXOpH8ArWkVqTGmnr9wNcsAqzlMXOrcfgwayu7gVFaDapKS0yqX UMyZPMdBuNQEegJ6wDL9zeXzJz81IurJLn61v03ssFEnMxnMnfvXD6PrD+j1pJ0wGQrF2qbOnDw0 RA1A6arpEOJMr+wF574c1VYBQDX42QgcOAQgKbVk3hOw5/Zo9+TIrp4A/PsOXBxwZkEecDE9Hz2b apnchR/PerGXGmgZO/nU9s16wJJVUoHAqucQ/KsPZn3qSyZRXY38E/6z2sXFpAO6E+dL+0UazsSk AwiZ/FTtFTmJR9WjEi6dS/+Q//v+sL+fuYfqncxqUEmxftmspzzBcTxHy/0dTc8FDRy27NgPsckW wLhk86Elmw9NGDNiyYw+1QOHw0adzGQQFNTAs0r1pp3IOmdfgfGJUK/6CtfTK3vBID/7YJb2aTkB 2C7G06rcHhHBlaGHti/fabxZUI6mCpeKyjWkvNq3BuokiqhM7AGg4WQSVWrmn1BFje+Ez68Bxn0n b5SnnQEwdWZU3RU5iUfVo/JWO5P+wXJj3t/PAAgL67Fi9qBQZc4br26Lr12R4+wOTmU1uMMruI2m nnxBlWjfaQs/GJpyYW/c8QWJ+QC274l7su8T1S+oHTbqZCaDhjtcX9qJlpWV5xRUINTx894Oa64q WFhmsa/ZaSq+UvXfVbk9dLm1cnsAvt5N92CVvPKauySrMp1E9c5WS+zRUDKJ6mrmyfDv03cCrm0H Vv3z36sAwP+1Z5zNI0Q8Ah6rL0EqWgAA+g/p1zPYkyksyLS/bv+b4Xx2h8ZYG00IZsi9lV/O+4eG z3xndsp7VVlwGw/KTZHJoN60E25qe+UrPt99Vm+PFEw522iNVQWXxF0Qj17q75fFQX0LX5c7uT10 uvMFPAAu9+LP4ng0rH1A0/3JTs0oAgDu9sGD4o079ROtHI+yG0om0QBF2xejquVomzikC3mI9nHy qIwunUr/wFUAAFat+OflnxRJefYFyRfMX+P/9czRIdWzO1yYO2nKh3UTEDqfPqGxDTLj10ftsWjb te4V6pJy3p7y19/hE+w1G6UD+8WNOTFijxF5f0Q+/4c2zN+9uCQ+zxI25sWjM2onH69Hxa53/7nA qJgQ0TZIYThcLe0E7Rq5e9hvzx2wAFlDpv59QkRr5GZtN/VO2zqy9olSq1fBlQWTE0Lm3JwfYFhy XA8A6h7vDW0JYMYHvZfMPwPkj3h1+dxhvocPpInBdP3sXkrA5Fy/G7Xqnz8c+7V1cFaWuIRl2LBh kfXMK1YO0vVDnv9CqzZWTl3qY+Zt/9cXEzrU/0b3HhOJRDGPkPrNMSTt7ePlURldOpP+QdE2dm4P 8dekPMvc6SNWRolDD32+masnu8PdZTWo5OposFejKk1oRwBJ6VkrDlyLzwPUmpWfvDU6WF53y7qN NpjJoGZZxxpIO0ENeHPe4emdxLQT25OztucBrcW9abhX1Qqmp4mxcsKwaN2Pz4l3jT27jkxZ9swE NQDjCjFWtuu0+9sFjne5Pqr6fhWLaxaO6aTT2WPl8GEj9r7Ztb7iDSeTaCBPhjKk+3w1AIQNGxJJ FjR6zDx2ySdgMRaZeKWbp5sCAF9UYIDSxfNOngknsjs0Gd5UXsEwPGiFp8c95AW8v0wGTqSdACil UuFW938bqtZcVMrR4OGm9nSQFoI3lFYA4ED7eDTLWhicxWgw8aBdfJxImNFoJpK6TJcPBs8/ASg2 /2v+0If4cUuSfKI5PDoX485SqKvdhKF8/GpdrTmR3aHJUG6uard7T291f5kMmiftBGiVT0PP1VCe HneVQffu26/x/jai0UwktXG3vpp/AgAiBg9+iGMl0UwelYtxgmh+qXt+WQEAWD29x+M30CAew9El QdyrDmNeyx0JgFLeXypQ4k+KhEuCcBotb/4ZbeLhRS7GCYIgnELCJUEQhFNIuCQIgnAKCZcEQRBO IeGSIAjCKSRcEgRBOIWES4IgCKeQcEkQBOEUEi4JgiCcQsIlQRCEU0i4JAiCcAoJlwRBEE4h4ZIg CMIpJFwSBEE4hYRLgiAIp5BwSRAE4RQSLgmCIJzyuIZLrvDIuqUJVwqbsMqKMoOhrMLWhDUSBPEw eVzDJWxlJXSRpQkrZC59v3r193+wTVTb8Y0rV245zlT+fvPwxsNp5U1TN0EQ9+SxDZeARALcV+Zl Tn9p6dKlW8+KQ1R5j9kzZszudR+pbOvQn4tPLrjTXBPWTBDE3SOJmgCu7NKJo/EndQA6RDwT1b+7 pxzgyq6cProvSQcAYaPmjuyYc3zv9qRUAGjdfdyQge010qtH4mUyWU7ihqVFI+Y+0/7mH0d0CBsx oKMcbM6lU4fjTxYCLTpEREf1D/aUc/or29de6DyuV9nvO09mIWzwC0N7Bjd69HNP7r/S8dUu7tVe 4ktOx+09k1kGIPDJZ0b16ygDc3rbz+Wdn2TO/ZZWBveQp58f3k0JlFw/+vOhC1bA78nhE/uFNMuh I4jHyWM8urRjzu/9/tCZayOmxcS8Otr0x39X7zxbAeb83u/jT17rN/rlmJgZL3TzlcLm0iJ8duz8 92JeDLl1eef5HBvkbXv0BRAQMXKGtiMNsCVpafmsDSg4v3/rwdNBI6bNfWtam4zzP63ef4uBzcbm yfIO79ole+LZfu1lVxNP327wut1iRvioZ8NcKhJ2H2XuvMxf2rPpTGHAxBmzZ0yKNp47tPt8EQCL uUz322/KXhNferZ3WdrxXAYoOb/p0IXISbNiZozizsUfL7A271EkiMfAYx8u2eLsDFraaUSXADfX Fh0jO0npW7cMpuLsDFradkTfrq1cXLzbtvWlIfcL1ty6fOrYySuMREIVl7OAi6cGgLtvgLcrLQVk UolEKpGCLbiZRlGdn+waKFf6RY7qJpPdzCtmJBIJgAGT3tY+0aV71w4U5dJopmqG8o8a2x9lF+Iv FVBKGQDwRVdzEfp0Pz8lpfTpMjDMpeBCmhWAGYFPvxTVxc/L388FMgAFaekArp84sPfwGT1Qamqi OVWCeIyRi3FKIpEIgtRms0khCIIgkUgqX7TxPE8BNpvNVpbyxfe/SEMHTuobJjfoCgRaCnCsFYCN r30znKKkAASOAw3WygHiPCkAqFykPM+zFt6pI8+z8Or+7JNXfvltP+du9QkEwHMATdkjLQUAHA9w gJtaVbMwB2g69+ih5vknnqA8/JX3foQIggBARpeQq4N8geuXrheYGEPW9esA/N3d1EG+QObBUym3 KhhTYYGBMZtkMpk2vLMXVZFzUwBYFqAUCgCG4sIypvrYTd4iKBi4fvF6AcvoU1N1gK+3u/0OEMfz d9vBVv1GhrlUFJRZQQGUXxcNdCculANgsn/XVWg6ta8MhDVq9gvpCOgLzW5t2rRp06qFqtGhLEEQ jXl8R5cKgKcBuES+9Aq3f93+jd8JgiBrP3Da2H5usIgvJu7ZdFIQJL6D574U3NsXx7avPtai+4Bu fpmXEnW3Ovdp2WpYV9+45H3fn+7/1vs97JUCLXuNHmc5vC3u38k2G02HjJr+bFtXidUM3DnccqCR BzTpO7fC3aPGRl/flAAAoLqPffbW5l/WrTwDwCW47wt9/ACGltW5b+7VfVJ08dZDm3SHACBs1Iyo NiRkEsR9kQiC8EAaFgSB53mWZc1ms9FoTE5OjoqK+l92QKVSsSzL8zwAhUJh4zgbpDQttVjsT2NW vUjJKJZhlEq51crLZDKbjbNaBRtsEkGQy+UCz0NKW60WhUIBQCwuk8mksHE20HI5yzDiNb5SqWQY RhAEiqLkcrnZbL7nzlsZhodMqWwsAvJWxspTMqWMhMrHTGJiYkREhFqtVqlUcrmcoiiJ5L4emyPw OI8uq0eryhDJV79WrvaiFQDDsNW3EE89lmXFTaptDwBWq/1ONF/ZiiAIVS3yPH8/sRKATCne+mkM JVNSTm1IEESjHvu5S4IgCOeQcEkQBOEUEi4JgiCcQsIlQRCEU0i4JAiCcAoJlwRBEE4h4ZIgCMIp JFwSBEE4hYRLgiAIp5BwSRAE4RQSLgmCIJxCwiVBEIRTSLgkCIJwCgmXBEEQTiHhkiAIwikkXBIE QTiFhEuCIAinPL6rqTeGK7hx9Tav6RzakuYKj/x7HRf5SnSXFo2VYlMSdh5H+EvRXeT30XZxcfGu Xbvy8vKqJwwQBMHPz2/8+PHe3t73UTdBEPeIhMv62PKTDhzC4A6hLWnYykroCkvjZQBwxbnFeKKR vGWNiYuL02q1kZGRUumd4T/P86dOndq/f/+UKVPur3qCIO4FuRivl0pDUW5K+wGSSCrT8zhmY8oK C/UVLEcrJRKJ48NqY5mKigquMpRyTEUFWzuBo6ikpKR79+4cx7Esa7VarVYry7Icx4WHhxsMhvvY J4Ig7h0ZXQIAbIbjv6xOSgWA1t2fHjKoj0YOAQCcSpPJFF76el28RCIRBIGmaXQEAK7sxt7vd6YC ALo/PW5gn/blKfFr41O7P/v6M6Ge4Ar2fr1B/uzrI0M961YoCILVarXZbNVHlzbexlrZuhsTBPG/ QcIlAMCGlj2mxI4LYrNOf/fzb+dDOke3Vzpd2HRu/wGZrP242RM7KgoPrthwTrxst8l6Tps9rqVb 1uldP/26u03n2C4de7f/z80L59MHhT5Zcf38TVnvV0O9HSYc12g0ZWVlNE1LpVIJAIlEEASbTeA4 K5m4JIgHhYRLAADtGeBZfvnU0ZLS21KptKiMARyHy8Lzu9YdSq36tfXgaZPCYSymENotQMlb4B7Y EecYscpA99yMU7/mGUtMFEWZzCzv7t+9K25e0uUYgm/HXew4ZpaHo1gJQK1W0zQtk8lqjC5tNkBw d3dvyh0nCMJpJFwCQNmNhO93JncaOCqyq6b4cgYtrXdK17fbiNiuVNWvNikNW4FEIhEYqxQAOIYR r99tNxKW7TorGfjspLCWsotpJyGhADq4q1ZyOWn76rUyWdjkEE+Ad9iKu7u7QqFQKpUURYk3xwVB 4HneYrGQcEkQDwq51QMATFmRTBbYtUsIbS7JBCycpb5b2wKloKuRSwFa5Q4g8+DpK+lXju7+Tyag AMCWF1N0ywEdgn3MRQUAeIYFIPcP6QrIZLLgqEg/ynGsBMAwjNlsVqlUCoVCLpfL5XKFQqFSqSoq KsxmczMcAIIgGkfCJQB4t+3ui9s7vv9qXxrX1ReZvx7PF++pKOwbKABFvQNx976vjvGTSE7E7fyd bdenjXgDXdmmR2+h4PgPX32Tznv5Ar8lpjCATap5ckAw4Nurk38D/SkuLj5x4kR6enpmNenp6SdO nCguLm6qvSYI4q5IBMGpm79NTry6ZFnWbDYbjcbk5OSoqKgH0hMAEolEKadZDhQlkYKz8hTPWxUK BQCLxQJApVKxLMvzjseDYnGGtclk9mtni8VCURQNcFK5FJzUZrNKKBvHwmY4vnzt6cjn39a2auAv VWlp6b59+9LS0qxWa9WLMpksJCRk1KhRHh4eTbr3xCMoMTExIiJCrVarVCq5XF41q0PcDzJ3CQCC IJgtVgCV8dCGykApavgSuKo4y96Jp7wYXHlz5Us8gJyTu05LpaN6BEvruckj8vDweOmll+5lTwiC aDYkXP5PtXpq+rwBcp63Nr4pQRAPGTJ3+T8lSCQkVhLEnxQJlwRBEE4h4ZIgCMIpJFzeJa7sxtnj RxOOnr5y6z6XHXKiLVN+fpGJq/1iUZHBYGKaqazJUFRUVFRrC85UlJ9vqLscCMfUaoEzFBUVFZka 6xvDcDV+bbCUWKfByS4RRPMh4fKucCkJ3+9OPGGANS+3pFmXu2ByEsb4BYeFhQb7jUnIsccKw5W9 A/yCQ0NDQoIDB6y8UH1704U1mpe3MPdTlkv9QKMJDgkNDQ0N1Lx8MMMev3ISvvALDg0LC/EbszKn Mj7lH90wZoDGL3Dyhcoox2Ts1Wj8QkJDQ0ODNS+vTHUUk7n8ox+MGaDxC/zhQuW6SsyFMX6B9lLV 6q/q2oYBYp0hgZqXq/bFYZcIormRcHl3BAtFtRv57LBhE0f0cH4RjruXvzJ8YsjqY3q9PnFlwMTw H4oAMBdi+k8fsjlZr9frc9O2TQqpXuDyvgUTJgxQ3ldZ9ai4Y5l6vV6ftnJC/OS1pwGg6Gj4xCWr j2Xq9Wkr3ReGrzglFuHkreZ8vLJ6JbS6fdwxnV6v16clTohfuOF4ft294jjX/nM+noVqT2TQIat1 aXq9Xp8Sp01a+N/rtcaYypHbUnL1er0+ZXFY/Df/TW+gSwTR3MiDRM5jrxzadCBVAsQv/sfeZ16Z 26rw2NoLGPWk575f/jt42ls9NeylE0fjT+oAdIh4Jqp/d0859FcS1l7A8HC33/f9VojWwydHyTOP /5KUig5Pvz66j2c9h59JTVwCbeLILgDCJ87RxvQ/nDpjwNWN8WGLvx/a1lRkoD09/X2ql8jZtiJs QkrQfZWlERkpftfIs1ekFruzTUDe4R8QtmxkFzcAYz9aFhO5ITUmsoMSQZHRQdwVLX6uqoX26RIp VusZGqnF7uwCoPY3l5RBPYcGMflhMN4p5uYvbqWUlQBuKvGIlG8Y3drySdbrT7j62PtKAwhwUwFI radLBNHcyOjSefKO2hH9/CQSv37TZs0OcZdJOAt96/z+PTeiR4z2d+HP7/3+0JlrI6bFxLw62vTH f1fvPFsBiNscjCvTPhcdKMs7sGXjBYSM6NeezkhK09c7h8hZWSDERQwdjBWAqYIpKy6EbkGwRhMc GhLop9lw6s7wjck4uhETevrcb1m7/KOvxibNnTPUDbCaytDFvmQcV8ECeWVVF7+c4yei8o+ujE3C nKFh9e1crUmMjIQ177wzSxM8BIsTx7cVw57iqXnb+rdUAGAyEj54550xmpAFWLZkfFs03CWCaE4k XN4F2lXj7SEISncfT3e1QgKwEonfpLenRHbvFqgozc6gpZ1GdAlwc23RMbKTlL51y8ACYCWSNlPe Hd25c3tfgA4ZPuHpiO7hYRKJBI18KU3laOg5PC5Fr9frj62cEDtie9W66in/+Vm7LNqzKcqaUvdq wp6LWH3sw+jKsaGL3PlrkNS9n4Q9t2T1sbRof2cLBYQPf23qjPWLZ+kWxOxIFS/G6Y79o7v40ACU AeHTXpsau36xVhf7xd7KpfPupksE0VRIuLwrNnGJdf7OF+095bBwHAdQEolEEKQ2m00QBEEQqn1F VwHezFssAAS5xGq1Mkwj97VpmRy4bB80KWXugFxGA2XQDuvuAwAdBwwG/ptmn+grOrwg6eWB7e6/ rCl1R3Dk9JXH0paP7yK+InNzR3K+WBntIgfcHUZiUeqOdyKnFyem6cd3cbBEfJVaSd+UPkFdwnuO nvl/i8N03xxMq7210qdDl/ABo2d+uUy76stfDXfZJYJoQiRcNhG5OsgXuH7peoGJMWRdvw7A370q MNgAgAVgAYBGFztQdoiai6Rtv2UASP1lbTzmD+3i1nHwq0iKOZxqAnD96B6EPRfqBgDIT16CuVr7 Zex9lOUyFke+jrmbh7ejqx7d6RA1DbrY3zIYwLT/+1jMndFFbIcDx5gBWBkGHABwOQcjX984d/Mb IbShqKjIwDi8QubAMSzAmBmIxRhDvviMkCHlmg5eapm4Wf716/nlHMDk54vjYMOFi0nwcqMb6BJB NDPyd/nuKap+kldLHeES+dIr3P51+zd+JwiCrP3AaWP7ucFSfGcbqRyA+s4Bpxv6W+X/bvLmIRER GgDQbrvwmT+AoNGn1s+NjAwGAEyI070gRryMpF8wf5r//ZdlyrIArJgcsgIAoF2WuWeam3908ua5 ERGBAKCdn/zZAHHbK5te7h8bD2BEaCCGr8z88UWU5QNYMTnSXnpx4p6Z4bX2ynRlU3D/WAAYEbYE ExJzV4Wm/xImvgJgwjLdS+Ko1rK9b1/LobR3u96aF9Y/3v7fU+N0Y90A1NMlgmhuZAG3u1N9VTeK ouRyefXFihQKhY3jbJDStLTuNiqVStxliUSiVCoZhmnk4HOmIgOj9PRxo2u8VmSCp79P5YjKsEYT gmOZM7u4NVlZBx0xGBh4+tR3J/++cIzJYGJAK308HXWDYwwGEwe6VuvN2qVHAFnArTmQk+3uVF/V jef5Wgu7Vf7vnYUxq29T9YMgCE4tik67+fjUjiC0m49/9dc4xn/Z6ic71gk091PWQUc861TWZGil m4+y/tpppaePg4vtZu0SQThEwuWfHO0/etr4B1CWIB4/5FYPQRCEU0i4JAiCcAoJlwRBEE4h4ZIg CMIpJFw+xB6T9S4b25qsd0k8JEi4fEg9LutdVrqy5R2NZtaF2qXIepfEQ4SEy+bEFe5funTp1vN3 /4l+bNa7BACYrmzpH7MRKEftI0XWuyQeIiRcNqPCy6evy2T0rYRlSw8VcuDKco7uWrd06dKlS9cl nM9sYDF2cc3KqVVdI5/9AAAgAElEQVRrVmLh4VQm5/DG+LDFbw9tayoyMLSnf42ntHO2rQib8FTQ fZWl/SMjxe/3ePaK1OJytqnG4pKeYz9ahiUbxGFjUGR09MDu2mq10D5dIrv4A/b1Li9nF9TdL2VQ z6HR/TrUWtrNdOGN/jEL168ejqqV2Mo3jNasvlgO0D727yA5XO+yRpcIormRcNmMvNt08AUkfn1e njXQw3Zr7/ebf88IfDlm7quj2577z7adZ2/VV/BxWu/StOWNqLLFiTGjw8sA2j7qJOtdEg8jEi6b EeXm7QsIHr5+niqU3r4pk4UOf6qli9yvS3hnispJu93gqOixWO/ywoY3YuKHLxgemH8lrQRJqSni ymxkvUviYUTCZXOy2VgAsPKVy19yVisA3moFIJXWe/Afm/UuTZmp0GrLFr84duKsz3TA61GfX6/1 N4Ssd0k8NEi4bE407QrAoC8qq6BdfYKB1HNXCipYfdbN64BvcIv61ml8bNa7dBv96Y979uzZc/To 0cRVWmgTc5d3UYKsd0k8nMjf5eYk9Qof0uPcod9//P7Gy3NfGfvquP1rd2xYeVwikYQMGDcysjV4 x9N/j896l+FVkY6zAu6Vd8bJepfEw4isd9m8aJqmJAIHKW+1SiQSpVLOshyktBQ2q7W+WFnp8Vjv shFkvct7Qta7bA7kZGteHMdxAMDDvsylBai+HmaDHo/1Lhtrm6x3STwsSLj8kyPrXRLE/wq51UMQ BOEUEi4JgiCcQsIlQRCEU0i4JAiCcAoJl4+vX3/99UF3gSD+TEi4fCgxF2ZpNLO2XKn83bBmzMun Glt1965cvHjxjz/+uHjxYlNWShCPNBIu/9f0lw4tXbr0bGHjq+hsj+m/N6NZ1iYrLi6Oi4u7cuVK XFxccXFxczRBEI8eEi7r4AoT1q1LOHvl7KGlS7eeZwFD+tmt4iqV+88aWABsSsLWrQlnU84eEl+9 oWcBgNWfPWTf8Gy6AQBshuO7loq2HjqtZwGu4PTBizKZLGH98kOXChvoRTkAYPrUH2qtspt/dssY jUaj0WjGfHAqnwHApO54edaGo3u/0Gg0mqpV0LmcDe8M0Gg0mgEfnC2qHZqzs7PT0tIApKWlZWdn N8VRI4hHHwmXddkqSkrOJcbp6EEje7VkC86v2ZGgGfFq7Fsvq6/9uvpUJgCuPDf3j1/3FmheeC66 ZUnKzrW/l4E5v3/tr5e8ps2NnfaMb8KOXzIrABta9pgSO/9vMS9G5146dj6rDLRXWN8AAL1GvdS3 o3cDnSjDhMOndmt1C+dtuABUfq0lPyFsSMzg3ckF+sy4EVkjwv6RA3BWU/z22Oe2eySn6NZPjZ+8 IwXgEj4Oj1X9rUCvPzYra8jcX2qNUcPDw9dWCg+v/c1ugiAcIt/qcUAikQT0nzxtQBuB5wvOnaFp +kJaiq8FUqmUOlPEDAigJRKpf/ScZ3sreIvl+tH910tMpuLsDFoqvZJyqYW8pIKmi/MNTHBLzwDP 8sunjpaU3pZKpUVlDODu7eMD3Nb4BbgrGv4Obx7ddsDqzbPCJkcdHKxzcweAnPNxwMKXB7Slgcgp 72oXRJ3K+L+hYIG5uh9n+gPmTtowCw0uO3EVoD285JNkc0o84nszdyIuQRD3iIRLx9RuCo5lAUgl HIC2vj7eLeSaF17oK/cUl2sUPFzAsjz4yjVKxCUMgn1atHD18Xuhi1TppSi7kfD9zuROA0dFdtUU X86gpVIAVpYBINg4QNZwHzgG/kMXrJywavKbC4eXuL4NWE0VgKL6e8aK19lhvuL3pysX7eDMwPAR I57X+lRYR03+yI98u5og7h+5GHeMsdrEH9R+wQDKyxlXn0A/b1eJlbH/x/WL1wvKTAXXL10HfIM8 3dRtggGYGZtrQICvq0LKCzxTViSTBXbtEkKbSzIBC2exAbTKFYC+sIhhbU50xO3FJYeHJ22P15XT QKvI4cCCg1cMAFIPb0zChF5tlbACupqF6LYjZiH+WLa6Y3h4eHjrFrWj5YULF16rdOHCBRAE4QQS Lh2QA0rafqUs939y1oQoyfn/rF25YsXXq348lS0GOYmEubhx1Xcb92dJuj0/LsIFLj3HvxrVFf/d 9q8VK1as/te/c8tt3m27++L2ju+/2pfGdfVF5q/H81l4turSFTi7f9PXfzjIleiAZ88vds8Xf6SD Rp9aP//1/iEajSZyetr6Y//P3nkHRlHtb/85s7MlYdNII7QAQVpCCl166IJIryLtijRRkCs25Prz tV8VrqhUBQQsdAQi0juolJCQQIBQ0giQhJBssrOzU94/ZmsaCwaSmPO5mLs5fSZnnv2eMt/zyVMs oAas5+JY7VW257vnv6gxNzTQ19fXN3jCpiJzl/Xq1QsJCQEQEhJSr169v3WzKJRqA/V3WQJubm48 z9u8rDEMo1WreEECw7IMTKb8pB2Ld5GBb4yIkDie0WnMRqOSUqPRyKIoAaxGw3McAJ2G5QWoVISB YBZVomgG4Oam5XlBlAmkRzqUS+AMnKDT6x84k8IZDAJYvb6Eecu4uLh9+/b16tUrPDz8UdpAqdxQ f5ePAzp3WQJGq/wpSJJkNEmA3U+lYIJs5PKNRh0gOiTmecsph7ZAo8kMwCq8krV8099qH6vTuzYZ WUa68PDw7OxsqpUUiutQuXwENOEj/t2SqKRHsw0rDdHR0RXdBAqlKkHl8lEQZRly1dZKCoXysNCl HgqFQnEJKpcUCoXiElQuKRQKxSWoXFIoFIpLULmkUCgUl6BySaFQKC5B5ZJCoVBcgsolhUKhuASV SwqFQnEJKpcUCoXiElQuKRQKxSWoXFIoFIpLULmkUCgUl6BySaFQKC5B5ZJCoVBcgsolhUKhuAR1 D/xwFObl8tB4ero/7u+ZnJycLVu23Lp1y/GIFVmWAwMDhw8fXrNmzcdcP4VCKQqVy4eCi1+y7BA6 v/pGpxJOCytXdu3a1blz5w4dOjCMXZlFUTx16tTOnTvHjx//mOunUChFoYPxh0ITNWPKlBltNS5n ELLjP/3005/O3H3Ymu7duxcZGSkIAs/zZrPZbDbzPC8IQkRERG5u7sOWRqFQ/j7UurQi3N3/ww5E dPDOOrUv9q5/aPdBfdr7avik/ZvPokmEd9aOfQUT5zx7/9zhBIQO6Oh7auP29Jpth/RtqQP47MR1 K1MHzu2Z/8evG49dAYD6kcP6dGvsy1w8HKNWq9MOrP40a8Ccvi2Qe+3obxtPpwD+kSOGRjfyLlV4 ZVk2m82SJDlal5Io8Wb+CdwMCoVSHGpd2pAK7907e2DXXf8uQ3pG5Vw6uvLUNQkQCtLTzx3cdUE1 4LkILQP+XnJyJi+xPg3qqNPjf7+SLQBSyukdue2a+bKSu3/EjLlvzps1NiTjwubYNAmahlFPAwhq 8+yUzk1YPmPnso2x+mdenTerj+eFjcv+MpTeGl9f37y8vPz8/Pz8fEN+vsFgyM/PzzcYCgoK6MQl hVIhULm0QwgJip70bLvmoe3bhTOMKjOfB1hCGKbzK1OfjQhr4s1CzRDCEAZMg/C2DMP8lZAJIfNE vKpvVDADTWCwb8aFU0dPJnKEqHIKeMDd2xeAZ0BQzRqscP/ODbUal2+eP3/xHqBWX88t3VL08PBg WVatVqvValattn5mWZb19PR8cjeFQqFYoYNxJzx0rCAIkMwACGNdkg72IhwnOqeUfYJ7BGDfn2eO mAuzmO6NfIh0/9J/l2xjmnYb83SoJjfhtswygMCbAUiiBIDIBABp4O/v5xdUc3Szjm7epd9+T09P rVar0+lUKpWyOC7LsiiKJpOJyiWFUiFQ69KJywkXMgyFty9dvAAEBNdSlr9lWSqeUpbdmnZuyzDJ f55LjxoW5ibLgtGgVqs7RzT3URWm3ZABngdUWi2A3Jy7eRyv8fILBuTCQsbNv1YtHy3DSyUUbIHj OKPR6ObmptVqNRqNRqPRarVubm6FhYVGo/ExXT6FQikDal3a0QAMn7n2m8UMw6ia9x7Srg7kAgDQ Oqez/lqjbtMw/HWBCQ+t4w5I2prB7QJwdOOyo/6RXVsG3ow/kJDRvH3tes+EBew6vWPJH11efaP9 8Gkjdm/esOG707IsE9Jkwuwh+lIak5OTc+LEiVatWrGs/W8kCMLZs2dzcnIew9VTKJQHQGRZrpCK laElz/NGozE/P//06dM9evSokJZYEG7v/Gq93O/Fka39OU7QaFiTyQRAq9UCUD4X/9XNzQ2AzdzT 6TRms6hWqyVJMJtlCRKRZY1GI4siGNZsNtnSAIxGw5ZhJ96/f3/Hjh3Jyclms9kWqFarQ0JCBg4c 6OXl9TjuAeUfw4EDB9q0aePh4eHm5qbRaGxTOpS/A7UurUgwAfkFRqPRBMBkssxV2pSxxF+L6B3H 8QBE0ZJX6Z48zwOANVBJA4hGoxml4+XlNW7cuEe6EgqF8ligcmlF4z/69ddNogyUPqFIoVCqMVQu bTBmUaQrXxQKpTSoPlAoFIpLULmkUCgUl6BySaFQKC5B5RIAIBmuxsYmZZTxDvc/h4MHD1Z0EyiU KgmVSwCAUHBm794TafkV3Q4r3PlpvhYGTfvv+SyhvAqOi4s7d+5cXFxceRVIoVQfqFwCABjUUKlq uD1un78PQQHw5tbTSac3BG38ZMGWhHIpMycnZ9euXYmJibt27aKvBlEoD0v13EgkpMWeOPr7yRQA CJ0891l/AICGuxN/ZHfMyRT/0F7D+7f2ZCDkpZ3Yt+fklbuAf5u+PbtEBuNu4rrvT7WdPK6lvybj zO9rz7MTx/UM1Bj++GmDtte4SH+7/8q8a8eXbDwGAKjffVif9o19S6i39NufB/gH1fNrGNQKWAcA hk3Tnje8sn5iCz24xNf6rJwQ82WE3rB/8b9HvrcRwBdHb04MuPBC028mJqzqWYsFDJtee/764GWv d61lKzM1NTU5ORlAcnJyamoqdQRHoTwU1VIuDSk/7f1DFfrcnEHNTLfvKe/eaICLh37lOz4zoJNm 96mDF1uFtvfL+XXJ+uts5AuzxmluHl+1c8Md8fmxYV5e6tyE69kt/WtcPhDHMsyNrC6B+pRjGeoR ei1gf6NUVgdMnDG3tif/x6alB7bENf13tHdhCfWWhiewdfWSu9kbP8Gc05MjAENO4jGTWRmVm5MT kgUAmcdGvrdxQ8Ltnt6GLEEHfVjPzjH/t/F8z1mthbQDU9dgz/u1HMuMiIhYuXJlOd9MCqXaUC0H 45oazVUqOSlmz54/7zFuehYAeCCoy+jnu0dFRoQyDMOyhL9/54Za3bR/x9rumsAWEc1VqrTkO0at f4smSL14O/tu2lmVihCScevu7ZuXSIM2tdyc3r73qVNPuJVw5PDJW4UyyxYUCiXXWwZBwUENQ9sA ew6fSCs5hXfIBGDkyJd/PJ6h17OA/tm5bya8t+I6cH71JEyb27o0Bx4UCuXhqZ5yGTji9WmDe7bP OXf0pxVfHbmWpwR76N3NZnMhxym/Ki4JBLMZgGg2A2AYBtDUaxbJZO3/btXO4K4jRvQIvnrgxx92 J0e2CnY6R0LK3fvf/63fdq1mSGiLxsEAVKXXWyJ5QIfOzw6f9eXRL3zmDvkpEwCgtYwGhHtKIt1T X6YnbJgWsnRklzof7BcAv46DJ2Dj+h9/XLQQy15sV143jEKhoHrKpWS4HX+toGGb7sNHdFCr1dn5 FlcXnFmCVSUBaGr4BQNXzibeLuSzU25cBgKC/XWAR1A9QgjLsg0a1q1TO1ilUqlUQY0C3Z3qEApz 1eraXVsF+6qzUm8AJo6XSqu3RDyBu1lZgiEz8coxQKfI5NGEFIFLWz6lTwI8WUDITbuSpe859vWl X/THwmQDAPapCR/3XzhrVkznL3o1LLpydf78+RetnD9/vhxuJYVSnaiOc5eSkL3ll52yLBNC2BY9 urUIADI0gMjapxNZQHarM/Rfw3au3LR68XFCSEjXYc92qA/RLNcI6hqAI3fC6nkzKiGoCXA5OLKW s1pCUzOyXcDWYxsXH67TtWtLpCXsT8gc3zS3WL1FfLTbqQF8MiTiEwChI5btGeEHfe9/z3lrUpfA WZj28XuhMX8KgHD3SIcOs5T0H2/9rzcAIGLolNC3Yvq80s+7WJn16tULCQlJTk4OCQmpV6/e37+T FEq1opr6u3Rz0wq8IIFhWUbxyebm5sbzvCiKhBCdTsdxnKJrOp2G5wUwLAPJ5npSp9MRQhTvbW5u bpIkFXHsBsDi5lKjgSBIgiQSAkkoXu9DIXAGDjq9zvFLTjAYONYhzHB+eXCPs6duL32qpK/CuLi4 ffv29erVKzw8/GFrp1QhqL/Lx0F1tC4BKE4tHVxT2j1XyrLs/NnknBAAOOv8Joq5vLRhcXNpi5VL rvehYHX6Yos3rN4pjPt1wVuh7+0pUSsBhIeHZ2dnU62kUB6BaiqX/1x0Q9ffHFlcVB2Ijo5+Yq2h UP5JULn8p1GCAUqhUMqD6rgyTqFQKI8AlUsKhUJxCSqXFAqF4hJULikUCsUlqFxSKBSKS1C5pFAo FJegckmhUCguQeWSQqFQXILKJYVCobgElUsKhUJxCSqXFAqF4hJULikUCsUlqFxSKBSKS1C5pFAo FJegclkc4fbV+PikDOERs/NJ+3/6fn8iX65tqvwIWXE/bT7NlZnm4MGDT6g1FMpjgPq7LI6Ueey3 39Hrqaa1H+3uCDnpOQiX/l4jfH19XUmWnZ1t/4U7P61Oj43K59ARqxZ/8FyE399rxUNgyjj88kt4 ZlibogeqWYmLizt37pyvry/15U6polRHueQNufeNolqtdffUa0oyr918VSqT7mENb4nLy8431/By Y3WEmMrBbpc/eMBhPmS+tkhIAfDm1tPTWwi/ftRhUo/QpOxZT04vWQ0AdSmROTk5u3btSk5ONplM devWrVmz5hNrF4VSXlQ3ueSvHt+5+dgVQogsy51feLW9Pu3XJZuvAAAiuw/r1r6xznKsjnLiG3/z zNGf950GENl9RHT7RhrwSfs3n0XztgF5m2NOwj9y9PCewZ4sdzf+f9/HKMWyLIsmACDkXS1WuJK9 SYR31o59BRPnDA3UlNTMRyUP8PLz1/vp+wyYhjXX73EQYlePHDA3AZiweM+XY1uDu/LOqCXt/9Vs 0qS33juQPMn91L//9fzGBKD/4ptrx+oBIfPMJ1P7LDwGoPPiXd+M7VAX3JV3Rq3uMjdq/ZCpMcB7 60/P6tdQSNv/8tiRGxMAdP5i17KJHWqV3bDU1NTk5GQAycnJqampVC4pVZHqJZd5V09tO3mtTrsh o/u01PIFBkGFAnXriTOG1dan/LHl54NbGzSf29TTnv527M4NB5IH/OvVxuKlxT9sdqs1vWuwRihI T7+cnlavw5ABnXb8/seJi5HB7Wuc3fmbWt142IyRTbR3dy9cfVaxC6USCrdk948c8FyEtrynjj2B +3m5hrQLC0cuxYT1DXN3Bw6Yu/58ej/vpGnBPX58On2sf2HKsTVL7805cD4hxE//x/97fmOXDbeP 9DRk5eoAIO2T0D5/vbf15vaOuae+jxgQUfP87X7ehSnHlj5/bMTW00lvxX/U5fmdL2TP0rFBE5cm LG1R68zyQX3m7R5+ZGLZxwxGRESsXLmynK+WQnmyVK+lHrMpn2GYqKgmrNkkEtZNTVjvOp5C5qmD R5PSDSqVymB0XKHhb99IVqlUVxITEq+lq1Sqa3cMAFhCGKbzrPE9W4SHNiXEXauCUJCfo0KTlkE6 0UQ86zSx5C+xcCX7K1OfjQhr4l3e31Y1gE8GRARHDDC+tyrhs36pfx4FsGf15x8sWrMRSM/hwCIP 2LplfkTdWnodWz9qApaOfPm/P2ZAxwJC2tmFCF0wqasebN0OY78IxbZT15Us6xOWdm3o16hxM0DL ArpaLZq5pW9avfzATcAHj7osRqFUJaqXXEq8GQDHm20BV/d/sWL9VtRqGBraBACIyjG9SsUACPD3 9Q8KHT16dN8m1iFksBdjMgkcD0CxIwkhMmdmAEDgOPkBhQd7EY57xMNzy6QAeG9PcnZ29peznqvF AjACIwYMHTpw4IQDB46+0FQ59axzDetyzFPDv0w4uiEkeWmXpnV2pwmCmQd8WJuI+6DAcq86B+kB 2GUx8cdpIW0WoVnnPl3a4h5fvQYplOpK9ZJLnzoNAOzfdTQt15B3N+OuobAgR8XW7vpUsJ8x6zYA kXO0LjWBwU0AFHLEt3Zt7xpambfIhSxLgMPNY908Adzc/UfitcQjW/feBLQA+NIKt2R/DOQptp+V hu36ABuT82pGREREhNbXF1U1Ie3KFV2Lnq8vWtofuHLboGvYegKOLdmZCMBwZffcYxj0dCNLUqeM hj+XbsS0icM7NBEykyyxZVqY58+ff9HK+fPn//aFUigVQPWSS3VgxL8GdVXlnFu/7Julq9alFLAN otrJt4+vWPTVNdEnADh0IMmyc1ALALVaPTOiR1jsvg2LFy5cvHTlHxmFcIgFoAG0KgCeT/9rUCAh J3Zt/otv1L6BMo+nK7vwx4EnoFE7iGKtfue3fvzWgFBfX1/fwOAfkzgljRXuyPsdQnx9fet0iRnx 8ZAIb6Dh+6dW3ZraxdfXN7jD1Dmrjg5vqHPOAoQC0Pf6z5tYOtLXN3DFlfqhCW/NWp0IFmhRasPq 1asXEhICICQkpF69euV60RTKE4LIslwhFcuyLIoiz/NGozE/P//06dM9evR4AvWqVCoNy/CCxLCs wPMMw7CAwGgYCIwkmYlKEnitVgvAZDIBYFlWRWRBAsNqJIEXRdEx1s3Njed5URQJIToNy/GSWq0i hCgJVCpV2YWXwaPsuywNgTNwAqvT60oaMyuRer3jdknBYOBKS++UEXq9DoLBIDwoMYC4uLh9+/b1 6tWL7rt8Ahw4cKBNmzYeHh5ubm4ajUalsnRLyt+h2k06iaJoFEXlg/JTBCAarfOIIpy1TBAEwZLR qIQ4xhqNlkBZlo0mMwCet89IPrDwMnBJB12E1en1DxXJ6svIUCwjqy82yi+J8PDw7OxsqpWUqkv1 GoxTKpbo6OiKbgKF8uhQuaRQKBSXoHJJoVAoLkHlkkKhUFyCyiWFQqG4BJVLCoVCcQkqlxQKheIS 1W7fZSWkot4UoPyDkYtR0S3CP2CfPJXLiqGM7lsZejblH0CFy2URfXRsQxWVTiqXTxRbj7l37x5K UkaqlZRyIS8v7969e2azWafTqdXqJ/YSZJFaileqhNj8Q1ct3aRy+YRw1MGcnBwA/v7+7u7uLMtW rR5DqfzIsty4cWNYxajydDDFU0Rubm52drbiFUF5LipPC8uGLvU8dhyHQrIsK1oZFBTk5eWlVqur SkehUP4+hBCWZX18fABkZ2c7PhdVYlxF5fLx4tgJlM+yLPv6+taoUaPiGkWhVCQqlcrLy8v2ONjC K79i0sH4Y8Txy9PxJ9VKSjVHpVJJklR88UeW5co83qLW5eOiNK2UZVmtLu18WQqlWqCcmVrk0VCi KrONSeXy8VJcKyv59yeF8gSwyWWJillpoXL5WCjeCWRZVkYfrp5oJst4nJ2n8uxeplRPRFG0PRQo 6ZGphFC5fFiE21fj45MyXDwq1lEr4eoKoCzLsiTLkiw9pp3GFb6BmUKx9b0iilmZoXL5sEiZx377 7WRmGXJZfC7GcTCudI4y+kXyni9VKtXwz49KkmzpSLIMx+G88dzzDDNpTZy1kNz/9RxyPL+o+pUm h7ZgS0uoYlIqAkmSHIWyyNxl5eyTVC4fGjdflUqvc+XGySWhjEFQmkZl7nuq3+vsqz//MKejLEkW K1MuwR5cMylyW7LRUYudbVGpWI6S2/Y37waF8mg4DsbL6qmVCSqXZSLlHt/yqcJPv/+RzQNQZhTl 0mKzE/d/9tP+hEtnPvvss7O3uZyLB/77y4ELF/9c/fnnn3/+S3xqZvLp3dZuUbxrCL/+tz8wK+Hj oVpZlmHVPCip7VahAQAwfNhX6ZKlw0mSJEtS+h8/9GRVKpWK7fna8YxCSZIKL/0ybPzSg1s+YhiG YQbFXMsHACF15ctttVqtts2/T2e5OK9AoZQbSo+1d11noay0oknlskwk1I4aP/fNt2eN7ZkefzQ2 Je/BsWaOvXV+169Xe/QfGOjGwmxiM87/HpP39MDuQeyt339ZlyjVhW14bekVQm5WrgAg69DghcKH R95ppCZQVs8d7ErbJwB5GHM8fm/XuLdeXXlWlrWWAm/tC+40uf+eS4V8zoFBKd3qv5Miy2Zz/vb1 M3uvc796O33D1N+G/HgBEH5/86lX3N8zms1nZ6d1nLqBe4J3lEJREEXRppiy41xTJd5RRLeplwnr HeRdcOHUkXv37zAMk5XHAboyYz0BnpCA0a++0MBNMJvN2TAREjx2dv9AknF915HbDXr3aRMAAPZl b2K+trNm46G9Pot51+sXYMGETv5EkggIrNuNLP2GEMiQoQRnqEO6/bBtTvDgdjG9b3p4AgSp534F PprYvZFKljtOfqvbnPYnr33QHyZgXsrmV2sTYmjRvaVJQ8TU3YsEKTrm/QV/FiZuk7a3MRHi9qTu KIWioGil8lnZV4RK//I4lcuyyLu6f8nm0826DewQ5ptz4TrLMK7EyrK3BiZBsH1naiAYRckkA7Ia PM8DgEOvUDcafH33uw379d8HzNh0OQiQoRiXlvccIMsgRJYdM8HMIeiZ+Suf/9+QF98amKN/A0Qw FAJatUPhvJkQEBJey0PJYvkCNxuBQYMGj4sOLOSH/uvjoBqyjMrdTSn/PIrblYpoVubXe+hgvCy4 vCy1uk5YixDWeO8mYBJMUpmxovNquL0ziLIkSbwsyyZZkiQopqNDbwju8+62OVHAwAl9GgMACIgF hlhSEgLnTADxGL/w2LOHfvw1Ll9DSHDH54C5vyXmEpCk3d8fxph2IVqYZTlOBnEQaLbRkNnstgPX 9U+FR0RE1F0mjVYAACAASURBVA/QP74bSKGURvG5y+ILPpVtPE7lsixqNowMwJ1NSxbtSBbCAnDz 4PFMHgCgLSNW41yGBpa/OqMG5BqMpAy0Ffmyix/73LtfvzB1VEs9lGBig2EYhmEIYwuwFU0IIT7t vtn7gZJFXX/whY3/7/nIAI1GEz7q0sbYRU3VhGgICVeUFtZXL9m+H1z52uOVYHeNRqPxGb6ezl1S njxFrMuKbo5LkIpqqCzLoijyPG80GvPz80+fPt2jR48KaUkZEEJ0GpYXoFIRBoJZVImiWavVAjCZ TMVjBYFXqVRqtbqwsFD52lQ8VhUUFIiiqNFoeJ5PSUnp0qWLrfwS6y36R3GY17F2L5TqyVDgDJyg 09dQyYBlqpMo+msrTMGYny8StYeHWxEVplR1bP2nsvm7tCHL8vnz52vXrq1ygLHiaBlUqsbTucuy kGXZaDIDsL64KAEwmUxlxIqiKAgCHFSJ4zjlQ2FhoW1fbtmdoGgsIXCeXbR+LqkYtZuHGtZdSiWk s3129/RUfq1UPZJSTSgyBlcCbZOYFdu20qByWf4U2UFW5FfbauBDYes/LvekshKWqJ4UypOkiAO3 IkJZOUWTyuVjp7Rp7IqlEvZFSrVCeRYkSWIYpvI8F2VDl3oeC8X//LYp7UezLimUfxiledaozNJJ 5fLxIjtsK6tU1iWFUrEUfygq/9NB5fKxIxfbjFmx7aFQKgPFF3kqtj2uQOXySVAlugKFUlFUlQeE ymU588A/fDn0DC72eYZhhyzKtQYImfsiGGbEirN/t2QK5UnxJJ6U8obK5WOkxB1F5dIJDIC0/bVD KWbl17hNy+IBmP5+wRTKE6LE+cpKKJGOULl8vDzW3rDkV8WcvLbmlc3dwy0bg7jMk1MjVQzDtJq+ KgsAYEiKGRepYhiGHfK9AQAMuz+fqLw+8X2CAYA5Za+SgGGivzueoRRzdMVMhmFUkT2G9IycuSbO MZBhItb+ebccL4RSPSljh3LlhMplFWXgqlVz977yYyqQ/+f2b6IXvjFz6HVOBlLfqN3J68PLkpTz cuaUGT9fAoRjy4ds7LmLl6SsFUN1ADKP9p/3w54MXirMeS5YB0DU1J6xPk2SpJNfaV6aud0AZOxZ 0G1q4oEb902HlnbAhav5AiyBHld5KS/+9QkdZl+mboUp1Qwql1WSPCCy77gxWLw34daxVW+8Nn9E fU0eAHPKmcXAuZ3fzJ//+fbt0q/JuQDboO0U88L+L364Jh06FoB3yItA334T1x5J1etZALpaoc3d 0n5a8fXe6zLxJQK44+sWtvrs4+71PVjvJs+N7pnNyQD319ZFwB/fvzf/46+/BH66Tz1zUKoZVC6r KHmsX+jkOVFTnn9mwLJnJkTXRj4AiAIADB45bvSwYe+dORP3rzAAzUZ/nR7/e6OkRS0D3GNSzNA1 WV6YHjOn+ef9Irzm7xaAuDWTfBt/wLToPqDH03I2x4L18GdsDowEU47ywQwwg0YOf2HM8Je+i4+/ 2FxXYsMolH8sVC6rKoUC22nyTDkuTj1neiigjIx1jVrPAw4lFDaLioqKahmgZwEhJSnJLbT3guXr BgJJmQYhNzXpjr7vhHfWLhtm/uiiAYbjC39Qz5k+qlMzPiMRgAC2cdvnz86bvPb4uWNbPop45Yyv FwF0HYfMlrbvNnqFREVFNQ0OpO/PUqobVC6rLAJ0oUOP7thx9q3uSoCvjgD1/nPjgM8rXTUMwzCa UasTAW7fm6E1GYZxbxkzbuHwVj7C7cPNG3gxDBM5dfPi/aO8oe//2Qfmhf0ZRvPtpfphca9NWRHX ePRX+5b1+bxL6/eP+33/dpR8XwZQu8/7R76q26m2O8MwGs8Jl+hgnFLNoP4uyxPHl7okK6IoKl7d lJ9paWl9+/Z9zB4uBIOBA6vT6ywmoMAZOIHV63WOCRziIXAGDnq9DoLBIOj0OpYzcDq9DkDu0p5+ W0ef/X1KuENR0CmznpRKie2hroQuIxVkWT5x4kT9+vVZKzaXl8pP4kBFN9YO7fP/SFi93ulICVbn /HvpCVi9ngXMKbs9Gwwl4eFyXBwJf+PimPDSi6JQqgtULqsAMlDiN6ztgMgHBj4s6vqDC/Nycg2c GWxQLT/aSygUVG+5FPLu5UPr4en+EDehMC+Xh8bT0/3JTPpajiMnQBEFlGE7WsJ+jGOJgVYBBeBw Fu8DKgWgreEdWMPVLBRKdaAaL/Xwd5YsX74k9s7D5OHilyxbtuQc/7crd2XKWNFKWYYsWXXTFg7I MiRroCWZc2DRQmRAdvq1hCbYCrT9k5wKt30uWr69gFJKplCqPtXYumRrzpgyWdDVfJg8mqgZU56C XgMI2fFfrIyp32vymNb+D1uz7HykcimJLOIlyYDytUYAqziiiCo5RNkPNHMYwltMVBdUzC7KsJdp s17LSO+Ui1h+UsuU8k+iGsulVHBuz045/LluLXyzE/evPI/B7QPOboxJgX+v0cNb1zEf2bg9vWbb IX1b6gA+O3HdytSBc6PvnTucgNABXRskHY5Rq9VpB1Z/mjVgTt8WyL129LeNp1Mg+0UMH9ytgZca MKecPbLhwBlZlkM7Dnw6oi4DGG5dOrFre+/evfGg9UrZaqnBau7Z1MqmibJzarvAOeuULDtlt30k JU10FrVMbZorO2S0htrsSiJbKnUa+Jc250qhVE2q8WAcQm56TqZJAkAEE5sRu33T1cghAxqrc/cf vMqxPg3qqNPjf7+SLQBSyukdue2a+bLg7yUnZ/ISNA2jngYQ1ObZKZ2bsHzGzmUbY/XPvPL6y308 L2xacdoA3InbtflwbL8JM6aN7ZlwYseZtAKgIGHbwZT8ZrYWlG3t2cTIJp32ka/jMY/OWonSNco+ UnYcmBcZsDuMxB2Kdx7FF/m1pJH+A65NuLVjzebUMnducrlZWVm5Bq6cX02/c27X1uMp5VsmpZpQ neVSse8UbeEJCRwze2xY85Ytm0Cl1zFgGoS3ZRjmr4RMCJkn4lV9o4IZQM0QwhAGcPf2BeAZEFSz Bivcv3NDrcblm+fPX7wHqNXX7/P8nRvXVCrV1YsXk25kqFSqG1kFAOsbzBJyFSVZfI6UIDqOSmSM naBhtMMX5cIilOZb+1qrmVHfnXPVmiuyauSog6WntbfHppglXYLN8lX+5Z9byDCf5BZJxKUNmjQi s1Ql5HZ/Pty9ZkBAQE1Pd8235/JduyqXSN0/bMyhjHIskFJ9qMaD8aJ4a2AURV62qoLsE9wjAPv+ PHPEXJjFdG/kQxylQeDNACRRAkBkAoA08Pf386vlM6rp0zpPFvdUDAB//5p+Gu+hQ8MkrRfAtBj8 osn3kCzLxDq7V6otWGRUaw1TUhsA+dfXDqXOHFxPDSB+87J4IMQkP8Cmg8N8osPquW393fbtYZl+ LD6gJpYm2ydCifWnbbbUKqNKjL7x6Lg4sx6AcHmQptmg+MLJoTqw6m7opi6t92Ud6z9vy5ar9wc3 cruVlMQFuj3oqh4Cd69uYffV5VggpfpQra3LspFlt6ad2zJM8p/n0qOGhbk5L2qotFoAuTl38zhe 4+UXDMiFhYybf61aPhrCS5ImMPgpAEaO1KxVy8tdI/MCpIKrlzN1QU1ceVHBMidIQAgI47AryEFI l1r9Xa6bs7l7OFF0iss8OaO1ilUxraavuisDQMHlmImtVRo1ox32fQEAGH7/YqJazWg0Vn+XqXsn tVVpNYxGHf39iQwABNyx717WqBltmx7De0fO+iEeAAh34ruXNRpGo45Y99ddQuxSeeij4ZY0WYeH aaK3X+MAZOz9ePjnR7k7R+d/fcwocxtfDtsBvNjSPWraj/kyAFw/+csghmEY5stdyY7Xbs4zAMjO ygfYoKahDb1ZAELm6bd7sopTzrXKaJpLmBo5NdYAAFzSul7jVxkALmnD0PFLD275iGEYhhkUc02x TO3uO2dM3euro1OqlEehWsulFtBaDBxN0QgAQI26TcMAhgkPreNeJFblXe+ZsICs0zuW/O+cUVtn +LQRYTi38ftvFi36etW6U4USAiP7De3WIu7glmXffrt81dozmUZI/I3ftm36aR2UeQD7VEDJWLRS Mfqspp81w8CV3/37wJwfUwkMf23/uvvC16cPu26SgdR36nfS/7/LgpAzK3PKjF8uybJwfMWQX6J3 FZqlO8ss/i6fffOH31J5c77d3+VLP6TxZun4Is20WdsNwK29C6KnJexNvl+wb2kHXLiSbwZB5t4F 0dP1lwqle7GvT+po93cpA40ig5ZO3meQkXJ00w4c/vH4DYDb8cb8Fq2b8rl3f11+W5Z1/d/c1RKY /1vi/s+G1pBRG4eH9fz1tau3z2+a8e+BGx1H6+pGvWL+X68pHeq2mv7V+SxlgjN1fu12p5/Zkyfx N46OmNClQUyKGTBfjrusOJQ3F+YdWJcLQBAM29bN6L3WPflO+oapvw39KQFAxsGPu01NO5iRV3Bo cb/oat3nKX+HajwYZwMHvfMOz/OiKPpHDXynvcZoNAKa8OFvhwMmkwmAxAYMeuedQYDRaATgHKuP eHZy+DMiGNZsNsnu9QZNeesZXpBlolarCgsLBUEV3KrvvFa9ebMoExXPFfI832fOnCY3rtnehC3L yiT2icKiIUAeEN77+TGI2pvwZt3Vb8x+50b9lN8ACClnFgPRu76Zf8o9Ybv0W+tcGWxwmyniuP4v 1Vw196VRobD4u+w/YOJ3n7wxondLKP4uC//6ZeWW5BsyahIB3In1CyM/Odqtvgdkj4Gjem24LwPc 6e2LgE6r358v58QAsfe59dCDyJCB+m2HA69czJ2UsO7oS68OXbH2hGFoztK4Z9e2D5CTAUCWofP3 bwAE+NXxqqGTTcgAdqav7xYEzhgKcM4dUd/vnT1p/be+3npY1LLZa85kj/Y98xla/jGthx7Qdxr/ TfisTSeS+w92uFsa2600AfNSt84OAgyh0WGcGhDidn7S6rPD3WrpgdDnRvfceJ/uC6U8CtX6m9Zo NIqiCEAURasgwmQyKVppS2OLKhLL87xZFM1my68cx4uiKIpmW3pRFHmzKIqi2WSpiOM4QZBccXxQ chwBFKsUeWq/0ImvRk0f/8yzy58Z3722nC8TQBQBYNCIcaOGDnv3rzPnJ4VBRtNRX6fE/h5yeVFU kPtvKWbomizJT985u8XC/hHe7+4WgAs/TA5s+gFp0W1A9NPI4Viwej+rv0sCsylbqVwAyHMjh44b M+zF72Jjrf4ulfb4R3wZfmH1d9+s+3XwG/PffPbQ2uXLvkx8aXJTR5+YAvKcVoa6BektxZZI7agh 66U73wxiXlz3hyjwQE3bXCfxJfkm5V0Biy9OmbevspPwWh4AALO14vy7kq+uRhl3m0JxhWotlxXI g6cvicNgnIAQMNZ/SlajZPF3yc6e3pJABEDgFtJ6HnA4obB5VFSrqJaBHiwhQurlJPew3u8uWzcQ uHzbIN5PvXxX33f82z8sHSZ+crGAGE7+bw07e/roTs3MtxIBiIR9qt3zsW9OXn/i3MltH7WafcbP mzBE9/SQ2fKvuznvkKhWUc0aBKqtjSEEhHj3mT1++Zvv3n+/X32fsOcGHX3zzS0Lp3RVExCzcr0g bp5PAfmF+bZJT3Mply5kXf4r6ZZNRknNGrpGbV7E4a+2xQMwJMXMOCiN6NIEAoD4pJv3uMzD41rP ZaLdAMi8LMcVMR51Tbv02PvKyoRcLv/a4Tfp3CXlUaFyWRmxz1eW9I8hAMCIcAsbemTHjrNvdVfC /XSEIfUWXD/gO7urjmVYVjN6TSIh3IG3Q/1YhtW3jBm3cERrH/HO4dBGXizLRE3bvHj/KB+i7//Z B8Ki/ixr8Xc59TuLv8svu7V+/7jfd29FyfdlQlCnz/uH/1e3a113NcvovCckmZxEvHH0IAAzB4cx RNdp1DRgVu9wH0JANCBhIAREXX/cp0Pnd6urGfZ9AYGnw1wECXfSL+72sfbN62gYhmECZuUtODOz C9Doy4tbro+NYBjGs/no+ZvOj2ykg77xnDlR41v6utf+sutX0y1FaYitNNv6d/iYL9+L/qZlTXev xu950rlLyqNC/V2WJ9Tf5QPhOA6sTvfAzAKXazAI0Pl5O7qLK9psAJzBAOeQ0ko05BpYvbcLKas8 1N/lY6Ia9J3qSOX1d6nTuXbED6vz9i6esmizAbjcHFbv7e1aSgqlZKhcUkqA+rukUIpDHwRKyej0 3rWo23QKxQE67U2hUCguQeWSQqFQXILKJYVCobgElctqjnB2y88nynY8SaFQAFC5rJJwsc8zdvp+ ffbhizAsZJhP/rwHcHuGjz1yy/jgHBRKtYeujFdJDMCHu6/M6ejLCWB1j7CArR99MV4I9AA4bRiB mrqcoFAeDLUuqyR5QEBwsE7v7e3trdexipPH339ewDCMKnL2X9di3+/JMgwz/MPdHAAh9bPxUYop OnPFUQEAuGPLPjuURo1KCuUhoHJZJfEEvv5w3ocffjh//rLrnMXJ41uHm6XnXPqP79ftG7fynZ+U dmbNlnffiDcAYDtNXZsnSdmnvl4y9fMLHAAhbd+6LHNpPi4oFEoJ0MF4VSWibeduYT6F5ho+LAAT sGDPkrF+QP9+kdv7LZsZHQKO64aaAMAGtQ/lfluz4vqdawDM5XxWGIVSXaDWZRWg+MxiHtC1R/9O 3aN7927nzQIACbe8Yq3R+VpTWYxHQ8L3mpoh8R7N+/Tq1BJ5jqVVkH8VCqVKQuUShoyrsbFX8yql zSXLkCT7kbY2PIHbt28LRs5gMOQbBYuTRxmybNFIx/TXTv8GzJswuLOPKScelqMfHdPILhyJRqFQ qFyi8NbpvXvPGKQnWqkrfvPs59k6K6YsQw+806uhVu/u5eXp8+xKg5qQcKIcZsvKqKkljoU07fZS N3xWj2X6fpMwNvxIx8Hf58vQ+lrK1Ppaj7p1PMecQqEU4x8wdykk7vxiR8JTE+cODWQhZMd/sTKm fq/JY1r7u5hfrXFTqVSqx/XFIVza/b+YxIYjp/WraQ2SZZkQovwsNZ9skTBJBpSvNetZPbI2cq0g /SBbTr5VTkgzn7WkD535+24loS7yoHRQliG5995bWGjgoPfQEfH9bwWdHuy0/aIijlP3icohuo5n AaHsc4QolGpJVZNLKff4tmXHrgBA/cjufaLbe9y/EHNJpVbfWP3Fp/0nz8TRGLVanXZg9adZA+b0 bZJ2/NeN1tTD+nRr7KsDhIzEPw7vOJYCAJGT5/ZVyTKA7BvxBzbHpMC/1+jhrYM9hezEjSvPNxoY lrsjJhZo0//55pqba7cdA54aNvW5xt4s+OwzB/fsi00B/HuNGNq6kTeEu/vX/IpWXfzv/xVzMsWv eY9BfSI0WYl7LjNqdcrP3y6OHvViI9Xt84f39e7dGwAhRQ/xdkQ5INd65rnFALREWQ/ylp1T29LI pFixrK6GHgQgrMWvr91WBYgMmQCS9bReGWAAmSomheJEVRuMS6gdNX7um2/PGtszPf5obEqe1rtu B4YBAp57YVpj7xoNo54GENTm2Smdm7CQ3P0jZsx9c96ssSEZFzbHpknA7djd63edENs9N23WjIlj W2oBQANc3rnlauSQAY3VufsPXuUASeJvqW8d2bU7cMhzUXXUZ3f/tC5WGjKgk1p946/kbICL3bny YLzPxDlzJ/YN2L9p281CAFJhbu7Zvdsuqlr279g4J+lQ0m1O61WnLcMAfv1GTmzoqUpPOHLxVhZs x4WXOe61jYtt0mkfLMuATWqdtRIlSXCRehy10laHY/l0CYhCKU5Vk0vWO8hbunDqyB8XUxmGycrj ZLVnQBMA3r61fNzUxN3bF4BnQFDNGiwDTWCwb8aFU0dPJnKEqHIKePC3b1xUqZr37xnh5e4RFFzX kwXAAwFjZo8Na96yZROo9DrG6q8/evy/Wzdv0cBLVqmaTx7dq0VkaBNApVKBz0m9zjJMYlL8+etZ hSybk5nLASCEBHUZNbZbZER4C4ZhVCoiqz38GwPw8gnw0qlVHt4+hBBZhpPsFcOmXPZ42TmQOITD IbB0e7BIjKNeF1FhxzQUCsVGFRuM513dv2Tz6WbdBnYI8825cJ1lGABmWQYgSxIYCLwZgCRKAKS8 pP8u2cY07Tbm6VBNbsJtmWUAZZLSzPNgIUm29R1vDYyiyMtOEgU1EUXRsplbNJkEhrfGqAghQLCf v38Nv8DRLRidj1aJ8KjhbjabTSa70wp78wC/Fs8MMXkR2GYKSx+POxwvThwHzmXfoFIUjsAqpqRM FSTO/y+XNK6nUKorVcy65PKy1Oo6YS1CWOO9m4BJMElg3GsAyM2+k8dLUGm1AHJz7uZxvGA0qNXq zhHNfVSFaTdkgOeh8a8bDFw+fiIpr7Aw9+7dwjL3DwkO0iI6Rmg8GgQDMHJSjaCggBpaRpQt8Zwg wekwKaV59+9lGXhJuH39Oude64GiB6umWU5/ZOzTiPaBeXHdK7Ko7bj9yHa0pLVu4qChymKRU7it cMdBuvM/CqW6UcXksmbDyADc2bRk0Y5kISwANw8ez+TZeqH9gDs71y09l8mpvOs9ExaQdXrHkv+d k2sGtwvA0Y3Lvtlxo27LQNw8kJDB1W773LCOTa79uWPJ4sXLV+3PlQBonOrQ2j+yAMCwGgAaZelc A2hVANxbD/9XjzDs2/DdwoULl333Q3qBpSCdijhnZ+s06wVk7dm4+sIdU/6NXTs2/wwC4qBXpWE/ LNdB6YqmJ3Z1c5zodFwXgq2mYiLrqJ5wyF50a1FJWkkFk1LdqGIH5xJCdBqWF6BSEQaCWVSJotkW KEgCkWWNRiOLIhjWbDbpdBqzWVSr1ZIkmM2yBInIslqtZiAJElhWYzIZVSqVRqMxGo0AtFotAJPJ RAjR6XQcx8myrNFoVCqVksDNzY3neVEUASgVSQCr0fAcJ8uyTqczmUyCICixhYWFoihKkqRWkUJO MJlNDJCemtq9R4+yTzS17B8qPpPorFOG3KwCE/Tefnqdk2mpaKuipLY1dCdtlouKJmwL8bDnLY45 K/bn/aaRo9vrrDpOqYTQg3MfE1XMupRl2Wgyi6KZ53mOl0TR7BhIZBkAz/NmUTSbTQA4jhdFkeM4 nhdkWVQSmM1mk1kURdFkMgIQRVGRQgAmk8lkMlnKNBpla4G2BEajUdFKW0WiKJqsKW2xjtkdm2c2 m3lBcKUTlxxnHTsTw+UvhrO+AQH16wXU9GDe++WsYDM/HTWxiObaTcdSKiUgBIbEdRo1o7b++zb2 Xn7sQrX6k1yASzs4edxB7gGrShTKP5MqttTzj+HB35nFbDcHGbz1effm7/h+lJQ7N0TPphz/rlG3 Npzn9U/7BxdJWTxv2SGKkDKEB1r+du3Q055EAHR6bx03OjbW7EFgVGsAsFQpKdWSKmZdVhPs85Ul /StM/O2tuLD9P7/R2IMlBMGd//XX/3p/+dyq2wRXNrw+65sta/7dmmUZzbD347IFQmC6fXJ6KxXL Mq1nrMomIASXN7z+8jc7tnw0nGUZzbBPrxRYSmYIGGXlBw3q1PHx8PH28fF2U8N09+iCb4+ZLFGW tmUc/y5C8aG55lQF3y8K5YlA5bKSUppWEoLrZ34DJkb620NCe4wCDqcXgM+/sfTV4bc6r7hz59KH ee+3nbtVJKlv1unk9eFlScqZdXvKzF8uEaIkG7TTa8adO/Ezt7+15eK9IlUAO35ZvebnH9asizkn Egh5d39dfpvY5JIAmb/V7TLl4xsFUt7Z3Ekd112jp/1Q/vnQwXgVhAcJJyX/5bi8Vp+deHtoKwCT 3njtrX5puR+cWQz03PnN/JPu8dul39vkKsnUc2JWz+oBcM3CCacuoSQjB17DE5MsACiW4OqJAwB2 Lv/wBHJ+AsKyjGikK8dLpFAqIVQuqx4N20TLcRsvGma3tR7Sc/30USC8lg53CYiuhhKo7CgVBAAY PHJcN28ybNiw/wY9BUAgaBmkuCARTCVXMnDS9Amh1t5Rktd1IzBmyJgxfjw/bNiMWk95lM+1USiV GDoYr3p4RA2ch8MdZyy9xQHAnXO/hE5aM2PTrHosWK3n2ZVbLucKQO7BdQvVc5rXatR6HnAoobBZ VFRUVMsAvYtfkHmFjsNrc9EPjTsOAH66kusTFRUV1bKBB/3apVQDqFxWRep9khP/bvrLddwZhmFq tR4z/8fTi4Y2tsaeG1FTwzA1x8fNj/+wH1DvPzcO+LzSVcMwDKMZtToRAOuwFV9bQvkAPJ3G32qQ MOcPtZ65vn/xy13qMgzDaDx/uEhPSaP886li29QrObIDkhVRFEVRFARB+ZmWlta3b99y2XxryM0V AFbnrbdOG579uu9UfP7Xy81zczm9t6MlKRgMHFidXleudqDAGTih3Eul/E3oNvXHBO3mVRi9t3eR EJnLjjcVAKy3d5HDx1m9/hGOI38QrO5xlEqhVE6oXFYBFGPBla/Z1rOPZQn0b0qhPBboo1VJKT5J 4hhSqnSyOlfXcigUykNCn63KiO1l8xJjH3zOT7lUb6nqcVVSiahu10t5VKhcVmqKP75lW52ulVEG in/koiUqRbhk3v5tSr+cx1KnLMu2Kgkp5seT6ifFASqXlRSb/ej4wJZwhKTytMuybElZzFt60YAy T5+0F2YLIMTWGNnyPwen68ThXB9CSEliV+QCSqzYlqbo5VgzKQuksnN6h9LszbPHO1fmqIUlVVdy uxxvnmOhVEarJVQuKyklbgFx1kqLA0xZliXZ8pkQENnJ9WXxY82KHChhyMriwOq9vXWsZSeU3bWw gzjaJUW2lkGKuN90TlbC5VgMudJmEpSjMS0CZjtpQ7ZeW/EtwsUqcw4o8luRpioCa937VeRWWzXR qQjlvMwnYmJTKid0m3oVhIsdp1IxjIphVGzUtK0JObbNnoocOeqdIqaSJMnKP1mWbFtCC5M/HcJ6 BQYGMhKSewAAIABJREFUBvrW0PaINSj6KNv8tlt0UpIshXN/RanVx/Mt+0otPy1lWXaayiUBu7TD MbMsWxslOYyJZWsqySGlfUurZMvmVKdkbacl3hLtVJVkT67opOUuOXwRwBphU1JLLuudc7woSnWD ymWVxAB8uP/K/dtxHzVYOXL2JoNFj+Sip+hYFQq2cadkl7mMk6vf/vXly/lmgctNPP1VA51dZy3b gy0jXFiURNf8pz/jW1i3xDvJnizLsnH1ME2/lfGyo+5Yai1mCdpFx6pLDsf+2g7UkIsYd46KCVuZ 1mpspUr2emUngbY1F84K6dgup3vnXJy9CSXcako1gMpllSQPCPSvrfdr0bdjhHyIEwBT0rp+k9fm QwZwae2sySsvAOAubxgxafnhrZ9oNBqNdljMdQNgVVWg8F42kJV1T5BZfdOoMG+WALj114ahajXL siz7QqwBSRvmzfp224qZbto2X+dyGWtfX54hEpCCrTNHfhuz7d9ttRqtduSCrVkCkrfNm/KrvH96 K416eqLJcboScJBCwNHhuwMOY1xbwuIp7CKl7EW1+XWX7ZpmkTUHx/E2bZUdWmH/aD3jze4i3nmW QS6S3n5RVC+rF1QuKzWO4z7Hz57AxQtnzh5c+583Y6d+F+3DEJEzHFx/X3majflX4u/zAETBsH39 zL7raySl3/x5yq7hPyc6nrDTqN+c/3T/uWN9t5e/3nlL8V90e3f9TuNqf3fsbn7+rdTPQrQwG24u nzMqvffRjP2TvFF46vD5QhGE4O7t7bMHr+284mp63K7cT0e/ufNayMB5/wknkW/tysz9vJkOjm+v OYgUsZ4jVKqzeGK1bZ2w3gGnDM4eOlGSrikCq4TYtdW5cgJiPULO4TxMhybaTvWgR25Uc+hST+VF tr7M46iYAAigB7785OUv4uLY2bu4CeEAGC2jJCaA2iIBhBAemHdz8yu1ZBS2iA4zaZTVc4u8uIfM 35szYNuKdiMGL5v94tmcZfqTMcCLr41v7w2gVi0AxJTHvrXn/4a0AwCTZfWJEEJu4P+d+GFIKz3k em+/qnrjehZhw+r5Et9Afz8PPYGyDE3s1htsa9MEkC3BxLrqbT+NDTKxapVchvFG4KhullJlR7tV KcDeCmJrBbHauA7rZsS6tlbsYHWHZIQQWYby46H/mpR/ANS6rOw4zg7aAjOA5Vv+un/qc2HRgPWJ BRYJC9cRwhDCmE05Nr0k4bU8CWEYYiYghDBMEfcFHq2HzhWz/xyDlT/+mQJCADeNQ7RASEtvb1se WOXSBPjoNQzDEIYRrIl5ixhZ7chiBiIhRYMdmgPrf0oaRmmrAmEsia3hSgJbKbay7CmsxVl/MrZ4 pTHWjQfW7La2F2me7ae98Q53sGL6BKWCoHJZGXEUpuIoaUz3OY92r+19K3JC+LTzBQRmyHHHku+L qYe/bffGuYY6QogSKDsLluVxZwjJvhJ39XahEmMAfLzdG3ccACz+bluCSEhBdmaBaLcLLVpibZXO l2zdtvc+IUxB4tZFQs+IYEJY3zrk8P0Ce3XF2lz6NTmkKSnKLowOIlkypaRwDLNbmCjaxrLLLhL/ RPoCpRJB5bKSUuIzaQv0BHQaAqDn/22ah5/avb5J3bzXG+E/t/bVhHyQ/tmcqDwlvYaQcEsWteM+ QUJAyK0jHzar48kwDFOzXeHbG6a381e8WH4wPEKrUnkFTr9kImqdo0zA09oS2RN3z6yqyTCMV/j1 t7ct6FObELdOkz41L+jOMM/HGkq9BJQsSa7fj1KyFIu1f2SKyecj/SH+RhmUfwjU32V54jhwfgL+ LoshGHI5nfdDONkQOIPBwEGnt7vMhMWLpU5fRjmGRZFe2vX3pzdFLsc65eU4Dqyukvi/tM3+VnRD njC2h5pQf5flSuXo1pTygdUXdXP5oAw6vbeuWBYXvFjKcXJugRmsT9EKdbpKdMJZpXrUKFUfKpeU R0A/qzBPYKlnYEr1gsol5VGgfjUp1RC61EOhUCguQeWSQqFQXILKJYVCobgElUsKhUJxCSqXFAqF 4hJ0ebNiSE9Plx1OkiCESJLEMIwkScR6sEKJH2h6mv6B6ZUXJZRwWZYZhqls7a9du/Zjea4eM1Qu K4Y6depUdBMo/2QcX2gilW+3fkW9TPg3oYNxCuWfRhUVo8oPlUsKhUJxCSqXFQX9/qdQqhhULisG +8GHFAqlikDlsgKwuUYvXTCL+U+nUCgVDV0ZrzBk2XIsTUlRgHICTZHTvCrfEieFUn2gclkRKBpY qvbZz9CWnSXSZXOTOM+NUpmlUMoBOhgvb4S7B1b9d8/FLAB89sUfvvzhUhYPIfvoTz8djbscf3jJ +n1XXDig2kExlUG5Q4bi4/Rix5/JcBrP01E9hVIOULksd6TCXPa+SfnI31ff52QZkIy5ufHH9l1m n+7YzO8RCpVRRBCdNBLCrZ0/bEnlnIJhT4cnvhAvnN3y84kUo2PQpT2/HE5KObfrl5OZXLnWlfv7 ms2XM6/vWLM5tcSCBY4TSgi+c27X1uMp5doSCFnnf/j5D1cuTzBc++nzd6dPf+eQ812iVGaoXJY/ yktgcB4DE0IC2w8d1b1tSH1fF0bGZb6MwcW+YD3hRN1q/NZzd8ClDZ48MtNZFCp0qYjbM3zsYWdZ jF83bmPCrVPvjD2UYgQXO4hhvk8wWJPHRjPRfxlKKOjBCDmbJ404d+vml5PeL3IHhMzDc3pGMhr3 JWfvFc+Xun/YmEMZj1RlqRhTD0wce9AVuTz8n+bj1gm9uzUlQklaTqmU0LnLx4JWpQIgGAsdA/U1 tILZLEkSCIj8ULOJcpEVIQPwwb7LL4cJmxa0HNE2LNPQpyu6ElLylGVFTFyyAdHMfbVTUKOm0WkN /eQ4SwvzAI43l0tVIeHPhQTpcxBfpDgz797zjc+kg/2gLiEf0XULKzHib0A0OgAunFbEXd4vfL5q wdAot/JtAOWxQq3L8kYSAVxOvZpyPW7JxhOOMZwgWT9ajuwuoxhiAyWkzAO8/AP0fk0GDJkNXMvh bAeCmw5+MUkxPPvOXH5LwJ/fjOzz4QEBBACXtCGy56e3HMoxJMWMi1QxDMMO+V6x7TL+XBvNMAzD sD3nKKNmLmldr/GrlNiLa2ZOWhGnFDV0/NKDWz5iGIZhBsVcywcAIXXZ9FYMw0T2HPPiQUnr3Ob6 gz8cUC+w79EDzzXyUEJ0GqtY6OyylXH8uwiGYRhm5ppTShs3TR/2xZYtLzFMm8/PANypNe8yDMMw TJ+5q1M5ALrB37zdQN9gxe6jTZyFyq1+22f7dG0WXvJ9VgMw3dj84XCGYdghn142AICQefrtnizD MAwTvVYZqnMJUyOnKkcB224Fl7Rh6Pj/bV4xkylmFJPwvF1rXlduyy/n7gAAuKMrZjIMwzARa/+8 CyBuzdyZcfLc1jXU41cZSr7nTuVzmSenRqoYhmk1fVVWiRdDeSJQuSxvNDWbt/UnF49s3JI+cGA3 ACwYAGpApypyaDhKUUznQFIUAJ5A3v17htSTHz3zheql/iEONkrA0zPSCkQx+w9x+YztlwtadOq3 f8Frf+UCEH7/8Hn2mW5B9rTCseVDNvbcxUtS1oqhOgCZ++p2mDBw/xVeyjs0JK1T7TdSAXNh3oF1 uUoGY/7V+PtmAIJg2LZuRu+17sl30jdM/W3oTwkA9r/XeOblCTcL+b3fTulW7Kr8Q9s28dOHdOoe 6scql/DS/Ffnz587d+7cuXP/c1g5wzzzt7pdpnx8o0DKO5s7qeO6axyAu5nbXx/+fz3PXNk3LTRj z4KOk44duHGfL7w5IPbFkDnbBbBNO7Xz0/u169PJr4TBkmAq5Q8la2uffXfETq8Zd+7Ez9z+1ubE e0Dq/NrtTj+zJ0/ibxwdMaFLg5gUM2C+HHdZsVttt0IQDNvWzfnoZvTNO1tbOp3wppXj/m9ZWoeb OekxnxnHtJ5/TUDGngXdpnpc5aW8+NcndJh9WUD4qH8vAN7dnXj3qxH6ku65c/mpb9Tu5PXhZUnK eTlzyoyfL5VyQZTHDh2Mlzu6ZtGTXu/Eg9UIPBca+nRhYaEg+D8zZ05hYSHP83CYlCxtmFxk1rLI HCQhRA+807XhO8DUTzfcnD2IFWKVcAJdWPsmf+3ZsPlaqicg82aPqP4L8NLK3292fDZ9yDpxz50O DiWxDdpOMY/t/2LNVa9PHRUK3DyzHfhocnQIC3R+8Z1ur7Q6ee3T/hp7YxzGriZgXurW2UGAITQ6 jFMDqb9+ZP7vqfH1dCya9hgZTh44hfdCz2efi6pZCKgLLi5cuB7A1RMHAOxc/uEJ5PwEhGUZ0UiN 6/K7+/eOigoAhMNbF7X67Ej3+h6Ax9SvFs9pueHawkFNHumsXmLKUM+JWfVyD4BrFk44NcwpZz5D yz+m9dAD+k7jvwmftelEcv/BDlnst8IELPj9g+HFlu1MwEdb3hmmB+pNnId5H2ZzXMbWRUCn79+b L2fHALH3ufXQ+weGE86/jre3/uauku65Q/nmlEOLgZ47v5l/0j1+u/R7m9xHuVpKeUDlsvzheV6W ZclklCTJbDYrYmc0GiXJNhh/uJ2QRRMTYgC+OJU9p52PJUS0Jig4P86zFff+uvfH9kp/FTwhhNQe 9+PEpp8s7Z12hRn0Q2fn57vZ6K/TWw5a8em8lgGTdt4wNckvALSOfUKZXSThFkHiuWx7K8JrKYNq y4yhYDQCuhquzgbmAYOie7cL1QGA4N0N6wEARmDMkDH/v70zD2vi3NvwM8MkGTEgIqC4oCJ1KQbF fbdo3WqtxX2rSz/rgj2eulRbQdt6SmutVY/iVq12VeuxWGtdqkWk7q1ahOK+IQWpIkIYYUgmme+P ITErBGRJ5L0vL6+QTGbemUye/N6Zd+4Z66PRDB8eUe85D4AvBLy8pPpZ4B6LFCs3zEMBcCUe/lQA NoNbC6j8faXZShWoTtAA3jLD+lN1qLxCDQAgW3pG1DyZExXiZTOlqZBaRTMQit6oBeiho0a81kvM Hz7uTffGLAAUGqbQ2t3mRfPXCQDw6qgJvb2o4cOHf+r/XElrTKgoSGfcJVEDClu5lHf91A5g5oxx wZ4Fl1GUZEEvz3w56ZPxC2LXLBls/g0X7l69WiO435LPvx0CXM3kGnd7BZh3IOURgMsHtiRgbKdm rKgRxaQTN3KE1Ph1HRdcaMpSAESNaDxpUwRTv0sY/e+Yn7IE4Wb8F7OSRItjl9bwGsMYGqEo9IK6 DQZ2XM+pHRoaGqpq4vEkRaTTx2yPV6efn70xhQPA/Rwzw23ChBbFlZYCBL4QKMwvMMyhONjADlOR sObHZADc1QMR8fqRPZtDAJB8NfURn5kwof08OqyG7dUvQiEm7Tp69RGA5GPbgUENlWy38Lf0ew8V 1GoWGhraonFdiwrF/jYXDa1qvwA4lpLfMjQ0NFTlR+5YXHWQuHRJPAFWLrN4BoCHasjHYXR/P9rt xXXNJrSZ12VyIg8oO/77P+2AJeGhtc1nw//6TrA3TdPuqgMTVo1oV1sW8GrK7g/HqOrQNB08IiU2 OaY5A49WLy4M2dnOW97sw/Tlc0LVAABKTlGGUyiGdijD1+zuvmmCn1ze4sMz1scuS1wFAKg36Hbc 2jd7NqRpmpZ7fn25AABrMvKq8bAPf1x0W+VJ07TnmGvzE9eMLCY8uJSvabnf3CRxUc+GND0p0bzI ZEzi3PAwcOXl2Nvj2tA07dlqTNTui6MCWSiD5swJnaiq415/Za81M2G1+lZkfz7ah6bpNuNu/3wj 0h+o33/pb2sadq/vTtO03HPSFd50ibC5zc3n3+i9O0drz+4lp2malo/+8pL9NSZULFRVjc0TRVGn 02k0moKCgry8vHPnzvXp06dKWlKOmF5dozeg0+l0Op0gCNL/f//994ABAyryskSB43ilUgkIHCco lSyQs7Gvz9E3/to1pqWNqXmOFxilkrV4ilWaljECl8OzXg4UNgKfwwlKR6YsdiYcLzCskrUzFxtt Lk8EjuMtls5zHOy3x+zNAhhG4HI4xsusty7wHC/AfKtavmz3VUOrUMxGMcH4pXZmm/qpU6cCAgIM A4gZNzc3Nzc3mqal/y3ObToJpLB/9mCUSqXhAQOAv/pDRHzw2b02shIAwyqVDjyl9LJ8ys7CWS+v 0jXXsTaV6vWnXbzSavaOL5BhADBKq61QQptLXiUbrSJUMqQz/uzDNhuvVp/vSL5rBMLTQapL58TQ nSqXrkgFF2MEQjWBxGXVIIrFXZtIfJcEghNCOuMVinDl4MrVq396YCW/KM6kbrS3WUkyREexmLJC 1o1AqG6Q6rL0CA/ivt6Hdr381H8cOH3XN/jFES+196Sh/jv5yC8Hrj8Q4RPUr0+YqqGH5kHKL9fc GObu9nX/7TNmWnP33OTjRw+cudKvXz8YpEN2llGUmNJ97iFdZG6YVjTYhY1vNk1Eo2jDpD8vzanc NwSBUL0g1WUZ0Oc/enThyJ7LbqrB3YOyr8RfzuT5fxI3bj94p8GgN9968+Umj4/s2vznvQKFV4OO NA34Dho9pWkt3V+/fnfqSq1Bo8cAEA3/HIT4Lp8KLisrhwcAgcvKMjw2f/1eVin9ccK9IsOm8UFO ys6d8ffu/mFPeSnwnK2x8ja21dMjZF385vvfHdnQj26dWh45c2bkxjRikisJEpdlgaIo/55jxr8Q 2rZNME3TDENxmX8zDDOgcxt3uXtwh44Mw1zPzBVlnr5BAGp5+3mxYm7GXYamr6fdvPFkRnZD7Nn3 XY6naSZ8tfH6ZyHz1zY0PXLzBceXcX4Fy0afsX6eS/lxKE3T9NBdKY8AQLg2zdNv1+2CG7Fv03JP Pz8/P2/3EdGHjK7NQ9H9Pf38Gvh59o8+KrU46aspdBFhH+28YDtG+L+HThmZKTx5oFWnjBv3Y1ra H9bKy4z4LX3ausndh/xpI5NtbKunx2Hz5r1lzbrvRJtezWsVkLgsCRKXZcRD6a7VavP5oh2SpgQA gqAFoNFoAdBuMgCCVNrp9QBNURTQoJaXFwAKJSrcTLGMPcl3mZN5aXOX70d2/DKLkRl8l6ZUse+S tfJdNjPxXXKAfu/cY3eLLn9M2r0pGUWXUjtI8/EXz09sYfW0EBczKvT4w8fnu4yLOgII3458Pmf7 pYjQ2rVahCdnqPV6/cPkr2MXv3QmUwBwP/7jlxY3SVbr9eoLvotfXH3yAQBoOGDJzez7v65pEjVu nq2MAxhZL/QyfSDza/pCSEt/LxubW5A3fmf5l/ZWhA2hWFk5D7mn5CygKHmmQt5lqDYtnjF20tiy mUqqFSQuywiv1cOkAKzp0wDAhaRrnCY/7eZ1AAE+SoCuURNAbnZWnpZRNmoIoFAjOmSErQ6+SwAb fpLKyVtfzf7hBcNlf6mHV0rKS7e2009LNTNvnHN4GB32bQoH4J/TW9YfTQMA4d72qOFSNThy87mH 1/QKdyVbywvgTuycNsVjx/YxLQH4BncLrqcEULtFaG/g+kMe4A+viW6/5l/BSkDZNmpTv6gVv/AA oKbDAhp5+fQK62Twa1g6K23ANF22rk/tBn3j4l61GLgV0L1f/z7t7F0YqgD4jOOfhDM0TRvLXusP oszmTYp6pci8KaRtnBFKURTd5t/nsgSA2zrl+X1I7lSDmrI5SXKJSjtdv7nbpGM7V3a+HbH2h40z ZHSbVTlAxskvQiiKoiiDjbR6QeKyLMgBlnkSYQzANujwf0N7Zf95YP3qmNjjt7oOntSpYQ2Aadiq H/Dgl13bku/TIS+P7d4Cf8TtM77Rnr/N/K9n03cJDNm2bd6R2dvTgLzf964LW7Vw1rDbvAhA3qDL 9gy1Xn9/ZZ0v3t93CRAORQbNujY6NV8TvzkCSFBrtADUGfFnHmgB4dDCJhM+anjizsN89f014a37 LoyMmjJlxrzdr3j83HtZ45T14eYNEY5+MikBC14OVgICp4bKp6gMLiiEeDuLBwBPffw3/41Z3F41 a/G+2I5KG85KGzA+nbq3UHo1DwtraUu8adedpGhKRQ4ZqJx9NT15Z+zihZc52x9EGcybG9M6S+bN Me0ibwnCwQXNZru/rxXFxLkZnafu4KEcGX1QBdXhm/dXjW2ecXhJ18nH41PV2oK7gxOnBr71owBo 8u5smD0io/+J+wlveGUebNBj6rLUfDHvz0eTu0o20moFOTNeepi6QyMjNRqNTqeT+7aNjOzC87wo it7NO0ct6lKo1VFuMp22UKvVApDVfX7+vGC+UFeo4TUC06bvKO+gVEPq2e0kVwffpRpoO2DCWIQe SXnHf9vCuVF3Au4ekF7yD+6U//svm3ffvgOgUIBwK3aV9tMz0xqxDAJ7mszZGwCEuwdXaSN2z+0W UBuAvxLo/8HjTjmPsv+YETR/+qJ6M4cOyIrXf3Djp1cDPQBu97w6o1bNuJC9rJGhJe5ym9+C+g2b tu4SQu37+depfRtcsHZWlt9Xp/C2OP/Q37PC6oPP6w1v2PkgGtV/8hYHzZt7okYogYApC7Hgw4fc 3YOrtLqw/e9F/v44JVa/tx0PePn5esPbq76vFysci11ldInOWBszp/WuW6tfBZ8rW3Rk6bDOAG7E HgWwb9OHJ5G9A1BlFSCwenXgSVyWhYKCovOYoigaH+t0OkEQRVEUBcEYcKIo8oWCTqeTxllqtVpB rzeIDxxd3DPpuwTUjE/w63NC+48fJCYNSt5QHzHS8zlbw32mYclvy0bXzWyTwotgangDKPJQWtvR hQLAy7znz3rh+xcGdj1+sdaKxRN+iVOdfT9sR8qrka2/m1h7Mj7P1k8xXtEt98TZjKJPsIYCVB1P BgDUdFj40MGjRw9oHSZXbRnVX2XtrCy/EyOFgL+vh+kz9iSYT2feFAqA8PBhE/vUy9eMeOOTek+K UQH2XKJaQPXk+vcCYOywceN8NJoRI2bVe86szdUB0hmvGp5yGOSz4bvMF5jur88Sk5Jkc2YGG/OH T9+7Vz935tRuLTzTUy5mQwv4tp/gNn/KRwkpiT9ED5ubJHqa/swzgcPmyD6L3JiSw0PgpPFAx6Pr vTPy2Dvdg3L33srnoH2cDyB1/9LXvtXtff9VJicrKyuLFwAoB86ce372d7d5gEtZNf1IZNRAJQB4 6uNzHvB8RvJfCUANubJ4Z2XJCBD4AgACz9vJWbNnbX4QT2ve9AocNke2J+6WZ4u2oaGhjetahB3b M3yG0SW6b+10a5eofRtpdYHEpUvyDPguAUAAGzzs+L59F959QXqiDkuBbTbzP8NWDGxI0wNvBI6/ sKDb1hRh5PqrG/peD1O1O+M35b0QSg0BAFNUCTEDo6981vRTlbc7LfecvPNaxuEFvRe/nxnZE2DH xk2b5037Lshd+38dcjMeAHg5qI6nt5+fn9/W5DwA9fsv/XHRkWbuNO2puvOfA++GST1eJbCosbt7 w/ZjJ/7nu0mdfW06Kz3NN34xJG0bKffunoCE7n7uzMitFmfaWatbKdv8IMps3gwZe2v/zSh/MIM+ uhnjMbu+jKIoqtawbyyOlkgu0dYeFEV5jLk2/+LaUQwgY01mXm/QnaMxs3o0oCiKknlINtJqBfFd lifEd1k+vkvJL6lUsgDHcaxSyfAczypZADnnwrw7vZasfj3Y0hrCc5zkyORzsnilj1dpWsDlZPFg fUqS1JXgrCx3bEkwHTFvSl9qQYBMpuNyOFnt2qZlIs9xAuzaQkt2iZZkI3UE4rskOAmu77s08UtK 63LjwDvNR6ynQigxSQxd9OMoq6w0fQvr5VPaExBKLx9HVq+y1U62llcG86ZF3jy1eLP6Cq5IXD77 sM3Gq9WTXHoXDxq2Wn3/fU4QREbp71CyEQjlD4nLasCzUA4wSh8Sk4QqhpzqIRAIBIcgcUkgEAgO QeKSQCAQHILE5TOBUbnoLFSd77Ik6SQEnrcxULyipJN2m2HOo1unPo2KiIjaRKSTzgyJSxeETxxv 0DG6tZ0g+S6L3IvOgkO+S4kXJy69mFVuTS9GOilkJszp25aWu2+48MiRBj89jksnPwnqsRNtej7n SaSTzgyJS5eEA6LjrqvvX9nSddfw9luzjO5FZ8Eh32V03PV/bvxS99v3F+xMKq8FFyOd1Grc+y5c /i+YmUKMVLl0cmPUdCKddHJIXLokasDLr66J79L4Cn90xWSpaus3c9M9AWdjRvaPPiqVLE7lu1QD fvUb+wb27FDkjbBsOYAr+4vElwbLOnfIMM3WFA4wM12+/dVxHsVJJ2sEdHy5f6+Wdi4ZtCmdFDLP LerLSFr1b07eBcounaTpoUXSSUt1Jrft9eB9SO7sThulk9Ia9Z/3pVE6OSsmdtNMuVvb1ZJ0Utos 1VM6WYWQuHRJPIHcnOy8u6eiB65gpg821Wj5dY1Iz9frs38XNs388Sr3fPeBvy6e44S+S0/g+89X L53YdR4WfD+jnXXLgbQNQ+b32ndbr8/fEN4cADKPv7Tg68MZGn1+9iuNWcl0OfF0pxtqTe6do9em 9H57f2oJ0kkbQqMibEgnkRZVv9O5QYfVes2d4yMn9Wxy4K62DNLJTX93kaSTY9tH3RKs1ZnKER8e UEH1y41/JOlktyknjt7J1eSnDk6c2mzOXqN0Mr3f8X+OTfXKPNiw5xsf33msV1/ImdKtGkonqxAS ly6JEljUs0mtJj20y/+XunaoSS6wrTs3T4v7PubbBBPfZfLmQ6ngfg//VrdsspXvctVLU6O/SgfL mGkWlT2mRvbG2tO3eKpY32VTH/8WwWGtFQbf5ccTG7GMb4s+o0KoEm8k0aBpw+dCugIHjx5PtW45 4NtzOrNuyCvRX52CdAmmV7OpwICBk7/5LU2pZCDcjV2l/fTjaYFKxiPghffW9Nuw5XiZw8MgnWzm 36y5JJ3U3j2/HKroGX2UYAK6T1wXQu0+ddP0LdbSyUY+Fi61QuCj2Mjhjbz8B05eAFx/yPN/7Flb IOCsAAAVmElEQVQNnN36ftTHMSuBHbk8PIzSSSXzx57V7ZZ//EKAB8M2mr5mrbBp1y0eVKFakk76 eClvnDoK4OfPo6OWfb4DSMuqdp6LKoTEpUsi+S71ev36+cP9TYsoLnG83Ht5oj7spb6tiu584z9h ++Svlm3csXGlbd9l8i+BV1er/NwP3NXa0yxWhO9SDfQMe3Xs/PWJm+pN67vtno2WsyM2qC8emn95 VT8/+TtpAsA2/zw//cCcVisGtqkVdUiA8BhQFHkwpSjXlHimxJ5Wzlo6qRM0gLdh9qDqUHmFGgBP J52EtkidOXbEtC+Sky+3Mr6tNNLJ8LFjhw9/4/z5pMnPVzvpZBVC4tIlKd53OWP6WOf3XXoC/9z/ R+Du/XXlGMAWWrdcyLl69ZGq/2tbvtsMHMzkIeSkXb2vHDAp8ptNw7UfXeaYwFET3P696qccAFzK ltlHJo7uVeyFkgIEvhAozC+wY/c1e5IN7DAVCWt+TAbAXT0QEa8f2bP500onlWyx6ky2x6vTjdLJ n2NmEOmkU0Hi0iV5BnyXSiCyb1O5Z4PX4kbuODOxiXXLufSlrRrQNO2umjppzbpQJYR/Elo1qUXT dNvpP6yNG+0FZuj6xMXpk7xpmvZUXVq0a+WYoGKWyKV8Tcv95iaJi3o2pOlJieb9dmvpJBC48nLs 7XFtaJr2bDUmavfFUYFsmaWTbcbd/vlGpD9gU51pRJJOqjxpmvYcc21+4pqRDMCY/vLUG3Q7bu2b PRvSNE3LPauhdLIKcTHfpU6nS0pKunnzpvGWD06FtDGN/+v1elEUFQpFQEBAy5YtRVEkvstStvyJ xdJ0GgvZIs9xFWmhtL3EEqWTRW8WwDACl8MxXma99eLVmU8pnTR+qQ23OXEiZaQE8V1WBklJSUql csyYMR4eznjIxkIPrNPp9Hp9bm7u5cuXL1261KpVq0pphev6Li1bDhtyRuM0T6hg4dJTLdEonbR8 vthZEOmkc+JinfHU1FSVSuWcWWkPpVL5/PPPp6WlVVUD2Gbj1erzHcm3i0B4OlysuhQEgWXZqjqA UCKiHRQKhSBU3dVtpBIhEMoDF6suabqsDdbyeXl5+bw06EV/98IfN7K15deukil7ywkEgnPgYtWl m5ubXq8v7bseXDqyZG2s9LjFqHffCqt7+fMvhLdXBHq5lW/zbN7aTMLNrZyXRSAQKhkXi0uapksf l7kn18b2nbl0RIhvYW5mlsZDr9cz9UXQZUne4ikmLkl1SSC4Oi72HXZzc7N3fNAuOs1jIC8nT6vT MR5+/nVYURTdAE3OtcMbIyIiIjYeSOGlCXNu710dERERERGx+vSNh6L48MDq6NOZvCiK6hvxEdF7 72tEUdRd2bvx8A11aVvhhNWl9kHiVzvOPHuXHPOco+vkuI/yaXB8KQJ3a8eKxTNnRh4rb/MmoVxw sbiUqsvSgTovvvny79uXvxm9/eKdbJ1Or9fr3erg5w3rZGFLl0W9nrz/x/QCvV6ftW/Rp3eC31q9 YV30vDbfrFx8McujUd2Mo0nper1w/cT/qIzDN7IEvZBx6HByYz9lqZogimJ5Dh8zkUVKvsgESQjE /xFC06e4kt5unM3f8VPGH3uG4pI/vvntNjRds8fGnCfPmW4rS12Qwz7Kp8LxpSS812rCt0K/3i2o KjwxSLCPi8UlAG2p0XgG9VsZvTC8/u1NyxZ9e+K2VisUPhBfiIjuGeihqOUdJLrrBG3h/Vu/oP7L 3ZqKBYXujTqNqY/z1+81bN/v7z3XHnFpiWefe6GDmHg1Izf1z6tB4xspNA4uWxAEQRC02nI+rcQB 0Yeu56uz79w42y9vaVhQj4RMAWyrXecvPe+4MFEmt7hC3NVR1O+3fHsEzI8xZQCxyanpd+7cubPd XBfksI/y6XB4Kfy1OGHFtiXDxkzsHehKQ+WqDy4Wl2Xr0oo6QXT37zPp3XfGtT2z8+IjQAd4ursJ OlHUF41J0un1FGpC1ImAqNeJNaHRi+7+rZtT506dPHmvz8D+L45IPnHuRMLBHmHN6NIPZCrfzrga qOXrxyq9AgI7Ltxz7V9I/mh3EviML+duSLdpiuSvzek7fc/+LdKTS3ZeMKtehLTlE0OlAmzW5uMC slaHt/34cKr04pWdb/aPPmoyNbd95vB1+/dLIsi3d579a//Hks/xiLn10q3tW+ckTTp3zTD/8ZIp 0rJ5lg0AgNR4qbVtwsP79pu5XTJMmpsiLWA7De7fWxVsdfl27waNG/kHBAQE+FtnFhWiSbCwdtoy ThpFnwD33cQXt6ZwALd75vDPYmOn0XSHFeet19F8KSVaL5H01bxZSeK89jVlE7dxtsWjZlZNPvP0 9LZuNE23m7kty+ZeQihvqkFc6rnU1H8KdXpBWyiIIkXVlL4zoqgznUrm06Q7rh27mAGg8J+/dl5D u2a+orxut44ZB/ed6timEesb1Cbj14PnmncJKstlKxVw7NKYeIGT1vT7dctvOcg/k3AxX4ANU6SQ fyt+88iVGV9n3L90aMWH4zr8bOZJZLpP/0at1z88E7Nh+oq/eJ9eL9WNHLgjBwBurRy3flC/UNMF 52bu/deQRa1W3L1+KPqzcV3bbqlx837qFxMOvBubAgiHFgbNdn9fo9f/OSe9yxs7eSDj1JZ3vh2Q qtHnZ/83iLXVPMsGAJkHm/adNinutkaTML2729HT9wFrU2RxG8WIJxI6e9Jtw5eeuptn9aJCTHp3 sLm106Zx0ij6BPAgKT5XowXwIHPv2yM+6Hv++q8zgq3W0WIpJVovETJ6/hJg8aFLD9aMVNoSj5pb NdMW1u9eK/qaXp/9ZuYbETuvFLurEMoHF+uKlSV0dDlxq1YkiaIIUHTLNyK7uQNMTVh2j0Xv8MVT Ny1d/u+vRYqiB74R2c7bTScyASF9qD+4Vg1kIuqEdqKS5L3qyURUdXVpDdXU0+Sz9O05nRk15JV6 21ZNH98HABiooTq9d0kbJVBv7ALMv51b8MReyfh3DuYPfrX5zoNbALQCOoYvwvSww3cXDkrbtQUL 0juZuzlui0uO//paqC+4F1U4vGXHW01ZcJ36gJdBuHtwlVYXtv/9qN8fp+zR723PA96NOwBjXnnd ffnCmf2CbTbPsgE3Tu0HPno9rDEDvDBktLhADUimyO5b348SHx4AEnP571Di8Hu27Q+afIF7cGTL //Vo8vcVzefNzXb5ImunP8AFh7XmZYDwx57V7Zb/9kKAB+Axfc3aOapdt1YNNX2PAuAN22Fx3JHR oX4AWMt1tFjKR7GRw5VAo8kLsCD6Ic9n2FgX37ohFO/bwMtLmbrfKB5Fj6mRvWe3O33rk5cMVk0f QHv32Fqg78/rok67J+/V/9IhB4SKpxrEpSxg+voYTT6v1UOhrEELgk6P7rNjoNMKehGyRrNjZuu0 Wr0outUJmb0uRlOopWUKN1EQdHpA9A4ZFhMDQaPVw63dxJiO0Gm0upIXakUFDCQyfnb3ds0+0nfT p0oYx0WxIzaoL4b/75MF/fymvJ2qWdYIMFE3WlZgXMpWT9XUD3f/NjzER4XzAODT+fsJbss+/+p2 StTk7X/5m09fCNRyZwCAkXkb5mf4+REKgPDwYa+F1c3XDJ+6rJ4SYFqMys8I/v6LTweo6i7ed/uD wY0tmlf7qmUD3JXuT9ZQkCyTRlNkLzF/+Lg33Rs7dtCRYVjGq9GQN6NVCzqfuLqyebBZxFpaO+0Y JwFQbNHJOt7Q2S8EvLxqFG1xq3U0X4o966XZuhQaprAvHi3ydOgEAHh11ITeXtTw4cM/9X/OoW1B eDpcrDNepvPLeq1GoGUyhUImarQ6vQiIglYjFB211Gs1WumhqNdpNQJN06KgEXRF0SPqtBqNVvpD p9WULSvL2nK7SDefEAQ+Jytl48SA5RjyydiQJy9bmSIBeCLhYNwVAXiUkrAcUPl7GBPi1rmDwIIp w3p4a7OTi55jB875758fvf7u3sEzX7bt5rANEzhsjmxP3C3PFm1DQ0Mb1/UA8Oju1QfK4EmRMevD 6P2X71k3z7oBvkEdgEUf7Iz/6+T3g1Sz6LAaQPGmSAAQgILHPFDIC4bfBMNtcjPOn0iGqlUDs6y0 5am0a5z8My4xR+BOxEyZZ+YYLlqO5TqaUVrrJeyLR4taywa2XwAcS8lvGRoaGqryqygbE8EMF4tL hUJRtrPM0uBHB6csw/yLR6vVKhTF23JLR5EsUu7u7af61Xfdley9bZWAwXoJwdIUKfH7ljFymq6j mrh43/UX6zGQgWoNAK3CpvXG8gY03T8mZVzIb12HbuUAj9DwJYBs0WxrN4eFGlJm8j/ADIy+EeMx u4Gcpmnaa/i3PJAWv6yxJ03TnhHxoz+b0Na6edYNKAwcdT3u8+vLXmy75Mz07VHiQ14oyRQJcJvD mbpd5gGL/OT02M1JALir29zlNE3TDXvOi973fVfzw862rJ22jZPPvzQzeO9Ub7nnB5m9ZhveYrod LNfREoesl8ZdxKZ41Nyq2ei9O0drz+4lp2malo/+8pLVEgnlj4v5Lu/du0fTtK+vr1wuL3Hiysfi qh6dTieKYkFBwf379zUajY+PT6X4LoswM0XyiWHuc1blx7cWON6mR1HgOR5KJQuB4wRWyTLgEod6 tht5Od9S5+340mGyJCuHpqXI0qoBHMdLb78QM6DTntE5ca8rn8zJcb2lwOXk8AJYL59SVWB2NKAo 0UFps2Fls14WM0PjFBzHw0p7KRLfZcXgYjV8QEBAamrqhQsXyn0kY7kgGsTAxsSUrhb38/Nr2LAh z1fqkHBzDZE2G9lawZa7UcJoLTKoJi/vWLgPn31Vpqy0WroNK5LdCaQGCLfmegZtKXqtd+zlUUqr CR2DUXr5lMHH5JgG1NEJyma9dER7af15VlUBVB1wsbjUarVNmzZt3ry5U/3mGLFZXQqCwPP848eP UYW/82zHs+qTTGli47nXflBPqTrxGxO4Pl/9UQ6n1Yge9f3JoTkHca2sNP06OFshaRPX2w0LCwsL C0u8J2vVYBGXxtAUBMG4N1AUVc7XRDpGaZ2XVS7JZFilTz3i6SwFLpSVxq+ARUo6eWK62Kke56fE z5uiKKeNe4LrIprcJ8r5kQqI4qdxwugkcVkZWHzw2dnZrrJbE1wC18pKURTz8/NNn3HCZLQJicsK x7grGM/0JSYmPnr0qGpbRXhmsMhKJw9NaaxIUlKSxYlvl0hMEpcVi+kBGom6devSNH3y5ElpdJGT 79wEJ8dmXem0O5Ver8/Pzz979ixN0/7+/hajhZz/bI/rnepxCaQP3nSvNe4QNE3Xq1cvPT395MmT ggk6nU46ky7dblc6U2Sk6laF4NTcv3//8uXL3bp1k8lkWVlZly5d6tq1q0wmu3btWkBAAMuyMpmM YZhKSCLT7JN8TsZxlG5ubtLgSqkxcrm8fv360uBKWNWVzhyaJC4rHMoW9erVM01JQRD0hvuSW3iF q7r5BOclPT393r17I0eOVCgU9+7dS09PHzFihHT9WHZ2doMGDdzd3eVyOcMwxmyqaIxZaUxMKTSl gejGQemmweqEw9HtQeKy/DGtK63HSZj+/NI0LRWPkoBDepdxAmNcktAkWJOWlnbx4sWBAwdKWfnn n38aH/v7+1sUd5UQl6b9J4vQNC02pQfWEWn9Z4W2tmyQuKwoTPvj1v0UKSKNtx6SdiBpSr1eT5mP zSRxSbAgIyMjKSlp0KBBLMtmZGRcuHDB9PHQoUNNu8CVU10a5y/t4dZdctPENE5jkZtOXmZWfVy6 UCleNowpKSWjsXKUnjEq6SiTo93GKaWXSFwSTMnIyDh//vzgwYMVCoXNx1JQSgcKpceVHJemlYGb CcbS0qICdZUQqMq4NC24nPBGieWIaRQa9yGLEJReNR6yNOZpFTWZ4LwEBAQEBAQU/1hmTqWFkXEn t64uLSQaxpSEs3a9rXGK6lI6Erxv375Hjx7l5uZyHFdQUFBYWKgv7/uAVw4WI+BEW1ic+DY9A256 KpzEJcERKIqSy+UKhaJGjRpKpdLDw6NWrVpSdWl6aqWi2wCro/MArOPSoq606JVb9M0rtM2lpcri UtoQxt+fli1b5ubmqtXqvLy8goKCgoIC6WRxVTWvzFgknbQKppeQiwZTkeloIev0tJ4VgWAP6Uuk UCgUCkXNmjVr1qypVCqlP6XQpMtf5m+JaVzC0CW3eZ7HQtFm+i6nDUqJqu+MS6WlXC5nWVYQBFEU pT+fgbg0rRZNk9EiNC0mgHlBWpUrQ3ARpBgyFpju7u41atRgWVYul8tkMimeKqclpp1x0zLTNDct TviQY5eOQlGUdChaLpfXqFEDgJubG8uy0h26XTQsLBLTmIYAbFaX9jrmLrr6hMqHoijjOHCWZaXQ lMvlxkGXlRaXMO+P20tMe0cwnbknjiqvLqWtJpPJpGhgGEahUAiCoNVqXbG0lDDtSlsnoHTpjjEi pT+NeWqvP04gFI/US5MSUyaTSXWlTCYzRlLlNMP6CCZMhhYZT4ubHrU0TUzTmTghVV9dSh8zDJ+3 XC43vQqwaptXNiziEuZ+dev/AUjrazqlxdwIhGIwZpPU1ZU64Ma6stL6uZT58EnT45jW+Wg6osj6 JI9zUsXVJQx3lDV+2BaXS1dh854G0fwctzEWYdIfF80PaFp34S3mRiDYwzRujKFps3Cr0DbYbA9M LvWxSExj2WvdB3fO3KyyW5sZsTjA92x0RW0WmBZnya3DtPh1d92tQahoKFtnpSutXrNehPWxSOsq 0piVpqEJEpclYjNcqrhNT00xXXKbwFZNWpUrQHA1nCR0LLLbIjpt4gzNdgSniEsLnLBJZcC0cw2r xCzmsfV7CQQHqfKgsehTw7zGLOaxzfc6G84Yl88M9hITViWkRTlJ4pLgotiMS+v/i6konTYrUeVn xp9tKBMjUTGvGicgKUl4ZrAZfyV2vZ05K0Gqy0rAdAsXUz+S45WEZw97laO9MK3c1pUaEpeVRPGh aXMyAsHVsXfSHK4WlBKkM15JmHa3XWXnIBCekmLi0t4EzgypLquGYjY7+UQIzwbFRKFrpaQREpdV D/kICNUBF41IU0hcEggEgkNUntaJQCAQXBoSlwQCgeAQJC4JBALBIUhcEggEgkOQuCQQCASHIHFJ IBAIDkHikkAgEByCxCWBQCA4BIlLAoFAcAgSlwQCgeAQJC4JBALBIUhcEggEgkOQuCQQCASHIHFJ IBAIDkHikkAgEByCxCWBQCA4BIlLAoFAcAgSlwQCgeAQJC4JBALBIUhcEggEgkOQuCQQCASHIHFJ IBAIDkHikkAgEByCxCWBQCA4BIlLAoFAcAgSlwQCgeAQJC4JBALBIUhcEggEgkOQuCQQCASHIHFJ IBAIDvH/eS07HLrIzNoAAAAASUVORK5CYII= --Boundary_(ID_xtEdFOi8lAxCsFoQpEbj2A) Content-type: image/png; x-unix-mode=0644; name=Whatis' "?.png"="" Content-transfer-encoding: base64 Content-disposition: inline; filename="What is ' ?.png" iVBORw0KGgoAAAANSUhEUgAAAVQAAAEJCAYAAADLgt+cAAAXNmlDQ1BJQ0MgUHJvZmlsZQAAWIW1 WQk0Vd3b3+fc+XJN1zzP8yxz5jljZiKueR4vIQ2GVGggRJRCxqIkJCWESslQKJQGISqFlPE7qvd9 /9+0vvWt9X3PWvuc33r2s589/e7ez3MuABzzlIiIEJgBgNAwapStiT6/s4srP24cQAANWAAdYKB4 R0fo2dhYgP9Wvg8j1ogMyWz7+u/t/kth9PGN9gYAskGwl0+0dyiCGwCA9b0joqgAoH4g+v591AgE ox8gmDkKGSCCx7ex/2+8sI29fmEM+peNva0BgtkBwNNSKFH+AJCEET1/rLc/4odkCACWKcwnMAwA sjOCtb0DKD4AcOQjNtKhoeHb+D6Cxb3+xY//v/Pp9bdPCsX/b/x7Lr8EbxgYHRFCif9fLsf/LKEh MX/1wYQU2rAQq+29YUXKjA/F0Bx5cyNlMyLk154hNhCnb5iD3R8sHeZlZf0Ha/tFGdv+bgvZRFD1 tzEyP8gvgmpj/0d/MCHAwGq7HwTn+EYb/eXnYhBl1/ae0SG4PirG1gHByBpA96Jj7YwQjDAKep8Q YO/0x2bJx9fwjx6G/QKNzf5gpkCq2XZfzAgWDA43t/3dF6wCzEEI8AUxIAp5hgEZYAEMgOGfpwzw AxSkJhapiwbB4AOCQ5EW4UibcATz/7Ez+E8a41/t/JF2/94jP/BG7GL+7vMv7T8eAoEP8v5LT/lT tz26aI/A5H96+Fd/v1rK18jPyq//VY8WRSuildH6aC20Nlod8KNZ0ZxABr0DrYbWQ+ugNZE6dWSU 73+N8s8Yt/2H1vvF5ofHazgG/JmD198zcPxlHfhfzujP2Pvmm+b/HiGg+sZRtwlkEB4RHxXoH0Dl 10N+ub7S/GZh3rLS/IryCor/57z9/5TtM+s3WrT9dRZBrE//0YWmAKCeg3Bqzz8670kAmr4CQPjw j04kGqFqIgDdc94xUbG/ddvHCcAAIqBHGMoBeIEQEEfWWRGoAE2gC4zALmAN7IEL2IusdgDCwSiw DySCJJAGMsBpkAvOgWJQCirBVVAPmkAraAfdoBf0g+dgDEyCKTAHFsB3sAZBEA4iQWSIA+KDRCAp SBFSg7QhI8gCsoVcIE/IHwqDYqBEKAXKgLKhc9AlqAq6Dt2C2qGH0AD0AnoDzULfoFUYBdPCzDAP LArLwWqwHmwO28PusD8cCSfAqfBJOB8uga/AjXA73As/hyfhOXgZBVA0KFaUAEoGpYYyQFmjXFF+ qCjUQVQ6Kg9VgqpFtaB6UEOoSdQ86icaiyaj+dEyCE9N0Q5ob3Qk+iA6E30OXYluRN9HD6HfoBfQ mxgShhsjhdHAmGGcMf6YfZg0TB6mHHMT04V5jpnCfMdisaxYMawq1hTrgg3C7sdmYs9j67D3sAPY d9hlHA7HgZPCaeGscRQcFZeGK8BdwbXhBnFTuB94GjwfXhFvjHfFh+GT8Xn4avxd/CB+Gr9GYCCI EDQI1gQfQjzhFKGM0EJ4SpgirBEZiWJELaI9MYiYRMwn1hK7iOPERRoaGkEadZrdNIE0h2nyaa7R PKB5Q/OTlolWktaA1o02hvYkbQXtPdoXtIskEkmUpEtyJVFJJ0lVpE7SK9IPOjKdLJ0ZnQ/dIbpC uka6QbrP9AR6EXo9+r30CfR59Dfon9LPMxAYRBkMGCgMBxkKGW4xjDAsM5IZFRitGUMZMxmrGR8y zjDhmESZjJh8mFKZSpk6md6RUWQhsgHZm5xCLiN3kaeYscxizGbMQcwZzFeZ+5gXWJhYdrA4ssSx FLLcYZlkRbGKspqxhrCeYq1nHWZdZeNh02PzZTvOVss2yLbCzsWuy+7Lns5ex/6cfZWDn8OII5gj i6OJY4ITzSnJuZtzH+cFzi7OeS5mLk0ub650rnqul9wwtyS3Lfd+7lLux9zLPLw8JjwRPAU8nTzz vKy8urxBvDm8d3ln+ch82nyBfDl8bXwf+Vn49fhD+PP57/MvCHALmArECFwS6BNYExQTdBBMFqwT nBAiCqkJ+QnlCHUILQjzCVsKJwrXCL8UIYioiQSInBXpEVkRFRN1Ej0q2iQ6I8YuZiaWIFYjNi5O EtcRjxQvEX8mgZVQkwiWOC/RLwlLKksGSBZKPpWCpVSkAqXOSw1IY6TVpcOkS6RHZGhl9GRiZWpk 3siyylrIJss2yX6WE5ZzlcuS65HblFeWD5Evkx9TYFLYpZCs0KLwTVFS0VuxUPGZEknJWOmQUrPS 1x1SO3x3XNgxqkxWtlQ+qtyhvKGiqhKlUqsyqyqs6qlapDqixqxmo5ap9kAdo66vfki9Vf2nhooG VaNe44umjGawZrXmzE6xnb47y3a+0xLUomhd0prU5tf21L6oPakjoEPRKdF5qyuk66NbrjutJ6EX pHdF77O+vH6U/k39FQMNgwMG9wxRhiaG6YZ9RkxGDkbnjF4ZCxr7G9cYL5gom+w3uWeKMTU3zTId MeMx8zarMlvYpbrrwK775rTmdubnzN9aSFpEWbRYwpa7LM9YjluJWIVZNVkDazPrM9YTNmI2kTa3 d2N32+wu3P3BVsE20bbHjmznYVdt991e3/6U/ZiDuEOMQ4cjvaObY5XjipOhU7bTpLOc8wHnXhdO l0CXZlecq6NruevyHqM9uXum3JTd0tyG3cXc49wf7uXcG7L3jge9B8XjhifG08mz2nOdYk0poSx7 mXkVeS14G3if9Z7z0fXJ8Zn11fLN9p320/LL9pvx1/I/4z8boBOQFzAfaBB4LvBrkGlQcdBKsHVw RfBWiFNIXSg+1DP0VhhTWHDY/XDe8LjwgQipiLSIyUiNyNzIhSjzqPJoKNo9upnKjASHj2PEY47E vInVji2M/bHPcd+NOMa4sLjH8ZLxx+OnE4wTLu9H7/fe35EokJiU+OaA3oFLB6GDXgc7DgkdSj00 ddjkcGUSMSk46UmyfHJ28lKKU0pLKk/q4dR3R0yO1KTRpUWljRzVPFp8DH0s8FjfcaXjBcc3033S H2XIZ+RlrGd6Zz46oXAi/8TWSb+TfadUTl04jT0ddno4SyerMpsxOyH73RnLM405/DnpOUu5HrkP 83bkFZ8lno05O5lvkd9cIFxwumD9XMC554X6hXVF3EXHi1bO+5wfvKB7obaYpzijePVi4MXRSyaX GktES/JKsaWxpR/KHMt6LqtdrirnLM8o36gIq5istK28X6VaVVXNXX2qBq6JqZm94nal/6rh1eZa mdpLdax1GdfAtZhrH697Xh+uN6/vuKF2o7ZBpKHoJvlmeiPUGN+40BTQNNns0jxwa9etjhbNlpu3 ZW9XtAq0Ft5huXPqLvFu6t2ttoS25XsR9+bb/dvfdXh0jHU6dz67v/t+X5d514Nu4+7OHr2etgda D1ofajy89UjtUVOvSm/jY+XHN58oP7nZp9LX+FT1aXO/en/LwM6Bu4M6g+1DhkPdz8ye9T63ej4w 7DA8OuI2MjnqMzrzIuTF15exL9fGDo9jxtMnGCbyXnG/Knkt8bpuUmXyzhvDN4/f2r0de+f9bu59 9Pv1qdQPpA9503zTVTOKM62zxrP9H/d8nJqLmFubT/vE+Knos/jnhi+6Xx4vOC9MfY36uvUtc5Fj sWJpx1LHss3yq++h39dW0n9w/Kj8qfazZ9VpdXpt3zpuPX9DYqNl03xzfCt0ayuCEkX5FQqgkAL7 +QHwrQKJ912Q3KEfACLd75zij6CQ4ANG3lgkBjdEooAhiBdyh6pgADvDt1FiqHNoNnQRRhrTgw3D 8eGG8LkET6IsDZrmFe1XOhK9EsMexmSm6+RpFm5WF7az7OOcIlwR3Hd56fn8+e8KcghFCbeKrIqp iEdIVEi+lMbJyMhayfnJxykkKR5RSt5xQJmq4q+6W01SHa3+SuOWZt7OGC0HbVUdLl1Yd15vRL/L 4KZhhVGRcbZJummy2f5dVPMwi0BLXysfax8bn90BtmF2VPsDDmmOJ53OOhe7VLjW7Wl0a3Xv2Nvt 0ev5lDLkNeI95vPW97PfZgA5UDrINNgv5FjolbD+8KVItii1aBdqXExmbOG+K3F34wcTZhPhA7wH tQ55HE5Jqk4eStk8wpumcNTgmNPx0PSjGWWZPSe+nOI5bZuVmd2bQ5/rkFdwdryA+5xr4dmi/gv4 Yt2LcZfqSmbKBC+7lUdVHK48XVVS3VwzeGWhllyneS3wemH90wb8TdVGxyZq8+lbNS0dt5+3Tt35 ene1basd1YHuxN4ndBG7cd0bPfMP+h9WPIrqVeidfpz1RPXJZF/N05h+nQH8wOBg4ZDPM9lnP593 DWePUEbVXnC+2Hj5Zuz++OWJtFe+r/UmuSeX3jx6W/wu9r3NlAzCsq/TL2cezrZ+bJi7Pn/t043P tV8qF65+7fy2sKS2XLTC++POavS69ibH1taviJED7ASRoBkiQobQMWgEloJT4CkktupA4v42jAVm Cnscp4L7gD9PcCMKEOdp5hAGAHoSgzCjGpMtmcqcy9LCOsXOxKHHuY/rKvcMrwifN/8lgX7B78Kc Ipqie8SixY9LFEiWSJVKX5A5I5ssFyJvq7BDkaw4rXQDYYKJCoPKC9UStRB1FQ2g8VAze6eblqjW F+0WnWO67npq+sz6Xwx6ETakGnuZ6JrymK6bje1qMS+wiLN0tdKxFrUh2Szvfm37yK7JvtQhyzHJ KcqZ4mLnarhH2U3EnXUvYe+Gx6LnHOW916T3hM+Y75jfuP9EwOvA10ETwWMhL0Nfho2FTyAn9VTU XPQidT0Wu48pjiteIEFsv2yiygGdg2aHHA57J1GT01IKU+uP9KbNHqM7rpTuknEgs+RE98mPpxmy VLLdz6Tl1OWO5H3JBwVM50QLtYqczlMv5BXfuThdwlJqUpaInH8PKqarsNWiNUZXfK6m1JbVdV+b rSfdUGywvRnYeKApq7nsVmNLz+3R1pk7P9uI97jbZTuUOkXuk7tA13z3SE/7g5qHOY8Se30fWz1R 6xN/KtDPPcAxyDHE+Yz3udCw+IjcqPILjZe6Y8bjVhOur4Jfp0yWIHzYeK8+deBDzwz7bPDH9nmx T5e+KCy8/XZjqeJ764/Pa6obOb/2H41kC/LAFZwB4xAP5AgVQO/hHXA6PIuyQrWg5dG1GGVMB9YZ u4TLwWviZwiXiXE0nrQWJDU6EXo2BhIjjgkio5gxLFhWejYudlEOZU4jLkfuQJ4QXi8+Z35zgZ2C 4kL0SETVK3JRNExMTeyn+E2JMEkRyRGpQ9L80vdkKLKQbJmcqdy8fLaCusIbxQwlVaW3O04payvP qZxV1Vf9pFagbqS+oFGoaaK5uLNYy0Lrh3aZjq3Olm6jXpS+ov6iQYNhjJGK0Ypxk0m8qabpmtmd XQfNdS2ARYdlqpWpNcn6mU3Rbn9bJTvYbgDhSIyjmROP02fnNpfTrt4IS/Bu4+7X9x7z8PBUo5Ap X7wee1/xOe0b4+firxUgEIgJnA16Enw9JDc0Psw9XD9CKpIjChe1HP2W+jSmJbZ0X0ZcZLxDgtp+ jkQocfUgdIhwmCmJM1koRSpV6YhGmu5R42Pmx23S3TOiMo+dKD5541T36ZGsqewvZ1Zy1nM38zbz iQXy51wKU4tqz48Ug4tilyxLokrzypovvyjfqlSo8qk+W/P4KqjdURd47cL1oRu4hp03IxsvN43c IrRo3A5uPXfnwd2le3ztph2Rnfn327re9mAeSDy0fhTfW/l4oo/z6d7+qoG1IdtnncMeo+wvVscl X7W9GZiizjZ9PrO49PPB9v7//ra0LVgVAEpLAHASBsDWEoAyaSTPRJJrUhsANiQA7NUBzFEAoI5T ADKp/fv+oAOSSGYZAk4hWeNzsIrcIoZQMHQGugE9h1ZgTlgH9kHYdA0eRXI3CZQd6gCqEvUMDdCy aDd0OroF/RHDhbHEJGFaMEtYeWwo9gr2E04eF4trwxPxLvgaAkxwI9wm8hBTkJNnD80IrQPtMMmZ NE7nRTdLH0m/ypDKSM9YyCTO1Eg2Ij9nDmBeZ8lmlWS9z+bBtsaez6HKMcwZy8XO1cK9lwfDc5XX mQ/D18DvJ8ApMCCYIWQijBHuFjkuai3GKjYmXizhJSks+UGqUjpIRlrms2y93D55HQWCwrDiZaV9 O+yUVVQ4VDZV3yFR9VWNbM19yDmlqy2iQ9D5ovtMr0W/AeHhTaMm41smt0xvmTXuum5ebVFsecYq 1Zpq473bxlbXTtFe1IHXkd2J1ZnVhdOVf4+4m5K7zl5Ljz2eQZQErxPe/b5kP0f//IAXQWzBdiGZ oZ1h3yPEIh2jjkTXU1/Fiu+LietO4NpPTRw6qHaoLIktOSuV6UjBUZFjjemGGaMnqMgtNZJdnVOc d7uArjD3gvpFr5Kssu7yrSrtmkNX26+h600ajjcWN99sedL6sY3UrtoZ3FXV8+2R0eOLfYsDBkMZ z3tH4Zey47tfhUwmvc1+f/FD98ynj9/n33y+uuD+dWmRuvT6u+ZK5o9nq4xrZusHNqo3h3+dHwxA DtiBOFAMusAcRIZ2Qn5QFtSA5PmbsAhsAcfAxfBDeAnJ2a1Qiaga1BiaBrlXwtEl6GEMDUYPE49p xCxjVbDx2Ds4DJJHF+Hm8Xr4c/gVggvhHlGKWEhDT3OClpn2AkmK1EpnQzdNn8TAx9DO6MtEYmoi uzNDzBUsNizrrNVsruwk9k6O/ZzKnItcN7ipPMo8K7y3+ZL4TQUYBMYEK4SowgYiLCIzonfF8sSj JWwkZaVIUp+k+2TqZLPkqPIuCtqKIkp0Sj93fFR+pTKk+lCtXb1F46bmtZ1XtKq0K3TKdcv1KvTr DG4bPjAaMZ42+WFG3MVtLmehZ2ln5WcdZ5Ox+7xtpV2DfafDkOMHp1UXRleJPQZu7u7xe/OQfGOQ 8tWb38fT96LfZAB/oEdQUfBoKGOYafjBiOuR76JZqEYxSbFP4jjjgxJaExkO+B28e5gtKTL5carY kZS0yWNax6szBDOLTnKeKsziyy7Pkc+9c9Yif+JceBHqfH6x5yX1Utayn+WTlU+q26401NZeq66v bChvzGyOaLFtVbrL1LbQ3td5tetET/hDh17tJxJPmfvXB18/axnOHLV/yTTWNRHxmjx57a3Zu/Gp 0GnMzJmPrHOZ88ufbb+cXxj7Rr+oumS7HPg9eiXhR8LPmNXQNc912w2dTektll/7zwzUgRc4AZrB e4gR0oUioAtQD/QV5oHN4QS4Gh5D0aH0ULGoq6j3aG60IzoL/QTZdzNMJmYYK4iNxHbiOHDRuEG8 Kr6UwErIIrIQi2kUaEZpU0nKpBm6YnpnBmaGQcYcJmeyAPkbcw/LJdZDbN7suzhUOEW5uLjJ3Bs8 H3gH+Nr5GwRqBMuFyoQrRK6KNol1i49KzEluSTPLSMjqyDnIhygcUSxWur1jUgWvqqjmoX5S467m gpaQtpNOpm6H3g8DScO9RnnG/aYkM6td2eYvLIWswq3bdjPautuV2y86GjrlO391tdnT4M6395Qn hpLk9dlHzTfFrz+ALzAyqCuEKzQmbDBCMTI3ap3qG9O5jzMuOr5vv0zi6QM/DvkdfplsnzJ8ZG/a 3LFDx6cy9DMvnYRO+Zx+mC1/pjCXkJdw9kuB/7l3RV7n3xXbXrxXIl966TK5/GjFRhW1+tMV/6vv 6ijX3tR73Zi6GdK40pzSwni79I7q3b57gR34zpqu3d1rDyofOT8mPul6mjSgM7j+rGk4bFTwxdOx 2AnWV9cnjd+MvPN5//mDw3TZzNxHwTmL+cBPQZ99vhgu8C28/Xr5m823n4vnl+SX7i87LI9+d/0+ seK48viH/o+mnyI/s35urAas9q8prxWsbax7rbdv8G0c3JjY1NzM3VzY2rVVtr3/0X5Kvz/AQrT6 SDD5amtrURQAXDYAG1lbW2slW1sbpUiyMQ7AvZDf/1f8umsYACiq30bdBqmH/+M30n8DKzqGkIWg ABAAAAAJcEhZcwAACxMAAAsTAQCanBgAACAASURBVHic7J13XJXVH8ffcBdwr0wFJyIKgis3YmXm znK002yo5SrN9rAymzY0bdkvZ2nacudEc6U4cqUJKiC4EGTKvcK93PH747mLy2Vo4KDzfr3ui8vz fc55zjnPcz/P92wPi8WCQCAQCP49ntc7AQKBQFBTEIIqEAgEVYQQVIFAIKgihKAKBAJBFSEEVSAQ CKoIIagCgUBQRQhBFQgEgipCCKpAIBBUEUJQBQKBoIoQgioQCARVhBBUgUAgqCKEoAoEAkEVIQRV IBAIqgghqAKBQFBFCEEVCASCKkIIqkAgEFQRQlAFAoGgipBf7wTY8PDw8LjeaRAIBDcflhto25Hr IqhliKcQVIFAcMW4k5PrJbIe1/K6LkJa1ncqcVwgEPw3KUuwLO6+X2thvSYeahlCWt4xIaQCgaA8 LC5/3Z5j055rJazV7qE6ianrXy/AH1AidY4524WwCgQCdzgLqfN3M2AA8oAiN+deE1GtVg/VRUyd v/sDvmvXrr2tXbt2z3h6ekYC/haLBZlMBoDJZCrRNiJswiZswlaGLc9sNp84fPjw1/369fsTuIQk rM5YPDw8PKpbVKtNUMsRUy/A7/z58+PlcvkEo9HoYTQasVgs9g+A0WgsVYjCJmzCJmyuNk9PT38P D4/O7du375iWlvZl48aNv0TyUouQvFNb4GoX1WoZh1qOmHoCgevWrbtdoVCMNxgMHmazmWrMn0Ag qOFYLBbMZjPFxcWePj4+49etW3c7EEgZTYnVOUSzOgf2u3Y62TKnat++/Viz2ewphFQgEFQVFosF g8Hg2b59+7GAipK6Y6Na+2WqXFDd9Og7Z8oTUHh6ekYKMRUIBFWNxWLB2iejoKTuONeWq81LrS4P 1cPNxxOQKZVKOdYOKFdRdf5f2IRN2ITtSm1msxmkTm+Z9eMsps6fauFajEO1iakn4GkwGMT6AQKB oLqxianz0KlqrxZXqbhZ3WhXr7SEh8oNtH6AQCCoscgp7aGW8Faro9pf3eJWwju1foSgCgSC6kaO Q3Ns3qn5Wly0unAdLmX7yNy1n9oor7NK2IRN2IStIpsVm3dqE1SbmHpQjVX/6mjPLKvab6vyy6rh mgKBQOCMa6eUu86pKqfKBLWCJflc21EFAoGgOnFtPwU3IlrV7ahVXeV3FVBXD7WUoN5IVQVhEzZh qzE25yq/TX/MOHTJQjVU/6t7CJNNYF0zJhAIBNWJqyMH12D1uuoe2O/uuxBUgUBQ3ZS3JOhNNZe/ rHmzzj39AoFAUJ2405tqn9N/LRZHuWZvB4FAILBSXi252rhWU0+vWYZuNIyXL5KQVABAQONQGgde o3kNpkIyMvIotqjw9lLipfZC43X951QYdRc5ejwXPDwIDGtMA99KDvrQn+XbT9aRVgSRfQcw4tY6 1ZtQK1d6/1K3rObTTRfwaXgLb43qgPpaJNIFXfo5kguMKOS+RIQHoCjrRP05Zk3fSBpQt1NfnutV /xqmstpx10Fe7VyLmVLO30tkzGKxlFo49kpsib/No/cvmS6XVNK3bSgPP9iD3hGBVxxnVdv0qQfo //5BAF6fNI7xgapqT0ti3BomzD5CgkvJ3PfoEGYOanzN8u7Opk/bT/8P9gPwxpvPMraNpnJxGvX8 dSiTjUDXqAJG3Frnhrx/hRfPsDwxF3LzeP1Kr1eUwsQnfmUZJYkOCeHhAd0Y1qcpqkrEmbJlOfes 1EGtDvw9uycBZV3PqGf/oUw2AF3D9Ey4zr+VKra5E9KbulPK3f/X4C1hYMOhJEZM+o64dFP1X85K /qkEVqzcwMzvd3HW+bIKxzurnkZZ7enI/nsNvZ3EtGuTAKKt3xNyDdV+/QqRO5VHrSsoDzl2b69W 1aaofNzcP+Ols8St286871YSd6bQJYAjT1fjrejcHEvIyOCdOb8yOe5CJWOx+qQ+FZwmuxZlaiJp z24W/riaXw9crLarlEFZunNTrzblStVnJrgte2f0xjv7DEu/XsY7iZJw/L73LD0HNKryy7kjPX4T 41foADV9H7uDhtaarDqiJ2d+6QnYlxarVs4fPWv9pmTWp+MYFK4GTJw9cZwsn4bVfv2KUEf2Iu2n O/D0vDn6Jt3dP+OFRJ76fg8AU+68q2qvZ/3btdc9zHkslDO7ttL3f8cAOHD8HMbedSv80bYaMorz j0uiWlxcXMpuNJmQy2QgvxZzbEzEf7+ZVzMgdlALHu54DS4pcV2aFq9/o1pV4CMnQKVEXb8pjz3R hnde/0s6Xgzoz/H5lLWkFClpfW8v2ufsZOCCVAjrxLGp3cj6cycL1x9jR0IuHholCVq4r9stPPvk nUT5OV3j0jl++ekP5mw6Z/X+lEQ3acbX79yDz4E1TFhh8y10TJz0DR0iOvPGiFtQntrDK7P+AaD3 6IcZFGlr0SrkYNxWvl5yhA1a6Uh0LQ33P/UQT8fUBiB1zzY+/188y6z2fl1ieGPUHTTRlF0UF9Jt 6VA4tZ3JCGkSQT0nEUvetIpPNmdQu2Us427VM+X1zWwAQM074+9nVHfpRWTMOcWin3ax4cBFdmml F1V0kya8Oupu7mzicIGS4lbyUVw6wZFdefVeNTMm/8rcTCm+aW8+ygOt/AEoStnNi1//jQce9B07 hP5NvK3XSWPJojjmb8sg0Vq+XcOa8v6UAUS5NAKq1ZC6ZwNPTztIIhDdpAUzXr+HFv5lFMqlU3z8 4SbOo6Dv2CH0a6wCTBz45We+OJyLpmEnPhnVARWgTz/MpKk78e5zD2/eHYre9f7VPcVHMw7ao/5p 9iIOewUx+vUBtHZOZ4AX2syTfPbeUuZkAGj4fPJj3BddOV+wVqAPapWG1n06cf//jrEUQKmSfrD6 c8z8YDVpehVtH+xH64ytDP4+DcI6kfhJTzI3reLDnRmog9vz3tgOdu9Td+oQ705bz+JMgABeuCuw VPMCAPqL/DrjF17aK+1zd1+3WHo3zGXTwVx0BPH8a/fQwtt6auZJ5s5ez0eHrc+dpj7/e/0++kdo AANxs3/k1QzJFL95Pc8dV3LL3YMZERNYqXK42agZgopj+lXG6Vz7MW8/FaDjSEIu64Gl0390BMgy YqSQjZ/vZDZAsJqul6WHYtn2fSw7LSNlWk+8AGP6fu55frNLm6SBhFNJZJvAlH62hC3hVC4Jl/N4 BfA0almWKrXztimytQXkM/+1r3gntWQeEgq0LD1ZwNMxtTny2zz629qHNUrQGli/ew/rj+bz17zB hJRRDk2i/WFPJqDjqZdnMP6xexk3oEWp2l9x/gXWn8qDU2tZ9LuzRcc7X/6Aznssz8cEos9IYPL2 c4CSvmFqNqTqSDh1iidf/44fvhzPnSGSSBvzL7AxNQ9S17JoY8n4Xnx/Ba2+f5LWCjAZtSxPlap+ txTayuMi7z29SLoPQHSIGjJ07EpNJttNq82yH38pIQQJp47R9+tgTk3q4v6BVivJTc1lGaCLT6df 4zAwZfLTz6fYCJB4mKee6EBrFZzadYBFGVqGKaTWSqPL/dOdTWF2hqPpJCE1kwR0PO6azsQddHzW +YCW56cso8X3T9jFqDwKDCagkD0rtktiCtza0nbX9RxNzGMjsPST7x2BsowYgcL8C6xPyIMcLZNt Ic7sIerVLU5XyGX6ulxKc5HPR3/HpwW2/5Us2x7vVN4GxpgccTZ7cYv9vGgMJGjPM3rSV3w57QUG NzKRecSpmq/NY1kiXAjPFoJaXfyb6WZ2c1Yufx07xrkd+3h+o6PKe0/7ECClRE9rdEwnpg5oRH6u Ci+86fPKQPpENKdxLQ88PDzYO/srHtikg9RETup60lqt5eeZDjEd+eiDvDqgCRpPI2fTspGroPb9 o1hp+I5BK3IBNctnjyfGT0axuZjLbrJwdssah5iGtSP+3T7UVxq5nJtLgVcwXDzIi1Yxje3Vj5+e aoNH+n76Pr+ZBG0ivx+7zIho97/Kpj3u4o113/Oh1Sv4cuFyvlwYx4cv3MewmHpOZzq5U2GtWDsx luJDGxm0IA2AT3/9m1Ex3VGF3MJv78fSOUL6ARQd20DklEOAgZQLhXQPllvvh7N71pAlH/WAPesZ siITyCQ+RUvrNgEl7yHSqmP6MyftYsrtA9nwrNTqm51+EZkKt8R2u52PB9Rm4bvLmV0AHD7DBWMM DdzVYmV16Ruj5Mc9BjbEJ5D/SBia5OMssp+Qyd7ky7SKNhG/7SKg5K5O9QAzro+gukU/jrxRTOsP /wbgjVfHMKa9ptR5Eg1YMrUXxK9lyMqLQAbxKVqiW5Ttpdqi2bViKY1XOI5/OOkphrUJkn4TFkuJ Zzqqc0c+HhhKfq4KlcWC872VAxaLnk0LHWL65iujGBdTh9Q9a+j6ySHrdaUrn92yxS6mffr34+sn bkF16TQzJi1huvX9rgAslgIWfWKLszHbFw+jmSqHz56YxXQtfLPyOIOeacWjX4xG9vr/ePUU9Bl0 L98OjQST+992Na48dc24ORqyKkKbzENvLS8hpu+8OIxbXV+Ct9zGqhd60C4igu6dQ1Eho1lMa8LI Zu/OvazdtIt1u126BXQZbE21fte05tmB4VJPq8ybhuENCbL+gL0VtodYgY9KVs4SMAb2bT5lT+cP L/ahgRQhfsH1aOgrQ5eV4eTxFnHwQCL7k/Psx3YdSi+7LFR1GfPFM8zt38C5gHhj+g8891sixlIB Itg+tT+t6gXS7q5BfBRmPXwqiRQdyAMb0DlCSdLfR1m7bhebTxbZO7ncv45D+H3+E3RtUpeOXZqW nU7nJAfVoavtnx2reO7rtWxNuIhfvTr4uSvHtrcz75muNG4UwSP9bSKdTaa+rCvIaH1buPQ14zjH L8OpfcdKnLHh0EW4lMpPmUBIFG2Cy25f9KrleJkpvZW4v9nBrJw9jFub1KVDJcuhPLbG/UXiJTfu ers7XJ5pN+jPsuGQLVkdeSJGGnLW4JYo7nU59Vyq7dlSM+reW6T4fEO5p5fLMLXLmezKcPx74fgx 9uxPId9aFUo4fp58AJQluunkXKOm2+vEdfFQq/xNpKnD1AejURYb8Q1uQIe24QQ5PVm2UH0iG7o8 cIVs+HY2w+PcVX2sXrBT73KfXlEEWeOrtPdcymakwN4xrMBP42yTAp05ds5+LH7TVgZvKhnHGUPJ H1bptGjo/cQwTtyTxk+zl/H2QamKuvzXddzbI4ruzi+asABqO/3rePgNGCwWMg5spPMnh6g0YU2J rGUBo7Rnums63ZabTzjvDY+g5/yTUjq3H2H59iMQ0ow1kwfRNlheYgmLPhENUWM75PDGXMdbOl8r KKo5sSQSj4H4fUfxP5ALtRrw4W0W3lh3nvhDSeytk0si0Ld7CwItFjcvH3d5MJWw2RMa1pRIX+mr azm4i9OVPoMfZPYjoZw9HM/LH+1i495DbNxbxL6fB5Vo7ulb6pkuEbP9m91NCPTC02L1R42uAq3l +D5rgz0KfJzUoVTXltMIAUjjoSlpJe1Ofkl5DuS1XkilurnuVf4qoXZTHrz7Nqm902ikzAW5XIRI l7DDLqYjH+zLU32akfrzAoZskp6GYgCj49nYmHoRPeH828FPzuGL3fzWGrVoAEhtT30GD2JqnzoY jVKmjCYjCk1ZvS8lUQWGMnLS80T972seitMCBlLOauke6NyrVfIRcLQO+uHrkcKbVjGNjmrN1Kdu JUJ1nufHr7J2YLmhsHzxcI+MqLsfJDn2LFvi9jL310TiATKSuHtJAueea1vydHeFVhG+DRkYAvEZ MH3WWulYl1u4p89l3lh3HlL38YC13WFAh8qPhlCV5W5dVTm4IiOsQ3cm3vEXu7YZgBT+TjfR2/mF aKjE0EDnU4pKpqtkfUxJSBMlWNuIHSJq4kxSfqk47WE1UWyb3hPvIgNGk1EaFyrzxo+SSzkVGKqi TG5sakaV/7KRqxlx6vAEAxhw1y008FWSn+V4xBRyQO1PK5v+HNrK/L1Ojex6A7ZaptH++BVzqcyq J4A3He60Vcd1TFu4x+mhNqDTm1D5OwRzY3wKeV6BNKhfR/oEepf7FsxPP01SpvPYSBPFzsNPFS4C kJrEPxel0tOdPMgPqdbj0aE0lCnt3mvXOzvRrpEfRVmZnLYHrqK6m6mQjEwtXoEN6X3/QH6efbej WcFedfy3aOjQLbjEkfFdmuBXL5SRJY42pXN45V+ZR5NyqiR1rhQYDBgxkX3+BDsS/+X4YZUP9sGD qUdYdywf9DmsnLOWEv2HKAmPtlXt83ht5h8kpZ9jxddzeWqvIw3FAD5BdLS5ytozHLmA9HzWq0OD en44T8qzhYzff6qK7uWNS83wUMvD5H6wNDh7grkMHvE1sRod8bYaD3k8P2k5335wL08+15bpH0ie 2ofT5rEsrD4dvQtZlJDL65PHMbZFLQL8fYFcQMdDoz6zD/mp5+a6zXr1ZOj8H1gMxG/fSvSBwwxt Kif18EW4+wGWPNaZ3/rv44G1Osg4Qo8RR+gaHUytnDw2ZBiI7n8fG56IcJunM1tX0X+FDkICGNrY l+yENDbYe2yjuLtUZ1YmD46fxr1tg0k8lGlvp506pC1eZGOT5rmz5nFsmZJ4px7ud6YspO7Ux+1D n64W3YkdtJ9yCEICGBkZCBcv2NNxb68o/KBETaEsSo+4LEmTDs3hV9vMOg13tvEDvOgao2TuHilf UT2b06DMGCTUDcLpw142Aj8uWMSB3wIYO2kY90f8y+HxTs9q/NqVNF3rYteE06aeDC5XXBYlkNXl 4UeDmfujNPrj2be/xnkAQrTT92bdY+k7/zc2AAmH9tFj4j6XyPyQZgv78dj4WD58M94e59chAUQF WEhMzCOB1hz5uT++yNDYHo/MQ7QeeYxnHniIV++qqJRvTmqGh1rejBCVklDbdxfHQx0Zw1ddbO6n jnhtMF9M6M6j1iMJqWe4ZAS/1n04+H4vHrWemph6nkUJuYCSIGuVr0Gve/i2m62DxMCu1AtIo4Js 7ywlIbaZUqqGfDTvUT6KsZ6vzWXx4YvsAsIDpBaxzk+MZePY1sRaQ+9KyGSDVcx6NCg7w3K1tWUr I5fFex1iGtu5I3/MH+RmuFUAIzv7s9wupkreeWE4j7XQgKox48e2sp8Zn2HgmaE9mX6HrczyuFDk Ujdw0la50/taaa8aO8qjrrU85Bp/qVMqI5e5O5KZmyjJxcjBd/PBQOvd81I6vCy3k9ODCCy7MREA VWg4z9j+CWtDK18AGW1iwu3nPNIlzCWUm/unDufN8a0cM9C0ueRccTm4S6BTHkugZGjP29jxpfX+ qVSO88pzpp3SEDXwEeb2KjnK4p2xfXkxBOm+28pUHcl33z3AM2GOiF8c+yC/DrJ6rmHB1LWWszqi Gwmf3c1I67kJGbksT5Q6T2Njgqy5VjJg/L08bXvXaA0cyCu3CndT41FVDbhOW0jbVuW37XAqR7rt CkAFtMzIyFhpMpkwGAwlZsyYzWYUCscMj2tlK7qUT16hBd/ataQGfr2W9Dwjtfz88VPLSoTTXcrn ssGCt7cPal9vLC5xFmoL0Js88FJrUHqaK0yL8bKW/CITnp6eaPz98ZK5ptNAbtZlPBQq5ColSqUH ygri1F/WotUWcqmwGLnci1pBgfgqS6bl2K/z6PfbRQjryvGPbsVTexmt0YSXnx/eHi5xFl8mW2fC S+2Ht8KMQuFJdmY+xTI5Af5qu1z86/ugL0SrvYzZLEfjp0Elu37PRKVsFj3Z+Qbkcm9qaeQ3bjqd n8+8AvQeZlD5lXompHAWko6lowkNoY63FIcxJ5ExY1dKzQNhnfnnozuo5RLOUHiZIiNYLB741FKj krmmxURWRh5mz+q/tz4+PgQHBw8C/gH0SJUXA2C0fsxILctmwGKpwl6sG66X/3rg5etHkHexw11X aQipY0bh2t4IqH398Ha+oS52lY8ajf1mVzzVVO6jIcjH+pC4dV6U+AWW/LFWhMpHg8pHQ0CJB6+s tBgpAgJ8Nfbe4lIzZFUa+6gJySYjKDhQepgrTE3l8VJ5I/OU3zTTUpF5ExQouYHXYlpxVaDyrej5 NLDt0x95uwCiQwKI8jawPNXRwDB+cHu3K2ipff1QYxM4d1eW4Rfoe/Pc26uk5rehCsrAKsxV0hst qEkEttTAbi0JGblO46HVTHpmMKNuC8RSiZf6fxUhqP9RogaPIPleqXVGxs3hXQmuBRrufWkC/bSX KCjQU2QyAN4EhtRyeLbXN4E3NEJQ/6vIZHhdQdOE4L+FXOVNkLejcn+zNGlcb667oN4gW84Km7AJ Ww20XWuuu6De0JgMZGfkk1tUhEIhR65SolFr8FFeWcO6/sx+3pmbABboPvJh7g4ve9xm6pbf+XRT Oj4N2/Dm0+VsoWHSknjiIsUWCwENwwgLrNxg9CtJS8VxHWDKPKmV7fYn7ueuMK+rjksgqAlct17+ st4qN8bbTcuuVZt5b8nxUtuIAND8Vo6/361MsXON01iUz+LE81LQQmO5eS+8eIYVx3MhN5/Xykun Pp13piwnHoi++37inoysXFq02ZVOS1nYbM75irSOw7wx7p+wCdv1ocZ7qMZL59iyO5XTZ3Np0Lsn vUMr2BdCf45PnvmRr7WOQ7GN61DX47Jj+Mg5nduFM6qGkkuvlYlMRV3r1wBl5W+jqnYIUUAiEHQN tmQRCP5L1HhBNWWcYPh8aQX/ybf3qfD8vT+tcBLTYBZNG8pt9RV4eHgww2Qg43QK+5NkXH3lVhps ajSZ8JDLK3UDjCYTcrnLmapQZvz0Cp9aLHi52spB7ivtMZWIP01DqlJQrYNoTSaMshq8PptAUA7X VVD/3U6HZpJ37uTHuER2JubZty8ZfFtrJozoSVMf4NJJPv7qb3u4n+cu5m/vIMa8PpAolZs4C5OY vc42iFnJoq+fpHuwNFNKWkFHSUiTKPo1Nlv9SBNJO7ezZNNxdibmgUZJohbu69aWCSN60lhZMg8A qoIz/PLBBl44JKn2vT2789bTnQlwraYEysk6tZ+Jr2+2LmChYcrEB3m8c5AUp/4cMz/aSIqlmJZ3 3cvYW+tay+UScUvW89nKNAIaq4lPK+bZ4QN4tncTvD08AJN1HrhjixSLRUv86i18sSrRvpZBtCaA iVOeoE89ebn3wYbSeJG42Zt5+g9p8ZjB/frwyZNtS+zSmfH3bmYt3MmcVOt6ABp/3nmsN4/c3hjb ZNYk29Yst8TwbEc9k9/aShyAJoAZzz/Cvc0uMX/6Ct6xbrnx7PCHea1/uNPzkm/Pf2CYhl2pBsY9 3p+J/SMrtWOosNUc2/XgJvZQC4n7cjdzocT2JSv+3M+KswpOTO2G8dwp5mU6FvNITLtIIpd5ooyl qXRpp+yr70Td1p3u5SwybEvDpq/22NMQa99CZS/LTstJ/LArrl0+r322tMT/yzdvZXmWjMRX25Wc op64m26vOx/QMnnGfPKeH8nEmCDAwNHEi2wEMltcZuytALl8O2EuH1nX/4jKltLz1fylHC+4nzkP NAVVXYYPakozSyRNVAAmtn0zlyf/tImcmlh0xGtzOZlnok+9yj0ib3zwU4n/V6zfSIOIBrxyqzQH PHH1Yu5act5qVRKrMRCvzeOdWb/yzq5bOf6m1CZdnJ9h3UplA4tXOmc/l4nvzWKiy3W/mv8zrVu9 SJ96HkAO306YY89/dJb0dvjmhxUkFT7I7PubVCovAsHVchPPA/Om9wv9+eObiZyaMZZf5r/Ost5W Pyc1kZOXQR3dh79ebmkP8drLo0j7aQztympGdao6R9WtzJqj3vR6/i7++GYiaV88w09zXuGXHtau qtQETl52F0bD9NeH8+eUHo7V0g/vYIe7La/DWrHm86dY/rh9eRc+X3bUvtKQ6xbA57bF2cXkw0nj WPfdS6y+W1oQI+63eJJNUpq7Drmflx9pafXYDFy8aHvp1GH7nGdY/N1LJM8dzWNNr2wEwPOj7+fP t7raFw05cNrq7l48zPM2MQ2JZuv8Cfw0ZzxzelrL+PBOZu+xLYNXcmuW1dOGMjXauWnCn1mTH+fX B+vbj1ywbh7onP8PXh9L3PzX7fnf+OtOa/4FgurjJhZUGU07t6IxOezbtY81cTtZG68tdZaXxtHa qfIqa7sKNyhcPTMDR7ft4tdV21m57ZS1U0pG004taUyOfQuV9XvLX1ht0uvDeah9XRpEtGf8gzbR NnA2r8jlzKb2rUna9hvI1DDr4bQUTrkV6kL+2upYqbQg5yz7DiaRpbQJ1OWy12m1X/oio177md+2 JaFVBxKkrnxb6Mixw5lwRxPCWobZBdW+22ZWtnUnU3h2SDcaqwC8ufMex8LRu5LzXGJszPYP+tOq Xn3uvN0mnkpmffok/aPr0rlrNFEumfhri2PV+IKcs+w9cKJy+RcIqojrVuV3bVu8cgqJm72Qpza7 /hDLowIXxanrPiO3wMVo4vDSP3kjE9DcQu9ekfhRyKY5C3j6j8qnQenlECn/Jg2BMsKWuTVJcZlT /3ROmvzRrFUu1jyOnSukXYSr1+nNXeN6EPfqH2wEElPTePl/abz8v7VMfelxHm5fud0Bmta31g5K basBZ445hK5hHcf15YF1uRdYjkN87YTVobYMMEPtxvWBVMCP0GBrSQTWsY9WsKF1yv/U/612ibCs /AsEVcdN24aqS9hhF9MRD/Rh9F3NSf1pPg/HSV6qO9Epdy1KQF07yP4jjV+/m4OPtKKd82BTW1OB j9Q7rzu23S6mIx/sy8jeTTn10/c8+ofkpbobWqVyKvG8s067nJU6uaytSXzxVbmPXO009OCzycPp HmjBZI2n2OhJcAP3YqJu1J7ZP0ZxdPcBlq0+wNxUA2Dgtc9W0XH+41RGgwxuhNRGPactXbK0Bkfe dLnux/kCOHnhRntmi53eiaWv51QZ4dO3nqRPXTlFRig2GvH0VFG7nhBTQfVy01b5HduX+DOgXxsa +CrJu+io8rtbCu+f5Aq2sANMZQAAIABJREFUq6jTipc62/65yIBnf+OgfTsRWam1fM/8Y9tl1d+x hUq2o8rvTr+T0qxpMGURt8m2nYqalg1cpgmkJpfYmuT7VOvx5o1o6Pa94E3b2xztijsPZaOpU9u+ dYq/ClzXQLYmhOz0LHQyDa1u7cbbU8fzaWObrZiCKmh3VDvtgfXZuqP2bTCSDyTaPcw6dSoYH1wh XiXzfzgbTbB125h6tcvJv0BQdVx3D/VqZzw0jLZ5PXnc+9Qsump07HLavuTFt1fy9ZSBhDcIoy/7 2QAs/mExB5b5M/aNYQxys22HxeJJr9EPM3Lvz1LPvfYkA56ZQWzz+jTxusyBVMe5RqBRy4ZAJpDn ZguVXF5+ZzVfTxlIXadszPnuB3buaEDDM+ewOtNE9exBJ9ctr7nIg+OnMfiWOiQevmgXng8eaoPS YsFitJTaBqNx956Mm7uQb4DlK1exfKWa+6LVXDiTyS4tvP7GOEa3dp3fVcjqyQuYolUy+JZG1Fdd 4g97Db0u9XwqNxTFfkqJrUqkGXGyhu35sccuHv3DAIe20/b1VF4IucT0vdbmDk1Lnu9dt1ScxRZL qVESBot1R1k3aQrt3pNxc6T8r1i1mhWrtnBftA/pZzKJLzP/N9ZMHmGrWtu15qb1UNWRMczsbPtx 6NilDeariXcy1HokMe0sl0yATxPemtja3lGSqM0jp6iclXN8QnlryTh+fKCpPUz88fMsPpxnF7XY MA1yQN28CzOc0hCvrcOMZ+9gmGsa7O8tfybdHUFCgkNM+/Tsyc9PlexeAYhq3pQXOqtZYRdTJVNe eoqh0dbrqdxsCSIL4ZUFw5nZ07bRmo5lCZnWF40/of7u9g5REtJCDRhYcTiZb/ZK1+sa3ZpNcwe4 2TLFGeftTKxxe/kQYRtUar+cjK5PjWH1sAipTNNO28V0cM9b2T3rrtLX8XY36UHhdvcT+86jsrou +deyLCHT+pIrK/8CQdVxXbZASU9PX2mxWNDr9aUG5TqvTF8Zm/7SJQqKPQkI8UcFFGvzyCww46VW 4+cjc4QzFXIh6zIKhTd+vsrKXc/TQkZGDrlFRrwVcuQqb/z91Cg9S4YzFBSgNcrQBKpRWiwozHoy 8k3IVCr81fJSeTDqtWTl6fFQeBNUQVp0ly5RWGyhVu0g1LLKl4tRX0ie1oDCW4WXyhulp7n8cOZi 8nXFGI1Sumv7qa/oPlTaZirkQpYehYcZ1Gr8VLJ/H6cbW3FRIZcNZpDLkHnK0XiVvg/Vkj9hu+42 Hx8fQkJC/ltboJSVhyt17VW+vigtFuQWi7QHuEpNiJdH6XCeXgQFlpz1U+H1PBUE1wsh0Gh0uWkl w6l8fR2zcACLUk1wHTAaS/ccWSwWZEo1QYGqSqVF7euLj8WC3NPirpZbZji5ypsgpZd9yqrRWNor LxFOpizxoqm2qtnV3IersMlVXgSqbXl3fx+q8nrCdnPYqpvrWuV3zbjrlDJhEzZhE7artV0Pbto2 VIFAILjREIIqEAgEVYQQVIFAIKgiqlNQPcr5CAQCQY2jSgTVachUeYIpxFQgENRoqmPYlKuwuoqt Z3m9dM4Im7AJm7D9G9u1prqq/M6D/G3fZUA9hJcqEAhqKFUlqOW1l3oirc4WFhMTE5qcnDzc01P0 hQkEgprHv6rye5Sc7uLskdr+ypG8Uv+lS5fGdOjQ4SVPT89AALO5nPn0AoFAcBNy1a6ik5i680g9 kLzSxj169AhNS0t7sVOnTh8qFIpAs9lsnwp4I82qEDZhE7aaZbseXLGH6iKktr/OYioHQgDfuLi4 2yMiIt6UyWSBFosFg8GA2WymvCr/jdSgLWzCJmw1y1bdXJGHWo6YeuJoKw3t379/2NmzZ99t2bLl dE9Pz0Cj0eh2gQqBQCCoSVTaQ3VTxbd9d/ZKNTt37ryzUaNG78hksgCTyURxcXG5HqlAIBDUFCql dBWIqQZoNHjw4ManT5/+LCwsbKbZbA4oLi4WHU8CgeA/xZW0obr26MuAOoDm8OHDfWrXrj3FbDb7 V6adVCAQCGoiFaqem6FRth78hhMmTIi4cOHC1wEBATOLi4v9RTupQCD4L1NZD7VUVf/06dMDlUrl 20aj0d91GwJXbqRePmETNmH779iuNeV6qB6lVdI+RMpsNnvAjZUZgUAguJ5cbUOnR1hY2Nr3339/ qEKh2GLbt0ggEAj+y1RGUN3NgtIBGV999VVKo0aNXsvOzn5NpVLl2TqibtSZE2XazFqS//6bk+na a3A9I+kn/+bvk+kYryjc1dv0+dlkZGWRn6+zX7PMcMYMNv22jnP60jZj9lF+W3kQ/b9OZzH52dnk u7lGueGKi8jPziY7W+c2nFGXTUZGNsYrSourrZija1ew95z+xnk+he2qbNeDq/FQbeJqAjKLi4uz 27dv/+eoUaPGKhSKPxQKRbntqTckxssc3b6dfem6aohbT07mBbIKDNYDZi7u3cK29VmYqv5qJdEl 8+1zoUS0bkfXmBjatWtNZPhojpaXTX06o199lkw3/Yv69F28+sI+itxd6uh3NGv2HfkVJiqD78dE 0a5TJ9pFh7PqeOnE5O/7ktELjmNM+40xXx2yXvwow6Ja0q5TJzp1ak340O84b0+jkUNL3iSydSdi YzsR2f9TkvWloq0kev4cM4H4THe5FAjK598Iqi28DjizZs2aMw0aNJh25MiRd5VKZZ5MJquyRFY7 nqBRKFB7eVV51Lr0/Sz66Rd+PHgOvdkMKOkwbALjn+9k33oazOjyc8nKyuJSUVWNlMjgq1v68mHi M6w9eJKkpCQSjuxj1c9jqaMqJ5hcThe6oHDXiqNQAkrclZK6ySDWrLkbdQWp0iVu4r1N8HNCCute i+Lb+FOlzjmxNZ47ejclY98uIjo0kQ7KmjB9135SUlJI2fczXXZPZVuyJMbGtOU88FYWy/alkJJy kE+iZtH3s+0VpKRslNGgUlT9syCo+ZQpqG46pKD0WFQbZiAdyOrfv//BBx54YJJMJouTy0vvvw6S W16Wa35dbba/xgKO7drA9OnTmT59Or9vP0K+zcE0FnB8r8P2xYbjGDCStmc1M2fO5IsvvmD6r3Ek ZxcCepJ3/IVKpUJxdB3/++pvCi16/vr+c2YuiJeqzoYsdi39krnfL2ThwoXM+eYLth/Pki6Vc5yl M5dyJCWFP3+Vrrfh0BlcJddd/nTHNzMD+OH7V2gZqARApQ6iVae2hMjBeH47z/UJJTQ0lGbNhrF4 X0aJ8EnbFtEnNJRmzZrx6aqjjmtGFbDplynWcGNYdTQbAH3WbqYv3E+RNS2Zfy2hf3g44eHhTPrt kD2dPmHRdAH+2bGK6VMTGdyynt2WtHERs7+fzeezdvPXsnl8M28FB9fM4ZedqVhkPgQH+0lp8FKQ B6i95VgsFi4c3w90oEkQgB8DRr8P8xeTUGRBm7CQZo8uRpJeHdu+e4FmzZoRGhrKogRHE48zSgsU nY9n9phmhIeHM/rLbdj86AsHfuFha7mED32ffRmSK6xPXsVTzy1i64qPJVv/9zmUdpQvh4bTrFkz npqxlSLrPcrYt9heNm8uPXTj/h5uUtv1pKpH3+cDqXv27Dlbt27dRVu3bp2mVCrzbq5OKz1H1s1j 2+EU7hk+nvEjB1H0z58sWH2IQqtt81/J3D7occaPH8XDbRvgiRlNSFvGvfgqLz/7KBGZJ1h15Dxm VHQY0AeAJnc8yqTJd+IF+NVV4RXkjwdm0nZv4O+LKvo9+TyTJ7/IoA5eHNn0MycLjFgsxWR5ZbFt 7Vq8293L7ZFeJO86RJah/BwAnD2yDXiLtiHu7SZ5CENn7iUtLY3f3oI3J2+2i4aG3UyYm8W0vQfY MO9VZk0cSFyaHlBC4gx+ON+RXX/vZd6rWiYOnE6aEYwFuWz+KVeKICOOro+8xQs7Ekg5sorCV+5j 6Wk9oGfvb7+wG3h31ERif45nVKcgzicnk62H2i1uo2sT2B31GiNuD2RJ4gheGj6Y9o1rA3B6+/dM mvQC4a3vg7dXMTBUcrU1tesCl7DJY9aZc4CWQiOo6nRk3rMxUm0gI57hU1cwb1ciaSf+pl8j9666 MhSmP/U4yif+IH7dDOI+/5iTOiBzO50Hv0T3JdtJTDrMz33O8HDsp5wDjEYdG5e/wYe7m7Nr/wae 95/HfXcOpNazW9i18mM2Tv+QYzogczOxD7/pKJtXH+DXtKtunxDcYJQpqBb38l/eK8FmMwFngQtD hw491q9fv4+BjUql8uaYPWXIJeOsEllUf5oFqVD6h9ElSobqYhb5OskmD7+bjlH1UCg0NGwYgBwl tRv4k3pwJ1t3/k2RhwfyfD3FQJFRain19PSgIFcSHLP97WqkuCgfD4+WBNWC/HwT9RtGoVAouFxk tnv3dwx5ji7RkbRp2Qy5XFO5t6ABiCo50NiYfZTfFkgdTqrg5jT3Ps/KH+fz51nAH7sXqiWKFXOf o1VIEE27DWIscKagyBrpq8x9rj8N/ELodt8o4BS5ekDhuE7a/ngAtiz+gk+/WcIKID2niOSVr/Lg G3XZsP03BgMn04uA44zq25c9WTqMXv54FV8i6s5WBMi10DuK+rXr0riB1JAQ0rI3jw95nK/fHkHi u6+wylrl92sxmIldZnF7+FAmTRrN7aNmIc2IBnlQFN1im0rl4N+EIcCIEa/y6+50NGr3L3rDaRj5 w16eiA0lJCycLvgDcP7IRuB1hnRtjBw1nYaMpwvz2J+mt5bNCyz+aBDBfk25s3sUUa+t4smujQlu 1opYAgA4fWB3ibJZCZzPEe21NYWrUTiL08ds/bj+bwbygOR//vnnfGho6O/Lli37WiaT5SkUijKi vVHwxNPTE4vZA5PJhNlsxmy24OHh6bBZzBgMBiwWC8XFxZgLTjLjm3lsOOdB01YtaRYKnp5KPAGL tefJ4um+o87D0wMoxmSSTiwutsqa06tLLjdiMBgovFwJ19RK3TaxkPgrh7Mdx/Tpf/HKu19y0QjH l75Im27fQEQsd3ZpB3kGJ/H1d2pDdWlgiNI4zjOBdJtdKQQG0WfgQO66awirVq3joQg1hTkXiHq9 J03rt2XSsrdZMvFOFqyKBx4hSn6Cue+9RN/Rs4jS/8HLA98FdvHxu/NJsrrOqqD6NG/VlruefJm3 oxL57o9Uq6Exzy5KZEfcZEaM+4Qdi8YCEdR3bdBVNeWDhHjmDW/CnMf7EvnJtlLNJyBJY3CQptRx o64QUJWaDWOwRRLla29fVij9nUO6lM1ge9msXLmGRyIrankW3Cz8W0EFh4CanP7axLUYSAPSJ0yY cLJHjx5fGY3GuBtaVJW1aFAHSDpKUqaWoryznEwCCKGW2mo7vZF9J9O5XKQlKzMfQ9FlvLy8uLVN C3zRcjbNAugxAHKl9BPLz8ggv7DY9WIEh0YAJzmacIGiy1kcP5YAhFLbz9EpYhfZKxg94Rd1J8NJ ZMgzM0nMlqqUUiz+gI4D81fCyGEM6tyM4syTTnapyr95ezJGIP94PLOA5nXUSFX+NWxPlvryj+9e CdxJPTXSnbbSuEMPYCWnLvnTqlUrWkU1RC0Hb00tEj+aw1+ZeoLaPsn8EfDuxHfxf+8xwkPa8cqM qYyNeoTn3nyN+7r05ufp05k27Vmi1IA+n0zbOKv8k5xMBH+NTdqM6HTQoGlzmvpnsXjYLAZNH0wI YNRlcDw5AyNgzD9HcpaGbvc/y8wP+8DXKZQ94KG01Nbv2Bt4h02JUv6T/1jCbgbTrrFKOj3Rca7r nbYR2v5OYIW9bFo2b4jmZmoRE5RLZW6lxeW7Bw5BNSGJstnlY6TkOqk5gO7kyZP6pk2bbklPT+9t j/Aqp5RVtU0FFMvAYvGi85AnKF67gPWL5wCgaNqNxwfH4q3Pt9u2rv2FvWYzlqBujHuoER3rwJ9L Z7M9sAU9WgVz+uhWEi+E0ql+Xfq2qMPaIxv5/kAnnnmxvf2CFouF2q3vZHChJ79sX8qxbRZUqlb0 f6w39ZVGjFoprY7xEkrAbG2QryB/slBe3bOSgLcG0bf9dKczhuAl8+GOVybCiMdpPBcGDR9OVOK7 vLK4C9/eJ5119JdxNH1KUoix3/1Bt2AZulyAPH4Z1wbJ1IXv/niPYIsFndwCza2XCOnN9oVv0e3h WN61Hnpr5WGeenAqXyQM5ZGuLa1Hu9C7Sx5xby3k6KCPaVV0gIPNb2NicSJxee352Mdif/r0p36n a983HNkY9D67HrReUJ/I6FvuZrfV1PvVRcwY2NQa7mfuvtvEgeTxeF2Mp3efV+xRvLPkffwo/Uwo A3Aaa+soV3n9fvwx6wV69G3DBGv6v177DeEyC1o5EOWIQw74K908b8E92b7o7RJl886aYwxvJS95 /9wgbFduu9Z4lJeYMrY58XT6yJCeHdtfhdNH6fRROP1tlZ6e/onBYMB1DQCLxYLNe73WNo1GQ2Fh IXq99FOqVauW9U3hiYeHhUuXLtnDOdvwhIL8fPz9fSkuNiF1wJkxGkFXqAOzmVq1aoHZjMVDRlHR ZTQaDSaTiYKCAgB8fHyQe4LFQ4ZcqSQ/N9e+Ypefnx95eXnIZDKUSiVKpZK8vDy3eSgrf7r8bAoK i1F418JPrbLbPMwG9KhRehZjunwZk0qNSi7F4+3tjV6XT6HFB42XI87iYgve3h7o8nVYfHzwKq+s TQZ0eiNylRqlzGHTZl1AZ/JA4xeESg6W4mIU3t4V3qNCbR6XdHqQexHkp3Zj04GXP0FqlcOWv40+ bY6yJHk00hgBI1ptEd4af3ter/h5MerJ0xbipXE0f1zxM2jUo9MbkSl90Hhfn2e+ptrUajX16tUb BPyD9G4sRmrJMVo/zjVqSxn9RVdFuR6qxWKxuAyfsrj52Mane+LwWD2tCXfeRtp5QoAt/lKFcb1s OTk5JTrN8vPzUSql4UYGg6FCW16eJLhms9luMxuNeHp62oXTZtNqtSXivHz5siNcYSFGaziz2Uyu VVxlMhkGgwGtVlsiLZXJn9ovCIW3oVQ4hUqNHDAYLMjVavvDYBtDrFL74WEw4DxCTiazAArUfn4Y DIYSzRCl0iJXoZarrHl32JS+gXg5p8VpzHJ590im9CHIS3NFNn2ugudX3GcVUwA5Pj4+KOUVX69M m1yFj49HifayK34GrWXjvGbwjfR7qAm260FlW29sqXSu7juvHm0TSlfxdJ4AYPNuy2peEgiqHFVY V3rWr3xnnkDwb6hQUF28VOeOKFvbqbPn6U5QndcAsHmuAoFAUOO4kv5FW4eU7btNVCuaku7a7ioE VSAQ1EgqJahOXqpr1b8iT9W5LdXWiSUEVSAQ1Egq7aFWIKquuFb3TdaPETBVNEe3nDQIm7AJm7Dd sMOormhIsRtRtWETVVcv1Z2HWu2r1gkEAsH14IrnaNjGbLlZRcrmrdpE1TbWy3XgvxBUgUBQI7nq 1UqcBsO6jku1ze23DZy1iajJ6ZhAIBDUOP7V8k8WK7Z/cYip81/X70JQBQJBjaSqlmWwuHx39Vhd V6RynHwDNVgLm7AJW82yXWuqa4FSV/F0FVnpoEtBuE4pEzZhEzZhu1rb9aA6BNVVOM0ux0SVXyAQ 1EiqRFCt7ailPFDX08qxCQQCwU1Pde5J4iqyFQmuQCAQ3NTcBJs8CQQCwc2BEFSBQCCoIoSgCgQC QRVxXbYHs1jE4ijCJmzCdu1t1Y3Yb7GK0WefYvOmtSRmgblFL8b1jHbesv7aY9SRkV2EyteXWsoS BvKzL2HEC19fZVmh3ceXY0ITFMQVhHKLLj+bIiP4BASUKiOjLpscnRz/2rXclp9Rr8Os8HaxGcnP zseIFwEB3pVLhFGP3tMb1dX+Eow6MnOK8PYPwF/haio/D4Kah6jyVynFJO1YQ6q2NUNGjWFY20aU WkLmGqI/v4OhEa3o0qUj7Vo8xvbz0gaE+tPriYxsQduOHenYsRWR42aTrC8dXnd0AZHjltl3ANWf 385jLdrRpUtHWkUMZYc1PnSHGNasGZGRkTRp0oQmTZoQGTmOQ7rS8TUZ9Rt6YwofNGvGLR1iiImJ oXXkODalOU4+v/0rom6JoWvXDrR4bDbnnFbQzYxfwrB7mhHVcjT/OMWvP72BZs2i6BATQ0zMLWXm yYYxYxfvDb2LyBat+eFovlMiDzPUnodImjVrRrNmY0rlxVYew6JuoWvXGNq1eIxt5xwXLC8PgpqL ENSqxFiEwksFjRujVioJquN7xVUAs0FPYWExYKYgN4usfJ00E8JYSE5WFgWFlf1lZjKn+0iazFjH qVOnWD41hBHdfiAbkKmbsHj1n5w6dYpTh1YzcNOn/LQns1QMx9ZNYeCgLqis8c3uNoIm01Zz6tQp Vn8awsjuUnyoI/hwzRrWr1/Ppq1/8uPk3kBDAlWl4xt8bywqNPT9aQ2Hk5JIStrP1IGbePqHv6ST cuLpNmIG09cclmy1PuW2b/bZ4zAqGjDqlY9LpVWmCeOnNbtISkoiaf9KBm76lMW7M8osHZPRh9jR r/EkUMJ9VDfjo3Xr2LRpE+s3bWXhW72ARqXyYiuPsOlrSEpKYvnUEJ68bYFUHhXkQVBzua5Vfte2 VNfvN5etmEM/z2NPgQpPzzjmfKWn430jaV6wj4X/QN82vqxfs42ejz1L20ADx3ZtY/P+EwCEt+3B rTEtqKOArGOrWbg5jUZNPTh3SvJvwzrF4v3Xbo57eGA01uW+UffSyNuz3HTqk7czkxhW95M2i28x 4Gm6vDaALUmPcX/TSDr4Wyes+UXQIQbWnc3EYqnjFOc5VnwTxcD4elgsFvTJ25lBF5b1jgSg1eDR xLx8F1uSnuD+pj40ioy07tyazrwpcUxato9GMgu25FksUnyD/2qARWagQ4cQsFiw4MstHWJg/Tl0 wJktP0Dzd+kT6YPFAv1fnMJrdy0meXQnGnlYqNfhduoZj9OF5SXyLguIpEOQp3TMtylSlBeBELf3 T9WgLb0a6DnfHHROdovFh8ZRUpkZDEkseG8Tb674i0YyC2azlh+HtMcw6SgPyHcwgy6s6BOJxWKh xYCniX1tAFuSn6TVvvLzcOM9uzXTdj0QHmqVoeDOsS/SO8wTj7DevPTm28TU80FmMeKVlcimDWn0 GTCYEB8zR9bNZfvfpxgwfDzjnxqM/tif/PD7YQoBb68AfHx8uFh7MOPGPEKklxdnDuylyeNjGDEw Bh+fHLLzK9441mg0AGF423Zo1kthtEVFJc7L2PU/Ju+Bp3s2L3FcnxbPYgZzS2BZ8Rndxrfvi+4s HjqboS19S8Z3ejeLGUzbIJeEZsYzcfIexo3uiRowarUQFeDIR6EByKDA2TE3le+lZ8bPZvIeGN0z qtzzwEh5+6H+9XVvfnrkWx5taduEWkWX8QvoWk9lLw8v1/ItLKpcHgQ1EiGoVUhu/mXkcjMWsyeX tZewWEx4eBTj4RHMkOeeoG10JPVVl7hwVoU8qj9NAhTIazWiS5QMr6wc8g0ABiCUod1boFDIqAUo ou+mebCGwGBJjWQKWTmpcMar3CpI8rpP6fLo50xbvY9uwSXPPLllGbEf3EFJWSw/Pn3KMh76PIpf XulV6rykrSuI/eAO/JyO6ZLXE3Hr47SdtpqX7whxGLwVVDaHriSvn8atj89k2up93BFy9RUwffJv PPpFc5a81NMpL3Kadr2D5kG2I15ldzb9izwIbl5EL38V477C4Y+pKJ9CTxNKPPD08MBsBqPRCJgw mcx4ejq/25QUFmip5SG5NGazCYPRiKlI6vSoTLVGLlcCiRSYkO6ySoEGUMqlW57y+9vc9aKM1YdO Eent6qfl8MeUeB7e2sR9fAAqeYn4IIeFd71O7Afr6OQHBkPJ+LZ+sKdEfLrk1bTt9wJTf/+LeyNq Oa6j0cDBTGzJlnsrAQ1elXhSk1e/Rb8XYMVfJ4muVbk1eJRAaX8/mwW9XiZmymo6+pUOA+WX77/J g+DmRnio1wi7CCpr0TAYSPqH5Ewd+vxznEwCqOsyrEnCANi62UvvOlM2qqa3M5o9LN+RBkDK+kVs 4jl6NldjPL+Zu178mXGzR9BEnk9OTg75eueu9EN8zji6NFaViG8Mu1m58zQAyWsWspkJ9GyuBiDn 0FI+pTnP9nVTzc48yBeMdsRnPM2Mfi/AmG/pFSYnJyeH7Hwpk+G3DYHjb/PnaT2gI27BZBj3JFG2 pBjBWFQIQLFeb99D13j+D/q98BNjvn2SMHd5KoURjEUYAH2hHufNeLMP/cZUohjXJ7JUmIzkZDJ0 RlThtzGG3az487S9fON4np5R6orzIKixiHdmdVDih+NaKfSm85AnMfw+n40/zwPAK/JOhg3sgtqk owAljhUOZdJYz1olb5OsUoOxgnkmbhYP9e6O5BfGMHfbWwQDugKpR/+bp3vxjfXsLm+uYOETLQE4 vXcdPD+MEHBqYwzm2c3fcn/P3tb4Ypmz5TWCrdb0w9uh+QO0dG0jBU7vWQcTHsJeqdcXcBbg2zF0 /NZ6LPYDji4eiiL4djZ/O4aePVtJx2MmsHVKV3tcx38dyz1vbwJgd2wb6P0pR797AINWytO3Y/ph j3LyahY/2cpt6egSf6HVXZOkf4bcykwGseLoZ0QrIP3QNoh6mBaBrqH0rOjVC/2yQ4xpaSuPnkRY y3fBn1OkMqsgD4Kai0dV9YpZd0O17XQqs/6VWz9KJGVRAS3PnTu30mAwYDAYSlR1pV5iyU27WW21 atVCLpdTUFCAwWDA29sbtVpNTk5OiXDe3t54WCyY8UQm8yA3NxelUolKpUKpVJKbmwtAYGAgBoOB oqIiPD09UavV5OfnYzabK5dOz2Ky84vw9K5FLWVl8pDPgoiOyNcd5ckodek4DQUUFJrx8gtCYa5M ueTzfURHLKsP8FSrgEqXp1GXzyU9aPxr4XOD3Fu3NqOOnEt6FBp/Anxu0jzUMJtGo6FBgwaDgH+Q 6nfFSL6B0fqx7XPoTIl7AAAdv0lEQVRnRlp9tMqGBggPtYrJz8+332wAvV6PXl96hHl+fr5Lu6nj /IKCArvNWYjNZjPZ2dluw5WJXE1QkCSMlcKoJ2TKNNo3U5cTn+1hrmR8706nVXgZ8ZWBXO1HoBr7 i+OGRa4mMFDtNp03TR4EVYYQVEFJ5MH0feQelFX1ZMiD6TdkgBAVwX8C0SklEAgEVYQQVIFAIKgi hKAKBAJBFSHWQxU2YRO2/4ytuhEeak3HqCMjIxtdqTHuRvKzs8nOdrMu3VXFd+Xo8nPIycnB3Sp7 Rl0OmZn5lHUZo17nxmYkPyeHnJwryJNRj9vx//p8MjNzyC9nCUBrQsnMzHFbHhXlQVDzuK6CavNU nT/CVnW2onPbGRrZmtjYTrRv+TjbzxVJx9PW07x5S9p16kSnTq1pPm42yUWl49QdXUDzcUspcorv 8ZbtiY3tROvIofb4LNpDDIuIoHnz5oSHhxMeHk7z5uM4pC0Zp+7oAsJH/0ZRcTIfRETQtqO0Hmqb 5o71UC0WC+e2f0V02xhuvbUjLR93rCVqsVjI2LWEYfdEEN1qNEe1jrwXpa0nIiKajjExxMS0lfKk L7vMjBm7eH9of5q3bMP3R/NK2NK2fUd4dDtuvz2Wjq0i+H5fhtuyLjq3nWHRbbn11hjat3zcvh5q RXm4UZ+Xmma7HggP9UbCmMWGmTP5avnRKvBqMpnb42mazFhHSkoKSz+U1i/NQVo79MdV20lJSSHl 4CoGbv6Mn/a6Ww/1XQYOdKyHOqf7SMI+W0VKSgqrPqnL0z0WkgOgbsYHq1ezdu1a4rbsYNHb0nqo AaXWQ32XwYOl9VD7LF7NwRMnOHFiHx8O3Myohbb1UHfTfeRMpq0+KNk0n3H7LNf1UKeWSqtMI63x euLECU7sW87AzZ+xpIL1ULuMfpUnwKXhK5NVw6fy/M/7SExMZP20gbw/5Q9K+7zW9WanrebEiRMs /TCE4bd/b10Ptfw8CGouQlBvILIS9pPq5YVX9m5mfbmFbCMYC84Tv2YJM2fOZObMH9lx9KybxTxK o0/5ky+IYUhfaVm+lgOfIoZP2ZqiRx7YnA6R1kmj1vVQE85ddInhHCtmRTGgU317fDOJ4SHn9VD5 jK0pekBNqNU7bdrYyJp345i09BlCSwjVeVbMimJQ5wYgD6Zjx+ZIQ/39aNshBo5J66GmbF0orSXa XA34cfeLU+DzJXZvs37H27k9tiUxLqmVB0bSsbktT82QonTNkwNVg7b0uqML4c3d20+dPANAzunj cGdja1p1/DgknAVHdfbyeLiPo3y7MJUtyfoK8yCouQhBvYGoEx5BHcAjuBOPj+mJr+UCGxYs5Z/0 UB579nlGDmrGP3/+/v/27jy+qTrf//ir2UtaWsCWDmVEcGiLpSKDDMVBlKXKwIPlAnNVlOUnV2X5 DQ6CXC4PbnG8uDzmgojIiIyAgFBwALGogOzi+GCRTcBSKMUFcFqgpVvSbCf3jyRtSFNa4LQ09PN8 PM4jbU5ychLCu99zTs47bDr2rxqX5XRU04dqDexDXcys/fB876p9qBn+fagOO9C2xuUdXNCLjKcW 81SQPtSMavpQJ8/az3hfH2pZKSQGdon+6wb7UD+4hT7UWEZtmM7GmUNJSkpixPxe7H6pu3eekdQ/ LaP7r4w4nQ6qez1q9RzEHUkCtSExRREDEBVDpBEovswv4eEkPN6dFjo3Ldrfx316PXk/FQY9kBNk gTX2oXZ/Zh5zMg/wcJA+1NTZN96H+sS8JNYG60Pd8ympswP6UHO3ktBjNA/Myby2D7XJzXeJ5m59 ix6j5zMn88DN9aE6L7L2r2+SNv1t5kwdBCzirRXfenfBVO1DrfYRbuE5iNAlp542IG6XCwfgdjtw KQoab1+frdyC223CZvXU1un0NX/fqOc21/Z1RuLfhzqL/lM1ZB7JDdqHuuvVfTy5656A5WX59aHq q/ah9p9B6uzgfah7Xtt/zfLKcjfRud8U3tx0kCH+fajmYF2ikYTX4p2auymdflPgk4Onb6gP1X9V y7K/4M194zm4ehCR9n482KEtj46dz8hhK0nx+yJVnU5f+Xr4v7563S09BxHaZITakOh0nn11Vwu4 UmJFa27B3cDZY9nkW+0UXPiZM0DM3THUVK1pbNeDF9jPxoo+1FVs50V6J5pxXtxJ/6lrGb/4en2o 4+nm34fargfj2E+mrw/1ixXsYBK9fX2ox9Yzh0T+/+NBdkrmH+UdXqhcnvMn5vebAuMW0adKH+qT kJ3OP31dostnwfjRJAbpQ3UG9qFOubk+VLtfH6pOHwnsIjvP87sp3AC09DYoBvah7q/oh83dssrT h5porvk5iDuW/M1sSDTRpPR5gMPbDvOPD0/zx3FPMWj0YDZ/uJGMxQfQaDS06zGEtN/GQbmlhoXF MuHLv/HEY71oB0A3luyeeU0f6nvPp/Ge99bdZn7CylG+PtQtMPnpKn2oE7cvYnjfx7zLS+XvO2vb h/oFTHoiaB9qV195aepsjnv7ULcvGkffvineFZvErlf8+lDXTWCgtw/16Yc6QdpfOf7+cOylngNQ /n2oqemZ1fehZn9Myh9men4Z0YP5DOKT43PokJDG289u5pnuleXSLy/aQjsjKIqNT9PSsK0/wgvJ vtejLwne13fZ3lcq+lCv9xzEneu29KGeP3/+ju1DvdV5RqMRnQZcYVpKi4vRaDRERUXicrlBo8Np L8disdR+mTfRh7o8oSvazccZk6hOH+qKhK64Mw8xNoT6UG1lRRSWWAmPvguz7jr3kz7UBjcvIiKC 1q1bSx+q8Pah+r1JPB2ohdW+gWp0E32osX+Zw2/vVbMPdS7JIdaHajRH0VwfTo0vtfShCj8SqOJa ulgef0LdPtTHn5Q+VNE4yEEpIYRQiQSqEEKoRAJVCCFUIoEqhBAqkUAVocGZx84NW7koBSOiAZNA vVPZTjItKaminzQpKYmRK07e7rW6ebZfmDDjRS5JwYhowORjUyqwlhRisSuYmjarbB+6SYrdSlFh MQoamjSNIlzv+ZtX8P0OVm47wUP//hydY2o+lx+gDJi8bBfPPxhNidWBPjzi1lbudtLp6FaltE+I hkVGqLXlvMLe1avZeyybY7veZf7649ixcXpvBh98+BEZGRksXbSGnELPSRlnvlrPJ3uPkXNsFwsW LGDB6i85V+htMrUXcGzXJ57rF6zm2I9F3sf4FxnvLWblqlVkZKzig0VryClxgvMSR3ZmYTKZ+HrN ++zKulKrVS4FWrSOx2iOomnTppjLTzIhYSrfFvluUcS6F/qz9mQxOC+yJn0gCQkJJA1+g6NXPENB W+5nTJi6gq1r0klIGMm6DyYyYsE3FQXYttxNDBz5d/zrqfO+WcDgaZ95S5nzWTFhIPO2es55d+bt YeLolRRg49s16Z7HSxrMuqOVzyn/2zUMTEggISGBWRuOBXlmRWxIH8jEDw7J14uIBkUCtdZcuMrK OPHNTnKb9GJgtzaU5e5nd1YJDz89mfSZE0kNt7Dl2E84gbDyPC5l7WdbQQxPDk3j12U/8vmqo5Rg 4/jWlRzIiWHM5CmM6deKrz/bwnkroGnGiMn/yaxZs5j+wiDCwy2cO18Kumg6dvcUPXcbNJLUhLtq tcYRwEcL32TBggXMm7eWn0z30DMxk6U7cgFw/riHadt+TeffNGHvXx8l3TSZ70+fJnP0eYbO+AIb 4HSWsT1zNu9e/D27971Ln+492TdvNkeKAJz8829ToOfvKs7pB2hxbweyM/9Ojg24uJ/Z27N5P9NT gXd2x/vseKA9zr1zGZEezfbvT3MoczTThr7GWSeQv5MeI9KZvPs4p498gnXGE6z70VbxjEw6Gztf 78r0I3/kf/6ji2xiiQZF3o83IiyMVg+P4KnUeNwuF5dO2NBqtfwzYz4X7vkVvwDGM05cj4FOE4Y2 rg/jB3dBayuja/uvuXTGSllZIXnnDWg02Zw4FEWT0lKMxhLyi2y0izKSf3o/G/+5gx8LNZhMJhR3 GKAnunlz4BJRzZoTrq39WUdJ93chNSGKYqueKG0UvaeNI33sRgqG/JmfP/4zTF5LgvYiGz4Euu3m nbeOYj2zA3Z0xVMdbQdeZPlLj9McUKJ7MZlZZOy5QKeHf2JcJizZ1+max9S17Mwksvn6VAGRWXtI fHIMrNnHWVsae2bu4y+Zb3Fi9RigG+veeQt34S4gmxLbW/x0ZD8Au9cs5ChXyQTuLSyHOIhgB6te G86aIy+ye9MomsvZV6KBkUC9QeZwT2mJwWDA7fRscHYeOIru8UYUtITpTOh89c9R4ZQXF6PD6Xfq pcZzLr7SmtiWLYn8VTx/7KjHbTRRkL2Tj788TbeBzzI43s6WJRtA5+1EtXkq6xwOG56emZqVAr26 96ZrotHbAQD8bgB9Gcjne+/nwHuweG9nIIdyoG9aGkO6NafMnsaT01thBkoAEiP96gJjGfT2EHot Wk2P86eh71x+1zzwkVvwyNRuDFu/nrwjeUxbMo3z53rwj4x7Wcqz7EwwcxKg7wAeH9IZpSyNIWOa 0toIv1AODCJtwACaO52kpY2gVXtfD0AiJtOvIfskZy/aiIur3esgRH2RTf4bZLVXjoqi4z1FdsdO nSW/zIm9vIgL5y7gu4X7zHHO5pdQln+WkzlATDxR5kjuvhvAitVl4q67mqNzO3C4HIQ5rBgM8URH hvHLqZP8BNgsNhRAH+4JlcLLV7A5ajcyiwCuXLmM02ajrKyMMpsTjIk8+2I3XntuAtuGvM3D8TrQ 3U3aGNi+7wIR9yaTnJxM67u8B7AcQPa1y23TZxRpp95j6pwdzJzYM2g36296D4Y1/8saenJ/bCyd +/dh6avzSE0fQiuMdE4bA9u/whpxD8nJydzb+i50wN2dHwEyOVfSjOTkZJIT44nw/tkvJZph095h 9csljH10OHsvyh5U0bBIoN4AA2D0O4qvbd6BsUMfJe6HA3y8fAkfLF3Fp98XVARqWJiNrI+Xs+zj bZzXdGT4kM6EE85v/20Mj94HezauYuHChSz7aA2/WNw0b3M/MVzi8xVL2XM5nPti4MK+A+Q7oGmr JO4Dvtu+nsXHq35DaTBmYN4zD5PQoQNdunSh83+sowx4YOAzAEwf9XtvGOp4eMpuXm2STo/7EkhK SiJl/KeecbYeCOyMNj/A6MlJwCT6JUcRjPHuBxkD9P1/PYkC2nT9AwBP9moPQOzDU1g98y5G9Egh KSmJhJRpnLEBsb3ZvXwms0f08Byw6tiFf5zxjPgjgHKbjgef+4AlL0bzXO8ZHC0K9uhC3B7Sh3oD 85o3b47FYsFisVTMc7vdREWasTsV0OjQoGCxXOWH7UvYzB+YMvR+lHI7GpOBoitX0Os9m6kmkwkN nkJGncHA1YICDAYDTSOaYLW50GhAp1FwuLQUF1/FYDAQHd0Uq9WG3ang8O4CUPu528rKsCsamjWL vM79rKwe0Zldw7/gvUG/uaXHc9rKsNoVIps1Q+c/z2mjzOZEow8nsknDfU/IvIY3T/pQQ0RBQUGV 6xwOBwVXiyt+9/xjg8sG7rJyLhUUeEaBFk/4+hR7y6P976coCleLS6vtPL16tfjG+1BvkNFsRl/D wR7b2c+ZuS+JtQvb3fLj6YxmzHql6htRZ8SsM0rtnwgpEqh1wkDKsMl0UMBiKb3dK6M6Y5thHD/+ 7+j1EnZC+JNArSOW8vI6H03eNjojZh21/xYAIRqJO/B/uxBC3B4SqEIIoRIJVCGEUIkEakhxculc Flk5/5JSECEaIAnUkKJw5eAudh66gqumm3r7UF9a53+aUxErRk7g27I6XEUhGjEJ1HpmLSng8uXL lNXy9NFraWjW0oghOqLW/3Abp/2BzT9Kzb0Q9UECtd54ulMXL13J6tWrWfb+Wm93qoOcvRv4ZO8J cr//hvnz5/Nuxi7Ol3g36h1XOLwtg/nz57Nq0x6yzrihlud1+AaiE8cvJ9jJqnkHV9Pf2+af7u0d PbZiAhNXVnaQlp1cy8AJayjy9pcmJSXRrl3/yv5SWy6vj0xn69YVJCUlsfiEnAsqGi8J1HpScu4A u7NK6OHXnbr5qLc71XaJS1nf8MUZHUMH9CDcksvBM4WAg6wvV3Poh1L6Pj2OYb//NcVhYbV+zFIG sWHbR6SeepO/rD0JmCpn5u+k+xMzeWlvFqcOrccy/Y9s+MnGb7qksuO1xWTbAGzs+tssont2xubt L/3yxCmOb36WaUNfI9cJOK2c37+GP717mfU7v+Lp9sHP7ReiMZAP9tcTxWlHq9XyTcZ8Lt7TivOA 4bQDVy8waMLQah9i/MhHMFov0H7bAexNTOAs5JcLRjT3PE6HODN6d3sebL+DzeW1fdQ8dG0eYt7i Z+n+/DB2PvI1EZ5T9Ct6R3etfodDSgGZQNvCcsyd+vECs/nHoSJmdjrJ1B2JrH7zHk7M/RDoxvoF 89AU7wFOUWJ7Ewyeir/ly18iOdpz2q0QjZUEan1xeDbhHxg4iodaGXEooDU0wa14N8zvboq9uBjs ntITm/e8f5NGg1vvRnE6ceHAYXV7KmhqyWmDln0n8/qgpYz7z7/S92oTXgCgHBjCY4MG0dRioV+/ Z4i5xwxEMfj1PvRf/jmp3ffAEy/yQBTsAOg7gMcGP4DeOYBBo8KJNeLd/dCNJsE6/IRoZGSTv55E tW4LeLpTL1sVbNYiLvzg153qK07x/xfRmYmJAXIOcyL3ArmHtrLtZwhaQHpdZobOXEvf/Zlsz7b4 9Y5u5FxxtLd3tDVm75/Xdo+OJHXbTJ5/dRuvj+6Gzq+/tDyiDR07dqzoLxVCVJJArSea6CRPd+q5 /az58O8sWbaKT08WVh5f8ttU1uPrXTVz/4ABxIZdYe/nG9hsiaNrmzBuqm2saSdeWf5i5e+xvdn7 UTqvPtHd00d6X2fW53g/DdC8MyOfAlLTebSdp9ja11/6dM9OtGvXjoSUafhuHnnjayPEHUn6UOtx nlarpVlUJHangssdhk4DRUVFREVF4Xa7sVgsAERGRmK1WikvL0ej0RAVacbhCkOrrdzWLyoqUmc9 nTYKSywYwiMx6mq+n91agltjwGg2ozTg11rmNd550ofaSDgcDq4We+r8/N8IRUVF17xJrly5UjFP URSuFBZV+wa6ZTojZnMYtV2kzmiuXBf11kKIO4Js8gshhEokUIUQQiUSqEIIoRIJVCGEUIkEqhBC qEQCVQghVCKBKoQQKpFAFUIIlUigCiGESiRQhRBCJRKoQgihEglUIYRQiQSqEEKoRAJVCCFUIoEq hBAqkUAVQgiVSKAKIYRKJFCFEEIl8hUoQoQQl8tFTk4OP//8M3b7nf8lNEajkfj4eNq3b49Wq73d q1MjCVQhQkhOTg4xMTH07NmTyMg7//tmS0pKyMrKIicnh8TExNu9OjWSTX4hQkheXh4pKSmNIkzB 8w3AKSkp5OXl3e5VqRUZoQoRQlwuFyaTCRW/+bjBM5lMuFyu270atSIjVCFCiKpfIR5CQuV5h8Za CiEA0Gq1KIpyy9N3y0ai1Wr9pj7MWPYVxSosuy6mUDggBbLJL0RI0Wg0KIpyy8tx20qBWZwq/DNN iwvIPfwxPf6tF1/8vIV9M3o1uGCQEaoQQnVarRa3233rE8WQEktMeDjN41rTtf8Uzn4yieN/eYND JW7cbiv7l/83RqMRo9HIY1OX86PVc99Ta6Yy8d3P2PDacM/84XM5VeKZZ734NRMf9NznwYnLyVdj Xd3ukBmhSqAKEUJ8I9RbntxuwI1LUVBcLlwuJ616jeAR9nDgdAEXts6k5/P72ZpTgKU4h0HfPU/C lE3YFQV7yQ98MGUYmVETuXDhMJM2zWDdyQIU5Qdmtu1Dk1eysNvzmJT3PBMyslRZ31AZoTa0kb0Q ogYOh+OWl+FS3OBWcDocVCytzIEbMGicHPz0XTq+toffx+pwuGMZ879zmPK79WS//hguaxH86VOW jOuB02WlfUco0jix5h7kXaDn5wv4r2/Cyd4En3UqVGV9Q4UEqhAhpC43fX/Zv5GvGMice02csAAG DS7vx7OcigEowwU4gI5xLXA4XYCdcu/9nc4wAAYNf4aeUW6cw4YxO7atKusmm/xCCNWpFyxRcKKY wnIn5aVXOb1nEUlD5zJwwX/RwWCk+8CxnHh5GSdLAUrZungSPPUkiSbv3Ss+BxtWsURTuy68DOw+ WUL7++8nJaUDLZqos74SqEII1akXLGZgJsktW9Ayvg1dB+1lweajrH02BQWIH/w/rHs5h4fio4iK imdUzsscnDsYDaA3Xrukil/d8UzP3kzLlx+nWWQkkZHNGLHylCprGyqBKpv8QoQQtYIleexSrM8t 87vGjeJy4XB6PpLldkXQ75UtlMwoo9ypI8JswOl0orgheewWDuC7bQRjD1jB5cCpuNH96mEWWEt4 s7QcdCbMBiqWeSskUIUQqgsLC6v5RrWgOB1cv6vKjcvpAI0Ro9GN3eG85r6K3+2cDr8luV047J6W KNwKfne7JWo977omm/xChBCj0VjPR83dlbtLb+RebjdqtQ04HA5PQIcACVQhQkhcXBz5+fmNogsV wG63k5+fT8uWLW/3qtSKbPILEUJiY2PJz8/n8OHDjeLznXq9nri4OFq2bElJScntXp0aSaAKEUJK SkqIi4ujbdu26HSe/77Bqvx8+xxDfZ6iKJSWllJcXFxlfkMkgSpEiCkqKqKwsBCDwQB4Nov9T81U FOWOnteQhcZaCiFECJBAFUIIldR3oLq9kxBC1KXbkjV1FaiBT0RCVAhxu9RbHtX1CNUd8LM7VE4h E0KENDdVR6l1PrCrj03+a56Yy+VSgEuhciqZECJ0eHPlEpXhGSxY60xdBmrgE/L97AKOhcrHIIQQ ocObK8fw5Ex1GVR3j18Hy6xuiK14J8u8efP2GAwGRUJVCKEWjUaDTqdT5s2btwewUJk5PnW++V+X B6UCJ9/1BXPnzv3u/Pnzb+v1ekWr1YZMk4wQouEJCwtDq9ViMpmUixcvzps7d+53QAHBN/vrdPO/ rs+U8q244jeVAfldu3b9Zvz48Zbp06enKorSSaPRxCiKgl6vBzwvUuCZEzJP5sk8mRc4D7ik0WiO vfHGG/sWLlx4FMjHkzP+uQP1sB81LNg5tDe1oMphpgbP9yJoAK130nknPWDwTlFAS++l0TvP/3ba gGWB//ctCCEaA/9Bmdt76ftqK6d3cgA2oAjI817avZP/7VzeyX9ZuNUKQVQcobrdbrdfqFZc7b30 PQHfQSkXUILnRdBzbZjqqAxiDZWhChKoQjQ21QWqi8qg9IWqA0+I+ua7/e7jv6zKhasYplA3m/yB +y0UPKHoeyE0fpdOKkPS//b+gRrmNwkhGh//fZ/+gRosVP1Hob5LuHZQV2f7UetyH2rgixDGtaHq P/KsLkwlUIUQgVlSXai6Aib/faj18nnU+qjv84Wpf6AGC1JfmGqQQBVCVKouUH2XTqqOVgMD9da/ KbAWVA1U735U/6t8m/v+Q/Uqd6PyCV8vTCVQhWicAjfVg4VqdaNVJeB+FctRe/8p1M8I1X+ncLCD Vr4XxD9IfZPvPnJQSojGKdjZToEjz2DBGmyTv87VVaAGa3cJHHIH7jf17Vv1fUxKju4LIXz8g9U/ JH2XgQei/H8O3Q/2B3x8yv8viu9Iv+963+S73j9IIfgIVQjROAWOUH2X/sEabArc1PcsrA4296Hu j/L7B+v1QtV/dBrsg/yBgSoBK8SdLdhWrv9l4L5R33WBIRq4uV+nm/6qnSlVZcGVo9TAfaD+U+CZ ULLfVAhRner2p/ouqxx4CnafuhqdQh0GKlQJVd9l4Cmq/tdXd0RfQlWIxi3YiLW64AzcCq64f12G KdRxoEK1oRp4WdNthBACqm76Bxu1Br2s6zCFeghUuCZUIXhYSpAKIW5EdeEZ9Lr6CFOop0CteLDg wRr4M7W4XgjROFUXWEEPPNVXkPrUa6BWPGjwRmkJTyHEzagSYvUdpD63JVCDqSZkhRDium5XeAbT YAJVCCFCnXxLnhBCqEQCVQghVCKBKoQQKpFAFUIIlUigCiGESiRQhRBCJRKoQgihEglUIYRQiQSq EEKoRAJVCCFUIoEqhBAqkUAVQgiVSKAKIYRKJFCFEEIlEqhCCKESCVQhhFCJBKoQQqjk/wBlLLhq qKxhgAAAAABJRU5ErkJggg== --Boundary_(ID_xtEdFOi8lAxCsFoQpEbj2A) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT This cognitive cost can also have a security cost, as draft-ietf-6man- uri-zoneid-02.txt points out, when two strings that are textually different have the same meaning. Since escaping has all these costs, escaping should only be used where it's actually needed. And here, in IPv6 addresses in URIs, escaping is *not* actually needed to allow unambiguous parsing. Since it's not needed, why inflict this pain on ourselves? The argument seems not to be one reasoning from computer science first principles (since there is in fact no need for escaping to allow unambiguous parsing) but instead one reasoning from what is sometimes called "RFC lawyering". The document draft-ietf-6man-uri-zoneid-02.txt says as much: Some versions of some browsers accept the RFC 4007 syntax for scoped IPv6 addresses embedded in URIs, i.e., they have been coded to interpret the "%" sign according to RFC 4007 instead of RFC 3986. Clearly this approach is very convenient for users, although it formally breaches the syntax rules of RFC 3986. The document concedes that using IPv6 addresses with a "%" zone identifier in URIs does actually work, and "is very convenient for users", and the only reason not to use it is that it "formally breaches the syntax rules of RFC 3986". We should fix RFC 3986 to match reality, rather than insisting that reality be constrained by a minor mistake in RFC 3986. In fact, careful reading of RFC 3986 makes it far from clear that using IPv6 addresses with a "%" zone identifier would in fact breach the syntax rules. RFC 3986 states that percent-encoding should be done on a component-by-component basis, and for each component of a URI, escaping is done *only* as necessary for that specific component. See excerpts from RFC 3986 below. Emphasis (in caps) added by me: 1. The percent-encoding rules are per component, not global for the URI as a whole: A percent-encoding mechanism is used to represent a data octet IN A COMPONENT when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, THE COMPONENT. 2. Characters should not be percent-encoded where they are specifically allowed by the component in question: URI producing applications should percent-encode data octets that correspond to characters in the reserved set UNLESS THESE CHARACTERS ARE SPECIFICALLY ALLOWED BY THE URI SCHEME TO REPRESENT DATA IN THAT COMPONENT. IPv6 literals *do* specifically allow percent signs, and so by this reading of RFC 3986 percent signs do not need to be (and should not be) escaped. The document draft-ietf-6man-uri-zoneid-02.txt even concedes that this is the most user-friendly approach: The authors believe it is feasible, and very convenient for users, if browsers also allow (in addition to the formal URI syntax defined in this document) a syntax that will enable cut and paste. For example: http://[fe80::a%en1] It seems that modern browsers can be adapted to parse this because it is inside of the "[" "]"'s. This would permit the output of commands like ping6 -w ff02::1%en1 to be "cut and pasted" into a browser address bar. Consequently this document recommends that browsers support this syntax in addition to the formal URI syntax defined above. If we are advocating that web browsers accept this syntax (and that is indeed what I am myself advocating internally at Apple) then what benefit do we gain by specifying that one syntax is acceptable in some places and a different syntax is acceptable in other places? Let's just publish a document which states that the currently- accepted and widely-used IPv6 "%zone" notation is also fine for use in URIs. This document would also in effect by clarifying RFC 3986 to state that "%" characters *only* need to be escaped in those URI components that actually use "%xx" escaping, and MUST NOT be escaped in URI components like IP-literals that are specified to not use "% xx" escaping. That clears up the ambiguity in RFC 3986, and lets people continue using the IPv6 "%zone" notation they already understand. Stuart Cheshire --Boundary_(ID_xtEdFOi8lAxCsFoQpEbj2A)-- From evyncke@cisco.com Mon Jul 16 23:35:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D074D11E80AA; Mon, 16 Jul 2012 23:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXPRDuCjVVZr; Mon, 16 Jul 2012 23:35:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C937411E80A2; Mon, 16 Jul 2012 23:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=2777; q=dns/txt; s=iport; t=1342506955; x=1343716555; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TWIlFC9NxI8exOCCt45QsvkqLV6T/iUcgDmxUBcaI5U=; b=MstWLJrEWJDaFVk2TQq7s8UQI+3ggA5Bpx/cBwSkE/9pzsn56Q+g4SyO zcQsLbTi64TXq2UgwLm/5ZhskCDdWr7eBAqYEUDpNHNwJIH90KMPW70Qw tsGxUhuro6PzHAEowA54/MMy4IfXr2HtuSYV9W0mch/yD/qhIhfBcWK7p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD0HBVCtJV2d/2dsb2JhbABFuVmBB4IgAQEBBAEBAQ8BWwsMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCBqHawucKKAgiz6FZ2ADiBaON40OgWaCXw X-IronPort-AV: E=Sophos;i="4.77,599,1336348800"; d="scan'208";a="102529421" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jul 2012 06:35:55 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6H6ZtYi013515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 06:35:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.178]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 01:35:54 -0500 From: "Eric Vyncke (evyncke)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: RE: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt Thread-Topic: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt Thread-Index: AQHNY5uf9NPwb/+GJkuSbbB/fIVyipctA4xw Date: Tue, 17 Jul 2012 06:35:54 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E104C050@xmb-aln-x02.cisco.com> References: <20120716213830.29978.99834.idtracker@ietfa.amsl.com> In-Reply-To: <20120716213830.29978.99834.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--41.499300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 06:35:09 -0000 Fernando, As I said in Paris, very useful I-D which is really important for stateless= firewalls (read switch ACL). Two minor comments: - section 2.0 I would also explicitly add ICMP in addition to UDP & TCP (as= ICMP is not really an upper-layer protocol as it is the control engine of = the network layer) - not sure whether an upper-layer header could strictly be part on the IPv6= extension header chain (at least not per RFC 2460) Even as the I-D is, it is ready for WGLC IMHO -=E9ric > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: lundi 16 juillet 2012 23:39 > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance Working Group of the > IETF. >=20 > Title : Security and Interoperability Implications of > Oversized IPv6 Header Chains > Author(s) : Fernando Gont > Vishwas Manral > Filename : draft-ietf-6man-oversized-header-chain-01.txt > Pages : 13 > Date : 2012-07-16 >=20 > Abstract: > The IPv6 specification allows IPv6 header chains of an arbitrary > size. The specification also allows options which can in turn extend > each of the headers. In those scenarios in which the IPv6 header > chain or options are unusually long and packets are fragmented, or > scenarios in which the fragment size is very small, the first > fragment of a packet may fail to include the entire IPv6 header > chain. This document discusses the interoperability and security > problems of such traffic, and updates RFC 2460 such that the first > fragment of a packet is required to contain the entire IPv6 header > chain. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-01 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-oversized-header-cha= in-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Tue Jul 17 06:15:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5453121F86FD for ; Tue, 17 Jul 2012 06:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toKK1naqm6aM for ; Tue, 17 Jul 2012 06:15:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9421F86FC for ; Tue, 17 Jul 2012 06:15:56 -0700 (PDT) Received: from bl10-131-211.dsl.telepac.pt ([85.243.131.211] helo=[192.168.1.84]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sr7dn-00066s-Nr; Tue, 17 Jul 2012 15:16:40 +0200 Message-ID: <5005656E.1020101@si6networks.com> Date: Tue, 17 Jul 2012 14:15:26 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt References: <20120716213830.29978.99834.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E104C050@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E104C050@xmb-aln-x02.cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 13:15:57 -0000 Hi, Eric, Thanks so much for your feedback! -- Please find my comments inline... On 07/17/2012 07:35 AM, Eric Vyncke (evyncke) wrote: > As I said in Paris, very useful I-D which is really important for stateless firewalls (read switch ACL). > > Two minor comments: > - section 2.0 I would also explicitly add ICMP in addition to UDP & TCP How about e.g. s/UDP/ICMPv6/, since, after all, "UDP" was just there as an example? (I'd prefer to do this rather to add yet another protocol, since it might lead people to think that the list is exhaustive.. when it's not). > (as ICMP is not really an upper-layer protocol as it is the control engine of the network layer) >From the point of view of encapsulation, I view ICMP as an upper layer protocol -- although it clearly provides a function at lower layers. A similar example would be BGP, which is an "app" protocol, but provides functions for the network layer. > - not sure whether an upper-layer header could strictly be part on the IPv6 extension header chain (at least not per RFC 2460) Well, I'd consider the upper-layer header being part of the "ipv6 header chain" (*) since they are identified with the same namespace used for extension headers. (*) I've just skimmed through RFC 2460, and it doesn't mention/define the term "header chain". Two possible options: 1) Leave the doc "as is" 2) s/IPv6 header chain/header chain/ This one might address the issue you've raised, but then some might argue that "the entire header chain could also mean that e.g. an app-layer header should be included". I'd rather stick with 1, but I'm certainly open to suggestions. Thoughts? > Even as the I-D is, it is ready for WGLC IMHO Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From evyncke@cisco.com Tue Jul 17 07:38:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ADA21F86C1 for ; Tue, 17 Jul 2012 07:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltzJaPXACrRb for ; Tue, 17 Jul 2012 07:38:55 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 566D021F86C4 for ; Tue, 17 Jul 2012 07:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=3053; q=dns/txt; s=iport; t=1342535983; x=1343745583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ufkDCtBvrBV7lE55t1izWBj0ARynZmszXZ3WyDz729M=; b=lM7O6W91SFssBRWUh9kOGx8tTIpmhIfA+1Hj0T6/owFaQz81TiWOgVa1 Gv4p1YyySnSn0b40cCoD09rfv0MmUjRqPJfkYTsS0V1Rtp8s3wPp1CzpM 7D9+Hbat1Fx991C2hwrXqOvNOou/wykqatath/1JCBHms5a7MShbVbjzu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALh3BVCtJXG9/2dsb2JhbABFuVKBB4IgAQEBBBIBZgwEAgEIDgMEAQEBCh0HMhQJCAIEDgUIGodrnQmgMYtAGoVNYAOIFptJgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,603,1336348800"; d="scan'208";a="102647159" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2012 14:39:43 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6HEdgQw032514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 14:39:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.178]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 09:39:42 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont Subject: RE: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt Thread-Topic: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt Thread-Index: AQHNY5uf9NPwb/+GJkuSbbB/fIVyipctA4xwgADFgwD//8KRsA== Date: Tue, 17 Jul 2012 14:39:42 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E104F17A@xmb-aln-x02.cisco.com> References: <20120716213830.29978.99834.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E104C050@xmb-aln-x02.cisco.com> <5005656E.1020101@si6networks.com> In-Reply-To: <5005656E.1020101@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--61.553600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 14:38:56 -0000 Fernando, Fully agree with your first change. Just for the pleasure chatting: BGP is = indeed an app while ICMP is the control part of the network layer, let's re= serve a beer to discuss about this.=20 Regarding the 'IPv6 header chain', indeed RFC 2460 does not define 'chain' = but specifically write about 'IPv6 extension headers' as w/o upper-layer pr= otocol, hence, 'IPv6 header chain' could be confusing. I.e. I am using this= wording to address the extension header chain (ellipsis of mine). Your I-D= clearly defines it so no big deal, just slightly confusing. I would prefer= the word 'IPv6 header chain + next-layer header' but this is quite long of= course. -=E9ric > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: mardi 17 juillet 2012 15:15 > To: Eric Vyncke (evyncke) > Cc: ipv6@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-01.txt >=20 > Hi, Eric, >=20 > Thanks so much for your feedback! -- Please find my comments inline... > On 07/17/2012 07:35 AM, Eric Vyncke (evyncke) wrote: > > As I said in Paris, very useful I-D which is really important for > stateless firewalls (read switch ACL). > > > > Two minor comments: > > - section 2.0 I would also explicitly add ICMP in addition to UDP & > > TCP >=20 > How about e.g. s/UDP/ICMPv6/, since, after all, "UDP" was just there as a= n > example? (I'd prefer to do this rather to add yet another protocol, since= it > might lead people to think that the list is exhaustive.. when it's not). >=20 >=20 > > (as ICMP is not really an upper-layer protocol as it is the control > > engine of the network layer) >=20 > From the point of view of encapsulation, I view ICMP as an upper layer > protocol -- although it clearly provides a function at lower layers. >=20 > A similar example would be BGP, which is an "app" protocol, but provides > functions for the network layer. >=20 >=20 > > - not sure whether an upper-layer header could strictly be part on the > > IPv6 extension header chain (at least not per RFC 2460) >=20 > Well, I'd consider the upper-layer header being part of the "ipv6 header > chain" (*) since they are identified with the same namespace used for > extension headers. >=20 > (*) I've just skimmed through RFC 2460, and it doesn't mention/define the > term "header chain". >=20 >=20 > Two possible options: > 1) Leave the doc "as is" >=20 > 2) s/IPv6 header chain/header chain/ > This one might address the issue you've raised, but then some might argue > that "the entire header chain could also mean that e.g. an app-layer head= er > should be included". >=20 >=20 > I'd rather stick with 1, but I'm certainly open to suggestions. Thoughts? >=20 >=20 >=20 > > Even as the I-D is, it is ready for WGLC IMHO >=20 > Thanks! >=20 > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From Aleksi.Suhonen@tut.fi Tue Jul 17 18:17:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0784521F855F for ; Tue, 17 Jul 2012 18:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDfEk1mWJtWe for ; Tue, 17 Jul 2012 18:16:59 -0700 (PDT) Received: from mail-gw-out2.cc.tut.fi (mail-gw-out2.cc.tut.fi [130.230.160.33]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9611E8079 for ; Tue, 17 Jul 2012 18:16:56 -0700 (PDT) X-AuditID: 82e6a021-b7f236d000000a82-2c-50060eb83deb Received: from mail1.tut.fi (mail1.tut.fi [130.230.162.19]) by mail-gw-out2.cc.tut.fi (Symantec Messaging Gateway) with SMTP id 48.6C.02690.8BE06005; Wed, 18 Jul 2012 04:17:44 +0300 (EEST) Received: from [IPv6:2001:708:310:52:21a:6bff:fe61:167] (pool46.nat64.trex.fi [195.140.194.46]) by mail1.tut.fi (Postfix) with ESMTPSA id 2DE4740344; Wed, 18 Jul 2012 04:17:44 +0300 (EEST) Message-ID: <50060EB3.9060308@tut.fi> Date: Wed, 18 Jul 2012 04:17:39 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Department of Communications Engineering User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: Michael Richardson Subject: Re: draft-chen-v6ops-nat64-experience-02 References: <4FF696AA.3050508@tut.fi> <23986.1341586765@marajade.sandelman.ca> In-Reply-To: <23986.1341586765@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsXS9GyRsO4OPrYAgwPHhC1enn3PZNFzqJ/d 4kNnC6vFn89v2B1YPOY8es/qsWTJTyaPljl7mD3W7PvBEsASxWWTkpqTWZZapG+XwJUxf95m loI97BVPnj1ibmD8xtrFyMEhIWAicfyeaxcjJ5ApJnHh3no2EFtIYB+jxM7lMl2MXED2AUaJ J3PvsoAkeAVUJQ4fvcQG0ssCZJ+/UwASZhPQkbjSdQusl18gWuL1ub/sILaoQIjE9OaDTBCt ghInZz4BGyMioCex/MgzRhCbWcBWovfFXGYQW1jAUOLmrfksEDf4Sdy7NB+sl1PAVGLi7n3M EPU2En9PLGKBsOUltr+dwzyBUXAWkhWzkJTNQlK2gJF5FaNYbmJmjm56uW5+aYmRXnKyXklp iV5a5iZGcFAvUNzBeGqG/iFGAQ5GJR7eG5tZA4RYE8uKK3MPMUpyMCmJ8m7nZQsQ4kvKT6nM SCzOiC8qzUktPsQowcGsJMIr+ByonDclsbIqtSgfJiXDwaEkwfsdpE2wKDU9tSItMwcYuzBp Jg5OkHYeoPbrIDW8xQWJucWZ6RD5U4yKUuK8nMDYFxIASWSU5sH1ghJH/f///18xigMdK8z7 DqSdB5h04LpfAQ1mAhpsWcIEMrgkESEl1cAYMlE7aN8xsW/+9X4ft3Bs/W9WaMPPG/txzX7L 1TJHGF7N2fqPZ9vu9d7fDYwdtt/q8w0SSjQ9e/xCrWvd7O/neurZcovibh0v2e/dc7d1dYyn xOLnb5+G9V+4lPtFSN/8Vkbx0fqfovf3ejtXdDNwXXpzSbfh+oWIrBWLfTz/n8i5lpznUftR iaU4I9FQi7moOBEAs8tuNfcCAAA= Cc: sunqiong@ctbri.com.cn, ipv6@ietf.org, niu.qibo@zte.com.cn X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 01:17:01 -0000 Hi, Sorry for late response. It's the summer holiday season here. O:-) On 07/06/2012 05:59 PM, Michael Richardson wrote: > >>>>>> "Aleksi" == Aleksi Suhonen writes: > Aleksi> Within an hour, all the IPv4 addresses in the pool for our > Aleksi> NAT64 were registered to this one device. > > Do I understand that you attempt to provide a single IPv4 address 1:1 > with a an internal IPv6 address? (NAT vs NAPT) Yes. Stateless NAT64. http://tools.ietf.org/html/rfc6144#section-3.2.1 > Can you tell me what your expiry time is for reclaiming the IPv4 address? 2 hours. However, anything above 5 minutes will yield the same result on today's Internet. And 5 minutes is too short. > Would IPv6 ping'ing the internal device help? Hmm? Help with what? I'm not sure I understand you. -- Aleksi Suhonen, Researcher Department of Communications Engineering Tampere University of Technology From ietfc@btconnect.com Wed Jul 18 01:33:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5213E21F8617 for ; Wed, 18 Jul 2012 01:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.712 X-Spam-Level: X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfYehE7vrFDp for ; Wed, 18 Jul 2012 01:33:40 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id E640F21F8604 for ; Wed, 18 Jul 2012 01:33:39 -0700 (PDT) Received: from mail208-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 08:34:29 +0000 Received: from mail208-va3 (localhost [127.0.0.1]) by mail208-va3-R.bigfish.com (Postfix) with ESMTP id D3D2B7802C5; Wed, 18 Jul 2012 08:34:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT006.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: PS-35(zz98dI9371Ic89bh936eI1b0bM542M1432Izz1202hzz1033IL8275bh8275dh186Mz2dh2a8h5a9h668h839h93fhd24hf0ah107ah304l) Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3 (MessageSwitch) id 1342600466326390_25402; Wed, 18 Jul 2012 08:34:26 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.250]) by mail208-va3.bigfish.com (Postfix) with ESMTP id 49455720046; Wed, 18 Jul 2012 08:34:26 +0000 (UTC) Received: from DB3PRD0702HT006.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 08:34:26 +0000 Received: from BY2PRD0310HT003.namprd03.prod.outlook.com (157.56.236.5) by pod51017.outlook.com (10.3.4.165) with Microsoft SMTP Server (TLS) id 14.15.86.1; Wed, 18 Jul 2012 08:34:13 +0000 Message-ID: <00cd01cd64bf$8d6eea80$4001a8c0@gateway.2wire.net> From: t.petch To: Brian E Carpenter , Bob Hinden References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org><9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4FF6E199.5020007@gmail.com> <4FF718C7.5060206@gmail.com> Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt Date: Wed, 18 Jul 2012 09:30:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.236.5] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-uri-zoneid@tools.ietf.org, ipv6@ietf.org, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:33:41 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: "Bob Hinden" Cc: <6man-chairs@tools.ietf.org>; ; ; "Dave Thaler" Sent: Friday, July 06, 2012 5:56 PM Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt > I'd be happy with that, or a small appendix. Dave, is it documented anywhere? > Non-normative Appendix, Please. Tom Petch > Regards > Brian > > On 2012-07-06 15:00, Bob Hinden wrote: > > With my co-author hat on, would it help to include a description of what IE supports in Section 3. Web Browsers? > > > > Bob > > > > > > On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: > > > >> Dave, > >> > >> 1) FYI, the deadline we gave the URI list to comment on this has just > >> passed, with only one (positive) reply. > >> > >> 2) It's for the WG Chairs to say if they want another version > >> in view of your comments. > >> > >> 3) I don't see how the % format is currently legal. There's > >> no provision for any characters after the IPv6 address, whether > >> percent-encoded or not. We heard of browsers that previously > >> allowed full RFC 4007 syntax (% *not* treated as an escape) > >> but this is the first I've heard of IE allowing a zone index > >> at all. > >> > >> Regards > >> Brian > >> > >> On 2012-07-06 02:28, Dave Thaler wrote: > >>> I know it's after the designated end of WGLC, but here's my feedback... > >>> > >>> The document appears to call out existing practice in several places, such as in section 1: > >>>> Some versions of some browsers accept the RFC 4007 syntax for scoped > >>>> IPv6 addresses embedded in URIs, i.e., they have been coded to > >>>> interpret the "%" sign according to RFC 4007 instead of RFC 3986. > >>> and in Appendix A point 1: > >>>> Advantage: works today. > >>> However, it's missing discussion of other alternatives already in common practice. > >>> For example alternative 3 (escaping the escape character as allowed by RFC 3986) has: > >>>> Advantage: allows use of browser. > >>>> > >>>> Disadvantage: ugly and confusing, doesn't allow simple cut and > >>>> paste. > >>> The disadvantage is certainly true. However the main advantage are notably > >>> lacking, which is that it's already in common practice in many places (to the extent > >>> that using a zone id at all is common practice anyway). > >>> > >>> You'll see at > >>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=3Dvs.8= 5 ).aspx > >>> that alternative 3 is what is supported in IE7 and above, and the APIs are generally > >>> available to Windows applications (i.e. not just IE7). > >>> > >>> The document does not state whether the existing legal use is suddenly > >>> declared to be illegal, or just another legal way of doing the same thing. > >>> > >>> If you're telling existing applications and OS's that use alternative 3 that they > >>> have to change, that doesn't sound like a good thing. That's because many apps > >>> want to be OS-version-independent and use URI parsing libraries provided by > >>> the OS. We don't want apps to code their own URI parsing (it's very easy to > >>> get wrong, especially when you add various internationalization issues). > >>> As a result, apps will tend to code to the lowest common denominator of > >>> OS's they want to work on. That means I expect to see apps coding to > >>> alternative 3 for the foreseeable future. When they don't use them in > >>> edit boxes, the disadvantage of not being able to cut and paste is not a > >>> real disadvantage. > >>> > >>> Personally I don't have an issue with allowing both formats if the WG feels > >>> strongly that a cut-and-paste-friendly format is needed in addition to > >>> what's existing practice, though having two does affect the rules for > >>> comparison (see draft-iab-identifier-comparison section 3.1.2) but not > >>> noticeably. > >>> > >>> Finally, the stated disadvantage of alternative 3 is only a disadvantage if the > >>> specified scheme in section 2 *does* allow cut-and-paste. For that to > >>> happen, it means the zone id separator has to work outside the context of > >>> URIs. That is, section 2 says: > >>>> Thus, the scoped address fe80::a%en1 would appear in a URI as > >>>> http://[fe80::a-en1]. > >>> To support cut-and-paste, that means that > >>> "ping fe80::a-en1" > >>> needs to work. But this document is titled > >>> " Representing IPv6 Zone Identifiers in Uniform Resource Identifiers" > >>> and similarly the abstract limits its scope to URIs. > >>> > >>> Hence section 2 is in contradiction with the analysis of alternative 3. > >>> The document already says it "updates 4007" so it seems that what's > >>> lacking is a section specifically updating RFC 4007 section 11 which would > >>> declare that both '%' and '-' are acceptable separators in the textual > >>> representation. > >>> > >>> -Dave > >>> > >>>> -----Original Message----- > >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >>>> Ole Tr=C3=B8an > >>>> Sent: Wednesday, June 13, 2012 5:18 AM > >>>> To: ipv6@ietf.org Mailing List > >>>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- > >>>> zoneid@tools.ietf.org > >>>> Subject: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt > >>>> > >>>> All, > >>>> > >>>> This message starts a one-week 6MAN Working Group Last Call on advancing: > >>>> Title : Representing IPv6 Zone Identifiers in Uniform > >>>> Resource Identifiers > >>>> Author(s) : Brian Carpenter > >>>> Robert M. Hinden > >>>> Filename : draft-ietf-6man-uri-zoneid-01.txt > >>>> Pages : 9 > >>>> Date : 2012-05-29 > >>>> > >>>> > >>>> as a Proposed Standard. Substantive comments should be directed to the > >>>> mailing list or the co-chairs. Editorial suggestions can be sent to the authors. > >>>> This last call will end on June 20, 2012. > >>>> Regards, > >>>> Bob, & Ole > >>>> ------------------------------------------------------------------- - > >>>> IETF IPv6 working group mailing list > >>>> ipv6@ietf.org > >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> ------------------------------------------------------------------- - > >>> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ietfc@btconnect.com Wed Jul 18 01:38:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBB521F8646 for ; Wed, 18 Jul 2012 01:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.705 X-Spam-Level: X-Spam-Status: No, score=-3.705 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfC8gC2NN2iD for ; Wed, 18 Jul 2012 01:38:30 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA821F86F7 for ; Wed, 18 Jul 2012 01:38:29 -0700 (PDT) Received: from mail82-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 08:39:18 +0000 Received: from mail82-am1 (localhost [127.0.0.1]) by mail82-am1-R.bigfish.com (Postfix) with ESMTP id 4929F260416; Wed, 18 Jul 2012 08:39:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I542M1432I1418Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail82-am1 (localhost.localdomain [127.0.0.1]) by mail82-am1 (MessageSwitch) id 134260075631385_14918; Wed, 18 Jul 2012 08:39:16 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.229]) by mail82-am1.bigfish.com (Postfix) with ESMTP id 03DE84E0053; Wed, 18 Jul 2012 08:39:16 +0000 (UTC) Received: from DB3PRD0702HT004.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 08:39:15 +0000 Received: from BY2PRD0310HT002.namprd03.prod.outlook.com (157.56.236.5) by pod51017.outlook.com (10.3.4.154) with Microsoft SMTP Server (TLS) id 14.15.86.1; Wed, 18 Jul 2012 08:39:13 +0000 Message-ID: <00e101cd64c0$4060da40$4001a8c0@gateway.2wire.net> From: t.petch To: Brian Haberman , 6man WG , 6man Chairs <6man-chairs@tools.ietf.org>, Barry Leiba , Pete Resnick , Ralph Droms References: <4FFB7918.9080806@innovationslab.net> Subject: Re: Status of draft-ietf-6man-lineid Date: Wed, 18 Jul 2012 09:35:02 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.236.5] X-OriginatorOrg: btconnect.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:38:31 -0000 Angels on the head of a pin. I think that almost all the world is unaware of the different classifications and so the answer for them is moot. Yes, I know, a few official bodies do care but for Internet at large, it will make no difference. That said, I care and think that PS is alway preferrable unless there is a good reason not to, that is, we should keep other categories, such as Experimental, for those when we really do care and want a strong marker that we can refer back to afterwards when those who do not appreciate the difference have stumbled over it. If in doubt, PS every time. Tom Petch ----- Original Message ----- From: "Brian Haberman" To: "6man WG" ; "6man Chairs" <6man-chairs@tools.ietf.org>; "Barry Leiba" ; "Pete Resnick" ; "Ralph Droms" Sent: Tuesday, July 10, 2012 1:36 AM Subject: Status of draft-ietf-6man-lineid > All, > During the IESG discussion of draft-ietf-6man-lineid, the question > was raised as to its appropriate status. The WG decided to advance the > draft as Experimental since it had documented limitations and was > targeted to a limited deployment scenario. Several ADs raised the issue > that the above reasons do not necessarily make the draft inappropriate > for Proposed Standard, To quote feedback from one of the ADs (Barry Leiba): > > > "If the limitations are clearly documented and if that document can be > used to target implementations correctly, then I think PS is completely > appropriate. If experimentation is needed to *determine* the > limitations, or to determine how to implement the specification to as > not to interfere with inapplicable situations, then Experimental is best." > > In my view, there is a clear understanding of what the limitations of > this approach are and they can be clearly defined in an applicability > statement within the draft. Additionally, we know the deployment > scenario (N:1 VLAN usage in broadband networks) where this approach will > be used. > > My question is whether there is opposition or support within the > community to move the document to Proposed Standard as long as there is > a sufficient applicability statement included in the draft. Please > provide feedback to the mailing list (and the cc:'ed ADs) on this > proposed change. > > Regards, > Brian From phdgang@gmail.com Wed Jul 18 02:04:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9418E21F86EA; Wed, 18 Jul 2012 02:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54QaJlbd0UFG; Wed, 18 Jul 2012 02:04:25 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7721F86D5; Wed, 18 Jul 2012 02:04:25 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1018946vcb.31 for ; Wed, 18 Jul 2012 02:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U2HpjSggEpu73XsQ8365wAPDIRb3bc2BKhJMjz5IcPA=; b=Zzpfq2egKW4Q2i/Mq20ykgorH0kZG/8N1GFF4XJLJ2X2tprEIvWWlD/eCp6sue9YFG fDi9gEmZ3lDVBKLOMCTlGMgw2bNJMJGDmSCwMpunuAnrz76IOml/O9qPcGBlRquX+Dog RgOCkcsbgngf9XYJra5wiO/uogwavV592LyoAZxAqywq97PT2djVbdhVVLK0H53fOZxu leAuPbREBOcplVNyCHsEszXYzSxzYX0UIYYvj+hsLA8eTiXV0pUhAFErbjCLD8t2Qlyh /4eXJsXV/41Bacsnzthn4Lidyi96vRXVMAATQyc37ie6T4+VmiQ28NWEr0wr+O05DvhC 1EmQ== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr43127vdb.66.1342602315106; Wed, 18 Jul 2012 02:05:15 -0700 (PDT) Received: by 10.58.58.36 with HTTP; Wed, 18 Jul 2012 02:05:15 -0700 (PDT) In-Reply-To: <4FF696AA.3050508@tut.fi> References: <4FF696AA.3050508@tut.fi> Date: Wed, 18 Jul 2012 17:05:15 +0800 Message-ID: Subject: Re: draft-chen-v6ops-nat64-experience-02 From: GangChen To: Aleksi Suhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 09:04:26 -0000 cc v6ops where there is discussion on draft-chen-v6ops-nat64-experience 2012/7/6, Aleksi Suhonen : > Hi, > > We've been running a NAT64/DNS64 setup at TREX Tampere Region Exchange > for over a year now and I'd like to submit the following experience for > your draft: Your inputs are welcome. > IPv6 Privacy Extensions are a big problem with stateless NAT64. A single > device with priv exts enabled will use up several IPv4 addresses from > the NAT64 pool. And since the IPv4 Internet is full of malware probing > for vulnerabilities, the whole IPv4 address pool for the stateless NAT64 > will periodically get random traffic from the Internet. > > Even if the priv ext addresses have expired, the network will generate > an ICMPv6 unreachable message which will travel through the NAT64 device > and thus refresh timers for the IPv4 mapping. Some firewalls will also > generate TCP RST messages for such probes to non-existent IPv6 addresses. > > In fact, our worst experience has been with an Apple iPad which was left > alone in an IPv6 only WLAN which was using our DNS64 service. The iPad > thought that the WLAN was broken because it only got an IPv6 address and > no DHCPv4 response. It had time to send some packets using IPv6 through > the NAT64 which created the mapping. Then it reset its WLAN and tried to > associate with the same SSID again. Every time it created a new privacy > extension based IPv6 address and a new mapping in the stateless NAT64 > device. > > Within an hour, all the IPv4 addresses in the pool for our NAT64 were > registered to this one device. =>I may hardly understand that is a problem with stateless NAT64. RFC6145 doesn't require creating a mapping state because it's *stateless*. The package forwarding is based on mapping rules, which is nothing to do with *lifetime*. Therefore, above statement of IPv4 pool exhaustion may not apply to stateless NAT64. I suspect this problem may occur in a stateful NAT64 context. The frequent reclaiming behavior would consume unnecessary resource by creating overwhelming states on NAT64 box. Your further check is expected. > It would be my recommendation that there was either a Router > Advertisement Flags Option for "do not use privacy extensions here" and > that this was used in all setups that use DNS64 name servers, or that > all such setups should use Managed Address Configuration aka DHCPv6 > address configuration. Those potential solutions are worth to be discussed further. Especially, new added RA flags option would require additional specification efforts. Many thanks Gang > -- > Aleksi Suhonen, Researcher > Department of Communications Engineering > Tampere University of Technology > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From mcr@sandelman.ca Wed Jul 18 07:25:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5421F876D for ; Wed, 18 Jul 2012 07:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBf-XO7PLFdE for ; Wed, 18 Jul 2012 07:25:43 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 17B5621F872D for ; Wed, 18 Jul 2012 07:25:41 -0700 (PDT) Received: from sandelman.ca (herring.sandelman.ca [209.87.252.231]) by relay.sandelman.ca (Postfix) with ESMTPS id B84648252; Wed, 18 Jul 2012 10:22:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C61079811D; Wed, 18 Jul 2012 10:26:27 -0400 (EDT) Received: from herring.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C1623980DA; Wed, 18 Jul 2012 10:26:27 -0400 (EDT) From: Michael Richardson To: Aleksi Suhonen Subject: Re: draft-chen-v6ops-nat64-experience-02 In-Reply-To: <50060EB3.9060308@tut.fi> References: <4FF696AA.3050508@tut.fi> <23986.1341586765@marajade.sandelman.ca> <50060EB3.9060308@tut.fi> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 18 Jul 2012 10:26:27 -0400 Message-ID: <23978.1342621587@herring.sandelman.ca> Sender: mcr@sandelman.ca Cc: sunqiong@ctbri.com.cn, ipv6@ietf.org, niu.qibo@zte.com.cn X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:25:44 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Aleksi" =3D=3D Aleksi Suhonen writes: Aleksi> Sorry for late response. It's the summer holiday season Aleksi> here. O:-) Aleksi> On 07/06/2012 05:59 PM, Michael Richardson wrote: >> >>>>>>> "Aleksi" =3D=3D Aleksi Suhonen writes: Aleksi> Within an hour, all the IPv4 addresses in the pool for our Aleksi> NAT64 were registered to this one device. >> Do I understand that you attempt to provide a single IPv4 address >> 1:1 with a an internal IPv6 address? (NAT vs NAPT) Aleksi> Yes. Stateless Aleksi> NAT64. http://tools.ietf.org/html/rfc6144#section-3.2.1 okay, so every v6 device gets 1 IPv4. I think that few people have enough IPv4 to do this, and your research demonstrates the problems with trying to do that. I think that most will do stateful NAPT64. >> Can you tell me what your expiry time is for reclaiming the IPv4 >> address? Aleksi> 2 hours. However, anything above 5 minutes will yield the Aleksi> same result on today's Internet. And 5 minutes is too short. >> Would IPv6 ping'ing the internal device help? Aleksi> Hmm? Help with what? I'm not sure I understand you. Would it help to expire the lease faster if you did a liveness check on the IPv6 device. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAUAbHk4qHRg3pndX9AQK5lQQAqQ5AQSkm+B2mheKcOTeKc5PXTO/UCZP5 iK8rh5kSrvebtk7x3uAzwrrcgyfRvEHX6FqHk6O24bm6Wdzk6YuxLeJeogWBn9mP FNUKmUGe5o+ITYK5NCO2EWah2C5QPYj1LhydTQo2BLxuXNWi+YyJCdmYchQULGc/ e+XDBtPXDVE= =DeZe -----END PGP SIGNATURE----- --=-=-=-- From v6ops@globis.net Wed Jul 18 10:29:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24F211E8132 for ; Wed, 18 Jul 2012 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ4sqA5VyXE7 for ; Wed, 18 Jul 2012 10:29:12 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB1D611E811D for ; Wed, 18 Jul 2012 10:29:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5DA9D870049; Wed, 18 Jul 2012 19:29:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBFcex+W7cxw; Wed, 18 Jul 2012 19:29:17 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E09BF870046; Wed, 18 Jul 2012 19:29:16 +0200 (CEST) Message-ID: <5006F266.3070802@globis.net> Date: Wed, 18 Jul 2012 19:29:10 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: draft-ietf-6man-addr-select-opt@tools.ietf.org Subject: re: I-D Action: draft-ietf-6man-addr-select-opt-04.txt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 17:29:12 -0000 I have read this draft. As previously stated, I like the idea. comments & questions: Section 2: / a client MAY NOT automatically add rows to the policy table/ MAY NOT seems to contradict Section 4 /This option's concept is to serve as a hint for a node about how to behave in the network./ i.e. it's a hint not a command. Is this not then a "SHOULD NOT"? Otherwise won't we get questions about who is leading for determining end-node global behaviour, the device owner or the network operator? Or is this MAY NOT flag only valid IF the node chooses to trust and install the policy table communicated via DHCPv6? /label: An 8-bit unsigned integer;/ Is there any specification in an RFC that says ALL implementations can only handle a label of 8 bits? /precedence: An 8-bit unsigned integer;/ Is there any specification in an RFC that says that ALL implementations can only handle a precedence of 8 bits? draft-ietf-6man-rfc3484bis-06 refers to numeric comparisons, but does not appear to specify a type. I see later in Section 5: /Currently, the label and precedence values are defined as 8-bit unsigned integers. In almost all cases, this value will be enough./ How many times have I heard that about fixed length fields. What happens if it is not enough? Is it worth considering variable length labels and precedence fields? Or making them 16 bits to start with? /An IPv4-mapped address [RFC4291] must be used to represent an IPv4 address as a prefix value./ Whilst I agree with this statement, some examples in the Microsoft documentation I have read show dual entries in the policy table: one for mapped IPv4 address prefixes and one for IPv4-Compatible IPv6 address prefixes. e.g. the default policy table is shown with entries like: ::/96 20 3 ::ffff:0:0/96 10 4 Since IPv4-Compatible IPv6 addresses are deprecated, can we assume that these can be safely ignored, or not? I have always played it safe and configured both in Windows 7, so I'm not sure of underlying behaviour of the implementation and if this might change over time or versions. /The zone-index is defined in RFC 3493 [RFC3493] as 'scope ID'/ I can't find a direct reference to 'scope ID' in RFC3493. Is it 'sin6_scope_id'? That would make sense as it is defined as 32 bit integer. Section 4.3: /In other cases the node MUST NOT use Policy Table options unless the node is specifically configured to do so./ When I first read this I asked myself "is that not too draconian?" I think a document link to the definition of a "secure channel" in the Security Considerations section would answer that question effectively i.e. a signed DHCP message is considered a secure channel, regardless of the underlying transport. What about version control of the policy table itself? Is there a need for a policy-table version option like a DNS SOA serial number? I could imagine some potential corner-case problems with replay attack or race conditions, especially if the local router is acting as some sort of smart caching DHCPv6 server introducing local options. Or is that just too obscure to worry about? Thanks! RayH From fgont@si6networks.com Wed Jul 18 13:36:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B07411E8162 for ; Wed, 18 Jul 2012 13:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLWbAOXMhq1G for ; Wed, 18 Jul 2012 13:36:35 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id EA81E11E80AA for ; Wed, 18 Jul 2012 13:36:34 -0700 (PDT) Received: from [2001:5c0:1000:a::14b] by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Srazq-0007Wy-94; Wed, 18 Jul 2012 22:37:22 +0200 Message-ID: <50071E54.30708@si6networks.com> Date: Wed, 18 Jul 2012 21:36:36 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: oversized-header-chains: Receipt of illegal first-fragments X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 20:36:35 -0000 Folks, There's one issue that came up during my recent exchange with Suresh on which I'd like others (including Suresh) to weigh in: Since first-fragments that fail to include the entire header chain will be illegal, I think it would be appropriate to include an additional requirement in draft-ietf-6man-oversized-header-chain along the lines of: "A host that receives a first-fragment that fails to include the entire IPv6 header chain MUST silently drop the aforementioned fragment". Clearly, since such packets are illegal, they shouldn't exist in the first place... so dropping them makes sense. Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From vishwas.ietf@gmail.com Wed Jul 18 13:50:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2950811E80A6 for ; Wed, 18 Jul 2012 13:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-nlzw059QsC for ; Wed, 18 Jul 2012 13:50:26 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 032A011E814A for ; Wed, 18 Jul 2012 13:50:25 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1572495vcb.31 for ; Wed, 18 Jul 2012 13:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c74rvg3xSGOfZWAf0F7sOezi8DrMf/JcsxzILdBgxz0=; b=O8YJoZm+yxPHeeSNJmnjjgnt8btGVVaN9dOGHvmNXZiTguddyaAvb9HXiAvYgxYOpL hTSRIuaWOibz7bSLHapky0XnsNkr8bZ/uZ4B9M7lW4/mEJPQlYtRm3pL29jwsmspuTiZ B37EUteeaEF2xnvfaVrEqphr8c5w699hTcuajJaWSirRd3zfN47D0XW+7Tsyze2MPE4X 15n8BGcioEdJH+V7Bo76vneNgg2SggMxK5WbqGVxJWB1X0C08Gqmb1uMBEKGqkCi9+ao J6vqFwu7b0in6i/wzMnzyQtBIMp/GopxFF7EuUvAs2K5hVdMhpr2qeW4hY1QLgFuEK22 3VRA== MIME-Version: 1.0 Received: by 10.220.221.7 with SMTP id ia7mr1685760vcb.31.1342644676727; Wed, 18 Jul 2012 13:51:16 -0700 (PDT) Received: by 10.220.192.12 with HTTP; Wed, 18 Jul 2012 13:51:16 -0700 (PDT) In-Reply-To: <50071E54.30708@si6networks.com> References: <50071E54.30708@si6networks.com> Date: Wed, 18 Jul 2012 13:51:16 -0700 Message-ID: Subject: Re: oversized-header-chains: Receipt of illegal first-fragments From: Vishwas Manral To: Fernando Gont Content-Type: multipart/alternative; boundary=14dae9cfc7e604146604c520d363 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 20:50:27 -0000 --14dae9cfc7e604146604c520d363 Content-Type: text/plain; charset=ISO-8859-1 Hi Fernando, I think this is an essential message that needs to be added as part of the draft. Thanks, Vishwas On Wed, Jul 18, 2012 at 1:36 PM, Fernando Gont wrote: > Folks, > > There's one issue that came up during my recent exchange with Suresh on > which I'd like others (including Suresh) to weigh in: > > Since first-fragments that fail to include the entire header chain will > be illegal, I think it would be appropriate to include an additional > requirement in draft-ietf-6man-oversized-header-chain along the lines of: > > "A host that receives a first-fragment that fails to include the entire > IPv6 header chain MUST silently drop the aforementioned fragment". > > Clearly, since such packets are illegal, they shouldn't exist in the > first place... so dropping them makes sense. > > Thoughts? > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --14dae9cfc7e604146604c520d363 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fernando,

I think this is an essential message that needs to be a= dded as part of the draft.

Thanks,
Vishwas

On Wed, Jul 18, 2012 at 1:36 PM, Fernando Gont <fgont@si6n= etworks.com> wrote:
Folks,

There's one issue that came up during my recent exchange with Suresh on=
which I'd like others (including Suresh) to weigh in:

Since first-fragments that fail to include the entire header chain will
be illegal, I think it would be appropriate to include an additional
requirement in draft-ietf-6man-oversized-header-chain along the lines of:
"A host that receives a first-fragment that fails to include the entir= e
IPv6 header chain MUST silently drop the aforementioned fragment".

Clearly, since such packets are illegal, they shouldn't exist in the first place... so dropping them makes sense.

Thoughts?

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--14dae9cfc7e604146604c520d363-- From fred@cisco.com Wed Jul 18 14:02:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77AF11E809B for ; Wed, 18 Jul 2012 14:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.605 X-Spam-Level: X-Spam-Status: No, score=-110.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7bOH+QMdFbE for ; Wed, 18 Jul 2012 14:02:38 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9A53211E819B for ; Wed, 18 Jul 2012 14:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2703; q=dns/txt; s=iport; t=1342645408; x=1343855008; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qybPfB05uQMyy8B6CtlCY8LDWqQY0aRiad3F/+9Gyhc=; b=J2/Enp/55P0kJmHL5MA59ontunyqiR31Kj0PJessr9s3OEdv4aKN9Rq6 dDJWCTD1I53ArZxfHp+wOO0zRr9TXPS4AvFdIP2RsDRfsTyGX0bv51DlT t+tW7FJap6FSBJAUUriwh8JdHjs0sMZ3x3Ca8OeA1OFAfpBwQtsm68IS1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANAjB1CtJV2Y/2dsb2JhbAA7Crk5gQeCIAEBAQMBAQEBDwEnNAsFCwIBCA4oECcLJQIEDgUih2UGC516oCAEi0AQCoYWYAOVRI4jgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,611,1336348800"; d="scan'208";a="103183960" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jul 2012 21:03:25 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6IL3P6u029904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 21:03:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 16:03:24 -0500 From: "Fred Baker (fred)" To: Fernando Gont Subject: Re: oversized-header-chains: Receipt of illegal first-fragments Thread-Topic: oversized-header-chains: Receipt of illegal first-fragments Thread-Index: AQHNZSUtNouozLlO+0+wf0KlZ63Ba5cv2w4A Date: Wed, 18 Jul 2012 21:03:27 +0000 Message-ID: <64FE914F-4607-4B3E-A06E-D8F193A6FEF9@cisco.com> References: <50071E54.30708@si6networks.com> In-Reply-To: <50071E54.30708@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.000 x-tm-as-result: No--43.116100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:02:39 -0000 On Jul 18, 2012, at 1:36 PM, Fernando Gont wrote: > Folks, >=20 > There's one issue that came up during my recent exchange with Suresh on > which I'd like others (including Suresh) to weigh in: >=20 > Since first-fragments that fail to include the entire header chain will > be illegal, I think it would be appropriate to include an additional > requirement in draft-ietf-6man-oversized-header-chain along the lines of: >=20 > "A host that receives a first-fragment that fails to include the entire > IPv6 header chain MUST silently drop the aforementioned fragment". >=20 > Clearly, since such packets are illegal, they shouldn't exist in the > first place... so dropping them makes sense. >=20 > Thoughts? I would say "SHOULD", but I'm OK with the fundamental statement. The Robust= ness Principle has some built-in tension: "be liberal in what you accept an= d conservative in what you send" often works out to mean "accept a technica= lly-illegal message if you can work out an unambiguous intent"; what you ar= e saying is to "be strict in what you accept", which in this case is (as yo= u suggest) probably the right thing to do. The distinction between "SHOULD" and "MUST" is a little of a chinese wall. = The rule I use, which is neither specified nor universal, is that I say som= ething "MUST" be obeyed if failing to obey results in an identifiable failu= re (fragmenting a DNF packet, for example, fails in that if a recipient of = DNF fragments will refuse to reassemble them, this prevents communication t= hat was intended to be supported, so a packet marked DNF "MUST" not be frag= mented), and I use "SHOULD" when I would like to say "MUST" but can't ident= ify the failure mode and therefore might have a case in which it is inappro= priate. The argument for "MUST" in this case would be that there will be a = reasonable chance that the recommendations of the draft will not be given t= eeth apart from being "strict"; the argument for "SHOULD" is that this coul= d be handled as an exception case operationally. > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From fgont@si6networks.com Wed Jul 18 14:48:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5D011E81AD for ; Wed, 18 Jul 2012 14:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUKZxQw0o6HI for ; Wed, 18 Jul 2012 14:48:44 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 14BDD11E8132 for ; Wed, 18 Jul 2012 14:48:44 -0700 (PDT) Received: from [2001:5c0:1400:a::531] by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Src7g-0000xQ-7h; Wed, 18 Jul 2012 23:49:32 +0200 Message-ID: <50072F26.9030002@si6networks.com> Date: Wed, 18 Jul 2012 22:48:22 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Fred Baker (fred)" Subject: Re: oversized-header-chains: Receipt of illegal first-fragments References: <50071E54.30708@si6networks.com> <64FE914F-4607-4B3E-A06E-D8F193A6FEF9@cisco.com> In-Reply-To: <64FE914F-4607-4B3E-A06E-D8F193A6FEF9@cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:48:44 -0000 Hi, Fred, Thanks so much for your prompt response. Please find my comments in-line... On 07/18/2012 10:03 PM, Fred Baker (fred) wrote: >> "A host that receives a first-fragment that fails to include the >> entire IPv6 header chain MUST silently drop the aforementioned >> fragment". >> >> Clearly, since such packets are illegal, they shouldn't exist in >> the first place... so dropping them makes sense. >> >> Thoughts? > > I would say "SHOULD", but I'm OK with the fundamental statement. The > Robustness Principle has some built-in tension: "be liberal in what > you accept and conservative in what you send" often works out to mean > "accept a technically-illegal message if you can work out an > unambiguous intent"; what you are saying is to "be strict in what you > accept", which in this case is (as you suggest) probably the right > thing to do. Agreed. > The distinction between "SHOULD" and "MUST" is a little of a chinese > wall. The rule I use, which is neither specified nor universal, is > that I say something "MUST" be obeyed if failing to obey results in > an identifiable failure I've always used the same rule, but ended up reconsidering it upon suggestion of S. Braden when he noted that, as per RFC2119, a "SHOULD" implies that "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." So I guess that, from that perspective, to make it a "SHOULD" (rather than a "MUST") one should be able to come up with a good reason to accept such packets... (I should say that I've authored documents that include SHOULDs/MUSTs with your rationale, rather than the one I've just quoted) > (fragmenting a DNF packet, for example, fails > in that if a recipient of DNF fragments will refuse to reassemble > them, this prevents communication that was intended to be supported, > so a packet marked DNF "MUST" not be fragmented), (Side discussion, but just for the fun of it): Actually, I'd argue that the motivation for "MUST NOT" fragment would probably be that the Identification field is most-likely 0, and the node fragmenting the DNF packet is in no good position of selecting a good Fragment ID. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From cheshire@apple.com Wed Jul 18 15:52:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA33011E80CD for ; Wed, 18 Jul 2012 15:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id semkObitx8CE for ; Wed, 18 Jul 2012 15:52:34 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id F361111E80BA for ; Wed, 18 Jul 2012 15:52:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M7D0034QOH6IW87@mail-out.apple.com> for ipv6@ietf.org; Wed, 18 Jul 2012 15:53:13 -0700 (PDT) X-AuditID: 11807134-b7f866d000002583-2d-50073e59fad9 Received: from [17.193.13.41] (chesh1.apple.com [17.193.13.41]) by relay14.apple.com (Apple SCV relay) with SMTP id FB.87.09603.95E37005; Wed, 18 Jul 2012 15:53:13 -0700 (PDT) In-reply-to: <20120717035100.92FF9228F4FE@drugs.dv.isc.org> References: <221B8D89-0B8E-498A-9C8C-74CC3D305FD1@apple.com> <20120717035100.92FF9228F4FE@drugs.dv.isc.org> Message-id: From: Stuart Cheshire Subject: Re: draft-ietf-6man-uri-zoneid-02.txt Date: Wed, 18 Jul 2012 15:52:13 -0700 To: Mark Andrews , ipv6@ietf.org X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUieJBXUzfSjj3A4PwTRouXZ98zWVx5cZ/F gcljyZKfTB4PHr9jDmCK4rJJSc3JLEst0rdL4Mr4smQ6a8FK0YonrzvYGhh/CXQxcnJICJhI dE3dwQZhi0lcuLceyObiEBLYyCix5v9uVpAEr4CRxNXJU9lBbE4Ba4mV09+C2UIC2RJ7z68B quHgYBZwkVg4JQ+i3Ebi5MpTzCA2s4C8xPa3c8BsNgEtiRefr4DtEhbQk5j/6x47SCuLgKrE zyU8IGERAUOJzr4vTBDnyEkcPv2KcQIj3ywkR8xCWDYLyYIFjMyrGAWLUnMSKw1N9BILCnJS 9ZLzczcxggKrodBkB+PBn/yHGAU4GJV4eDv12QOEWBPLiitzDzFKcDArifA+EAQK8aYkVlal FuXHF5XmpBYfYpTmYFES591vC5QSSE8sSc1OTS1ILYLJMnFwSjUwrg14HB7WvDjp4P+4Zztm mS54oSy84PJRmRye07o6zsc3hW1Ll3OsVQ61WBXTdbiRu+3FmknTt3BH1UWazd1novNQR33P HbdtTO80luk+lFmpd8jr66vu/X7+BxTFdQP1Nvr5KLg2304v6vxq0eB0eKeCMpNKg8e27nlf NlRYWh7Q+/evqPaMEktxRqKhFnNRcSIAsq34rigCAAA= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:52:36 -0000 On 16 Jul, 2012, at 20:50, Mark Andrews wrote: > Stuart, > your mail client botched the Content-type line generation. > You may want to report it. > > Content-type: image/png; x-unix-mode=0644; name=Whatis' > "?.png"="" > Content-transfer-encoding: base64 > Content-disposition: inline; filename="What is ' ?.png" > > Mark Mark, your tone sounds very confident that you're absolutely certain that you know exactly what botched what, and whose fault it is. I'll reserve judgement until I actually know what happened, but what I can tell you is this: Viewing the outgoing TCP packets with tcpflow, this is what my mail client sends on-the-wire to the SMTP relay: Content-Transfer-Encoding: base64 Content-Type: image/png; x-unix-mode=0644; name=What is ' ?.png Content-Disposition: inline; filename="What is ' ?.png" By the time you received the email, Mark, it had been rewritten to the form you showed. As to what intermediary (or intermediaries) contributed to that rewriting, I do not yet know. It's ironic that this problem occurs in the midst of a discussion of the problems of escaping and message framing. The reality seems to be that unless we keep things supremely simple, we can't hope to have all programmers get it right in all cases. If there's exactly one valid form for a string, then maybe we can hope to have that implemented properly. When there are different representations of the same string in different contexts, the probability of everyone getting it right in all contexts pretty much approaches zero. Slightly off-topic, I'm told that at least some mail clients truncated my original email at the line "unintentionally leaked through into the user interface." As composed on my Mac, there was some introductory text, then two images, then the bulk of the text, as it appears in the archive: Apparently some mail clients turned the second chunk of body text into an attachment. I'm curious as to how widespread this issue is -- I might have to be more careful about where I put images in my email messages in the future. Could people send me a quick private email saying what mail client they use and whether it: 1. Showed the entire message as I composed it with the two images displayed in-line (like the archive). 2. Showed the entire text of the message, but with the two images as attachments (Gmail shows it this way). 3. Showed only the first five paragraphs of text, with the two images and remaining text as attachments. I'll summarize results to the list. Stuart Cheshire From marka@isc.org Wed Jul 18 17:42:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67311E81D6 for ; Wed, 18 Jul 2012 17:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-zi5p5DHCpL for ; Wed, 18 Jul 2012 17:42:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 84BBC11E81D5 for ; Wed, 18 Jul 2012 17:42:17 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 67E7BC95B9; Thu, 19 Jul 2012 00:43:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1c27:6a6c:c6b:b42b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 34581216C36; Thu, 19 Jul 2012 00:42:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 924F022AE699; Thu, 19 Jul 2012 10:42:52 +1000 (EST) To: Stuart Cheshire From: Mark Andrews References: <221B8D89-0B8E-498A-9C8C-74CC3D305FD1@apple.com> <20120717035100.92FF9228F4FE@drugs.dv.isc.org> Subject: Re: draft-ietf-6man-uri-zoneid-02.txt In-reply-to: Your message of "Wed, 18 Jul 2012 15:52:13 MST." Date: Thu, 19 Jul 2012 10:42:52 +1000 Message-Id: <20120719004252.924F022AE699@drugs.dv.isc.org> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 00:42:19 -0000 In message , Stuart Cheshire wr ites: > On 16 Jul, 2012, at 20:50, Mark Andrews wrote: > > > Stuart, > > your mail client botched the Content-type line generation. > > You may want to report it. > > > > Content-type: image/png; x-unix-mode=0644; name=Whatis' > > "?.png"="" > > Content-transfer-encoding: base64 > > Content-disposition: inline; filename="What is ' ?.png" > > > > Mark > > Mark, your tone sounds very confident that you're absolutely certain > that you know exactly what botched what, and whose fault it is. > > I'll reserve judgement until I actually know what happened, but what > I can tell you is this: Viewing the outgoing TCP packets with > tcpflow, this is what my mail client sends on-the-wire to the SMTP > relay: > > Content-Transfer-Encoding: base64 > Content-Type: image/png; > x-unix-mode=0644; > name=What is ' ?.png > Content-Disposition: inline; > filename="What is ' ?.png" Which isn't a syntactically valid Content-Type header (RFC 1341). > By the time you received the email, Mark, it had been rewritten to > the form you showed. As to what intermediary (or intermediaries) > contributed to that rewriting, I do not yet know. It may have been re-written but Garbage In - Garbage Out. > It's ironic that this problem occurs in the midst of a discussion of > the problems of escaping and message framing. The reality seems to be > that unless we keep things supremely simple, we can't hope to have > all programmers get it right in all cases. If there's exactly one > valid form for a string, then maybe we can hope to have that > implemented properly. When there are different representations of the > same string in different contexts, the probability of everyone > getting it right in all contexts pretty much approaches zero. It was slightly ironic. > Slightly off-topic, I'm told that at least some mail clients > truncated my original email at the line "unintentionally leaked > through into the user interface." > > As composed on my Mac, there was some introductory text, then two > images, then the bulk of the text, as it appears in the archive: > > > > Apparently some mail clients turned the second chunk of body text > into an attachment. > > I'm curious as to how widespread this issue is -- I might have to be > more careful about where I put images in my email messages in the > future. > > Could people send me a quick private email saying what mail client > they use and whether it: > > 1. Showed the entire message as I composed it with the two images > displayed in-line (like the archive). > 2. Showed the entire text of the message, but with the two images as > attachments (Gmail shows it this way). > 3. Showed only the first five paragraphs of text, with the two images > and remaining text as attachments. > > I'll summarize results to the list. > > Stuart Cheshire > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From evyncke@cisco.com Wed Jul 18 23:20:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD6021F85B1 for ; Wed, 18 Jul 2012 23:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.404 X-Spam-Level: X-Spam-Status: No, score=-10.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV4Mxr6geE8T for ; Wed, 18 Jul 2012 23:20:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 95FB121F85AE for ; Wed, 18 Jul 2012 23:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=2050; q=dns/txt; s=iport; t=1342678892; x=1343888492; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JvneJgQxB3HpL9VgG1QWwFoioS84/BrkkQfK+Er0dec=; b=EgSFSrMdnFax5kFHM977+JNjWAThyQAYOkmRePlgFfXwCLAfpC9i7STW Y/OpiFEcVMaitP5fJ5emvOAlfoc2llPxnIkyloWU/8lRCUJLDc81JvLM2 lO0312KulLjuS5lC3Qif2Vq2VMpHBr5XMsQyPtiOVeBmnwE1ifUmIx6st g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMWmB1CtJV2c/2dsb2JhbABFuUuBB4IgAQEBBAEBAQ8BWxcEAgEIDgMEAQELHQcnCxQJCAIEARIIGodrC54poAgEi0AahhZgA4gYm0+BZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,614,1336348800"; d="scan'208";a="103300794" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jul 2012 06:21:31 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6J6LVVX006138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 06:21:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.178]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 01:21:31 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont , "ipv6@ietf.org" Subject: RE: oversized-header-chains: Receipt of illegal first-fragments Thread-Topic: oversized-header-chains: Receipt of illegal first-fragments Thread-Index: AQHNZSUt5qYdYs0kXkeuVTjXE3Qt/JcwIfAg Date: Thu, 19 Jul 2012 06:21:31 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E10519F4@xmb-aln-x02.cisco.com> References: <50071E54.30708@si6networks.com> In-Reply-To: <50071E54.30708@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--41.400600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 06:20:41 -0000 Fernando, Adding this text has the merit of being clear. Two comments: 1) for the transition period (when we could perhaps see those packets -- ev= en if I have yet to see one!), 'silently' is perhaps too strong, I would su= ggest at the bare minimum a dropped packet counter (else operators would be= blind) 2) RFC1858 (the IPv4 equivalent of your I-D) specifies that routers with an= ACL must also drop those packets and I would think that this should also b= e the case here but with a SHOULD for router implementing layer-4 ACL (not = for plain forwarding routers or layer-3 ACL) Hope it helps -=E9ric > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: mercredi 18 juillet 2012 22:37 > To: ipv6@ietf.org > Subject: oversized-header-chains: Receipt of illegal first-fragments >=20 > Folks, >=20 > There's one issue that came up during my recent exchange with Suresh on > which I'd like others (including Suresh) to weigh in: >=20 > Since first-fragments that fail to include the entire header chain will b= e > illegal, I think it would be appropriate to include an additional > requirement in draft-ietf-6man-oversized-header-chain along the lines of: >=20 > "A host that receives a first-fragment that fails to include the entire > IPv6 header chain MUST silently drop the aforementioned fragment". >=20 > Clearly, since such packets are illegal, they shouldn't exist in the firs= t > place... so dropping them makes sense. >=20 > Thoughts? >=20 > Thanks! >=20 > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Thu Jul 19 06:59:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F6721F869E for ; Thu, 19 Jul 2012 06:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIgeY0MTzHr3 for ; Thu, 19 Jul 2012 06:59:38 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7F21F869D for ; Thu, 19 Jul 2012 06:59:38 -0700 (PDT) Received: from [2001:5c0:1400:a::1a1] by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SrrHE-0003Bi-N6; Thu, 19 Jul 2012 16:00:24 +0200 Message-ID: <500812D3.3090000@si6networks.com> Date: Thu, 19 Jul 2012 14:59:47 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" Subject: Re: oversized-header-chains: Receipt of illegal first-fragments References: <50071E54.30708@si6networks.com> <97EB7536A2B2C549846804BBF3FD47E10519F4@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E10519F4@xmb-aln-x02.cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:59:39 -0000 Hi, Eric, On 07/19/2012 07:21 AM, Eric Vyncke (evyncke) wrote: > Two comments: 1) for the transition period (when we could perhaps see > those packets -- even if I have yet to see one!), 'silently' is > perhaps too strong, I would suggest at the bare minimum a dropped > packet counter (else operators would be blind) Ok. What about the counter? SHOULD? > 2) RFC1858 (the IPv4 > equivalent of your I-D) specifies that routers with an ACL must also > drop those packets and I would think that this should also be the > case here but with a SHOULD for router implementing layer-4 ACL (not > for plain forwarding routers or layer-3 ACL) The caveat here is that it's trivial for a v4 router to figure out whether the upper layer protocol's header is fragmented, but it may be not so trivial for a v6 router to do so (i.e., it would require them to follow the entire IPv6 header chain, which could possibly be a large number of headers. That said, I guess that including the aforementioned requirement for routers, with the granularity you mention ("routers implementing layer-4 ACLs" or some equivalent wording) might work for the wg? Can others please weigh in? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Thu Jul 19 11:33:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DB721F8690 for ; Thu, 19 Jul 2012 11:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCwc9q1u3rnU for ; Thu, 19 Jul 2012 11:33:05 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5CA321F864E for ; Thu, 19 Jul 2012 11:33:04 -0700 (PDT) Received: by qcac10 with SMTP id c10so2061577qca.31 for ; Thu, 19 Jul 2012 11:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=e/PRjJqDN0To4PZjCCYHgoxqo3nbS7XDAdWd63T0WHo=; b=Ds8Rces80AK1Ud79NiUwJ5TwYDN5W87FTvzHf49OD3u+maquUJbPeu0/+OalX9D7EO XY6odbmfIwdNVwmeXrZvj7KP8MDjo2fm/JUK1NLTjZh9fn7z41Pi9tWXjP2dRQmrUpfQ f+mWz/0gaFfo1XbkKl+acFoVMLuS10e7iG6TYF9kHirqkayN6wAFnhl7Pzuto/1owJxk ibDrBnmaA5bynLsqTDOhSlc3S+POhkg8jlqf9wTXZDTtXpO1TtEwSXlpsXFpkxtMS1OR bUQN1l+9O+7ifkwWVOx1W38VAZAOE1Y29pOAgp9fftBEFGi+2Mz0wrXT6/5e6F4AUnCn 8QRw== Received: by 10.224.174.143 with SMTP id t15mr5501793qaz.15.1342722838386; Thu, 19 Jul 2012 11:33:58 -0700 (PDT) Received: from [10.30.20.12] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id f14sm3535062qak.20.2012.07.19.11.33.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 11:33:57 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: oversized-header-chains: Receipt of illegal first-fragments Date: Thu, 19 Jul 2012 14:33:55 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:33:05 -0000 OPINION/BELIEF: I concur with Fred Baker's analysis of "SHOULD" versus "MUST". I think the requirement that a packet that violates the proposed oversized-heacer-chain rule be dropped "silently" is too strong and lacks operational flexibility. A device ought to be allowed, but not required, to send an ICMPv6 Parameter Problem message if/when it drops such a packet. In some situations, it might be desirable for a device to drop the packet AND also generate an ICMPv6 "Parameter Problem" message for the packet originator. ACTIONABLE SUGGESTIONS: So.... 1) I'd prefer this draft say that such illegal packets MUST be dropped, but then also say that the device dropping the packet MAY send an ICMPv6 Parameter Problem control message back to the (alleged) sending node. A brief sentence suggesting, but not requiring, that implementations make the sending of the ICMPv6 message configurable also would be sensible. and 2) For the situation where an IPv6 packet is dropped for this specific reason, I'd suggest that the "Reason Code" registry for an ICMPv6 "Type 4 - Parameter Problem" message be updated with a new focused reason code defined. As a straw man, I'd propose adding this new entry to that registry, as part of this proposal: CODE NAME/DESCRIPTION 3 IPv6 Initial Fragment missing upper-layer protocol header Of course, this means an "IANA Considerations" section update for the I-D would be in order. and 3) I'd also suggest a sentence or two clarifying that the ICMPv6 "Parameter Problem" with the new Reason Code is the appropriate message to send -- if the device dropping the packet with oversized-header-chain sends an ICMPv6 message. One would hope this would be obvious, but being very clear is good. and 4) Security Considerations ought to note the importance of deploying Source Address Forgery Prevention filters, in order to reduce the threat of an adversary forging an illegal packet with contains a victim/target's IP address in the Source IPv6 Address field of the illegal packet. [RFC-2827, RFC-3704] Yours, Ran From fgont@si6networks.com Thu Jul 19 12:21:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0121F8737 for ; Thu, 19 Jul 2012 12:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pu1lqaz5-sr for ; Thu, 19 Jul 2012 12:21:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DA33021F871D for ; Thu, 19 Jul 2012 12:21:40 -0700 (PDT) Received: from 132.66.37.188.rev.vodafone.pt ([188.37.66.132] helo=[10.0.0.196]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SrwIr-0003RU-HO; Thu, 19 Jul 2012 21:22:30 +0200 Message-ID: <50085DE8.2060906@si6networks.com> Date: Thu, 19 Jul 2012 20:20:08 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: oversized-header-chains: Receipt of illegal first-fragments References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 19:21:47 -0000 Hi, Ran, As always, thanks so much for your feedback and elaborated comments. Please find my response in-line... On 07/19/2012 07:33 PM, RJ Atkinson wrote: > I think the requirement that a packet that violates the > proposed oversized-heacer-chain rule be dropped "silently" > is too strong and lacks operational flexibility. FWIW, when I said "silently", I didn't meant to stress it. My point was about including a requirement to drop such packets, than whether they should be silently dropped, a counter incremented, etc. > A device ought to be allowed, but not required, to send > an ICMPv6 Parameter Problem message if/when it drops > such a packet. > > In some situations, it might be desirable for a device > to drop the packet AND also generate an ICMPv6 > "Parameter Problem" message for the packet originator. Agreed. > 1) I'd prefer this draft say that such illegal packets MUST > be dropped, but then also say that the device dropping the > packet MAY send an ICMPv6 Parameter Problem control message > back to the (alleged) sending node. A brief sentence > suggesting, but not requiring, that implementations make > the sending of the ICMPv6 message configurable also would be > sensible. Should we make this latter bit (about this being configurable) a MAY, or would you prefer to have non-RFC2119 language? > 2) For the situation where an IPv6 packet is dropped for this > specific reason, I'd suggest that the "Reason Code" registry > for an ICMPv6 "Type 4 - Parameter Problem" message be updated > with a new focused reason code defined. As a straw man, > I'd propose adding this new entry to that registry, > as part of this proposal: > > CODE NAME/DESCRIPTION > 3 IPv6 Initial Fragment missing upper-layer protocol header > > Of course, this means an "IANA Considerations" section > update for the I-D would be in order. I find your suggestion acceptable. Can others please weigh in? Minor note: May be the description for the error code should be along the lines of "IPv6 First Fragment missing entire IPv6 header chain"? (I'm just thinking of IPv6 packets with no upper layer protocol, which would remain legal, but would not have an "upper layer protocol header") > 3) I'd also suggest a sentence or two clarifying that the > ICMPv6 "Parameter Problem" with the new Reason Code > is the appropriate message to send -- if the device dropping > the packet with oversized-header-chain sends an ICMPv6 > message. One would hope this would be obvious, but being > very clear is good. Ok. > 4) Security Considerations ought to note the importance of > deploying Source Address Forgery Prevention filters, in > order to reduce the threat of an adversary forging an > illegal packet with contains a victim/target's IP address > in the Source IPv6 Address field of the illegal packet. > [RFC-2827, RFC-3704] I have no problem with this. However, should we really elaborate on this topic, since it applies to all ICMPv6 error messages and hence is probably a topic belonging to e.g. RFC 4443? Thanks so much, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Thu Jul 19 13:03:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37E521F86D9 for ; Thu, 19 Jul 2012 13:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lVUkzOyG5GZ for ; Thu, 19 Jul 2012 13:03:19 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8A21F869D for ; Thu, 19 Jul 2012 13:03:19 -0700 (PDT) Received: by qaea16 with SMTP id a16so1957373qae.10 for ; Thu, 19 Jul 2012 13:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ibYHnn1Op48+RT9MPuEq69flENHKQds1t1i1KrgE97Q=; b=IVai2IxOgXLmukge7IpatnAXZL+yCJfEvjI87kVebAq+O9bdNiMHH5/pA1y9cA9ZOU j+ILOLF4WcFVd0+1TniGHygmYS+edTg0RFLqnEf5gXxp5xdNNHDZl3ByaLv+XENOT7Js YbF04Jwwskgsp7mn1gQ7w5tFwT6iBIuLNrFCH6k7ww6R3TF0Zw5MiNO3B3Vzm3bTImIv K3dNlHtM5AF9DcPB4RxFyD46KnOqea1tiQEkK1cH5EQQZ4M06u/gv10Xsi8RYjWFRGGy R4PRsakD343rPDn5W+EFrOO+K2cFKXvEkQTgmhRsHDRIxQ40CVvKSdshfgglbXdVsh1F FgbQ== Received: by 10.229.136.14 with SMTP id p14mr1487152qct.93.1342728252716; Thu, 19 Jul 2012 13:04:12 -0700 (PDT) Received: from [10.30.20.12] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id he6sm3699306qab.13.2012.07.19.13.04.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 13:04:12 -0700 (PDT) Subject: Re: oversized-header-chains: Receipt of illegal first-fragments Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: RJ Atkinson In-Reply-To: <50085DE8.2060906@si6networks.com> Date: Thu, 19 Jul 2012 16:04:10 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <50085DE8.2060906@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1278) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:03:20 -0000 On 19 Jul 2012, at 15:20 , Fernando Gont wrote: >> 1) I'd prefer this draft say that such illegal packets MUST >> be dropped, but then also say that the device dropping the >> packet MAY send an ICMPv6 Parameter Problem control message >> back to the (alleged) sending node. A brief sentence >> suggesting, but not requiring, that implementations make >> the sending of the ICMPv6 message configurable also would be >> sensible. > > Should we make this latter bit (about this being configurable) > a MAY, or would you prefer to have non-RFC2119 language? I believe this configurability is really desirable. It isn't a big burden for an implementer, as it is simply an on/off flag, but we don't want to require it. So I would suggest either use "SHOULD support configuration of whether an ICMPv6 error/diagnostic message is sent" (edit to preference) OR (more simply) avoid using RFC21109 ALL-CAPS wording and still urge that implementers support this as a configurable setting as part of supporting "local operational policy". > 2) For the situation where an IPv6 packet is dropped for this >> specific reason, I'd suggest that the "Reason Code" registry >> for an ICMPv6 "Type 4 - Parameter Problem" message be updated >> with a new focused reason code defined. As a straw man, >> I'd propose adding this new entry to that registry, >> as part of this proposal: >> >> CODE NAME/DESCRIPTION >> 3 IPv6 Initial Fragment missing upper-layer protocol header >> >> Of course, this means an "IANA Considerations" section >> update for the I-D would be in order. > > I find your suggestion acceptable. Can others please weigh in? > > Minor note: May be the description for the error code should be along > the lines of "IPv6 First Fragment missing entire IPv6 header chain"? > (I'm just thinking of IPv6 packets with no upper layer protocol, which > would remain legal, but would not have an "upper layer protocol header") I don't object to the rephrasing of the name/description. Ideally the name/description field is relatively short. >> 4) Security Considerations ought to note the importance of >> deploying Source Address Forgery Prevention filters, in >> order to reduce the threat of an adversary forging an >> illegal packet with contains a victim/target's IP address >> in the Source IPv6 Address field of the illegal packet. >> [RFC-2827, RFC-3704] > > I have no problem with this. > However, should we really elaborate on this topic, > since it applies to all ICMPv6 error messages and > hence is probably a topic belonging to e.g. RFC 4443? I think a brief reminder here is appropriate, in part because this draft increases the attack surface a bit, by making illegal a previously-valid, if very odd, IPv6 packet construct. I would not object to including the phrase "...as with all ICMPv6 error/diagnostic messages..." as part of that brief description of the concern. Cheers, Ran From fgont@si6networks.com Thu Jul 19 16:46:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FABC11E80E0 for ; Thu, 19 Jul 2012 16:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTHQ7hN0hfCr for ; Thu, 19 Jul 2012 16:46:06 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id ECB8D11E80CA for ; Thu, 19 Jul 2012 16:46:05 -0700 (PDT) Received: from [2001:5c0:1400:a::12b] by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Ss0Qq-00034R-Gm; Fri, 20 Jul 2012 01:46:56 +0200 Message-ID: <50089C45.1020305@si6networks.com> Date: Fri, 20 Jul 2012 00:46:13 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: oversized-header-chains: Receipt of illegal first-fragments References: <50085DE8.2060906@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 23:46:06 -0000 Hi, Ran, On 07/19/2012 09:04 PM, RJ Atkinson wrote: >> Should we make this latter bit (about this being configurable) >> a MAY, or would you prefer to have non-RFC2119 language? > > I believe this configurability is really desirable. > It isn't a big burden for an implementer, as it is > simply an on/off flag, but we don't want to require it. > > So I would suggest either use "SHOULD support configuration of > whether an ICMPv6 error/diagnostic message is sent" (edit to preference) > OR (more simply) avoid using RFC21109 ALL-CAPS wording and > still urge that implementers support this as a configurable > setting as part of supporting "local operational policy". Ok. I will craft some text, and post it to the list for review... >>> 4) Security Considerations ought to note the importance of >>> deploying Source Address Forgery Prevention filters, in >>> order to reduce the threat of an adversary forging an >>> illegal packet with contains a victim/target's IP address >>> in the Source IPv6 Address field of the illegal packet. >>> [RFC-2827, RFC-3704] >> >> I have no problem with this. >> However, should we really elaborate on this topic, >> since it applies to all ICMPv6 error messages and >> hence is probably a topic belonging to e.g. RFC 4443? > > I think a brief reminder here is appropriate, in part > because this draft increases the attack surface a bit, > by making illegal a previously-valid, if very odd, > IPv6 packet construct. Ok. As with the above, I will craft some text and send it to the list for review. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From cheshire@apple.com Thu Jul 19 23:18:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBDA21F85A2 for ; Thu, 19 Jul 2012 23:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTTP_EXCESSIVE_ESCAPES=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhKMaxRS8S5p for ; Thu, 19 Jul 2012 23:18:29 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6A50121F8585 for ; Thu, 19 Jul 2012 23:18:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M7G00D8Q45PB17B@mail-out.apple.com> for ipv6@ietf.org; Thu, 19 Jul 2012 23:19:11 -0700 (PDT) X-AuditID: 11807112-b7f796d000000feb-ee-5008f85f3238 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 28.3D.04075.F58F8005; Thu, 19 Jul 2012 23:19:11 -0700 (PDT) Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M7G00FQS47YDD30@koseret.apple.com> for ipv6@ietf.org; Thu, 19 Jul 2012 23:19:11 -0700 (PDT) Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt From: Stuart Cheshire In-reply-to: <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 19 Jul 2012 23:20:13 -0700 Message-id: <42C2E69E-A5E3-492A-A857-C910237CD30D@apple.com> References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OXTf+B0eAwZrtKhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuJHq5kLWlgrps1oZ2pgnMbSxcjJISFgIvH7QCcrhC0mceHe erYuRi4OIYFOJolLp2YyQTgHmST+z3sPVMXBISzgJXHmSQ5IA6+AoUTHuqPsIDazgJbE+p3H mUBsNiD7xecrbCA2p0C+xI/ph8EWsAioSizuXMUMUW8gcfzDR6hebYkn7y6AjecVsJFo600D CQsJLGaUODjXAcQWEVCX2PdjHwtIiYSArETTsowJjAKzkBwxC8kRs5AMXcDIvIpRsCg1J7HS 0FwvsaAgJ1UvOT93EyMo7BoKhXYw3t+ld4hRgINRiYd3YhJHgBBrYllxZe4hRgkOZiUR3hkf gEK8KYmVValF+fFFpTmpxYcYpTlYlMR5Xz8GSgmkJ5akZqemFqQWwWSZODilGhiFp5usqX19 uOWIyvp83x+1XVO2b3ubfeidcTfLjU3hPHLN4j587LLTEhhKG2dbGPyMi1To6Lz5dZKeTuqO 99mcH/R51yltPq37pmSCjK7lpw1B3cUiuXtW5X9VzfxwWapl4+Tf5/dOPh0ddvXbrqyArKJZ SdKWq9Q3qtVuVe7I2efg37xln68SS3FGoqEWc1FxIgCUbyhLNwIAAA== Cc: "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 06:18:30 -0000 On 5 Jul 2012, at 18:28, Dave Thaler wrote: > You'll see at > http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=vs.85).aspx > that alternative 3 is what is supported in IE7 and above, and the APIs are generally > available to Windows applications (i.e. not just IE7). Surely Dave, in the spirit of escaping characters that really didn't need to be escaped, you could have been a bit more creative with the URL :-) Maybe something like this? Stuart Cheshire From bill.jouris@insidethestack.com Sat Jul 21 03:37:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7164421F8672 for ; Sat, 21 Jul 2012 03:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3zD5Dy6fo-J for ; Sat, 21 Jul 2012 03:37:14 -0700 (PDT) Received: from nm4-vm0.access.bullet.mail.sp2.yahoo.com (nm4-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.110]) by ietfa.amsl.com (Postfix) with SMTP id 6A28021F848B for ; Sat, 21 Jul 2012 03:37:14 -0700 (PDT) Received: from [98.139.44.103] by nm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 21 Jul 2012 10:38:11 -0000 Received: from [98.139.44.70] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 21 Jul 2012 10:38:11 -0000 Received: from [127.0.0.1] by omp1007.access.mail.sp2.yahoo.com with NNFMP; 21 Jul 2012 10:38:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 207928.47576.bm@omp1007.access.mail.sp2.yahoo.com Received: (qmail 90554 invoked by uid 60001); 21 Jul 2012 10:38:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1342867090; bh=XinFNPhunM4kUXzZz+0O2B+vwfwWa6VFwslMjNoxePM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=N89tiKAqovuVE34pUKkoQzYlQHzIXXmnrvdygV1SCojKnXdSWsDc2fRSjWO1d8D8uA43sdPI9A/h0GCWBfeokSEKS2vt3E5T4JJytlo8GsJVRzSZ/bPJ2b4+FNi0wufJPvYNJfsEwc5d4u+LPjtjV6yH/qPyvXF1IhHpxfqDV6o= X-YMail-OSG: P1nvWswVM1k3TSjyT5r9FFHBPBC4DYs6SmEFpteA4O5po6o TOwtvLFB7GF3rMMROEnHO8WCl2vBeBq2x7RKX3Nl2z6i6D6jkEXD4_JIRea4 50D2nPziASS.T6.xriJ0vO.ZSduDvkq15LEawEkLoQ_y7NqaE5HftdTG9gkA 4vw3Li7JeZ.NHuJThLWZdebwxvjQ9bKwZ5IGU1MH2cWHepKLpvjTzN_ZT9NX tBZRBwNdzYjE6NfBNsOnBz2wbwtvbr2THyh1TNl04ErT2OfCENmHhkSVlaah qxEtOpoLXnjPYQnaOskS7HHhF5OZr58NV4NjwU6lAshu2rAvx5kFbpxwelJe 4Upn9DzGXLcfkVxtvEMts0fPNGjQp9c_ox0tSW2wGnL8Bj3maO8.DKjf_6aA kFTFc0hv_mbTUQ3ypkvQtObVuMptCBflxPF0twd_O1JVyLa9WJDyKtoAUpt6 aaS5uSfSHRXwlGPCmoo0AO2s3yLBOM2umnuTTRIZPcMzNVfSCpM3VhHvEpKq C2Oq40EOPbNRuwq3EGJc5bC6lW8GPQjUWk6Nhl5yYez85_GUjRnE0IZ78tTO oowyyqXthh.4- Received: from [64.134.241.153] by web2811.biz.mail.ne1.yahoo.com via HTTP; Sat, 21 Jul 2012 03:38:10 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.120.356233 Message-ID: <1342867090.80463.YahooMailClassic@web2811.biz.mail.ne1.yahoo.com> Date: Sat, 21 Jul 2012 03:38:10 -0700 (PDT) From: Bill Jouris Subject: Re: oversized-header-chains: Receipt of illegal first-fragments To: ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-759923333-1771573322-1342867090=:80463" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 10:37:15 -0000 ---759923333-1771573322-1342867090=:80463 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Thu, 7/19/12, Fernando Gont wrote: =0A=0A>>On 07/19/2012 07:33 PM, RJ Atkinson wrote: =0A=0A>> I think the requirement that a packet that violates the =0A=0A>> proposed oversized-heacer-chain rule be dropped "silently"=20 =0A=0A>> is too strong and lacks operational flexibility. =0A=0A> =0A=0A>FWIW, when I said "silently", I didn't meant to stress it. My point = was =0A=0A>about including a requirement to drop such packets, than whether the= y =0A=0A>should be silently dropped, a counter incremented, etc. =0A=0A> =0AThere are few things more frustrating, when trying to analyze a problem,= than a =0Asituation where something happened with no fingerprints left behind.=A0 = Not to mention =0Athat having no record makes actually finding and fixing the original pro= blem =0Amuch more difficult.=A0 Not only should there be some kind of record abo= ut what=20 =0Ahappened, the more information we can provide about why it happened the =0Abetter. =0A=0A> =0A=0A>> A device ought to be allowed, but not required, to send=20 =0A=0A> >an ICMPv6 Parameter Problem message if/when it drops=20 =0A=0A> >such a packet. =0A=0A>>=20 =0A=0A> >In some situations, it might be desirable for a device =0A=0A> >to drop the packet AND also generate an ICMPv6=20 =0A=0A> >"Parameter Problem" message for the packet originator.=20 =0A=0A> =0A=0A>Agreed. =0A=0A> =0AAs above: the more we information we can provide to the poor guy =0Atrying to find and fix the problem, the better. =0A=0A> =0A=0A>> 1) I'd prefer this draft say that such illegal packets MUST=20 =0A=0A>>=A0 =A0 be dropped, but then also say that the device dropping the= =20 =0A=0A>>=A0 =A0 packet MAY send an ICMPv6 Parameter Problem control message= =20 =0A=0A>>=A0 =A0 back to the (alleged) sending node.=A0 A brief sentence=20 =0A=0A> > =A0 suggesting, but not requiring, that implementations make=20 =0A=0A>>=A0 =A0 the sending of the ICMPv6 message configurable also would b= e=20 =0A=0A>>=A0 =A0 sensible. =0A=0A> =0A=0A>Should we make this latter bit (about this being configurable) a MAY= , or =0A=0A>would you prefer to have non-RFC2119 language? =0A=0A> =0A> =0A=0A> =0A=0A>> 2) For the situation where an IPv6 packet is dropped for this =0A=0A>>=A0 =A0 specific reason, I'd suggest that the "Reason Code" registr= y=20 =0A=0A> > =A0 for an ICMPv6 "Type 4 - Parameter Problem" message be updated =0A=0A>>=A0 =A0 with a new focused reason code defined.=A0 As a straw man,= =20 =0A=0A>>=A0 =A0 I'd propose adding this new entry to that registry,=20 =0A=0A> > =A0 as part of this proposal: =0A=0A>>=20 =0A=0A>>=A0 =A0 CODE=A0 =A0=A0=A0NAME/DESCRIPTION =0A=0A>>=A0 =A0 =A0 3=A0 =A0 =A0 IPv6 Initial Fragment missing upper-layer = protocol header =0A=0A> > =0A=0A>>=A0 =A0=A0=A0Of course, this means an "IANA Considerations" section =0A=0A>>=A0 =A0=A0 update for the I-D would be in order. =0A=0A> =0A=0A>I find your suggestion acceptable. Can others please weigh in? =0A=0A> =0A=0A>Minor note: May be the description for the error code should be alon= g =0A=0A>the lines of "IPv6 First Fragment missing entire IPv6 header chain"? =0A=0A>(I'm just thinking of IPv6 packets with no upper layer protocol, whi= ch =0A=0A>would remain legal, but would not have an "upper layer protocol head= er") =0A=0A> =0A> =0A=0A> =0A=0A>> 3) I'd also suggest a sentence or two clarifying that the =0A=0A>>=A0 =A0 ICMPv6 "Parameter Problem" with the new Reason Code =0A=0A>>=A0 =A0 is the appropriate message to send -- if the device droppin= g =0A=0A>>=A0 =A0 the packet with oversized-header-chain sends an ICMPv6 =0A=0A>> =A0 message.=A0 One would hope this would be obvious, but being =0A=0A>>=A0 =A0 very clear is good. =0A=0A> =0A=0A>Ok. =0A=0A> =0A=0AI'm not invested in HOW we provide feedback.=A0 But THAT we provide t= he =0A=0A=0Ainformation as clearly as possible.=A0 Something that says explici= tly to the=20 =0A=0Auser: "oversize-header-chain -- illegal first fragment received"=A0 T= he user needs to=20 know exactly what went wrong that got the packet dropped. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) ---759923333-1771573322-1342867090=:80463 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
--- On Thu, 7/19/12, Fernando Gont <= fgont@si6networks.com> wrote:
=0A=0A>>On 07/19/2012 07:= 33 PM, RJ Atkinson wrote:
=0A=0A>> I think the requirement that a = packet that violates the
=0A=0A>> proposed oversized-heacer-chain = rule be dropped "silently"
=0A=0A>> is too strong and lacks opera= tional flexibility.
=0A=0A>
=0A=0A>FWIW, when I said "silently"= , I didn't meant to stress it. My point was
=0A=0A>about including a = requirement to drop such packets, than whether they
=0A=0A>should be = silently dropped, a counter incremented, etc.
=0A=0A>
=0AThere are= few things more frustrating, when trying to analyze a problem, than a
= =0Asituation where something happened with no fingerprints left behind.&nbs= p; Not to mention
=0Athat having no record makes actually finding and fi= xing the original problem
=0Amuch more difficult.  Not only should = there be some kind of record about what
=0Ahappened, the more informati= on we can provide about why it happened the
=0Abetter.
=0A=0A>
= =0A=0A>> A device ought to be allowed, but not required, to send
= =0A=0A> >an ICMPv6 Parameter Problem message if/when it drops
=0A= =0A> >such a packet.
=0A=0A>>
=0A=0A> >In some sit= uations, it might be desirable for a device
=0A=0A> >to drop the p= acket AND also generate an ICMPv6
=0A=0A> >"Parameter Problem" me= ssage for the packet originator.
=0A=0A>
=0A=0A>Agreed.
=0A= =0A>
=0AAs above: the more we information we can provide to the poor = guy
=0Atrying to find and fix the problem, the better.
=0A=0A>
= =0A=0A>> 1) I'd prefer this draft say that such illegal packets MUST =
=0A=0A>>    be dropped, but then also say that the devi= ce dropping the
=0A=0A>>    packet MAY send an ICMPv6 P= arameter Problem control message
=0A=0A>>    back to th= e (alleged) sending node.  A brief sentence
=0A=0A> >  = suggesting, but not requiring, that implementations make
=0A=0A>>= ;    the sending of the ICMPv6 message configurable also would be=
=0A=0A>>    sensible.
=0A=0A>
=0A=0A>Shoul= d we make this latter bit (about this being configurable) a MAY, or
=0A= =0A>would you prefer to have non-RFC2119 language?
=0A=0A>
=0A&= gt;
=0A=0A>
=0A=0A>> 2) For the situation where an IPv6 pack= et is dropped for this
=0A=0A>>    specific reason, I'd = suggest that the "Reason Code" registry
=0A=0A> >   for an I= CMPv6 "Type 4 - Parameter Problem" message be updated
=0A=0A>>&nbs= p;   with a new focused reason code defined.  As a straw man, =0A=0A>>    I'd propose adding this new entry to that regi= stry,
=0A=0A> >   as part of this proposal:
=0A=0A>>= ;
=0A=0A>>    CODE     NAME/DESCRIP= TION
=0A=0A>>      3      IPv6 Initi= al Fragment missing upper-layer protocol header
=0A=0A> >
=0A= =0A>>     Of course, this means an "IANA Consider= ations" section
=0A=0A>>     update for the I-D wou= ld be in order.
=0A=0A>
=0A=0A>I find your suggestion acceptabl= e. Can others please weigh in?
=0A=0A>
=0A=0A>Minor note: May b= e the description for the error code should be along
=0A=0A>the lines= of "IPv6 First Fragment missing entire IPv6 header chain"?
=0A=0A>(I= 'm just thinking of IPv6 packets with no upper layer protocol, which
=0A= =0A>would remain legal, but would not have an "upper layer protocol head= er")
=0A=0A>
=0A>
=0A=0A>
=0A=0A>> 3) I'd also s= uggest a sentence or two clarifying that the
=0A=0A>>   = ICMPv6 "Parameter Problem" with the new Reason Code
=0A=0A>> = ;   is the appropriate message to send -- if the device dropping
= =0A=0A>>    the packet with oversized-header-chain sends an= ICMPv6
=0A=0A>>   message.  One would hope this would b= e obvious, but being
=0A=0A>>    very clear is good.
= =0A=0A>
=0A=0A>Ok.
=0A=0A>
=0A=0AI'm not invested in HOW = we provide feedback.  But THAT we provide the
=0A=0A=0Ainformation = as clearly as possible.  Something that says explicitly to the
=0A= =0Auser: "oversize-header-chain -- illegal first fragment received"  T= he user needs to
know exactly what went wrong that got the packet dropp= ed.

Bill Jouris
Inside P= roducts, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (di= rect)

---759923333-1771573322-1342867090=:80463-- From phdgang@gmail.com Sat Jul 21 21:27:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5D921F847E; Sat, 21 Jul 2012 21:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qqpBaQM1ura; Sat, 21 Jul 2012 21:27:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C94E821F847C; Sat, 21 Jul 2012 21:27:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8538824obb.31 for ; Sat, 21 Jul 2012 21:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g3mhZ2oC+4iWkm8IdMBZ4L6N3Oa/GZLPgnK4GH0yXN8=; b=xse5fmhsUhASusxjLFwNZ2Ps5O5bgjDLqtyeosVB6kNK/XRilGOWYTrB2dfDeGPflw 7foHeLSVWdJRxZD3AylXqsZynWlB2RcQQ29HPZS0yR/pdHvp53KvPJCAP0FGHdxQIizE fpm0QOjEpZHzvsk4n/yV4ixt1Db4YbmKZfm3n9T/3yx1aRJr80dqDroQu1M92Tns54ps CdJEZ1RcMhx/GV3pnFOVzrxXhRA9wB0xeMb6sS3bV5RRg/olhtX7NxsRMIBGk598TdFc xymB5GARE99Y3/O7HF1wuhmnxrWWrn4iUpiCqEbTDwwe4VrzA0pkF+pmIWwtMoK45yE0 n29g== MIME-Version: 1.0 Received: by 10.50.173.5 with SMTP id bg5mr7633384igc.35.1342931304837; Sat, 21 Jul 2012 21:28:24 -0700 (PDT) Received: by 10.42.151.194 with HTTP; Sat, 21 Jul 2012 21:28:24 -0700 (PDT) In-Reply-To: <500B5A2D.6000408@tut.fi> References: <4FF696AA.3050508@tut.fi> <500B5A2D.6000408@tut.fi> Date: Sun, 22 Jul 2012 12:28:24 +0800 Message-ID: Subject: Re: draft-chen-v6ops-nat64-experience-02 From: GangChen To: Aleksi Suhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 04:27:25 -0000 Hello Aleksi, Please see my reply inline. 2012/7/22, Aleksi Suhonen : > Hi, > > On 07/18/2012 12:05 PM, GangChen wrote: >> cc v6ops where there is discussion on draft-chen-v6ops-nat64-experience > > Oh sorry. I thought I started the discussion on the right mailing-list > in the first place, but turns out it was wrong. > >> =>I may hardly understand that is a problem with stateless NAT64. >> RFC6145 doesn't require creating a mapping state because it's >> *stateless*. The package forwarding is based on mapping rules, which >> is nothing to do with *lifetime*. Therefore, above statement of IPv4 >> pool exhaustion may not apply to stateless NAT64. I suspect this >> problem may occur in a stateful NAT64 context. The frequent reclaiming >> behavior would consume unnecessary resource by creating overwhelming >> states on NAT64 box. Your further check is expected. > > I think you're confused by the name "Stateless NAT64" because it's not > stateless despite its name. Stateless NAT64 maintains state about the > src.IPv6->src.IPv4 address mappings, while Stateful NAPT64 maintains > state about both addresses and ports. I have same understanding on the term of "Stateless NAT64" with http://www.ietf.org/mail-archive/web/ipv6/current/msg16070.html > Take a minute to think about it: Stateless NAT64 creates a 1:1 mapping > between its IPv6 clients and the IPv4 pool it's been given. If it did > not maintain a mapping, how would returning IPv4 packets be mapped back > to IPv6? Where would it find which IPv6 address should be the final > destination? Please take a look at Page13~22 at http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf If a stateless translator maintains the binding information of *src.IPv6->src.IPv4 address*, the essential feature of "Does not require flows to flow bidirectionally across a single translator" would lose. Therefore, I prefer to understand your above description is a variant of RFC6146, i.e. in the case of BIB/STE excluding port information. BRs Gang > -- > Aleksi Suhonen, Researcher > Department of Communications Engineering > Tampere University of Technology > From sarikaya2012@gmail.com Mon Jul 23 12:29:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0121F842B; Mon, 23 Jul 2012 12:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqj8ag3ZxlYq; Mon, 23 Jul 2012 12:29:54 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 431B621F841E; Mon, 23 Jul 2012 12:29:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6418055ghb.31 for ; Mon, 23 Jul 2012 12:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=i5ECtGMAeDi6OUydL+NpbkT76uXtMK60DUqNDvYEWDA=; b=QTgTNdlxqQbq8LqHs+U1Jg9n5v0+jR9qZ4RhED5kb569p+mvV1n+lgEWcMTQx1ZnvB uo23t8sg/FD77RmOJ+5KKJevQ1i0XiLfmQNSbDnTul9J6hYgnfLsmHPCb6+nnEWya462 tx2TF8HyPOwxxO3uDFhGmsAfX2G+YmrBzHAJHBj5Yd3Iahw56WIyxWR1Knf7gMgYj8qI 9TvkULlC7Kjefw/MoDwFEbMdq4ji5ovCgqczPaeJH7jaYB2iHJhOuDFn4fkJ+MFCZSqn sWkQMNczbJeHkeC8V43/KIM/k3ULm7qIbu4HWjcvQaXItuznSsqa2oXH+1PvMjqoULix vfXA== MIME-Version: 1.0 Received: by 10.236.201.161 with SMTP id b21mr8316764yho.41.1343071793787; Mon, 23 Jul 2012 12:29:53 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Mon, 23 Jul 2012 12:29:53 -0700 (PDT) In-Reply-To: References: <4FF696AA.3050508@tut.fi> <500B5A2D.6000408@tut.fi> Date: Mon, 23 Jul 2012 14:29:53 -0500 Message-ID: Subject: Re: draft-chen-v6ops-nat64-experience-02 From: Behcet Sarikaya To: GangChen Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksi Suhonen , v6ops , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 19:29:55 -0000 > > Please take a look at Page13~22 at > http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf > > If a stateless translator maintains the binding information of > *src.IPv6->src.IPv4 address*, the essential feature of "Does not > require flows to flow bidirectionally across a single translator" > would lose. > Exactly. I now understood what is meant by Stateless NAT64 reading the above presentation. It solves the reverse problem of IPv4-only client talking to IPv6-only server. Regards, Behcet From iesg-secretary@ietf.org Mon Jul 23 13:46:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F0511E809A; Mon, 23 Jul 2012 13:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny4dhNdkAPXM; Mon, 23 Jul 2012 13:46:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDF411E80C1; Mon, 23 Jul 2012 13:46:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Default Address Selection for Internet Protocol version 6 (IPv6)' to Proposed Standard (draft-ietf-6man-rfc3484bis-06.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120723204618.25107.74106.idtracker@ietfa.amsl.com> Date: Mon, 23 Jul 2012 13:46:18 -0700 Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 20:46:19 -0000 The IESG has approved the following document: - 'Default Address Selection for Internet Protocol version 6 (IPv6)' (draft-ietf-6man-rfc3484bis-06.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484bis/ Technical Summary This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. Working Group Summary The working group has been working on this replacement to RFC3484 for several years. There has been a very active discussion and there is a strong consensus to move it forward. Document Quality This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Personnel Bob Hinden is the Document Shepherd. Brian Haberman is the Responsible Area Director. From kauer@biplane.com.au Mon Jul 23 16:24:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F65E11E80E7 for ; Mon, 23 Jul 2012 16:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kej8q9DPzkvW for ; Mon, 23 Jul 2012 16:24:20 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 9C57411E80F3 for ; Mon, 23 Jul 2012 16:24:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBACbcDVCWZX+7/2dsb2JhbAANOIVvt0KBCwImAl8TsGhuknaBIIEhjk2BEgOgVodx Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 24 Jul 2012 08:54:15 +0930 Subject: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() From: Karl Auer To: IETF IPv6 Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Jul 2012 09:24:12 +1000 Message-ID: <1343085852.2796.201.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 23:24:20 -0000 I don't fully understand this change (from section Appendix B): 1. Changed the definition of CommonPrefixLen() to only compare bits up to the source address's prefix length. The previous definition used the entire source address, rather than only its prefix. As a result, when a source and destination addresses had the same prefix, common bits in the interface ID would previously result in overriding DNS load balancing [RFC1794] by forcing the destination address with the most bits in common to be always chosen. The updated definition allows DNS load balancing to continue to be used as a tie breaker. I can see this for destination address selection, where you are working from a candidate set provided by a DNS server. But I don't see it for source address selection. If you have multiple source address candidates in the same prefix, they will "fall through" Rule 8 and the implementation then has to make a choice anyway, and that choice doesn't seem able to be related to DNS load balancing. That is, the design rationale for the new CommonPrefixLen() doesn't seem to apply to source address selection, which leads me to think that for source address selection, CommonPrefixLen() should not stop at the source address prefix length. Am I missing something obvious here? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From andrewmcgr@gmail.com Mon Jul 23 20:46:11 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2375A11E8104 for ; Mon, 23 Jul 2012 20:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl6A4AWRqIBx for ; Mon, 23 Jul 2012 20:46:10 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6634411E810E for ; Mon, 23 Jul 2012 20:46:10 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so12293311pbc.31 for ; Mon, 23 Jul 2012 20:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=0v+7YcsB2Cc77dX1TFcyHoIPBJEGqOn5Oz4AKD7/TY8=; b=lJxWtRZS+DveM8n4i/p7/C3ZWumsT9Q/fVImy10rkM+ruddTSiBF6VZzu3hXPjyu11 2aP6dkOnXIC1xglhC4dF+QpcIJevzOr3hEyjotvfTNCFRpjCxlfZVjx79UAwdRSj8dL8 YENCBvMnXpDIOEGfktKGRXSJTfdQCuMwGnJpeuCfUB/mxmynp+vDnQjXPDqEfLgjSCdv u0EbsY7KNlx1nV5A80xbzmt32VKNQysa3R4JSBNNfjLaci8+UtrcnhRvy7wb4cs9rBT3 hCM8Up9VLnkSyWUZzYasnlfVuNAFr9JNHsxYoiyvotx3lzzWeRhvgBiArWe27/+4l9HE 9NWQ== Received: by 10.68.220.39 with SMTP id pt7mr41975322pbc.40.1343101570154; Mon, 23 Jul 2012 20:46:10 -0700 (PDT) Received: from andrewm-lo.ws.atlnz.lc (gate1.alliedtelesyn.co.nz. [202.49.72.36]) by mx.google.com with ESMTPS id ql3sm11239178pbc.72.2012.07.23.20.46.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 20:46:09 -0700 (PDT) From: Andrew McGregor Content-Type: multipart/signed; boundary="Apple-Mail=_6630FE46-C777-47AE-B6E7-23011799542B"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: ICMP6 redirect Date: Tue, 24 Jul 2012 15:46:04 +1200 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 03:46:11 -0000 --Apple-Mail=_6630FE46-C777-47AE-B6E7-23011799542B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've come across what looks like a bug in the ICMPv6 spec. Specifically, = RFC 4861 says that "A host MUST silently discard any received Redirect = message that does not satisfy all of the following validity checks" = amongst which is "The IP source address of the Redirect is the same as = the current first-hop router for the specified ICMP Destination = Address." Unfortunately, there is no way that a router can reliably generate that = response, if it has more than one link-local address, because the = message that caused the redirect does not actually contain the router's = own address, and the router cannot know the content of the host's route = table. The VRRPv3 spec suggests that the destination MAC address for the packet = causing the redirect is a sufficient cue, but that cannot be true in the = presence of multiple link-local addresses, which is guaranteed to happen = in VRRP (in some cases). What is the correct method of constructing ICMPv6 redirects in the = presence of multiple link-locals for the same MAC address? Is it even = possible without a spec change? I have an (untested) idea that one might be able to construct a router = advertisement that achieves the same goal as a redirect to an onlink = address, which should be processed and does not require guessing which = link local is appropriate. We have tested various of our own and other vendors products, and nobody = reliably gets this right (unsurprising, as it is inherently impossible). I will be at IETF 84 if face-to-face discussion would help. Andrew McGregor Allied Telesis Labs= --Apple-Mail=_6630FE46-C777-47AE-B6E7-23011799542B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MjQwMzQ2MDVaMCMGCSqGSIb3DQEJBDEWBBQ8bc1r Dt0Rk/PyHISAhJJ+AAdvYjCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAAkO6e+C0eqTVTObyoim9lmSBR3U+c2Bqz1Ygf93ZTuJ7PNHDS3DuIwe UgfEoukNj0OZintLaPXEy16RX+JR+R4VG5Ph1IXJ5HdfQLwGzitDrPIiaTwEsBSfqZtn7UXuycYg wWSWGxX1yh8o/QCOeEyXyM+7fap+POz/NlpHCJ/XeormcHmWusTIwpZ1nnV2ciPz95/7DHm98fKc WmKKFSgsXUIJ6w1sqbvLHQlCy8yzdUU1ezEFa8h3dk+iEfZMN3er/kXgDZWGzE2SMUxyUw4K6AKd dol8lNIdnEKuLtO08z8/7foRjLj+X9lQi55ye+jGqumJT9usL8bvsOEKURkAAAAAAAA= --Apple-Mail=_6630FE46-C777-47AE-B6E7-23011799542B-- From kauer@biplane.com.au Mon Jul 23 21:09:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8919711E8118 for ; Mon, 23 Jul 2012 21:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynsQuct7g0sS for ; Mon, 23 Jul 2012 21:09:27 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 913B111E8114 for ; Mon, 23 Jul 2012 21:09:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAJAeDlCWZX+7/2dsb2JhbAANOIVwtyQBAQEEI2YLGCoCAlcZsHZukwOPIoIKgRIDoFaHcQ Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 24 Jul 2012 13:39:24 +0930 Subject: Re: ICMP6 redirect From: Karl Auer To: ipv6@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gcTs9pBnjS4XratpMhC6" Date: Tue, 24 Jul 2012 14:09:21 +1000 Message-ID: <1343102961.2796.241.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 04:09:27 -0000 --=-gcTs9pBnjS4XratpMhC6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-07-24 at 15:46 +1200, Andrew McGregor wrote: > Unfortunately, there is no way that a router can reliably generate > that response, if it has more than one link-local address Do you mean "has more than one link-local address" or "has more than one link-local address on the receiving interface"? Regards,K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-gcTs9pBnjS4XratpMhC6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAlAOH+oACgkQFpl7eE7uYBesTAD/Sx8zWXQfLOAzf7jUsjFqVRmp nflAn5otdTa0Xi5uJYcA/1YFKmYWK5ekcXfR/b5QgKc5eXDGCG6D/mWQHgNRQjQA =Um5s -----END PGP SIGNATURE----- --=-gcTs9pBnjS4XratpMhC6-- From hesham@elevatemobile.com Mon Jul 23 21:15:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD7811E810F for ; Mon, 23 Jul 2012 21:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX20P-G-Qscm for ; Mon, 23 Jul 2012 21:15:52 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7848311E8109 for ; Mon, 23 Jul 2012 21:15:51 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1StWXA-0000JV-I4; Tue, 24 Jul 2012 14:15:45 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 24 Jul 2012 14:15:38 +1000 Subject: Re: ICMP6 redirect From: Hesham Soliman To: Andrew McGregor , Message-ID: Thread-Topic: ICMP6 redirect In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 04:15:53 -0000 >I've come across what looks like a bug in the ICMPv6 spec. => You mean in 4861 or ICMPv6? >Specifically, RFC 4861 says that "A host MUST silently discard any >received Redirect message that does not satisfy all of the following >validity checks" amongst which is "The IP source address of the Redirect >is the same as the current first-hop router for the specified ICMP >Destination Address." > >Unfortunately, there is no way that a router can reliably generate that >response, if it has more than one link-local address, because the message >that caused the redirect does not actually contain the router's own >address, and the router cannot know the content of the host's route table. => The router doesn't need to know the host's route table, it knows which address it included in its RAs, which is what the host records. I'm not sure why you think that there is no way the router can construct that message reliably. If it uses the same address it uses for its RAs, it can construct the message. > >The VRRPv3 spec suggests that the destination MAC address for the packet >causing the redirect is a sufficient cue, but that cannot be true in the >presence of multiple link-local addresses, which is guaranteed to happen >in VRRP (in some cases). > >What is the correct method of constructing ICMPv6 redirects in the >presence of multiple link-locals for the same MAC address? Is it even >possible without a spec change? => You mean multiple LLA's for the same link? The MAC address is not relevant here, it's about the LLA used on that link. Hesham > > >Andrew McGregor >Allied Telesis >Labs-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From andrewmcgr@gmail.com Mon Jul 23 21:33:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CD911E8109 for ; Mon, 23 Jul 2012 21:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tvZSsU1XS49 for ; Mon, 23 Jul 2012 21:33:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5127511E8108 for ; Mon, 23 Jul 2012 21:33:28 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so12355590pbc.31 for ; Mon, 23 Jul 2012 21:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=WzRpi1mMDpslWXyQuR0+BmnpCnGXLQpTVA3tzvqfh54=; b=H6Er/6c8Jd6kgy33NCtPOjdq6SSA3LakwzUQsljMJw1LZXg4wIsrjOjwZcY3mPBYlo cGcH/RWzsuHlgS+dzZY8Sb3E//jde7YcJRZ8Lb2p4coU03jW96xWqvm+ACiJfs0fs903 xwqy91xlkPmaiW+5YAdXnfYLvdKjwyFeqfW1xsBrVZj1uh/0X+agN/WMcFDf91udi6X5 bHMmg3q7z0HOlXdvhxpWRH91RmsH4AuOLzUIdC3WD166OGgBJnHb20MKf+FG/hOhYTSN rovMsG9YTxlioapdr9sbbDV8ZLsXHDus3jTsbami9FC773K8ce2KX822x+3I5uYAYglc 6jkw== Received: by 10.68.223.138 with SMTP id qu10mr41709994pbc.50.1343104408130; Mon, 23 Jul 2012 21:33:28 -0700 (PDT) Received: from andrewm-lo.ws.atlnz.lc (gate1.alliedtelesyn.co.nz. [202.49.72.36]) by mx.google.com with ESMTPS id sr8sm11323866pbc.61.2012.07.23.21.33.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 21:33:27 -0700 (PDT) Subject: Re: ICMP6 redirect Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_86FB823C-0B0A-44ED-937E-1B84A289D95A"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew McGregor In-Reply-To: <1343102961.2796.241.camel@karl> Date: Tue, 24 Jul 2012 16:33:22 +1200 Message-Id: <9FF3F2FD-A31B-4FC1-9DDE-4BF3C5E57032@gmail.com> References: <1343102961.2796.241.camel@karl> To: Karl Auer X-Mailer: Apple Mail (2.1278) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 04:33:29 -0000 --Apple-Mail=_86FB823C-0B0A-44ED-937E-1B84A289D95A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24/07/2012, at 4:09 PM, Karl Auer wrote: > On Tue, 2012-07-24 at 15:46 +1200, Andrew McGregor wrote: >> Unfortunately, there is no way that a router can reliably generate >> that response, if it has more than one link-local address > > Do you mean "has more than one link-local address" or "has more than one > link-local address on the receiving interface"? > > Regards,K. The latter. Andrew --Apple-Mail=_86FB823C-0B0A-44ED-937E-1B84A289D95A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MjQwNDMzMjJaMCMGCSqGSIb3DQEJBDEWBBT2iMvl uU6XVyQaW/lnVFmDivoanDCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAJCwSVTJINfg6cqRwinBcFbM5AVdHo6yDua6xJ2SudOWAopnYrnvh78g 0HZomA0XlFRX2xprTrHPqaIFL+VJgrK7SNhmhAsr/LNsxekImVn144cgIMF+xcUiCoN4WvGPwnuW P+zYAl4AhAr0glMYB7z0jbUEPmyWPNvJXaSAQDJ9AGK9LVLgYwx5ZChi2hDibfD1JMoF2fIv9WVs /R4rWD0DLGX5XVgIB2teFpoBq9r0qrYP6QOC1H2My6JGia9UXJP+oxqvnWKJ/DHXjOXlBySZn/Pp amNzmjG6u0MZZb375kRe84vcD2Do5LEF+jCvOrDrNpNAcfgyAWgvuyx4c7UAAAAAAAA= --Apple-Mail=_86FB823C-0B0A-44ED-937E-1B84A289D95A-- From andrewmcgr@gmail.com Mon Jul 23 21:39:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF09611E8118 for ; Mon, 23 Jul 2012 21:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAKTMsergk-2 for ; Mon, 23 Jul 2012 21:39:38 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3A211E8109 for ; Mon, 23 Jul 2012 21:39:38 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so12363562pbc.31 for ; Mon, 23 Jul 2012 21:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=yG2UUtEwB5/TU9+iZV89KCUT9XJTG/Znypf/p9ZsEGk=; b=LoBvXspP1GXrUI5hbxKSpFQ4VyjwLpcKASnAKAj/X9L8aPF2WxIiHEYsSFhZpRGtRJ 87ei0cz/TA8tEtdXBSIDY0YyEzrmDx4ZbPG1PKqYfimSBEhXq51Xn74tz+9HF71jnXfb UfvxrMKLqMmRo97Uyt/UsFCRVQE4r4WBIbLFvRkX+35wUq5bnHxCu5UYIkLBqgyu8Mr/ CSR6Ph5bf0XQX+itpeFrUPWT/QPsN8SGOShfm77KUZe54pOUI6G/yVrylKL2pO9rxa5S /z90gQ1yFrCFN0DcpWJe/+ysbaN7oFS6dLrsM6qr31yr1Obgi0lC86TQLFSIVxvRLqQC X3YQ== Received: by 10.68.202.133 with SMTP id ki5mr41363436pbc.10.1343104777894; Mon, 23 Jul 2012 21:39:37 -0700 (PDT) Received: from andrewm-lo.ws.atlnz.lc (gate1.alliedtelesyn.co.nz. [202.49.72.36]) by mx.google.com with ESMTPS id ny4sm11333781pbb.57.2012.07.23.21.39.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 21:39:37 -0700 (PDT) Subject: Re: ICMP6 redirect Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_D92F7A67-30A8-439F-AC01-35ED48E03CC3"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew McGregor In-Reply-To: Date: Tue, 24 Jul 2012 16:39:33 +1200 Message-Id: References: To: Hesham Soliman X-Mailer: Apple Mail (2.1278) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 04:39:39 -0000 --Apple-Mail=_D92F7A67-30A8-439F-AC01-35ED48E03CC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24/07/2012, at 4:15 PM, Hesham Soliman wrote: >=20 >> I've come across what looks like a bug in the ICMPv6 spec. >=20 > =3D> You mean in 4861 or ICMPv6? That's what I'm trying to work out, and I could see two potential = solutions. >=20 >> Specifically, RFC 4861 says that "A host MUST silently discard any >> received Redirect message that does not satisfy all of the following >> validity checks" amongst which is "The IP source address of the = Redirect >> is the same as the current first-hop router for the specified ICMP >> Destination Address." >>=20 >> Unfortunately, there is no way that a router can reliably generate = that >> response, if it has more than one link-local address, because the = message >> that caused the redirect does not actually contain the router's own >> address, and the router cannot know the content of the host's route = table. >=20 > =3D> The router doesn't need to know the host's route table, it knows = which > address it included in its RAs, which is what the host records. > I'm not sure why you think that there is no way the router can = construct > that message reliably. If it uses the same address it uses for its = RAs, it > can construct the message. Ah. Well, that will certainly help, but consider a situation where = there are no RAs, or the host has a manual static route. Arguably = misconfigured, I know, but if we have that situation a router cannot = know what address the host was sending to, only that it is one of its = own. For that matter, there may be many RAs being generated through = that interface, and do we necessarily know which it was that caused the = host/peer to route through us? >=20 >>=20 >> The VRRPv3 spec suggests that the destination MAC address for the = packet >> causing the redirect is a sufficient cue, but that cannot be true in = the >> presence of multiple link-local addresses, which is guaranteed to = happen >> in VRRP (in some cases). >>=20 >> What is the correct method of constructing ICMPv6 redirects in the >> presence of multiple link-locals for the same MAC address? Is it even >> possible without a spec change? >=20 > =3D> You mean multiple LLA's for the same link? The MAC address is not > relevant here, it's about the LLA used on that link. I mean multiple LLAs for the same link. VRRPv3 was suggesting that the = destination MAC address might help work out which LLA the host was = using. Andrew= --Apple-Mail=_D92F7A67-30A8-439F-AC01-35ED48E03CC3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MjQwNDM5MzNaMCMGCSqGSIb3DQEJBDEWBBQfaycp 0T2oarmYjK3I38gvuerTczCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAIfWqgQaA1zvFi+jXxgd2Zkc5SfdzkzgGYsyd4+yiAHktbBpQdkuWDTR y4wGwpduPoznzkzegwkahWcDlPG69UfkELeJ6ofmGZ8uYobbfHAfU3m6cFQ0dRHUvuqDY5aE9DNe NyERhgEKRau3AdN+pFj/Iv9fsHXnDK433PplLcKBzjBtgA9DvAatFNiZx1C/MQvGC+iWtlZpn+ga Dsa03YpBlfsDOnGQg5xsl5GI3efVfwb8bzwKy/3Z7ljuvp5GvioX1dauPuCNwfGNizj/z875HYed vN4ptwNZzYHwbjdLyWfMHITNHSJaafQ097IX6PZmOZQ1L0ulT7S7za+EVkcAAAAAAAA= --Apple-Mail=_D92F7A67-30A8-439F-AC01-35ED48E03CC3-- From hesham@elevatemobile.com Mon Jul 23 21:46:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115EA21F8540 for ; Mon, 23 Jul 2012 21:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIjCRaVE452k for ; Mon, 23 Jul 2012 21:46:13 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 72D4C21F8535 for ; Mon, 23 Jul 2012 21:46:12 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1StX0U-0004xl-28; Tue, 24 Jul 2012 14:46:02 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 24 Jul 2012 14:45:59 +1000 Subject: Re: ICMP6 redirect From: Hesham Soliman To: Andrew McGregor Message-ID: Thread-Topic: ICMP6 redirect In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 04:46:14 -0000 >> >>=> The router doesn't need to know the host's route table, it knows which >> address it included in its RAs, which is what the host records. >> I'm not sure why you think that there is no way the router can construct >> that message reliably. If it uses the same address it uses for its RAs, >>it >> can construct the message. > >Ah. Well, that will certainly help, but consider a situation where there >are no RAs, => Where is that situation possible/deployed? It's hard to consider something that is against the spec you're commenting on :) >or the host has a manual static route. Arguably misconfigured, I know, >but if we have that situation a router cannot know what address the host >was sending to, only that it is one of its own. For that matter, there >may be many RAs being generated through that interface, and do we >necessarily know which it was that caused the host/peer to route through >us? => Well, it depends on your implementation I guess. If your router randomly assigns src addresses to RAs with arbitrary prefixes then I can see where it would get confusing very quickly. But if they're doing it in a structured way it will work. That's why I raised a comment against your premise of "no way to do it reliably". There is definitely a way to do it reliably. Hesham From andrewmcgr@gmail.com Wed Jul 25 00:12:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05811E807F for ; Wed, 25 Jul 2012 00:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv7OeCeSg+Ai for ; Wed, 25 Jul 2012 00:12:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAFEE11E8073 for ; Wed, 25 Jul 2012 00:12:00 -0700 (PDT) Received: by yenq13 with SMTP id q13so423746yen.31 for ; Wed, 25 Jul 2012 00:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=IxyD/Dx9dhk9WeTB83noywAPr4sWmm4AMDZnlrcvYzw=; b=ZkHG4ZhFjDpQpDSvBGs0+80WjuV+O2s1egXlrOCamNeheVlsVcsfKmYkjdMCzlQTH3 UJhY+mbuKpPnugrdz0poVj6DWS4sVkb8kxBdvISs5so4TlMfd+YVYqLRBGNk4iD2i9Sg senKxCRyr+MOxoogy6Pip4eqvoFo42l/D3TnmUAngo9UiF69zRiDCxjObggWAGX1Wwv5 hZ4lfSNcT8GP3zNcJl884tFgF3BWAPNMqQhYofBmKqy5XMvA9CUNUM/GDVLePZtOPchX huayVuspuGa9BzmoXqcgb/NaQk/AT7Ff8AiWGIb0uvpeF2tSYyYMC3j0Cge931q0kCfw WHxA== Received: by 10.66.73.5 with SMTP id h5mr10548882pav.79.1343200319985; Wed, 25 Jul 2012 00:11:59 -0700 (PDT) Received: from ?IPv6:2406:e000:62e9:1:6c8a:17d2:19ac:6905? ([2406:e000:62e9:1:6c8a:17d2:19ac:6905]) by mx.google.com with ESMTPS id qp6sm31660pbc.55.2012.07.25.00.11.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 00:11:58 -0700 (PDT) Subject: Re: ICMP6 redirect Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_9B6F32EE-11B6-4D4F-814F-28375F371CA4"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew McGregor In-Reply-To: Date: Wed, 25 Jul 2012 19:11:53 +1200 Message-Id: <1DC7DA96-0DF2-4C79-BDEF-0DD038257B41@gmail.com> References: To: Hesham Soliman X-Mailer: Apple Mail (2.1278) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:12:01 -0000 --Apple-Mail=_9B6F32EE-11B6-4D4F-814F-28375F371CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24/07/2012, at 4:45 PM, Hesham Soliman wrote: >>>=20 >>> =3D> The router doesn't need to know the host's route table, it = knows which >>> address it included in its RAs, which is what the host records. >>> I'm not sure why you think that there is no way the router can = construct >>> that message reliably. If it uses the same address it uses for its = RAs, >>> it >>> can construct the message. >>=20 >> Ah. Well, that will certainly help, but consider a situation where = there >> are no RAs,=20 >=20 > =3D> Where is that situation possible/deployed? It's hard to consider > something that is against the spec you're commenting on :) Sure, it is not a situation contemplated by the ND spec. So, do you = mean to say it is incorrect configuration for a router to have = forwarding on and not be sending RAs, and therefore you should not send = redirects if you are not sending RAs? That works as a resolution for = me, in terms of specs. However, if it is not a misconfiguration, and you wish to redirect = traffic that has a better first hop, or is on-link but the host for = whatever reason does not know that, is that possible? Should it be? I suspect it is a common situation, no matter that it's completely = broken. Andrew= --Apple-Mail=_9B6F32EE-11B6-4D4F-814F-28375F371CA4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MjUwNzExNTRaMCMGCSqGSIb3DQEJBDEWBBR0/eOn VoFhVTYo+T+SzLHhHvSlyjCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAJJOBEpx7juTf63slFhi5oWQMKpXTkhtNlGgQEBq3a+m6c5pcmpOhsZr 5eXc1GRWLkvS+7KK25zpe5UdH0vbkSqz9cGVo2ORLz9I62W30X5O60nT/giovuEubbWqM9TozLv6 3sMsQigishAtWo+uZi0VBn6EornLPezK51+7oCuMdFhqGNFZUUnFoAQTJWv2QhqOLYcMfloTuE+C NpfF2lV7JoxKMacidJu7qYysvPIdXTq9tTjJI7c64XqQ3auLnSSzEj/FZgRyhTMJfQx2y6iN98qz MrO3V/I7lhTja8CPxbqtwaYRNCCKvqJ2M2FP9pQBJH/kT1Ro9XzJFg5hRnsAAAAAAAA= --Apple-Mail=_9B6F32EE-11B6-4D4F-814F-28375F371CA4-- From pkern@spike.0x539.de Wed Jul 25 02:19:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2EB21F857A for ; Wed, 25 Jul 2012 02:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w-VELilyU1V for ; Wed, 25 Jul 2012 02:19:12 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5221F8575 for ; Wed, 25 Jul 2012 02:19:11 -0700 (PDT) Received: from [2001:470:720c:0:7c26:800f:8492:6266] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1StxkE-0002Xp-4t for ipv6@ietf.org; Wed, 25 Jul 2012 11:19:02 +0200 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1StxkK-0004Hc-Bh for ipv6@ietf.org; Wed, 25 Jul 2012 11:19:08 +0200 Date: Wed, 25 Jul 2012 11:19:08 +0200 From: Philipp Kern To: ipv6@ietf.org Subject: Re: ICMP6 redirect Message-ID: <20120725091908.GB14875@spike.0x539.de> References: <1DC7DA96-0DF2-4C79-BDEF-0DD038257B41@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1DC7DA96-0DF2-4C79-BDEF-0DD038257B41@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:19:13 -0000 Andrew, am Wed, Jul 25, 2012 at 07:11:53PM +1200 hast du folgendes geschrieben: > However, if it is not a misconfiguration, and you wish to redirect traffic > that has a better first hop, or is on-link but the host for whatever reason > does not know that, is that possible? Should it be? I still wonder how the devices should figure out that there's a better first hop apart from network misdesigns[1]. Are people really diverging from "one subnet per VLAN" with two routers connected to a segment and routing the traffic to the other router over that segment? (But that's possibly an ops question.) Kind regards Philipp Kern [1] http://www.cymru.com/gillsr/documents/icmp-redirects-are-bad.pdf From andrewmcgr@gmail.com Wed Jul 25 03:38:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092EA21F852C for ; Wed, 25 Jul 2012 03:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNERPVCLXo4y for ; Wed, 25 Jul 2012 03:38:25 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFE4921F84EB for ; Wed, 25 Jul 2012 03:38:24 -0700 (PDT) Received: by ggnc4 with SMTP id c4so577570ggn.31 for ; Wed, 25 Jul 2012 03:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=r/QkOmFO4yk8d6ZSIeq6d2oDHflfv0pQMRH6MkkCVOI=; b=ZUIYAbij2DU09hBV9aVdMqbNj3wxxuTdbGW2PbWhZcTLX+A4Q0AzCzq1QnY97MeD9l wsz7PcAAr8gJA7det0xZWFHPpsZYKI0gOoWNKX6Dt9mAPKej+2gECTr6D8MJpPxU4q8v ZYyjsbG9JMK5crnl57vaFRuF144S6oT70WllYZIhPEnDQkP1DfMg2Z0eND9dD0z8x3ms ONR5dM51+r4u5ZnKhWIbWC+hiwe89Pj0Q94B6jDZg6kGe6SJxkrhLU/0xiaURDdmJK+d 3SMI68tZ+VquXOTdsmqB0a3CwzU9qYhY7ZsvPBlxuhG7aNLbK+TK4LcxBhVZCTHvNb+o fTug== Received: by 10.66.75.168 with SMTP id d8mr11746958paw.63.1343212704246; Wed, 25 Jul 2012 03:38:24 -0700 (PDT) Received: from ?IPv6:2406:e000:62e9:1:91c5:1a89:193c:cb2d? ([2406:e000:62e9:1:91c5:1a89:193c:cb2d]) by mx.google.com with ESMTPS id vu8sm14139270pbc.41.2012.07.25.03.38.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 03:38:23 -0700 (PDT) Subject: Re: ICMP6 redirect Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_16611B66-B3FA-4AF7-9210-81A912D269CD"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew McGregor In-Reply-To: <20120725091908.GB14875@spike.0x539.de> Date: Wed, 25 Jul 2012 22:38:18 +1200 Message-Id: References: <1DC7DA96-0DF2-4C79-BDEF-0DD038257B41@gmail.com> <20120725091908.GB14875@spike.0x539.de> To: Philipp Kern X-Mailer: Apple Mail (2.1278) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:38:26 -0000 --Apple-Mail=_16611B66-B3FA-4AF7-9210-81A912D269CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25/07/2012, at 9:19 PM, Philipp Kern wrote: > Andrew, >=20 > am Wed, Jul 25, 2012 at 07:11:53PM +1200 hast du folgendes = geschrieben: >> However, if it is not a misconfiguration, and you wish to redirect = traffic >> that has a better first hop, or is on-link but the host for whatever = reason >> does not know that, is that possible? Should it be? >=20 > I still wonder how the devices should figure out that there's a better = first > hop apart from network misdesigns[1]. >=20 > Are people really diverging from "one subnet per VLAN" with two = routers > connected to a segment and routing the traffic to the other router = over that > segment? (But that's possibly an ops question.) >=20 > Kind regards > Philipp Kern This originally came in the context of VRRP v3. If you want to run some = dynamic routing protocol at the same time as VRRP on the same VLAN, you = need another link-local address to talk to your routing peers with, = since there's no way for the non-master routers to use the VRRP address. = So, you have two (or more) link locals on the same VLAN. Ideally only = the VRRP one should be used for sending RAs, of course. I totally agree that RAs should take care of this, and in fact I think = one way to resolve the conundrum is to craft an RA to specifically tell = the host it is onlink with that exact destination, rather than a = redirect, since as I read the RA processing rules, it does not matter = what source address the router uses in that case. Andrew= --Apple-Mail=_16611B66-B3FA-4AF7-9210-81A912D269CD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MjUxMDM4MThaMCMGCSqGSIb3DQEJBDEWBBQ/TEsj YOXPl82W+dCStBncpgkMyTCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAKqJNJXiYP2NB1uag4TzcKHK3l754okBthpTlxE/kXtwxXstIebHnanF CAq+XtfqlLEb4H8wteaWWYFjd6wUdpe4kNptLp85J7y++2MLwse3lfsNfC6W5cWvt/o0AT7MOUzj Lt1Kcp8xQHXyLJcAjl0f43WGSBYcfrBvIecqTpjkQUZujC7lLQhl9BdzAFceWhwYYRugqeZ/Fhd7 CaIT+wq1SlMaRM61TdNaDow81OqZUbMTA+yOIT9ArpI18EbXSv1O8APSjg6Cfs8SXdC39VQj9Gao 1VsThVvsCNXbseuo8mB4NQWDw2Xhtvf3MVI7PzpNySSs43RACSaqDzuRE0MAAAAAAAA= --Apple-Mail=_16611B66-B3FA-4AF7-9210-81A912D269CD-- From hesham@elevatemobile.com Wed Jul 25 04:09:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A1E21F85AD for ; Wed, 25 Jul 2012 04:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7TjimUE+g0B for ; Wed, 25 Jul 2012 04:09:32 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8572121F85A3 for ; Wed, 25 Jul 2012 04:09:31 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1StzSj-0000Hc-Qy; Wed, 25 Jul 2012 21:09:06 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 25 Jul 2012 21:08:56 +1000 Subject: Re: ICMP6 redirect From: Hesham Soliman To: Andrew McGregor Message-ID: Thread-Topic: ICMP6 redirect In-Reply-To: <1DC7DA96-0DF2-4C79-BDEF-0DD038257B41@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 11:09:33 -0000 > > > >>>> >>>> => The router doesn't need to know the host's route table, it knows >>>>which >>>> address it included in its RAs, which is what the host records. >>>> I'm not sure why you think that there is no way the router can >>>>construct >>>> that message reliably. If it uses the same address it uses for its >>>>RAs, >>>> it >>>> can construct the message. >>> >>> Ah. Well, that will certainly help, but consider a situation where >>>there >>> are no RAs, >> >> => Where is that situation possible/deployed? It's hard to consider >> something that is against the spec you're commenting on :) > >Sure, it is not a situation contemplated by the ND spec. So, do you mean >to say it is incorrect configuration for a router to have forwarding on >and not be sending RAs, => This sentence should not imply the following words after "therefore". I think a router can be forwarding without sending RAs. But I also think that if you're going to send redirects, you must have sent an RA. > and therefore you should not send redirects if you are not sending RAs? >That works as a resolution for me, in terms of specs. => Yes. I don't think it implies that if you're forwarding you must send RA's though :). They're two separate issues. Anyone, that's my opinion given the way the spec is written. It's not explicitly mentioned in 4861 that you can't send redirects unless you're also sending RAs, but that seems implicit to me. > >However, if it is not a misconfiguration, and you wish to redirect >traffic that has a better first hop, or is on-link but the host for >whatever reason does not know that, is that possible? Should it be? => Well, knowing that someone's on-link is based on knowing that the prefix is on-link. They all seem to be related to information communicated in the RA. So it makes sense to me to tie this function to a router that sends RAs. > >I suspect it is a common situation, no matter that it's completely broken. => I don't know how common this is honestly. So I'll take your word with caution. Hesham > >Andrew From ichiroumakino@gmail.com Wed Jul 25 06:14:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D21921F85E3 for ; Wed, 25 Jul 2012 06:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA4mWCyRhDnh for ; Wed, 25 Jul 2012 06:14:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3135C21F85D1 for ; Wed, 25 Jul 2012 06:14:32 -0700 (PDT) Received: by lagv3 with SMTP id v3so555201lag.31 for ; Wed, 25 Jul 2012 06:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=HtGD8sI4nG8jGWi+RYk0yLkLIGqAg2jeE6qOfGRUKgU=; b=F82kFyDxAvE+b9hv6xSGP3FTQIAuQLbXYeCKlwNK9oyhx+RuWRqIrQdpujwR9fCXVF Oob62tJkvaGszB0QHIj6B3IfDKsXfjpeZupFATmpoGouvV9q7OAeVk4y3nFwx+0oa+bP vdVGmz6dvAoOi2cM5ONgbDMfA3v4+dw6BBbJ+Potzz8CWIj86zcd8wLLGLudA1ei2Bmu MnfvUyfMjLR+4PQQ0b9AqL7YB94lHR7rj+LnEscx73DdqQDmpqRSSR5xUWfr6h8SbdBw Mjj1lVr1kxQKNVO2I2CA1BYd/zvuuCKvNzyxGlTtW+OLtQrSiaIdoBUlvAaByYBm+Moc I0gA== Received: by 10.112.84.168 with SMTP id a8mr11633903lbz.92.1343222072160; Wed, 25 Jul 2012 06:14:32 -0700 (PDT) Received: from [10.0.0.20] ([80.203.105.126]) by mx.google.com with ESMTPS id u10sm4573055lbm.14.2012.07.25.06.14.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 06:14:31 -0700 (PDT) Sender: Ole Troan From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IETF 84 6man agenda Date: Wed, 25 Jul 2012 10:56:00 +0200 Message-Id: <89CD3FD2-4CBA-4D90-B30F-5E781F9A9AA1@employees.org> To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:14:34 -0000 all, apologies for the late update, the tentative 6man agenda is now available at: https://datatracker.ietf.org/meeting/84/agenda/6man/ appreciated if the presenters could send the chairs their presentations, preferably no later than Tuesday mid day. Best regards, Ole & Bob From nordmark@acm.org Wed Jul 25 10:36:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4402B21F86DE for ; Wed, 25 Jul 2012 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5mdI7KCbFzw for ; Wed, 25 Jul 2012 10:36:14 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2221F86D5 for ; Wed, 25 Jul 2012 10:36:14 -0700 (PDT) Received: from [10.33.22.136] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q6PHaA48016985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 10:36:11 -0700 Message-ID: <50102E8A.5000003@acm.org> Date: Wed, 25 Jul 2012 10:36:10 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: ICMP6 redirect References: <1DC7DA96-0DF2-4C79-BDEF-0DD038257B41@gmail.com> <20120725091908.GB14875@spike.0x539.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:36:15 -0000 On 7/25/12 3:38 AM, Andrew McGregor wrote: > This originally came in the context of VRRP v3. If you want to run > some dynamic routing protocol at the same time as VRRP on the same > VLAN, you need another link-local address to talk to your routing > peers with, since there's no way for the non-master routers to use > the VRRP address. So, you have two (or more) link locals on the same > VLAN. Ideally only the VRRP one should be used for sending RAs, of > course. Agreed. Sounds like that is a small implementation matter in the router software. > I totally agree that RAs should take care of this, and in fact I > think one way to resolve the conundrum is to craft an RA to > specifically tell the host it is onlink with that exact destination, > rather than a redirect, since as I read the RA processing rules, it > does not matter what source address the router uses in that case. I guess I don't understand the problem you want to solve. Can you clarify? I thought the problem was that the 1st hop was suboptimal, and the 1st hop router wants to send a redirect to tell the host to use a different 1st hop router to get to the offlink destination. You can't do that by faking an RA. But above it sounds like the destination is on-link. Is that the problem you want to solve? While you can fake an RA for that, it runs into a issue with NUD should the destination ever move off-link. That issue is that the prefix information in the RAs time out based on the preferred/valid lifetime, and NUD doesn't affect that. Thus if the destination is no longer off-link, either the routers have to detect that and send a fake RA with the prefix with onlink=0, or communication will be broken until the valid lifetime of the prefix expires. Redirects don't have that issue; NUD knows to ignore/discard the redirects when it doesn't get responses to the probes. Erik From bob.hinden@gmail.com Thu Jul 26 16:47:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFE021F85EA for ; Thu, 26 Jul 2012 16:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5K-vlmwtYjl for ; Thu, 26 Jul 2012 16:47:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F350B21F85E4 for ; Thu, 26 Jul 2012 16:47:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4052859pbc.31 for ; Thu, 26 Jul 2012 16:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wYseLR8vh4hSUotJjVpyDjLTgjQ17RdiTtsH7kBcirA=; b=XAWn6nu1iRUtuxtPwyoEMNzavw/ii6TJ/HuAtIgX8D/6yCxBfjdUAEln88kE4vDTgC 5cri9Q0257HLopbaKEF1nHbmmrcRFXtXHL47AwGnFtVTYFcv8iu+T4rBuPjIPEKDbe51 Afr38gda200sVEMqjU6VdSZkBjdN0hzYDoILXCIyNobkuamGjBtrno3FfSfYJ1sIDAWE 1JKacA1lTzjStIEJndLwMMmDCbVXAHNdaWewCQTDCLhZPRTF6YsALw55B2mJbpjWYkwr NNhJQOMxTWpTQdW6CwwUxI5G9Afq1xC1detbSlMHf72ACbTyQuWzntYEVIqzanKIMtno Wmyw== Received: by 10.68.216.72 with SMTP id oo8mr8833982pbc.82.1343346460835; Thu, 26 Jul 2012 16:47:40 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPS id ql6sm624484pbc.61.2012.07.26.16.47.39 (version=SSLv3 cipher=OTHER); Thu, 26 Jul 2012 16:47:40 -0700 (PDT) Subject: Re: Status of draft-ietf-6man-lineid Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4FFB7918.9080806@innovationslab.net> Date: Thu, 26 Jul 2012 16:47:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49AE274A-AC1C-463E-AB02-C022B39232E4@gmail.com> References: <4FFB7918.9080806@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1280) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , Bob Hinden , Ralph Droms , Pete Resnick , Barry Leiba X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 23:47:41 -0000 Brian, In the two plus weeks since you sent this, I saw one email in support = and none is opposition. Given the lack of objections to publishing this = as a Proposed Standard, I think OK to go forward as a PS. Bob On Jul 9, 2012, at 5:36 PM, Brian Haberman wrote: > All, > During the IESG discussion of draft-ietf-6man-lineid, the question = was raised as to its appropriate status. The WG decided to advance the = draft as Experimental since it had documented limitations and was = targeted to a limited deployment scenario. Several ADs raised the issue = that the above reasons do not necessarily make the draft inappropriate = for Proposed Standard, To quote feedback from one of the ADs (Barry = Leiba): >=20 >=20 > "If the limitations are clearly documented and if that document can be = used to target implementations correctly, then I think PS is completely = appropriate. If experimentation is needed to *determine* the = limitations, or to determine how to implement the specification to as = not to interfere with inapplicable situations, then Experimental is = best." >=20 >=20 > In my view, there is a clear understanding of what the limitations of = this approach are and they can be clearly defined in an applicability = statement within the draft. Additionally, we know the deployment = scenario (N:1 VLAN usage in broadband networks) where this approach will = be used. >=20 > My question is whether there is opposition or support within the = community to move the document to Proposed Standard as long as there is = a sufficient applicability statement included in the draft. Please = provide feedback to the mailing list (and the cc:'ed ADs) on this = proposed change. >=20 > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kauer@biplane.com.au Sat Jul 28 18:14:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B750A21F84F5 for ; Sat, 28 Jul 2012 18:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APfu9zLzwTHE for ; Sat, 28 Jul 2012 18:14:59 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id BD65D21F84B2 for ; Sat, 28 Jul 2012 18:14:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJeNFFCWZX+7/2dsb2JhbAANOIVztxMBAQEDASNbCwsaAiYCAlcZiAemPW6SFIEhgSGMVIIKgRIDoFaHcQ Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 29 Jul 2012 10:44:53 +0930 Subject: Re: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() From: Karl Auer To: ipv6@ietf.org In-Reply-To: <1343085852.2796.201.camel@karl> References: <1343085852.2796.201.camel@karl> Content-Type: text/plain; charset="UTF-8" Date: Sun, 29 Jul 2012 11:14:49 +1000 Message-ID: <1343524489.3497.94.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 01:14:59 -0000 A few days ago, I asked about this draft as below. I haven't seen a response, but the question still seems fair. > I don't fully understand this change (from section Appendix B): > > 1. Changed the definition of CommonPrefixLen() to only compare bits > up to the source address's prefix length. The previous > definition used the entire source address, rather than only its > prefix. As a result, when a source and destination addresses > had the same prefix, common bits in the interface ID would > previously result in overriding DNS load balancing [RFC1794] by > forcing the destination address with the most bits in common to > be always chosen. The updated definition allows DNS load > balancing to continue to be used as a tie breaker. > > I can see this for destination address selection, where you are > working from a candidate set provided by a DNS server. > > But I don't see it for source address selection. If you have multiple > source address candidates in the same prefix, they will "fall through" > Rule 8 and the implementation then has to make a choice anyway, and > that choice doesn't seem able to be related to DNS load balancing. > > That is, the design rationale for the new CommonPrefixLen() doesn't > seem to apply to source address selection, which leads me to think > that for source address selection, CommonPrefixLen() should not stop > at the source address prefix length. > > Am I missing something obvious here? > > Regards, K. > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From brian@innovationslab.net Mon Jul 30 12:45:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C18811E81C7 for ; Mon, 30 Jul 2012 12:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxDIsR9n5XkL for ; Mon, 30 Jul 2012 12:45:56 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id CA68F11E81D4 for ; Mon, 30 Jul 2012 12:45:56 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7EDBE88094; Mon, 30 Jul 2012 12:45:56 -0700 (PDT) Received: from dhcp-5588.meeting.ietf.org (dhcp-5588.meeting.ietf.org [130.129.85.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3D5C8130017; Mon, 30 Jul 2012 12:45:56 -0700 (PDT) Message-ID: <5016E473.9010302@innovationslab.net> Date: Mon, 30 Jul 2012 15:45:55 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bob Hinden Subject: Re: Status of draft-ietf-6man-lineid References: <4FFB7918.9080806@innovationslab.net> <49AE274A-AC1C-463E-AB02-C022B39232E4@gmail.com> In-Reply-To: <49AE274A-AC1C-463E-AB02-C022B39232E4@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Pete Resnick , Barry Leiba , 6man WG , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 19:45:57 -0000 Bob, I agree that there is consensus to move this forward as PS. There will be an IETF Last Call for the draft as a PS started after Vancouver. Regards, Brian On 7/26/12 7:47 PM, Bob Hinden wrote: > Brian, > > In the two plus weeks since you sent this, I saw one email in support > and none is opposition. Given the lack of objections to publishing > this as a Proposed Standard, I think OK to go forward as a PS. > > Bob > > On Jul 9, 2012, at 5:36 PM, Brian Haberman wrote: > >> All, During the IESG discussion of draft-ietf-6man-lineid, the >> question was raised as to its appropriate status. The WG decided >> to advance the draft as Experimental since it had documented >> limitations and was targeted to a limited deployment scenario. >> Several ADs raised the issue that the above reasons do not >> necessarily make the draft inappropriate for Proposed Standard, To >> quote feedback from one of the ADs (Barry Leiba): >> >> >> "If the limitations are clearly documented and if that document can >> be used to target implementations correctly, then I think PS is >> completely appropriate. If experimentation is needed to >> *determine* the limitations, or to determine how to implement the >> specification to as not to interfere with inapplicable situations, >> then Experimental is best." >> >> >> In my view, there is a clear understanding of what the limitations >> of this approach are and they can be clearly defined in an >> applicability statement within the draft. Additionally, we know >> the deployment scenario (N:1 VLAN usage in broadband networks) >> where this approach will be used. >> >> My question is whether there is opposition or support within the >> community to move the document to Proposed Standard as long as >> there is a sufficient applicability statement included in the >> draft. Please provide feedback to the mailing list (and the cc:'ed >> ADs) on this proposed change. >> >> Regards, Brian >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From n@arifumi.net Mon Jul 30 16:30:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D2B11E8138 for ; Mon, 30 Jul 2012 16:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq7exsJ2b0Zm for ; Mon, 30 Jul 2012 16:30:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04D7311E8109 for ; Mon, 30 Jul 2012 16:30:17 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5502149vcb.31 for ; Mon, 30 Jul 2012 16:30:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=8iF0XIsKKCdIXGN0xuFLMCnDIsCXL9EowqIUSFBXvXk=; b=PnfVOE9p0DOYkkTX7Y+6Mt0hgbDav+NO5yPPm9eAG8uMgFrTWC1XoYUljPPGdkKrDg W2m/0BaXUAEJD3P7HPaqPYVbLO2XSWLvGeBRHSUBhWNuOhnYp8v9xoY+5QMJnDJlZCQV TwchyavV+zMg470ZpCN7Di8Mpy/CPhdP/JGf7BzirxSTC5x1biZz+JqoJCcMqJ1sC2e5 bHc0cAm83bZpfgbAJKQI3nGwmRGHc6RTHaDFhe2azvpNPK0IlSkbItxAANSDOsBw2DSn tFw17X020H55L2CT18hcrU5mh6cYRiLS7vyt/FLlFPVhTAhCrnUGZlVSh1ytXiH/VRV0 5xOA== MIME-Version: 1.0 Received: by 10.221.1.137 with SMTP id nq9mr12510667vcb.16.1343691017240; Mon, 30 Jul 2012 16:30:17 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.94.132 with HTTP; Mon, 30 Jul 2012 16:30:17 -0700 (PDT) X-Originating-IP: [130.129.16.149] In-Reply-To: <1343524489.3497.94.camel@karl> References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl> Date: Tue, 31 Jul 2012 08:30:17 +0900 X-Google-Sender-Auth: 4BxU1Rm-zjS221vj7J2kV6LxK3M Message-ID: Subject: Re: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() From: Arifumi Matsumoto To: Karl Auer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm7OYRaszEDOoMU1C9bNSiFiZwuaV6VmEhvdtJV3oI1EVHvHejZRJDG/Jf0qLRZtGNt1Ofr Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:30:19 -0000 Karl, 2012/7/29 Karl Auer : > A few days ago, I asked about this draft as below. I haven't seen a > response, but the question still seems fair. > >> I don't fully understand this change (from section Appendix B): >> >> 1. Changed the definition of CommonPrefixLen() to only compare bits >> up to the source address's prefix length. The previous >> definition used the entire source address, rather than only its >> prefix. As a result, when a source and destination addresses >> had the same prefix, common bits in the interface ID would >> previously result in overriding DNS load balancing [RFC1794] by >> forcing the destination address with the most bits in common to >> be always chosen. The updated definition allows DNS load >> balancing to continue to be used as a tie breaker. >> >> I can see this for destination address selection, where you are >> working from a candidate set provided by a DNS server. >> >> But I don't see it for source address selection. If you have multiple >> source address candidates in the same prefix, they will "fall through" >> Rule 8 and the implementation then has to make a choice anyway, and >> that choice doesn't seem able to be related to DNS load balancing. >> >> That is, the design rationale for the new CommonPrefixLen() doesn't >> seem to apply to source address selection, which leads me to think >> that for source address selection, CommonPrefixLen() should not stop >> at the source address prefix length. >> >> Am I missing something obvious here? In my understanding, there is no use to look at the interface id part also for source address selection as well as for destination address selection. DNS load balance issue is explicitly specified, because it is clear problem that we see. Thanks. >> >> Regards, K. >> > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://www.biplane.com.au/blog > > GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 > Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kauer@biplane.com.au Mon Jul 30 17:08:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5AF11E80CC for ; Mon, 30 Jul 2012 17:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWAKHtjD3rCK for ; Mon, 30 Jul 2012 17:08:42 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 5925511E8099 for ; Mon, 30 Jul 2012 17:08:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJAgF1CWZX+7/2dsb2JhbAANOIVztw0BAQEEDhVCJAsYAgImAgJXGa9AbpMdgSGBIYx7ggqBEgOgVodx Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 31 Jul 2012 09:38:37 +0930 Subject: Re: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() From: Karl Auer To: ipv6@ietf.org In-Reply-To: References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl> Content-Type: text/plain; charset="UTF-8" Date: Tue, 31 Jul 2012 10:08:15 +1000 Message-ID: <1343693295.26898.53.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:08:43 -0000 On Tue, 2012-07-31 at 08:30 +0900, Arifumi Matsumoto wrote: > In my understanding, there is no use to look at the interface id part > also for source address selection as well as for destination address > selection. > > DNS load balance issue is explicitly specified, because it is clear > problem that we see. Thanks, Arifumi, but I don't understand your point. You have not said *why* "there is no use". I do see the rationale for stopping the comparison at the prefix length for *destination* address selection. I do not see the rationale for doing so for *source* address selection. Perhaps we need to distinguish between source address selection and source address checking. I just made up that second term :-) Source address selection is the process of choosing which source address will be used in an outgoing packet. Source address checking is the process, performed during destination address selection, of looking to see which source address *would* be selected if a given destination address were selected. My question is about the first of these two, not the second. I don't see how DNS load balancing affects the first. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From dthaler@microsoft.com Mon Jul 30 17:28:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD1F21F85D2 for ; Mon, 30 Jul 2012 17:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.406 X-Spam-Level: X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3QwlByJ2mS7 for ; Mon, 30 Jul 2012 17:28:15 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id DDD7F21F85C4 for ; Mon, 30 Jul 2012 17:28:14 -0700 (PDT) Received: from mail168-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 00:28:14 +0000 Received: from mail168-va3 (localhost [127.0.0.1]) by mail168-va3-R.bigfish.com (Postfix) with ESMTP id 39BA560389; Tue, 31 Jul 2012 00:28:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I146fI542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail168-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail168-va3 (localhost.localdomain [127.0.0.1]) by mail168-va3 (MessageSwitch) id 1343694492835038_941; Tue, 31 Jul 2012 00:28:12 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.254]) by mail168-va3.bigfish.com (Postfix) with ESMTP id BDA0F3800D2; Tue, 31 Jul 2012 00:28:12 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 00:28:12 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 00:28:10 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 30 Jul 2012 17:28:10 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Mon, 30 Jul 2012 17:28:10 -0700 From: Dave Thaler To: Karl Auer , "ipv6@ietf.org" Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() Thread-Topic: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() Thread-Index: AQHNbSefWPJft5j+MUyaK6aT0cUFA5dCiZ7g Date: Tue, 31 Jul 2012 00:28:09 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B72ECDD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl> In-Reply-To: <1343524489.3497.94.camel@karl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:28:16 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Karl Auer > Sent: Saturday, July 28, 2012 6:15 PM > To: ipv6@ietf.org > Subject: Re: question about draft-ietf-6man-rfc3484bis-06.txt and > CommonPrefixLen() >=20 > A few days ago, I asked about this draft as below. I haven't seen a respo= nse, Probably because we've been in route to IETF. > but the question still seems fair. >=20 > > I don't fully understand this change (from section Appendix B): > > > > 1. Changed the definition of CommonPrefixLen() to only compare bits > > up to the source address's prefix length. The previous > > definition used the entire source address, rather than only its > > prefix. As a result, when a source and destination addresses > > had the same prefix, common bits in the interface ID would > > previously result in overriding DNS load balancing [RFC1794] by > > forcing the destination address with the most bits in common to > > be always chosen. The updated definition allows DNS load > > balancing to continue to be used as a tie breaker. > > > > I can see this for destination address selection, where you are > > working from a candidate set provided by a DNS server. > > > > But I don't see it for source address selection. If you have multiple > > source address candidates in the same prefix, they will "fall through" > > Rule 8 and the implementation then has to make a choice anyway, and > > that choice doesn't seem able to be related to DNS load balancing. True. It is missing the implied tie breaker sentence that exists in Destination address selection: Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise prefer DB. > > That is, the design rationale for the new CommonPrefixLen() doesn't > > seem to apply to source address selection, which leads me to think > > that for source address selection, CommonPrefixLen() should not stop > > at the source address prefix length. > > > > Am I missing something obvious here? The bits in the interface identifier are not indicative of goodness or appropriateness or whatever. They can be random, or based on something unrelated to appropriateness for a given destination or for destinations in general. So there's no benefit in having CommonPrefixLen() continue. In the destination case, rule 10 preserves the original order, resulting in DNS load balancing applying. That is, the pre-sort order is the implied tie breaker. For source sorting, the same is true. That is, you have a list of candida= te source addresses. Whatever that order is, is the implied tie breaker. So if the host has some default ordering, or chooses to round robin them (as DNS does with dest addrs), or whatever else, then the=20 implied Rule 9 (don't change the order) preserves that tie breaker, which is better than using the interface identifier bits which don't have any technical reason to use them. I would be fine with making an editorial-only change to the doc to: 1) explicitly add Rule 9 which is already implied. 2) Update Appendix B with a sentence or two summarizing the change to source sorting. Of course an implementation that does use the interface identifier bits as RFC 3484 did is still compliant to 3484bis, since it can override rule 8 per the existing text, and of course it could order the candidate source list by common prefix length, either of which would result in the old behavior. And since RFC 3484 already contained the same MAY about overriding the new rule 8, there's no real "compliance" change between the two, just a marginally different recommendation, based on the WG agreement that the interface identifier bits aren't really relevant to sorting. -Dave > > > > Regards, K. > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://www.biplane.com.au/blog >=20 > GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old > fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kauer@biplane.com.au Mon Jul 30 18:46:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2159C21F8517 for ; Mon, 30 Jul 2012 18:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+DVKUiSnUyn for ; Mon, 30 Jul 2012 18:46:09 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3221F8516 for ; Mon, 30 Jul 2012 18:46:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAA44F1CWZX+7/2dsb2JhbAANOIV4tw8BAQEDASNbCwsYKgICVwYTiAenOm6TKIJCjwOBEgOgVYdx Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 31 Jul 2012 11:16:06 +0930 Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() From: Karl Auer To: "ipv6@ietf.org" In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B72ECDD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl> <9B57C850BB53634CACEC56EF4853FF653B72ECDD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-p8mHU00+T968FwkZPnx/" Date: Tue, 31 Jul 2012 11:46:05 +1000 Message-ID: <1343699165.26898.113.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:46:10 -0000 --=-p8mHU00+T968FwkZPnx/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-07-31 at 00:28 +0000, Dave Thaler wrote: > The bits in the interface identifier are not indicative of goodness or > appropriateness or whatever. Firstly, thanks for the extensive explanation. I realise now that I was confusing two comparisons - the comparison of an address with a prefix in the policy table and the comparison of two addresses with each other. Comparing an address with a prefix in the policy table must continue for as many bits as are specified for the prefix in the policy table. Is that understanding correct? If so, given the redefinition of CommonPrefixLen(), do the definitions of Label() and Precedence() need to make this point explicit? > 1) explicitly add Rule 9 which is already implied. Is it? In the fourth paragraph of Section 5, the draft says If the eight rules fail to choose a single address, the tie-breaker is implementation-specific. I suppose one could say that since the draft does not specify an initial ordering, the ordering is implementation-specific, so therefore the tie-breaker is implementation specific :-) but that's not really the point. If the draft wants the ordering to be the tie-breaker I think it has to say so explicitly, as that would then exclude other tie-breaking mechanisms. It seems to me that the draft should be left as it is in this respect, and thus allow an implementation to use the original ordering if it wants to, but not demand it or expect it. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-p8mHU00+T968FwkZPnx/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAlAXONIACgkQFpl7eE7uYBdwJAD+IWiqKrXgwvh1wWJZN5CU7w4x pyQryzC8njcoI9YdhKUA+we0Ro3I4w3FTcUlhm/F+SrON+rwgX8toC4+MvFlLGZ8 =QkNK -----END PGP SIGNATURE----- --=-p8mHU00+T968FwkZPnx/-- From ichiroumakino@gmail.com Tue Jul 31 15:28:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8F921F85B4 for ; Tue, 31 Jul 2012 15:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnwJqZNfBpwk for ; Tue, 31 Jul 2012 15:28:18 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9E721F8577 for ; Tue, 31 Jul 2012 15:28:18 -0700 (PDT) Received: by ggnc4 with SMTP id c4so7166828ggn.31 for ; Tue, 31 Jul 2012 15:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=SGd2mrY8BnEbSYByrMJK0lhWMAV6li5hQ5NAuk93qrM=; b=FIJbcKVmELgyxOhh3J9SLD7a5fqVVbPetF4JQJ/CBkv8TSjNS+DobSHOYSh5eKuE/3 6CCP9TAADovOac4uumvdxI+LajM1bFEOGYO3qpLfyzofb7cmG/oAf5cihWxko2squJ4O k8w8I9nNdGDJau71TcGd2luMHZbjVcObt0jN27uamhsfg5ZbjqbolKWvT/G4Qcp5K1Gs 391l78oMRd3LwbJq8iy7P8Hr8P/k8kjvXTKWL9KFSIqmx22HEohE6Jk7aSRtlABCU8xP 3g529AoR3jTBh5Hh3oZ+sdG6h2d0IM/UiMYylri6A550bQQkhHJQREQ5tTCG/KCqKuOX rssA== Received: by 10.50.220.194 with SMTP id py2mr3487692igc.15.1343773697825; Tue, 31 Jul 2012 15:28:17 -0700 (PDT) Received: from sjc-vpn6-1138.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id c3sm2367730iga.8.2012.07.31.15.28.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 15:28:17 -0700 (PDT) Sender: Ole Troan From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Volunteers needed: Minute takers and jabber scribe Date: Tue, 31 Jul 2012 15:28:13 -0700 Message-Id: To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:28:19 -0000 hi, we will be doing minutes with etherpad = (http://tools.ietf.org/wg/6man/minutes). greatly appreciated if we could get a couple of volunteers for minute = taking and jabber scribing ahead of tomorrows meeting. Best regards, Ole & Bob= From dthaler@microsoft.com Tue Jul 31 15:40:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E15721F8738 for ; Tue, 31 Jul 2012 15:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XOMFQ9QT5d8 for ; Tue, 31 Jul 2012 15:40:18 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id E32CA21F86EB for ; Tue, 31 Jul 2012 15:40:17 -0700 (PDT) Received: from mail166-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 22:40:06 +0000 Received: from mail166-ch1 (localhost [127.0.0.1]) by mail166-ch1-R.bigfish.com (Postfix) with ESMTP id 5E29E60272; Tue, 31 Jul 2012 22:40:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zz98dI9371I936eI542M1432I1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h93fhd25hf0ah107ah) Received-SPF: pass (mail166-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail166-ch1 (localhost.localdomain [127.0.0.1]) by mail166-ch1 (MessageSwitch) id 1343774405146317_9047; Tue, 31 Jul 2012 22:40:05 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail166-ch1.bigfish.com (Postfix) with ESMTP id 2186D240049; Tue, 31 Jul 2012 22:40:05 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 22:40:04 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 22:40:03 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Tue, 31 Jul 2012 15:40:02 -0700 From: Dave Thaler To: Karl Auer , "ipv6@ietf.org" Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() Thread-Topic: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen() Thread-Index: AQHNbSefWPJft5j+MUyaK6aT0cUFA5dCiZ7ggACN6oCAAOeS8A== Date: Tue, 31 Jul 2012 22:40:03 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7313E1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl> <9B57C850BB53634CACEC56EF4853FF653B72ECDD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <1343699165.26898.113.camel@karl> In-Reply-To: <1343699165.26898.113.camel@karl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:40:19 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBLYXJsIEF1 ZXINCj4gU2VudDogTW9uZGF5LCBKdWx5IDMwLCAyMDEyIDY6NDYgUE0NCj4gVG86IGlwdjZAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUkU6IHF1ZXN0aW9uIGFib3V0IGRyYWZ0LWlldGYtNm1hbi1yZmMz NDg0YmlzLTA2LnR4dCBhbmQNCj4gQ29tbW9uUHJlZml4TGVuKCkNCj4gDQo+IE9uIFR1ZSwgMjAx Mi0wNy0zMSBhdCAwMDoyOCArMDAwMCwgRGF2ZSBUaGFsZXIgd3JvdGU6DQo+ID4gVGhlIGJpdHMg aW4gdGhlIGludGVyZmFjZSBpZGVudGlmaWVyIGFyZSBub3QgaW5kaWNhdGl2ZSBvZiBnb29kbmVz cyBvcg0KPiA+IGFwcHJvcHJpYXRlbmVzcyBvciB3aGF0ZXZlci4NCj4gDQo+IEZpcnN0bHksIHRo YW5rcyBmb3IgdGhlIGV4dGVuc2l2ZSBleHBsYW5hdGlvbi4NCj4gDQo+IEkgcmVhbGlzZSBub3cg dGhhdCBJIHdhcyBjb25mdXNpbmcgdHdvIGNvbXBhcmlzb25zIC0gdGhlIGNvbXBhcmlzb24gb2Yg YW4NCj4gYWRkcmVzcyB3aXRoIGEgcHJlZml4IGluIHRoZSBwb2xpY3kgdGFibGUgYW5kIHRoZSBj b21wYXJpc29uIG9mIHR3byBhZGRyZXNzZXMNCj4gd2l0aCBlYWNoIG90aGVyLg0KPiANCj4gQ29t cGFyaW5nIGFuIGFkZHJlc3Mgd2l0aCBhIHByZWZpeCBpbiB0aGUgcG9saWN5IHRhYmxlIG11c3Qg Y29udGludWUgZm9yIGFzDQo+IG1hbnkgYml0cyBhcyBhcmUgc3BlY2lmaWVkIGZvciB0aGUgcHJl Zml4IGluIHRoZSBwb2xpY3kgdGFibGUuDQo+IA0KPiBJcyB0aGF0IHVuZGVyc3RhbmRpbmcgY29y cmVjdD8gDQoNClRoYXQgaXMgY29ycmVjdC4gIFRoZSBDb21tb25QcmVmaXhMZW4oKS4gYWxnb3Jp dGhtIGlzIG9ubHkgcmVsZXZhbnQgaW4gdGhlIGNvbnRleHQgb2YgcnVsZXMNCnRoYXQgZXhwbGlj aXRseSBzYXkgc28uICAgUHJlZml4IHBvbGljeSB0YWJsZSBsb29rdXBzIGFyZSBub3QgaW4gdGhh dCBjYXRlZ29yeQ0KDQo+IElmIHNvLCBnaXZlbiB0aGUgcmVkZWZpbml0aW9uIG9mDQo+IENvbW1v blByZWZpeExlbigpLCBkbyB0aGUgZGVmaW5pdGlvbnMgb2YgTGFiZWwoKSBhbmQgUHJlY2VkZW5j ZSgpIG5lZWQgdG8NCj4gbWFrZSB0aGlzIHBvaW50IGV4cGxpY2l0Pw0KDQpNeSBvcGluaW9uOiBu bywgaXQgYWxyZWFkeSBzZWVtcyBleHBsaWNpdCBlbm91Z2ggdG8gbWUuDQoNCj4gPiAxKSBleHBs aWNpdGx5IGFkZCBSdWxlIDkgd2hpY2ggaXMgYWxyZWFkeSBpbXBsaWVkLg0KPiANCj4gSXMgaXQ/ IEluIHRoZSBmb3VydGggcGFyYWdyYXBoIG9mIFNlY3Rpb24gNSwgdGhlIGRyYWZ0IHNheXMNCj4g DQo+ICAgICAgSWYgdGhlIGVpZ2h0IHJ1bGVzIGZhaWwgdG8gY2hvb3NlIGEgc2luZ2xlIGFkZHJl c3MsDQo+ICAgICAgdGhlIHRpZS1icmVha2VyIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLg0K DQpUcnVlLiAgIEkgZm9yZ290IHRoYXQsIHNvIG5vIGVkaXRvcmlhbCBjaGFuZ2UgaXMgbmVlZGVk LCBpdCdzIGFscmVhZHkgZXhwbGljaXQNCmFzIHlvdSBwb2ludCBvdXQuDQoNCj4gSSBzdXBwb3Nl IG9uZSBjb3VsZCBzYXkgdGhhdCBzaW5jZSB0aGUgZHJhZnQgZG9lcyBub3Qgc3BlY2lmeSBhbiBp bml0aWFsDQo+IG9yZGVyaW5nLCB0aGUgb3JkZXJpbmcgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lm aWMsIHNvIHRoZXJlZm9yZSB0aGUgdGllLQ0KPiBicmVha2VyIGlzIGltcGxlbWVudGF0aW9uIHNw ZWNpZmljIDotKSBidXQgdGhhdCdzIG5vdCByZWFsbHkgdGhlIHBvaW50LiBJZiB0aGUNCj4gZHJh ZnQgd2FudHMgdGhlIG9yZGVyaW5nIHRvIGJlIHRoZSB0aWUtYnJlYWtlciBJIHRoaW5rIGl0IGhh cyB0byBzYXkgc28NCj4gZXhwbGljaXRseSwgYXMgdGhhdCB3b3VsZCB0aGVuIGV4Y2x1ZGUgb3Ro ZXIgdGllLWJyZWFraW5nIG1lY2hhbmlzbXMuDQo+DQo+IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhl IGRyYWZ0IHNob3VsZCBiZSBsZWZ0IGFzIGl0IGlzIGluIHRoaXMgcmVzcGVjdCwgYW5kIHRodXMN Cj4gYWxsb3cgYW4gaW1wbGVtZW50YXRpb24gdG8gdXNlIHRoZSBvcmlnaW5hbCBvcmRlcmluZyBp ZiBpdCB3YW50cyB0bywgYnV0IG5vdA0KPiBkZW1hbmQgaXQgb3IgZXhwZWN0IGl0Lg0KDQpBZ3Jl ZWQuDQoNClNvIHRoZSBvbmx5IGVkaXRvcmlhbCBjaGFuZ2Ugd2UgY291bGQgY29uc2lkZXIgaXMg YWRkaW5nIGEgc2VudGVuY2UgdG8NCkFwcGVuZGl4IEIgbm90aW5nIHRoZSBzb3VyY2UgcnVsZSB3 YXMgYWZmZWN0ZWQgYnkgdGhlIGNoYW5nZSBhcyB3ZWxsLg0KDQotRGF2ZQ0KDQo+IFJlZ2FyZHMs IEsuDQo+IA0KPiAtLQ0KPiB+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+DQo+IH5+fn5+fn5+fn5+fn4NCj4gS2FybCBBdWVyIChrYXVlckBi aXBsYW5lLmNvbS5hdSkNCj4gaHR0cDovL3d3dy5iaXBsYW5lLmNvbS5hdS9rYXVlcg0KPiBodHRw Oi8vd3d3LmJpcGxhbmUuY29tLmF1L2Jsb2cNCj4gDQo+IEdQRyBmaW5nZXJwcmludDogQUUxRCA0 ODY4IDY0MjAgQUQ5QSBBNjk4IDUyNTEgMTY5OSA3Qjc4IDRFRUUgNjAxNyBPbGQNCj4gZmluZ2Vy cHJpbnQ6IERBNDEgNTFCMSAxNDgxIDE2RTEgRjdFMiBCMkU5IDMwMDcgMTRFRCA1NzM2IEY2ODcN Cg== From internet-drafts@ietf.org Tue Jul 31 16:48:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5426111E80DC; Tue, 31 Jul 2012 16:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxY7xyoJbym3; Tue, 31 Jul 2012 16:48:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A99011E808E; Tue, 31 Jul 2012 16:48:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-impatient-nud-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120731234819.20604.58552.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2012 16:48:19 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:48:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Neighbor Unreachability Detection is too impatient Author(s) : Erik Nordmark Igor Gashinsky Filename : draft-ietf-6man-impatient-nud-02.txt Pages : 8 Date : 2012-07-31 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-impatient-nud-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nordmark@acm.org Tue Jul 31 16:50:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424B421F898A for ; Tue, 31 Jul 2012 16:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.155 X-Spam-Level: X-Spam-Status: No, score=-103.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKxrrUT75PKQ for ; Tue, 31 Jul 2012 16:50:47 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id C92BC21F897F for <6man@ietf.org>; Tue, 31 Jul 2012 16:50:44 -0700 (PDT) Received: from [10.21.92.49] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q6VNofsC029958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 16:50:41 -0700 Message-ID: <50186F50.8090106@acm.org> Date: Tue, 31 Jul 2012 16:50:40 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: 6man@ietf.org Subject: Fwd: New Version Notification for draft-ietf-6man-impatient-nud-02.txt References: <20120731234819.20604.39168.idtracker@ietfa.amsl.com> In-Reply-To: <20120731234819.20604.39168.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120731234819.20604.39168.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 Jul 2012 23:05:34 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:50:48 -0000 -------- Original Message -------- Subject: New Version Notification for draft-ietf-6man-impatient-nud-02.txt Date: Tue, 31 Jul 2012 16:48:19 -0700 From: To: CC: A new version of I-D, draft-ietf-6man-impatient-nud-02.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-ietf-6man-impatient-nud Revision: 02 Title: Neighbor Unreachability Detection is too impatient Creation date: 2012-07-31 WG ID: 6man Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-impatient-nud-02.txt Status: http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud Htmlized: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-impatient-nud-02 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. The IETF Secretariat