From internet-drafts@ietf.org Fri Jul 1 01:40:40 2011 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 B477E21F86E2; Fri, 1 Jul 2011 01:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJcIZabVYScJ; Fri, 1 Jul 2011 01:40:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5D821F869A; Fri, 1 Jul 2011 01:40:40 -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-rfc3484-revise-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110701084040.29447.75078.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2011 01:40:40 -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: Fri, 01 Jul 2011 08:40:40 -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= IETF. Title : Update to RFC 3484 Default Address Selection for IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro Fujisaki Tim Chown Filename : draft-ietf-6man-rfc3484-revise-04.txt Pages : 12 Date : 2011-07-01 RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-04.txt From dwmalone@maths.tcd.ie Fri Jul 1 02:49:45 2011 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 C5F1911E8109 for ; Fri, 1 Jul 2011 02:49:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAfrb8zR+xRJ for ; Fri, 1 Jul 2011 02:49:45 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by ietfa.amsl.com (Postfix) with SMTP id B602911E80F6 for ; Fri, 1 Jul 2011 02:49:43 -0700 (PDT) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 1 Jul 2011 10:49:42 +0100 (BST) Date: Fri, 1 Jul 2011 10:49:42 +0100 From: David Malone To: Bob Hinden Subject: Re: 6MAN WG Last Call: Message-ID: <20110701094942.GA95635@walton.maths.tcd.ie> References: <0D404626-3B18-41EA-839D-43FDA972842B@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D404626-3B18-41EA-839D-43FDA972842B@gmail.com> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: Brian Haberman , 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: Fri, 01 Jul 2011 09:49:45 -0000 I was a little surprised by this document when I read it. The title is "An uniform format for IPv6 extension headers", and the abstract reads as I'd expect. However, when we get to section 3 (Applicability) "SHOULD" and "MUST" are used, *not* to require people to use a uniform format for IPv6 extension headers, but instead: 1) implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information 2) The request for creation of a new IPv6 extension header MUST be accompanied by an specific explanation of why destination options could not be used 3) new IPv6 Extension Header(s) having hop-by-hop behaviour MUST NOT be created or specified 4) new options for the existing Hop-by-Hop Header SHOULD NOT be created or specified unless no alternative is feasible 5) new optional information to be sent SHOULD be encoded in a new option for the existing IPv6 Destination Options Header 6) new IPv6 extension headers MUST NOT be created or specified, unless no existing IPv6 Extension Header can be used 7) Any proposal to create or specify a new IPv6 Extension Header MUST include a detailed technical explanation of why no existing IPv6 Extension Header can be used I don't particularly object to any of these, but none of these relate to the format of IPv6 extension headers. When we get to section 4, which details the uniform format, no SHOULD or MUST language is present. This seems to mean that the document's title and abstract do not match the imperative content of the document. Fixing this could be a simple as changing the title and abstract, plus possibly adding something in Section 4 to actually encourage use of the uniform format. I've also noted a few more minor points below. David. Title: "An Uniform" - for me this should be "A Uniform". Googling for both says "A Uniform" is more used by about 40-1, but also brings up some documents explaining the disagreement. Section 1: "Also, Several" -> "Also, several" Section 3: I think there's an unwanted page break after the first paragraph of section 3. Section 4: Should you give a reference to the IANA protocol numbers registery when you desceibe Next Header? Section 5 should probably give a list of the existing headers that do follow this format. From rja.lists@gmail.com Fri Jul 1 07:00:51 2011 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 2829A1F0C6B for ; Fri, 1 Jul 2011 07:00:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3uZH-b1CbO9 for ; Fri, 1 Jul 2011 07:00:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 722581F0C6A for ; Fri, 1 Jul 2011 07:00:50 -0700 (PDT) Received: by vxi40 with SMTP id 40so2924965vxi.31 for ; Fri, 01 Jul 2011 07:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=G1RSzm4eQGRVeKt64DehlkhhKdzgEfbvHfif9FlkXwc=; b=xgJYIKU+03yt/k0gPfAOBHOpguYfvKHmClGpq3Z2zIE9CAL1m7xijiBHB8iHMaIr7F yREt2jASUviHhPWYSpQMIXYAXyOKjJ+MauoCCQWp97tlShVmGqdcpdo5ozhRBqgJCPHD BRFToNS1OinG1UCGf5W8vc8X9mtvPrUJkkpqU= Received: by 10.52.94.50 with SMTP id cz18mr845566vdb.299.1309528848810; Fri, 01 Jul 2011 07:00:48 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id q1sm1267162vdt.23.2011.07.01.07.00.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 07:00:47 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: 6MAN WG Last Call: Date: Fri, 1 Jul 2011 10:00:45 -0400 Message-Id: <894ABDC2-238A-41AC-831A-D816E2DAD0A2@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 01 Jul 2011 14:00:51 -0000 On 30th June 2011, Bob Hinden wrote: > This message starts a two week 6MAN Working Group Last Call on advancing: > > Title : An uniform format for IPv6 extension headers > Author(s) : Suresh Krishnan > Erik Kline > James Hoagland > Manav Bhatia > Filename : draft-ietf-6man-exthdr-03.txt > Pages : 8 > Date : 2011-06-27 > > > http://tools.ietf.org/html/draft-ietf-6man-exthdr-03 > > > as a Proposed Standard. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call > will end on 14 July 2011. I support publishing this as a Proposed Standard. This revision resolves my earlier concerns that it is highly undesirable to define *any* new IPv6 Extension Headers (since defining any new IPv6 Extension Header will break multiple existing IPv6 deployments). On 1st July 2011, David Malone wrote, in part: > Fixing this could be a simple as changing the title and abstract, > plus possibly adding something in Section 4 to actually encourage > use of the uniform format. I do not have any philosophical objections to the suggested edit of the document Title and expansion of the Abstract. Perhaps the lone sentence in Section 4 could be reworded into RFC-2119 language. Candidate replacement text might be: If any IPv6 Extension Headers are defined in future, keeping in mind the restrictions above in Section 3 and also the restrictions specified in RFC-2460, they MUST use the consistent format defined in Figure 1. This enables future IPv6 implementations to skip over unknown IPv6 Extension Headers and continue to further process the IPv6 header chain. Yours, Ran From kauer@biplane.com.au Fri Jul 1 15:53:32 2011 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 8A91311E81EB for ; Fri, 1 Jul 2011 15:53:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs0pziCXFNEC for ; Fri, 1 Jul 2011 15:53:31 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6488311E8206 for ; Fri, 1 Jul 2011 15:53:29 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QcmaV-0000cj-IF for ipv6@ietf.org; Fri, 01 Jul 2011 18:53:27 -0400 Subject: Re: 6MAN WG Last Call: From: Karl Auer To: IETF IPv6 In-Reply-To: <894ABDC2-238A-41AC-831A-D816E2DAD0A2@gmail.com> References: <894ABDC2-238A-41AC-831A-D816E2DAD0A2@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-vw3uYwMYw4F7WOwijjH9" Date: Sat, 02 Jul 2011 08:53:24 +1000 Message-ID: <1309560804.4314.54.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 01 Jul 2011 22:53:32 -0000 --=-vw3uYwMYw4F7WOwijjH9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2011-07-01 at 10:00 -0400, RJ Atkinson wrote: > This revision resolves my earlier concerns that it is > highly undesirable to define *any* new IPv6 Extension Headers > (since defining any new IPv6 Extension Header will break=20 > multiple existing IPv6 deployments). It seems strange to me that we define "IPv6 Extension Headers", then refuse to allow any further extensions! That was largely the point and purpose of the exercise. That said, it is always "highly undesirable" to make changes to a deployed protocol UNLESS the changes can safely be ignored. It will depend on the function of any future extension headers as to whether they will be able to be safely ignored. On the other hand, if an extension is needed, then it is needed, and the community will have to make the tradeoff between the undesirability of a change and the desirability of a new feature. This draft means that if an application runs into headers it does not understand, then at least it can skip them neatly. If *skipping* them causes problems, then at least the authors *should have* been aware that new extension headers might come along, and *should have* planned for that in some way. Hm, I think I might just have used more words to say what you said :-) Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-vw3uYwMYw4F7WOwijjH9 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) iEYEABECAAYFAk4OT94ACgkQMAcU7Vc29occ/QCeNNf7QYhW5Jb7hodLHBkn6XFG SqQAn0HlQiG8lfVQAHIffKK0RYgJh6zH =zwZD -----END PGP SIGNATURE----- --=-vw3uYwMYw4F7WOwijjH9-- From rja.lists@gmail.com Sat Jul 2 11:39:18 2011 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 93E981F0C5A for ; Sat, 2 Jul 2011 11:39:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLqOn2KggCfO for ; Sat, 2 Jul 2011 11:39:18 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E71331F0C59 for ; Sat, 2 Jul 2011 11:39:17 -0700 (PDT) Received: by qwc23 with SMTP id 23so3421362qwc.31 for ; Sat, 02 Jul 2011 11:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=6nzI3KzWOyEdOPpMu4gM9n6xyr8hO94vfNe+IfpG0y4=; b=lSuoEMf/lHoz62GpbFDUJpB0L/f73tjVO3Y4zV/jBx6agV+C8DxjPmkrl8Y57kL+h3 vsxUVnBdeu0S9JUwExLyMJH96xvQSOOFaSUV8g8kkb5t9E9xuzrO4TXiuy3FFLEfDinm ObAfXQ+tZD4xSErzOUureK1Ce6CImC9SWKegI= Received: by 10.229.21.2 with SMTP id h2mr3538699qcb.141.1309631957396; Sat, 02 Jul 2011 11:39:17 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id r33sm3496288qcs.30.2011.07.02.11.39.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Jul 2011 11:39:16 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: 6MAN WG Last Call: Date: Sat, 2 Jul 2011 14:39:14 -0400 Message-Id: <975ACE23-6DC4-4D34-885C-2E30E449FD79@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 02 Jul 2011 18:39:18 -0000 On 2nd July 2011, Karl Auer wrote, in part: > It seems strange to me that we define "IPv6 Extension Headers", > then refuse to allow any further extensions! Kindly note that this document does NOT prohibit future IPv6 extensions. That is a mis-understanding of this document. Please re-read the actual document. Background: * IPv6 has always been specified and intended to carry future options and extensions inside the pre-defined "bucket" headers (e.g. Hop-by-Hop Header, Destination Options Header), each of which can contain multiple options concurrently. In slightly more detail... The document DOES now very clearly define the rules for creating new types of *headers*. These are mostly documentation rules. More dangerous behaviours, such as hop-by-hop behaviour, will require more documentation to justify the necessity of the more dangerous behaviour. In any event, it is important to recall that defining a new "header type" is very different from defining new IPv6 options or IPv6 extensions. Yours, Ran From kauer@biplane.com.au Sat Jul 2 16:15:15 2011 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 D467911E80CC for ; Sat, 2 Jul 2011 16:15:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu1kmAsEw1m8 for ; Sat, 2 Jul 2011 16:15:14 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0C321F8629 for ; Sat, 2 Jul 2011 16:15:13 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qd9P4-0004l9-Kp for ipv6@ietf.org; Sat, 02 Jul 2011 19:15:10 -0400 Subject: Re: 6MAN WG Last Call: From: Karl Auer To: ipv6@ietf.org In-Reply-To: <975ACE23-6DC4-4D34-885C-2E30E449FD79@gmail.com> References: <975ACE23-6DC4-4D34-885C-2E30E449FD79@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5cfJv7zZ3hqACkdxTdIb" Date: Sun, 03 Jul 2011 09:15:07 +1000 Message-ID: <1309648507.2490.13.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 02 Jul 2011 23:15:15 -0000 --=-5cfJv7zZ3hqACkdxTdIb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2011-07-02 at 14:39 -0400, RJ Atkinson wrote: > On 2nd July 2011, Karl Auer wrote, in part: > > It seems strange to me that we define "IPv6 Extension Headers", > > then refuse to allow any further extensions! >=20 > Kindly note that this document does NOT prohibit future IPv6 extensions. > That is a mis-understanding of this document. I was not taking issue with the document, I was just commenting on your assertion that it would be "highly undesirable" to create more extension headers. Sorry to have been unclear about that. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-5cfJv7zZ3hqACkdxTdIb 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) iEYEABECAAYFAk4PpnUACgkQMAcU7Vc29oeXJACaA8kmLsYmnPDG2YN9AixVwwXu YLYAmgNXUxnrVqDAWY90QKueHWxb425Z =xBfR -----END PGP SIGNATURE----- --=-5cfJv7zZ3hqACkdxTdIb-- From kauer@biplane.com.au Sun Jul 3 10:04:04 2011 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 4C4ED21F874B for ; Sun, 3 Jul 2011 10:04:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKfIOK2RktlI for ; Sun, 3 Jul 2011 10:04:03 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0C48721F862B for ; Sun, 3 Jul 2011 10:04:01 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdQ5P-0000ux-Bj for ipv6@ietf.org; Sun, 03 Jul 2011 13:03:59 -0400 Subject: subnet router anycast From: Karl Auer To: IETF IPv6 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Jn0DNpV5IgF007xhs2LK" Date: Mon, 04 Jul 2011 03:03:56 +1000 Message-ID: <1309712636.2490.203.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 03 Jul 2011 17:04:04 -0000 --=-Jn0DNpV5IgF007xhs2LK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Which RFCs (or other sources) describe how IPv6 subnet anycast *works*? In particular how it works when there are multiple routers in a single subnet? Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-Jn0DNpV5IgF007xhs2LK 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) iEYEABECAAYFAk4QoPUACgkQMAcU7Vc29ocVBwCgmwizW0wTjODigd+Y2L2AM9pY 26EAoL3BCJs1pFO+vgMgto50RLXUae3H =tIvw -----END PGP SIGNATURE----- --=-Jn0DNpV5IgF007xhs2LK-- From roland.bless@kit.edu Sun Jul 3 14:50:36 2011 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 E48F311E80CB for ; Sun, 3 Jul 2011 14:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVUEUbs2MkVQ for ; Sun, 3 Jul 2011 14:50:36 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1A11E80AE for ; Sun, 3 Jul 2011 14:50:35 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1QdUYd-00028k-GC; Sun, 03 Jul 2011 23:50:32 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 20A46A80007; Sun, 3 Jul 2011 23:50:26 +0200 (CEST) Message-ID: <4E10E421.5020804@kit.edu> Date: Sun, 03 Jul 2011 23:50:25 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Karl Auer Subject: Re: subnet router anycast References: <1309712636.2490.203.camel@karl> In-Reply-To: <1309712636.2490.203.camel@karl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1309729833.050505000 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, 03 Jul 2011 21:50:37 -0000 Hi, On 03.07.2011 19:03, Karl Auer wrote: > Which RFCs (or other sources) describe how IPv6 subnet anycast *works*? > In particular how it works when there are multiple routers in a single > subnet? That's a good question. I was also looking for that. It's distributed across various RFCs: ----------------------------------------------------------------------- RFC4291: "A node is required to compute and join (on the appropriate interface) the associated Solicited-Node multicast addresses for all unicast and anycast addresses that have been configured for the node's interfaces (manually or automatically)." RFC 4861: 7.2.7. Anycast Neighbor Advertisements From the perspective of Neighbor Discovery, anycast addresses are treated just like unicast addresses in most cases. Because an anycast address is syntactically the same as a unicast address, nodes performing address resolution or Neighbor Unreachability Detection on an anycast address treat it as if it were a unicast address. No special processing takes place. Nodes that have an anycast address assigned to an interface treat them exactly the same as if they were unicast addresses with two exceptions. First, Neighbor Advertisements sent in response to a Neighbor Solicitation SHOULD be delayed by a random time between 0 and MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, so that when multiple advertisements are received, the first received advertisement is used rather than the most recently received advertisement. As with unicast addresses, Neighbor Unreachability Detection ensures that a node quickly detects when the current binding for an anycast address becomes invalid. RFC 4862: - Duplicate Address Detection MUST NOT be performed on anycast addresses (note that anycast addresses cannot syntactically be distinguished from unicast addresses). ---------------------------------------------------------------------- Multiple Routers are usually not a problem since only one gets the packet for forwarding into the subnet. Regards, Roland From randy@psg.com Sun Jul 3 15:02:02 2011 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 0A06511E80AE for ; Sun, 3 Jul 2011 15:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7v3U1rwVS3c for ; Sun, 3 Jul 2011 15:02:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 105CA11E8080 for ; Sun, 3 Jul 2011 15:02:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdUjf-000IFE-6M; Sun, 03 Jul 2011 22:01:51 +0000 Date: Mon, 04 Jul 2011 07:01:50 +0900 Message-ID: From: Randy Bush To: Roland Bless Subject: Re: subnet router anycast In-Reply-To: <4E10E421.5020804@kit.edu> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 03 Jul 2011 22:02:02 -0000 Network Working Group R. Bush Internet-Draft IIJ Intended status: Standards Track August 2010 Expires: February 2, 2011 IPv6 Subnet Anycast Deprecated draft-ymbk-no-subnet-anycast-00 Abstract IPv6 subnet anycast is not used operationally, complicates implementations, and complicates protocol specifications. The form of anycast actually used in the Internet is routing-based, and is essentilly the same as that of IPv4 anycast. Therefore, this document deprecates IPv6 subnet anycast. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 2, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bush Expires February 2, 2011 [Page 1] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Normative References . . . . . . . . . . . . . . . . . . . 3 4.2. Informative References . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Bush Expires February 2, 2011 [Page 2] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 1. Introduction The form of anycast which is used in the operational internet is described in [RFC4786]. This is used widely in IPv4 and IPv6. To quote, "To distribute a service using anycast, the service is first associated with a stable set of IP addresses, and reachability to those addresses is advertised in a routing system from multiple, independent service nodes." IPv6 subnet anycast, as defined in [RFC2526], complicates host and router stacks. It also makes address assignment unnecessarily complex, see [I-D.kohno-ipv6-prefixlen-p2p]. IPv6 subnet anycast is not actually used or deployed. In this case, it is sure that implementations are not even debugged. Therefore, this document deprecates IPv6 subnet anycast and removes conformance requirements from host and router implementations. 2. Security Considerations There are no known security implications for this document. 3. IANA Considerations This document has no IANA Considerations. 4. References 4.1. Normative References [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. 4.2. Informative References [I-D.kohno-ipv6-prefixlen-p2p] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., and L. Colitti, "Using 127-bit IPv6 Prefixes on Inter-Router Links", draft-kohno-ipv6-prefixlen-p2p-02 (work in progress), July 2010. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Bush Expires February 2, 2011 [Page 3] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 Services", BCP 126, RFC 4786, December 2006. Author's Address Randy Bush Internet Initiative Japan, Inc. 5147 Crystal Springs Bainbridge Island, Washington 98110 US Phone: +1 206 780 0431 x1 Email: randy@psg.com Bush Expires February 2, 2011 [Page 4] From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 3 16:55:09 2011 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 E76A221F85B6 for ; Sun, 3 Jul 2011 16:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMVtHhxZbcSM for ; Sun, 3 Jul 2011 16:55:09 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 5F10721F85B5 for ; Sun, 3 Jul 2011 16:55:09 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdWVF-000880-M4; Mon, 04 Jul 2011 09:25:05 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 301E43B33E; Mon, 4 Jul 2011 09:25:05 +0930 (CST) Date: Mon, 4 Jul 2011 09:25:04 +0930 From: Mark Smith To: Roland Bless Subject: Re: subnet router anycast Message-ID: <20110704092504.69a70911@opy.nosense.org> In-Reply-To: <4E10E421.5020804@kit.edu> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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, 03 Jul 2011 23:55:10 -0000 Hi, On Sun, 03 Jul 2011 23:50:25 +0200 Roland Bless wrote: > Hi, > > On 03.07.2011 19:03, Karl Auer wrote: > > Which RFCs (or other sources) describe how IPv6 subnet anycast *works*? > > In particular how it works when there are multiple routers in a single > > subnet? > > That's a good question. I was also looking for that. It's distributed > across various RFCs: > ----------------------------------------------------------------------- To make a higher level observation, I don't think it is any different to the operation of host anycast, as the destination address in the packet matches one of the router's own addresses, so the router would process the packet in "host mode" rather than "forwarding mode". I suspect it was inspired by Appletalk's assignment of node ID zero on each cable range to attached routers. That in turn was used by the Name Binding Protocol for mapping host names to DDP addresses. Since the goals of Multicast DNS and DNS-based Service Discovery are similar to NBP, it may be possible that IPv6 router anycast could be used in a similar way with mDNS and DNS-SD. Here's an ID on the topic of NBP/mDNS/DNS-SD - http://tools.ietf.org/html/draft-cheshire-dnsext-nbp-10 If you're interested in the Appletalk spec that talks about DDP and NBP, do an Internet search for "Inside Appletalk". It used to be a freely downloadable PDF on Apple's website, but it seems to have disappeared. Regards, Mark. From joelja@bogus.com Sun Jul 3 16:57:20 2011 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 4EF8C21F85BF; Sun, 3 Jul 2011 16:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mcYdKNxDf3j; Sun, 3 Jul 2011 16:57:20 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9778E21F85D5; Sun, 3 Jul 2011 16:57:19 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p63NvGSR045801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Jul 2011 23:57:17 GMT (envelope-from joelja@bogus.com) Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Sun, 3 Jul 2011 16:57:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5023B51E-7D7D-43EB-B8FC-FF9BE13D5867@bogus.com> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Jul 2011 23:57:17 +0000 (UTC) Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , Ted Lemon 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, 03 Jul 2011 23:57:20 -0000 On Jun 23, 2011, at 2:31 PM, Manfredi, Albert E wrote: > Ted Lemon wrote: >=20 >> That's correct. Ultimately the security of the client depends on = the >> client being secure. Trying to secure the client by securing the >> network is a noble cause, but ultimately doomed to failure, because = you >> can't control what networks the client connects to. >=20 > No, I think you have it backwards. >=20 > It is service providers that are interested in protecting their = networks, in this discussion. If they also happen to protect their = clients, that is just a nice byproduct. >=20 > Service providers want to keep malicious clients from degrading their = network. as the former operator of some university residence hall networks, the = goal is to minimize damage in a common l2 broadcast domain. = Misconfigured or malicious users both cause similar sorts of damage, = there's dramatically more of the former than the later. > Bert >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From kauer@biplane.com.au Sun Jul 3 17:06:12 2011 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 92FA521F8541 for ; Sun, 3 Jul 2011 17:06:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPQNHfdFVr2F for ; Sun, 3 Jul 2011 17:06:12 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id A68F221F8540 for ; Sun, 3 Jul 2011 17:06:11 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdWfx-0004YW-56 for ipv6@ietf.org; Sun, 03 Jul 2011 20:06:09 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DPK7jRAGApi77W80xOoH" Date: Mon, 04 Jul 2011 10:06:07 +1000 Message-ID: <1309737967.2490.218.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 00:06:12 -0000 --=-DPK7jRAGApi77W80xOoH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 07:01 +0900, Randy Bush wrote: > Intended status: Standards Track August 2010 > Expires: February 2, 2011 > IPv6 Subnet Anycast Deprecated > draft-ymbk-no-subnet-anycast-00 >=20 > Abstract >=20 > IPv6 subnet anycast is not used operationally, complicates > implementations, and complicates protocol specifications. The form > of anycast actually used in the Internet is routing-based, and is > essentilly the same as that of IPv4 anycast. Therefore, this > document deprecates IPv6 subnet anycast. Does this apply to subnet *router* anycast, or just subnet anycast? The two are not quite the same, and the draft doesn't mention RFC4291. I'd agree wholeheartedly with deprecating them both! But this draft expired some months ago - what are its chances? Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-DPK7jRAGApi77W80xOoH 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) iEYEABECAAYFAk4RA+YACgkQMAcU7Vc29oeoZwCfRDcKaMn5WChbwFvJZSPsmMv1 LeAAnAnx7u7QEPkPnhZJ1bODmdVFot/6 =BBUv -----END PGP SIGNATURE----- --=-DPK7jRAGApi77W80xOoH-- From kauer@biplane.com.au Sun Jul 3 17:13:54 2011 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 A7B221F0C5F for ; Sun, 3 Jul 2011 17:13:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvNWa3F+GmRJ for ; Sun, 3 Jul 2011 17:13:54 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 126E61F0C56 for ; Sun, 3 Jul 2011 17:13:53 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdWnQ-000611-Vz for ipv6@ietf.org; Sun, 03 Jul 2011 20:13:53 -0400 Subject: Re: subnet router anycast From: Karl Auer To: ipv6@ietf.org In-Reply-To: <20110704092504.69a70911@opy.nosense.org> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <20110704092504.69a70911@opy.nosense.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-l0o0UsI/sITgsQ+xtyQc" Date: Mon, 04 Jul 2011 10:13:51 +1000 Message-ID: <1309738431.2490.223.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 00:13:54 -0000 --=-l0o0UsI/sITgsQ+xtyQc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 09:25 +0930, Mark Smith wrote: > To make a higher level observation, I don't think it is any different > to the operation of host anycast, as the destination address in the > packet matches one of the router's own addresses, so the router would > process the packet in "host mode" rather than "forwarding mode".=20 The big difference for me is that subnet anycast has to function without the benefit of any routing as such - i.e., within a subnet. So something was going on that was very different to IPv4 multicast IPv4. It was the detail of how DAD, ND etc worked that had eluded me, thanks for that excellent, concise answer. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-l0o0UsI/sITgsQ+xtyQc 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) iEYEABECAAYFAk4RBb8ACgkQMAcU7Vc29odwjwCfalBaFjztCuAEwaHudu+2C/g9 LlIAoKdzS4qMZxHlXir8t9A+Up1WSYnV =YmBW -----END PGP SIGNATURE----- --=-l0o0UsI/sITgsQ+xtyQc-- From randy@psg.com Sun Jul 3 18:12:45 2011 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 BEB6C1F0C54 for ; Sun, 3 Jul 2011 18:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ-Uho32bkOy for ; Sun, 3 Jul 2011 18:12:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF721F0C53 for ; Sun, 3 Jul 2011 18:12:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdXiM-000JEI-C6; Mon, 04 Jul 2011 01:12:42 +0000 Date: Mon, 04 Jul 2011 10:12:41 +0900 Message-ID: From: Randy Bush To: Karl Auer Subject: Re: subnet router anycast In-Reply-To: <1309737967.2490.218.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF IPv6 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, 04 Jul 2011 01:12:45 -0000 > I'd agree wholeheartedly with deprecating them both! But this draft > expired some months ago - what are its chances? i was discouraged by bob from submitting it. dreadine approacheth. should i? randy From SRS0=bfWxgr=ZX=sneep.net=aj@srs.bis6.us.blackberry.com Sun Jul 3 18:24:31 2011 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 29A071F0C4F for ; Sun, 3 Jul 2011 18:24:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPSQnDUeeiQi for ; Sun, 3 Jul 2011 18:24:30 -0700 (PDT) Received: from smtp05.bis6.us.blackberry.com (smtp05.bis6.us.blackberry.com [74.82.85.5]) by ietfa.amsl.com (Postfix) with ESMTP id 239E91F0C41 for ; Sun, 3 Jul 2011 18:24:24 -0700 (PDT) Received: from b4.c22.bise6.blackberry ([192.168.0.104]) by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p641ONDW005909; Mon, 4 Jul 2011 01:24:23 GMT Received: from 172.29.215.183 (cmp13.c22.bise6.blackberry [172.29.215.183]) by b4.c22.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p641OLcc007184; Mon, 4 Jul 2011 01:24:21 GMT X-rim-org-msg-ref-id: 1997594372 Message-ID: <1997594372-1309742659-cardhu_decombobulator_blackberry.rim.net-784302467-@b26.c22.bise6.blackberry> X-Priority: Normal Sensitivity: Normal Importance: Normal Subject: Re: subnet router anycast To: "Randy Bush" From: "Alastair Johnson" Date: Mon, 4 Jul 2011 01:24:18 +0000 Content-Type: text/plain MIME-Version: 1.0 Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: aj@sneep.net List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 01:26:45 -0000 Yes please. aj ------Original Message------ From: Randy Bush Sender: ipv6-bounces@ietf.org To: Karl Auer Cc: IETF IPv6 Subject: Re: subnet router anycast Sent: 3 Jul 2011 18:12 > I'd agree wholeheartedly with deprecating them both! But this draft > expired some months ago - what are its chances? i was discouraged by bob from submitting it. dreadine approacheth. should i? randy -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From cb.list6@gmail.com Sun Jul 3 18:37:20 2011 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 EC8BA11E809C for ; Sun, 3 Jul 2011 18:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNRu16JSLwdh for ; Sun, 3 Jul 2011 18:37:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC3C11E8082 for ; Sun, 3 Jul 2011 18:37:20 -0700 (PDT) Received: by wyj26 with SMTP id 26so3640108wyj.31 for ; Sun, 03 Jul 2011 18:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gb1i91nq63QVW/YXzQtE+9lNTpr2MoVqdld/0UWyVKg=; b=TRucbO6BNAhlD6vkHwlcX9NtTepjwcaTfru1fB/jMBqOKRMW+0PeC+vyLXOQQTcskY L7qv8H+95OSdeVcUvNttwGyCvJdfcWAs67GKjklxHFV/2ZFbdyavhHnLw7BrtHkyiIS+ aiRXokVZxmIiIBQ1Gj2vVuaLR/73WcKUfGp3A= MIME-Version: 1.0 Received: by 10.216.198.146 with SMTP id v18mr1251369wen.94.1309743437425; Sun, 03 Jul 2011 18:37:17 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sun, 3 Jul 2011 18:37:17 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sun, 3 Jul 2011 18:37:17 -0700 (PDT) In-Reply-To: References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> Date: Sun, 3 Jul 2011 18:37:17 -0700 Message-ID: Subject: Re: subnet router anycast From: Cameron Byrne To: Randy Bush Content-Type: multipart/alternative; boundary=0016e6d59e1b55abe504a734687e Cc: IETF IPv6 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, 04 Jul 2011 01:37:21 -0000 --0016e6d59e1b55abe504a734687e Content-Type: text/plain; charset=ISO-8859-1 On Jul 3, 2011 6:13 PM, "Randy Bush" wrote: > > > I'd agree wholeheartedly with deprecating them both! But this draft > > expired some months ago - what are its chances? > > i was discouraged by bob from submitting it. dreadine approacheth. > should i? > Yes, please Cb > randy > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --0016e6d59e1b55abe504a734687e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 3, 2011 6:13 PM, "Randy Bush" <randy@psg.com> wrote:
>
> > I'd agree wholeheartedly with deprecating them both! But this= draft
> > expired some months ago - what are its chances?
>
> i was discouraged by bob from submitting it. =A0dreadine approacheth.<= br> > should i?
>

Yes, please

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

--0016e6d59e1b55abe504a734687e-- From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 3 20:58:13 2011 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 11F6E1F0C61 for ; Sun, 3 Jul 2011 20:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2-LOEY5oQRx for ; Sun, 3 Jul 2011 20:58:12 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 426161F0C53 for ; Sun, 3 Jul 2011 20:58:12 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdaIT-0001rk-VI; Mon, 04 Jul 2011 13:28:10 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 3FBA83B33E; Mon, 4 Jul 2011 13:28:09 +0930 (CST) Date: Mon, 4 Jul 2011 13:28:09 +0930 From: Mark Smith To: Karl Auer Subject: Re: subnet router anycast Message-ID: <20110704132809.25f4cac9@opy.nosense.org> In-Reply-To: <1309737967.2490.218.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 04 Jul 2011 03:58:13 -0000 On Mon, 04 Jul 2011 10:06:07 +1000 Karl Auer wrote: > On Mon, 2011-07-04 at 07:01 +0900, Randy Bush wrote: > > Intended status: Standards Track August 2010 > > Expires: February 2, 2011 > > IPv6 Subnet Anycast Deprecated > > draft-ymbk-no-subnet-anycast-00 > > > > Abstract > > > > IPv6 subnet anycast is not used operationally, complicates > > implementations, and complicates protocol specifications. The form > > of anycast actually used in the Internet is routing-based, and is > > essentilly the same as that of IPv4 anycast. Therefore, this > > document deprecates IPv6 subnet anycast. > > Does this apply to subnet *router* anycast, or just subnet anycast? The > two are not quite the same, and the draft doesn't mention RFC4291. > > I'd agree wholeheartedly with deprecating them both! But this draft > expired some months ago - what are its chances? > Perhaps we should wait until IPv6 traffic exceeds IPv4's before deciding. With the trivial amount of use that IPv6 currently has, it makes no sense to say history shows it hasn't been useful and should be deprecated. > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 From kauer@biplane.com.au Sun Jul 3 21:23:55 2011 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 F10A51F0C64 for ; Sun, 3 Jul 2011 21:23:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNUf3jKZjeWQ for ; Sun, 3 Jul 2011 21:23:54 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9541F0C61 for ; Sun, 3 Jul 2011 21:23:53 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdahK-0005oZ-Ij for ipv6@ietf.org; Mon, 04 Jul 2011 00:23:50 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: <20110704132809.25f4cac9@opy.nosense.org> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gvl3nVEPVh/YByX7eix3" Date: Mon, 04 Jul 2011 14:23:47 +1000 Message-ID: <1309753427.2490.299.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 04:23:55 -0000 --=-gvl3nVEPVh/YByX7eix3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 13:28 +0930, Mark Smith wrote: > Perhaps we should wait until IPv6 traffic exceeds IPv4's before > deciding. With the trivial amount of use that IPv6 currently has, it > makes no sense to say history shows it hasn't been useful and should be > deprecated. On the other hand, if we can see now that they are unlikely to be useful (and IMHO we *can* see that) then we are doing the world a service by helping all those vendors NOT implement it :-) There is no need for subnet anycast addresses, because any address can be an anycast address. Only the node where an anycast address is configured needs to know that it is an anycast address. That is, there is no need to be able to recognise such an address from its format. Has the use of IPv4 anycast been impeded by the inability to tell an anycast address from an ordinary address? There is also no need for subnet router anycast addresses, because a node wanting to contact a router can use the all-routers-on-link multicast address. Note that the subnet router anycast address doesn't even ensure that the "nearest" router is contacted, which would arguably have been useful, because the current spec deliberately builds in a small random delay in responding, to avoid network congestion. If I have missed some really good use for either set of anycast addresses, please let me know! Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-gvl3nVEPVh/YByX7eix3 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) iEYEABECAAYFAk4RQFMACgkQMAcU7Vc29ocIDwCffxwGerXBKYFr/mpEwu8JF1mJ BJwAn2NhE81/1V7h/xlV0BaAdrY93smI =jSxb -----END PGP SIGNATURE----- --=-gvl3nVEPVh/YByX7eix3-- From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 3 22:29:14 2011 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 9B85C21F85F9 for ; Sun, 3 Jul 2011 22:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97Dcu-7a7fLz for ; Sun, 3 Jul 2011 22:29:14 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id BC12921F8545 for ; Sun, 3 Jul 2011 22:29:13 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdbiS-0005R0-8H; Mon, 04 Jul 2011 14:59:04 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id BCEE73B33E; Mon, 4 Jul 2011 14:59:03 +0930 (CST) Date: Mon, 4 Jul 2011 14:59:03 +0930 From: Mark Smith To: Karl Auer Subject: Re: subnet router anycast Message-ID: <20110704145903.7765e0df@opy.nosense.org> In-Reply-To: <1309753427.2490.299.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 04 Jul 2011 05:29:14 -0000 Hi Karl, On Mon, 04 Jul 2011 14:23:47 +1000 Karl Auer wrote: > On Mon, 2011-07-04 at 13:28 +0930, Mark Smith wrote: > > Perhaps we should wait until IPv6 traffic exceeds IPv4's before > > deciding. With the trivial amount of use that IPv6 currently has, it > > makes no sense to say history shows it hasn't been useful and should be > > deprecated. > > On the other hand, if we can see now that they are unlikely to be useful > (and IMHO we *can* see that) then we are doing the world a service by > helping all those vendors NOT implement it :-) > I'd suggest many IPv6 implementations are, while possibly not well exercised, are quite mature. Anycast addresses have been in the IPv6 specs for many years, and there are a number of implementations. Cisco's IOS supports them, as does Linux, Windows and probably Mac OS X. > There is no need for subnet anycast addresses, because any address can > be an anycast address. Only the node where an anycast address is > configured needs to know that it is an anycast address. That is, there > is no need to be able to recognise such an address from its format. Has > the use of IPv4 anycast been impeded by the inability to tell an anycast > address from an ordinary address? > IPv4 anycast is a routing/forwarding plane trick (and a fault if not intended), and only works if the designated IPv4 anycast address is off link. It is not possible under IPv4 to have an on-link anycast address, because the routing/forwarding plane isn't involved. The same routing/forwarding plane trick will work with IPv6. What has been added in IPv6 is formal support of anycast addresses that are onlink within the neighbor discovery / address resolution protocol. To do the equivalent under IPv4 ARP would have to be changed. > There is also no need for subnet router anycast addresses, because a > node wanting to contact a router can use the all-routers-on-link > multicast address. Note that the subnet router anycast address doesn't > even ensure that the "nearest" router is contacted, which would arguably > have been useful, because the current spec deliberately builds in a > small random delay in responding, to avoid network congestion. > You seem to only looking at it from the point of view of a traffic source being onlink and wanting to send to the subnet router anycast address. The all-routers-on-link multicast address could not be used if the traffic source is off-link. Some scenarios where this might be useful is to be able to establish a BGP session over TCP with the closest router on the remote subnet, or perhaps a GRE or IPsec tunnel with the closest router on the remote subnet. If that router fails, anycast will take care of re-establishing these services to the next closest router without intervention. These scenarios aren't really that special, all you are doing is using anycast to access remote services that just happen to reside on a router instead of a host. > If I have missed some really good use for either set of anycast > addresses, please let me know! > I think another beneficial use of IPv6 (on-link) anycast could be to replace on-link multicast for NTP, reducing the multicast traffic on the segment. The NTP client would send to an anycast address (e.g. supplied via DHCPv6) that all the on-link NTP servers are configured with. IPv6 ND would resolve that anycast address to one of the NTP servers, and after that, all NTP traffic would be unicast between the client and the selected server. If the selected NTP server fails, IPv6 NUD would detect that, triggering another anycast ND address resolution process. Fail over detection doesn't need to be fast in this scenario because hosts run their own clocks (always easy to forget that NTP is a time sync, not a time supply service!), and NTP transactions normally happen only once every 60 seconds or so. There may be other similar IPv4 multicast applications I'm not aware of that could benefit from IPv6's formal anycast capability in a similar way when IPv6 support is added. Regards, Mark. From randy@psg.com Sun Jul 3 22:43:34 2011 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 ABB2A21F85E8 for ; Sun, 3 Jul 2011 22:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqBptyBtqlt2 for ; Sun, 3 Jul 2011 22:43:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CE51221F8597 for ; Sun, 3 Jul 2011 22:43:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdbwQ-000Jvr-0W; Mon, 04 Jul 2011 05:43:30 +0000 Date: Mon, 04 Jul 2011 14:43:29 +0900 Message-ID: From: Randy Bush To: Karl Auer Subject: Re: subnet router anycast In-Reply-To: <1309753427.2490.299.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF IPv6 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, 04 Jul 2011 05:43:34 -0000 > On Mon, 2011-07-04 at 13:28 +0930, Mark Smith wrote: >> Perhaps we should wait until IPv6 traffic exceeds IPv4's before >> deciding. With the trivial amount of use that IPv6 currently has, it >> makes no sense to say history shows it hasn't been useful and should be >> deprecated. rofl. these are the same folk that also say "you can not change X in IPv6 because IPv6 is already deployed for a decade." > On the other hand, if we can see now that they are unlikely to be > useful (and IMHO we *can* see that) then we are doing the world a > service by helping all those vendors NOT implement it :-) and getting unneeded crap out of a code-path which some day may need to perform. > There is no need for subnet anycast addresses, because any address can > be an anycast address. Only the node where an anycast address is > configured needs to know that it is an anycast address. That is, there > is no need to be able to recognise such an address from its format. Has > the use of IPv4 anycast been impeded by the inability to tell an anycast > address from an ordinary address? > > There is also no need for subnet router anycast addresses, because a > node wanting to contact a router can use the all-routers-on-link > multicast address. Note that the subnet router anycast address doesn't > even ensure that the "nearest" router is contacted, which would arguably > have been useful, because the current spec deliberately builds in a > small random delay in responding, to avoid network congestion. may i steal your text? randy From kauer@biplane.com.au Mon Jul 4 00:27:40 2011 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 7D30421F86B4 for ; Mon, 4 Jul 2011 00:27:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cUF68fpH8Zr for ; Mon, 4 Jul 2011 00:27:39 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6D21F86A3 for ; Mon, 4 Jul 2011 00:27:29 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QddZ1-0005aG-HF for ipv6@ietf.org; Mon, 04 Jul 2011 03:27:27 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: <20110704163402.3104e3a7@opy.nosense.org> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fnIS0iypWBr1EAchU6qd" Date: Mon, 04 Jul 2011 17:27:24 +1000 Message-ID: <1309764444.2490.315.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 07:27:40 -0000 --=-fnIS0iypWBr1EAchU6qd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 16:34 +0930, Mark Smith wrote: > I missed this earlier - >=20 > > Note that the subnet router anycast address doesn't > > even ensure that the "nearest" router is contacted, which would arguabl= y > > have been useful, because the current spec deliberately builds in a > > small random delay in responding, to avoid network congestion. > >=20 >=20 > Are you referring to rfc4861, section 7.2.7? The thing that makes the > first/quickest response "stick" is the Override flag being set to 0 - That's correct, the first/quickest response will stick. The thing that stops that working in the sense of getting to the "nearest" router is this: "Nodes that have an anycast address assigned to an interface treat them exactly the same as if they were unicast addresses with two exceptions. First, Neighbor Advertisements sent in response to a Neighbor Solicitation SHOULD be delayed by a random time between 0 and MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, so that when multiple advertisements are received, the first received advertisement is used rather than the most recently received advertisement." Because of that random delay, the nearest router may not be the one that "wins". It's a SHOULD, so I suppose implementations could choose to ignore that. Unless there are a LOT of routers on the link, network congestion is most unlikely to be a problem, and leaving out the delay would help the nearest router "win". But I simply see no point to the subnet router anycast address. Is there any use case that could not be equally well dealt with using all-routers-on-link or normal routed anycast? Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-fnIS0iypWBr1EAchU6qd 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) iEYEABECAAYFAk4Ra1YACgkQMAcU7Vc29odyXgCglKX/bSS9Yk7XCdBe7CSH6ZWR bx4AoICckSDay160qEvE9bxvTNZQcdj4 =6CkS -----END PGP SIGNATURE----- --=-fnIS0iypWBr1EAchU6qd-- From randy@psg.com Mon Jul 4 00:34:42 2011 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 866DE21F86F7 for ; Mon, 4 Jul 2011 00:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG7NK08iEK+9 for ; Mon, 4 Jul 2011 00:34:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 14DAC21F86E2 for ; Mon, 4 Jul 2011 00:34:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qddfz-000KCN-RB; Mon, 04 Jul 2011 07:34:40 +0000 Date: Mon, 04 Jul 2011 16:34:38 +0900 Message-ID: From: Randy Bush To: Karl Auer Subject: Re: subnet router anycast In-Reply-To: <1309764444.2490.315.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF IPv6 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, 04 Jul 2011 07:34:42 -0000 could you explain to my why i would want to reach any random router on a lan? some mey go to florida, others to shinjuku, and one goes to hell in a handbasket. randy From kauer@biplane.com.au Mon Jul 4 00:36:00 2011 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 2166021F8703 for ; Mon, 4 Jul 2011 00:36:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POeFzIBwmo8A for ; Mon, 4 Jul 2011 00:35:59 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3175D21F86F8 for ; Mon, 4 Jul 2011 00:35:58 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QddhF-00076V-Ft for ipv6@ietf.org; Mon, 04 Jul 2011 03:35:57 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: <20110704145903.7765e0df@opy.nosense.org> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-khEoVr8sacBEHDAAkQeD" Date: Mon, 04 Jul 2011 17:35:54 +1000 Message-ID: <1309764954.2490.324.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 07:36:00 -0000 --=-khEoVr8sacBEHDAAkQeD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 14:59 +0930, Mark Smith wrote: > You seem to only looking at it from the point of view of a traffic > source being onlink and wanting to send to the subnet router anycast > address. Yes and no. Let me first say that I think anycast is great! I'm not advocating disposing of anycast. And I like the idea of onlink anycast - I just don't want reserved addresses for it! Perhaps someone could enlighten me - is there any way to tell an interface that the address it has is an anycast address? Or is the only way it can know because of the specific addresses used? That is, subnet router address or addresses with the right bits set, i.e., subnet anycast addresses? If there is no way to specify to an interface that an address is an anycast address, then there would seem to be no way to deprecate both subnet router anycast and subnet anycast addresses without also deprecating the whole idea of onlink anycast. I'm starting to wonder whether this is a bigger can of worms than I first thought... Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-khEoVr8sacBEHDAAkQeD 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) iEYEABECAAYFAk4RbVoACgkQMAcU7Vc29oeT/gCg1InjaCfRFF1lPsJIRuD5uQU1 /ZQAnjVnI+1CintucpkYn47Z7UdiAonT =Vz0/ -----END PGP SIGNATURE----- --=-khEoVr8sacBEHDAAkQeD-- From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jul 4 00:54:06 2011 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 E332C21F8644 for ; Mon, 4 Jul 2011 00:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SBp1MP+qngo for ; Mon, 4 Jul 2011 00:54:06 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id DB62D21F8613 for ; Mon, 4 Jul 2011 00:54:05 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qddyj-0003Xy-Lz; Mon, 04 Jul 2011 17:24:01 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 976A93B33E; Mon, 4 Jul 2011 17:24:00 +0930 (CST) Date: Mon, 4 Jul 2011 17:23:59 +0930 From: Mark Smith To: Karl Auer Subject: Re: subnet router anycast Message-ID: <20110704172359.7b858037@opy.nosense.org> In-Reply-To: <1309764954.2490.324.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> <1309764954.2490.324.camel@karl> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 04 Jul 2011 07:54:07 -0000 On Mon, 04 Jul 2011 17:35:54 +1000 Karl Auer wrote: > On Mon, 2011-07-04 at 14:59 +0930, Mark Smith wrote: > > You seem to only looking at it from the point of view of a traffic > > source being onlink and wanting to send to the subnet router anycast > > address. > > Yes and no. > > Let me first say that I think anycast is great! I'm not advocating > disposing of anycast. And I like the idea of onlink anycast - I just > don't want reserved addresses for it! > The reserving of addresses is so that the are autoconfigured and therefore well known and "well available" ones. It's no different to the idea of having reserved well known ports, multicast groups or unicast addresses. > Perhaps someone could enlighten me - is there any way to tell an > interface that the address it has is an anycast address? Yes, there is (and has to be) a flag specified when the address is assigned to nominate it as an anycast address. > Or is the only > way it can know because of the specific addresses used? That is, subnet > router address or addresses with the right bits set, i.e., subnet > anycast addresses? > > If there is no way to specify to an interface that an address is an > anycast address, then there would seem to be no way to deprecate both > subnet router anycast and subnet anycast addresses without also > deprecating the whole idea of onlink anycast. > > I'm starting to wonder whether this is a bigger can of worms than I > first thought... > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jul 4 00:54:07 2011 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 6899B21F8644 for ; Mon, 4 Jul 2011 00:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ANP35aD2PHC for ; Mon, 4 Jul 2011 00:54:07 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id C801F21F8622 for ; Mon, 4 Jul 2011 00:54:06 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QddCN-0001Rl-A5; Mon, 04 Jul 2011 16:34:03 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id D28973B33E; Mon, 4 Jul 2011 16:34:02 +0930 (CST) Date: Mon, 4 Jul 2011 16:34:02 +0930 From: Mark Smith To: Karl Auer Subject: Re: subnet router anycast Message-ID: <20110704163402.3104e3a7@opy.nosense.org> In-Reply-To: <1309753427.2490.299.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 04 Jul 2011 07:54:07 -0000 Hi Karl, On Mon, 04 Jul 2011 14:23:47 +1000 Karl Auer wrote: > On Mon, 2011-07-04 at 13:28 +0930, Mark Smith wrote: > > Perhaps we should wait until IPv6 traffic exceeds IPv4's before > > deciding. With the trivial amount of use that IPv6 currently has, it > > makes no sense to say history shows it hasn't been useful and should be > > deprecated. > I missed this earlier - > Note that the subnet router anycast address doesn't > even ensure that the "nearest" router is contacted, which would arguably > have been useful, because the current spec deliberately builds in a > small random delay in responding, to avoid network congestion. > Are you referring to rfc4861, section 7.2.7? The thing that makes the first/quickest response "stick" is the Override flag being set to 0 - " Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, so that when multiple advertisements are received, the first received advertisement is used rather than the most recently received advertisement." So the difference between IPv4 ARP and IPv6 ND is that IPv4 ARP will always use the most recent/last reply it received. Normal unicast IPv6 ND works the same way, for NAs that have the default of the Override flag set. When a NA for an anycast address is sent/received, the Override flag is not set, and therefore the receiving host will use the information in the first and quickest response it received rather than the last. I don't seem to be able to find anything that says subnet router anycast addresses are to be treated differently to the above, have you a reference I could look at? Thanks, Mark. From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jul 4 01:08:00 2011 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 7A1E521F8531 for ; Mon, 4 Jul 2011 01:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ho2yBamdCKGH for ; Mon, 4 Jul 2011 01:07:59 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 554E921F85B9 for ; Mon, 4 Jul 2011 01:07:59 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdeCD-00040R-Sg; Mon, 04 Jul 2011 17:37:57 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 57BBD3B33E; Mon, 4 Jul 2011 17:37:55 +0930 (CST) Date: Mon, 4 Jul 2011 17:37:55 +0930 From: Mark Smith To: Karl Auer Subject: Re: subnet router anycast Message-ID: <20110704173755.3201052a@opy.nosense.org> In-Reply-To: <1309764444.2490.315.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 04 Jul 2011 08:08:00 -0000 On Mon, 04 Jul 2011 17:27:24 +1000 Karl Auer wrote: > On Mon, 2011-07-04 at 16:34 +0930, Mark Smith wrote: > > I missed this earlier - > > > > > Note that the subnet router anycast address doesn't > > > even ensure that the "nearest" router is contacted, which would arguably > > > have been useful, because the current spec deliberately builds in a > > > small random delay in responding, to avoid network congestion. > > > > > > > Are you referring to rfc4861, section 7.2.7? The thing that makes the > > first/quickest response "stick" is the Override flag being set to 0 - > > That's correct, the first/quickest response will stick. The thing that > stops that working in the sense of getting to the "nearest" router is > this: > > "Nodes that have an anycast address assigned to an interface treat > them exactly the same as if they were unicast addresses with two > exceptions. First, Neighbor Advertisements sent in response to a > Neighbor Solicitation SHOULD be delayed by a random time between 0 > and MAX_ANYCAST_DELAY_TIME to reduce the probability of network > congestion. Second, the Override flag in Neighbor Advertisements > SHOULD be set to 0, so that when multiple advertisements are > received, the first received advertisement is used rather than the > most recently received advertisement." > > Because of that random delay, the nearest router may not be the one that > "wins". It's a SHOULD, so I suppose implementations could choose to > ignore that. Unless there are a LOT of routers on the link, network > congestion is most unlikely to be a problem, and leaving out the delay > would help the nearest router "win". > Ok, so it seems a bit of variation has been added in so that the anycast "clients" are likely to be spread more across all the available anycast servers. This is probably not a bad thing. I'd been assuming it was working like PPPoE does, where the first BRAS to respond is (usually) the one chosen by the client. However I have seen a scenario where out of a group of equal capacity and performance BRASes, when one of them was placed one extra layer 2 hop away (i.e. a switch inserted between it and the switch the others were attached to), quite surprisingly customer connections drifted away from it over time, despite it being less loaded, and therefore in theory should be the fastest to respond. This extra switch hop was only adding microseconds of latency to customer's ADSL connections that had latencies in the order of 9 to 20ms. Adding some variation into the PADOs as per the method above would probably have lessened if not eliminated this customer session drift. > But I simply see no point to the subnet router anycast address. Is there > any use case that could not be equally well dealt with using > all-routers-on-link or normal routed anycast? > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 From alexandru.petrescu@gmail.com Mon Jul 4 01:44:37 2011 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 8AFAE21F861B for ; Mon, 4 Jul 2011 01:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0diP5ODti-Ze for ; Mon, 4 Jul 2011 01:44:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id D2AE921F85C2 for ; Mon, 4 Jul 2011 01:44:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p648iZPV013853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jul 2011 10:44:35 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p648iYJ5031937; Mon, 4 Jul 2011 10:44:34 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p648iYHc017215; Mon, 4 Jul 2011 10:44:34 +0200 Message-ID: <4E117D72.40001@gmail.com> Date: Mon, 04 Jul 2011 10:44:34 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: subnet router anycast References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 04 Jul 2011 08:44:37 -0000 Le 04/07/2011 09:34, Randy Bush a écrit : > could you explain to my why i would want to reach any random router > on a lan? Maybe for a form of reliability and, indirectly, bootstrapping - of Mobile IPv6. Mobile IPv6 has this DHAAD procedure by which a MH sends a request with dst address an anycast address ("HAs on the home link"). Only one HA will reply even though several may be present in the same lan subnet. They have previously synched among them (a preference field in RA) to decide who's to send that reply. Thus, anycast and multiple HA on the home link is advantageous for reliability of Mobile IPv6. Indirectly, this use of anycast means bootstrapping also is easier: the HA anycast identifier being well-known, a MH is to be preconfigured solely with the prefix of its home link (it subsequently obtains dynamically its Home Address, the HA address and so on.) Alex > some mey go to florida, others to shinjuku, and one goes to hell in a > handbasket. > > randy > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From roland.bless@kit.edu Mon Jul 4 03:22:42 2011 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 A768121F85C8 for ; Mon, 4 Jul 2011 03:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6xY3K8TDTRC for ; Mon, 4 Jul 2011 03:22:42 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 12EB221F85C7 for ; Mon, 4 Jul 2011 03:22:41 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1QdgIS-0003Hv-Tj; Mon, 04 Jul 2011 12:22:38 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 9E265A80007; Mon, 4 Jul 2011 12:22:32 +0200 (CEST) Message-ID: <4E119468.6030605@kit.edu> Date: Mon, 04 Jul 2011 12:22:32 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Randy Bush Subject: Re: subnet router anycast References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1309774958.943572000 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, 04 Jul 2011 10:22:42 -0000 Hi Randy, On 04.07.2011 00:01, Randy Bush wrote: > IPv6 subnet anycast is not used operationally, complicates > implementations, and complicates protocol specifications. The form > of anycast actually used in the Internet is routing-based, and is > essentilly the same as that of IPv4 anycast. Therefore, this > document deprecates IPv6 subnet anycast. I was more referring to host anycast, I don't care about the special anycast addresses of routers as defined in sec. 2.6.1. of RFC 4291 http://tools.ietf.org/html/rfc4291#section-2.6.1. or also RFC2526. There are definitely cases where it can be useful to have a group of anycast hosts inside a subnet, e.g., in order to increase robustness of services etc. For instance, we had a nice use case for bootstrapping into P2P networks by using subnet anycast addresses. There is no need to inject anycast routes into the routing system for this. I don't see the point why the currently proposed mechanisms (as I quoted in my earlier mail) complicates protocol specifications. All that a host must do is to join the solicited node multicast address for the anycast address, and then to omit DAD. Setting the overwrite flag to zero for an NA is also not such a big thing. I don't see a need to implement any special functionality in routers and I don't see how anycast complicates the host stacks as this boils down to: support a local anycast flag for addresses; if flag is set then omit DAD; when sending a neighbor advertisement: the overwrite flag to zero if flag is set. Seems to be simple enough... Regards, Roland From randy@psg.com Mon Jul 4 03:35:53 2011 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 45B4D21F864F for ; Mon, 4 Jul 2011 03:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njieh2QFyl+v for ; Mon, 4 Jul 2011 03:35:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C73B621F864B for ; Mon, 4 Jul 2011 03:35:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdgVC-000KeW-Of; Mon, 04 Jul 2011 10:35:43 +0000 Date: Mon, 04 Jul 2011 19:35:41 +0900 Message-ID: From: Randy Bush To: Roland Bless Subject: Re: subnet router anycast In-Reply-To: <4E119468.6030605@kit.edu> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <4E119468.6030605@kit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 04 Jul 2011 10:35:53 -0000 > There are definitely cases where it can be useful to have a group of > anycast hosts inside a subnet, e.g., in order to increase robustness > of services etc. do you use this in production or test? randy From roland.bless@kit.edu Mon Jul 4 03:50:48 2011 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 DDDA421F8674 for ; Mon, 4 Jul 2011 03:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTnQIufB7mcB for ; Mon, 4 Jul 2011 03:50:48 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3921F863C for ; Mon, 4 Jul 2011 03:50:47 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1Qdgjh-0006Ur-8h; Mon, 04 Jul 2011 12:50:46 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 1FBF6A80676; Mon, 4 Jul 2011 12:50:41 +0200 (CEST) Message-ID: <4E119B01.9090703@kit.edu> Date: Mon, 04 Jul 2011 12:50:41 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Randy Bush Subject: Re: subnet router anycast References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <4E119468.6030605@kit.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1309776646.391657000 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, 04 Jul 2011 10:50:49 -0000 Hi Randy, Am 04.07.2011 12:35, schrieb Randy Bush: >> There are definitely cases where it can be useful to have a group of >> anycast hosts inside a subnet, e.g., in order to increase robustness >> of services etc. > > do you use this in production or test? Frankly said, I wasn't aware that they basic mechanisms are so simple and thought that one would need some MLD equivalent for anycast, which would have been a major effort. However, after browsing some RFCs I found that it should simply work out of the box if the specs are implemented correctly. Therefore, we are currently testing it, but we'd like to use it in production for P2P bootstrapping. Regards, Roland From kauer@biplane.com.au Mon Jul 4 04:01:34 2011 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 3EC5E21F862E for ; Mon, 4 Jul 2011 04:01:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1kfPJdQ1ivQ for ; Mon, 4 Jul 2011 04:01:33 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4E69121F8603 for ; Mon, 4 Jul 2011 04:01:32 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdguA-0002YD-6z for ipv6@ietf.org; Mon, 04 Jul 2011 07:01:30 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: <20110704172359.7b858037@opy.nosense.org> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> <1309764954.2490.324.camel@karl> <20110704172359.7b858037@opy.nosense.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9HqwFU3br2oJHQuvTPD2" Date: Mon, 04 Jul 2011 21:01:27 +1000 Message-ID: <1309777287.2490.342.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 11:01:34 -0000 --=-9HqwFU3br2oJHQuvTPD2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 17:23 +0930, Mark Smith wrote: > The reserving of addresses is so that the are autoconfigured and > therefore well known and "well available" ones. It's no different to the > idea of having reserved well known ports, multicast groups or unicast > addresses. That's fine - but we should not reserve addresses unless there is a point to doing so. I can see no reason why there should be a group of addresses designated "anycast" at the top of the subnet (the subnet anycast addresses). And so far, no-one has provided a use case that shows why they need to be reserved. > Yes, there is (and has to be) a flag specified when the address is > assigned to nominate it as an anycast address. I'm glad there is, because that means we do not need to reserve those addresses. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-9HqwFU3br2oJHQuvTPD2 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) iEYEABECAAYFAk4RnYEACgkQMAcU7Vc29ofsuwCfaLb8j/RyJuUQ/8ULJJpcGjnO JPAAnjxBQQQQbbmx5RnkurGy5jRVivgb =ToMt -----END PGP SIGNATURE----- --=-9HqwFU3br2oJHQuvTPD2-- From kauer@biplane.com.au Mon Jul 4 04:06:42 2011 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 B56DC21F86BA for ; Mon, 4 Jul 2011 04:06:42 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nhSGdbFg8Rf for ; Mon, 4 Jul 2011 04:06:42 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2962921F867D for ; Mon, 4 Jul 2011 04:06:41 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdgzB-0003Hn-13 for ipv6@ietf.org; Mon, 04 Jul 2011 07:06:41 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: <20110704173755.3201052a@opy.nosense.org> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> <20110704173755.3201052a@opy.nosense.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4eV2uDErIk5OE9o0a6lh" Date: Mon, 04 Jul 2011 21:06:37 +1000 Message-ID: <1309777598.2490.347.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 11:06:42 -0000 --=-4eV2uDErIk5OE9o0a6lh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 17:37 +0930, Mark Smith wrote: > Ok, so it seems a bit of variation has been added in so that the > anycast "clients" are likely to be spread more across all the available > anycast servers. This is probably not a bad thing. I'm happy to have it, or not have it. But the current discussion is about whether to reserve the subnet router anycast address and/or the subnet anycast addresses. It is not about whether to have on-link anycast at all.=20 We can have anycast, however it may be implemented, without reserving special addresses for it. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-4eV2uDErIk5OE9o0a6lh 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) iEYEABECAAYFAk4Rnr0ACgkQMAcU7Vc29ocgRQCfT0CZIHvETOPiQv+1pQq3+5iV K28AnjUx2T9KNgrtY6EuRn63GQHwafsA =1fi0 -----END PGP SIGNATURE----- --=-4eV2uDErIk5OE9o0a6lh-- From kauer@biplane.com.au Mon Jul 4 04:09:22 2011 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 0733421F86C9 for ; Mon, 4 Jul 2011 04:09:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWAzKr2BnpV5 for ; Mon, 4 Jul 2011 04:09:21 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 63EC521F86B1 for ; Mon, 4 Jul 2011 04:09:20 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qdh1k-0003f7-1J for ipv6@ietf.org; Mon, 04 Jul 2011 07:09:20 -0400 Subject: Re: subnet router anycast From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4E117D72.40001@gmail.com> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> <4E117D72.40001@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bGcSoDA9VglKr8BmD+gU" Date: Mon, 04 Jul 2011 21:09:17 +1000 Message-ID: <1309777757.2490.350.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 11:09:22 -0000 --=-bGcSoDA9VglKr8BmD+gU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 10:44 +0200, Alexandru Petrescu wrote: > Thus, anycast and multiple HA on the home link is advantageous for > reliability of Mobile IPv6. Again, I'm not proposing that we deprecate the mechanisms for on-link anycast. Only that we should not reserve the subnet router anycast and/or the subnet anycast addresses. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-bGcSoDA9VglKr8BmD+gU 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) iEYEABECAAYFAk4Rn10ACgkQMAcU7Vc29oemvgCdEW2cZvQXvSwy6KRQL6CxK0OX o50An3GeoyzaqMpYKLCGAU6xnLN0zmi6 =V5si -----END PGP SIGNATURE----- --=-bGcSoDA9VglKr8BmD+gU-- From kauer@biplane.com.au Mon Jul 4 04:15:38 2011 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 2FE8921F8641 for ; Mon, 4 Jul 2011 04:15:38 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32SH2FRiTp+5 for ; Mon, 4 Jul 2011 04:15:37 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id DBF6B21F863F for ; Mon, 4 Jul 2011 04:15:36 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qdh7n-0004UP-M4 for ipv6@ietf.org; Mon, 04 Jul 2011 07:15:35 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-uHJPUQw/gPGIL6tztgVp" Date: Mon, 04 Jul 2011 21:15:32 +1000 Message-ID: <1309778132.2490.357.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 11:15:38 -0000 --=-uHJPUQw/gPGIL6tztgVp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 16:34 +0900, Randy Bush wrote: > could you explain to my why i would want to reach any random router on a > lan? some mey go to florida, others to shinjuku, and one goes to hell > in a handbasket. heh :-) Randy, are we actually on the same page? I like the idea of on-link anycast in general, but do not see why we should reserve any addresses for it. I'm therefore in favour of deprecating both the subnet router anycast address and the subnet anycast addresses. Which is (I think) all your draft is advocating...? Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-uHJPUQw/gPGIL6tztgVp 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) iEYEABECAAYFAk4RoNQACgkQMAcU7Vc29oc4pgCgnenvKyZGsDUaIIu6zPaY/j5B jqkAnRuIe/x91ch6rPGw3+7s3iYSi2EO =U/rj -----END PGP SIGNATURE----- --=-uHJPUQw/gPGIL6tztgVp-- From mark@townsley.net Mon Jul 4 04:30:56 2011 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 46EEE21F86F0 for ; Mon, 4 Jul 2011 04:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-JVnLKXLd8H for ; Mon, 4 Jul 2011 04:30:55 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE7F21F86F6 for ; Mon, 4 Jul 2011 04:30:54 -0700 (PDT) Received: by wyj26 with SMTP id 26so3904122wyj.31 for ; Mon, 04 Jul 2011 04:30:54 -0700 (PDT) Received: by 10.227.168.207 with SMTP id v15mr5333320wby.50.1309779054014; Mon, 04 Jul 2011 04:30:54 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id p14sm153069wbh.30.2011.07.04.04.30.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 04:30:52 -0700 (PDT) From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10-759367567 Subject: Re: subnet router anycast Date: Mon, 4 Jul 2011 13:30:49 +0200 In-Reply-To: <1309777757.2490.350.camel@karl> To: ipv6@ietf.org References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> <4E117D72.40001@gmail.com> <1309777757.2490.350.camel@karl> Message-Id: <8B9F15F9-4A5D-480E-97B9-1E98157E3262@townsley.net> X-Mailer: Apple Mail (2.1084) 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, 04 Jul 2011 11:30:56 -0000 --Apple-Mail-10-759367567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 6rd makes use of the v6 subnet router anycast, see section 5 of RFC5969. = In short, this allows a CE to construct a ping with a well-known = destination that will be returned by one of the BRs. Operators like this = because it allows them to fairly easily get a good indication of which = BR a given CE is likely traversing when sending traffic.=20 Also, at the last IETF meeting the DHC WG took on an effort to describe = the use of subnet router anycast here: http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02 ...in a more generic manner for use with DHCPv6 (which 6rd could in turn = use). I suspect the -00 is either just out or will be very soon. - Mark On Jul 4, 2011, at 1:09 PM, Karl Auer wrote: > On Mon, 2011-07-04 at 10:44 +0200, Alexandru Petrescu wrote: >> Thus, anycast and multiple HA on the home link is advantageous for >> reliability of Mobile IPv6. >=20 > Again, I'm not proposing that we deprecate the mechanisms for on-link > anycast. Only that we should not reserve the subnet router anycast > and/or the subnet anycast addresses. >=20 > Regards, K. >=20 > --=20 > = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 = (mob) >=20 > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-10-759367567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02=

...in a more generic manner for use with DHCPv6 = (which 6rd could in turn use). I suspect the -00 is either just out or = will be very soon.

- Mark

On = Jul 4, 2011, at 1:09 PM, Karl Auer wrote:

On = Mon, 2011-07-04 at 10:44 +0200, Alexandru Petrescu wrote:
Thus, anycast and multiple HA on the home link is = advantageous for
reliability = of Mobile IPv6.

Again, I'm not proposing that we = deprecate the mechanisms for on-link
anycast. Only that we should not = reserve the subnet router anycast
and/or the subnet anycast = addresses.

Regards, K.

-- =
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~
Karl Auer (kauer@biplane.com.au) =             &n= bsp;     +61-2-64957160 (h)
http://www.biplane.com.au/kauer/= =             &n= bsp;     +61-428-957160 (mob)

GPG = fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old = fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 = 0156
------------------------------------------------------------------= --
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests: = https://www.ietf.org/mailman/listinfo/ipv6
----------------------------= ----------------------------------------

<= /body>= --Apple-Mail-10-759367567-- From kauer@biplane.com.au Mon Jul 4 04:54:51 2011 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 B98C311E8079 for ; Mon, 4 Jul 2011 04:54:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhc7PwmEgT3g for ; Mon, 4 Jul 2011 04:54:51 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id CD7D011E8078 for ; Mon, 4 Jul 2011 04:54:50 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qdhjk-0001Lr-IZ for ipv6@ietf.org; Mon, 04 Jul 2011 07:54:48 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: <8B9F15F9-4A5D-480E-97B9-1E98157E3262@townsley.net> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> <4E117D72.40001@gmail.com> <1309777757.2490.350.camel@karl> <8B9F15F9-4A5D-480E-97B9-1E98157E3262@townsley.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-iSIswdx5RPWxgkm5pFMO" Date: Mon, 04 Jul 2011 21:54:45 +1000 Message-ID: <1309780485.2490.372.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 11:54:51 -0000 --=-iSIswdx5RPWxgkm5pFMO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 13:30 +0200, Mark Townsley wrote: > 6rd makes use of the v6 subnet router anycast > [...] > Also, at the last IETF meeting the DHC WG took on an effort to > describe the use of subnet router anycast here: >=20 > http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02 On an admittedly rapid read through those texts (RFC3315, RFC5969, the above draft) all references to subnet router anycast addresses were inside "SHOULD" clauses. Which implies that there are alternative methods of achieving those aims? One alternative would be to make the subnet router anycast address well-known rather than reserved. Then it could be used in environments that need it, and would not interfere in environments that do not. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-iSIswdx5RPWxgkm5pFMO 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) iEYEABECAAYFAk4Rqf4ACgkQMAcU7Vc29oeIBwCfc9D9Z6GwUsC8fy2dSeEKXBhq OOgAn2F6VNa7DYKDCgvdiyRk2n/ajKcI =jLky -----END PGP SIGNATURE----- --=-iSIswdx5RPWxgkm5pFMO-- From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jul 4 05:43:04 2011 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 6B1ED1F0C4C for ; Mon, 4 Jul 2011 05:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKOC8NzFRuh5 for ; Mon, 4 Jul 2011 05:43:04 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2411F0C49 for ; Mon, 4 Jul 2011 05:43:03 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdiUP-0004eF-DQ; Mon, 04 Jul 2011 22:13:01 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id D851E3B341; Mon, 4 Jul 2011 22:12:58 +0930 (CST) Date: Mon, 4 Jul 2011 22:12:57 +0930 From: Mark Smith To: Karl Auer Subject: Re: subnet router anycast Message-ID: <20110704221257.05e845a7@opy.nosense.org> In-Reply-To: <1309777287.2490.342.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> <1309764954.2490.324.camel@karl> <20110704172359.7b858037@opy.nosense.org> <1309777287.2490.342.camel@karl> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 04 Jul 2011 12:43:04 -0000 On Mon, 04 Jul 2011 21:01:27 +1000 Karl Auer wrote: > On Mon, 2011-07-04 at 17:23 +0930, Mark Smith wrote: > > The reserving of addresses is so that the are autoconfigured and > > therefore well known and "well available" ones. It's no different to the > > idea of having reserved well known ports, multicast groups or unicast > > addresses. > > That's fine - but we should not reserve addresses unless there is a > point to doing so. > I can see no reason why there should be a group of > addresses designated "anycast" at the top of the subnet (the subnet > anycast addresses). And so far, no-one has provided a use case that > shows why they need to be reserved. > Sometimes you have to have the base capability widely available before it is attractive to people to use. By insisting on a use case, you may be creating a chicken and egg problem. See the "success" of IPv4 multicast, bearing in mind that it was specified in RFC1119, August 1989. Perhaps it would have been more widely used if it had been more widely available in the 90s. That's why it's been part of IPv6 from day one. If every router supports the subnet anycast address, because it is a mandated requirement, you can develop and deploy something that relies on it. If the availability is limited, you end up duplicating the same mechanism some other way at the cost of additional effort, or don't bother at all because those additional costs are too high. > > Yes, there is (and has to be) a flag specified when the address is > > assigned to nominate it as an anycast address. > > I'm glad there is, because that means we do not need to reserve those > addresses. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 From kauer@biplane.com.au Mon Jul 4 06:16:20 2011 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 8481921F85B3 for ; Mon, 4 Jul 2011 06:16:20 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z91eg7bB2cBD for ; Mon, 4 Jul 2011 06:16:19 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9284721F85AF for ; Mon, 4 Jul 2011 06:16:18 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.204]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qdj0a-0000TO-9O for ipv6@ietf.org; Mon, 04 Jul 2011 09:16:16 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: <20110704221257.05e845a7@opy.nosense.org> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> <1309764954.2490.324.camel@karl> <20110704172359.7b858037@opy.nosense.org> <1309777287.2490.342.camel@karl> <20110704221257.05e845a7@opy.nosense.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tRAbGZETgn1VVYjgVeOE" Date: Mon, 04 Jul 2011 23:16:12 +1000 Message-ID: <1309785372.2490.389.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 13:16:20 -0000 --=-tRAbGZETgn1VVYjgVeOE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 22:12 +0930, Mark Smith wrote: > If every router supports the subnet anycast address, because it is a > mandated requirement, you can develop and deploy something that relies > on it. If the availability is limited, you end up duplicating the same > mechanism some other way at the cost of additional effort, or don't > bother at all because those additional costs are too high. For situations apparently needing the subnet router anycast address, there is the all-routers-on-link multicast address. Not that it would normally be needed, because any node on the link has (or can cheaply build) a list of all routers on the link by just watching the RAs, something it has to do anyway. A node can then choose a router at random, or any router based on any criteria it likes. Alternatively an application can ping the all-routers-on-link multicast address and build a list of responders. There is no need for the subnet router anycast address. The subnet anycast addresses are reserved but not necessarily used. Any node actually sending to one must therefore first acquire information about which one to send to. The source of that information could just as well supply any address. On the other side of the equation, an application wanting to use one of the reserved addresses must somehow publish information about which one it is using. Again, that could just as well convey information about any address. There is no need for the subnet anycast addresses to be reserved. Seriously, I'm not being bloody-minded. I simply cannot see a good reason for either of these two reserved address sets. If someone can provide any, I will immediately retract everything I have said and maintain the opposite :-) Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-tRAbGZETgn1VVYjgVeOE 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) iEYEABECAAYFAk4RvRYACgkQMAcU7Vc29of+lQCgjvFAH8BUskc9muM+GOOkf3PL aGwAoNB4RNE1r0nRFi2Nu0JXmwvKvghk =PocN -----END PGP SIGNATURE----- --=-tRAbGZETgn1VVYjgVeOE-- From randy@psg.com Mon Jul 4 06:36:18 2011 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 3133A21F85CA for ; Mon, 4 Jul 2011 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txTo+HjT3V+r for ; Mon, 4 Jul 2011 06:36:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A581A21F84CF for ; Mon, 4 Jul 2011 06:36:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdjJl-000L8i-QC; Mon, 04 Jul 2011 13:36:06 +0000 Date: Mon, 04 Jul 2011 22:36:04 +0900 Message-ID: From: Randy Bush To: Karl Auer Subject: Re: subnet router anycast In-Reply-To: <1309785372.2490.389.camel@karl> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> <1309764954.2490.324.camel@karl> <20110704172359.7b858037@opy.nosense.org> <1309777287.2490.342.camel@karl> <20110704221257.05e845a7@opy.nosense.org> <1309785372.2490.389.camel@karl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF IPv6 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, 04 Jul 2011 13:36:18 -0000 it's getting late evening here, and the -00 dreadline approaches. so i have submitted so that we have something concrete to discuss. randy From mark@townsley.net Mon Jul 4 09:51:52 2011 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 98C3521F85F2 for ; Mon, 4 Jul 2011 09:51:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGVg+RO0c--p for ; Mon, 4 Jul 2011 09:51:52 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD2E21F85DD for ; Mon, 4 Jul 2011 09:51:48 -0700 (PDT) Received: by wwg11 with SMTP id 11so1661863wwg.1 for ; Mon, 04 Jul 2011 09:51:46 -0700 (PDT) Received: by 10.227.195.13 with SMTP id ea13mr2224635wbb.0.1309798306827; Mon, 04 Jul 2011 09:51:46 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id c17sm4624528wbh.29.2011.07.04.09.51.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 09:51:46 -0700 (PDT) Subject: Re: subnet router anycast Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <1309780485.2490.372.camel@karl> Date: Mon, 4 Jul 2011 18:51:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704163402.3104e3a7@opy.nosense.org> <1309764444.2490.315.camel@karl> <4E117D72.40001@gmail.com> <1309777757.2490.350.camel@karl> <8B9F15F9-4A5D-480E-97B9-1E98157E3262@townsley.net> <1309780485.2490.372.camel@karl> To: Karl Auer X-Mailer: Apple Mail (2.1084) Cc: IETF IPv6 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, 04 Jul 2011 16:51:52 -0000 On Jul 4, 2011, at 1:54 PM, Karl Auer wrote: > On Mon, 2011-07-04 at 13:30 +0200, Mark Townsley wrote: >> 6rd makes use of the v6 subnet router anycast >> [...] >> Also, at the last IETF meeting the DHC WG took on an effort to >> describe the use of subnet router anycast here: >>=20 >> http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02 >=20 > On an admittedly rapid read through those texts (RFC3315, RFC5969, the > above draft) all references to subnet router anycast addresses were > inside "SHOULD" clauses. Which implies that there are alternative > methods of achieving those aims? In this case, the alternative is to simply not have the troubleshooting = feature. - Mark >=20 > One alternative would be to make the subnet router anycast address > well-known rather than reserved. Then it could be used in environments > that need it, and would not interfere in environments that do not. >=20 > Regards, K. >=20 > --=20 > = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 = (mob) >=20 > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From mark@townsley.net Mon Jul 4 09:52:46 2011 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 1BAAE11E80C5 for ; Mon, 4 Jul 2011 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdEwH+4I61wl for ; Mon, 4 Jul 2011 09:52:45 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7CF11E80CA for ; Mon, 4 Jul 2011 09:52:45 -0700 (PDT) Received: by wyj26 with SMTP id 26so4108225wyj.31 for ; Mon, 04 Jul 2011 09:52:44 -0700 (PDT) Received: by 10.227.196.80 with SMTP id ef16mr5462114wbb.27.1309798362867; Mon, 04 Jul 2011 09:52:42 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id c17sm4624528wbh.29.2011.07.04.09.52.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 09:52:42 -0700 (PDT) Subject: Re: subnet router anycast Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <1309785372.2490.389.camel@karl> Date: Mon, 4 Jul 2011 18:52:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> <1309764954.2490.324.camel@karl> <20110704172359.7b858037@opy.nosense.org> <1309777287.2490.342.camel@karl> <20110704221257.05e845a7@opy.nosense.org> <1309785372.2490.389.camel@karl> To: Karl Auer X-Mailer: Apple Mail (2.1084) Cc: IETF IPv6 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, 04 Jul 2011 16:52:46 -0000 On Jul 4, 2011, at 3:16 PM, Karl Auer wrote: > On Mon, 2011-07-04 at 22:12 +0930, Mark Smith wrote: >> If every router supports the subnet anycast address, because it is a >> mandated requirement, you can develop and deploy something that = relies >> on it. If the availability is limited, you end up duplicating the = same >> mechanism some other way at the cost of additional effort, or don't >> bother at all because those additional costs are too high. >=20 > For situations apparently needing the subnet router anycast address, > there is the all-routers-on-link multicast address. Not that it would > normally be needed, because any node on the link has (or can cheaply > build) a list of all routers on the link by just watching the RAs, > something it has to do anyway. A node can then choose a router at > random, or any router based on any criteria it likes. Alternatively an > application can ping the all-routers-on-link multicast address and = build > a list of responders. There is no need for the subnet router anycast > address. A residential gateway router is not going to be able to do this for a = variety of reasons.=20 - Mark >=20 > The subnet anycast addresses are reserved but not necessarily used. = Any > node actually sending to one must therefore first acquire information > about which one to send to. The source of that information could just = as > well supply any address. On the other side of the equation, an > application wanting to use one of the reserved addresses must somehow > publish information about which one it is using. Again, that could = just > as well convey information about any address. There is no need for the > subnet anycast addresses to be reserved. >=20 > Seriously, I'm not being bloody-minded. I simply cannot see a good > reason for either of these two reserved address sets. If someone can > provide any, I will immediately retract everything I have said and > maintain the opposite :-) >=20 > Regards, K. >=20 > --=20 > = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 = (mob) >=20 > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > -------------------------------------------------------------------- > 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 4 16:08:49 2011 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 BB7D921F87B5 for ; Mon, 4 Jul 2011 16:08:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+wdP+9t+SpI for ; Mon, 4 Jul 2011 16:08:48 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5221F87F2 for ; Mon, 4 Jul 2011 16:08:45 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.202]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdsFv-0000h8-9H for ipv6@ietf.org; Mon, 04 Jul 2011 19:08:43 -0400 Subject: Re: subnet router anycast From: Karl Auer To: IETF IPv6 In-Reply-To: References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> <1309764954.2490.324.camel@karl> <20110704172359.7b858037@opy.nosense.org> <1309777287.2490.342.camel@karl> <20110704221257.05e845a7@opy.nosense.org> <1309785372.2490.389.camel@karl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-QT5nWwYnKmA6rI5trKNH" Date: Tue, 05 Jul 2011 09:08:40 +1000 Message-ID: <1309820920.2490.401.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 04 Jul 2011 23:08:49 -0000 --=-QT5nWwYnKmA6rI5trKNH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-04 at 18:52 +0200, Mark Townsley wrote: > > For situations apparently needing the subnet router anycast address, > > there is the all-routers-on-link multicast address. Not that it would > > normally be needed, because any node on the link has (or can cheaply > > build) a list of all routers on the link by just watching the RAs, > > something it has to do anyway. A node can then choose a router at > > random, or any router based on any criteria it likes. Alternatively an > > application can ping the all-routers-on-link multicast address and buil= d > > a list of responders. There is no need for the subnet router anycast > > address. >=20 > A residential gateway router is not going to be able to do this for a var= iety of reasons.=20 Could you expand on that? Do you mean on the inside network or the outside network And which of the three alternatives (all-routers, RA-watching, ping) are not going to work?=20 Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-QT5nWwYnKmA6rI5trKNH 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) iEYEABECAAYFAk4SR/IACgkQMAcU7Vc29oc4EQCglyXE4jE9Y+oVI2AN8sv41OhT 8SMAoLjZ/Hccv2eXMsP7KJuZiOvRIRwW =N/uk -----END PGP SIGNATURE----- --=-QT5nWwYnKmA6rI5trKNH-- From ichiroumakino@gmail.com Mon Jul 4 23:42:44 2011 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 4764921F8607 for ; Mon, 4 Jul 2011 23:42:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqjLrAejjMaY for ; Mon, 4 Jul 2011 23:42:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3805921F8606 for ; Mon, 4 Jul 2011 23:42:43 -0700 (PDT) Received: by wyj26 with SMTP id 26so4412967wyj.31 for ; Mon, 04 Jul 2011 23:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XGYR8ZWVch7cOKh5Knxx9z6/1NShuUikCwTmgPQrFIs=; b=SEBPQ4v0WTRMTIKnjnaHn5iPmPkTH00Igr05W4orXcLIKNzaRQ6WnWtddpajOJsnaR y5kM3z/CcKonHhaG+06ZF8OU1nLPem8Ymn3N3LI0I8hb9mrPqpsdlCRWQmW/FsYNf1py OaLQH0WiP5qT8RJnzrL1x1JAfeF2EozE6fSaE= Received: by 10.216.68.131 with SMTP id l3mr4156820wed.43.1309848162192; Mon, 04 Jul 2011 23:42:42 -0700 (PDT) Received: from dhcp-10-61-101-157.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id w10sm3457508weq.3.2011.07.04.23.42.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 23:42:40 -0700 (PDT) Sender: Ole Troan Subject: Re: subnet router anycast Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <1309820920.2490.401.camel@karl> Date: Tue, 5 Jul 2011 08:42:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0375983C-143A-4BB1-A35A-791EABE8689C@employees.org> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <20110704132809.25f4cac9@opy.nosense.org> <1309753427.2490.299.camel@karl> <20110704145903.7765e0df@opy.nosense.org> <1309764954.2490.324.camel@karl> <20110704172359.7b858037@opy.nosense.org> <1309777287.2490.342.camel@karl> <20110704221257.05e845a7@opy.nosense.org> <1309785372.2490.389.camel@karl> <1309820920.2490.401.camel@karl> To: Karl Auer X-Mailer: Apple Mail (2.1084) Cc: IETF IPv6 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, 05 Jul 2011 06:42:44 -0000 Karl, >>> For situations apparently needing the subnet router anycast address, >>> there is the all-routers-on-link multicast address. Not that it = would >>> normally be needed, because any node on the link has (or can cheaply >>> build) a list of all routers on the link by just watching the RAs, >>> something it has to do anyway. A node can then choose a router at >>> random, or any router based on any criteria it likes. Alternatively = an >>> application can ping the all-routers-on-link multicast address and = build >>> a list of responders. There is no need for the subnet router anycast >>> address. >>=20 >> A residential gateway router is not going to be able to do this for a = variety of reasons.=20 >=20 > Could you expand on that? Do you mean on the inside network or the > outside network And which of the three alternatives (all-routers, > RA-watching, ping) are not going to work?=20 from RFC5969: The 6rd link is modeled as an NBMA link similar to other automatic IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs and BRs defined as off-link neighbors from one other. The link-local address of a 6rd virtual interface performing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213].=20= However, no communication using link-local addresses will occur. a 6rd link doesn't have RAs, and doesn't support link-local addressing. cheers, Ole= From internet-drafts@ietf.org Tue Jul 5 06:28:43 2011 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 6ADCA21F8711; Tue, 5 Jul 2011 06:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFUKnnUDacHJ; Tue, 5 Jul 2011 06:28:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB3321F86D5; Tue, 5 Jul 2011 06:28:43 -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-flow-ecmp-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705132843.3765.24159.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 06:28:43 -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, 05 Jul 2011 13:28:43 -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= IETF. Title : Using the IPv6 flow label for equal cost multipath routi= ng and link aggregation in tunnels Author(s) : Brian Carpenter Shane Amante Filename : draft-ietf-6man-flow-ecmp-04.txt Pages : 10 Date : 2011-07-05 The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-04.txt From brian.e.carpenter@gmail.com Tue Jul 5 06:34:53 2011 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 4406F21F8707 for ; Tue, 5 Jul 2011 06:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tBufoFP7YPJ for ; Tue, 5 Jul 2011 06:34:52 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A382D21F870B for ; Tue, 5 Jul 2011 06:34:52 -0700 (PDT) Received: by iwn39 with SMTP id 39so6448879iwn.31 for ; Tue, 05 Jul 2011 06:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Y9FffOHNownvwNppeu7GsLXX8eJdpjN7EGqY2BGmaZs=; b=O3AlzCzqc/RHlwjZsAF/x/vC6M8D12myc7EJGYCSAsfTO1kMqEz6xVsdYWS9sWB9eA Bg2h3NGc5FhrHNCZcnLzWmuasLDy59no+fbrjIDllRHCKboNJC+6Gl46lDJx1Wtj4mOk Sy4X3xcWAfR/TRWRXY5EMMgH+MbRHCDPjsHDM= Received: by 10.42.96.133 with SMTP id j5mr7384424icn.477.1309872892023; Tue, 05 Jul 2011 06:34:52 -0700 (PDT) Received: from [10.255.25.118] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id hw7sm7648952icc.15.2011.07.05.06.34.50 (version=SSLv3 cipher=OTHER); Tue, 05 Jul 2011 06:34:51 -0700 (PDT) Message-ID: <4E1312F3.9030806@gmail.com> Date: Wed, 06 Jul 2011 01:34:43 +1200 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-flow-ecmp-04.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: Tue, 05 Jul 2011 13:34:53 -0000 This version fixes the two comments received during IETF Last Call (expanding an acronym, and noting in the security considerations that label values should be unpredictable). We'll also need to expand on the unpredictability point in 3697bis, when its Last Call ends. Regards Brian -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-flow-ecmp-04.txt Date: Tue, 05 Jul 2011 06:28:43 -0700 From: internet-drafts@ietf.org Reply-To: 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 : Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Author(s) : Brian Carpenter Shane Amante Filename : draft-ietf-6man-flow-ecmp-04.txt Pages : 10 Date : 2011-07-05 The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-04.txt From internet-drafts@ietf.org Tue Jul 5 06:41:52 2011 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 5472721F8603; Tue, 5 Jul 2011 06:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fCWywDzwAb5; Tue, 5 Jul 2011 06:41:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005EA21F8515; Tue, 5 Jul 2011 06:41:50 -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-flow-update-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705134149.8385.31461.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 06:41:49 -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, 05 Jul 2011 13:41:52 -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= IETF. Title : Rationale for update to the IPv6 flow label specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-flow-update-07.txt Pages : 13 Date : 2011-07-05 Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it, and to introduce some additional flexibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-update-07.txt From brian.e.carpenter@gmail.com Tue Jul 5 06:49:41 2011 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 072E711E80A6 for ; Tue, 5 Jul 2011 06:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6atlBAUbKFKO for ; Tue, 5 Jul 2011 06:49:40 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4764511E8098 for ; Tue, 5 Jul 2011 06:49:40 -0700 (PDT) Received: by yie30 with SMTP id 30so2851292yie.31 for ; Tue, 05 Jul 2011 06:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=asE7BHaSh9KfRgdllrpiam9zNEYfdDWJnfluphAoCxc=; b=Xl/7zOwDUxKdLN6gnBeG4yc4wvEv9ARSLdaLdCzijf5vExeHvlLpCFJ7592JtQPAW5 +Am4y0+8lX2EHk6kGd8A/441gUrluNopXiBugIUeiD1pmuJ3QMhzvDJiAntpXJuFOVqT Wa9+IpAaYzxyC1464pzQlwJXKu4q1fcgh0VcM= Received: by 10.150.114.11 with SMTP id m11mr6018540ybc.137.1309873779733; Tue, 05 Jul 2011 06:49:39 -0700 (PDT) Received: from [10.255.25.118] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id l10sm2104730ybf.4.2011.07.05.06.49.39 (version=SSLv3 cipher=OTHER); Tue, 05 Jul 2011 06:49:39 -0700 (PDT) Message-ID: <4E131671.9050702@gmail.com> Date: Wed, 06 Jul 2011 01:49:37 +1200 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: New Version Notification for draft-ietf-6man-flow-update-07.txt] 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: Tue, 05 Jul 2011 13:49:41 -0000 There were no comments (that the authors saw) during IETF Last Call. This version fixes a few minor editorial points, and the AD's comments. Brian -------- Original Message -------- Subject: New Version Notification for draft-ietf-6man-flow-update-07.txt Date: Tue, 05 Jul 2011 06:41:51 -0700 From: internet-drafts@ietf.org To: brian.e.carpenter@gmail.com CC: shengjiang@huawei.com, brian.e.carpenter@gmail.com, shane@level3.net A new version of I-D, draft-ietf-6man-flow-update-07.txt has been successfully submitted by Brian Carpenter and posted to the IETF repository. Filename: draft-ietf-6man-flow-update Revision: 07 Title: Rationale for update to the IPv6 flow label specification Creation date: 2011-07-05 WG ID: 6man Number of pages: 13 Abstract: Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it, and to introduce some additional flexibility. The IETF Secretariat From kerlyn2001@gmail.com Tue Jul 5 09:38:19 2011 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 BC62321F8573 for ; Tue, 5 Jul 2011 09:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW4if44Tv+oT for ; Tue, 5 Jul 2011 09:38:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 688D211E8117 for ; Tue, 5 Jul 2011 09:38:09 -0700 (PDT) Received: by iwn39 with SMTP id 39so6628039iwn.31 for ; Tue, 05 Jul 2011 09:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=8Jb1NalC/DidverCExLT5mhiwLQhX4cjSvCxdoIcKXk=; b=oHfEpwW+CtJv5nItmUaUiP1sKHybDxUZyIGrryoYforCN8oTvo955pyH99mILDF3mo Zr7vTpFSraYhcuLOKJxJbG2v4HIqrBxzdsTwkCU2+Ci3YIYh5BHszaSzdP08BfyEt8Vg BZp/tFAVf+uWE3XwR0be6YYYhvdh8sUWP3F78= MIME-Version: 1.0 Received: by 10.42.97.132 with SMTP id o4mr8059761icn.59.1309883888846; Tue, 05 Jul 2011 09:38:08 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.42.218.5 with HTTP; Tue, 5 Jul 2011 09:38:08 -0700 (PDT) In-Reply-To: <20110704221746.32625.89914.idtracker@ietfa.amsl.com> References: <20110704221746.32625.89914.idtracker@ietfa.amsl.com> Date: Tue, 5 Jul 2011 12:38:08 -0400 X-Google-Sender-Auth: 08gFrHQtb0CC1fsyuXhZYC8Sgus Message-ID: Subject: Fwd: New Version Notification for draft-lynn-6man-6lobac-00.txt From: Kerry Lynn To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=20cf303bf95ee445b104a7551b5b 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, 05 Jul 2011 16:38:19 -0000 --20cf303bf95ee445b104a7551b5b Content-Type: text/plain; charset=ISO-8859-1 Greetings, A new "IPv6 over foo" I-D has been posted at draft-lynn-6man-6lobac-00 . This I-D specifies an IPv6 encapsulation for a constrained data link that I'd describe as a wired alternative to 15.4 in commercial building automation applications. The I-D provides some background material on MS/TP (the access method) as well as the required IPv6 stuff. The encapsulation and header compression schemes are derived from (and compatible with) 6LoWPAN. I hope to get a few minutes on the 6man agenda in QC to discuss the I-D and where it belongs. I have been working closely with the ASHRAE BACnet standards committee (the owners of the MS/TP spec) and several industry sponsors on this I-D and hope it can proceed as an individual submission. Regards, -K- ---------- Forwarded message ---------- From: Date: Mon, Jul 4, 2011 at 6:17 PM Subject: New Version Notification for draft-lynn-6man-6lobac-00.txt To: kerlyn@ieee.org Cc: kerlyn@ieee.org A new version of I-D, draft-lynn-6man-6lobac-00.txt has been successfully submitted by Kerry Lynn and posted to the IETF repository. Filename: draft-lynn-6man-6lobac Revision: 00 Title: Transmission of IPv6 over MS/TP Networks Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 13 Abstract: MS/TP (Master-Slave/Token-Passing) is a contention-free access method for the TIA-485-A physical layer that is used extensively in building automation networks. This document describes the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. The IETF Secretariat --20cf303bf95ee445b104a7551b5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

A new "IPv6 over foo" I-D has been = posted at=A0draft-lynn-6man-6lobac-00.
This I-D specifies an IPv6 en= capsulation for a constrained data link that
I'd describe as=A0a wired alternative to 15.4 in commercial buildi= ng automation
applications. =A0The I-D provides some background m= aterial on MS/TP (the
access method) as well as the required IPv6= stuff. =A0The encapsulation and
header compression schemes are derived from (and compatible with)=A06L= oWPAN.

I hope to get a few minutes on the 6man age= nda in QC to discuss the I-D and
where it belongs. =A0I have been= working closely with the ASHRAE BACnet
standards committee=A0(the owners of the MS/TP spec) and several indus= try
sponsors on this I-D and hope it can proceed as an individual= submission.

Regards, -K-

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Jul 4, 2011 at 6:17 P= M
Subject: New Version Notification for draft-lynn-6man-6lobac-00.txt
To: = kerlyn@ieee.org
Cc: kerlyn@ieee.org


A new version of I-D, = draft-lynn-6man-6lobac-00.txt has been successfully submitted by Kerry Lynn= and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-lynn-6man-6lobac
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Transmission of IPv6 over MS/TP Networks
Creation date: =A0 2011-07-04
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 13

Abstract:
=A0 MS/TP (Master-Slave/Token-Passing) is a contention-free access method<= br> =A0 for the TIA-485-A physical layer that is used extensively in building<= br> =A0 automation networks. =A0This document describes the frame format for =A0 transmission of IPv6 packets and the method of forming link-local and<= br> =A0 statelessly autoconfigured IPv6 addresses on MS/TP networks.




The IETF Secretariat

--20cf303bf95ee445b104a7551b5b-- From joelja@bogus.com Tue Jul 5 13:33:59 2011 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 B171821F889A for ; Tue, 5 Jul 2011 13:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2uxyZ3tJtmT for ; Tue, 5 Jul 2011 13:33:58 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD8E21F8894 for ; Tue, 5 Jul 2011 13:33:49 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p65KXgNx095896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 5 Jul 2011 20:33:42 GMT (envelope-from joelja@bogus.com) Resent-Message-Id: <201107052033.p65KXgNx095896@nagasaki.bogus.com> Subject: Re: [v6ops] new draft: draft-gashinsky-v6nd-enhance-00 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Resent-From: Joel Jaeggli Date: Sun, 3 Jul 2011 16:18:28 -0700 Content-Transfer-Encoding: quoted-printable Resent-Date: Tue, 5 Jul 2011 13:33:37 -0700 Resent-To: ipv6@ietf.org References: Message-Id: <4B51E24B-B934-45AB-A72C-03BDDCEFFCCF@bogus.com> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 05 Jul 2011 20:33:43 +0000 (UTC) Cc: v6nd@ne-where.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, 05 Jul 2011 20:33:59 -0000 I forgot to include 6man On Jul 1, 2011, at 7:52 PM, Andrew Yourtchenko wrote: > Joel, >=20 > FWIW, a couple of observations about the "6.3. Routing Mitigation" = based on my experiments and various discussions, and a few miscellanea. >=20 > 6.2. Appropriate Subnet Sizing. >=20 > Maybe worth to note here that the folks would still benefit of = allocating the /64, and then using smaller part of it, if they want to = do so. So later if they need to have more hosts in that segment, they = would only renumber that segment. (also to "optimize the allocation for = conservation of braincells" which I remember someone mentioned some = time) fwiw that's essentially what I did in practice, e.g. I assign p-to-p = links as /64s and user them with much shorter. load balancer virtual = ip's are all assigned out of the same /64 but are actually used as = /128s. use of non-default subnet size on the other hand runs afoul of = SLAAC so it has it's limitations. > Also for consistency with 6.1, might be worth noting that this = approach would inhibit the use of RFC4862 altogether ? >=20 > 6.3. Routing Mitigation. >=20 > - the necessity to enable routing will depend on whether the host = implements Strong ES or Weak ES multihoming model as per rfc1122 = terminology - I tested on 2.6.32-24-generic and reaching the global = address configured on the "lo" interface from ethernet side did not = require enabling the forwarding. >=20 > - one semi-related advantage of the routing approach is that it can = and is used in operations to allow the routing-protocol based redundancy = with anycast addresses for transactional services. >=20 > - the overhead on the host will of course depend on the type of the = routing protocol. Also, since it is effectively host->router = communication, one can take an advantage of that. The RIPng seemed like = a good candidate to me in this regard (to be run only on the first hop = router). > The prototype code is 205 lines of vanilla C, of which 113 lines are = the RT_NETLINK boilerplate to retrieve the current address(es) assigned = to loopback interface, such that the host config files were the only = dependency. >=20 > (IMHO this approach is effectively a 7.3, but at network layer at an = expense of some addition to host. Arguably, http server code is also an = addition, though :). >=20 > - one other side effect of this approach is that if it is used in the = NBMA-type ethernet deployment (cf: the RA thread), then the absence of = the on-link global prefix takes care of the inter-host communication - = it will happen via the default gateway. >=20 >=20 > 7.1, item 5: Recommendations for Implementors. >=20 > keeping the state here opens the hole from another end - if a router = "remembers" the "past good" addresses, then a local attacker may easily = exhaust the resources on the router by rapidly changing the source = address and making a single ping, then moving on. yeah I think what exposure a malicious local system might exploit is = worth a thought expierment or two. > 7.2. Queue Tuning. >=20 > How does this interact with the other aspect of the behavior that is = dictated by RFC4861 ? >=20 > "While waiting for address resolution to complete, the sender MUST, > for each neighbor, retain a small queue of packets waiting for > address resolution to complete. " >=20 > Merely rate-limiting the requests from the dataplane would result in = inability for an implementation to comply with this "MUST", I think. yeah > Also, to me this section seems to contradict the 6.4: the 7.2 says = it's applicable if there is a single queue, while 6.4 says it is useful = only if there is more than one queue - while 7.2 reads as the suggestion = to implement the knobs for doing 6.4... If I miss something more subtle = here, might be useful to have it more explicit (and as well to expand on = the relationship between the two chapters). >=20 > 7.3. NDP Protocol Gratuitous NA >=20 > "Hosts MAY be configured to send unsolicited Neighbor = advertisement..." - is it something that exists now somewhere in the OS = or would this require additional code as well ? The implementations I = know of, used ad-hoc appendages to send these NAs. Ergo, I think it is = similar to section 6.3 except it uses the different name for the = protocol ? So NDP, as it exists today assumes that a gratuitious NA message kicks = of a NDP cycle. regarding whether implementations do something along = these links I'm pretty sure that host implmentations for vrrp6 pretty = much do that when transitioning the shared address between instaces. > I wonder if there is a room for "neighbor registration" approach = similar to the one in http://tools.ietf.org/html/draft-ietf-6lowpan-nd. >=20 > 9. >=20 > "... DOS exposure" is the ending of the sentence or there is something = more ? >=20 > s/Explicitely/Explicitly/ > s/maintin/maintain/ > s/amerlorate/ameliorate/ > s/isse/issue/ > s/excissivly/excessively/ > s/lowing/lowering/ > s/investigationg/investigating/ > s/maintaice/maintenance/ > s/recieving/receiving/ > s/correpsonding/corresponding/ thanks > cheers, > andrew >=20 > On Thu, 30 Jun 2011, Joel Jaeggli wrote: >=20 >> I would direct the two working groups' attention if I may to a = recently posted draft: >>=20 >> http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 >>=20 >> the potential DOS exposure that ipv6 neighbor discovery poses to = routers is generally understood at this point, the document covers = usable work arounds, and includes some rough proposals for addressing = what the authors views as shortcomings in the neighbor disocvery = process. >>=20 >> some inspiration was drawn from: >>=20 >> http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00 >>=20 >> thanks >> joel >>=20 >> A new version of I-D, draft-gashinsky-v6nd-enhance-00.txt has been = successfully submitted by joel jaeggli and posted to the IETF = repository. >>=20 >> Filename: draft-gashinsky-v6nd-enhance >> Revision: 00 >> Title: Operational Neighbor Discovery Problems and = Enhancements. >> Creation date: 2011-06-29 >> WG ID: Individual Submission >> Number of pages: 15 >>=20 >> Abstract: >> In IPv4, subnets are generally small, made just large enough to cover >> the actual number of machines on the subnet. In contrast, the >> default IPv6 subnet size is a /64, a number so large it covers >> trillions of addresses, the overwhelming number of which will be >> unassigned. Consequently, simplistic implementations of Neighbor >> Discovery can be vulnerable to denial of service attacks whereby they >> attempt to perform address resolution for large numbers of unassigned >> addresses. Such denial of attacks can be launched intentionally (by >> an attacker), or result from legitimate operational tools that scan >> networks for inventory and other purposes. As a result of these >> vulnerabilities, new devices may not be able to "join" a = network, it >> may be impossible to establish new IPv6 flows, and existing ipv6 >> transported flows may be interrupted. >>=20 >> This document describes the problem in detail and suggests possible >> implementation improvements as well as operational mitigation >> techniques that can in some cases to protect against such attacks. >> It also discusses possible modifications to the traditional [RFC4861] >> neighbor discovery protocol itself. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From sander@steffann.nl Tue Jul 5 15:49:07 2011 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 EACC621F883A for ; Tue, 5 Jul 2011 15:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1QbOAlokuPP for ; Tue, 5 Jul 2011 15:49:07 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15921F88AA for ; Tue, 5 Jul 2011 15:49:07 -0700 (PDT) Received: from [10.0.0.63] (unknown [151.11.144.66]) by mail.sintact.nl (Postfix) with ESMTP id 687752013 for ; Wed, 6 Jul 2011 00:49:06 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: subnet router anycast From: Sander Steffann In-Reply-To: <1309737967.2490.218.camel@karl> Date: Wed, 6 Jul 2011 00:49:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> To: IETF IPv6 X-Mailer: Apple Mail (2.1084) 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, 05 Jul 2011 22:49:08 -0000 Hi, > Does this apply to subnet *router* anycast, or just subnet anycast? = The > two are not quite the same, and the draft doesn't mention RFC4291. >=20 > I'd agree wholeheartedly with deprecating them both! But this draft > expired some months ago - what are its chances? Just an observation: I have been playing with the new IPv6-capable = firmware of the Thompson/Technicolor TG789 firmware. It does implement = IPv6 subnet router anycast, and it will be deployed in the near future = (firmware production release in a couple of weeks IIRC). - Sander From jhw@apple.com Tue Jul 5 17:17:33 2011 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 8111721F88A9 for ; Tue, 5 Jul 2011 17:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.742 X-Spam-Level: X-Spam-Status: No, score=-106.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeOJyNwNldgz for ; Tue, 5 Jul 2011 17:17:33 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 16ABE21F88A8 for ; Tue, 5 Jul 2011 17:17:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay12.apple.com ([17.128.113.53]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNV001F8Y54Z970@mail-out.apple.com> for ipv6@ietf.org; Tue, 05 Jul 2011 17:17:32 -0700 (PDT) X-AuditID: 11807135-b7b76ae000001169-3f-4e13aa1805d3 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay12.apple.com (Apple SCV relay) with SMTP id 96.87.04457.81AA31E4; Tue, 05 Jul 2011 17:19:36 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNV002DOY58AQB0@cardamom.apple.com> for ipv6@ietf.org; Tue, 05 Jul 2011 17:17:32 -0700 (PDT) Subject: Re: subnet router anycast From: james woodyatt In-reply-to: Date: Tue, 05 Jul 2011 17:17:32 -0700 Message-id: <11E3ACFC-AAFE-408A-985D-C1DA1223B992@apple.com> References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> To: Sander Steffann X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUiON1OVVdilbCfQd8UTYuXZ98zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48O/N6wFzzkrGn+uYW9g/MPexcjJISFgItGz8QUThC0mceHe erYuRi4OIYFWJol3vWtZQRK8AoISPybfY+li5OBgFpCXOHheFiTMLKAl8f1RKwtE/Uyg+s9P 2EASwgJKEnd2rwcbyiagIvHt8l0wm1PAXuLP/FcsIDaLgKrEva+drBCDXCX2bdrMBrHLRuLM zBlQR+xllPg6dz/YpSICGhKLnt5jg7hUXmJxy2fGCYwCs5DcNwvhvllI7lvAyLyKUbAoNSex 0tBIL7GgICdVLzk/dxMjKPQaCk13MD5aqH6IUYCDUYmHd6WRsJ8Qa2JZcWXuIUYJDmYlEV7m TqAQb0piZVVqUX58UWlOavEhRmkOFiVx3ipHLj8hgfTEktTs1NSC1CKYLBMHp1QD4/KqHevv XOq8E7REQ7MucZf2n/K1qrNFvj5z3c769ug2lyqupBM3lab5X7B7lZ8teOz2d9NoubrAP64y ooZqfRq/E3aofbsTPVUwcp0ZY4PnlQWmx2bfn1oUqS0q1D7TtPvBRff7Je7TVxxd+mz+Ws9T y1Y15h6ySq5O1JoXUBk2+7SP2q9lv5RYijMSDbWYi4oTAUHKj/E5AgAA Cc: IETF IPv6 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, 06 Jul 2011 00:17:33 -0000 On Jul 5, 2011, at 15:49 , Sander Steffann wrote: > > Just an observation: I have been playing with the new IPv6-capable firmware of the Thompson/Technicolor TG789 firmware. It does implement IPv6 subnet router anycast, and it will be deployed in the near future (firmware production release in a couple of weeks IIRC). Apple's AirPort Extreme supports the subnet router anycast address on its advertising interfaces. It wasn't hard at all to implement and debug. My reading of RFC 2526, which this draft references, is that there is exactly one node requirement: don't assign unicast addresses to interfaces with the subnet anycast prefix. I know we will never do that with SLAAC on the advertising interfaces, but I suspect that the DHCPv6 client on the soliciting interface will happily violate RFC 2526 if the IA_NA or IA_TA addresses have the subnet anycast prefix for one of its on-link prefixes. I haven't checked, and I don't think the IPv6 Ready certification test does either, or I would have remembered failing it. It would not be very hard at all to apply a patch to comply with the requirement in RFC 2526 to refuse those addresses. -- james woodyatt member of technical staff, core os networking From alexandru.petrescu@gmail.com Wed Jul 6 00:30:31 2011 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 1A4CE21F86B4 for ; Wed, 6 Jul 2011 00:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tziu5sikhuM for ; Wed, 6 Jul 2011 00:30:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD2D21F869D for ; Wed, 6 Jul 2011 00:30:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p667USCK020293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Jul 2011 09:30:28 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p667USsa028283; Wed, 6 Jul 2011 09:30:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p667USbV001236; Wed, 6 Jul 2011 09:30:28 +0200 Message-ID: <4E140F14.8020105@gmail.com> Date: Wed, 06 Jul 2011 09:30:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: subnet router anycast References: <1309712636.2490.203.camel@karl> <4E10E421.5020804@kit.edu> <1309737967.2490.218.camel@karl> <11E3ACFC-AAFE-408A-985D-C1DA1223B992@apple.com> In-Reply-To: <11E3ACFC-AAFE-408A-985D-C1DA1223B992@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 06 Jul 2011 07:30:31 -0000 Le 06/07/2011 02:17, james woodyatt a écrit : > On Jul 5, 2011, at 15:49 , Sander Steffann wrote: >> >> Just an observation: I have been playing with the new IPv6-capable >> firmware of the Thompson/Technicolor TG789 firmware. It does >> implement IPv6 subnet router anycast, and it will be deployed in >> the near future (firmware production release in a couple of weeks >> IIRC). > > Apple's AirPort Extreme supports the subnet router anycast address on > its advertising interfaces. It wasn't hard at all to implement and > debug. > > My reading of RFC 2526, which this draft references, is that there is > exactly one node requirement: don't assign unicast addresses to > interfaces with the subnet anycast prefix. Hmm... this requirement is probably being violated by one implementation of Home Agent of Mobile IPv6 - it needs to assign an anycast address _and_ its unicast global address on a same interface, otherwise the DHAAD part of Mobile IPv6 wouldn't work. Also, the link-local _unicast_ address is an almost de facto mandate on every Ethernet interface, on many implementations. This also would violate that either-or requirement on anycast-unicat. Alex > I know we will never do that with SLAAC on the advertising > interfaces, but I suspect that the DHCPv6 client on the soliciting > interface will happily violate RFC 2526 if the IA_NA or IA_TA > addresses have the subnet anycast prefix for one of its on-link > prefixes. I haven't checked, and I don't think the IPv6 Ready > certification test does either, or I would have remembered failing > it. > > It would not be very hard at all to apply a patch to comply with the > requirement in RFC 2526 to refuse those addresses. > > > -- james woodyatt member of technical staff, core os > networking > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From suresh.krishnan@ericsson.com Thu Jul 7 12:12:37 2011 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 AC0BA1F0C50 for ; Thu, 7 Jul 2011 12:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.731 X-Spam-Level: X-Spam-Status: No, score=-105.731 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL2jI1ElU0X3 for ; Thu, 7 Jul 2011 12:12:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id DE3451F0C3C for ; Thu, 7 Jul 2011 12:12:36 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p67JCUAA028085; Thu, 7 Jul 2011 14:12:35 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 7 Jul 2011 15:12:29 -0400 From: Suresh Krishnan To: RJ Atkinson , "ipv6@ietf.org" Date: Thu, 7 Jul 2011 15:11:30 -0400 Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: Acw393KN+Xh8SUCzS42m2aJT2lWqYwE4jsss Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC1513D42BE5B@EUSAACMS0703.eamcs.ericsson.se> References: <894ABDC2-238A-41AC-831A-D816E2DAD0A2@gmail.com> In-Reply-To: <894ABDC2-238A-41AC-831A-D816E2DAD0A2@gmail.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-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, 07 Jul 2011 19:12:37 -0000 Hi Ran, The text you proposed seems reasonable. I will make the change in the nex= t rev. Thanks Suresh ________________________________________ From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] On Behalf Of RJ Atkinso= n [rja.lists@gmail.com] Sent: Friday, July 01, 2011 10:00 AM To: ipv6@ietf.org Subject: Re: 6MAN WG Last Call: On 30th June 2011, Bob Hinden wrote: > This message starts a two week 6MAN Working Group Last Call on advancing: > > Title : An uniform format for IPv6 extension headers > Author(s) : Suresh Krishnan > Erik Kline > James Hoagland > Manav Bhatia > Filename : draft-ietf-6man-exthdr-03.txt > Pages : 8 > Date : 2011-06-27 > > > http://tools.ietf.org/html/draft-ietf-6man-exthdr-03 > > > as a Proposed Standard. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call > will end on 14 July 2011. I support publishing this as a Proposed Standard. This revision resolves my earlier concerns that it is highly undesirable to define *any* new IPv6 Extension Headers (since defining any new IPv6 Extension Header will break multiple existing IPv6 deployments). On 1st July 2011, David Malone wrote, in part: > Fixing this could be a simple as changing the title and abstract, > plus possibly adding something in Section 4 to actually encourage > use of the uniform format. I do not have any philosophical objections to the suggested edit of the document Title and expansion of the Abstract. Perhaps the lone sentence in Section 4 could be reworded into RFC-2119 language. Candidate replacement text might be: If any IPv6 Extension Headers are defined in future, keeping in mind the restrictions above in Section 3 and also the restrictions specified in RFC-2460, they MUST use the consistent format defined in Figure 1. This enables future IPv6 implementations to skip over unknown IPv6 Extension Headers and continue to further process the IPv6 header chain. Yours, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nordmark@acm.org Thu Jul 7 13:41:52 2011 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 CDD4611E80A4 for ; Thu, 7 Jul 2011 13:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gcuajb7DHUir for ; Thu, 7 Jul 2011 13:41:51 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id DC80E11E8072 for ; Thu, 7 Jul 2011 13:41:51 -0700 (PDT) Received: from [192.168.1.100] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p67KfiTn028771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2011 13:41:47 -0700 Message-ID: <4E161A05.6050605@acm.org> Date: Thu, 07 Jul 2011 13:41:41 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Fwd: New Version Notification for draft-nordmark-6man-impatient-nud-01.txt Content-Type: text/plain; charset=UTF-8; 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, 07 Jul 2011 20:41:52 -0000 This has some more details based on the mailing list discussion, and references draft-gashinsky-v6nd-enhance-00 for further motivation. Erik -------- Original Message -------- Subject: New Version Notification for draft-nordmark-6man-impatient-nud-01.txt Date: Thu, 07 Jul 2011 13:33:06 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-nordmark-6man-impatient-nud-01.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-nordmark-6man-impatient-nud Revision: 01 Title: Neighbor Unreachability Detection is too impatient Creation date: 2011-07-07 WG ID: Individual Submission Number of pages: 7 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. However, if there are no alternatives, this is far too impatient. This document proposes an approach where an implementation can choose the timeout behavior to be different based on whether or not there are alternatives. The IETF Secretariat From wdec.ietf@gmail.com Fri Jul 8 03:30:43 2011 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 2A03821F89F7 for ; Fri, 8 Jul 2011 03:30:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjsPYQ4cJCEx for ; Fri, 8 Jul 2011 03:30:42 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF2DC21F89F0 for ; Fri, 8 Jul 2011 03:30:42 -0700 (PDT) Received: by pwj5 with SMTP id 5so381960pwj.31 for ; Fri, 08 Jul 2011 03:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=D+5+6rPCMI5iggsN+I9AKTdDYyp881ek6Q7lC0tnbLA=; b=AxGxSTpoGEpHLV4Cn+N9Fk4EPPit/9kAq/SKKdRDOsDYk8OScaV4pbDvhTjfKk7MT8 M20JSgJ4qmZEZ4x/AUkAvbSjOqJXUXhnxfGWRmIbGHvRK9NNIlheTBHUJEWpoL+14fFI 6/VEnpcJe+sdeXcmFv6OibgEI70a/2uw/TOiY= MIME-Version: 1.0 Received: by 10.142.247.27 with SMTP id u27mr226537wfh.141.1310121042314; Fri, 08 Jul 2011 03:30:42 -0700 (PDT) Received: by 10.142.136.8 with HTTP; Fri, 8 Jul 2011 03:30:42 -0700 (PDT) Date: Fri, 8 Jul 2011 12:30:42 +0200 Message-ID: Subject: FW: draft-dec-6man-rs-access-harmful From: Wojciech Dec To: IPv6 WG Mailing List Content-Type: text/plain; charset=ISO-8859-1 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, 08 Jul 2011 10:30:43 -0000 Feedback is welcome... A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Router Solicitation Driven Access Considered Harmful Author(s) : Wojciech Dec Filename : draft-dec-6man-rs-access-harmful-00.txt Pages : 15 Date : 2011-06-20 This document presents issues regarding the reliance of IPv6 Router Solicitation messages for creating or initializing router state necessary to enable IPv6 users' connectivity, particularly in situations where such users have bridged ethernet connectivity with the router. A number of alternative solution approaches are also presented and discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dec-6man-rs-access-harmful-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-dec-6man-rs-access-harmful-00.txt From rathiguru@hotmail.com Fri Jul 8 22:23:24 2011 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 C0F9321F871A for ; Fri, 8 Jul 2011 22:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZZ4WTH5K1-6 for ; Fri, 8 Jul 2011 22:23:24 -0700 (PDT) Received: from bay0-omc1-s12.bay0.hotmail.com (bay0-omc1-s12.bay0.hotmail.com [65.54.190.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1545621F8719 for ; Fri, 8 Jul 2011 22:23:24 -0700 (PDT) Received: from BAY146-W45 ([65.54.190.61]) by bay0-omc1-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 22:23:24 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3721c64c-81d8-4979-9307-d24a1054d923_" X-Originating-IP: [59.92.2.15] From: Thiruma valavan To: Subject: Doubt in Router Advertisement Message Date: Sat, 9 Jul 2011 10:53:21 +0530 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2011 05:23:24.0149 (UTC) FILETIME=[530DAA50:01CC3DF8] X-Mailman-Approved-At: Sat, 09 Jul 2011 02:51:06 -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: Sat, 09 Jul 2011 05:25:24 -0000 --_3721c64c-81d8-4979-9307-d24a1054d923_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi IETF Group=2C While testing IPV6 Router Advertisement part=2C I noticed some behaviour th= at if I changed router interface MTU value=2C it won't send Router Advertis= ement message immediately instead of waiting to next interval time. Is that normal behaviour=2C=20 Thanks & Regards=2C Thirumavalavan PCalsoflabs India Pvt Ltd=2CBangaloreATLEN Group of CompanyM= ob: +91 9790758035=20 = --_3721c64c-81d8-4979-9307-d24a1054d923_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi IETF Group=2C

While testing IPV6 Router Advertisement part=2C I noticed some behaviour= that if I changed router interface MTU value=2C it won't send Router Adver= tisement message immediately instead of waiting to next interval time.
<= /font>

Is that nor= mal behaviour=2C =3B

Thanks &=3B Regards=2C
Thirumavalavan P
Calsoflabs In= dia Pvt Ltd=2CBangalore
ATLEN G= roup of Company
Mob: +91 979075= 8035
= --_3721c64c-81d8-4979-9307-d24a1054d923_-- From vishwas.ietf@gmail.com Sat Jul 9 15:06:00 2011 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 65DAA21F8A5F for ; Sat, 9 Jul 2011 15:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA+WKUhCExPY for ; Sat, 9 Jul 2011 15:05:59 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE7D721F8A21 for ; Sat, 9 Jul 2011 15:05:59 -0700 (PDT) Received: by pzk5 with SMTP id 5so2979269pzk.31 for ; Sat, 09 Jul 2011 15:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:to:reply-to:subject:in-reply-to:x-mailer :mime-version:content-type; bh=GKeQtmtQyvLF3H8nCRBjMIqoVdYExNAOnCmzhF/fwpA=; b=axlboeZtvmoJwl9uP07pPOiSXLHS/HaHJWQFTCpbFAq6fb5KRfjIhhtlQaQy0OG9yI m2rNrhSr/nQJc9HoLV2jJPDbpTPzt/5Ll7SstdUj7kpx0D/9SDsIeUioiXyzGIQdv/MA PereNv7GVg7kO2iQuaRU9TH+t+WKQ+V9M12NM= Received: by 10.68.27.68 with SMTP id r4mr5094390pbg.133.1310249159586; Sat, 09 Jul 2011 15:05:59 -0700 (PDT) Received: from www.palm.com ([32.173.67.185]) by mx.google.com with ESMTPS id m7sm7257899pbk.38.2011.07.09.15.05.53 (version=SSLv3 cipher=OTHER); Sat, 09 Jul 2011 15:05:57 -0700 (PDT) Message-ID: <4e18d0c5.2727440a.7a71.2906@mx.google.com> Date: Sat, 9 Jul 2011 15:05:47 -0700 From: "Vishwas Manral" To: "Thiruma valavan" , "ipv6@ietf.org" Subject: Re: Doubt in Router Advertisement Message In-Reply-To: X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Alternative__boundary__1310249153729 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Vishwas Manral List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 22:06:00 -0000 --Alternative__boundary__1310249153729 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thiruma, >From the specs it is clear that the MTU is optional. However if MTU sending= is enabled it should be sent on change too. Sounds like a bug in the implementation to me. Thanks, Vishwas Sent from my Palm Pre on AT&T On Jul 9, 2011 2:51 AM, Thiruma valavan <rathiguru@hotmail.com> wrote= :=20 Hi IETF Group, While testing IPV6 Router Advertisement part, I noticed some behaviour that= if I changed router interface MTU value, it won't send Router Advertisemen= t message immediately instead of waiting to next interval time. Is that normal behaviour,  Thanks & Regards, Thirumavalavan PCalsoflabs India Pvt Ltd,BangaloreATLEN Group of CompanyMob= : +91 9790758035=20 =20 --Alternative__boundary__1310249153729 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thiruma,

From the specs it is clear that the MTU is optional. How= ever if MTU sending is enabled it should be sent on change too.

Soun= ds like a bug in the implementation to me.

Thanks,
Vishwas


Sent from my Palm Pre on AT&T

= On Jul 9, 2011 2:51 AM, Thiruma valavan= <rathiguru@hotmail.com> wrote:

Hi IETF Group,

W= hile testing IPV6 Router Advertisement part, I noticed some behaviour that= if I changed router interface MTU value, it won't send Router Advertisemen= t message immediately instead of waiting to next interval time.
<= /div>

Is that normal beh= aviour, 

Thanks &a= mp; Regards,
Thirumavalavan P
Calsoflabs Indi= a Pvt Ltd,Bangalore
ATLEN Group= of Company
Mob: +91 9790758035=
--Alternative__boundary__1310249153729-- From rathiguru@hotmail.com Sun Jul 10 02:17:53 2011 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 2539D21F867F for ; Sun, 10 Jul 2011 02:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=-1.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfqgbCz7P6b3 for ; Sun, 10 Jul 2011 02:17:52 -0700 (PDT) Received: from bay0-omc2-s18.bay0.hotmail.com (bay0-omc2-s18.bay0.hotmail.com [65.54.190.93]) by ietfa.amsl.com (Postfix) with ESMTP id B140A21F85EB for ; Sun, 10 Jul 2011 02:17:52 -0700 (PDT) Received: from BAY146-W57 ([65.54.190.125]) by bay0-omc2-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Jul 2011 02:17:52 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bca0ad01-5c4e-443a-81c8-c1e1c6bebe14_" X-Originating-IP: [59.92.93.145] From: Thiruma valavan To: , Subject: RE: Doubt in Router Advertisement Message Date: Sun, 10 Jul 2011 14:47:52 +0530 Importance: Normal In-Reply-To: <4e18d0c5.2727440a.7a71.2906@mx.google.com> References: , <4e18d0c5.2727440a.7a71.2906@mx.google.com> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2011 09:17:52.0722 (UTC) FILETIME=[3EFD4B20:01CC3EE2] X-Mailman-Approved-At: Sun, 10 Jul 2011 02:19:40 -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: Sun, 10 Jul 2011 09:17:53 -0000 --_bca0ad01-5c4e-443a-81c8-c1e1c6bebe14_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks vishwas. Once again I will analyze those things(Router Advertisement - MTU option) a= nd let you know.=20 Thanks in Advance=2C Thirumavalavan PCalsoftlabs India Pvt Ltd=2C Bangalore. ALTEN Group of Company.Mob: +91 9790758035=20 Date: Sat=2C 9 Jul 2011 15:05:47 -0700 From: vishwas.ietf@gmail.com To: rathiguru@hotmail.com=3B ipv6@ietf.org Subject: Re: Doubt in Router Advertisement Message Hi Thiruma=2C >From the specs it is clear that the MTU is optional. However if MTU sending= is enabled it should be sent on change too. Sounds like a bug in the implementation to me. Thanks=2C Vishwas Sent from my Palm Pre on AT&T On Jul 9=2C 2011 2:51 AM=2C Thiruma valavan wrote:= =20 Hi IETF Group=2C While testing IPV6 Router Advertisement part=2C I noticed some behaviour th= at if I changed router interface MTU value=2C it won't send Router Advertis= ement message immediately instead of waiting to next interval time. Is that normal behaviour=2C=20 Thanks & Regards=2C Thirumavalavan PCalsoflabs India Pvt Ltd=2CBangaloreATLEN Group of CompanyM= ob: +91 9790758035=20 =20 = --_bca0ad01-5c4e-443a-81c8-c1e1c6bebe14_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks vishwas.

<= font class=3D"Apple-style-span" face=3D"Verdana">Once again I will =3Banalyze =3Bthose things(Rout= er Advertisement - MTU option) and let you know. =3B

Thanks in Advance=2C
Thirumavalavan P
Calsoftlabs India Pvt Ltd=2C Bangalor= e.
ALTEN Group of Company.
Mob: +91 9790758035



Date: Sat=2C 9 Jul 2011 15:05:47 -0700
From: vi= shwas.ietf@gmail.com
To: rathiguru@hotmail.com=3B ipv6@ietf.org
Subje= ct: Re: Doubt in Router Advertisement Message

Hi Thiruma=2C

F= rom the specs it is clear that the MTU is optional. However if MTU sending = is enabled it should be sent on change too.

Sounds like a bug in the= implementation to me.

Thanks=2C
Vishwas



Sent from my Palm Pre on AT&=3BT

On Jul 9=2C 2011 2:51 AM=2C Thiruma valavan &= lt=3Brathiguru@hotmail.com>=3B wrote:

Hi IETF Group=2C

While testing IPV6 Router Advertisement part=2C I noticed some beha= viour that if I changed router interface MTU value=2C it won't send Router = Advertisement message immediately instead of waiting to next interval time.=
=
= Is that normal behaviour=2C =3B

Thanks &=3B Regards=2C
Thirumavalavan P
Calsoflabs India P= vt Ltd=2CBangalore
ATLEN Group of Co= mpany
Mob: +91 9790758035
=
= --_bca0ad01-5c4e-443a-81c8-c1e1c6bebe14_-- From internet-drafts@ietf.org Mon Jul 11 14:06:08 2011 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 6A00411E8256; Mon, 11 Jul 2011 14:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQWAt1c75bLW; Mon, 11 Jul 2011 14:06:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D8811E816B; Mon, 11 Jul 2011 14:06:07 -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-flow-3697bis-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711210607.27065.142.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 14:06:07 -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, 11 Jul 2011 21:06:08 -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= IETF. Title : IPv6 Flow Label Specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Filename : draft-ietf-6man-flow-3697bis-06.txt Pages : 16 Date : 2011-07-11 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-06.txt From internet-drafts@ietf.org Mon Jul 11 14:36:21 2011 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 7019C11E82C1; Mon, 11 Jul 2011 14:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS9LKVkjOE4h; Mon, 11 Jul 2011 14:36:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166EA11E8165; Mon, 11 Jul 2011 14:36:21 -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-exthdr-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711213621.8727.63593.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 14:36:21 -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, 11 Jul 2011 21:36:21 -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= IETF. Title : An uniform format for IPv6 extension headers Author(s) : Suresh Krishnan Apple Inc. Erik Kline James Hoagland Manav Bhatia Filename : draft-ietf-6man-exthdr-04.txt Pages : 7 Date : 2011-07-11 In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternative extension mechanisms in IPv6. It also provides a format for defining new IPv6 extension headers that would allow implementations to process past unknown extension headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-exthdr-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-exthdr-04.txt From brian.e.carpenter@gmail.com Mon Jul 11 14:45:38 2011 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 F39C611E82D6 for ; Mon, 11 Jul 2011 14:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvsAa5nLGELn for ; Mon, 11 Jul 2011 14:45:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6388711E8098 for ; Mon, 11 Jul 2011 14:45:37 -0700 (PDT) Received: by vxi40 with SMTP id 40so4480552vxi.31 for ; Mon, 11 Jul 2011 14:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=A9WQLPIy/+b5YyE4+r3LDNnbZAkv/EYMqTgxzxW6xl4=; b=P/ih4dGD3Zg08fFJgOORHdnxLVGCZMPBdyOY8z99VXrkRYijtz4tKZCqL8sP5VMEVV JPd6I0d5Huhth9zJdhdb5neJmw+v+Xv5TenPt3foavgJiQCC6Ng3LvpOQVGaAQylO5iy 8mnMySrvXrbuamJ/ectUdks6ApW+fhV0CC6pw= Received: by 10.52.74.234 with SMTP id x10mr6100074vdv.18.1310420736637; Mon, 11 Jul 2011 14:45:36 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id e8sm4726158vdf.33.2011.07.11.14.45.34 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 14:45:36 -0700 (PDT) Message-ID: <4E1B6EFD.7070005@gmail.com> Date: Tue, 12 Jul 2011 09:45:33 +1200 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-flow-3697bis-06.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: Mon, 11 Jul 2011 21:45:38 -0000 This version fixes most of the Last Call comments that came in before the cutoff. However, there's a security review that came in too late for that, and several IESG comments that will need attention, so there will probably be another version in a couple of weeks. Brian -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-flow-3697bis-06.txt Date: Mon, 11 Jul 2011 14:06:07 -0700 From: internet-drafts@ietf.org Reply-To: 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 : IPv6 Flow Label Specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Filename : draft-ietf-6man-flow-3697bis-06.txt Pages : 16 Date : 2011-07-11 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-06.txt From brian.e.carpenter@gmail.com Mon Jul 11 15:12:39 2011 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 943A411E82FA for ; Mon, 11 Jul 2011 15:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.676 X-Spam-Level: X-Spam-Status: No, score=-103.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxuIqH991KXP for ; Mon, 11 Jul 2011 15:12:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0A111E8308 for ; Mon, 11 Jul 2011 15:12:38 -0700 (PDT) Received: by vxi40 with SMTP id 40so4501138vxi.31 for ; Mon, 11 Jul 2011 15:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=0nvqjRlto4FsBWfa+TztZKPk61CTBz/UiZcLDRghtHs=; b=jeXMdW5rSzfoMimf6zM02susFIYHpU2Ebh9CDuobDZjPruK/8wr/fFSSJzAXl4Z+VT 1QlkkPfsJ0++qKBhKyqOqI++0mRSWBPoVVeI5lvHJuH6Kx5lwhcfT3OQim3JVIiOsw00 PLKVlHhQ0roe4OA/8z4Upm/RxhhjF8UY6/Yh4= Received: by 10.52.187.65 with SMTP id fq1mr2729018vdc.454.1310422357993; Mon, 11 Jul 2011 15:12:37 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k14sm142322vdu.25.2011.07.11.15.12.36 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 15:12:37 -0700 (PDT) Message-ID: <4E1B7552.2050808@gmail.com> Date: Tue, 12 Jul 2011 10:12:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: draft-ietf-6man-flow-ecmp-04 as standards track instead of BCP? 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: Mon, 11 Jul 2011 22:12:39 -0000 Does anyone object to switching this draft from BCP to Standards Track? (See Pete Resnick's comments below.) It is on this Thursday's IESG agenda. Brian Carpenter -------- Original Message -------- Subject: Re: Pete Resnick's Discuss on draft-ietf-6man-flow-ecmp-04: (with DISCUSS) ... > On 2011-07-12 03:09, Pete Resnick wrote: >> Pete Resnick has entered the following ballot position for >> draft-ietf-6man-flow-ecmp-04: Discuss ... >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 3 of this document (the main section) seems like protocol to me. (For example, "Inner packets MUST be encapsulated in an outer IPv6 packet whose source and destination addresses are those of the tunnel end points (TEPs)".) Therefore, I see no reason for this not to be on the Standards Track. It seems like it has interoperability impacts and gives normative implementation guidance. >> From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 01:48:57 2011 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 3EB5F21F90E6 for ; Tue, 12 Jul 2011 01:48:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gli0sWwlnE4k for ; Tue, 12 Jul 2011 01:48:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 814C221F90CA for ; Tue, 12 Jul 2011 01:48:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QgYeD-0001i9C; Tue, 12 Jul 2011 10:48:53 +0200 Message-Id: To: ipv6@ietf.org Subject: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com Date: Tue, 12 Jul 2011 10:48:47 +0200 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, 12 Jul 2011 08:48:57 -0000 Occasionally the subject comes up: /64 (and SLAAC) is bad because it is easy to DoS routers by getting to perform too much ND. At least in theory this seems to be a valid complaint. A router can (and should) carefully allocate resources for ND to avoid having ND interfere with other parts of the routers functionality. But in the end, if the ND part of a router is overloaded and it needs to do ND for a genuine neighbor, it may have to drop the packet. So what I was thinking of, what if a router that is under attack would periodically multicast to the all-nodes multicast address a message saying "help I'm under attack". Upon receiving such a message all nodes send a neighbor solication to the router. This populates the router's neighbor cache with entries for all of it's neighbors. Thus ensuring that normal traffic can flow uninterrupted. From sander@steffann.nl Tue Jul 12 02:22:19 2011 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 5FEEF21F9086 for ; Tue, 12 Jul 2011 02:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.985 X-Spam-Level: * X-Spam-Status: No, score=1.985 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMGALRvxb11R for ; Tue, 12 Jul 2011 02:22:19 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 7774F21F907B for ; Tue, 12 Jul 2011 02:22:09 -0700 (PDT) Received: from [10.248.1.31] (unknown [188.142.127.132]) by mail.sintact.nl (Postfix) with ESMTP id 5ED9E2031; Tue, 12 Jul 2011 11:22:07 +0200 (CEST) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: Date: Tue, 12 Jul 2011 11:22:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Philip Homburg X-Mailer: Apple Mail (2.1084) 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, 12 Jul 2011 09:22:19 -0000 Hi, > So what I was thinking of, what if a router that is under attack would=20= > periodically multicast to the all-nodes multicast address a message = saying > "help I'm under attack". Upon receiving such a message all nodes send = a=20 > neighbor solication to the router. This populates the router's = neighbor > cache with entries for all of it's neighbors. Thus ensuring that = normal traffic > can flow uninterrupted. I have thought about this too. I wouldn't even mind if this became = (configurable) default behaviour. One thing though: all nodes should = send neighbour solicitations for each IPv6 address they are listening = on. Thanks, Sander From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 02:46:38 2011 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 D2CA221F914D for ; Tue, 12 Jul 2011 02:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v58t7hLF2VZm for ; Tue, 12 Jul 2011 02:46:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9F621F8E4E for ; Tue, 12 Jul 2011 02:46:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QgZY5-0001i9C; Tue, 12 Jul 2011 11:46:37 +0200 Message-Id: To: Sander Steffann Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: In-reply-to: Your message of "Tue, 12 Jul 2011 11:22:06 +0200 ." Date: Tue, 12 Jul 2011 11:46:17 +0200 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, 12 Jul 2011 09:46:38 -0000 In your letter dated Tue, 12 Jul 2011 11:22:06 +0200 you wrote: >I have thought about this too. I wouldn't even mind if this became = >(configurable) default behaviour. One thing though: all nodes should = >send neighbour solicitations for each IPv6 address they are listening = >on. I was thinking that it might be easiest to allocate some flags in the router advertisement message. In that case, you could in theory also do it per prefix. But that may complicate routers too much. (When doing ND, routers can keep track of for which on-link prefixes they have recently dropped packets. Also, routers can give priority to ND requests that originate from whithin the router, so there should never be any reason to request help for link-local addresses). From kauer@biplane.com.au Tue Jul 12 05:35:03 2011 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 8645D21F905B for ; Tue, 12 Jul 2011 05:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkIJ1ZV+SIzz for ; Tue, 12 Jul 2011 05:35:02 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0950121F9053 for ; Tue, 12 Jul 2011 05:35:00 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.203]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QgcAz-0000kV-6m for ipv6@ietf.org; Tue, 12 Jul 2011 08:34:57 -0400 Subject: Re: /64 ND DoS From: Karl Auer To: ipv6@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-rG+Wqv94/l9jF/1X5p8v" Date: Tue, 12 Jul 2011 22:34:53 +1000 Message-ID: <1310474093.2382.154.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 12 Jul 2011 12:35:03 -0000 --=-rG+Wqv94/l9jF/1X5p8v Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2011-07-12 at 11:22 +0200, Sander Steffann wrote: > > So what I was thinking of, what if a router that is under attack would The router would need to know that it was under attack. That could be quite a complicated heuristic. It seems to me that it is simpler to treat ND slot exhaustion as the problem, and not worry too much about the cause. I have no clue how sensible these ideas are: - when slots get scarce, start favouring existing completed entries. Don't time them out as fast. That is, treat completed entries as more valuable than incomplete ones. Silly to toss out a probably-good entry in favour of a definitely-incomplete one. - when slots get very scarce, start timing out incomplete entries faster, returning the slots to the pool. There will be a useful minimum time here... - store source info with each slot. Have separate slot space for local (on-router) sources and remote (off-router) sources. This lets the local network keep working even when under attack from off-router. - when slot space reaches a critical level, start ignoring requests from sources that have no completed entries. Yes, innocent new sources will suffer, but you are heading into crisis. - when and as long as there are NO slots left: - don't delete completed entries at all while there are incomplete entries to delete - delete entries with sources with the fewest completed entries first. After them, delete the oldest entries first. > > periodically multicast to the all-nodes multicast address a message say= ing > > "help I'm under attack". Upon receiving such a message all nodes send a= =20 > > neighbor solication to the router. This could be a reaction to a rapid decrease in available cache slots. Do you need a special message? A ping to the all-nodes multicast address should result in all nodes responding, and the responses would have all the info in them that you need. You'd have to do that on each link, though. And you'd have to do it *fast*. In fact, it seems to me that you would be unlikely to be able to do it fast enough to make a difference - by the time your nodes had responded, the attacker would have filled the ND cache. Doing it preemptively would make for a very chatty link. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-rG+Wqv94/l9jF/1X5p8v 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) iEYEABECAAYFAk4cP2YACgkQMAcU7Vc29of7fwCdGtkRAudDcDwPvaT8pwrAuxPP QEMAoI0hJ1onOC0DvBRwdvvQU7SPEg/W =EaJO -----END PGP SIGNATURE----- --=-rG+Wqv94/l9jF/1X5p8v-- From fweimer@bfk.de Tue Jul 12 05:40:14 2011 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 6261221F906B for ; Tue, 12 Jul 2011 05:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO43zHyo6syt for ; Tue, 12 Jul 2011 05:40:13 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id AC79921F906A for ; Tue, 12 Jul 2011 05:40:13 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QgcG4-0007Cl-A8; Tue, 12 Jul 2011 12:40:12 +0000 Received: by bfk.de with local id 1QgcG4-0001DZ-58; Tue, 12 Jul 2011 12:40:12 +0000 From: Florian Weimer To: Philip Homburg Subject: Re: /64 ND DoS References: Date: Tue, 12 Jul 2011 12:40:12 +0000 In-Reply-To: (Philip Homburg's message of "Tue, 12 Jul 2011 10:48:47 +0200") Message-ID: <82d3hfr7tf.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 12 Jul 2011 12:40:14 -0000 * Philip Homburg: > So what I was thinking of, what if a router that is under attack would > periodically multicast to the all-nodes multicast address a message > saying "help I'm under attack". Upon receiving such a message all > nodes send a neighbor solication to the router. This populates the > router's neighbor cache with entries for all of it's neighbors. Thus > ensuring that normal traffic can flow uninterrupted. Assuming that neighbor discovery is vulnerable, wouldn't the same issue affect the triggered solications? And isn't it a fine way to overload a router on a large subnet? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From brian@innovationslab.net Tue Jul 12 05:50:24 2011 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 3C15421F8B42 for ; Tue, 12 Jul 2011 05:50:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv16JAFwX-D8 for ; Tue, 12 Jul 2011 05:50:23 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id CABD121F8E3C for ; Tue, 12 Jul 2011 05:50:23 -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 5A0ED88154 for ; Tue, 12 Jul 2011 05:50:23 -0700 (PDT) Received: from clemson.local (unknown [75.94.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D812A136839E for ; Tue, 12 Jul 2011 05:50:22 -0700 (PDT) Message-ID: <4E1C4315.2080501@innovationslab.net> Date: Tue, 12 Jul 2011 08:50:29 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: draft-ietf-6man-flow-ecmp-04 as standards track instead of BCP? References: <4E1B7552.2050808@gmail.com> In-Reply-To: <4E1B7552.2050808@gmail.com> X-Enigmail-Version: 1.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: Tue, 12 Jul 2011 12:50:24 -0000 I have no objections with moving it to Standards Track. Regards, Brian On 7/11/11 6:12 PM, Brian E Carpenter wrote: > Does anyone object to switching this draft from BCP to Standards Track? > (See Pete Resnick's comments below.) > > It is on this Thursday's IESG agenda. > > Brian Carpenter > > -------- Original Message -------- > Subject: Re: Pete Resnick's Discuss on draft-ietf-6man-flow-ecmp-04: (with DISCUSS) > ... >> On 2011-07-12 03:09, Pete Resnick wrote: >>> Pete Resnick has entered the following ballot position for >>> draft-ietf-6man-flow-ecmp-04: Discuss > > ... >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> Section 3 of this document (the main section) seems like protocol to me. (For example, "Inner packets MUST be encapsulated in an outer IPv6 packet whose source and destination addresses are those of the tunnel end points (TEPs)".) Therefore, I see no reason for this not to be on the Standards Track. It seems like it has interoperability impacts and gives normative implementation guidance. >>> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 06:12:13 2011 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 3C18121F8F90 for ; Tue, 12 Jul 2011 06:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.099 X-Spam-Level: X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvzHFto2yDsP for ; Tue, 12 Jul 2011 06:12:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id B5C2421F8EF3 for ; Tue, 12 Jul 2011 06:12:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qgckq-0001i9C; Tue, 12 Jul 2011 15:12:00 +0200 Message-Id: To: Karl Auer Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <1310474093.2382.154.camel@karl> In-reply-to: Your message of "Tue, 12 Jul 2011 22:34:53 +1000 ." <1310474093.2382.154.camel@karl> Date: Tue, 12 Jul 2011 15:11:44 +0200 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, 12 Jul 2011 13:12:13 -0000 In your letter dated Tue, 12 Jul 2011 22:34:53 +1000 you wrote: >The router would need to know that it was under attack. That could be >quite a complicated heuristic. It seems to me that it is simpler to >treat ND slot exhaustion as the problem, and not worry too much about >the cause. First, let me make clear that I was thinking about remote attacks. I think that's the most serious problem. If you have malicious hosts directly attached you have bigger problems, and you have to use either SeND or L2 filtering. Assuming a remote attack, the only thing the attacker can do is cause incomplete entries to be created. So the table consist of a collection of normal (complete) entries for neighbors and a potentially large number of incomplete entries. Ultimately, the limit is not so much the number of incomplete entries in the table, but the number of NS messages you can send per second. So my definition of under attack would be that the router did not send a NS because doing so would exceed the maximum number NS messages per second. Beyond that, scale the table to hold that number of incomplete entries and you are done. >- when slots get scarce, start favouring existing completed entries. > Don't time them out as fast. That is, treat completed entries as more > valuable than incomplete ones. Silly to toss out a probably-good entry > in favour of a definitely-incomplete one. This can be done all the time. If a completed entry is less then 1 minute old, keep it. If you run out of space, then there is a local attack (or the number of neighbors exceeds what the router can handle) >- when slots get very scarce, start timing out incomplete entries > faster, returning the slots to the pool. There will be a useful > minimum time here... You only need incomplete entries for about 3 seconds (default settings). >- store source info with each slot. Have separate slot > space for local (on-router) sources and remote (off-router) sources. > This lets the local network keep working even when under attack from > off-router. Yes. Just one bit to mark an incomplete entry as local. But that should mostly effect the sending of NS messages. >- when slot space reaches a critical level, start ignoring requests from > sources that have no completed entries. Yes, innocent new sources will > suffer, but you are heading into crisis. That would be just the packets that are forwarded. >- when and as long as there are NO slots left: > - don't delete completed entries at all while there are incomplete > entries to delete I would just partition the table: some number of entries for completed and some number for incomplete. > - delete entries with sources with the fewest completed entries > first. After them, delete the oldest entries first. I think that for remote attack this doesn't make much sense. >Do you need a special message? A ping to the all-nodes multicast address >should result in all nodes responding, and the responses would have all >the info in them that you need. No, other nodes have to send a NS (or anything else that contains their link layer addresses). >You'd have to do that on each link, >though. If the bottleneck is not the table size, but number of NS messages you can send per second, then it is per overloaded link. >And you'd have to do it *fast*. In fact, it seems to me that you >would be unlikely to be able to do it fast enough to make a difference - >by the time your nodes had responded, the attacker would have filled the >ND cache. Doing it preemptively would make for a very chatty link. The attacker fills the cache with incomplete entries. NS requests can be used to create complete entries. So you can always add them to the table. From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 06:19:11 2011 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 D1F7E21F8C05 for ; Tue, 12 Jul 2011 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.266 X-Spam-Level: X-Spam-Status: No, score=-8.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EARwQM11ux0u for ; Tue, 12 Jul 2011 06:19:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8E521F858C for ; Tue, 12 Jul 2011 06:19:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qgcrl-0001pzC; Tue, 12 Jul 2011 15:19:09 +0200 Message-Id: To: Florian Weimer Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <82d3hfr7tf.fsf@mid.bfk.de> In-reply-to: Your message of "Tue, 12 Jul 2011 12:40:12 +0000 ." <82d3hfr7tf.fsf@mid.bfk.de> Date: Tue, 12 Jul 2011 15:19:05 +0200 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, 12 Jul 2011 13:19:11 -0000 In your letter dated Tue, 12 Jul 2011 12:40:12 +0000 you wrote: >* Philip Homburg: >> So what I was thinking of, what if a router that is under attack would >> periodically multicast to the all-nodes multicast address a message >> saying "help I'm under attack". Upon receiving such a message all >> nodes send a neighbor solication to the router. This populates the >> router's neighbor cache with entries for all of it's neighbors. Thus >> ensuring that normal traffic can flow uninterrupted. > >Assuming that neighbor discovery is vulnerable, wouldn't the same issue >affect the triggered solications? And isn't it a fine way to overload a >router on a large subnet? One, I was thinking about a remote attack. So neighbors are trusted. Two, a NS doesn't require the router to maintain any state. The router just stores the IPv6 address and the MAC in the table and sends an NA. As long as the router is properly sized for the number of neighbors, it should be able to store it. I'd say that a router has to be able to handle one NS per address per neighbor every 30 seconds anyhow. If the router can do that, then sending one request for help every minute should do the trick. From fweimer@bfk.de Tue Jul 12 06:22:34 2011 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 F3F4221F8B21 for ; Tue, 12 Jul 2011 06:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMtHIs+1qO0V for ; Tue, 12 Jul 2011 06:22:33 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 551C521F8558 for ; Tue, 12 Jul 2011 06:22:33 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qgcv2-0004E4-HY; Tue, 12 Jul 2011 13:22:32 +0000 Received: by bfk.de with local id 1Qgcv2-0004ot-Du; Tue, 12 Jul 2011 13:22:32 +0000 From: Florian Weimer To: Philip Homburg Subject: Re: /64 ND DoS References: <82d3hfr7tf.fsf@mid.bfk.de> Date: Tue, 12 Jul 2011 13:22:32 +0000 In-Reply-To: (Philip Homburg's message of "Tue, 12 Jul 2011 15:19:05 +0200") Message-ID: <824o2rr5uv.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 12 Jul 2011 13:22:34 -0000 * Philip Homburg: > Two, a NS doesn't require the router to maintain any state. The router > just stores the IPv6 address and the MAC in the table and sends an NA. Huh? If this isn't state, then what is it? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 06:26:59 2011 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 88E0C21F8EAD for ; Tue, 12 Jul 2011 06:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.349 X-Spam-Level: X-Spam-Status: No, score=-8.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLVwuQQvKyvS for ; Tue, 12 Jul 2011 06:26:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC3621F8EA6 for ; Tue, 12 Jul 2011 06:26:58 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QgczJ-0001hwC; Tue, 12 Jul 2011 15:26:57 +0200 Message-Id: To: Florian Weimer Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <82d3hfr7tf.fsf@mid.bfk.de> <824o2rr5uv.fsf@mid.bfk.de> In-reply-to: Your message of "Tue, 12 Jul 2011 13:22:32 +0000 ." <824o2rr5uv.fsf@mid.bfk.de> Date: Tue, 12 Jul 2011 15:26:57 +0200 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, 12 Jul 2011 13:26:59 -0000 In your letter dated Tue, 12 Jul 2011 13:22:32 +0000 you wrote: >* Philip Homburg: >> Two, a NS doesn't require the router to maintain any state. The router >> just stores the IPv6 address and the MAC in the table and sends an NA. > >Huh? If this isn't state, then what is it? It is state, but it is not required :-) Updating the table is optional. In this case it is desired. But there is no reason to expect that the situation will get worse. Unless the router was too small to begin with. From fweimer@bfk.de Tue Jul 12 06:31:30 2011 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 17A1121F9025 for ; Tue, 12 Jul 2011 06:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ectuKnplpaQv for ; Tue, 12 Jul 2011 06:31:29 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5F21F9024 for ; Tue, 12 Jul 2011 06:31:29 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qgd3b-0005LB-SD; Tue, 12 Jul 2011 13:31:23 +0000 Received: by bfk.de with local id 1Qgd3b-0003Kx-Nt; Tue, 12 Jul 2011 13:31:23 +0000 From: Florian Weimer To: Philip Homburg Subject: Re: /64 ND DoS References: <1310474093.2382.154.camel@karl> Date: Tue, 12 Jul 2011 13:31:23 +0000 In-Reply-To: (Philip Homburg's message of "Tue, 12 Jul 2011 15:11:44 +0200") Message-ID: <82zkkjpqvo.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 12 Jul 2011 13:31:30 -0000 * Philip Homburg: > First, let me make clear that I was thinking about remote attacks. How would a remote attack work? > I think that's the most serious problem. If you have malicious hosts > directly attached you have bigger problems, and you have to use either > SeND or L2 filtering. On its own, neither SeND nor L2 filtering prevent any attacks on neighbor discovery. You need some sort of layering violation to tie endpoints to specific addresses, and nothing working exclusively on layer 2 or the IP layer can achieve that. Once you can make that connection, you can also limit the amount of processing power and state per identified endpoint. But without that, you have zero chance against a local attacker. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From joelja@bogus.com Tue Jul 12 06:46:21 2011 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 D882D21F90F0 for ; Tue, 12 Jul 2011 06:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgNrUJyvGPY2 for ; Tue, 12 Jul 2011 06:46:21 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14A21F90D7 for ; Tue, 12 Jul 2011 06:46:21 -0700 (PDT) Received: from [192.168.1.171] (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6CDkDOg074021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2011 13:46:16 GMT (envelope-from joelja@bogus.com) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Tue, 12 Jul 2011 06:45:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> References: To: Philip Homburg X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 12 Jul 2011 13:46:16 +0000 (UTC) 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, 12 Jul 2011 13:46:22 -0000 we had a couple of suggestions. http://www.ietf.org/id/draft-gashinsky-v6nd-enhance-00.txt On Jul 12, 2011, at 1:48 AM, Philip Homburg wrote: > Occasionally the subject comes up: /64 (and SLAAC) is bad because it = is > easy to DoS routers by getting to perform too much ND. >=20 > At least in theory this seems to be a valid complaint. A router can = (and > should) carefully allocate resources for ND to avoid having ND = interfere with > other parts of the routers functionality.=20 >=20 > But in the end, if the ND part of a router is overloaded and it needs = to do > ND for a genuine neighbor, it may have to drop the packet. >=20 > So what I was thinking of, what if a router that is under attack would=20= > periodically multicast to the all-nodes multicast address a message = saying > "help I'm under attack". Upon receiving such a message all nodes send = a=20 > neighbor solication to the router. This populates the router's = neighbor > cache with entries for all of it's neighbors. Thus ensuring that = normal traffic > can flow uninterrupted. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 06:56:36 2011 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 9F42821F9131 for ; Tue, 12 Jul 2011 06:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbiXCBLMgPfl for ; Tue, 12 Jul 2011 06:56:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D4C7B21F912E for ; Tue, 12 Jul 2011 06:56:35 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QgdRy-0001hpC; Tue, 12 Jul 2011 15:56:34 +0200 Message-Id: To: Florian Weimer Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <1310474093.2382.154.camel@karl> <82zkkjpqvo.fsf@mid.bfk.de> In-reply-to: Your message of "Tue, 12 Jul 2011 13:31:23 +0000 ." <82zkkjpqvo.fsf@mid.bfk.de> Date: Tue, 12 Jul 2011 15:56:24 +0200 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, 12 Jul 2011 13:56:36 -0000 In your letter dated Tue, 12 Jul 2011 13:31:23 +0000 you wrote: >* Philip Homburg: > >> First, let me make clear that I was thinking about remote attacks. > >How would a remote attack work? You send a stream of packets directed to a particular /64 but you make sure that each packet has a different destination address. The router that attaches to the /64 has perform ND for each packet. Assuming that those addresses are not in use, it takes 3 seconds for the ND to time out. So the router will have to maintain a huge amount of state. And, because the NS messages are multicast, you have to rate limit them. >> I think that's the most serious problem. If you have malicious hosts >> directly attached you have bigger problems, and you have to use either >> SeND or L2 filtering. > >On its own, neither SeND nor L2 filtering prevent any attacks on >neighbor discovery. You need some sort of layering violation to tie >endpoints to specific addresses, and nothing working exclusively on >layer 2 or the IP layer can achieve that. Once you can make that >connection, you can also limit the amount of processing power and state >per identified endpoint. But without that, you have zero chance against >a local attacker. For fixed ethernet (wireless is more tricky) a switch could limit the number of MAC addresses per port in time. If you then limit the number of IPv6 address per MAC (that would require a layer violation) then can prevent hosts from executing a local attack. From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 07:04:41 2011 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 775C921F9170 for ; Tue, 12 Jul 2011 07:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.432 X-Spam-Level: X-Spam-Status: No, score=-8.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwn1lZ9bqovF for ; Tue, 12 Jul 2011 07:04:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 54B7D21F916E for ; Tue, 12 Jul 2011 07:04:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QgdZi-0001i5C; Tue, 12 Jul 2011 16:04:34 +0200 Message-Id: To: Joel Jaeggli Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> In-reply-to: Your message of "Tue, 12 Jul 2011 06:45:59 -0700 ." <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> Date: Tue, 12 Jul 2011 16:04:33 +0200 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, 12 Jul 2011 14:04:41 -0000 In your letter dated Tue, 12 Jul 2011 06:45:59 -0700 you wrote: >we had a couple of suggestions. > >http://www.ietf.org/id/draft-gashinsky-v6nd-enhance-00.txt Yes, but I prefer something triggered by a router then just requiring host to do something occasionally on their own. From joelja@bogus.com Tue Jul 12 08:17:39 2011 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 6EA8A21F8D57 for ; Tue, 12 Jul 2011 08:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIt0YwvLnA3R for ; Tue, 12 Jul 2011 08:17:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE2521F8D56 for ; Tue, 12 Jul 2011 08:17:38 -0700 (PDT) Received: from [172.16.24.53] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6CFHaFr076348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2011 15:17:37 GMT (envelope-from joelja@bogus.com) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Tue, 12 Jul 2011 08:17:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B8CE538-3C26-4280-B524-A90E6DD38A65@bogus.com> References: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 12 Jul 2011 15:17:37 +0000 (UTC) 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, 12 Jul 2011 15:17:39 -0000 On Jul 12, 2011, at 7:04 AM, Philip Homburg wrote: > In your letter dated Tue, 12 Jul 2011 06:45:59 -0700 you wrote: >> we had a couple of suggestions. >>=20 >> http://www.ietf.org/id/draft-gashinsky-v6nd-enhance-00.txt >=20 > Yes, but I prefer something triggered by a router then just requiring > host to do something occasionally on their own. The problem in my opinion is not that the router isn't sending enough = messages. It's sending too many for it's own purposes. keeping existing known hosts in the cache and learning new ones in the = face of resource exhaustion is the challenge. >=20 From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 08:40:42 2011 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 50B7521F8F69 for ; Tue, 12 Jul 2011 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.456 X-Spam-Level: X-Spam-Status: No, score=-8.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbRVmvrCGytk for ; Tue, 12 Jul 2011 08:40:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 965DB21F8F66 for ; Tue, 12 Jul 2011 08:40:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qgf4e-0001i9C; Tue, 12 Jul 2011 17:40:36 +0200 Message-Id: To: Joel Jaeggli Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> <2B8CE538-3C26-4280-B524-A90E6DD38A65@bogus.com> In-reply-to: Your message of "Tue, 12 Jul 2011 08:17:31 -0700 ." <2B8CE538-3C26-4280-B524-A90E6DD38A65@bogus.com> Date: Tue, 12 Jul 2011 17:40:29 +0200 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, 12 Jul 2011 15:40:42 -0000 In your letter dated Tue, 12 Jul 2011 08:17:31 -0700 you wrote: >The problem in my opinion is not that the router isn't sending enough = >messages. It's sending too many for it's own purposes. > >keeping existing known hosts in the cache and learning new ones in the = >face of resource exhaustion is the challenge. In theory, when the router is in distress, it could just limit itself to sending out the distress signal and waiting for the neighbors to respond with NS messages. From bob.hinden@gmail.com Tue Jul 12 09:05:23 2011 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 12DA221F8E35 for ; Tue, 12 Jul 2011 09:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sBbM+2Acs1d for ; Tue, 12 Jul 2011 09:05:19 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 045AC21F8E2A for ; Tue, 12 Jul 2011 09:05:18 -0700 (PDT) Received: by gyd5 with SMTP id 5so2390546gyd.31 for ; Tue, 12 Jul 2011 09:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=Af8cOg2JV8EEOyw0ystciExUt/y6KHUnI+ivhYCNsfM=; b=qDwhAhWQmXxb7hqtt2IeWI84PDzmYTDwWPbymhmK4/LZ/PAG8JLi6f9F1u4AOU4Kr5 sZw7Ot/gFk0JCqMiFRlCGf9XRcLxgbkCaqIF6OPju1790swMBt63pYQhoaCkn7KA4QEj EcU6CM9VTGuLCUYy7OclOUn+drNftIsO6U5+w= Received: by 10.101.165.1 with SMTP id s1mr116059ano.52.1310486718468; Tue, 12 Jul 2011 09:05:18 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id w10sm5126925ano.32.2011.07.12.09.05.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 09:05:17 -0700 (PDT) From: Bob Hinden Content-Type: multipart/alternative; boundary=Apple-Mail-3--680450750 Subject: Agenda posted for 6MAN Working Group - IETF 81 Quebec City Date: Tue, 12 Jul 2011 09:05:14 -0700 Message-Id: <7810DB2A-25B7-41B1-AD56-60CDC116FB6D@gmail.com> To: 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden 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, 12 Jul 2011 16:05:23 -0000 --Apple-Mail-3--680450750 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii You can find the current agenda at: http://www.ietf.org/proceedings/81/agenda/6man.html I think we were able to accommodate the requests we received. Bob --Apple-Mail-3--680450750 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
You can = find the current agenda at:
http://www.ie= tf.org/proceedings/81/agenda/6man.html

I think we = were able to accommodate the requests we received.

Bob

= --Apple-Mail-3--680450750-- From jared@puck.nether.net Tue Jul 12 09:09:12 2011 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 5ACE521F8E65 for ; Tue, 12 Jul 2011 09:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc0ir3I8D7hi for ; Tue, 12 Jul 2011 09:09:11 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 893EF21F8E67 for ; Tue, 12 Jul 2011 09:09:11 -0700 (PDT) Received: from [IPv6:2001:418:3f4:2:217:f2ff:fecf:8ee1] ([IPv6:2001:418:3f4:2:217:f2ff:fecf:8ee1]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p6CG930t083776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Jul 2011 12:09:04 -0400 (EDT) (envelope-from jared@puck.nether.net) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 12 Jul 2011 12:09:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [IPv6:2001:418:3f4::5]); Tue, 12 Jul 2011 12:09:04 -0400 (EDT) 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, 12 Jul 2011 16:09:12 -0000 On Jul 12, 2011, at 10:04 AM, Philip Homburg wrote: > In your letter dated Tue, 12 Jul 2011 06:45:59 -0700 you wrote: >> we had a couple of suggestions. >>=20 >> http://www.ietf.org/id/draft-gashinsky-v6nd-enhance-00.txt >=20 > Yes, but I prefer something triggered by a router then just requiring > host to do something occasionally on their own. You can't have two-party communication have only one part (the router) = perform all the actions. Is there a specific part of the above draft that you think should be = changed? In what manner? I happen to think that it's not desirable to have any network element = under attack, but the ideas in the draft seem to be well thought out, = but perhaps not clearly stated enough for your needs? (and with the = least amount of protocol changes necessary, infact i believe only one, = the rest could be seen as implementation details that would result in a = lab failure and failure of RFP with noncompliant vendors). - Jared= From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 09:39:50 2011 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 966F221F8CFC for ; Tue, 12 Jul 2011 09:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.474 X-Spam-Level: X-Spam-Status: No, score=-8.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9SXMH3QYbhK for ; Tue, 12 Jul 2011 09:39:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06F21F8E0D for ; Tue, 12 Jul 2011 09:39:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qgfzt-0001i5C; Tue, 12 Jul 2011 18:39:45 +0200 Message-Id: To: Jared Mauch Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> In-reply-to: Your message of "Tue, 12 Jul 2011 12:09:03 -0400 ." Date: Tue, 12 Jul 2011 18:39:42 +0200 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, 12 Jul 2011 16:39:50 -0000 In your letter dated Tue, 12 Jul 2011 12:09:03 -0400 you wrote: >You can't have two-party communication have only one part (the router) = >perform all the actions. So, in my proposal, the router sends out a request for help. And all of its neighbors respond with a Neighbor Solicitation. >Is there a specific part of the above draft that you think should be = >changed? In what manner? Well, add my proposal :-) Formally request a change to the Neighbor Discovery RFC that allows this to happen. >I happen to think that it's not desirable to have any network element = >under attack, but the ideas in the draft seem to be well thought out, = >but perhaps not clearly stated enough for your needs? (and with the = >least amount of protocol changes necessary, infact i believe only one, = >the rest could be seen as implementation details that would result in a = >lab failure and failure of RFP with noncompliant vendors). I think they are certainly not stated clearly enough. But also don't think they go far enough. As far as I can tell, the draft does not contain a protocol that will always work. It contains a number of suggestions that to some extent mitigate the problem. For example, "Hosts MAY be configured to send unsolicited Neighbor advertisement "at a rate set at the discretion of the operators. The rate SHOULD "be appropriate to the sizing of ND cache parameters and the host "count on the subnet. An unsolicited NA rate parameter MUST NOT be "enabled by default. What does that mean? Each time I connect my laptop to a network, an operator shows up from behind the bushes and configures the right parameters? What if it doesn't happen? Then my laptop is not protected a case of a DoS on the router? IMHO, what is needed is to write a document that lists changes and additions relative to the neighbor discovery rfc, such that by default, routers and hosts can be protected against this attack. From joelja@bogus.com Tue Jul 12 09:56:41 2011 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 9E31C21F8E55 for ; Tue, 12 Jul 2011 09:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRSVATp6fToZ for ; Tue, 12 Jul 2011 09:56:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7B21F8E48 for ; Tue, 12 Jul 2011 09:56:40 -0700 (PDT) Received: from [172.16.24.53] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6CGudJO079405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2011 16:56:39 GMT (envelope-from joelja@bogus.com) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Tue, 12 Jul 2011 09:56:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <689A4B0D-085C-4E88-AB80-EE4CC36F5046@bogus.com> References: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 12 Jul 2011 16:56:40 +0000 (UTC) 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, 12 Jul 2011 16:56:41 -0000 On Jul 12, 2011, at 9:39 AM, Philip Homburg wrote: > In your letter dated Tue, 12 Jul 2011 12:09:03 -0400 you wrote: >> You can't have two-party communication have only one part (the = router) =3D >> perform all the actions. >=20 > So, in my proposal, the router sends out a request for help. And all = of its > neighbors respond with a Neighbor Solicitation. >=20 >> Is there a specific part of the above draft that you think should be = =3D >> changed? In what manner? >=20 > Well, add my proposal :-) Formally request a change to the Neighbor = Discovery=20 > RFC that allows this to happen. >=20 >> I happen to think that it's not desirable to have any network element = =3D >> under attack, but the ideas in the draft seem to be well thought out, = =3D >> but perhaps not clearly stated enough for your needs? (and with the = =3D >> least amount of protocol changes necessary, infact i believe only = one, =3D >> the rest could be seen as implementation details that would result in = a =3D >> lab failure and failure of RFP with noncompliant vendors). >=20 > I think they are certainly not stated clearly enough. But also don't = think > they go far enough. As far as I can tell, the draft does not contain a = protocol > that will always work. >=20 > It contains a number of suggestions that to some extent mitigate the = problem. >=20 > For example, >=20 > "Hosts MAY be configured to send unsolicited Neighbor advertisement > "at a rate set at the discretion of the operators. The rate SHOULD > "be appropriate to the sizing of ND cache parameters and the host > "count on the subnet. An unsolicited NA rate parameter MUST NOT be > "enabled by default. >=20 > What does that mean? Each time I connect my laptop to a network, an = operator > shows up from behind the bushes and configures the right parameters? first off, beaconing is clearly not appropriate for all environments. so = I wouldn't expect a laptop to do it at all unless you were explicit in = your desire to do so. the goal was also to make the mechanism backward = compatible with existing ND behavior, where such a message unsolicited = would be grounds for kicking off a neighbor discovery process. > What if it doesn't happen? Then my laptop is not protected a case of a = DoS on > the router? it's the router's ndp cache not the laptop that's the target of the dos. > IMHO, what is needed is to write a document that lists changes and = additions > relative to the neighbor discovery rfc, such that by default, routers = and > hosts can be protected against this attack. 7.3 and 7.4 are in fact proposals for changes to 4861. They could be = split into a separate document. goal was to get something out so that we = could shoot holes in it. implementation advice in 7.1 7.2 are things that can be done without = making changes to the way that NDP works today. >=20 From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 10:31:49 2011 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 171E621F8CAF for ; Tue, 12 Jul 2011 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.488 X-Spam-Level: X-Spam-Status: No, score=-8.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNoqUPS1D4iC for ; Tue, 12 Jul 2011 10:31:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id BE6D721F8C80 for ; Tue, 12 Jul 2011 10:31:47 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QggoA-0001i5C; Tue, 12 Jul 2011 19:31:42 +0200 Message-Id: To: Joel Jaeggli Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> <689A4B0D-085C-4E88-AB80-EE4CC36F5046@bogus.com> In-reply-to: Your message of "Tue, 12 Jul 2011 09:56:33 -0700 ." <689A4B0D-085C-4E88-AB80-EE4CC36F5046@bogus.com> Date: Tue, 12 Jul 2011 19:31:33 +0200 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, 12 Jul 2011 17:31:49 -0000 In your letter dated Tue, 12 Jul 2011 09:56:33 -0700 you wrote: >On Jul 12, 2011, at 9:39 AM, Philip Homburg wrote: >> What does that mean? Each time I connect my laptop to a network, an = >operator >> shows up from behind the bushes and configures the right parameters? > >first off, beaconing is clearly not appropriate for all environments. so = >I wouldn't expect a laptop to do it at all unless you were explicit in = >your desire to do so. the goal was also to make the mechanism backward = >compatible with existing ND behavior, where such a message unsolicited = >would be grounds for kicking off a neighbor discovery process. >From a presentation perspective, I think it would be better if you start with the general solution before moving to more specialized ones. (I'll ignore this part for now) >it's the router's ndp cache not the laptop that's the target of the dos. I know. But it is vital that my laptop's MAC gets into the router's neighbor cache. So I assumed that this was done using beaconing. >> IMHO, what is needed is to write a document that lists changes and = >additions >> relative to the neighbor discovery rfc, such that by default, routers = >and >> hosts can be protected against this attack. > >7.3 and 7.4 are in fact proposals for changes to 4861. They could be = >split into a separate document. goal was to get something out so that we = >could shoot holes in it. Moving it to separate document is one thing. Moving it to its own section and using more formal language wouldn't hurt. In particular try to make clear what you want to add to what sections of RFC-4861. Now to Section 7.4. Are you seriously suggesting that on a large network, every host when it boots sends a multicast to the all-routers address? You have 6000 hosts that wake up after a power failure and they just randomly multicast to the all-routers address? And then what? How does this stay in all of the routers' neighbor caches for ever? Except that hosts can use privacy address, so more and more addresses have to become locked in the routers' caches. What if a router reboots? >implementation advice in 7.1 7.2 are things that can be done without = >making changes to the way that NDP works today. Even then, if doing things in the right order is critical, that should be considered part of the protocol. Even if the bits on the wire remain the same. From jared@puck.nether.net Tue Jul 12 10:50:23 2011 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 896A921F8E03 for ; Tue, 12 Jul 2011 10:50:23 -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=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RGf9z+6TxtC for ; Tue, 12 Jul 2011 10:50:19 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 635C521F8D7E for ; Tue, 12 Jul 2011 10:50:19 -0700 (PDT) Received: from [10.0.0.241] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p6CHoDE0066573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Jul 2011 13:50:13 -0400 (EDT) (envelope-from jared@puck.nether.net) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 12 Jul 2011 13:50:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15EA4C51-8A7D-4F3D-B8E2-01926D70C973@bogus.com> <689A4B0D-085C-4E88-AB80-EE4CC36F5046@bogus.com> To: Philip Homburg X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 12 Jul 2011 13:50:14 -0400 (EDT) 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, 12 Jul 2011 17:50:23 -0000 Keeping the scope on this part only... On Jul 12, 2011, at 1:31 PM, Philip Homburg wrote: > You have 6000 hosts that wake up after a power failure and they just = randomly > multicast to the all-routers address? I think this is just an example, it's also IMHO a test that means you = read the draft (or at least that part). I think this needs to be refined, hence the feedback process via the = community here. I think sending to all-routers (or all-hosts) is = generally an unwelcome event, but it is a way to have the host = communicate with something that is setting the "i'm a router" bit. - Jared= From dougb@dougbarton.us Tue Jul 12 11:39:18 2011 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 0C3E121F8D5A for ; Tue, 12 Jul 2011 11:39:18 -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.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoSa1sO3QQ1c for ; Tue, 12 Jul 2011 11:39:13 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8A21F8E2D for ; Tue, 12 Jul 2011 11:39:10 -0700 (PDT) Received: (qmail 22939 invoked by uid 399); 12 Jul 2011 18:39:05 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 12 Jul 2011 18:39:05 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E1C94C5.8030308@dougbarton.us> Date: Tue, 12 Jul 2011 11:39:01 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Philip Homburg Subject: Re: /64 ND DoS References: In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 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, 12 Jul 2011 18:39:18 -0000 On 07/12/2011 01:48, Philip Homburg wrote: > So what I was thinking of, what if a router that is under attack would > periodically multicast to the all-nodes multicast address a message saying > "help I'm under attack". Upon receiving such a message all nodes send a > neighbor solication to the router. This populates the router's neighbor > cache with entries for all of it's neighbors. Thus ensuring that normal traffic > can flow uninterrupted. I like this idea, and would like to suggest that we name it the HHIBR packet. Doug (Help, help! I'm being repressed!) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From sander@steffann.nl Tue Jul 12 12:09:26 2011 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 DE7E621F8EB2 for ; Tue, 12 Jul 2011 12:09:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LrRfvjLB98C for ; Tue, 12 Jul 2011 12:09:26 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id DE34621F8EB0 for ; Tue, 12 Jul 2011 12:09:25 -0700 (PDT) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id 58A52203C; Tue, 12 Jul 2011 21:09:21 +0200 (CEST) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <4E1C94C5.8030308@dougbarton.us> Date: Tue, 12 Jul 2011 21:09:20 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7671DE0A-9EB1-4919-BB8E-018BC0EDD3B9@steffann.nl> References: <4E1C94C5.8030308@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) 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, 12 Jul 2011 19:09:27 -0000 Hi Doug, > I like this idea, and would like to suggest that we name it the HHIBR > packet. > > Doug (Help, help! I'm being repressed!) Well, this is all about the violence inherent in the system! ;-) Sander From fred@cisco.com Tue Jul 12 13:39:53 2011 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 5EEF121F8B53 for ; Tue, 12 Jul 2011 13:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.352 X-Spam-Level: X-Spam-Status: No, score=-105.352 tagged_above=-999 required=5 tests=[AWL=-2.753, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gvVR7fXFOLi for ; Tue, 12 Jul 2011 13:39:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2633D21F8B4C for ; Tue, 12 Jul 2011 13:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=267; q=dns/txt; s=iport; t=1310503189; x=1311712789; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=XsI4ssg3K0Wlwq2AmfzaHZfhpn6tSlsoogRWalEIUh0=; b=G4SzaZ98NlLaxgt08F8fnIr/I6vo1WGbJru2Y/AwwhJAxsa3zAZo9GDE Hsh4aR6R3NdnXpXV78unCRxmNke8AsN0ewr5hYlnFdFbWg0J5Nn/7ZgK8 Xt+DK+jBZEuN4RYbUBHqdzNrsl9L24hjJg5xW11DvfQcbnKJKFqQva54x 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACOwHE6rRDoJ/2dsb2JhbABTpzN3iHqkH54IhVtfBJJchH+LaA X-IronPort-AV: E=Sophos;i="4.65,522,1304294400"; d="scan'208";a="2290967" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2011 20:39:45 +0000 Received: from Freds-Computer.local (sjc-vpn5-1911.cisco.com [10.21.95.119]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6CKdhjS005527; Tue, 12 Jul 2011 20:39:44 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 12 Jul 2011 16:39:44 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 12 Jul 2011 16:39:44 -0400 Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 12 Jul 2011 16:39:19 -0400 Message-Id: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> References: To: Philip Homburg X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii 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, 12 Jul 2011 20:39:53 -0000 On Jul 12, 2011, at 4:48 AM, Philip Homburg wrote: > Occasionally the subject comes up: /64 (and SLAAC) is bad because it is > easy to DoS routers by getting to perform too much ND. I suppose the same might be true of ARP. Has it been observed in the wild? From huitema@microsoft.com Tue Jul 12 13:52:12 2011 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 B27D021F8C28 for ; Tue, 12 Jul 2011 13:52:12 -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, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZQ9yBMFGblR for ; Tue, 12 Jul 2011 13:52:12 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3F94D21F8C26 for ; Tue, 12 Jul 2011 13:52:12 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 12 Jul 2011 13:52:12 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.323.2; Tue, 12 Jul 2011 13:52:11 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.52]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Tue, 12 Jul 2011 13:52:11 -0700 From: Christian Huitema To: Fred Baker , Philip Homburg Subject: RE: /64 ND DoS Thread-Topic: /64 ND DoS Thread-Index: AQHMQHCeJ2nzCpZQtkuXIbj7frsScZTpnAOA//+M8XA= Date: Tue, 12 Jul 2011 20:52:11 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> In-Reply-To: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.28] Content-Type: text/plain; charset="us-ascii" 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, 12 Jul 2011 20:52:12 -0000 > I suppose the same might be true of ARP. Has it been observed in the wild= ? Suppose a simple attack of: For each address A in subnet, Compose packet with source=3Dlocal and dest=3DA Send packet to router In a typical IPv4 subnet, the loop will run 255 times. In a very large one,= a few thousand times. In an IPv6 subnet, the loop will run 2^64 times, and= the effect on the neighbor cache on the router could be interesting. On the other hand, there are many ways for a local host to DOS a local rout= er. I am not sure that this specific one is particularly practical, or worr= isome. -- Christian Huitema =20 From joelja@bogus.com Tue Jul 12 13:58:43 2011 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 B83EA11E8081 for ; Tue, 12 Jul 2011 13:58:43 -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=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4Z0S9o0yqN2 for ; Tue, 12 Jul 2011 13:58:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 29E2711E8078 for ; Tue, 12 Jul 2011 13:58:42 -0700 (PDT) Received: from [172.16.24.53] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6CKwelE083984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2011 20:58:41 GMT (envelope-from joelja@bogus.com) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> Date: Tue, 12 Jul 2011 13:58:35 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 12 Jul 2011 20:58:41 +0000 (UTC) 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, 12 Jul 2011 20:58:43 -0000 On Jul 12, 2011, at 1:39 PM, Fred Baker wrote: > > On Jul 12, 2011, at 4:48 AM, Philip Homburg wrote: > >> Occasionally the subject comes up: /64 (and SLAAC) is bad because it is >> easy to DoS routers by getting to perform too much ND. > > I suppose the same might be true of ARP. Has it been observed in the wild? if you have a big enough subnet yes it is... on the scale of a /19 the volume of broadcast traffic begins to annoy imho. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From pch-b2B3A6689@u-1.phicoh.com Tue Jul 12 14:07:04 2011 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 B688821F8AD1 for ; Tue, 12 Jul 2011 14:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4f0YWWNThsW for ; Tue, 12 Jul 2011 14:07:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id F40F221F8ACA for ; Tue, 12 Jul 2011 14:07:03 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QgkAU-0001cKC; Tue, 12 Jul 2011 23:06:58 +0200 Message-Id: To: Christian Huitema Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-reply-to: Your message of "Tue, 12 Jul 2011 20:52:11 +0000 ." <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 12 Jul 2011 23:06:48 +0200 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, 12 Jul 2011 21:07:04 -0000 In your letter dated Tue, 12 Jul 2011 20:52:11 +0000 you wrote: >On the other hand, there are many ways for a local host to DOS a local rout= >er. I am not sure that this specific one is particularly practical, or worr= >isome. I guess I should have been way more explicit that I was thinking about the remote attack. From arturo.servin@gmail.com Tue Jul 12 15:32:19 2011 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 B603F21F85BA for ; Tue, 12 Jul 2011 15:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gL1MstQTOTzK for ; Tue, 12 Jul 2011 15:32:19 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2923A21F85A0 for ; Tue, 12 Jul 2011 15:32:19 -0700 (PDT) Received: by gxk19 with SMTP id 19so1919679gxk.31 for ; Tue, 12 Jul 2011 15:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Rdli1tG/rCN9zdHoMiRMCwxMjb8KOtP9Pkfx1lrFn8g=; b=FczVH8cFaCjSPVdkOhGFsRBXpfY7fy+1wH3I86Yggf5O33D8evmV34GB58KbQ8RGz4 vzEoN0hj17vZ67rK6MQm0Ks9aA0DCU97qWjUOo7rhMkoxEln4VR1zgiKk/UmAXzBnBkq dYe1ZHHDjnOdt2iXHFtgIqIqVfF5MvEDWSlpI= Received: by 10.151.79.16 with SMTP id g16mr593880ybl.404.1310509938655; Tue, 12 Jul 2011 15:32:18 -0700 (PDT) Received: from [192.168.9.164] ([190.213.0.174]) by mx.google.com with ESMTPS id v4sm984937yhm.48.2011.07.12.15.32.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 15:32:17 -0700 (PDT) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Tue, 12 Jul 2011 18:32:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Philip Homburg X-Mailer: Apple Mail (2.1084) 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, 12 Jul 2011 22:32:19 -0000 IMHO I think this would be a vector for other attacks in ND. You may solve a remote attack but you are opening the door to = local attacks, and a big ones I think. Regards, .as On 12 Jul 2011, at 04:48, Philip Homburg wrote: > So what I was thinking of, what if a router that is under attack would=20= > periodically multicast to the all-nodes multicast address a message = saying > "help I'm under attack". Upon receiving such a message all nodes send = a=20 > neighbor solication to the router. This populates the router's = neighbor > cache with entries for all of it's neighbors. Thus ensuring that = normal traffic > can flow uninterrupted. From v6ops@globis.net Tue Jul 12 16:47:43 2011 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 3765711E8073 for ; Tue, 12 Jul 2011 16:47:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EToplZyG+GFD for ; Tue, 12 Jul 2011 16:47:42 -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 506F111E8071 for ; Tue, 12 Jul 2011 16:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 16DB18700E4; Wed, 13 Jul 2011 01:47:41 +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 ml6I2Uc7G8gw; Wed, 13 Jul 2011 01:47:33 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E20B6870066; Wed, 13 Jul 2011 01:47:32 +0200 (CEST) Message-ID: <4E1CDD14.7020702@globis.net> Date: Wed, 13 Jul 2011 01:47:32 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Jared Mauch , ipv6@ietf.org Subject: [ipv6] Re: /64 ND DoS 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, 12 Jul 2011 23:47:43 -0000 > > Message: 9 > Date: Tue, 12 Jul 2011 13:50:16 -0400 > From: Jared Mauch > To: Philip Homburg > Cc:ipv6@ietf.org > Subject: Re: /64 ND DoS > Message-ID: > Content-Type: text/plain; charset=us-ascii > > I think this needs to be refined, hence the feedback process via the community here. I think sending to all-routers (or all-hosts) is generally an unwelcome event, but it is a way to have the host communicate with something that is setting the "i'm a router" bit. > > - Jared > It seems to me that the root cause of the problem is the size of the (default) /64 prefix defined for SLAAC compared to the capabilities of current computers / routers to provide sufficient slots/ resources for ND, especially when under remote attack. One mitigation measure is suggested in section 6.2. Appropriate Subnet Sizing. Here's a brute-force "what if" scenario for your consideration / discussion. Today SLAAC addresses (RFC4862) are built on EUI-64 addresses, which in turn are derived from EUI-48, with some defined padding. But EUI-48 itself has a not-very-well-published sub-structure of a "manufacturer's IEEE-assigned company_id" and a "manufacturer-selected extension identifier" What if SLAAC was (temporarily) redefined to build EUI-64 identifiers with the manufacturer's IEEE-assigned company_id set to a single well known value? i.e. EUI-64 was derived from the "manufacturer-selected extension identifier" only. That would effectively mean there'd be 2^24 different possible interface identifiers per prefix. Are 2^24 interface identifiers small enough that every implementation could simply provide enough resources (for ND) to cope with all addresses being in play simultaneously? 2^24 is approx 17e6 table entries as a maximum, which may not be excessive for most modern devices, even most embedded ones. Whereas 2^64 has already been shown to be excessive via the ND vulnerability. Would 2^24 interface identifiers be large enough to ensure that SLAAC can still produce enough node identifiers whilst avoiding producing excessive collisions in Duplicate Address Detection (DAD)? [bearing in mind anyway the limited variation in the first 24 bits of EUI-48 in practice] Or can SLAAC and DAD be amended to 'guess and test' a new interface identifier automatically on detection of a duplicate address [like Appletalk node ID acquisition on Extended Networks]? Would 2^24 interface identifiers be large enough that RFC 4941 (privacy extension) addresses are still reasonably useful? [again bearing in mind the limited variation in the first 24 bits of EUI-48 in practice] IMVHO this might be a useful compromise to investigate further. regards, RayH From huitema@microsoft.com Tue Jul 12 16:56:39 2011 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 B36D011E80AF for ; Tue, 12 Jul 2011 16:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.499 X-Spam-Level: X-Spam-Status: No, score=-11.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urV0Qzs2idJD for ; Tue, 12 Jul 2011 16:56:39 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC7F11E80B4 for ; Tue, 12 Jul 2011 16:56:39 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 12 Jul 2011 16:56:38 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.323.2; Tue, 12 Jul 2011 16:56:38 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.52]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Tue, 12 Jul 2011 16:56:38 -0700 From: Christian Huitema To: Philip Homburg Subject: RE: /64 ND DoS Thread-Topic: /64 ND DoS Thread-Index: AQHMQNepmHcnhmqIhE+kNwuz2UPtvZTpXAhQ Date: Tue, 12 Jul 2011 23:56:38 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.28] Content-Type: text/plain; charset="us-ascii" 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, 12 Jul 2011 23:56:39 -0000 > From: pch-b2B3A6689@u-1.phicoh.com [mailto:pch-b2B3A6689@u-1.phicoh.com]= On Behalf Of Philip Homburg > In your letter dated Tue, 12 Jul 2011 20:52:11 +0000 you wrote: >> On the other hand, there are many ways for a local host to DOS a local=20 > >router. I am not sure that this specific one is particularly=20 >> practical, or worrisome. > > I guess I should have been way more explicit that I was thinking about th= e remote attack. Then I am really not worried. This kind of attack is trivially mitigated by= any stateful firewall on the path. In addition to all other mitigations th= at were listed on this thread. -- Christian Huitema From swmike@swm.pp.se Tue Jul 12 22:29:03 2011 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 80AF321F8BD5 for ; Tue, 12 Jul 2011 22:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuZxhKlOniS8 for ; Tue, 12 Jul 2011 22:29:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C906E21F8BD4 for ; Tue, 12 Jul 2011 22:29:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6C16E261; Wed, 13 Jul 2011 07:28:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 67E33260; Wed, 13 Jul 2011 07:28:58 +0200 (CEST) Date: Wed, 13 Jul 2011 07:28:58 +0200 (CEST) From: Mikael Abrahamsson To: Fred Baker Subject: Re: /64 ND DoS In-Reply-To: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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, 13 Jul 2011 05:29:03 -0000 On Tue, 12 Jul 2011, Fred Baker wrote: > I suppose the same might be true of ARP. Has it been observed in the wild? Yes. At Interop they had this exact problem because they had huge subnets (/16 or something, I don't know exactly, they had a /8 so they could "afford" it), and they had to make them smaller. I've seen it at other places as well, in the IPv4 Internet it doesn't even need to be ddos, it only needs to be the "normal" scanning traffic that the botnets do. This is a REAL problem already, has been forever, and I imagine if I take most IPv6 router platforms today and give it 10kpps to random destinations to its attached /64 (10kpps of small packets is 5 megabit/s) it'll stop working normally. -- Mikael Abrahamsson email: swmike@swm.pp.se From fweimer@bfk.de Wed Jul 13 00:33:11 2011 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 0505821F8B27 for ; Wed, 13 Jul 2011 00:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFl5fKNKL4pu for ; Wed, 13 Jul 2011 00:33:06 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id BD0C821F8B04 for ; Wed, 13 Jul 2011 00:33:06 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QgtwM-0003So-8y; Wed, 13 Jul 2011 07:33:02 +0000 Received: by bfk.de with local id 1QgtwM-0005EW-4P; Wed, 13 Jul 2011 07:33:02 +0000 From: Florian Weimer To: Fred Baker Subject: Re: /64 ND DoS References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> Date: Wed, 13 Jul 2011 07:33:02 +0000 In-Reply-To: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> (Fred Baker's message of "Tue, 12 Jul 2011 16:39:19 -0400") Message-ID: <828vs2prdd.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 13 Jul 2011 07:33:11 -0000 * Fred Baker: > On Jul 12, 2011, at 4:48 AM, Philip Homburg wrote: > >> Occasionally the subject comes up: /64 (and SLAAC) is bad because it is >> easy to DoS routers by getting to perform too much ND. > > I suppose the same might be true of ARP. Has it been observed in the > wild? Yes, for the remote case. Sequential scanning used to trigger it. I suspect that router capacities for ARP processing have since increased. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Wed Jul 13 00:39:11 2011 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 D2AFE21F8B4A for ; Wed, 13 Jul 2011 00:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sSYPa1wZA5X for ; Wed, 13 Jul 2011 00:39:11 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2A821F8B26 for ; Wed, 13 Jul 2011 00:39:11 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qgu2G-0004D0-PZ; Wed, 13 Jul 2011 07:39:08 +0000 Received: by bfk.de with local id 1Qgu2G-0006fv-BM; Wed, 13 Jul 2011 07:39:08 +0000 From: Florian Weimer To: Ray Hunter Subject: Re: [ipv6] Re: /64 ND DoS References: <4E1CDD14.7020702@globis.net> Date: Wed, 13 Jul 2011 07:39:08 +0000 In-Reply-To: <4E1CDD14.7020702@globis.net> (Ray Hunter's message of "Wed, 13 Jul 2011 01:47:32 +0200") Message-ID: <82wrfmocir.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 13 Jul 2011 07:39:11 -0000 * Ray Hunter: > Are 2^24 interface identifiers small enough that every implementation > could simply provide enough resources (for ND) to cope with all > addresses being in play simultaneously? You'd need per-interface and per-VLAN tables. I don't think that's feasible. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pch-b2B3A6689@u-1.phicoh.com Wed Jul 13 01:00:22 2011 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 51C4E21F896E for ; Wed, 13 Jul 2011 01:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.508 X-Spam-Level: X-Spam-Status: No, score=-8.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgpcOJIxbp6k for ; Wed, 13 Jul 2011 01:00:21 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDB121F88E1 for ; Wed, 13 Jul 2011 01:00:21 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QguMl-0001gQC; Wed, 13 Jul 2011 10:00:19 +0200 Message-Id: To: Christian Huitema Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-reply-to: Your message of "Tue, 12 Jul 2011 23:56:38 +0000 ." <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 13 Jul 2011 10:00:06 +0200 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, 13 Jul 2011 08:00:22 -0000 In your letter dated Tue, 12 Jul 2011 23:56:38 +0000 you wrote: >Then I am really not worried. This kind of attack is trivially mitigated by= > any stateful firewall on the path. If a stateful firewall is mandatory for the operation of IPv6 then it should be there in the specs. Last time I looked, there was no standards track RFC that made stateful firewall mandatory. I could be wrong though. I'm not aware of any system today that in the presence of just SLAAC can figure out where the stateful firewall is hiding in the network and how to get it to open the port you need automatically (i.e. whenever a host allocate a passive socket). If you want to go that route, then IMHO, there is a huge amount of work to be done. Certainly to get it to work transparently for every possible protocol that runs on top of IPv6. Otherwise, it may be more productive to see a stateful firewall as an optional extra and fix the protocols to be safe even in the absence of such a device. From v6ops@globis.net Wed Jul 13 01:06:21 2011 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 8535421F8A97 for ; Wed, 13 Jul 2011 01:06:21 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S70W+U6RjtiS for ; Wed, 13 Jul 2011 01:06:21 -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 9BA3221F8A4F for ; Wed, 13 Jul 2011 01:06:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6FF2B8700F1; Wed, 13 Jul 2011 10:06:18 +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 4SqrlKI7NWDN; Wed, 13 Jul 2011 10:06:12 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id AA13287005C; Wed, 13 Jul 2011 10:06:12 +0200 (CEST) Message-ID: <4E1D51F4.7040103@globis.net> Date: Wed, 13 Jul 2011 10:06:12 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Florian Weimer Subject: Re: [ipv6] Re: /64 ND DoS References: <4E1CDD14.7020702@globis.net> <82wrfmocir.fsf@mid.bfk.de> In-Reply-To: <82wrfmocir.fsf@mid.bfk.de> Content-Type: multipart/alternative; boundary="------------040803000107020107090107" 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, 13 Jul 2011 08:06:21 -0000 This is a multi-part message in MIME format. --------------040803000107020107090107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Florian Weimer wrote: > * Ray Hunter: > > >> Are 2^24 interface identifiers small enough that every implementation >> could simply provide enough resources (for ND) to cope with all >> addresses being in play simultaneously? >> > > You'd need per-interface and per-VLAN tables. I don't think that's > feasible. > > So where's the limit for ND and prefix length on today's implementations and platforms? What if SLAAC was limited to using 20 bits or even just 16 bits of MAC BIA information or even in extremis dare I say 12 bits? That would mean taking one or even two steps closer to Appletalk's node ID auto configuration mechanism. [implying higher chance of collisions and that DAD would almost certainly have to be adjusted to allow generation of random node IDs, and then testing for uniqueness on interface status transition. ]. IMHO There's no reason why this (temporary) limit on the amount of MAC BIA information used for SLAAC couldn't change over time as the power of platforms increases, and that this limit could also be dynamically advertised via RA as a per prefix option. Or are you saying that a brute force solution (a la ARP) is simply a no go? regards, RayH --------------040803000107020107090107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Florian Weimer wrote: 
* Ray Hunter:

  
Are 2^24 interface identifiers small enough that every implementation
could simply provide enough resources (for ND) to cope with all
addresses being in play simultaneously?
    

You'd need per-interface and per-VLAN tables.  I don't think that's
feasible.
So where's the limit for ND and prefix length on today's implementations and platforms?

What if SLAAC was limited to using 20 bits or even just 16 bits of MAC BIA information or even in extremis dare I say 12 bits?

That would mean taking one or even two steps closer to Appletalk's node ID auto configuration mechanism. [implying higher chance of collisions and that DAD would almost certainly have to be adjusted to allow generation of random node IDs, and then testing for uniqueness on interface status transition. ].

IMHO There's no reason why this (temporary) limit on the amount of MAC BIA information used for SLAAC couldn't change over time as the power of platforms increases, and that this limit could also be dynamically advertised via RA as a per prefix option.

Or are you saying that a brute force solution (a la ARP) is simply a no go?

regards,
RayH
--------------040803000107020107090107-- From swmike@swm.pp.se Wed Jul 13 01:08:48 2011 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 DBFA521F8B0C for ; Wed, 13 Jul 2011 01:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npSvd3Ha7UMT for ; Wed, 13 Jul 2011 01:08:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0201E21F8B0B for ; Wed, 13 Jul 2011 01:08:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 53BE8241; Wed, 13 Jul 2011 10:08:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 516C5240; Wed, 13 Jul 2011 10:08:46 +0200 (CEST) Date: Wed, 13 Jul 2011 10:08:46 +0200 (CEST) From: Mikael Abrahamsson To: Christian Huitema Subject: RE: /64 ND DoS In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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, 13 Jul 2011 08:08:49 -0000 On Tue, 12 Jul 2011, Christian Huitema wrote: > Then I am really not worried. This kind of attack is trivially mitigated > by any stateful firewall on the path. In addition to all other > mitigations that were listed on this thread. Think as an ISP. We do not stateful firewall our customers, and we might be forced to have requipment in the customer /64, at least initially. This is a real problem, as this device will in some cases be a L3 switch with quite limited CPU and FIB table size. I definitely prefer to have only link-local between me and a CPE and just route the /56 to the CPE, so I do not ever have to keep any state regarding individual customer placed devices. We have already requested that our L3 switch vendors have ND starvation protection, but there is serious lack of documentation to point to. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Jul 13 01:11:32 2011 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 842F421F8B56 for ; Wed, 13 Jul 2011 01:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxfFng9o8XOc for ; Wed, 13 Jul 2011 01:11:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id F14C121F8B53 for ; Wed, 13 Jul 2011 01:11:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3B2501C1; Wed, 13 Jul 2011 10:11:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 390291C0; Wed, 13 Jul 2011 10:11:31 +0200 (CEST) Date: Wed, 13 Jul 2011 10:11:31 +0200 (CEST) From: Mikael Abrahamsson To: Ray Hunter Subject: Re: [ipv6] Re: /64 ND DoS In-Reply-To: <4E1D51F4.7040103@globis.net> Message-ID: References: <4E1CDD14.7020702@globis.net> <82wrfmocir.fsf@mid.bfk.de> <4E1D51F4.7040103@globis.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW 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: Wed, 13 Jul 2011 08:11:32 -0000 On Wed, 13 Jul 2011, Ray Hunter wrote: > So where's the limit for ND and prefix length on today's implementations > and platforms? Todays L3 switches typically have an ND/ARP table size limitations in the 1-4k entry range. > What if SLAAC was limited to using 20 bits or even just 16 bits of MAC > BIA information or even in extremis dare I say 12 bits? /120 would be more doable. When I think of ND table size per customer, I'm thinking limitation to 16-32 entries, after that the customer needs to get a router. -- Mikael Abrahamsson email: swmike@swm.pp.se From pch-b2B3A6689@u-1.phicoh.com Wed Jul 13 01:14:24 2011 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 747C121F8B65 for ; Wed, 13 Jul 2011 01:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.516 X-Spam-Level: X-Spam-Status: No, score=-8.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS1Jnddu44mB for ; Wed, 13 Jul 2011 01:14:23 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4D721F89BE for ; Wed, 13 Jul 2011 01:14:23 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QguaJ-0001hpC; Wed, 13 Jul 2011 10:14:19 +0200 Message-Id: To: Ray Hunter Subject: Re: [ipv6] Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Wed, 13 Jul 2011 01:47:32 +0200 ." <4E1CDD14.7020702@globis.net> Date: Wed, 13 Jul 2011 10:14:13 +0200 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, 13 Jul 2011 08:14:24 -0000 In your letter dated Wed, 13 Jul 2011 01:47:32 +0200 you wrote: >But EUI-48 itself has a not-very-well-published sub-structure of a >"manufacturer's IEEE-assigned company_id" and a "manufacturer-selected >extension identifier" > >What if SLAAC was (temporarily) redefined to build EUI-64 identifiers >with the manufacturer's IEEE-assigned company_id set to a single well >known value? i.e. EUI-64 was derived from the "manufacturer-selected >extension identifier" only. > >That would effectively mean there'd be 2^24 different possible interface >identifiers per prefix. With SLAAC you get an IPv6 address that is essentially guaranteed to be unique. There is absolutly no rule for allocating the lower 24 bits in an ehternet address. If every vendor would simply start counting at 1, you can expect a huge number of collisions. >2^24 is approx 17e6 table entries as a maximum, which may not be >excessive for most modern devices, even most embedded ones. Whereas 2^64 >has already been shown to be excessive via the ND vulnerability. There are plenty of embedded devices with a relatively small number of megabytes. There is plenty of hardware that would not support this. >Or can SLAAC and DAD be amended to 'guess and test' a new interface >identifier automatically on detection of a duplicate address [like >Appletalk node ID acquisition on Extended Networks]? > >Would 2^24 interface identifiers be large enough that RFC 4941 (privacy >extension) addresses are still reasonably useful? >[again bearing in mind the limited variation in the first 24 bits of >EUI-48 in practice] I think there is something to be said for this. Add some text that if a router advertises a prefix longer than /64 for SLAAC then the host will generate a series of random numbers, test each of them in sequence and start using one that is collision free. What may be needed is that the host will keep performing duplicate address detection periodically. On a typical home net that might make it possible to go /112. However, I much more prefer to solve the DoS problem for /64s than to just give up. From fweimer@bfk.de Wed Jul 13 01:15:34 2011 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 3D29121F8B72 for ; Wed, 13 Jul 2011 01:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMKjQqct09fp for ; Wed, 13 Jul 2011 01:15:33 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8500321F8B1E for ; Wed, 13 Jul 2011 01:15:33 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QgubT-0001LW-3V; Wed, 13 Jul 2011 08:15:31 +0000 Received: by bfk.de with local id 1QgubT-0000To-03; Wed, 13 Jul 2011 08:15:31 +0000 From: Florian Weimer To: Mikael Abrahamsson Subject: Re: /64 ND DoS References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 13 Jul 2011 08:15:30 +0000 In-Reply-To: (Mikael Abrahamsson's message of "Wed, 13 Jul 2011 10:08:46 +0200 (CEST)") Message-ID: <82liw2oau5.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Christian Huitema , "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, 13 Jul 2011 08:15:34 -0000 * Mikael Abrahamsson: > On Tue, 12 Jul 2011, Christian Huitema wrote: > >> Then I am really not worried. This kind of attack is trivially >> mitigated by any stateful firewall on the path. In addition to all >> other mitigations that were listed on this thread. > > Think as an ISP. We do not stateful firewall our customers, and we > might be forced to have requipment in the customer /64, at least > initially. Could you rephrase that? If you're in the IPv4 consumer market, I'm pretty sure you provide stateful filtering for customers. (The filter probably resides on the CPE.) It's possible to do things differently with IPv6, but customers will probably not like it. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pch-b2B3A6689@u-1.phicoh.com Wed Jul 13 01:17:49 2011 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 EFE9A21F8BDE for ; Wed, 13 Jul 2011 01:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.522 X-Spam-Level: X-Spam-Status: No, score=-8.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YDLQFFRiejf for ; Wed, 13 Jul 2011 01:17:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3A04921F8BCB for ; Wed, 13 Jul 2011 01:17:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qgudc-0001hpC; Wed, 13 Jul 2011 10:17:44 +0200 Message-Id: To: Arturo Servin Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: In-reply-to: Your message of "Tue, 12 Jul 2011 18:32:15 -0400 ." Date: Wed, 13 Jul 2011 10:17:43 +0200 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, 13 Jul 2011 08:17:50 -0000 In your letter dated Tue, 12 Jul 2011 18:32:15 -0400 you wrote: > > IMHO I think this would be a vector for other attacks in ND. > > You may solve a remote attack but you are opening the door to = >local attacks, and a big ones I think. Let's assume for a moment a 'normal' link (not one with 6000 hosts) and a protocol that spreads NS requests by the hosts over a period of say 20 seconds, how would you then use this as an attack vector? From swmike@swm.pp.se Wed Jul 13 01:57:06 2011 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 9A03221F861D for ; Wed, 13 Jul 2011 01:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnBdAnYF89lq for ; Wed, 13 Jul 2011 01:57:06 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D102521F8665 for ; Wed, 13 Jul 2011 01:57:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D20B41E1; Wed, 13 Jul 2011 10:57:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CD6BF1E0; Wed, 13 Jul 2011 10:57:01 +0200 (CEST) Date: Wed, 13 Jul 2011 10:57:01 +0200 (CEST) From: Mikael Abrahamsson To: Florian Weimer Subject: Re: /64 ND DoS In-Reply-To: <82liw2oau5.fsf@mid.bfk.de> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Christian Huitema , "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, 13 Jul 2011 08:57:06 -0000 On Wed, 13 Jul 2011, Florian Weimer wrote: >> Think as an ISP. We do not stateful firewall our customers, and we >> might be forced to have requipment in the customer /64, at least >> initially. > > Could you rephrase that? Our central (for some definition of central) equipment might have to be the default gw of the devices residing in the customer /64. To scale, I of course want to have a LL onmly between my central equipment and a CPE, and DHCPv6-PD it a /56 and don't have to care about how many devices the customer has in his/her home, but a lot of people say requiring a CPE to deploy IPv6 is a showstopper so that most likely will not happen initially. > If you're in the IPv4 consumer market, I'm pretty sure you provide > stateful filtering for customers. (The filter probably resides on the > CPE.) It's possible to do things differently with IPv6, but customers > will probably not like it. No, we do not provide stateful filtering. We a lot of the time don't even provide a CPE. Customer can connect their computer directly into the wall RJ45 and get an IPv4 address today. When looking at deploying IPv6 in this scenario, we'd like to put each customer in a separate /64 so we don't have to deal with a lot of the security issues seen when sharing L2 domain between several customers, but we'd still have to limit the amount of IPv6 addresses the customer can have "active" due to ND table size limitations (if our central equipment is the default gw on the customer LAN). This is even without any ddos discussion, this is just normal operations. -- Mikael Abrahamsson email: swmike@swm.pp.se From jeroen@unfix.org Wed Jul 13 02:03:13 2011 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 E2FCF21F858A for ; Wed, 13 Jul 2011 02:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLdEHd1ZNxKf for ; Wed, 13 Jul 2011 02:03:09 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id EF50621F8584 for ; Wed, 13 Jul 2011 02:03:07 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (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 289C7801B513; Wed, 13 Jul 2011 11:03:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1310547784; bh=Gpi0b19chbEOm3dtljmP3JJjes7mjmTu28Rs/net55Y=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VMVmiNZq5gIAkf6oK2NrxJLtgbo5hdcigczQ7TjBu4IvEnvnSQU8xQB81YPEt/FJy OuqrCfMT3LULiSAy6AncoajTXoUkGVii/JhQk192AFKMzvCkSjofawU0ANvFKtg4f6 ZL/5XbU5iY+P/dYDQjWJOjalOQsoJiXADKZwPDs0cbdthmySZsI+s5dUO+VOJdhc1z WBZuDzZ9C/LcJ2xr/Hy8S2cE0FYEb7W66kbIG6h/M8nozwFXQXgLvdsTdslq9Fw3Ki 5hpjKXfJsHfomK2kiUXCLosqVS1jZthgBefD2COMUvq9O4wCSrCrO7traEwIBsbIQ3 Ww4WZ6bs1/AdQ== Message-ID: <4E1D5F48.7020501@unfix.org> Date: Wed, 13 Jul 2011 11:03:04 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: How to deploy IPv6 to endusers (Was: /64 ND DoS) References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "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, 13 Jul 2011 09:03:14 -0000 On 2011-07-13 10:57 , Mikael Abrahamsson wrote: [..] > No, we do not provide stateful filtering. We a lot of the time don't > even provide a CPE. Customer can connect their computer directly into > the wall RJ45 and get an IPv4 address today. > > When looking at deploying IPv6 in this scenario, we'd like to put each > customer in a separate /64 so we don't have to deal with a lot of the > security issues seen when sharing L2 domain between several customers, > but we'd still have to limit the amount of IPv6 addresses the customer > can have "active" due to ND table size limitations (if our central > equipment is the default gw on the customer LAN). This is even without > any ddos discussion, this is just normal operations. Why not deploy it like a lot of folks have been deploying IPv6 for over a decade already: - a /64 link to the router/host of the user (::1 is you, ::2 is them) - a route, be it /64, /56 or /48 to ::2 aka the user That link can be a real Ethernet link or a tunnel. AVM Fritz!Box supports this and various other vendors also find this great. The "ND" issue now lies at the CPE device of the user, who will most likely not be able to handle 1GB/s anyway when somebody wants to DDoS them off the net... Greets, Jeroen (who saw 500mbit coming sourced from 6to4 on Monday... and indeed most home networks don't have 500mbit connectivity yet...) From swmike@swm.pp.se Wed Jul 13 02:18:14 2011 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 1C9F321F8B6D for ; Wed, 13 Jul 2011 02:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GWciE9lR0hv for ; Wed, 13 Jul 2011 02:18:13 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id EAB5621F8B78 for ; Wed, 13 Jul 2011 02:18:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0C774221; Wed, 13 Jul 2011 11:18:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0A1F2220; Wed, 13 Jul 2011 11:18:12 +0200 (CEST) Date: Wed, 13 Jul 2011 11:18:12 +0200 (CEST) From: Mikael Abrahamsson To: Jeroen Massar Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) In-Reply-To: <4E1D5F48.7020501@unfix.org> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Christian Huitema , "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, 13 Jul 2011 09:18:14 -0000 On Wed, 13 Jul 2011, Jeroen Massar wrote: > Why not deploy it like a lot of folks have been deploying IPv6 for over > a decade already: > > - a /64 link to the router/host of the user > (::1 is you, ::2 is them) > - a route, be it /64, /56 or /48 to ::2 aka the user > > That link can be a real Ethernet link or a tunnel. AVM Fritz!Box > supports this and various other vendors also find this great. What? If it's a /64, then we have the /64 ND DoS problem we've been discussing for a gazillion mail already. > The "ND" issue now lies at the CPE device of the user, who will most > likely not be able to handle 1GB/s anyway when somebody wants to DDoS > them off the net... No it doesn't, if I am ::1 then if someone sends 10kpps to random values of ::X:Y:Z:W on that subnet I have to ND all those. 10kpps is 5 megabit/s, anyone can do that. I doubt most routers will work properly when handling 10k ND state changes per second. -- Mikael Abrahamsson email: swmike@swm.pp.se From jeroen@unfix.org Wed Jul 13 02:22:55 2011 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 AE1E621F8AFD for ; Wed, 13 Jul 2011 02:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA1UlLWyT4mC for ; Wed, 13 Jul 2011 02:22:50 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 88AB221F8AF0 for ; Wed, 13 Jul 2011 02:22:40 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (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 B1B0B801B513; Wed, 13 Jul 2011 11:22:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1310548958; bh=TmegpKc090cZWVOAxssDVoviiChQdc/NkqYDzBxFebU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=s0WIUzE/F9zinfPVfBaoVLwmjaL4k83rgJs/ZJ/dJXMSBJ8TVM/bzotMOnjbei2i6 t2lF8V5AM0IZJUzIuUrd4+uAs5rlDPLGS/YbeoUI0B9b3Z0Wvd61I9Wrx4p81zW7MY +0qUPkDxEZNXwYubKn9IALr9qo8bUaHnINf/YFfJjNL2D6Tn9Iba+AcGk9h3oXWVhT 40xH4OViQH9moeknZOfw/U0Qthp/KKMU2gEvPKAU2MDAvyucyphOAyO1oyEdckGoJt 971eB3RH77WPm/E6zuw53H8sbCzX7r3gSjVUlVtqXYMoGSJTrc2Mk+16VZ0NHD5yFM 6OaypI+Wc72xg== Message-ID: <4E1D63DE.80605@unfix.org> Date: Wed, 13 Jul 2011 11:22:38 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "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, 13 Jul 2011 09:22:55 -0000 On 2011-07-13 11:18 , Mikael Abrahamsson wrote: > On Wed, 13 Jul 2011, Jeroen Massar wrote: > >> Why not deploy it like a lot of folks have been deploying IPv6 for over >> a decade already: >> >> - a /64 link to the router/host of the user >> (::1 is you, ::2 is them) >> - a route, be it /64, /56 or /48 to ::2 aka the user >> >> That link can be a real Ethernet link or a tunnel. AVM Fritz!Box >> supports this and various other vendors also find this great. > > What? If it's a /64, then we have the /64 ND DoS problem we've been > discussing for a gazillion mail already. It might look like a /64, but you only use ::1 and ::2 and those are effectively static and effectively it is a /127 without the anycast issue. Heck, some people pick a /120 for it or whatever they find nice. Configuration wise and counting wise /64 is just handy. And if one day you have multi-access on that link, well, no re-numbering, just enable it. >> The "ND" issue now lies at the CPE device of the user, who will most >> likely not be able to handle 1GB/s anyway when somebody wants to DDoS >> them off the net... > > No it doesn't, if I am ::1 then if someone sends 10kpps to random values > of ::X:Y:Z:W on that subnet I have to ND all those. There is no subnet, only ::2, the rest you can ignore. > 10kpps is 5 megabit/s, anyone can do that. I doubt most routers will work properly > when handling 10k ND state changes per second. Test it out today and complain to your vendor ;) Greets, Jeroen From swmike@swm.pp.se Wed Jul 13 03:10:11 2011 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 9C39F21F879F for ; Wed, 13 Jul 2011 03:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNm9wBSYqXDg for ; Wed, 13 Jul 2011 03:10:11 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E621F8793 for ; Wed, 13 Jul 2011 03:10:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8D4882E1; Wed, 13 Jul 2011 12:09:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 891AB2E0; Wed, 13 Jul 2011 12:09:28 +0200 (CEST) Date: Wed, 13 Jul 2011 12:09:28 +0200 (CEST) From: Mikael Abrahamsson To: Jeroen Massar Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) In-Reply-To: <4E1D63DE.80605@unfix.org> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> <4E1D63DE.80605@unfix.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Christian Huitema , "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, 13 Jul 2011 10:10:11 -0000 On Wed, 13 Jul 2011, Jeroen Massar wrote: > Heck, some people pick a /120 for it or whatever they find nice. > Configuration wise and counting wise /64 is just handy. And if one day > you have multi-access on that link, well, no re-numbering, just enable > it. That's why /125 is nice for renumbering, and no ND issue. >>> The "ND" issue now lies at the CPE device of the user, who will most >>> likely not be able to handle 1GB/s anyway when somebody wants to DDoS >>> them off the net... >> >> No it doesn't, if I am ::1 then if someone sends 10kpps to random values >> of ::X:Y:Z:W on that subnet I have to ND all those. > > There is no subnet, only ::2, the rest you can ignore. What should the router do when someone sends a packet to ::3 on that subnet? If it's a /64, then it's a subnet with 2^64 active addresses, I don't understand how you can call it a non-subnet. > Test it out today and complain to your vendor ;) Wow. -- Mikael Abrahamsson email: swmike@swm.pp.se From jeroen@unfix.org Wed Jul 13 04:00:03 2011 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 6329821F88B2 for ; Wed, 13 Jul 2011 04:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A4cJSMfNUKZ for ; Wed, 13 Jul 2011 03:59:58 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8421F87C7 for ; Wed, 13 Jul 2011 03:59:57 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (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 3D983801B513; Wed, 13 Jul 2011 12:59:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1310554794; bh=Hwlbiijwfmu4bbZrmmcC2dNl0a+PUjA9hR0U+HpKE98=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WtWlm7ZuFd7X6qoatM+wjY03LlbIQQVziWhsH+ZfAsuvHxyClMR+xQQ9fhkV32U2O sO8VjlkLMxW/yGpMMHvkK8GdmWSOPpVxETZf7xpT+FwFNpDC1UT+pzBlYte4CkxJz2 0aPFe5FRFN4cVCvhqXKexXuRAZh5hPB2FKuM6codoIMjxzwVsrh2K15iCzVg7v16fK MoBl7iAwlEPZjVngL4b3F7FCj+Z0etjy2LNULGW/cDWfyUAWtPAUNBPYegnEiUBIJ+ OB4+yeceJzhryKdFyxNOby5dcIfaLaY0iYb6FLUK6QN3aijdHDr+cZ2OuHpBD1tcJ4 j74oCFgeYrOcQ== Message-ID: <4E1D7AAA.200@unfix.org> Date: Wed, 13 Jul 2011 12:59:54 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> <4E1D63DE.80605@unfix.org> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "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, 13 Jul 2011 11:00:03 -0000 On 2011-07-13 12:09 , Mikael Abrahamsson wrote: > On Wed, 13 Jul 2011, Jeroen Massar wrote: > >> Heck, some people pick a /120 for it or whatever they find nice. >> Configuration wise and counting wise /64 is just handy. And if one day >> you have multi-access on that link, well, no re-numbering, just enable >> it. > > That's why /125 is nice for renumbering, and no ND issue. Yeah, pick whatever you like I would say. Just stay away from actually putting a /127 on the link. Two /128s works like a charm though as then subnet anycast is not involved anymore. >>>> The "ND" issue now lies at the CPE device of the user, who will most >>>> likely not be able to handle 1GB/s anyway when somebody wants to DDoS >>>> them off the net... >>> >>> No it doesn't, if I am ::1 then if someone sends 10kpps to random values >>> of ::X:Y:Z:W on that subnet I have to ND all those. >> >> There is no subnet, only ::2, the rest you can ignore. > > What should the router do when someone sends a packet to ::3 on that > subnet? If it's a /64, then it's a subnet with 2^64 active addresses, I > don't understand how you can call it a non-subnet. To take this little thing called SixXS as an example, we allocate a /64 per tunnel, but only use ::1 (PoP) and ::2 (user). We actually only configure ::1 on the tunnel and route ::2 to the tunnel, thus effectively two /128's. Thus for everything else there will be directly an ICMP unreachable. Simple as that. >> Test it out today and complain to your vendor ;) > > Wow. What else would you do? :) Greets, Jeroen From swmike@swm.pp.se Wed Jul 13 04:20:38 2011 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 0597B21F8893 for ; Wed, 13 Jul 2011 04:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lpfa1BpgwIZ for ; Wed, 13 Jul 2011 04:20:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D61321F887C for ; Wed, 13 Jul 2011 04:20:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CF6C7201; Wed, 13 Jul 2011 13:20:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CB7CA200; Wed, 13 Jul 2011 13:20:31 +0200 (CEST) Date: Wed, 13 Jul 2011 13:20:31 +0200 (CEST) From: Mikael Abrahamsson To: Jeroen Massar Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) In-Reply-To: <4E1D7AAA.200@unfix.org> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> <4E1D63DE.80605@unfix.org> <4E1D7AAA.200@unfix.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Christian Huitema , "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, 13 Jul 2011 11:20:40 -0000 On Wed, 13 Jul 2011, Jeroen Massar wrote: > To take this little thing called SixXS as an example, we allocate a /64 > per tunnel, but only use ::1 (PoP) and ::2 (user). > > We actually only configure ::1 on the tunnel and route ::2 to the > tunnel, thus effectively two /128's. Thus for everything else there will > be directly an ICMP unreachable. Simple as that. A tunnel is not a broadcast medium, it's a point to point device. You already statically tell it what the other end address is, right? Thus, this is not a problem on this type of tunnel. -- Mikael Abrahamsson email: swmike@swm.pp.se From jeroen@unfix.org Wed Jul 13 04:46:46 2011 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 8451E21F8A71 for ; Wed, 13 Jul 2011 04:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92+cpVluMOfp for ; Wed, 13 Jul 2011 04:46:41 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 84EF621F8A64 for ; Wed, 13 Jul 2011 04:46:40 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (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 D695B801B513; Wed, 13 Jul 2011 13:46:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1310557597; bh=XrmEzNFeAp8OqY3Yla9XgFzq/YmgYbMDByEl/Tvn/R0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=AAIH7H52nnPs6fMpQBn5q38xPV3Ufw74ZqdRmU08A0OQ1oYELLZfA4DXK34kDcOpV rKdOPR2WFC7f6wVX/X3YzkCZY/iDUg6ER1IQkuUvwvRgpSIZ0CyVvSwHaopfZR9LVn 3ZX2cC5R4CmLoFwEzTwN1GyiiJgsbbrfUHp25v5ikz2BHU7KW86uEO53RRZ2+j1ipA ZsKMA4T7+9cJ+1Vh+hHgMZ8hqwz5dvx9fhNLKO3LL9KBKaV9aB5YZXQDCpQX9EF0cF 76pxTjG5Qroz6UEZRhiNOhGkcky+ehVVfFi/u4mmr3hSCtqlbKyiFbBEHhbw7rGdXo mY/sg5FUqRVVw== Message-ID: <4E1D859D.9020207@unfix.org> Date: Wed, 13 Jul 2011 13:46:37 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> <4E1D63DE.80605@unfix.org> <4E1D7AAA.200@unfix.org> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "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, 13 Jul 2011 11:46:46 -0000 On 2011-07-13 13:20 , Mikael Abrahamsson wrote: > On Wed, 13 Jul 2011, Jeroen Massar wrote: > >> To take this little thing called SixXS as an example, we allocate a /64 >> per tunnel, but only use ::1 (PoP) and ::2 (user). >> >> We actually only configure ::1 on the tunnel and route ::2 to the >> tunnel, thus effectively two /128's. Thus for everything else there will >> be directly an ICMP unreachable. Simple as that. > > A tunnel is not a broadcast medium, it's a point to point device. You > already statically tell it what the other end address is, right? Thus, > this is not a problem on this type of tunnel. And you can do exactly the same on a Ethernet link... if there are only 2 addresses (router + user) then there is no need to do ND, well, you might need to discover the ::2 but that is it, the rest can be ignored. Greets, Jeroen From swmike@swm.pp.se Wed Jul 13 04:52:36 2011 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 1580921F8695 for ; Wed, 13 Jul 2011 04:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJWQTW38EemH for ; Wed, 13 Jul 2011 04:52:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 60A2121F855B for ; Wed, 13 Jul 2011 04:52:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 289641C1; Wed, 13 Jul 2011 13:52:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 256AC1C0; Wed, 13 Jul 2011 13:52:33 +0200 (CEST) Date: Wed, 13 Jul 2011 13:52:33 +0200 (CEST) From: Mikael Abrahamsson To: Jeroen Massar Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) In-Reply-To: <4E1D859D.9020207@unfix.org> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> <4E1D63DE.80605@unfix.org> <4E1D7AAA.200@unfix.org> <4E1D859D.9020207@unfix.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Christian Huitema , "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, 13 Jul 2011 11:52:36 -0000 On Wed, 13 Jul 2011, Jeroen Massar wrote: > And you can do exactly the same on a Ethernet link... if there are only > 2 addresses (router + user) then there is no need to do ND, well, you > might need to discover the ::2 but that is it, the rest can be ignored. Yes, true, you route ::2 to the ethernet interface, but then it's not really a /64, it's a /128 that you reach via ethernet. -- Mikael Abrahamsson email: swmike@swm.pp.se From jeroen@unfix.org Wed Jul 13 04:55:28 2011 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 5B51721F86A2 for ; Wed, 13 Jul 2011 04:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbK36iOs4fMP for ; Wed, 13 Jul 2011 04:55:23 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1CC21F86A3 for ; Wed, 13 Jul 2011 04:55:22 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (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 A583C801B513; Wed, 13 Jul 2011 13:55:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1310558120; bh=k6prs9wWhf9MVLexicJrdS+U0Ply+fVBdwXFn/W5wds=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IEsjRlKFy8wS5NUazW+GyrUIDqra17LOTBjvWsH59saEwgGfeeH/qAKbgeio3rSsH kv8sJBgvgAdI6tC9IMe5mjP0t/VPkcPORBVAurf4Ou/MKdrp01QCTOKhLvoOYMq0Hs p/wBrhi7yqeT18WxeB/ZIYHYshObI5LacITibB0AVJTGFyeQTmCGh98VzW93CBYoKH P9wRjZPWU3gBJ9DCRPFQoOaV/8M1J8KAxj2XL7jj7yeTzw1vIV4g1hrkvlFbKIrBu5 pg+6r/uQt6DIsOKh3uvoqHac7SamzLyhO89lrTVct2DPBHQTpEAMX5urw8MOSvMU/D 0b1qn1GQPvupA== Message-ID: <4E1D87A8.3040707@unfix.org> Date: Wed, 13 Jul 2011 13:55:20 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> <4E1D63DE.80605@unfix.org> <4E1D7AAA.200@unfix.org> <4E1D859D.9020207@unfix.org> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "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, 13 Jul 2011 11:55:28 -0000 On 2011-07-13 13:52 , Mikael Abrahamsson wrote: > On Wed, 13 Jul 2011, Jeroen Massar wrote: > >> And you can do exactly the same on a Ethernet link... if there are >> only 2 addresses (router + user) then there is no need to do ND, well, >> you might need to discover the ::2 but that is it, the rest can be >> ignored. > > Yes, true, you route ::2 to the ethernet interface, but then it's not > really a /64, it's a /128 that you reach via ethernet. And is that not what you want to achieve? It gives you the flexibility to limit the number of NDs being made, while also the option of making it multi-access, or one day upgrading it to one of those fancy proposed crypto-IP-address schemes ;) Greets, Jeroen From swmike@swm.pp.se Wed Jul 13 05:41:23 2011 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 22CD111E80D2 for ; Wed, 13 Jul 2011 05:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AXIBmQW+Rnd for ; Wed, 13 Jul 2011 05:41:22 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74A11E80CE for ; Wed, 13 Jul 2011 05:41:22 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 77B2B2E1; Wed, 13 Jul 2011 14:41:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 748072E0; Wed, 13 Jul 2011 14:41:21 +0200 (CEST) Date: Wed, 13 Jul 2011 14:41:21 +0200 (CEST) From: Mikael Abrahamsson To: Jeroen Massar Subject: Re: How to deploy IPv6 to endusers (Was: /64 ND DoS) In-Reply-To: <4E1D87A8.3040707@unfix.org> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <82liw2oau5.fsf@mid.bfk.de> <4E1D5F48.7020501@unfix.org> <4E1D63DE.80605@unfix.org> <4E1D7AAA.200@unfix.org> <4E1D859D.9020207@unfix.org> <4E1D87A8.3040707@unfix.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Christian Huitema , "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, 13 Jul 2011 12:41:23 -0000 On Wed, 13 Jul 2011, Jeroen Massar wrote: >> Yes, true, you route ::2 to the ethernet interface, but then it's not >> really a /64, it's a /128 that you reach via ethernet. > > And is that not what you want to achieve? Not in the deployment scenario I was talking about (where we act default-gw for customer which want to directly hook up SLAAC devices). For routed scenarios I prefer LL only between PE and CPE. -- Mikael Abrahamsson email: swmike@swm.pp.se From rathiguru@hotmail.com Wed Jul 13 05:43:24 2011 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 00FDE21F8834 for ; Wed, 13 Jul 2011 05:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA7yxmeJOJLb for ; Wed, 13 Jul 2011 05:43:23 -0700 (PDT) Received: from bay0-omc2-s11.bay0.hotmail.com (bay0-omc2-s11.bay0.hotmail.com [65.54.190.86]) by ietfa.amsl.com (Postfix) with ESMTP id B20BA21F8829 for ; Wed, 13 Jul 2011 05:43:23 -0700 (PDT) Received: from BAY146-W60 ([65.54.190.125]) by bay0-omc2-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 05:43:23 -0700 Message-ID: Content-Type: multipart/mixed; boundary="_b2d195fa-6892-4e99-91b3-36155d967fd3_" X-Originating-IP: [202.75.206.179] From: Thiruma valavan To: Subject: RE: Doubt in Router Advertisement Message Date: Wed, 13 Jul 2011 18:13:22 +0530 Importance: Normal In-Reply-To: <4e18d0c5.2727440a.7a71.2906@mx.google.com> References: , <4e18d0c5.2727440a.7a71.2906@mx.google.com> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2011 12:43:23.0556 (UTC) FILETIME=[73FA7E40:01CC415A] X-Mailman-Approved-At: Wed, 13 Jul 2011 05:58: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, 13 Jul 2011 12:43:24 -0000 --_b2d195fa-6892-4e99-91b3-36155d967fd3_ Content-Type: multipart/alternative; boundary="_8d3c6d41-e2c6-4d91-9882-6df81ab7af78_" --_8d3c6d41-e2c6-4d91-9882-6df81ab7af78_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Vishwas=2C I am having one more doubt in IPv6 Fragmentation=20 Router Interface MTU 1500=2C Host A wants to send a packet with 3=2C000 dat= a bytes but MTU is 1500=2C so it needs to fragment the packet. As per RFC 2460=2C First Packet 40 bytes (IPv6 Header) + 8 bytes Fragment H= eader + 1452 Data =3D 1500 =20 Second Packet 40 bytes (IPv6 Header) + 8 bytes Fragment Header= + 1452 Data =3D 1500 =20 Third Packet 40 bytes (IPv6 Header) + 8 bytes Fragme= nt Header + 96 Data =3D 1500=20 =20 Thanks=2C Thiru=20 Date: Sat=2C 9 Jul 2011 15:05:47 -0700 From: vishwas.ietf@gmail.com To: rathiguru@hotmail.com=3B ipv6@ietf.org Subject: Re: Doubt in Router Advertisement Message Hi Thiruma=2C >From the specs it is clear that the MTU is optional. However if MTU sending= is enabled it should be sent on change too. Sounds like a bug in the implementation to me. Thanks=2C Vishwas Sent from my Palm Pre on AT&T On Jul 9=2C 2011 2:51 AM=2C Thiruma valavan wrote:= =20 Hi IETF Group=2C While testing IPV6 Router Advertisement part=2C I noticed some behaviour th= at if I changed router interface MTU value=2C it won't send Router Advertis= ement message immediately instead of waiting to next interval time. Is that normal behaviour=2C=20 Thanks & Regards=2C Thirumavalavan PCalsoflabs India Pvt Ltd=2CBangaloreATLEN Group of CompanyM= ob: +91 9790758035=20 =20 = --_8d3c6d41-e2c6-4d91-9882-6df81ab7af78_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Vishwas=2C

I am having one more doubt in IPv6 Fragmentation =3B
<= div style=3D"font-size: 10pt=3B ">
R= outer Interface MTU 1500=2C Host A wants to send a packet with 3=2C000 data= bytes but MTU is 1500=2C so it needs to fragment the packet.
<= div style=3D"font-size: 10pt=3B ">
A= s per RFC 2460=2C First Packet 40 bytes (IPv6 Header) + 8 bytes Fragment He= ader + 1452 Data =3D 1500  =3B

 =3B  =3B  =3B  =3B =  =3B  =3B Second Packet =3B40 byt= es (IPv6 Header) + 8 bytes Fragment Header + 1452 Data =3D 1500  =3B

 = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3BThird Packet  =3B  =3B =3B40 bytes (IPv6 Header) + 8 bytes Fragment Header +  =3B  =3B96 Da= ta =3D  =3B1500 =3B
=
=  =3B




Thanks=2C
Thiru
 =3B


Date: Sat=2C 9 J= ul 2011 15:05:47 -0700
From: vishwas.ietf@gmail.com
To: rathiguru@hot= mail.com=3B ipv6@ietf.org
Subject: Re: Doubt in Router Advertisement Mes= sage

Hi Thiruma=2C

From the specs it is clear that the MTU is= optional. However if MTU sending is enabled it should be sent on change to= o.

Sounds like a bug in the implementation to me.

Thanks=2CVishwas

Sent from my Palm Pre on A= T&=3BT

On Jul 9= =2C 2011 2:51 AM=2C Thiruma valavan <=3Brathiguru@hotmail.com>=3B wrote= :

Hi IETF Group=2C

While testing IPV6 Router Advertisement part=2C I noticed some beha= viour that if I changed router interface MTU value=2C it won't send Router = Advertisement message immediately instead of waiting to next interval time.=
=
= Is that normal behaviour=2C =3B

Thanks &=3B Regards=2C
Thirumavalavan P
Calsoflabs India P= vt Ltd=2CBangalore
ATLEN Group of Co= mpany
Mob: +91 9790758035
=
= --_8d3c6d41-e2c6-4d91-9882-6df81ab7af78_-- --_b2d195fa-6892-4e99-91b3-36155d967fd3_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="frag.pcap" 1MOyoQIABAAAAAAAAAAAAAAgAAABAAAAxqsWThy/CwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMyrFk6cvAEAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADZqxZO3L0GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3KsWTrQ1AgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANyrFk40OAwAVgAAAFYA AAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkC CQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAeWrFk6sywUAagAAAGoAAAAzMwAAAAnCCRdQ AACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAg AAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB5asWTvSzBwA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AOyrFk60NQIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADyqxZOxEQGADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9qsWTsREBgCXAQAAlwEAAAEA DMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcw MCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUs IFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lz Y28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3Rl bXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYA DkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAAC CKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkA BAALAAUA+asWTswrAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP6rFk5sRwEAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqq AwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMz NzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRX QVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3Vw cG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBp bGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIA SQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAA AAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAAGsFk68UQsA agAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB AqwWTgSCAQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAasFk6U1QQAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKrBZOJKYIADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA F6wWTtTWCQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABysFk5UFQoAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH/ /oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAA AAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABHqwWTlSkBwBWAAAAVgAAADMzAAAACcIIF1AAAIbd bgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAA AAAAAAAAAAAAAAAAAEABHqwWTrxdCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACWsFk5sTQAAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmrBZO NDgMAHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAA AAAAAAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAA IAAAAAAAAAAAAAAAAAAAACesFk7ERAYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxrBZOBAUBAJcBAACXAQAAAQAMzMzM wgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNv ZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVM RUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5j b20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywg SW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lz Y28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoD AAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsA BQAzrBZOfCAOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAANqwWTuyLAAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADesFk6UUgUAagAAAGoAAAAz MwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABPqwWTrQ1AgA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEasFk7UAAMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMrBZOVBUKADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATqwWTkQGBgBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFP rBZOzCsDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAW6wWTszvDAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF2sFk6EAQwAVgAAAFYAAAAzMwAA AAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDF tAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAWOsFk5c/AYAPAAAADwAAADCCBdQAADCCBdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkrBZOBEYLADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAbqwWTtQSAABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAA AAAAAAAAAAAAAAAAQAFurBZOzK4CAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QA AQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRF UlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpU ZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJp Z2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAt QXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQA AAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAA AAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQBurBZOZGAEADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA eawWToRDAQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHmsFk4UFAUAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACFrBZOzGwNAJcBAACXAQAAAQAM zMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQCGrBZOhMYAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhqwWThSXBABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGMrBZOHPsBADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkKwWTqRn CAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAJmsFk5kZgMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACarBZOpOQIAFYAAABWAAAAMzMAAAAJwggX UAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAA IAAAAAAAAAAAAAAAAAAAAAAAQAGfrBZOhAcLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoqwWTswrAwBqAAAAagAAADMz AAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA NFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGmrBZOfNkEADwA AAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAp6wWThx+AQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIy AAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklT RUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5p Y2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAo YykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0w OCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAII qqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMA E0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAqKwWTlQVCgA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALWsFk6U Fg8APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAC8rBZONDgMADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw6wWTvwdBAA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMWsFk7E RAYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAA AEABx6wWTmxNAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAANCsFk6EBwsAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUrBZOHH4BADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2awWTrR2DABWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA /wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB36wWTmSnDQBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHg rBZONHQCADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA4qwWTpQWDwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAAC tB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURW RU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZj NCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNv cHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2Vk IDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEB zAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAA AAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA5awWTiyNBQA8AAAAPAAA AMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAOWsFk40OAwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADorBZOFJcEAHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAA AEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkX UAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAPKsFk58IA4APAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD7rBZOZOMDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/KwWTmTjAwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAH9rBZORAYGADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/awWTjQ4 DABNAAAATQAAAKsAAAIAAMIJF1AAAGACPQAHAAAAAQADAwAAAgACIQADAAYAAAAAAAAEAAI8AAUA AtgFBgACAAEHAAbCCRdQAABkAAF5kAEBAZEBAu4FBK0WThz7AQA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAatFk40tQwA lwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29m dHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAx Mi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRw Oi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBD aXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9y ZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAA AMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAA BAAIAAAAKQAJAAQACwAFAA2tFk5EBgYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQrRZOBEYLAFYAAABWAAAAMzMAAAAJ wggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEQrRZOBEYLADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEq0WTpy8AQBqAAAAagAA ADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEYrRZORAYG ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIq0WTmyOCgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEA BlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQ UklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVj aG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdo dCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFw ci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAA AAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAAC AAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAJa0WTvSzBwA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACWt Fk5UFQoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAArrRZOpOQIADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL60WTlz8BgBqAAAAagAAADMzAAAA CcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWK AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAE4rRZOJKYIADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAOa0WTrxdCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+tFk7kpAMAdgAAAHYAAAAzMwAAAAHCCBdQAACG3W4A AAAAQDr//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3zQAAHCAAAAAAAAAAAAQHC CBdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAARa0WTrxdCQA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAEytFk6EQwEAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAU2tFk5M 7QIAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABSrRZODC0IAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAA AAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAA QAEwAAAAAAAAAAAAAAAAAAAAAABAAVKtFk68XQkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYrRZOBEYLADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAWq0WTpQWDwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENp c2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0p LCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1 cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4 Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoy NyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAA ht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RF dGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAXa0WTjQ4DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGStFk4UlwQAPAAA ADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABlrRZORAAHAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX //5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAA AAAAAAAAAAAAAAAAAABAAWatFk58nQ4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxrRZOnLwBADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeq0W TmyOCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAH6tFk5M7QIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACFrRZOBAUBAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAYWtFk70swcAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACHrRZONDgMAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8 Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzkt TSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwg U3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAx OTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4 OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMA AACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFz dEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQCNrRZOhAcLAFYAAABWAAAAMzMAAAAJwggXUAAA ht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAGOrRZOnP0LADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkq0WTlQVCgA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJit Fk7MbA0AlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJ T1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVy c2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0 OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAw OCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkg cHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+ gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJu ZXQwLzAABAAIAAAAKQAJAAQACwAFAJmtFk6cvAEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACZrRZOvF0JAGoAAABqAAAA MzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkC CQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAaWtFk6U1QQA PAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACorRZOtHYMADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsq0WTqxOBQA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALWtFk7cvQYA dgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAA AAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAA AAAAAAAAAAAAAAAAva0WTgwtCABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAA AMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB MAAAAAAAAAAAAAAAAAAAAAAAQAG9rRZOhAcLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvq0WTnxcBAA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AMmtFk6EBwsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADKrRZOfFwEAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR //6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAHMrRZO1BIAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0q0WTtQSAABqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHSrRZOzCsDADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1K0W TgQFAQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElP UyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJz aW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6 IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4 IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBw cm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6A AAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5l dDAvMAAEAAgAAAApAAkABAALAAUA1K0WTgRGCwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOGtFk6EhAsAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADorRZO7MwKADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA7q0WTrR2DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPOtFk78Xg4AagAAAGoAAAAz MwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB9q0WTjwfCQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACuFk58nQ4APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADrhZObAsLADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADK4WTjR0AgBW AAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABDa4WTkztAgCXAQAAlwEAAAEADMzM zMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBT b2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJF TEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28u Y29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMs IEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNp c2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqq AwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAAL AAUADa4WThSRBQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2uFk4cvwsAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAA NBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAA AAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABDq4WTpz9CwCXAQAAlwEAAAEADMzMzMIJF1AA AAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2Fy ZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0Ug U09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3Rl Y2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4K Q29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3 MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbd ABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAEa4W TrQ1AgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABeuFk5EBgYAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAerhZOzCsDADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKa4W TsxsDQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAA AAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAA AAAAQAEqrhZOBAUBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALq4WTvQ2BwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC6uFk6c/QsAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA7rhZOnP0LADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARa4WTszvDABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFGrhZOTO0CADwAAAA8AAAAwggXUAAAwggX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASK4WTpz9 CwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAFKuFk70NgcAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA AVKuFk48HwkAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNj byBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwg VmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBw b3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYt MjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6Mjcg YnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbd ABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRo ZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAFKuFk6EhAsAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABXrhZOTC4NADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAXa4WTsREBgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGCuFk4cvwsAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4A AAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAA AAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABYa4WTgQFAQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG2uFk5c fwYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAB2rhZO1BIAADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeq4WTozuBwA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH6uFk4s jQUAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAg AAAAAAAAAAAAAAAAAAAAfq4WTnR1BwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAF+rhZOnP0LADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiK4WTuzMCgCXAQAAlwEA AAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwg MzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUp VDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cu Y2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5 c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFt AAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5Q AAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAAp AAkABAALAAUAiK4WTvxeDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIuuFk4cfgEAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPrhZOtHYMAFYA AABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAA AAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAGVrhZOJKYIADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlq4W TtTWCQCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElP UyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJz aW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6 IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4 IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBw cm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6A AAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5l dDAvMAAEAAgAAAApAAkABAALAAUAm64WTsREBgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0 Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAA AAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGfrhZOnP0LADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoq4WTjwfCQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAK+uFk7sTwoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC3rhZOhEMBADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvK4WTuzMCgA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAL+uFk5EBgYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADA CRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAA AAAAAAAAAAAAAAAAAAAAAEABxa4WToSECwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMuuFk7k5Q0APAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ rhZO7IsAAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28g SU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZl cnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9y dDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIw MDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5 IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ /oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVy bmV0MC8wAAQACAAAACkACQAEAAsABQDRrhZOHL8LAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAA ACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAA AAAAAAAAAAAAQAHSrhZONLUMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2K4WTswrAwBqAAAAagAAADMzAAAACcIJF1AA AIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAA AAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHZrhZOnLwBADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 4q4WTsxsDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAOOuFk7ctwcAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADtrhZOvF0JADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 864WTjR0AgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAH5rhZOHH4BADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+q4WTpTVBAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACvFk7k5Q0AdgAA AHYAAAAzMwAAAAHCCBdQAACG3W4AAAAAQDr//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAA AAGGAE3zQAAHCAAAAAAAAAAAAQHCCBdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAA AAAAAAAAAAAABq8WTjR0AgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2vFk5sTQAAVgAAAFYAAAAzMwAAAAnCCBdQAACG 3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAA AAAAAAAAAAAAAAAAAABAAQ2vFk58XAQAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQf tAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVO VEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQp ClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5 cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAz MC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwA BAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAA AAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAA2vFk5cfwYAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAANrxZOtHYMADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAD68WTmyOCgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0 Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAA AAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEWrxZOzO8MADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGa8WTsREBgCX AQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0 d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEy LjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6 Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENp c2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3Jl bF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAA wAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAE AAgAAAApAAkABAALAAUAIq8WTty9BgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACOvFk7MbA0APAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwrxZO FNgOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAANa8WThx+AQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAE2rxZOVBUKADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPK8WTsyuAgA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEGvFk78HQQAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAA AP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAUmvFk78HQQA PAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABLrxZOBEYLADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU68WTqTkCACXAQAAlwEAAAEADMzMzMIJF1AA AAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2Fy ZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0Ug U09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3Rl Y2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4K Q29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3 MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbd ABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAVq8W TkQGBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAFqvFk7cvQYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAA AAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAA AABAATAAAAAAAAAAAAAAAAAAAAAAAEABWq8WTgwtCAB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAA AABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJ F1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAABbrxZONHQCADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAX68WTjycCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGivFk5k4wMAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzrxZOHH4BADwAAAA8 AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAdK8WTtQSAABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAA AAAAAAAAAAAAAAAAQAF1rxZOfFwEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAea8WToRDAQBWAAAAVgAAADMzAAAACcII F1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABgq8WTlx/BgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIqvFk68XQkAPAAAADwAAADC CBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACPrxZOjO4HADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAkK8WTnydDgBNAAAATQAAAKsAAAIAAMIJF1AAAGACPQAHAAAA AQADAwAAAgACIQADAAYAAAAAAAAEAAI8AAUAAtgFBgACAAEHAAbCCRdQAABkAAF5kAEBAZEBAu4F l68WTtzDBQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAGXrxZONDgMAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEA BQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNF SzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmlj YWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChj KSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4 IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiq qgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwAT RmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQCZrxZOtHYMAJcBAACXAQAAAQAMzMzMwgkX UAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3 YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFT RSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20v dGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5j LgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28g MzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAA ht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQCa rxZObE0AADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAoa8WTrQ1AgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKKvFk40OAwAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACu rxZOzCsDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAsq8WTjwfCQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+ gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAA AAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAG2rxZOHH4BADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuK8WTqRnCAA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALmvFk6EhAsAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAcCvFk60 NQIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADLrxZOFNgOADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAza8WTqxOBQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM6vFk7E RAYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAA AEAB168WTjwfCQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENp c2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0p LCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1 cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4 Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoy NyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAA ht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RF dGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA168WTnwgDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN6vFk6cvAEAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADirxZONLUMADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6a8WTmRgBABqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHprxZOXPwGADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8a8W ToTGAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAPSvFk7siwAATQAAAE0AAACrAAACAADCCBdQAABgAj0ABwAAAAEAAwMA AAIAAiEAAwAGAAAAAAAABAACPAAFAALYBQYAAgABBwAGwggXUAAAZAABeZABAQGRAQLuBfWvFk7U 1gkAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAfevFk4UCAcAPAAAADwAAADC CBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD7rxZOLI0FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABbAWTgwtCABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0 Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAA AAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEFsBZOfJ0OADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACLAWTnydDgA8 AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA6wFk70NgcAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZS MgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJ U0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2hu aWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQg KGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHIt MDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAAC CKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgAD ABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFABGwFk58XAQAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUsBZO 3L0GAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9T IFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNp b24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDog aHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDgg YnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHBy b2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAA AAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0 MC8wAAQACAAAACkACQAEAAsABQAdsBZOvF0JADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHrAWThSXBAA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACSwFk4sjQUAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAA AAAAAAAAAEABJ7AWThSXBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACywFk5EBgYAdgAAAHYAAAAzMwAAAAHCCRdQAACG 3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAA AQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAAMbAWTtTWCQBW AAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABNLAWTswrAwA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADSw Fk4sjQUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABBsBZOrE4FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAR7AWTmRmAwBqAAAAagAAADMzAAAA CcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWK AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFMsBZOnP0LADwAAAA8 AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAATbAWTsxsDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFiwFk7kIQQAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqq AwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMz NzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRX QVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3Vw cG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBp bGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIA SQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAA AAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAFuwFk40dAIA PAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABisBZOhEMBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaLAWTjR0AgA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGiwFk7ERAYA agAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB aLAWTrR2DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAG+wFk5kZgMAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH/ /oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAA AAAAAABAAXOwFk5UFQoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2sBZONDgMADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgLAWTgRGCwA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAISwFk4sjQUAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAA AAAAAAAAAAAAAAAAAEABh7AWTqzLBQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIuwFk7k5Q0APAAAADwAAADCCBdQAADC CBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPsBZO ZGYDAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9T IFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNp b24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDog aHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDgg YnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHBy b2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAA AAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0 MC8wAAQACAAAACkACQAEAAsABQCSsBZOBAUBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlrAWTnxcBACXAQAAlwEAAAEA DMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcw MCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUs IFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lz Y28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3Rl bXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYA DkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAAC CKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkA BAALAAUAm7AWTkwuDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJywFk6UFg8AagAAAGoAAAAzMwAAAAnCCRdQAACG3W4A AAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAA AAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABn7AWThQUBQA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKawFk7k 5Q0AdgAAAHYAAAAzMwAAAAHCCBdQAACG3W4AAAAAQDr//oAAAAAAAADACBf//lAAAP8CAAAAAAAA AAAAAAAAAAGGAE3zQAAHCAAAAAAAAAAAAQHCCBdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAg AAAAAAAAAAAAAAAAAAAAqLAWThTYDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKuwFk7k5Q0AVgAAAFYAAAAzMwAAAAnC CBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIB AAAgAAAAAAAAAAAAAAAAAAAAAABAAbOwFk6EQwEAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2sBZOhMYAADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAvrAWTnwgDgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA /wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAA AAAAAAAAAAAAQAHAsBZO3L0GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAybAWTtTWCQA8AAAAPAAAAMIIF1AAAMIIF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM2wFk6kZwgA PAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADXsBZOhIQLAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAG UjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBS SVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNo bmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0 IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXBy LTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAA AgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIA AwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQDXsBZO5OUNADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3rAW Thx+AQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAN6wFk5cfwYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAA AAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAA AABAATAAAAAAAAAAAAAAAAAAAAAAAEAB4bAWTkQGBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOuwFk7MKwMAVgAAAFYA AAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkC CQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAeywFk40OAwAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADzsBZOZOMD ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA+bAWTjQ4DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPqwFk5M7QIAagAAAGoAAAAzMwAAAAnCCRdQ AACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAg AAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB/7AWTgRGCwA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAWxFk48HwkAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6 gAAAAAAgAAAAAAAAAAAAAAAAAAAACbEWTjR0AgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmxFk5c/AYAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAATsRZOVBUKAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lz Y28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSks IFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3Vw cG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2 LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3 IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG 3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0 aGVybmV0MC8wAAQACAAAACkACQAEAAsABQAUsRZOpGcIAJcBAACXAQAAAQAMzMzMwggXUAAAAYmq qgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChD MzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZU V0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1 cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21w aWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQAC AEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAA AAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQAWsRZOJKYI ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGLEWTmxNAABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAA AMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB MAAAAAAAAAAAAAAAAAAAAAAAQAEesRZOhMYAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHrEWTuxPCgA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACKxFk7k5Q0AVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAASuxFk60NQIAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA3sRZONHQCADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLEWTpy8AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADuxFk40tQwAagAA AGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABPrEW TuzMCgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEWxFk40dAIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLsRZONLUMADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT7EW TsREBgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElP UyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJz aW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6 IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4 IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBw cm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6A AAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5l dDAvMAAEAAgAAAApAAkABAALAAUAUrEWTrSsAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFSxFk6UFg8AagAAAGoAAAAz MwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABX7EWTnxcBAA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAF+xFk48HwkAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgsRZObI4KAFYAAABWAAAAMzMAAAAJwggXUAAA ht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAFjsRZOzCsDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbrEWTpQWDwA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHCx Fk4cvwsAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAA AAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAA AAAAAEABdrEWTqTkCAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHexFk60NQIAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEsRZOzK4CADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAjLEWTqRnCAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI6xFk5EBgYAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqq AwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMz NzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRX QVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3Vw cG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBp bGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIA SQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAA AAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAI+xFk40tQwA agAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB kLEWTtQSAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAJaxFk4EBQEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACWsRZOBEYLAJcBAACXAQAAAQAM zMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQChsRZOhMYAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAobEWTvwdBAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKKxFk60NQIAVgAAAFYA AAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkC CQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAaaxFk50dQcAagAAAGoAAAAzMwAAAAnCCRdQ AACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAg AAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABqbEWTvwdBAA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ALKxFk7k5Q0APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAC2sRZOrE4FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvbEWThTYDgBNAAAATQAAAKsA AAIAAMIJF1AAAGACPQAHAAAAAQADAwAAAgACIQADAAYAAAAAAAAEAAI8AAUAAtgFBgACAAEHAAbC CRdQAABkAAF5kAEBAZEBAu4Fw7EWTsREBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMixFk7siwAAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADI sRZO3L0GAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAcmxFk60dgwAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAF APxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VL OS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNh bCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMp IDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDgg MTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqq AwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNG YXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAMmxFk78Xg4APAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMsRZOzK4C AHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAA AAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAA AAAAAAAAAAAAAAAAANKxFk58IA4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYsRZOxEQGAFYAAABWAAAAMzMAAAAJwggX UAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAA IAAAAAAAAAAAAAAAAAAAAAAAQAHdsRZOLI0FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3bEWTkQGBgA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AN2xFk48nAkAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAA AAAAAAAAAEAB5rEWTjS1DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPOxFk48HwkAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADzsRZOzO8MADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAALIWTvSzBwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAA AAAAAAAAAAAAAAAAAAAAQAEAshZOfCAOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB7IWTjR0AgA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuy Fk4c+wEAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJ T1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVy c2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0 OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAw OCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkg cHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+ gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJu ZXQwLzAABAAIAAAAKQAJAAQACwAFAA2yFk78Xg4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARshZODC0IAJcBAACXAQAA AQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAz NzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlU NSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5j aXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lz dGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0A BgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAA AAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkA CQAEAAsABQAUshZOHPsBAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX //5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEbshZO 1BIAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAG7IWTlQVCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACKyFk7k5Q0AagAAAGoAAAAzMwAAAAnC CRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIB AAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABJbIWTqzLBQA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAADKyFk5M7QIAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyshZOxEQGADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPbIWTszvDAA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAESyFk4EBQEAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAA AP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAA AAAAAAAAAAAAAEABRrIWTty9BgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEqyFk78Xg4APAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQshZOhAcL AHYAAAB2AAAAMzMAAAABwggXUAAAht1uAAAAAEA6//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAA AAAAAAABhgBN80AABwgAAAAAAAAAAAEBwggXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAA AAAAAAAAAAAAAAAAAFCyFk4U2A4AlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAAB AAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVS UFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRl Y2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmln aHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1B cHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAA AAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAA AgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAFKyFk5sTQAAVgAAAFYAAAAzMwAA AAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDF tAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAVOyFk7MKwMAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABdshZODC0IADwAAAA8 AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAYLIWThSXBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGOyFk7UEgAAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4A AAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAA AAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABZ7IWTjwfCQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHOyFk6M 7gcAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAB0shZOvF0JADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgLIWTsyuAgBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGAshZOxEQGADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAhbIWTmyOCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIayFk7siwAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMshZOhEMBAFYAAABWAAAA MzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkC CQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAGQshZOhEMBAJcBAACXAQAAAQAMzMzMwggXUAAA AYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJl IChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBT T0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVj aHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpD b21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcy NQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0A ECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQCQshZO /B0EAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9T IFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNp b24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDog aHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDgg YnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHBy b2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAA AAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0 MC8wAAQACAAAACkACQAEAAsABQCTshZOhEMBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmrIWThQUBQBqAAAAagAAADMz AAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA NFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGbshZOpOQIADwA AAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAnLIWTsyuAgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKSyFk4cvwsAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACrshZOBEYLAHYA AAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAA AAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAA AAAAAAAAAAAAALGyFk4cvwsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0shZOXPwGADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtrIWTgwtCABq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAG+ shZONDgMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAy7IWTvQ2BwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMuyFk5kpw0APAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADN shZOzO8MAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAHTshZOZKcNAJcBAACX AQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJl LCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgx NSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3 dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28g U3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3Rl YW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf/ /lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAA ACkACQAEAAsABQDWshZOBEYLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA27IWTrQ1AgBqAAAAagAAADMzAAAACcIJF1AA AIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAA AAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHeshZOBEYLADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 37IWTgRGCwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAOyyFk60dgwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD0shZOfJ0OADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA +LIWTpQWDwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAH5shZOtDUCADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/7IWTuyLAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASzFk4MLQgAVgAA AFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAQmzFk6cvAEAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKsxZO 5KQDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAErMWTswrAwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAETsxZOFBQFAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMA AAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcy NS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FS RSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBv cnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxl ZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkA AAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAA AAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQAVsxZONDgMAJcB AACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQAWsxZOzCsDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH7MWTuTlDQA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACOzFk5k ZgMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAwsxZOlNUEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANbMWTtQSAABqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAE3sxZOhAcLADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAOLMWTkwuDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAD6zFk58nQ4AVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAA IBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAA AAAAAAAAAABAAUWzFk7szAoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMsxZO5KQDADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUrMWTjQ4DAA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFOzFk58XAQAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADA CRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAA AAAAAAAAAAAAAAAAAAAAAEABWLMWTvSzBwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAAC tB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURW RU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZj NCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNv cHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2Vk IDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEB zAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAA AAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAWLMWTmyOCgA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAF+zFk7MrgIAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhsxZOzK4CADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAarMWTqxOBQBqAAAAagAA ADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFssxZO5OUN ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAdrMWTuxPCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHqzFk7siwAAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB+sxZOtDUC AFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAA AAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAF+sxZOFNgOADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA g7MWTjQ4DABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAGEsxZOHL8LAHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX //5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDA ACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAIqzFk7MKwMAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNsxZOxEQGADwA AAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAlLMWTvQ2BwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIy AAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklT RUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5p Y2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAo YykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0w OCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAII qqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMA E0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAl7MWThSXBAA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJqzFk7k pAMAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAKSzFk4UFAUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACksxZONK8NADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA pbMWTkztAgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAGxsxZOXH8GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAurMWThz7AQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyzFk6kZwgAVgAA AFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAb2zFk6M7gcAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADCsxZO fFwEAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAA AABAAcWzFk7cvQYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADNsxZODC0IADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0rMWTvQ2BwA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAANyzFk7U1gkAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxD aXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1N KSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBT dXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5 ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6 MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAA AIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0 RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAN+zFk6M7gcAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADisxZOpGcIADwA AAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA5bMWToTGAABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAA AAAAAAAAAAAAAAAAAAAAQAHlsxZOjO4HADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7bMWTrQ1AgBNAAAATQAAAKsAAAIA AMIJF1AAAGACPQAHAAAAAQADAwAAAgACIQADAAYAAAAAAAAEAAI8AAUAAtgFBgACAAEHAAbCCRdQ AABkAAF5kAEBAZEBAu4F7bMWTrR2DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPKzFk6EQwEAVgAAAFYAAAAzMwAAAAnC CBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIB AAAgAAAAAAAAAAAAAAAAAAAAAABAAfezFk7cvQYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAA NBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAA AAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB97MWToSECwA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPizFk40tQwA PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAACtBZOhEMBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7QWThSXBAB2AAAAdgAAADMzAAAAAcIIF1AA AIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfNAAAcIAAAAAAAA AAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAAANtBZOlNUE ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAELQWTrxdCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABS0Fk58XAQAagAAAGoAAAAzMwAAAAnCCRdQ AACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAg AAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABFLQWTrxdCQCXAQAAlwEAAAEA DMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcw MCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUs IFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lz Y28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3Rl bXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYA DkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAAC CKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkA BAALAAUAFLQWTpz9CwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABm0Fk70NgcAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqq AwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMz NzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRX QVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3Vw cG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBp bGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIA SQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAA AAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAB60Fk58nQ4A PAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAitBZOFNgOADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALLQWTmxNAAA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC20Fk6sywUA agAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB LrQWTqRnCABWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABNLQWTjR0AgA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAADe0Fk6c/QsAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+tBZOhAcLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS7QWTqTkCABqAAAA agAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFLtBZO 1NYJADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAATLQWTjycCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE+0Fk4sjQUAlwEAAJcBAAABAAzMzMzC CRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29m dHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxF QVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNv bS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJ bmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNj byAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMA AACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAF AFK0Fk5k4wMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABatBZOvF0JAHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6 //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAA BQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAFq0Fk5kpw0APAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABhtBZOZGYDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAYrQWTty9BgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0 Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAA AAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFltBZOZOMDADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZbQWTkwuDQBW AAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABbrQWTpTVBABNAAAATQAAAKsAAAIA AMIIF1AAAGACPQAHAAAAAQADAwAAAgACIQADAAYAAAAAAAAEAAI8AAUAAtgFBgACAAEHAAbCCBdQ AABkAAF5kAEBAZEBAu4FcrQWTnxcBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHW0Fk4c+wEAPAAAADwAAADCCBdQAADC CBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB/tBZO rE4FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAh7QWTuTlDQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAGLtBZOXPwGADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjLQWTpy8AQA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJa0Fk4sjQUAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxD aXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1N KSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBT dXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5 ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6 MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAA AIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0 RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAJm0Fk7MrgIAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACZtBZOzK4CAJcB AACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQCktBZOHPsBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApbQWTgwtCABWAAAAVgAAADMzAAAACcII F1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABpbQWTtTWCQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKa0Fk7U1gkAagAAAGoAAAAz MwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABrLQWTmTjAwA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAALe0Fk4sjQUAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5tBZO/B0EADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwLQWTqxOBQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAMW0Fk5M7QIAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADA CRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAA AAAAAAAAAAAAAAAAAAAAAEABzLQWToSECwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM20Fk7ERAYAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADR tBZOHH4BAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28g SU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZl cnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9y dDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIw MDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5 IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ /oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVy bmV0MC8wAAQACAAAACkACQAEAAsABQDTtBZO/F4OADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2bQWTpTVBABWAAAAVgAA ADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB4LQWThz7AQBqAAAAagAAADMzAAAACcIJF1AA AIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAA AAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHgtBZONDgMADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 4bQWTkztAgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAOm0Fk78Xg4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD1tBZOpOQIADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 9rQWTpQWDwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP+0Fk68XQkAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH/ /oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAA AAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABALUWTtQSAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW1Fk6UFg8APAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAItRZOFNgOADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAELUWThx+AQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJ qqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAo QzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09G VFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hz dXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29t cGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUA AgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAg AAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAELUWTjS1 DABWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABErUWTpQWDwA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABW1Fk4U3g0AagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAA AAAAAAAAAEABFrUWTuSkAwCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIx AAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklT RUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5p Y2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAo YykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0w OCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAII qqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMA E0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAGbUWTlz8BgA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB61Fk60 dgwAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAjtRZOXH8GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALLUWTsREBgB2AAAAdgAAADMzAAAAAcIJ F1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAA AAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAAAttRZO BEYLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAALbUWTkwuDQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAE0tRZOZKcNADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAObUWTsREBgA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEa1Fk5cfwYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLtRZOdHUHADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAULUWTrxdCQCXAQAAlwEA AAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwg MzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUp VDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cu Y2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5 c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFt AAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5Q AAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAAp AAkABAALAAUAULUWTvxeDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFG1Fk7UEgAAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABUrUWTuzMCgBWAAAAVgAAADMzAAAA CcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0 AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABVbUWThSXBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGK1Fk7ERAYAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABjtRZOFNgOADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa7UWThTYDgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFutRZOtHYMADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAebUWTkzt AgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHu1Fk7k5Q0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACItRZOfJ0OADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjbUWThTY DgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABj7UWTlz8BgA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AJC1Fk50dQcAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAA AAAAAAAAAEABkLUWTgwtCACXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIy AAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklT RUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5p Y2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAo YykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0w OCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAII qqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMA E0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAkLUWTgTDCwA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJi1Fk6c vAEAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAJy1Fk5kpw0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChtRZOFJcEADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA qbUWTnwgDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAKu1Fk7M7wwAdgAAAHYAAAAzMwAAAAHCCBdQAACG3W4AAAAAQDr/ /oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3zQAAHCAAAAAAAAAAAAQHCCBdQAAAF AQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAAsbUWTjR0AgBqAAAAagAAADMz AAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA NFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAG1tRZOPB8JADwA AAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAt7UWTmxNAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMC1Fk4EBQEAVgAAAFYAAAAzMwAAAAnCCBdQAACG 3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAA AAAAAAAAAAAAAAAAAABAAcS1Fk7siwAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADKtRZOtHYMADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0bUW TgQFAQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAANe1Fk7MbA0AagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAA AAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAA AABAATAAAAAAAAAAAAAAAAAAAAAAAEAB2LUWTuSkAwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoD AAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3 MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdB UkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBw b3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGls ZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJ AAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAA AAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA2LUWTpTVBAA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAN61Fk6M7gcAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADhtRZOpOQIADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7rUWTjwfCQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAPS1Fk5UFQoAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADA CRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAA AAAAAAAAAAAAAAAAAAAAAEAB9LUWTlQVCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPW1Fk4cfgEAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD6 tRZOfCAOAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAH/tRZODC0IADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACbYWTrQ1AgB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAn jQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAAAJthZOfCAOADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADLYWTqTkCAA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA62Fk4UFAUAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAA AAAAAAAAAAAAAAAAAEABE7YWTkQGBgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0 AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5U RVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkK VGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHly aWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMw LUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAE AAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAA AAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAFbYWTmyOCgCXAQAAlwEAAAEA DMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcw MCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUs IFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lz Y28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3Rl bXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYA DkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAAC CKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkA BAALAAUAFrYWTmTjAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABi2Fk7MbA0ATQAAAE0AAACrAAACAADCCRdQAABgAj0A BwAAAAEAAwMAAAIAAiEAAwAGAAAAAAAABAACPAAFAALYBQYAAgABBwAGwgkXUAAAZAABeZABAQGR AQLuBR+2Fk4EBQEAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfthZO9LMHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ7YWTuzMCgBqAAAAagAA ADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEothZOFNgO ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAANLYWTjycCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADa2Fk7siwAAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3thZO9DYH AFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAA AAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAE6thZONLUMADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA RLYWTnydDgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAFHthZOFBQFADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASrYWTvQ2BwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE22Fk7MKwMAlwEA AJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdh cmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40 KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8v d3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNj byBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxf dGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJ F//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAI AAAAKQAJAAQACwAFAFC2Fk6EQwEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABdthZOhMYAADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX7YWTmRm AwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGa2Fk6EhAsAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAA AADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABA ATAAAAAAAAAAAAAAAAAAAAAAAEABZ7YWTtQSAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG62Fk70swcAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAB0thZOrE4FADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdLYWTjwfCQBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAg Ef/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAA AAAAAAAAAEABdrYWTnydDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHq2Fk40tQwAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABgrYWTgwtCAA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIi2 Fk5MLg0APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACMthZO7MwKAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0 H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZF TlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0 KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29w eXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQg MzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHM AAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAA AAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQCPthZOJKYIADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAk7YWTmyOCgCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENp c2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0p LCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1 cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4 Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoy NyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAA ht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RF dGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAlLYWTszvDABqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGUthZONCwOADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnLYW TtTWCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKG2Fk7sTwoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACuthZOBEYLADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAr7YW TjR0AgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAA AAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABsbYWTnR1BwA8AAAAPAAA AMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAALm2Fk6MxA4AagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAA AP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAA AAAAAAAAAAAAAEABurYWThx+AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL22Fk4kpggAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADGthZOFJcE ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAx7YWTjQ4DACXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEA BlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQ UklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVj aG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdo dCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFw ci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAA AAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAAC AAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAyrYWTmyOCgA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANK2 Fk50dQcAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAA AAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAA AAAAAEAB07YWTmRmAwB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAn jQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAADTthZOLI0FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2rYWTnydDgA8AAAA PAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAANy2Fk6UFg8APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADothZOTC4NAFYAAABWAAAAMzMAAAAJwggXUAAAht1u AAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAA AAAAAAAAAAAAAAAAQAHqthZOHH4BADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA77YWTpz9CwBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHxthZOhEMBADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA87YWTnydDgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPu2Fk7MKwMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtxZONDgMAJcBAACXAQAA AQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAz NzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlU NSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5j aXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lz dGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0A BgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAA AAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkA CQAEAAsABQADtxZOFJcEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrcWTrxdCQBqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEMtxZOhAcLADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAELcW TvwdBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABe3Fk58IA4AlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQh tQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVO VEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQp ClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5 cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAz MC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwA BAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAA AAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAB23Fk4UFAUAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAitxZOLI0FADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKLcWTjR0AgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAg Ef/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAA AAAAAAAAAEABKrcWTsREBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACu3Fk6U1QQAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABLLcWTjR0AgA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADe3 Fk6cvAEAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA3txZOfFwEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO7cWTgwtCABqAAAAagAAADMzAAAA CcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWK AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAE8txZOPB8JAJcBAACX AQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJl LCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgx NSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3 dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28g U3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3Rl YW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf/ /lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAA ACkACQAEAAsABQA/txZOxEQGADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATLcWTty9BgA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE23Fk4c+wEA PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABZtxZOnLwBAHYAAAB2AAAAMzMAAAABwggXUAAAht1uAAAAAEA6//6AAAAAAAAA wAgX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN80AABwgAAAAAAAAAAAEBwggXUAAABQEAAAAABdwD BEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAFm3Fk6M7gcAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABdtxZOzCsD AGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAA AAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABA AWG3Fk78HQQAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABktxZOvF0JAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR //6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAFmtxZOvF0JADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc7cWTty9BgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHa3Fk7sTwoAPAAA ADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAtxZOdHUHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgbcWToRDAQBqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGKtxZOhIQLAJcBAACXAQAAAQAMzMzM wgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNv ZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVM RUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5j b20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywg SW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lz Y28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoD AAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsA BQCMtxZO9LMHADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAjbcWTjwfCQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJi3Fk4UlwQAlwEAAJcBAAAB AAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3 MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1 LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNp c2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0 ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAG AA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAA AgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJ AAQACwAFAJq3Fk4ERgsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACitxZOlNUEADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo7cWTjR0AgBWAAAA VgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABo7cWTuTlDQBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGktxZOHH4BADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAqbcWTjR0AgB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA /wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAA CTqAAAAAACAAAAAAAAAAAAAAAAAAAACptxZO9DYHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArbcWTjQ4DAA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAALa3Fk6EQwEAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAA AP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAA AAAAAAAAAAAAAEABtrcWTnzZBAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALa3Fk60dgwAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBtxZObE0A AJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNv ZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24g MTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0 cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkg Q2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2Rf cmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAA AADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8w AAQACAAAACkACQAEAAsABQDDtxZONLUMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAy7cWToQHCwA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMy3 Fk5MLg0APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADRtxZOhMYAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6A AAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAA AAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAdi3Fk4cvwsAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADctxZO1BIAAFYAAABW AAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJ AgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAHitxZOFNgOADwAAAA8AAAAwggXUAAAwggX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5bcWTjS1 DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAPK3Fk78Xg4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD3txZOHL8LAGoAAABqAAAAMzMAAAAJwgkX UAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAA IAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAfi3Fk5M7QIAPAAAADwAAADC CBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD6txZOPB8JADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABLgWToQHCwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAM IAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUt QURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUg KGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0 CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQg V2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAA AwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAA AAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAB7gWTuxPCgA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA64Fk5c/AYAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARuBZOnLwBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE7gWTpy8AQBqAAAA agAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEVuBZO 5KQDAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEYuBZOHL8LAJcBAACXAQAA AQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAz NzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlU NSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5j aXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lz dGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0A BgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAA AAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkA CQAEAAsABQAbuBZOvF0JADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIbgWTvxeDgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACW4Fk60NQIAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAxuBZO7IsAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMrgWTgQFAQBqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAE4uBZODC0IADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPrgW TuyLAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEi4Fk58XAQAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQf tAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVO VEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQp ClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5 cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAz MC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwA BAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAA AAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAEm4Fk6U1QQAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABNuBZORAYGADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAATbgWTszvDABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0 Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAA AAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFNuBZO5OUNADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATrgWTpQWDwBW AAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABV7gWTozuBwBNAAAATQAAAKsAAAIA AMIJF1AAAGACPQAHAAAAAQADAwAAAgACIQADAAYAAAAAAAAEAAI8AAUAAtgFBgACAAEHAAbCCRdQ AABkAAF5kAEBAZEBAu4FWrgWTmSnDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGK4Fk70swcAPAAAADwAAADCCBdQAADC CBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnuBZO FNgOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAc7gWToTGAABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAF0uBZOBAUBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdLgWToQHCwB2AAAAdgAA ADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYA TfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAA AAAAAAB0uBZOtHYMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeLgWTszvDAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH24Fk6sMAoAlwEAAJcB AAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUs IDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1 KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3 LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBT eXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVh bQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+ UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAA KQAJAAQACwAFAH+4Fk7siwAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACFuBZO/F4OAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAYm4Fk5k4wMAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACP uBZOzK4CADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAkLgWTqRnCABWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+ gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAA AAAAAEABlrgWTqzLBQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJq4Fk70swcAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqq AwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMz NzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRX QVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3Vw cG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBp bGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIA SQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAA AAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAJ24Fk7MrgIA PAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACfuBZOhAcLAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAA wAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEw AAAAAAAAAAAAAAAAAAAAAABAAaW4Fk7cvQYAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACquBZOZOMDADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA t7gWTsREBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAL24Fk4MLQgAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBuBZOpGcIAJcBAACXAQAAAQAM zMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQDDuBZONLUMAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAcS4Fk5sTQAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADKuBZOFJcEADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzrgWTmxN AABWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB0bgWTmSnDQA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANe4Fk6U1QQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADduBZOxEQGAE0AAABNAAAAqwAAAgAAwggXUAAAYAI9AAcAAAAB AAMDAAACAAIhAAMABgAAAAAAAAQAAjwABQAC2AUGAAIAAQcABsIIF1AAAGQAAXmQAQEBkQEC7gXh uBZOVBUKAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAeW4Fk6c/QsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADnuBZOrMsFADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8rgWTjQ4DAA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPi4Fk7szAoAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAA AAAAAAAAAAAAAAAAAEAB+bgWTgQFAQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0 AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5U RVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkK VGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHly aWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMw LUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAE AAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAA AAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA+bgWTnxcBAA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA APq4Fk5sjgoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAADuRZOlNUEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACLkWTmRmAwB2AAAAdgAAADMz AAAAAcIIF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfNA AAcIAAAAAAAAAAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAA AAAIuRZO9LMHAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/ AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAENuRZONHQCADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAD7kWTlx/BgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABC5Fk7U1gkAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABF7kWToSECwCXAQAAlwEAAAEADMzM zMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBT b2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJF TEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28u Y29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMs IEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNp c2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqq AwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAAL AAUAGLkWTtQSAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACC5Fk78Xg4APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiuRZOJKYIADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKbkWTsyuAgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA /wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAA AAAAAAAAAAAAQAEpuRZO/B0EADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMrkWThy/CwCXAQAAlwEAAAEADMzMzMIJF1AA AAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2Fy ZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0Ug U09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3Rl Y2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4K Q29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3 MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbd ABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUANLkW Thx+AQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADW5Fk5UFQoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/uRZOpOQIAFYAAABWAAAAMzMAAAAJ wggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAFBuRZONLUMAHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAA AEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkX UAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAEK5Fk7U1gkAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABDuRZO9DYHAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAUe5Fk60dgwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIuRZOzO8MADwAAAA8AAAAwggXUAAAwggX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAULkWTrR2 DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAFy5Fk5UFQoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABduRZOzO8MADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZbkWTpz9 CwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAA QAFquRZOZKcNADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAcrkWTszvDAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHO5Fk5M7QIAlwEAAJcBAAAB AAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3 MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1 LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNp c2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0 ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAG AA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAA AgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJ AAQACwAFAHO5Fk70NgcAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB6uRZOdHUHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAe7kWTiSmCABWAAAA VgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABf7kWTtQSAABqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGFuRZOhIQLADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAh7kWTvSzBwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAI25Fk60dgwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRuRZOFBQFAJcBAACXAQAA AQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAz NzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlU NSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5j aXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lz dGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0A BgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAA AAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkA CQAEAAsABQCZuRZOfFwEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmrkWTpz9CwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ25Fk58XAQAagAA AGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABobkW ToSECwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKu5Fk58IA4AlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQf tAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVO VEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQp ClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5 cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAz MC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwA BAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAA AAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAK25Fk58IA4APAAAADwAAADC CBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACuuRZOHL8LADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAtbkWTgRGCwBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAg Ef/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAA AAAAAAAAAEABu7kWTrR2DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL25Fk48nAkAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABwrkWTqRnCAA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMK5 Fk4ERgsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADKuRZOvF0JADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1rkWToRDAQA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANe5 Fk7sTwoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADYuRZO1BIAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6A AAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAA AAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAd65Fk40dAIAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADouRZOrE4FAJcBAACX AQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJl LCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgx NSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3 dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28g U3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3Rl YW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf/ /lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAA ACkACQAEAAsABQDpuRZONHQCADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA67kWTkztAgA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOu5Fk5kZgMA VgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAfW5Fk6U1QQAagAAAGoAAAAzMwAA AAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRV igIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB9bkWTjwfCQA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPy5Fk6sTgUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD8uRZO9LMHADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABroWTuTlDQCXAQAA lwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2Fy ZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQo MTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93 d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2Nv IFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90 ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX //5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgA AAApAAkABAALAAUACboWTnxcBAB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAA AMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXc AwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAAAJuhZO9LMHADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADboWTmxN AABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAA QAEPuhZO/B0EADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAELoWTtTWCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABu6Fk48HwkAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAluhZOzCsDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAJboWTjS1DACXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAM IAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUt QURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUg KGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0 CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQg V2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAA AwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAA AAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAJroWTmSnDQBWAAAA VgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABKLoWTtTWCQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACy6Fk50 dQcAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAA AEABMboWTrQ1AgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADi6Fk7UEgAAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9uhZOhEMBADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQboWTmSnDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEK6Fk7MbA0AagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAA NBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAA AAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABTLoWTmTjAwA8AAAAPAAAAMIIF1AAAMIIF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE26Fk4c+wEA PAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABXuhZOBAUBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYLoWTjS1DABWAAAAVgAAADMzAAAACcIIF1AA AIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAA AAAAAAAAAAAAAAAAAAAAAEABYboWTswrAwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAAC tB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURW RU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZj NCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNv cHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2Vk IDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEB zAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAA AAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAYboWThSXBABqAAAAagAA ADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFhuhZO3L0G ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAYboWTsxsDQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGq6Fk78Xg4APAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2uhZOnP0L ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAeboWTqzLBQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAA AMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB MAAAAAAAAAAAAAAAAAAAAAAAQAF7uhZOhMYAADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfboWTuSkAwA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIa6Fk4c+wEAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNj byBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwg VmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBw b3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYt MjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6Mjcg YnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbd ABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRo ZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAIa6Fk40tQwAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQuhZOFBQFADwAAAA8 AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAk7oWTkwuDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJq6Fk4ERgsAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4A AAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAA AAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABnLoWTqxOBQCXAQAAlwEAAAEADMzMzMIJ F1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0 d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVB U0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29t L3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIElu Yy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2Nv IDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAA AIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA nboWTuTlDQB2AAAAdgAAADMzAAAAAcIIF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIA AAAAAAAAAAAAAAAAAYYATfNAAAcIAAAAAAAAAAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqA AAAAACAAAAAAAAAAAAAAAAAAAACfuhZOzK4CADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAn7oWTnwgDgBWAAAAVgAAADMz AAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA IMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABo7oWThTYDgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKm6Fk6kZwgAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAC2uhZOPJwJADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuboWToQHCwBqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAG5uhZOTC4NADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuroW TnydDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAMi6Fk6ExgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADLuhZOzGwNADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0roW TnydDgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAA AAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAA AAAAQAHTuhZOZOMDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA07oWTpTVBAB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAA AABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJ F1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAADVuhZO1BIAAJcBAACX AQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJl LCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgx NSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3 dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28g U3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3Rl YW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf/ /lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAA ACkACQAEAAsABQDWuhZOZKcNADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2boWThx+AQBWAAAAVgAAADMzAAAACcIIF1AA AIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAA AAAAAAAAAAAAAAAAAAAAAEAB4boWToSECwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOK6Fk4U2A4APAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADs uhZOHH4BAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAfC6Fk7siwAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD3uhZOhAcLAE0AAABNAAAAqwAAAgAAwgkXUAAAYAI9 AAcAAAABAAMDAAACAAIhAAMABgAAAAAAAAQAAjwABQAC2AUGAAIAAQcABsIJF1AAAGQAAXmQAQEB kQEC7gX4uhZOhEMBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+LoWTkQGBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC7Fk40tQwAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACuxZONLUMAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8 Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzkt TSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwg U3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAx OTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4 OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMA AACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFz dEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQAEuxZOJKYIAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAQu7Fk5k4wMAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL uxZO9DYHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEbsWTrQ1AgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+ gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAA AAAAAEABFbsWThy/CwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA /ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5 LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2Fs IFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykg MTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAx ODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoD AAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zh c3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAGLsWTjwfCQA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB+7Fk4cvwsA PAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAfuxZOTC4NAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAA wAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEw AAAAAAAAAAAAAAAAAAAAAABAASG7Fk7MKwMAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApuxZO1BIAADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA NrsWThx+AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAADi7Fk70swcAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDuxZOhMYAAGoAAABqAAAAMzMA AAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0 VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAUO7Fk4cfgEAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABOuxZOrE4FADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAULsWTkztAgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFO7Fk7siwAAVgAA AFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAVq7Fk4sjQUAlwEAAJcBAAABAAzMzMzC CRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29m dHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxF QVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNv bS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJ bmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNj byAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMA AACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAF AFu7Fk7ERAYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABhuxZOHL8LADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYrsWTkQGBgBqAAAAagAAADMz AAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA NFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFiuxZOtHYMADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAb7sWTnwgDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHa7Fk7ERAYAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8uxZOfCAOADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAgLsWTkwuDQCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIx AAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklT RUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5p Y2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAo YykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0w OCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAII qqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMA E0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAgbsWTmRmAwBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGBuxZOvF0JADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAirsWTgQFAQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIq7Fk4EBQEAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAA IBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAA AAAAAAAAAABAAYu7Fk4UFAUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUuxZOtHYMAJcBAACXAQAAAQAMzMzMwgkXUAAA AYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJl IChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBT T0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVj aHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpD b21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcy NQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0A ECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQCXuxZO 1NYJADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAmLsWTnR1BwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAGcuxZOnLwBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAn7sWTrxdCQA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAKC7Fk4ERgsAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAA AP8CAAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40A AAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAAqbsWTnxcBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALO7Fk78Xg4APAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAC1uxZOBAUBAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAbW7Fk78HQQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC/uxZO7IsAADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw7sWThQU BQBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABx7sWTgRGCwA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AMq7Fk4UFAUAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADPuxZO/B0EAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAdC7Fk5sdg4AlwEAAJcBAAABAAzMzMzCCRdQAAAB iaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUg KEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNP RlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNo c3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNv bXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1 AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQ IAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFANG7Fk6k kQEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADduxZOnP0LADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3rsWTrxdCQA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOa7Fk7U 1gkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADsuxZOFJcEAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAA AAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAA QAEwAAAAAAAAAAAAAAAAAAAAAABAAfO7Fk5cfwYAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5uxZORAYGAFYAAABWAAAA MzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkC CQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAH5uxZOdHUHADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+7sWTvwdBACX AQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0 d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEy LjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6 Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENp c2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3Jl bF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAA wAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAE AAgAAAApAAkABAALAAUABLwWTpQWDwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW8Fk5EBgYAPAAAADwAAADCCBdQAADC CBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGvBZO 5KQDAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAA AABAAQu8Fk6c/QsAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxD aXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1N KSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBT dXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5 ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6 MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAA AIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0 RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAA28Fk5kpw0APAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZvBZOvNoJADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAG7wWTlz8BgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACG8Fk50dQcAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABIbwWTlQVCgA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC28 Fk48nAkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAvvBZO/F4OADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANLwWTgwtCABWAAAAVgAAADMzAAAA CcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0 AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABOrwWTpy8AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADy8Fk7kpAMAagAAAGoA AAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkC CQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABP7wWTsyu AgB2AAAAdgAAADMzAAAAAcIIF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAA AAAAAAAAAYYATfNAAAcIAAAAAAAAAAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAA AAAAAAAAAAAAAAAAAABAvBZOzCsDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARLwWTpQWDwA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEq8Fk5E BgYAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAE28Fk4UlwQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABXvBZO7IsAADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA WrwWThTYDgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAFbvBZOjI8CADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXbwWTuSkAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGq8Fk58XAQAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABsvBZOBAUBAHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX //5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDA ACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAG+8Fk5cYQsAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABb7wWTnydDgA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHG8 Fk403wUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABxvBZOdHUHAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6A AAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAA AAAAQAF6vBZOXPwGAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8 Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzkt TSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwg U3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAx OTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4 OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMA AACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFz dEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQB7vBZOLI0FADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhLwWTjQ4DACX AQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0 d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEy LjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6 Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENp c2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3Jl bF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAA wAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAE AAgAAAApAAkABAALAAUAhbwWTuzMCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIe8Fk40dAIAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACOvBZO /B0EAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAA AABAAY68Fk6c/QsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACbvBZOpOQIADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnbwWTmyOCgA8AAAAPAAA AMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAKO8Fk7MbA0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACqvBZO1NYJAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAA ADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAA AAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAa28Fk4UFAUAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACyvBZOfCAO ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAs7wWTozuBwBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAA AMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB urwWTkQGBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAL+8Fk4kpggAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAA ArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFE VkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChm YzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApD b3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdl ZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMB AcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAA AAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAMK8Fk70NgcAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADGvBZOpOQIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAcm8Fk5EBgYAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADNvBZOJKYIADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1rwWTty9 BgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAN+8Fk7ERAYAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgvBZO7IsAAGoAAABqAAAAMzMAAAAJwgkX UAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAA IAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAeG8Fk7ERAYAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADqvBZO7IsAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA9bwWTjwfCQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPW8Fk6UFg8APAAAADwAAADC CBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD2vBZOPB8JAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/ AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAH7vBZOrE4FAJcB AACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQD7vBZO1NYJAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAA AAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAA QAEwAAAAAAAAAAAAAAAAAAAAAABAAf68Fk7kpAMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABvRZO7E8KAJcBAACXAQAA AQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAz NzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlU NSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5j aXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lz dGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0A BgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAA AAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkA CQAEAAsABQALvRZOLI0FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADL0WTmTjAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABi9Fk6kZwgAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAdvRZOjO4HAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX //5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAA AAAAAAAAAAAAAAAAAABAAR29Fk4ERgsATQAAAE0AAACrAAACAADCCRdQAABgAj0ABwAAAAEAAwMA AAIAAiEAAwAGAAAAAAAABAACPAAFAALYBQYAAgABBwAGwgkXUAAAZAABeZABAQGRAQLuBR69Fk6c vAEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAhvRZOzK4CADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJb0WTmTjAwA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC69Fk5U FQoAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAS+9Fk58nQ4APAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAwvRZO7IsAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/ AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAA AAAAAAAAAABAATC9Fk60dgwAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADA CRf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AME QMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAANr0WTlQVCgA8AAAAPAAAAMIIF1AAAMIIF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADi9Fk6sTgUA lwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29m dHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAx Mi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRw Oi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBD aXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9y ZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAA AMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAA BAAIAAAAKQAJAAQACwAFADu9Fk7MKwMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIvRZOzCsDADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATr0W TmxNAAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAFW9Fk4EBQEAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAA AAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAA AABAATAAAAAAAAAAAAAAAAAAAAAAAEABVb0WTmTjAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFe9Fk60NQIAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABbvRZOHL8LAE0AAABNAAAAqwAAAgAAwggXUAAAYAI9AAcAAAABAAMDAAACAAIhAAMABgAA AAAAAAQAAjwABQAC2AUGAAIAAQcABsIIF1AAAGQAAXmQAQEBkQEC7gVivRZOHL8LADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAZL0WTsyuAgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGy9Fk58IA4AVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAA IBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAA AAAAAAAAAABAAW29Fk5kZgMAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADA CRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAA AAAAAAAAAAAAAAAAAAAAAEABbb0WThQUBQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHS9Fk60NQIAlwEAAJcBAAABAAzM zMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAg U29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBS RUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2Nv LmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1z LCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5D aXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiq qgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQA CwAFAHS9Fk6UFg8APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2vRZOVBUKADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgb0WTuzMCgA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIG9Fk4ERgsAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxD aXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1N KSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBT dXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5 ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6 MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAA AIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0 RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAIe9Fk5M7QIAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABib0WTmTjAwA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIq9 Fk6EBwsAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACVvRZOtDUCADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAn70WTsREBgA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKC9 Fk5sTQAAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAChvRZOhMYAAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6A AAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAA AAAAQAGhvRZOpOQIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAae9Fk48HwkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACxvRZOhAcLAJcBAACXAQAAAQAMzMzMwgkX UAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3 YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFT RSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20v dGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5j LgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28g MzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAA ht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQC0 vRZO1NYJADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAtr0WTlx/BgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMG9Fk40OAwAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADF vRZOHPsBAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAcW9Fk40tQwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADLvRZOZOMDADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0b0WTsxsDQA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAANq9Fk4c+wEAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAdu9Fk78 HQQAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAA AEAB3L0WTlSqBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAN29Fk5M7QIAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADivRZOTC4NADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA7L0WTiSmCACXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENp c2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0p LCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1 cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4 Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoy NyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAA ht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RF dGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA7r0WTnxcBAB2AAAAdgAAADMzAAAAAcIIF1AAAIbd bgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfNAAAcIAAAAAAAAAAAB AcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAADvvRZO3L0GADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA870WTuyLAAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPS9Fk78Xg4AagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB970WTpTVBAA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPq9 Fk70NgcAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8CAAAA AAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAA AAAgAAAAAAAAAAAAAAAAAAAA/L0WTjQ4DACXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAAC tCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURW RU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZj NCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNv cHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2Vk IDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEB zAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAA AAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAAb4WTsxsDQA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAe+Fk7MbA0APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPvhZOHPsBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEb4WTqzLBQBWAAAAVgAA ADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABF74WTuxPCgBqAAAAagAAADMzAAAACcIJF1AA AIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAA AAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEZvhZOVBUKADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Hr4WTlx/BgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACa+Fk7ERAYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwvhZO7MwKAJcBAACXAQAAAQAM zMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQAzvhZOvF0JADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANL4WTuxPCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADa+Fk5k4wMAagAAAGoA AAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkC CQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABNr4WTjyc CQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAEG+Fk6EBwsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJvhZOZOMDADwAAAA8AAAAwggXUAAAwggX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATr4WTszv DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAE++Fk4EBQEAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA AVO+Fk7kpAMAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAA AAAAAAAAAEABU74WTjS1DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFu+Fk5kJA4APAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcvhZO1NYJADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAZL4WTty9BgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIy AAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklT RUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5p Y2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAo YykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0w OCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAII qqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMA E0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAZ74WTuSkAwA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGm+Fk5c /AYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAA AEABc74WTgQFAQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHS+Fk6U1QQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB+vhZOtHYMAJcBAACXAQAA AQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAz NzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlU NSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5j aXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lz dGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0A BgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAA AAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkA CQAEAAsABQCBvhZOFBQFADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAib4WTsyuAgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIq+Fk4ERgsAagAA AGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABi74W TqxOBQBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAA AAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABi74WTty9BgA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAI++Fk7kIQQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACZvhZOnLwBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnb4WTtQSAAA8AAAAPAAA AMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJ++Fk7M7wwAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAA AP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAA AAAAAAAAAAAAAEABo74WTsREBgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEA BlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQ UklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVj aG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdo dCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFw ci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAA AAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAAC AAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAo74WTjycCQA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKy+ Fk6UFg8APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC0vhZOhEMBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAur4WTuyLAAA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMC+ Fk70swcAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAA AAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAA AAAAAEABx74WToRDAQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMe+Fk4cvwsAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4A AAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAA AAAAAAAAAAAAAABAAci+Fk6k5AgAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADJvhZOTO0CAHYAAAB2AAAAMzMAAAABwgkX UAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAABwgAAAAA AAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAMm+Fk6E hAsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADVvhZO7E8KADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2L4WTlx/BgBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHevhZOvF0JADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA3r4WTnydDgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENp c2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0p LCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1 cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4 Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoy NyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAA ht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RF dGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA4b4WTrR2DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO6+Fk5MLg0APAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADzvhZOlNUEADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+74WTuwIAQBqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAH7vhZONHQCADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/b4W TqRnCACXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElP UyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJz aW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6 IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4 IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBw cm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6A AAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5l dDAvMAAEAAgAAAApAAkABAALAAUAAr8WTkwuDQBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAg Ef/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAA AAAAAAAAAEABBr8WTnydDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAi/Fk7UEgAAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUvxZO7IsAADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAGr8WTty9BgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAA AAAAAAAAAAAAAAAAAAAAQAEbvxZOxEQGADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH78WThx+AQA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACG/ Fk4c+wEAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJ T1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVy c2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0 OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAw OCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkg cHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+ gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJu ZXQwLzAABAAIAAAAKQAJAAQACwAFACS/Fk7UEgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxvxZOzK4CADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAM78WTuzMCgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA /wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAA AAAAAAAAAAAAQAE1vxZOHL8LADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN78WToRDAQA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADu/Fk60dgwA VgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAUS/Fk4sjQUAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABK vxZO9EgEADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAUb8WTnR1BwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFG/Fk68XQkAagAAAGoAAAAzMwAA AAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRV igIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABUb8WTtTWCQBNAAAA TQAAAKsAAAIAAMIJF1AAAGACPQAHAAAAAQADAwAAAgACIQADAAYAAAAAAAAEAAI8AAUAAtgFBgAC AAEHAAbCCRdQAABkAAF5kAEBAZEBAu4FVb8WToQHCwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF6/Fk78Xg4APAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABfvxZOZKcNAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8 Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzkt TSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwg U3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAx OTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4 OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMA AACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFz dEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQBgvxZOHPsBADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ78WTozuBwBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFo vxZOtHYMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdb8WTtQSAAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHW/Fk5MagMAVgAAAFYAAAAzMwAA AAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDF tAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAXW/Fk4ERgsAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB/vxZOJKYIAJcBAACX AQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJl LCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgx NSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3 dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28g U3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3Rl YW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf/ /lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAA ACkACQAEAAsABQCCvxZOtHYMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAi78WTuSkAwA8AAAAPAAAAMIIF1AAAMIIF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIu/Fk50dQcA agAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB jr8WThx+AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAJq/Fk5MLg0AdgAAAHYAAAAzMwAAAAHCCBdQAACG3W4AAAAAQDr/ /oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3zQAAHCAAAAAAAAAAAAQHCCBdQAAAF AQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAAm78WTrQ1AgA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AJ6/Fk5UFQoAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6 gAAAAAAgAAAAAAAAAAAAAAAAAAAAnr8WTvxeDgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKK/Fk7k5Q0AlwEAAJcBAAAB AAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3 MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1 LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNp c2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0 ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAG AA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAA AgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJ AAQACwAFAKS/Fk7MbA0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACqvxZO5KQDAGoAAABqAAAAMzMAAAAJwgkXUAAAht1u AAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAA AAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAa+/Fk5kpw0AVgAAAFYAAAAzMwAAAAnC CBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIB AAAgAAAAAAAAAAAAAAAAAAAAAABAAbC/Fk60NQIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC1vxZOBDoNADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAub8WThy/CwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMa/Fk5kpw0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADJvxZORAYGAGoAAABqAAAA MzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkC CQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAcu/Fk4cvwsA PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADTvxZOlBYPADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4b8WTryTAAA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOK/Fk6sTgUA PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADrvxZO1BIAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAA wAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEw AAAAAAAAAAAAAAAAAAAAAABAAeu/Fk5k4wMAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAA ArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFE VkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChm YzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApD b3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdl ZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMB AcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAA AAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAO6/Fk7MKwMAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADxvxZORAYGAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAH4vxZOrE4F ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA+78WTnxcBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAFk58XAQAlwEAAJcBAAABAAzMzMzCCBdQ AAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdh cmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNF IFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90 ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMu CkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAz NzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG 3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAArA Fk4sjQUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAMwBZOxMEGADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE8AWTtQSAAA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACDA Fk6EQwEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAhwBZOXPwGADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIcAWTrxdCQBqAAAAagAAADMzAAAA CcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWK AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAElwBZOdHUHAJcBAACX AQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJl LCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgx NSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3 dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28g U3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3Rl YW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf/ /lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAA ACkACQAEAAsABQAowBZOxEQGADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKcAWTnR1BwBWAAAAVgAAADMzAAAACcIIF1AA AIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAA AAAAAAAAAAAAAAAAAAAAAEABM8AWToRDAQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADfAFk6EQwEAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABA wBZONHQCADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAQ8AWTgRGCwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+ gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAA AAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFLwBZOZGYDADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATcAWTvwdBAA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFrAFk4UlwQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABfwBZOzO8MADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZMAWTty9BgBWAAAA VgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABZcAWTgRGCwA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGfAFk6s TgUAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAA AEABbsAWTiyNBQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENp c2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0p LCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1 cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4 Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoy NyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAA ht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RF dGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAccAWTmTjAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHTAFk58nQ4APAAA ADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAB+wBZOZOMDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgMAWTkztAgCXAQAAlwEAAAEADMzMzMIIF1AAAAGJ qqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAo QzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09G VFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hz dXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29t cGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUA AgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAg AAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAgMAWTvQ2 BwB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAA AAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAA AAAAAAAAAAAAAAAAAACAwBZOfJ0OADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAg8AWTrQ1AgBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGJwBZOXPwGADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAisAWThw2DQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJfAFk7k5Q0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACfwBZOZOMDADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAn8AWTvxeDgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA /wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABoMAWTiSmCABq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGg wBZObI4KADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAqMAWTvSzBwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAAC tB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURW RU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZj NCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNv cHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2Vk IDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEB zAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAA AAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAq8AWTiyNBQA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAALLAFk6M7gcAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4wBZOHH4BADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuMAWTlQVCgBqAAAAagAA ADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAG+wBZO/B0E ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAyMAWTty9BgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMvAFk6sTgUAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYwBZODC0I ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA3MAWTuyLAABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAA AMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB MAAAAAAAAAAAAAAAAAAAAAAAQAHfwBZOXPwGADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4MAWTvwdBABWAAAAVgAAADMz AAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA IMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB5MAWTsREBgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJ qqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAo QzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09G VFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hz dXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29t cGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUA AgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAg AAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA58AWTnxc BAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAPLAFk5sjgoAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAA AADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABA ATAAAAAAAAAAAAAAAAAAAAAAAEAB9MAWTpTVBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPXAFk7M7wwAPAAAADwAAADC CBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABwRZOXH8GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAcEWTgRGCwCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAM IAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUt QURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUg KGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0 CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQg V2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAA AwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAA AAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAAsEWTnwgDgA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAArBFk6kZwgAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwRZOfCAOAGoAAABqAAAAMzMAAAAJwgkXUAAAht1u AAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAA AAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAQ7BFk78HQQAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwRZO vF0JADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAG8EWTpQWDwBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAA AAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAA AEABIMEWThQUBQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACDBFk5MLg0AlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAA DCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1 LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJF IChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9y dApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVk IFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAA AAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAA AAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFACHBFk7M7wwAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAqwRZO5OUNAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX //5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAA AAAAAAAAAAAAAAAAAABAASvBFk6ExgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1wRZO5KQDADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQcEW TmxNAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEbBFk6EhAsAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAA AAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAA AAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAASMEWTlx/BgB2AAAAdgAAADMzAAAA AcIIF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfNAAAcI AAAAAAAAAAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAABI wRZOpGcIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAUrBFk6UFg8APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOwRZOzCsDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWcEWTty9BgBWAAAA VgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABW8EWTmRmAwA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGDBFk58 XAQAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABhwRZOzO8MAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QA AQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRF UlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpU ZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJp Z2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAt QXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQA AAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAA AAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQBiwRZOhMYAADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA YsEWTswrAwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAFowRZOnLwBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc8EWTuSkAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHXBFk4UlwQAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAB/wRZOZOMDAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX //5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAA AAAAAAAAAAAAAAAAAABAAX/BFk6s0QQAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQh tQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVO VEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQp ClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5 cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAz MC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwA BAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAA AAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAH/BFk7ERAYAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACGwRZOdHUHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAiMEWTsyuAgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJLBFk4EBQEAVgAAAFYAAAAz MwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAZLBFk6sTgUAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACXwRZOFNgOAJcB AACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQCYwRZOhMYAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAA AAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAA QAEwAAAAAAAAAAAAAAAAAAAAAABAAZnBFk5sTQAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACawRZOhAcLADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAo8EWTmRmAwBNAAAATQAAAKsAAAIAAMIIF1AAAGACPQAHAAAAAQADAwAAAgACIQADAAYAAAAA AAAEAAI8AAUAAtgFBgACAAEHAAbCCBdQAABkAAF5kAEBAZEBAu4Fo8EWTlQVCgA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ALDBFk7sTwoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACxwRZOTO0CADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuMEWThx+AQBqAAAAagAAADMz AAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA NFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAG9wRZOVBUKADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAxsEWTpy8AQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMjBFk48HwkAVgAAAFYAAAAzMwAAAAnCCBdQAACG 3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAA AAAAAAAAAAAAAAAAAABAAcrBFk5sjgoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADXwRZOHL8LADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3sEW TtQSAAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAN7BFk70NgcAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAA AAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAA AABAATAAAAAAAAAAAAAAAAAAAAAAAEAB3sEWToSECwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoD AAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3 MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdB UkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBw b3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGls ZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJ AAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAA AAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA3sEWTsxsDQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAOjBFk7siwAATQAAAE0AAACrAAACAADCCRdQAABgAj0ABwAAAAEAAwMAAAIAAiEA AwAGAAAAAAAABAACPAAFAALYBQYAAgABBwAGwgkXUAAAZAABeZABAQGRAQLuBevBFk48HwkAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD1wRZOHH4BADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+MEWTjycCQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPrBFk6sTgUAagAA AGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB/cEW TozuBwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/BFk5EAAcAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQh tQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVO VEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQp ClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5 cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAz MC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwA BAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAA AAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAATCFk6U1QQAVgAAAFYAAAAz MwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAQnCFk7UEgAAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwhZOrMsFADwA AAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAE8IWTlQVCgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAA AAAAAAAAAAAAAAAAAAAAQAETwhZOTC4NADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFsIWTjR0AgB2AAAAdgAAADMzAAAA AcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcI AAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAAAZ whZOFBQFAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28g SU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZl cnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9y dDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIw MDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5 IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ /oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVy bmV0MC8wAAQACAAAACkACQAEAAsABQAcwhZOTO0CADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIMIWTlz8BgA8AAAAPAAA AMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACXCFk60NQIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuwhZOdHUHAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAA ADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAA AAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAATLCFk7MrgIAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0whZONDgM ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAP8IWTnxcBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEHCFk48HwkAVgAAAFYAAAAzMwAAAAnCCBdQ AACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAg AAAAAAAAAAAAAAAAAAAAAABAAUrCFk6sTgUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLwhZOzK4CADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA UcIWTkztAgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAFRwhZOFNgOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWcIWThx+AQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJ qqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAo QzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09G VFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hz dXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29t cGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUA AgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAg AAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAWcIWTiyN BQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGHCFk6kZwgAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABlwhZOBEYLADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ8IWTpTV BABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAA QAFywhZONDgMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAd8IWTvQ2BwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH3CFk5c/AYAVgAAAFYAAAAz MwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAX/CFk78Xg4APAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACCwhZOHE4JAJcB AACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQCHwhZO1BIAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAA AAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAA QAEwAAAAAAAAAAAAAAAAAAAAAABAAYjCFk4sjQUAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIwhZOfCAOADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAlcIWTnydDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJvCFk7szAoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACfwhZOHH4BAJcBAACXAQAA AQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAz NzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlU NSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5j aXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lz dGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0A BgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAA AAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkA CQAEAAsABQCfwhZOFJcEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAosIWTkztAgBqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGnwhZOtDUCADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAr8IW TmxNAAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAALHCFk7ERAYAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAA AAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAA AABAAbTCFk5k4wMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBwhZO5KQDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxcIWTjQ4DABqAAAAagAA ADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHFwhZO/F4O ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAx8IWTvxeDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANXCFk4EBQEAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADawhZOZOMD ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA38IWTjR0AgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEA BlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQ UklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVj aG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdo dCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFw ci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAA AAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAAC AAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA4sIWTgQFAQA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOTC Fk4c+wEAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAA AAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAA AAAAAEAB7MIWTswrAwBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+ UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB7cIWTgRG CwB2AAAAdgAAADMzAAAAAcIIF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAA AAAAAAAAAYYATfNAAAcIAAAAAAAAAAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAA AAAAAAAAAAAAAAAAAADuwhZOfJ0OADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA78IWTpy8AQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPbCFk40 dAIAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAg AAAAAAAAAAAAAAAAAAAA+cIWTqxOBQCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1 AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5U RVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkK VGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHly aWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMw LUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAE AAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAA AAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA/MIWThSXBAA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAPDFk6cvAEAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAFwxZOpOQIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAQbDFk7ERAYAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwxZOHPsBADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAFMMWTsREBgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnDFk5M7QIAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgwxZOHH4BAGoA AABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAA AAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAASPD Fk7ERAYAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJ T1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVy c2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0 OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAw OCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkg cHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+ gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJu ZXQwLzAABAAIAAAAKQAJAAQACwAFACTDFk6k5AgAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAA IBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAA AAAAAAAAAABAASbDFk7kpAMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnwxZOfJ0OADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKcMWTuzMCgA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADXDFk4kpggAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6wxZOhEMBAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAUDDFk7MrgIAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABC wxZOpGcIADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAScMWThy/CwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFTDFk58nQ4APAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABW wxZONLUMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAWsMWTjQ4DABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+ gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAA AAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFhwxZObE0AAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmq qgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChD MzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZU V0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1 cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21w aWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQAC AEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAA AAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQBjwxZO5OUN ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAZMMWTlQVCgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAA AMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB bMMWTuSkAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHDDFk58nQ4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4wxZOzO8MAJcBAACXAQAAAQAM zMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQB+wxZOhMYAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfsMWTuxPCgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGCwxZOpOQIADwAAAA8AAAAwggXUAAAwggX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAi8MWTsyu AgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAJjDFk5sTQAAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACYwxZO5KQDADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoMMWTjR0 AgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAA QAGgwxZO/F4OADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAApcMWTqTkCAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKnDFk7ERAYAlwEAAJcBAAAB AAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3 MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1 LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNp c2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0 ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAG AA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAA AgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJ AAQACwAFAKzDFk6U1QQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2wxZOnP0LADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAu8MWTqTkCAA8AAAA PAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAL7DFk7UEgAAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAA AAAAAAAAAAAAAAAAAEABwcMWTqxOBQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM7DFk4UFAUAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADVwxZO tDUCADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA1cMWTnwgDgB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAA AAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAADYwxZOzK4CAFYAAABWAAAAMzMAAAAJ wggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAHZwxZOPJwJADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2sMWTgwtCABqAAAAagAA ADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHdwxZOxEQG ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA58MWTjwfCQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEA BlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQ UklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVj aG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdo dCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFw ci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAA AAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAAC AAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA6cMWThz7AQA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOnD Fk78Xg4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADzwxZOVBUKAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0 IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZF TlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0 KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29w eXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQg MzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHM AAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAA AAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQD3wxZO1BIAADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA+MMWTmRmAwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA /wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAA AAAAAAAAAAAAQAH/wxZOZGYDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMQWTtQSAAA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3EFk6sywUA VgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAQ7EFk5kpw0APAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU xBZOhEMBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAFMQWTsyuAgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABTEFk7kpAMAagAAAGoAAAAzMwAA AAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRV igIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABGsQWThSXBAA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACTEFk48HwkAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAF APxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VL OS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNh bCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMp IDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDgg MTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqq AwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNG YXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFACfEFk5c/AYAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqxBZONLUM ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAMMQWThQUBQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAA AMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB MAAAAAAAAAAAAAAAAAAAAAAAQAE0xBZODC0IADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQcQWTtTWCQA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEPEFk6c/QsAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABOxBZO7E8KADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU8QWTvxeDgBWAAAAVgAAADMz AAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA IMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABVcQWTvwdBABqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFbxBZOhEMBADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW8QW TkwuDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGjEFk58nQ4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByxBZOrE4FADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc8QW Thx+AQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElP UyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJz aW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6 IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4 IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBw cm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6A AAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5l dDAvMAAEAAgAAAApAAkABAALAAUAc8QWTlQVCgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHTEFk58XAQAagAAAGoAAAAz MwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABe8QWTuzMCgCX AQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0 d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEy LjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6 Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENp c2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3Jl bF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAA wAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAE AAgAAAApAAkABAALAAUAf8QWTpTVBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITEFk6c/QsAPAAAADwAAADCCBdQAADC CBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJxBZO ZOMDAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAGMxBZOrE4FADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAlsQWTqRnCABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA /wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAA AAAAAAAAAAAAQAGWxBZOZKcNADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmsQWTlz8BgB2AAAAdgAAADMzAAAAAcIIF1AA AIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfNAAAcIAAAAAAAA AAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAACaxBZOBEYL ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAmsQWTnwgDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKTEFk7MbA0APAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACpxBZOHPsB AGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAA AAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABA AavEFk7U1gkAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6 gAAAAAAgAAAAAAAAAAAAAAAAAAAArcQWTqRnCACXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAM IAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUt QURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUg KGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0 CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQg V2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAA AwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAA AAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUArsQWTuTlDQA8AAAA PAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALDEFk7ERAYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC9xBZOXPwGADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwsQWTjwfCQBWAAAA VgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABxcQWTpy8AQA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMXEFk58 IA4ATQAAAE0AAACrAAACAADCCRdQAABgAj0ABwAAAAEAAwMAAAIAAiEAAwAGAAAAAAAABAACPAAF AALYBQYAAgABBwAGwgkXUAAAZAABeZABAQGRAQLuBcnEFk7kpAMAagAAAGoAAAAzMwAAAAnCCRdQ AACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAg AAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABysQWTlz8BgA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANfEFk4UFAUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADaxBZOzCsDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4cQWTrxdCQA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AOvEFk4cvwsAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAA AAAAAAAAAEAB68QWTnwgDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO3EFk6M7gcAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD0xBZO7E8KAJcB AACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQD0xBZOlBYPADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+MQWTgQFAQCXAQAAlwEAAAEADMzMzMII F1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0 d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVB U0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29t L3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIElu Yy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2Nv IDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAA AIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA /sQWToSECwBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABAcUWTvwdBAA8AAAA PAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAHFFk5UFQoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxRZOPB8JAGoAAABqAAAAMzMAAAAJwgkXUAAAht1u AAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAA AAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAQvFFk7MrgIAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVxRZO /B0EADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAF8UWThy/CwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB7FFk5k4wMAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhxRZO 5OUNAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAA AABAASnFFk4MLQgAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtxRZO9LMHADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALsUWTpz9CwCXAQAAlwEA AAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwg MzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUp VDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cu Y2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5 c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFt AAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5Q AAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAAp AAkABAALAAUAMcUWTtTWCQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADbFFk6k5AgAVgAAAFYAAAAzMwAAAAnCCBdQAACG 3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATzFFk6EQwEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8xRZOrE4FAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAUHFFk60dgwAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABJxRZOZGYDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVsUWTmTjAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFjFFk7cvQYAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABexRZO7MwKAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAV/FFk5sTQAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkxRZOBAUBADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa8UWTszv DAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAG7FFk5M7QIAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAAB AAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVS UFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRl Y2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmln aHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1B cHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAA AAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAA AgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAG7FFk6sTgUAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABv xRZO3L0GAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAW/FFk5MLg0AVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAXbFFk4U FAUAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAHjFFk58IA4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB/xRZORAYGADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gcUWTmSnDQB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqA AAAAACAAAAAAAAAAAAAAAAAAAACDxRZO7IsAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAisUWTqRnCABqAAAAagAAADMz AAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA NFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGLxRZOzK4CADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAkcUWTjwfCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJjFFk7MrgIAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChxRZOpGcIADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAp8UWTmRmAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKjFFk48nAkAVgAAAFYAAAAzMwAAAAnCCBdQAACG 3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAA AAAAAAAAAAAAAAAAAABAAanFFk7siwAAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAA AAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAA AABAATAAAAAAAAAAAAAAAAAAAAAAAEABq8UWTmyOCgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoD AAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3 MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdB UkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBw b3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGls ZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJ AAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAA AAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUArsUWTiSmCAA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAALvFFk68XQkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC9xRZOfCAOADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyMUWTjycCQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAM7FFk6EBwsAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADA CRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAA AAAAAAAAAAAAAAAAAAAAAEAB08UWTrQ1AgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANPFFk4UlwQAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADc xRZO5OUNADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA58UWThy/CwBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+ gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAA AAAAAEAB6cUWTmyOCgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOnFFk6EBwsAPAAAADwAAADCCBdQAADCCBdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADpxRZOFNgOAGoAAABq AAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJ AgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAe3FFk48 HwkAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAPDFFk70swcAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD0xRZOfCAOAJcBAACXAQAAAQAM zMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQD8xRZO3L0GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/sUWToSECwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnGFk6svwcAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAOxhZOrE4FAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAQ7GFk5MLg0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUxhZOdHUHADwAAAA8AAAAwggXUAAAwggX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGcYWTqRn CAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACTGFk6UFg8AVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA ASbGFk6EhAsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAqxhZOhAcLAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAASrGFk5UCQwAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArxhZOhEMBAJcB AACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQArxhZO5KQDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN8YWTuTlDQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD7GFk7s zAoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA/xhZOrMsFAHYAAAB2AAAAMzMAAAABwggXUAAAht1uAAAAAEA6//6AAAAA AAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN80AABwgAAAAAAAAAAAEBwggXUAAABQEAAAAA BdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAEDGFk7M7wwAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBxhZO lNUEAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAA AABAAUrGFk40tQwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUxhZOZOMDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVMYWTqzLBQB2AAAAdgAA ADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYA TfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAA AAAAAABXxhZOzGwNADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXsYWTpTVBABWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAA AAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAA AAAAAAAAAAAAAEABY8YWTjS1DABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAA AMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB MAAAAAAAAAAAAAAAAAAAAAAAQAFkxhZOlBYPADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAacYWTiSmCAA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AG/GFk4c+wEAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNj byBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwg VmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBw b3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYt MjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6Mjcg YnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbd ABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRo ZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAHDGFk7M7wwAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1xhZO1BIAAJcBAACX AQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJl LCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgx NSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3 dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28g U3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3Rl YW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf/ /lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAA ACkACQAEAAsABQB9xhZOnP0LADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfsYWTuxPCgA8AAAAPAAAAMIIF1AAAMIIF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIfGFk4sjQUA agAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB icYWTsyuAgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAJLGFk60NQIAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUxhZOhEMBAFYAAABWAAAAMzMA AAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAg xbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAGWxhZOhEMBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo8YWTpy8AQA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAKbGFk4c+wEAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACrxhZO1NYJAGoAAABqAAAAMzMAAAAJwgkXUAAAht1u AAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAA AAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAbDGFk7kpAMAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2xhZO FJcEAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9T IFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNp b24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDog aHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDgg YnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHBy b2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAA AAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0 MC8wAAQACAAAACkACQAEAAsABQC3xhZOHH4BADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAu8YWTrR2DAA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AMTGFk40dAIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADJxhZO5OUNAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAc/GFk7szAoAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUxhZOzCsDADwA AAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA1MYWTvwdBABWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAI F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB1sYW Tlx/BgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAOPGFk6k5AgAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADlxhZOjO4HAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAenGFk4UlwQAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADwxhZOpOQIADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8sYWTqxOBQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoD AAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3 MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdB UkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBw b3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGls ZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJ AAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAA AAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA8sYWTmSnDQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAPTGFk7szAoAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZS MQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJ U0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2hu aWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQg KGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHIt MDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAAC CKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQAD ABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAPjGFk60dgwATQAAAE0AAACrAAACAADC CRdQAABgAj0ABwAAAAEAAwMAAAIAAiEAAwAGAAAAAAAABAACPAAFAALYBQYAAgABBwAGwgkXUAAA ZAABeZABAQGRAQLuBf7GFk6sywUAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAA AADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABA ATAAAAAAAAAAAAAAAAAAAAAAAEAB/sYWTvSzBwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7GFk6kZwgAPAAAADwAAADC CBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAHxxZOZOMDAE0AAABNAAAAqwAAAgAAwggXUAAAYAI9AAcAAAABAAMDAAACAAIhAAMABgAAAAAA AAQAAjwABQAC2AUGAAIAAQcABsIIF1AAAGQAAXmQAQEBkQEC7gUJxxZOHH4BADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FccWTsxsDQBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABFccWTuTlDQA8AAAA PAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABbHFk4EBQEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcxxZO/F4OAGoAAABqAAAAMzMAAAAJwgkXUAAAht1u AAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAA AAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAR3HFk6M7gcAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnxxZO /B0EADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAK8cWTszvDAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADHHFk5c/AYAlwEAAJcBAAABAAzMzMzC CRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29m dHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxF QVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNv bS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJ bmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNj byAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMA AACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAF ADHHFk70swcAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6 gAAAAAAgAAAAAAAAAAAAAAAAAAAAMccWTuxPCgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADLHFk7sTwoAagAAAGoAAAAz MwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABO8cWToRDAQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEDHFk4ERgsAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIxxZOnLwBADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATccWTsREBgBW AAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABVMcWTlx/BgA8AAAAPAAAAMIIF1AA AMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFXH Fk78HQQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABZxxZOfJ0OAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6A AAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAA AAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAWLHFk4UFAUAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqxxZO7E8KADwAAAA8 AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAb8cWTsREBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHbHFk6k5AgAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqq AwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMz NzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRX QVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3Vw cG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBp bGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIA SQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAA AAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAHnHFk6k5AgA lwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29m dHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAx Mi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRw Oi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBD aXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9y ZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAA AMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAA BAAIAAAAKQAJAAQACwAFAHzHFk5c/AYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8xxZO7EkLAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAX3HFk4MLQgAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACAxxZOzK4CADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiscWTlx/BgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJDHFk40dAIAVgAAAFYA AAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkC CQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAZPHFk4kpggAagAAAGoAAAAzMwAAAAnCCRdQ AACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAg AAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABl8cWTlx/BgA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AJfHFk5UFQoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACgxxZOpGcIADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArccWTjR0AgA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AK3HFk48HwkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAC1xxZOPJwJAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAbfHFk6EhAsAlwEAAJcBAAABAAzMzMzCCRdQAAAB iaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUg KEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNP RlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNo c3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNv bXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1 AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQ IAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFALrHFk6k ZwgAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADFxxZObL4CADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAx8cWThz7AQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMvHFk5s jgoAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAdLHFk5k4wMAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADYxxZOXH8GAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/ AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAA AAAAAAAAAABAAdvHFk7U0AoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADdxxZOpOQIADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA48cWTuSkAwA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAPDHFk6U1QQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwxxZObI4KAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAfHHFk5c/AYAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADz xxZOfFwEAHYAAAB2AAAAMzMAAAABwggXUAAAht1uAAAAAEA6//6AAAAAAAAAwAgX//5QAAD/AgAA AAAAAAAAAAAAAAABhgBN80AABwgAAAAAAAAAAAEBwggXUAAABQEAAAAABdwDBEDAACeNAAAJOoAA AAAAIAAAAAAAAAAAAAAAAAAAAPXHFk4c+wEAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAA ArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFE VkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChm YzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApD b3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdl ZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMB AcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAA AAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAPjHFk7UEgAAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD7xxZOBEYLAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8 Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzkt TSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwg U3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAx OTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4 OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMA AACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFz dEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQAFyBZOBAUBADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsgWTtQSAAA8 AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAjIFk7siwAAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADA CBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAQ3I Fk68XQkAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAA AAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAA AAAAAEABDcgWTmSnDQB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAn jQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAAAOyBZOfFwEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG8gWTqzLBQA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABvIFk4MLQgAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfyBZONLUMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIsgWTnwgDgBqAAAA agAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEryBZO lBYPADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAM8gWTuxPCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADbIFk5M7QIAlwEAAJcBAAABAAzMzMzC CRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29m dHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxF QVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNv bS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJ bmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNj byAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMA AACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAF ADbIFk7cvQYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA+yBZOzGwNADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQMgWTrxdCQBWAAAAVgAAADMz AAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA IMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABQMgWTmSnDQBqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFHyBZO/F4OADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASMgW TjwfCQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAFXIFk40tQwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABeyBZO3L0GADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXsgW TvxeDgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAA AAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAA AAAAQAFgyBZOBEYLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbcgWTjQ4DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHbIFk50dQcAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB2yBZOpOQIAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8 Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzkt TSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwg U3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAx OTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4 OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMA AACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFz dEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQB2yBZONDgMADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd8gWTjR0AgBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAF4 yBZO5OUNADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAf8gWThx+AQCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAAC tCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURW RU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZj NCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNv cHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2Vk IDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEB zAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAA AAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAgMgWTjQ4DABWAAAAVgAA ADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABg8gWTqRnCAA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIrIFk5MLg0A PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACQyBZOpOQIADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAk8gWTqTkCABqAAAAagAAADMzAAAACcIJF1AA AIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAA AAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGXyBZOhAcLADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA oMgWTnydDgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAKTIFk60dgwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACvyBZO7IsAAJcBAACXAQAAAQAM zMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQCxyBZOXPwGADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAscgWTiSmCABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAG1yBZOhEMBADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtcgWTnwg DgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAALvIFk4UFAUAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA Ab/IFk78Xg4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADMyBZOtHYMAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAczIFk7k5Q0APAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMyBZOfBoPADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA08gWTmRmAwB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRA wAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAADUyBZOhAcLADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2cgWTsyuAgA8 AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAOHIFk40OAwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADqyBZOtDUCAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAezIFk6ExgAAlwEAAJcBAAABAAzM zMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAg U29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBS RUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2Nv LmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1z LCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5D aXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiq qgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQA CwAFAOzIFk5sygAAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAA AP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAezIFk40dAIA PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADsyBZOfFwEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8sgWTvwdBAA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPXIFk40tQwA lwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29m dHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAx Mi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRw Oi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBD aXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9y ZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAA AMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAA BAAIAAAAKQAJAAQACwAFAPvIFk7M7wwAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByRZOFJcEADwAAAA8AAAAwggXUAAA wggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8kW Tpx6DABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAA AAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAA AAAAQAEIyRZOFNgOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFskWThx+AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABbJFk6sywUAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAjyRZOBAUBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKMkWTsxsDQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEryRZOHPsBAFYAAABWAAAAMzMAAAAJwggX UAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAA IAAAAAAAAAAAAAAAAAAAAAAAQAEsyRZOPB8JAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwg AAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1B RFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAo ZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQK Q29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBX ZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAAD AQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAA AAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQAsyRZO5OUNADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAALskWTnwgDgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADrJFk6ExgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFyRZOLI0FADwAAAA8 AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAR8kWTmxNAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEnJFk7MrgIAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4A AAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAA AAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABVMkWThz7AQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF3JFk5c /AYAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABhyRZOtDUCADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZckWTgykCQBWAAAAVgAAADMzAAAACcII F1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABaskWTuzMCgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0 Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAA AAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFqyRZO/F4OADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcMkWTkwuDQA8 AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHLJFk5cfwYATQAAAE0AAACrAAACAADCCRdQAABgAj0ABwAAAAEAAwMAAAIAAiEA AwAGAAAAAAAABAACPAAFAALYBQYAAgABBwAGwgkXUAAAZAABeZABAQGRAQLuBXLJFk6k5AgAlwEA AJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdh cmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40 KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8v d3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNj byBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxf dGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJ F//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAI AAAAKQAJAAQACwAFAHXJFk4UFAUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8yRZO/B0EAJcBAACXAQAAAQAMzMzMwggX UAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3 YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFT RSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20v dGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5j LgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28g MzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAA ht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQCC yRZOTO0CADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAhskWTmTjAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAInJFk58IA4AagAAAGoAAAAzMwAA AAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRV igIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABj8kWTkztAgA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJvJFk58nQ4APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcyRZOLI0FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnskWTuzMCgB2AAAA dgAAADMzAAAAAcIIF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAA AYYATfNAAAcIAAAAAAAAAAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAA AAAAAAAAAACiyRZOvF0JAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX //5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAGnyRZO hEMBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAqskWTmxNAABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAGwyRZONHQCADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtMkWTjR0AgA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAL7JFk6sTgUAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxD aXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1N KSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBT dXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5 ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6 MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAA AIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0 RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAL7JFk4MLQgAdgAAAHYAAAAzMwAAAAHCCRdQAACG 3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAA AQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAAvskWTpQ6CQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAMPJFk7U1gkAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADHyRZOFJcEADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyckWTnydDgBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHP yRZO7MwKADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA18kWTjR0AgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANnJFk7MrgIAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADb yRZOXH8GAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAHhyRZORAYGADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA4skWTqzLBQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAA AAAAAAAAAAAAAAAAQAHuyRZO3L0GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA78kWTvxeDgA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPPJFk4U lwQAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAPTJFk58IA4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD6yRZOHPsBAJcBAACXAQAAAQAM zMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQD+yRZO9DAIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAQDKFk68XQkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEyhZONLUMADwAAAA8AAAAwggXUAAAwggX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMoWTuyL AAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABTKFk78Xg4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbyhZOVBUKAGoAAABqAAAAMzMAAAAJwgkX UAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAA IAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAARvKFk7k5Q0AVgAAAFYAAAAz MwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAARvKFk7k5Q0APAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdyhZOzCsDADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKsoWTmTjAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC7KFk4UlwQAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0yhZOXH8GAJcB AACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQA0yhZOVAMNADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANMoWTvxeDgBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAE8yhZO1NYJADwAAAA8AAAA wgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAPsoWTpQWDwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEnKFk5UFQoAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQyhZOnP0LAFYAAABWAAAA MzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkC CQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAFSyhZODC0IADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVsoWTjwfCQBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFW yhZOzAEKADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAWMoWTmSnDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGTKFk50dQcAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABl yhZOfCAOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAb8oWTuzMCgCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAAC tCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURW RU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZj NCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNv cHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2Vk IDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEB zAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAA AAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAb8oWTjS1DACXAQAAlwEA AAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwg MzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUp VDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cu Y2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5 c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFt AAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5Q AAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAAp AAkABAALAAUAb8oWTkwuDQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAA AAAAAAAAAAAAAAAAAAAAQAFwyhZOhMYAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAecoWTtQSAAA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHrK Fk5sjgoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACFyhZOzO8MAHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6A AAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEA AAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAIXKFk58nQ4APAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJ yhZOHH4BAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAYzKFk4sjQUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMyhZONLUMAFYAAABWAAAAMzMAAAAJwggXUAAAht1u AAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAA AAAAAAAAAAAAAAAAQAGQyhZO7E8KADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlcoWTqxOBQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKLKFk5c fwYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACoyhZOFNgOADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqsoWTqxOBQBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGqyhZOPB8JAJcBAACXAQAA AQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAz NzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlU NSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5j aXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lz dGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0A BgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAA AAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkA CQAEAAsABQCqyhZOtHYMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAt8oWTuSkAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALrKFk6UFg8APAAA ADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADEyhZOfFwEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxMoWTiyNBQBWAAAAVgAAADMzAAAACcIIF1AAAIbd bgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAA AAAAAAAAAAAAAAAAAEABx8oWThx+AQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAHQyhZOZOMDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0coWTsyuAgA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAN7KFk7MKwMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADoyhZOdHUHADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA68oWTkztAgBqAAAAagAA ADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHryhZOfFwE ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA7coWThx+AQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEA BlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQ UklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVj aG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdo dCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFw ci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAA AAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAAC AAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA78oWTsREBgA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPHK Fk7k5Q0AlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJ T1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVy c2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0 OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAw OCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkg cHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+ gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJu ZXQwLzAABAAIAAAAKQAJAAQACwAFAPzKFk6M7gcAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD8yhZOzO8MADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAcsWTqzLBQBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA /wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABAssWTgRGCwBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAED yxZOhEMBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAD8sWTmSnDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABHLFk4UFAUAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd yxZOnLwBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAI8sWTozuBwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+ gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAA AAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEjyxZONLUMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJssWTqTkCAA8AAAA PAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACrLFk7MKwMAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAF APxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VL OS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNh bCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMp IDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDgg MTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqq AwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNG YXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFACrLFk6UFg8APAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1yxZOPB8J AFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAA AAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAE2yxZOhIQLADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA OssWTlx5BwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAADzLFk60sgIAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH/ /oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAA AAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABPssWTrQ1AgB2AAAAdgAAADMzAAAAAcIIF1AAAIbd bgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfNAAAcIAAAAAAAAAAAB AcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAABDyxZONLUMADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUMsWTkwuDQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFLLFk4c+wEAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABdyxZO5OUNADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAXssWTqxOBQB2AAAAdgAAADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRA wAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAABfyxZOFNgOAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAWbLFk6M7gcAPAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABn yxZO7E8KADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAbssWTlQVCgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+ gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAA AAAAAEABcMsWTuTlDQCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA /ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5 LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2Fs IFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykg MTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAx ODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoD AAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zh c3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAccsWTmSnDQCXAQAAlwEAAAEADMzMzMIJF1AA AAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2Fy ZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0Ug U09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3Rl Y2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4K Q29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3 MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbd ABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAdMsW Thy/CwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHnLFk5kHg8APAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB/yxZOpOQIAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAX/LFk4cvwsAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACLyxZONHQCADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjMsWTjwfCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJDLFk5EBgYAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACUyxZO1NYJAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAZvLFk6sTgUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChyxZO3L0GADwAAAA8AAAAwggXUAAAwggX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqMsWTgwt CAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKrLFk78HQQAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA AbLLFk6c/QsAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNj byBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwg VmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBw b3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYt MjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6Mjcg YnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbd ABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRo ZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFALXLFk7U1gkAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5yxZOFBQFADwAAAA8 AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAussWTjS1DABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAA AAAAAAAAAAAAAAAAQAHCyxZOBAUBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAz8sWTrQ1AgA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDLFk7M KwMAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADTyxZOHPsBAE0AAABNAAAAqwAAAgAAwgkXUAAAYAI9AAcAAAABAAMDAAAC AAIhAAMABgAAAAAAAAQAAjwABQAC2AUGAAIAAQcABsIJF1AAAGQAAXmQAQEBkQEC7gXUyxZOpOQI AE0AAABNAAAAqwAAAgAAwggXUAAAYAI9AAcAAAABAAMDAAACAAIhAAMABgAAAAAAAAQAAjwABQAC 2AUGAAIAAQcABsIIF1AAAGQAAXmQAQEBkQEC7gXcyxZOzK4CADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4MsWTmRmAwBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHg yxZO/F4OADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA5csWTswrAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOvLFk4sjQUAVgAAAFYAAAAzMwAA AAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDF tAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAevLFk50dQcAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwyxZOBAUBAJcBAACX AQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJl LCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgx NSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3 dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28g U3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3Rl YW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf/ /lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAA ACkACQAEAAsABQD1yxZO7E8KAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAG UjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBS SVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNo bmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0 IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXBy LTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAA AgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIA AwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQD4yxZOHPsBAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAfjLFk7kpAMAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD4yxZORAAHADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/csWTpz9CwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArMFk4cuQwAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAQzBZO5KQDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFswWTjS1DABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEWzBZO/NsOADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHMwWTpy8 AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACbMFk7sTwoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApzBZOnLwBADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKcwWThQU BQBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMMwWThQUBQBqAAAAagAAADMz AAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA NFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAEzzBZORAYGAJcB AACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQA2zBZO5KQDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN8wWTqxOBQB2AAAAdgAAADMzAAAAAcIJ F1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfFAAAcIAAAA AAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAAA7zBZO lFIFADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAQ8wWThSXBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE/MFk6EBwsAPAAAADwAAADCCBdQAADC CBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQzBZO rE4FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAUcwWTszvDABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAFVzBZOfCAOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYswWTgQFAQBWAAAAVgAA ADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABYswWThTYDgA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGPMFk4kpggA PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABvzBZOpGcIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAA wAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEw AAAAAAAAAAAAAAAAAAAAAABAAXDMFk6ExgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwzBZONDgMAJcBAACXAQAAAQAM zMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQBxzBZO7MwKAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8 Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzkt TSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwg U3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAx OTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4 OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMA AACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFz dEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQB0zBZOPB8JADwAAAA8AAAAwgkXUAAAwgkXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeswWTpQWDwA8 AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAIHMFk6kZwgAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIzBZOxEQGAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAYnMFk7kpAMAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQ zBZO3L0GADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAk8wWTiSmCAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKDMFk68XQkAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACj zBZOpGcIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAaTMFk40tQwAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAabMFk4U FAUAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACszBZO9DYHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAr8wWTqxOBQCXAQAAlwEAAAEADMzMzMIJ F1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0 d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVB U0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29t L3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIElu Yy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2Nv IDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAA AIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA sswWTmRmAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAL3MFk5k4wMAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+zBZOBEYLADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA vswWTkwuDQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAHGzBZOhEMBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0cwWToQHCwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANPMFk7siwAAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADgzBZOBAUBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4MwWToQHCwBqAAAAagAAADMzAAAACcIJF1AAAIbd bgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAA AAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHizBZOzK4CAFYAAABWAAAAMzMAAAAJ wggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAHkzBZOFJcEADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5cwWTlx/BgA8AAAAPAAA AMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAOrMFk4EBQEAdgAAAHYAAAAzMwAAAAHCCBdQAACG3W4AAAAAQDr//oAAAAAAAADACBf//lAA AP8CAAAAAAAAAAAAAAAAAAGGAE3zQAAHCAAAAAAAAAAAAQHCCBdQAAAFAQAAAAAF3AMEQMAAJ40A AAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAA7swWTvQ2BwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoD AAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3 MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdB UkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBw b3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGls ZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJ AAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAA AAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA7swWTkwuDQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAO/MFk4cvwsAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZS MQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJ U0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2hu aWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQg KGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHIt MDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAAC CKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQAD ABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAPjMFk7M7wwAPAAAADwAAADCCBdQAADC CBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5zBZO LI0FADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA+cwWTlz8BgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAEDzRZOnLwBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABM0WTmSnDQB2AAAAdgAA ADMzAAAAAcIJF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYA TfFAAAcIAAAAAAAAAAABAcIJF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAA AAAAAAAMzRZOHL8LADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM0WTjQ4DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABjNFk6sywUAagAAAGoA AAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkC CQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABGc0WTkwu DQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAB7NFk4cvwsAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA ASPNFk4MLQgAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAmzRZOtHYMADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMc0WThx+AQCXAQAAlwEAAAEA DMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcw MCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUs IFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lz Y28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3Rl bXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYA DkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAAC CKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkA BAALAAUAM80WTnwgDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADjNFk5EBgYAPAAAADwAAADCCBdQAADCCBdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5zRZOzO8MAGoAAABq AAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJ AgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAUHNFk60 sgIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABOzRZO5KQDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUM0WThSXBAA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFbNFk4s jQUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABYzRZOFNgOAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAA AAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAA QAEwAAAAAAAAAAAAAAAAAAAAAABAAWDNFk7ctwcAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAA IBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAA AAAAAAAAAABAAWPNFk70swcAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnzRZOpGcIADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcM0WTqTkCAA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHLNFk6UTAYAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZS MQAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJ U0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2hu aWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQg KGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHIt MDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAAC CKqqAwAAAIbdABD+gAAAAAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQAD ABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAHrNFk7MbA0AlwEAAJcBAAABAAzMzMzC CRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29m dHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxF QVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNv bS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJ bmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNj byAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMA AACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAF AHzNFk6M7gcAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAA AAAAAAAAAEABfM0WTtTWCQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH3NFk5c/AYAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACKzRZOvF0JADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAkc0WTuTlDQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJfNFk48nAkAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACezRZOHPsBAFYA AABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAA AAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAGezRZOLI0FAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAaHNFk48nAkAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAClzRZOBAUBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArs0WTuzMCgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALrNFk4c+wEAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAC7zRZOhIQLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwM0WThz7AQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHDzRZOfFwEAJcBAACXAQAAAQAMzMzMwgkX UAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3 YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFT RSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20v dGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5j LgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28g MzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAA ht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQDG zRZOTO0CADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA0M0WTsREBgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANPNFk5kZgMAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADc zRZOnP0LAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAHgzRZOTO0CAGoAAABq AAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJ AgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAeDNFk5k ZgMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADmzRZO9LMHADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7c0WTgQFAQA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPHNFk40 dAIAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAPHNFk7MbA0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADzzRZOZOMDAHYAAAB2AAAAMzMA AAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAA BwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAA APrNFk40OAwAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD8zRZOTC4NAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAf3NFk4cfgEAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEzhZO3L0GAJcB AACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQAHzhZOFBQFADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADs4WTjwfCQA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABPOFk60 NQIAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAARTOFk4sjQUAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAbzhZOpGcIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/ AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAA AAAAAAAAAABAAR7OFk5M7QIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkzhZOhEMBADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK84WTjwfCQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADfOFk5cfwYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6zhZO5KQDADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO84WTpy8AQBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFD zhZOhEMBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAASs4WTkztAgCXAQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAAC tB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURW RU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZj NCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNv cHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2Vk IDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEB zAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAA AAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUASs4WTsxsDQBNAAAATQAA AKsAAAIAAMIJF1AAAGACPQAHAAAAAQADAwAAAgACIQADAAYAAAAAAAAEAAI8AAUAAtgFBgACAAEH AAbCCRdQAABkAAF5kAEBAZEBAu4FTc4WTgQFAQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE/OFk6U1QQA5gUAAOYFAADC CRdQAADCCBdQAACG3WAAAAAFsCxAIAAAAAAAAAAAAAAAAAAAATAAAAAAAAAAAAAAAAAAAAI6AAAB AAAAAYAA+WwJ5gAAAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKiss LS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2Rl ZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2e n6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX 2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8Q ERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJ SktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGC g4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7 vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP0 9fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywt Li8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVm Z2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6f oKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY 2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAR EhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElK S0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKD hIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8 vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T1 9vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0u LzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZn aGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+g oaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ 2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBES ExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpL TE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOE hYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6fT84WTpTVBADmBQAA5gUAAMIJF1AAAMIIF1AAAIbd YAAAAAWwLEAgAAAAAAAAAAAAAAAAAAABMAAAAAAAAAAAAAAAAAAAAjoABakAAAABoKGio6Slpqeo qaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh 4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBka GxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJT VFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouM jY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TF xsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+ /wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3 ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9w cXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ip qqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi 4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob HB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNU VVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yN jo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXG x8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/ AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4 OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3Bx cnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmq q6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj 5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhsc HR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RV VldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2O j5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbH yMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8A AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5 Ojs8PT4/QEFCQ0RFRkdPzhZOxEQGAH4AAAB+AAAAwgkXUAAAwggXUAAAht1gAAAAAEgsQCAAAAAA AAAAAAAAAAAAAAEwAAAAAAAAAAAAAAAAAAACOgALUAAAAAFISUpLTE1OT1BRUlNUVVZXWFlaW1xd Xl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHUM4WTiSmCABWAAAAVgAA ADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABUs4WTkztAgA8AAAAPAAAAMIIF1AAAMIIF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFTOFk7sTwoA agAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAA AAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB VM4WThTYDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAFjOFk58nQ4AVgAAAFYAAADCCRdQAADCCBdQAACG3W4AAAAAIDr/ /oAAAAAAAADACBf//lAAAP6AAAAAAAAAwAkX//5QAACHAB+8AAAAAP6AAAAAAAAAwAkX//5QAAAB AcIIF1AAAFnOFk6ExgAATgAAAE4AAADCCBdQAADCCRdQAACG3W4AAAAAGDr//oAAAAAAAADACRf/ /lAAAP6AAAAAAAAAwAgX//5QAACIADkdwAAAAP6AAAAAAAAAwAkX//5QAABfzhZO1BIAAFYAAABW AAAAwggXUAAAwgkXUAAAht1uAAAAACA6//6AAAAAAAAAwAkX//5QAAD+gAAAAAAAAMAIF//+UAAA hwAfvAAAAAD+gAAAAAAAAMAIF//+UAAAAQHCCRdQAABfzhZO7AICAE4AAABOAAAAwgkXUAAAwggX UAAAht1uAAAAABg6//6AAAAAAAAAwAgX//5QAAD+gAAAAAAAAMAJF//+UAAAiAA5HsAAAAD+gAAA AAAAAMAIF//+UAAAYM4WTgRYCAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGjOFk7M7wwAPAAAADwAAADCCBdQAADCCBdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqzhZOTO0C AOYFAADmBQAAwgkXUAAAwggXUAAAht1gAAAABbAsQCAAAAAAAAAAAAAAAAAAAAEwAAAAAAAAAAAA AAAAAAACOgAAAQAAAAKAAPSrDqcAAAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEi IyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpb XF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOU lZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zN zs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUG BwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/ QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4 eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7Cx srO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq 6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIj JCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltc XV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SV lpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3O z9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYH CAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9A QUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5 ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGy s7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err 7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMk JSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xd Xl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWW l5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P 0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcI CQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BB QkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6 e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en2rOFk4UlwQA5gUAAOYFAADCCRdQ AADCCBdQAACG3WAAAAAFsCxAIAAAAAAAAAAAAAAAAAAAATAAAAAAAAAAAAAAAAAAAAI6AAWpAAAA AqChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX 2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8Q ERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJ SktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGC g4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7 vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP0 9fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywt Li8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVm Z2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6f oKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY 2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAR EhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElK S0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKD hIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8 vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T1 9vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0u LzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZn aGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+g oaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ 2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBES ExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpL TE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOE hYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9 vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX2 9/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4v MDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHas4WThSXBAB+AAAAfgAAAMIJF1AAAMIIF1AAAIbdYAAA AABILEAgAAAAAAAAAAAAAAAAAAABMAAAAAAAAAAAAAAAAAAAAjoAC1AAAAACSElKS0xNTk9QUVJT VFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh2rOFk7U 1gkAVgAAAFYAAAAzM/8AAAHCCRdQAACG3W4AAAAAIDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAA AAAAAf8AAAGHAKtoAAAAACAAAAAAAAAAAAAAAAAAAAEBAcIJF1AAAGrOFk4cvwsAVgAAAFYAAADC CRdQAADCCBdQAACG3W4AAAAAIDr/IAAAAAAAAAAAAAAAAAAAAf6AAAAAAAAAwAkX//5QAACIAKdt 4AAAACAAAAAAAAAAAAAAAAAAAAECAcIIF1AAAGrOFk5MLg0A5gUAAOYFAADCCBdQAADCCRdQAACG 3WAAAAAFsCw/MAAAAAAAAAAAAAAAAAAAAiAAAAAAAAAAAAAAAAAAAAE6AAWpAAAAAaChoqOkpaan qKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g 4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFS U1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPE xcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9 /v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2 Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5v cHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqeo qaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh 4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBka GxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJT VFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouM jY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TF xsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+ /wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3 ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9w cXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ip qqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi 4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob HB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNU VVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yN jo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXG x8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/ AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4 OTo7PD0+P0BBQkNERUZHas4WTmSnDQB+AAAAfgAAAMIIF1AAAMIJF1AAAIbdYAAAAABILD8wAAAA AAAAAAAAAAAAAAACIAAAAAAAAAAAAAAAAAAAAToAC1AAAAABSElKS0xNTk9QUVJTVFVWV1hZWltc XV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh23OFk7sSQsAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB0zhZOzGwNAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8 Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzkt TSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwg U3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAx OTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4 OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMA AACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFz dEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQB2zhZO1BIAAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAXbOFk5cfwYAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB+ zhZOrE4FADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAfs4WTpQWDwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAInOFk7MrgIAlwEAAJcBAAABAAzM zMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAg U29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBS RUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2Nv LmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1z LCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5D aXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiq qgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQA CwAFAInOFk48HwkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACLzhZOZGYDAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAA ADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAA AAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAZDOFk5sjgoAVgAAAFYAAAAzMwAAAAnCCBdQ AACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAg AAAAAAAAAAAAAAAAAAAAAABAAZHOFk6c/QsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACSzhZOJKYIADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA mM4WTsyoAwB2AAAAdgAAADMzAAAAAcIIF1AAAIbdbgAAAABAOv/+gAAAAAAAAMAIF//+UAAA/wIA AAAAAAAAAAAAAAAAAYYATfNAAAcIAAAAAAAAAAABAcIIF1AAAAUBAAAAAAXcAwRAwAAnjQAACTqA AAAAACAAAAAAAAAAAAAAAAAAAACbzhZOnP0LADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAps4WTjR0AgA8AAAAPAAAAMII F1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKnOFk7UEgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACszhZO1BIAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAa/OFk5sTQAAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5zhZOnP0LADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAvc4WThx+AQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMPOFk4U2A4AlwEAAJcBAAABAAzMzMzCCRdQAAAB iaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUg KEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNP RlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNo c3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNv bXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1 AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQ IAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAMbOFk6k ZwgAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADJzhZOzK4CAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAA AAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAA QAEwAAAAAAAAAAAAAAAAAAAAAABAAcnOFk5cfwYAdgAAAHYAAAAzMwAAAAHCCRdQAACG3W4AAAAA QDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQ AAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAAys4WTswrAwDmBQAA5gUA AMIJF1AAAMIIF1AAAIbdYAAAAAWwLEAgAAAAAAAAAAAAAAAAAAABMAAAAAAAAAAAAAAAAAAAAjoA AAEAAAADgADxLxIjAAAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkq KywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJj ZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpuc nZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV 1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0O DxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZH SElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+A gYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5 uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy 8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSor LC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNk ZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5yd np+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW 19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4P EBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdI SUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CB goOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6 u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz 9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKiss LS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2Rl ZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2e n6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX 2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8Q ERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJ SktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGC g4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp/KzhZO/B0EAOYFAADmBQAAwgkXUAAAwggXUAAA ht1gAAAABbAsQCAAAAAAAAAAAAAAAAAAAAEwAAAAAAAAAAAAAAAAAAACOgAFqQAAAAOgoaKjpKWm p6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f 4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcY GRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BR UlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImK i4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLD xMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8 /f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1 Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1u b3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaan qKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g 4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFS U1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPE xcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9 /v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2 Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5v cHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqeo qaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh 4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBka GxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJT VFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouM jY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TF xsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+ /wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3 ODk6Ozw9Pj9AQUJDREVGR8rOFk4UlwQAfgAAAH4AAADCCRdQAADCCBdQAACG3WAAAAAASCxAIAAA AAAAAAAAAAAAAAAAATAAAAAAAAAAAAAAAAAAAAI6AAtQAAAAA0hJSktMTU5PUFFSU1RVVldYWVpb XF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhofKzhZOJKYIAOYFAADm BQAAwggXUAAAwgkXUAAAht1gAAAABbAsPzAAAAAAAAAAAAAAAAAAAAIgAAAAAAAAAAAAAAAAAAAB OgAAAQAAAAKBAPAvEiMAAAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJico KSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2Bh YmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJma m5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT 1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsM DQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RF RkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+ f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3 uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w 8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygp KissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFi Y2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqb nJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU 1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwN Dg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVG R0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/ gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4 ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx 8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkq KywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJj ZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpuc nZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV 1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0O DxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZH SElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+A gYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en8rOFk68XQkA5gUAAOYFAADCCBdQAADCCRdQ AACG3WAAAAAFsCw/MAAAAAAAAAAAAAAAAAAAAiAAAAAAAAAAAAAAAAAAAAE6AAWpAAAAAqChoqOk paanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd 3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUW FxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5P UFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeI iYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DB wsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6 +/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIz NDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamts bW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Sl pqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e 3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYX GBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9Q UVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJ iouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHC w8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7 /P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0 NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xt bm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f 4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcY GRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BR UlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImK i4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLD xMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8 /f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1 Njc4OTo7PD0+P0BBQkNERUZHys4WTmyOCgB+AAAAfgAAAMIIF1AAAMIJF1AAAIbdYAAAAABILD8w AAAAAAAAAAAAAAAAAAACIAAAAAAAAAAAAAAAAAAAAToAC1AAAAACSElKS0xNTk9QUVJTVFVWV1hZ WltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh8rOFk6EhAsAVgAA AFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAcrOFk60dgwA5gUAAOYFAADCCRdQAADC CBdQAACG3WAAAAAFsCxAIAAAAAAAAAAAAAAAAAAAATAAAAAAAAAAAAAAAAAAAAI6AAABAAAABIAA MmUSIwABAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIz NDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamts bW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Sl pqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e 3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYX GBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9Q UVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJ iouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHC w8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7 /P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0 NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xt bm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f 4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcY GRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BR UlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImK i4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLD xMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8 /f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1 Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1u b3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaan qKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g 4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFS U1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJmam5ydnp+gys4WTsxsDQDmBQAA5gUAAMIJF1AAAMIIF1AAAIbdYAAAAAWw LEAgAAAAAAAAAAAAAAAAAAABMAAAAAAAAAAAAAAAAAAAAjoABakAAAAEoaKjpKWmp6ipqqusra6v sLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo 6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh IiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFla W1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvM zc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQF BgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+ P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3 eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+w sbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp 6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEi IyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpb XF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOU lZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zN zs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUG BwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/ QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4 eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7Cx srO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq 6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIj JCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltc XV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SV lpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3O z9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYH CAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9A QUJDREVGR0jKzhZO/F4OAH4AAAB+AAAAwgkXUAAAwggXUAAAht1gAAAAAEgsQCAAAAAAAAAAAAAA AAAAAAEwAAAAAAAAAAAAAAAAAAACOgALUAAAAARJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNk ZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIy84WTgQFAQDmBQAA5gUAAMIIF1AA AMIJF1AAAIbdYAAAAAWwLD8wAAAAAAAAAAAAAAAAAAACIAAAAAAAAAAAAAAAAAAAAToAAAEAAAAD gQAxZRIjAAEBAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAx MjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlq a2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKj pKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc 3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQV FhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1O T1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaH iImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/A wcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5 +vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEy MzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWpr bG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOk paanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd 3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUW FxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5P UFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeI iYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DB wsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6 +/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIz NDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamts bW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Sl pqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e 3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYX GBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9Q UVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJ iouMjY6PkJGSk5SVlpeYmZqbnJ2en6DLzhZONHQCAOYFAADmBQAAwggXUAAAwgkXUAAAht1gAAAA BbAsPzAAAAAAAAAAAAAAAAAAAAIgAAAAAAAAAAAAAAAAAAABOgAFqQAAAAOhoqOkpaanqKmqq6yt rq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm 5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f ICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldY WVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CR kpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnK y8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQID BAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8 PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1 dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn 6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8g ISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZ WltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGS k5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrL zM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgME BQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9 Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2 d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6v sLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo 6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh IiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFla W1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvM zc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQF BgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+ P0BBQkNERUZHSMvOFk7MKwMAfgAAAH4AAADCCBdQAADCCRdQAACG3WAAAAAASCw/MAAAAAAAAAAA AAAAAAAAAiAAAAAAAAAAAAAAAAAAAAE6AAtQAAAAA0lKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFi Y2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4jNzhZO/F4OADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0M4WTszvDAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAANHOFk5MagMAVgAAAFYAAADCCBdQAADCCRdQAACG3W4AAAAAIDr/ /oAAAAAAAADACRf//lAAACAAAAAAAAAAAAAAAAAAAAGHAIltAAAAACAAAAAAAAAAAAAAAAAAAAEB AcIJF1AAANHOFk4UlwQATgAAAE4AAADCCRdQAADCCBdQAACG3W4AAAAAGDr/IAAAAAAAAAAAAAAA AAAAAf6AAAAAAAAAwAkX//5QAACIAKLPwAAAACAAAAAAAAAAAAAAAAAAAAHXzhZOFBQFADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA484WTkztAgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAA AAAAAAAAAAAAAAAAQAHkzhZOXH8GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5c4WTlQVCgA8AAAAPAAAAMIIF1AAAMII F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOzOFk4M LQgAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADxzhZOZGYDAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUA AQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRF UlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpU ZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJp Z2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAt QXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQA AAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAA AAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQD2zhZOhMABADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA +84WTpz9CwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP7OFk4UlwQAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH/ /oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAA AAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB/s4WTnR1BwCXAQAAlwEAAAEADMzMzMIJF1AAAAGJ qqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAo QzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09G VFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hz dXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29t cGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUA AgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAg AAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA/84WTpy8 AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAnPFk6EBwsAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA AQzPFk7MrgIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAARzxZOhEMBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGc8WThQUBQA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABvPFk70rQgAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8C AAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAA AAAAAAAAAEABJs8WTsREBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACfPFk78Xg4APAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzzxZOpGcIADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAPs8WTqxOBQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/PFk6U1QQAagAAAGoAAAAzMwAAAAnCCRdQAACG 3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAA AAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABP88WTnR1BwA8AAAAPAAAAMIJF1AA AMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEfP Fk7szAoAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAA AAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAU7PFk7ERAYAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABPzxZO9LMHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWM8WTjQ4DABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFazxZOVBUKADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZM8WThx+ AQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGfPFk5kpw0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABvzxZOtHYMAJcBAACXAQAAAQAMzMzMwggX UAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3 YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFT RSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20v dGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5j LgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28g MzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAA ht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQBw zxZOTC4NADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAc88WThx+AQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+ gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAA AAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAF4zxZOnLwBADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAec8WTmTjAwA8AAAA PAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHrPFk6UFg8AVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAX/PFk6c /QsAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAILPFk7U1gkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNzxZOZOMDADwAAAA8AAAAwggX UAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA j88WToSECwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAJbPFk5EBgYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH/ /oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAA AAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABls8WTgRGCwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJfPFk5MLg0AdgAA AHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAA AAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAA AAAAAAAAAAAAoM8WThTYDgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKHPFk40dAIAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACuzxZOtDUCADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAArs8WThSXBABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAA AAAAAAAAAAAAAAAAAAAAQAGzzxZObE0AAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6A AAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAA AAAAQAGzzxZOdHUHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAs88WTpQWDwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALzPFk5MLg0AlwEAAJcB AAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUs IDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1 KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3 LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBT eXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVh bQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+ UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAA KQAJAAQACwAFAL/PFk4ERgsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADJzxZOTC4NADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzM8WTqxOBQA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAMzPFk6sywUAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADA CRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAA AAAAAAAAAAAAAAAAAAAAAEAB0s8WTpTVBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN/PFk50dQcAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADg zxZO5KQDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA5M8WTmyICwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+ gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAA AAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHkzxZOlBYPADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7M8WTsREBgCXAQAA lwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2Fy ZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQo MTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93 d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2Nv IFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90 ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX //5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgA AAApAAkABAALAAUA8s8WTrQ1AgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPXPFk60dgwAVgAAAFYAAAAzMwAAAAnCCBdQ AACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAg AAAAAAAAAAAAAAAAAAAAAABAAffPFk5EAAcAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD8zxZO3L0GAJcBAACXAQAAAQAM zMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQD8zxZOfCAOADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAWTjycCQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAED0BZOlNUEADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADNAWTtTW CQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABDQFk5EBgYAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd0BZOxEQGADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAINAWToSE CwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAA QAEh0BZOjO4HADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAIdAWTkwuDQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACzQFk4UlwQATQAAAE0AAACr AAACAADCCBdQAABgAj0ABwAAAAEAAwMAAAIAAiEAAwAGAAAAAAAABAACPAAFAALYBQYAAgABBwAG wggXUAAAZAABeZABAQGRAQLuBS3QFk7k5Q0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAy0BZO1NYJAFYAAABWAAAAMzMA AAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAg xbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAE40BZOHPsBAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmq qgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChD MzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZU V0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1 cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21w aWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQAC AEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAA AAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQA40BZOTO0C ADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAONAWTrxdCQBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAA AMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB MAAAAAAAAAAAAAAAAAAAAAAAQAE70BZOtDUCADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQNAWTmRmAwA8AAAAPAAAAMIJ F1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEDQFk6sywUAdgAAAHYAAAAzMwAAAAHCCBdQAACG3W4AAAAAQDr//oAAAAAAAADACBf//lAAAP8C AAAAAAAAAAAAAAAAAAGGAE3zQAAHCAAAAAAAAAAAAQHCCBdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6 gAAAAAAgAAAAAAAAAAAAAAAAAAAATdAWTpy8AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE7QFk6k5AgAPAAAADwAAADC CBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABX0BZOtDUCAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/ AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAA AAAAAAAAAABAAVjQFk5kpw0ATQAAAE0AAACrAAACAADCCRdQAABgAj0ABwAAAAEAAwMAAAIAAiEA AwAGAAAAAAAABAACPAAFAALYBQYAAgABBwAGwgkXUAAAZAABeZABAQGRAQLuBVrQFk6cvAEAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABk0BZOhEMBADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ9AWTnxcBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGvQFk7sTwoAdgAA AHYAAAAzMwAAAAHCCRdQAACG3W4AAAAAQDr//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAA AAGGAE3xQAAHCAAAAAAAAAAAAQHCCRdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAA AAAAAAAAAAAAbtAWTnwgDgCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIx AAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklT RUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5p Y2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAo YykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0w OCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAII qqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMA E0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAb9AWTlx/BgA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHDQFk6M 7gcAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAA AAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAXjQFk58XAQAagAAAGoAAAAz MwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABeNAWTszvDACX AQAAlwEAAAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0 d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEy LjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6 Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENp c2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3Jl bF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAA wAkX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAE AAgAAAApAAkABAALAAUAedAWTlQVCgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHvQFk68XQkAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACI0BZO hIQLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAj9AWTuyFAQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI/QFk7cvQYAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACV0BZO RAYGAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAA AABAAZnQFk6U1QQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACk0BZO/F4OADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAptAWTsREBgA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAK3QFk5M7QIAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACt0BZOhAcLAFYAAABWAAAAMzMAAAAJwggXUAAAht1uAAAA ACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAA AAAAAAAAAAAAQAGy0BZObI4KAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAA wAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEw AAAAAAAAAAAAAAAAAAAAAABAAbXQFk5k4wMAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAA ArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFE VkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChm YzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApD b3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdl ZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMB AcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAA AAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFALfQFk40tQwAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAC30BZOfJ0OADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw9AWTuxJCwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM3QFk4UlwQAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADQ0BZOTC4NADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1NAWTsREBgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAA AAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAA AAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHd0BZOzGwNADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA49AWTrQ1 AgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAOrQFk78Xg4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADs0BZOdHUHAFYAAABWAAAAMzMAAAAJwggX UAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQAgxbQCAQAA IAAAAAAAAAAAAAAAAAAAAAAAQAHv0BZO1BIAAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwg AAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1B RFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAo ZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQK Q29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBX ZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAAD AQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAA AAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQD40BZOTO0CADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA+NAWTmRmAwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAA AAAAAAAAAAAAAAAAQAH40BZOTC4NADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/tAWToQHCwCXAQAAlwEAAAEADMzMzMIJ F1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0 d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVB U0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29t L3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIElu Yy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2Nv IDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAA AIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA AdEWTuxPCgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA7RFk6EBwsAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO0RZOzO8MADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GNEWTjS1DABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIA AAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAA AAAAAAAAQAEZ0RZOpJcAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIdEWTmTjAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACLRFk4ERgsAVgAA AFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAA AAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAASLRFk5MLg0APAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw0RZO 7IsAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAANtEWTrQ1AgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAA AAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAA AEABMAAAAAAAAAAAAAAAAAAAAAAAQAE20RZOzCsDADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANtEWTtTWCQA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEDRFk5kZgMAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxD aXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1N KSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBT dXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5 ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6 MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAA AIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0 RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAEHRFk6c/QsAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABC0RZOHH4BAHYA AAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAA AAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAA AAAAAAAAAAAAAEPRFk6EQwEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABI0RZOXH8GAGoAAABqAAAAMzMAAAAJwgkXUAAA ht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAA AAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAUjRFk7MbA0APAAAADwAAADCCBdQ AADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABO 0RZOHH4BADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAWtEWTrxdCQBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+ gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAA AAAAAEABW9EWTswrAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF3RFk5MLg0APAAAADwAAADCCBdQAADCCBdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABh0RZOhAcLADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAYdEWToSECwBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+ UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAA AAAAAAAAAAAAAAAAQAFo0RZOtHYMAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0IbUA AQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRF UlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpU ZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJp Z2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAt QXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQA AAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAA AAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQBu0RZOBEYLADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ctEWThy/CwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHjRFk78Xg4AlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAA ArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFE VkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChm YzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApD b3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdl ZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMB AcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAA AAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAHvRFk58IA4APAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACE0RZOpGcIAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAYjRFk6M7gcAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJ0RZO5KQDADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAltEWTlz8 BgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAJnRFk58XAQAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA AZ3RFk4cvwsAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACh0RZOPB8JADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqNEWTmRmAwBqAAAAagAAADMz AAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkA NFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGo0RZO1NYJADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAs9EWTtTWCQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALTRFk60NQIAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC60RZOhEMBAJcB AACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3 YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIu NCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDov L3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lz Y28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVs X3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADA CRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQA CAAAACkACQAEAAsABQC80RZO/F4OADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwdEWTsREBgBqAAAAagAAADMzAAAACcIJ F1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEA ACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHI0RZOlBYPADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAytEWThx+AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAANDRFk6kZwgAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAA IBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAA AAAAAAAAAABAAdbRFk4MLQgAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADe0RZONDgMADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA49EWToRDAQBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAHj 0RZO1NYJADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA59EWTsyuAgB2AAAAdgAAADMzAAAAAcIIF1AAAIbdbgAAAABAOv/+ gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAAAYYATfNAAAcIAAAAAAAAAAABAcIIF1AAAAUB AAAAAAXcAwRAwAAnjQAACTqAAAAAACAAAAAAAAAAAAAAAAAAAADp0RZO/F4OAJcBAACXAQAAAQAM zMzMwggXUAAAAYmqqgMAAAwgAAK0IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQDu0RZOhIQLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9NEWTmxNAAA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPrRFk6sywUAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD90RZO1BIAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAf/RFk7U1gkAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAAB AAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVS UFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRl Y2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmln aHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1B cHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAA AAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAA AgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAAHSFk7kpAMAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL 0hZOhMYAADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAC9IWTpy8AQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3SFk68XQkAVgAAAFYAAAAzMwAA AAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDF tAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAARfSFk5MZAQAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd0hZOHH4BAHYAAAB2 AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAB hgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAA AAAAAAAAAB7SFk7cvQYAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf/ /lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAA AAAAAAAAAAAAAAAAAEABH9IWTuyLAAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACDSFk4kpggAPAAAADwAAADCCBdQAADC CBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAs0hZO tDUCADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAN9IWTuTlDQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADnSFk7MKwMAPAAAADwAAADCCRdQAADC CRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA80hZO jGUJAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAA AAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAA AABAAT3SFk60NQIAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxD aXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1N KSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBT dXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5 ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6 MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAA AIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0 RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFAD3SFk6sTgUAPAAAADwAAADCCRdQAADCCRdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABG0hZO7IsAAFYA AABWAAAAMzMAAAAJwggXUAAAht1uAAAAACAR//6AAAAAAAAAwAgX//5QAAD/AgAAAAAAAAAAAAAA AAAJAgkCCQAgxbQCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAFJ0hZOFNgOADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATNIW TjxPAQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAFfSFk7UEgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABa0hZO9LMHAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAVvSFk60NQIAPAAAADwA AADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABi0hZOhIQLADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAadIWTnwgDgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG7SFk5UFQoAlwEAAJcB AAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1MgU29mdHdhcmUs IDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1 KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3 LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBT eXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVh bQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAIF//+ UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAA KQAJAAQACwAFAHfSFk40bgMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB50hZOfFwEADwAAAA8AAAAwggXUAAAwggXUAAA kAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAetIWTmRmAwBq AAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAA AAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGC 0hZOFBQFAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28g SU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZl cnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9y dDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIw MDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5 IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ /oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVy bmV0MC8wAAQACAAAACkACQAEAAsABQCF0hZONPECADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAh9IWTjycCQBWAAAAVgAA ADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJ AgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABiNIWTtQSAAA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI7SFk4sjQUA PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACV0hZObE0AADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAldIWTgRGCwBqAAAAagAAADMzAAAACcIJF1AA AIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAA AAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGX0hZOlNUEADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA o9IWTvwdBAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAKPSFk5cfwYAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACt0hZOLI0FAGoAAABqAAAAMzMA AAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0 VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAa3SFk5cfwYAPAAA ADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACz0hZOhAcLAJcBAACXAQAAAQAMzMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIA BQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNF SzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmlj YWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChj KSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4 IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiq qgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwAT RmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQC20hZO1NYJADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudIWThTY DgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAMLSFk406wMAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAA AADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABA AcPSFk7k5Q0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADN0hZOPJwJAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR //6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAA AAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAdDSFk7sTwoAPAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADR0hZOZGYDADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA3tIWTiyNBQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOXSFk58IA4APAAAADwAAADCCBdQAADCCBdQAACQ AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADs0hZOzGwNADwA AAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA8dIWTpTVBABqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJ F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAA AAAAAAAAAAAAAAAAAAAAQAHx0hZO/I4GAJcBAACXAQAAAQAMzMzMwggXUAAAAYmqqgMAAAwgAAK0 IbUAAQAGUjEABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3YXJlIChDMzcyNS1BRFZF TlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFTRSBTT0ZUV0FSRSAoZmM0 KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20vdGVjaHN1cHBvcnQKQ29w eXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5jLgpDb21waWxlZCBXZWQg MzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28gMzcyNQACAEkAAAADAQHM AAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACBf//lAAAAIIqqoDAAAAht0AECAAAAAAAAAAAAAA AAAAAAEAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQDx0hZODCcJAHYAAAB2AAAA MzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN 8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAA AAAAAPLSFk4c+wEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD50hZOzK4CADwAAAA8AAAAwggXUAAAwggXUAAAkAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+9IWTnxcBACXAQAAlwEA AAEADMzMzMIJF1AAAAGJqqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwg MzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUp VDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cu Y2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5 c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFt AAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5Q AAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAAp AAkABAALAAUA/NIWTlQVCgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAI F//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB/tIW TswrAwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAvTFk5kZgMAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL0xZOZOMDAGoAAABqAAAAMzMAAAAJ wgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoC AQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAQvTFk6M7gcAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAT0xZOJFkAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAINMWTlTIAQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACHTFk5USwEAPAAAADwA AADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAq0xZO7IUBAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5Q AAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAA AAAAAAAAAAAAAABAAS7TFk78lAUAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAv0xZOBL0MAE0AAABNAAAAqwAAAgAAwgkX UAAAYAI9AAcAAAABAAMDAAACAAIhAAMABgAAAAAAAAQAAjwABQAC2AUGAAIAAQcABsIJF1AAAGQA AXmQAQEBkQEC7gUw0xZO7MYLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANNMWTmTdBABWAAAAVgAAADMzAAAACcIIF1AA AIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAA AAAAAAAAAAAAAAAAAAAAAEABNtMWTqzFBgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADvTFk68kwAAlwEAAJcBAAABAAzM zMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAg U29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBS RUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2Nv LmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1z LCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5D aXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiq qgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQA CwAFAD3TFk7k3w4APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABG0xZOvJMAAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAA ADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAA AAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAUbTFk6sxQYAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABM0xZOXPYH ADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAATdMWTlz2BwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFbTFk6MZQkAPAAAADwAAADCCRdQAADCCRdQ AACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABb0xZOTGQE AGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAA AAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABA AWLTFk6k3gkAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABk0xZOXPYHADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAb9MWTuwCAgCXAQAAlwEAAAEA DMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEABlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcw MCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUs IFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lz Y28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3Rl bXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYA DkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAAC CKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAABAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkA BAALAAUActMWTsS7BwA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHXTFk4cNg0AVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4A AAAAIBH//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAA AAAAAAAAAAAAAABAAXnTFk50bwgAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB70xZOhD0CAJcBAACXAQAAAQAMzMzMwgkX UAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAwIFNvZnR3 YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwgUkVMRUFT RSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNjby5jb20v dGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVtcywgSW5j LgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAOQ2lzY28g MzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAIIqqoDAAAA ht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAEAAsABQB9 0xZOLIcGAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAA AAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAA AAAAAABAAX3TFk7cNAgAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACK0xZOVIwLADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkNMWTnRvCAA8AAAA PAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJjTFk40rw0APAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACZ0xZO1E0LAGoAAABqAAAAMzMAAAAJwgkXUAAAht1u AAAAADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAA AAAAAAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAZrTFk7kngQAdgAAAHYAAAAzMwAAAAHC CBdQAACG3W4AAAAAQDr//oAAAAAAAADACBf//lAAAP8CAAAAAAAAAAAAAAAAAAGGAE3zQAAHCAAA AAAAAAAAAQHCCBdQAAAFAQAAAAAF3AMEQMAAJ40AAAk6gAAAAAAgAAAAAAAAAAAAAAAAAAAAm9MW Tpz3DAA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKTTFk48lgoAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACo0xZOPJYKADwAAAA8AAAAwgkXUAAA wgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsdMW TpRMBgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAA AAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABtdMWTpx0DQA8AAAAPAAA AMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAALvTFk7EPgcAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC80xZOdG8IAGoAAABqAAAAMzMAAAAJwgkXUAAAht1uAAAA ADQR//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAJAgkCCQA0VYoCAQAAIAAAAAAAAAAA AAAAAAAAAAAAQAEwAAAAAAAAAAAAAAAAAAAAAABAAbzTFk507AgAlwEAAJcBAAABAAzMzMzCCRdQ AAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJT1MgU29mdHdhcmUsIDM3MDAgU29mdHdh cmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNF IFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90 ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMu CkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAz NzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG 3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJuZXQwLzAABAAIAAAAKQAJAAQACwAFALzT Fk7UTQsAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC+0xZOzGYOAHYAAAB2AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6A AAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAABhgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEA AAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAAAAAAAAAAAMTTFk6EPQIAPAAAADwAAADCCRdQ AADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADR 0xZONG4DADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA0dMWTqzFBgA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANbTFk4sBAcAagAAAGoAAAAzMwAA AAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRV igIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB19MWTjRuAwA8AAAA PAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAOTTFk7UDAEAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADm0xZOtKwDADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA79MWThw2DQBWAAAA VgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAAAEAB8dMWTrSsAwA8AAAAPAAAAMIJF1AAAMIJ F1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPLTFk4E fAIAlwEAAJcBAAABAAzMzMzCCBdQAAABiaqqAwAADCAAArQhtQABAAZSMQAFAPxDaXNjbyBJT1Mg U29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVyc2lv biAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0OiBo dHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAwOCBi eSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkgcHJv ZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+gAAA AAAAAMAIF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAQADABNGYXN0RXRoZXJuZXQw LzAABAAIAAAAKQAJAAQACwAFAPLTFk5MpQ4AagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAANBH/ /oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAAAAAA AAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEAB9tMWTrTtDQCXAQAAlwEAAAEADMzMzMIJF1AAAAGJ qqoDAAAMIAACtB+0AAEABlIyAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAo QzM3MjUtQURWRU5URVJQUklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09G VFdBUkUgKGZjNCkKVGVjaG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hz dXBwb3J0CkNvcHlyaWdodCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29t cGlsZWQgV2VkIDMwLUFwci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUA AgBJAAAAAwEBzAAEAAAAAAIIqqoDAAAAht0AEP6AAAAAAAAAwAkX//5QAAACCKqqAwAAAIbdABAg AAAAAAAAAAAAAAAAAAACAAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUA+dMWTjSv DQA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAPrTFk50bwgAPAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1BZO/JQFADwAAAA8AAAAwgkXUAAAwgkX UAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB9QWTrxX CgBqAAAAagAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAA AAAAAAAACQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAA QAEJ1BZO/JQFADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAEdQWTlz2BwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABPUFk7EuwcAPAAAADwAAADC CRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAg1BZODKQJADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAJtQWTjSvDQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACfUFk6cMwMAagAAAGoAAAAz MwAAAAnCCRdQAACG3W4AAAAANBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJ ADRVigIBAAAgAAAAAAAAAAAAAAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABJ9QWTvStCAA8 AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAC/UFk7EPgcAVgAAAFYAAAAzMwAAAAnCCBdQAACG3W4AAAAAIBH//oAAAAAAAADA CBf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJACDFtAIBAAAgAAAAAAAAAAAAAAAAAAAAAABAAS/U Fk6c9wwAlwEAAJcBAAABAAzMzMzCCRdQAAABiaqqAwAADCAAArQftAABAAZSMgAFAPxDaXNjbyBJ T1MgU29mdHdhcmUsIDM3MDAgU29mdHdhcmUgKEMzNzI1LUFEVkVOVEVSUFJJU0VLOS1NKSwgVmVy c2lvbiAxMi40KDE1KVQ1LCBSRUxFQVNFIFNPRlRXQVJFIChmYzQpClRlY2huaWNhbCBTdXBwb3J0 OiBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWNoc3VwcG9ydApDb3B5cmlnaHQgKGMpIDE5ODYtMjAw OCBieSBDaXNjbyBTeXN0ZW1zLCBJbmMuCkNvbXBpbGVkIFdlZCAzMC1BcHItMDggMTg6MjcgYnkg cHJvZF9yZWxfdGVhbQAGAA5DaXNjbyAzNzI1AAIASQAAAAMBAcwABAAAAAACCKqqAwAAAIbdABD+ gAAAAAAAAMAJF//+UAAAAgiqqgMAAACG3QAQIAAAAAAAAAAAAAAAAAAAAgADABNGYXN0RXRoZXJu ZXQwLzAABAAIAAAAKQAJAAQACwAFADHUFk7EPgcAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA61BZOTKUOADwAAAA8AAAA wggXUAAAwggXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAO9QWTpRMBgA8AAAAPAAAAMIJF1AAAMIJF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEHUFk6ctgIAagAAAGoAAAAzMwAAAAnCCRdQAACG3W4AAAAA NBH//oAAAAAAAADACRf//lAAAP8CAAAAAAAAAAAAAAAAAAkCCQIJADRVigIBAAAgAAAAAAAAAAAA AAAAAAAAAABAATAAAAAAAAAAAAAAAAAAAAAAAEABRtQWTlRLAQA8AAAAPAAAAMIJF1AAAMIJF1AA AJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFDUFk7UTQsA PAAAADwAAADCCBdQAADCCBdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABT1BZOFA4GADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYtQWTpwzAwBqAAAAagAAADMzAAAACcIJF1AA AIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWKAgEAACAA AAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAFi1BZOxD4HADwAAAA8AAAAwgkX UAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ZdQWTjTrAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGXUFk4MpAkAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABs1BZO1E0LAJcBAACXAQAAAQAM zMzMwgkXUAAAAYmqqgMAAAwgAAK0H7QAAQAGUjIABQD8Q2lzY28gSU9TIFNvZnR3YXJlLCAzNzAw IFNvZnR3YXJlIChDMzcyNS1BRFZFTlRFUlBSSVNFSzktTSksIFZlcnNpb24gMTIuNCgxNSlUNSwg UkVMRUFTRSBTT0ZUV0FSRSAoZmM0KQpUZWNobmljYWwgU3VwcG9ydDogaHR0cDovL3d3dy5jaXNj by5jb20vdGVjaHN1cHBvcnQKQ29weXJpZ2h0IChjKSAxOTg2LTIwMDggYnkgQ2lzY28gU3lzdGVt cywgSW5jLgpDb21waWxlZCBXZWQgMzAtQXByLTA4IDE4OjI3IGJ5IHByb2RfcmVsX3RlYW0ABgAO Q2lzY28gMzcyNQACAEkAAAADAQHMAAQAAAAAAgiqqgMAAACG3QAQ/oAAAAAAAADACRf//lAAAAII qqoDAAAAht0AECAAAAAAAAAAAAAAAAAAAAIAAwATRmFzdEV0aGVybmV0MC8wAAQACAAAACkACQAE AAsABQBt1BZOpBoAADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbdQWTpy2AgBWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAA AAAgEf/+gAAAAAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAA AAAAAAAAAAAAAEABcNQWTrzUCgCXAQAAlwEAAAEADMzMzMIIF1AAAAGJqqoDAAAMIAACtCG1AAEA BlIxAAUA/ENpc2NvIElPUyBTb2Z0d2FyZSwgMzcwMCBTb2Z0d2FyZSAoQzM3MjUtQURWRU5URVJQ UklTRUs5LU0pLCBWZXJzaW9uIDEyLjQoMTUpVDUsIFJFTEVBU0UgU09GVFdBUkUgKGZjNCkKVGVj aG5pY2FsIFN1cHBvcnQ6IGh0dHA6Ly93d3cuY2lzY28uY29tL3RlY2hzdXBwb3J0CkNvcHlyaWdo dCAoYykgMTk4Ni0yMDA4IGJ5IENpc2NvIFN5c3RlbXMsIEluYy4KQ29tcGlsZWQgV2VkIDMwLUFw ci0wOCAxODoyNyBieSBwcm9kX3JlbF90ZWFtAAYADkNpc2NvIDM3MjUAAgBJAAAAAwEBzAAEAAAA AAIIqqoDAAAAht0AEP6AAAAAAAAAwAgX//5QAAACCKqqAwAAAIbdABAgAAAAAAAAAAAAAAAAAAAB AAMAE0Zhc3RFdGhlcm5ldDAvMAAEAAgAAAApAAkABAALAAUAddQWTuQbBQBqAAAAagAAADMzAAAA CcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkANFWK AgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAF31BZOfNMFADwAAAA8 AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAetQWTjTrAwA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIPUFk6kGgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACK1BZODCcJAHYAAAB2 AAAAMzMAAAABwgkXUAAAht1uAAAAAEA6//6AAAAAAAAAwAkX//5QAAD/AgAAAAAAAAAAAAAAAAAB hgBN8UAABwgAAAAAAAAAAAEBwgkXUAAABQEAAAAABdwDBEDAACeNAAAJOoAAAAAAIAAAAAAAAAAA AAAAAAAAAJDUFk5UzgAAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACR1BZOTKUOADwAAAA8AAAAwggXUAAAwggXUAAAkAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlNQWTqzFBgBqAAAA agAAADMzAAAACcIJF1AAAIbdbgAAAAA0Ef/+gAAAAAAAAMAJF//+UAAA/wIAAAAAAAAAAAAAAAAA CQIJAgkANFWKAgEAACAAAAAAAAAAAAAAAAAAAAAAAEABMAAAAAAAAAAAAAAAAAAAAAAAQAGd1BZO NOsDADwAAAA8AAAAwgkXUAAAwgkXUAAAkAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAApdQWTgS9DABWAAAAVgAAADMzAAAACcIIF1AAAIbdbgAAAAAgEf/+gAAA AAAAAMAIF//+UAAA/wIAAAAAAAAAAAAAAAAACQIJAgkAIMW0AgEAACAAAAAAAAAAAAAAAAAAAAAA AEABqNQWTlRLAQA8AAAAPAAAAMIIF1AAAMIIF1AAAJAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAKrUFk7kngQAPAAAADwAAADCCRdQAADCCRdQAACQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --_b2d195fa-6892-4e99-91b3-36155d967fd3_-- From rathiguru@hotmail.com Wed Jul 13 05:46:49 2011 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 158D621F8625 for ; Wed, 13 Jul 2011 05:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS3GxMlBzPie for ; Wed, 13 Jul 2011 05:46:48 -0700 (PDT) Received: from bay0-omc2-s2.bay0.hotmail.com (bay0-omc2-s2.bay0.hotmail.com [65.54.190.77]) by ietfa.amsl.com (Postfix) with ESMTP id 84F6721F8829 for ; Wed, 13 Jul 2011 05:46:48 -0700 (PDT) Received: from BAY146-W17 ([65.54.190.125]) by bay0-omc2-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 05:46:48 -0700 Message-ID: Content-Type: multipart/mixed; boundary="_aa15614e-95b6-45c6-8c15-0ee9c3232c72_" X-Originating-IP: [202.75.206.179] From: Thiruma valavan To: Subject: FW: Doubt in Router Advertisement Message Date: Wed, 13 Jul 2011 18:16:47 +0530 Importance: Normal In-Reply-To: References: , <4e18d0c5.2727440a.7a71.2906@mx.google.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2011 12:46:48.0667 (UTC) FILETIME=[EE3BF2B0:01CC415A] X-Mailman-Approved-At: Wed, 13 Jul 2011 05:58: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, 13 Jul 2011 12:46:49 -0000 --_aa15614e-95b6-45c6-8c15-0ee9c3232c72_ Content-Type: multipart/alternative; boundary="_66adeaa1-abf2-40c3-9e60-ee9952d10e21_" --_66adeaa1-abf2-40c3-9e60-ee9952d10e21_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is the correct packet capture for IPv6 fragmentation Thanks=2C Thiru=20 From: rathiguru@hotmail.com To: vishwas.ietf@gmail.com CC: ipv6@ietf.org Subject: RE: Doubt in Router Advertisement Message Date: Wed=2C 13 Jul 2011 18:13:22 +0530 Vishwas=2C I am having one more doubt in IPv6 Fragmentation=20 Router Interface MTU 1500=2C Host A wants to send a packet with 3=2C000 dat= a bytes but MTU is 1500=2C so it needs to fragment the packet. As per RFC 2460=2C First Packet 40 bytes (IPv6 Header) + 8 bytes Fragment H= eader + 1452 Data =3D 1500 =20 Second Packet 40 bytes (IPv6 Header) + 8 bytes Fragment Header= + 1452 Data =3D 1500 =20 Third Packet 40 bytes (IPv6 Header) + 8 bytes Fragme= nt Header + 96 Data =3D 1500=20 =20 Thanks=2C Thiru=20 Date: Sat=2C 9 Jul 2011 15:05:47 -0700 From: vishwas.ietf@gmail.com To: rathiguru@hotmail.com=3B ipv6@ietf.org Subject: Re: Doubt in Router Advertisement Message Hi Thiruma=2C >From the specs it is clear that the MTU is optional. However if MTU sending= is enabled it should be sent on change too. Sounds like a bug in the implementation to me. Thanks=2C Vishwas Sent from my Palm Pre on AT&T On Jul 9=2C 2011 2:51 AM=2C Thiruma valavan wrote:= =20 Hi IETF Group=2C While testing IPV6 Router Advertisement part=2C I noticed some behaviour th= at if I changed router interface MTU value=2C it won't send Router Advertis= ement message immediately instead of waiting to next interval time. Is that normal behaviour=2C=20 Thanks & Regards=2C Thirumavalavan PCalsoflabs India Pvt Ltd=2CBangaloreATLEN Group of CompanyM= ob: +91 9790758035=20 =20 = --_66adeaa1-abf2-40c3-9e60-ee9952d10e21_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is= the correct packet capture for IPv6 fragmentation

Thanks=2C
Thiru
 =3B=


From: rathiguru@hotmail.com
To: vishwas.ietf@gmail.com
CC= : ipv6@ietf.org
Subject: RE: Doubt in Router Advertisement Message
Da= te: Wed=2C 13 Jul 2011 18:13:22 +0530

Vishwas=2C
<= div>

I = am having one more doubt in IPv6 Fragmentation =3B

Router Int= erface MTU 1500=2C Host A wants to send a packet with 3=2C000 data bytes bu= t MTU is 1500=2C so it needs to fragment the packet.

As per RFC 2460= =2C First Packet 40 bytes (IPv6 Header) + 8 bytes Fragment Header + 1452 Da= ta =3D 1500  =3B

<= /div>
 =3B  =3B  =3B  =3B  =3B  = =3B Second Packet =3B40 bytes (IPv6 Header)= + 8 bytes Fragment Header + 1452 Data =3D 1500  =3B

 =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B  =3B  =3BThird Packet  =3B  = =3B =3B40 bytes (IPv6 Header) + 8 bytes Fragm= ent Header +  =3B  =3B96 Data =3D  =3B1500 =3B
=

 =3B

<= br>
=


Thanks=2C<= br>Thiru<= div style=3D"font-family:Tahoma=3Bfont-size:10pt">
 =3B


Date: Sat=2C 9 Jul 2011 15:05:47 -0700
From: vishwas.ietf= @gmail.com
To: rathiguru@hotmail.com=3B ipv6@ietf.org
Subject: Re: Do= ubt in Router Advertisement Message

Hi Thiruma=2C

From the sp= ecs it is clear that the MTU is optional. However if MTU sending is enabled= it should be sent on change too.

Sounds like a bug in the implement= ation to me.

Thanks=2C
Vishwas



<= div style=3D"font-family:arial=2C sans-serif=3Bfont-size:12px=3Bcolor:#9999= 99">Sent from my Palm Pre on AT&=3BT

On Jul 9=2C 2011 2:51 AM=2C Thiruma valavan <=3Brathigu= ru@hotmail.com>=3B wrote:

Hi IETF Group=2C

While testing IPV6 Router Advertisement part=2C I noticed some beha= viour that if I changed router interface MTU value=2C it won't send Router = Advertisement message immediately instead of waiting to next interval time.=
=
= Is that normal behaviour=2C =3B

Thanks &=3B Regards=2C
Thirumavalavan P
Calsoflabs India P= vt Ltd=2CBangalore
ATLEN Group of Co= mpany
Mob: +91 9790758035
=
= --_66adeaa1-abf2-40c3-9e60-ee9952d10e21_-- --_aa15614e-95b6-45c6-8c15-0ee9c3232c72_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="frag-thiru.pcap" 1MOyoQIABAAAAAAAAAAAAAAgAAABAAAAys4WTrR2DADmBQAA5gUAAMIJF1AAAMIIF1AAAIbdYAAA AAWwLEAgAAAAAAAAAAAAAAAAAAABMAAAAAAAAAAAAAAAAAAAAjoAAAEAAAAEgAAyZRIjAAEBAgME BQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9 Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2 d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6v sLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo 6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh IiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFla W1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvM zc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQF BgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+ P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3 eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+w sbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp 6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEi IyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpb XF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOU lZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zN zs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUG BwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/ QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4 eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7Cx srO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq 6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIj JCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltc XV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SV lpeYmZqbnJ2en6DKzhZOzGwNAOYFAADmBQAAwgkXUAAAwggXUAAAht1gAAAABbAsQCAAAAAAAAAA AAAAAAAAAAEwAAAAAAAAAAAAAAAAAAACOgAFqQAAAAShoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5 uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy 8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSor LC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNk ZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5yd np+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW 19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4P EBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdI SUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CB goOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6 u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz 9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKiss LS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2Rl ZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2e n6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX 2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8Q ERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREVGR0hJ SktMTU5PUFFSU1RVVldYWVpbXF1eX2BhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ent8fX5/gIGC g4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7 vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP0 9fb3+Pn6+/z9/v8AAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywt Li8wMTIzNDU2Nzg5Ojs8PT4/QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl9gYWJjZGVm Z2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+f4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6f oKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY 2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAECAwQFBgcICQoLDA0ODxAR EhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSMrO Fk78Xg4AfgAAAH4AAADCCRdQAADCCBdQAACG3WAAAAAASCxAIAAAAAAAAAAAAAAAAAAAATAAAAAA AAAAAAAAAAAAAAI6AAtQAAAABElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1u b3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4g= --_aa15614e-95b6-45c6-8c15-0ee9c3232c72_-- From arturo.servin@gmail.com Wed Jul 13 06:14:44 2011 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 A8D2C21F84F1 for ; Wed, 13 Jul 2011 06:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+GxS3I3DN2y for ; Wed, 13 Jul 2011 06:14:44 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8BCF21F8419 for ; Wed, 13 Jul 2011 06:14:43 -0700 (PDT) Received: by bwb17 with SMTP id 17so5671742bwb.31 for ; Wed, 13 Jul 2011 06:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=49zCR8275D0+JH7+79zT4R7NdJiNsFhiTW0YUkcNJNA=; b=uwGDbP7DXnGBwjpDK7dYLVqpWKRioy0/z24EWGRwU7giD1/vTCESBppn/s96YMxHb6 roeMEg5sYG7F1HmhdBc2q7z+G/n+NFZUd5T9STnJqNzJNp9JI5VOx/tlc5YS2ONmyR3H HN3eKEPWg/TndIGBoEt0TmEaUCaLUfyfml9kI= Received: by 10.204.14.146 with SMTP id g18mr562992bka.68.1310562875221; Wed, 13 Jul 2011 06:14:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.126.100 with HTTP; Wed, 13 Jul 2011 06:14:15 -0700 (PDT) In-Reply-To: References: From: Arturo Servin Date: Wed, 13 Jul 2011 09:14:15 -0400 Message-ID: Subject: Re: /64 ND DoS To: Philip Homburg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 13 Jul 2011 13:14:44 -0000 What's the point? If you asume unrealistic scenarios to prove your concept, then you have a problem with your solution. The problem is that you have a link where the attacker can have 2^64 different addresses to spoof and it can send NS request at any rate. -as On Wed, Jul 13, 2011 at 4:17 AM, Philip Homburg w= rote: > In your letter dated Tue, 12 Jul 2011 18:32:15 -0400 you wrote: >> >> =A0 =A0 =A0 IMHO I think this would be a vector for other attacks in ND. >> >> =A0 =A0 =A0 You may solve a remote attack but you are opening the door t= o =3D >>local attacks, and a big ones I think. > > Let's assume for a moment a 'normal' link (not one with 6000 hosts) and a > protocol that spreads NS requests by the hosts over a period of say 20 se= conds, > how would you then use this as an attack vector? > > > From jmh@joelhalpern.com Wed Jul 13 08:54:14 2011 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 738E021F8922 for ; Wed, 13 Jul 2011 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JRdB7eiSC0f for ; Wed, 13 Jul 2011 08:54:14 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id C929321F8906 for ; Wed, 13 Jul 2011 08:54:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B009632448B8; Wed, 13 Jul 2011 08:54:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D71A3324640B; Wed, 13 Jul 2011 08:54:11 -0700 (PDT) Message-ID: <4E1DBFA0.1050103@joelhalpern.com> Date: Wed, 13 Jul 2011 11:54:08 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: /64 ND DoS References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: 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: Wed, 13 Jul 2011 15:54:14 -0000 There appear to be several different cases, which can be addressed by different reasonable mechanisms (not firewalls, and not lengthening the subnet prefix.) For ISPs, I would assume the primary concern is routers connecting to subnets used to provide services. A non-dynamic approach to ND can address that. For ISPs providing bridged residential services, the ISP normally operates on the basis that it gets registration information from all the devices in the home. Thus, it does not need to generate ND solicitations. Yours, Joel On 7/13/2011 4:08 AM, Mikael Abrahamsson wrote: > On Tue, 12 Jul 2011, Christian Huitema wrote: > >> Then I am really not worried. This kind of attack is trivially >> mitigated by any stateful firewall on the path. In addition to all >> other mitigations that were listed on this thread. > > Think as an ISP. We do not stateful firewall our customers, and we might > be forced to have requipment in the customer /64, at least initially. > This is a real problem, as this device will in some cases be a L3 switch > with quite limited CPU and FIB table size. > > I definitely prefer to have only link-local between me and a CPE and > just route the /56 to the CPE, so I do not ever have to keep any state > regarding individual customer placed devices. > > We have already requested that our L3 switch vendors have ND starvation > protection, but there is serious lack of documentation to point to. > From swmike@swm.pp.se Wed Jul 13 09:07:39 2011 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 4CD3211E8116 for ; Wed, 13 Jul 2011 09:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-dapce+7U9R for ; Wed, 13 Jul 2011 09:07:38 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 878E911E810B for ; Wed, 13 Jul 2011 09:07:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A7B53281; Wed, 13 Jul 2011 18:07:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A5651280; Wed, 13 Jul 2011 18:07:33 +0200 (CEST) Date: Wed, 13 Jul 2011 18:07:33 +0200 (CEST) From: Mikael Abrahamsson To: "Joel M. Halpern" Subject: Re: /64 ND DoS In-Reply-To: <4E1DBFA0.1050103@joelhalpern.com> Message-ID: References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4E1DBFA0.1050103@joelhalpern.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW 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: Wed, 13 Jul 2011 16:07:39 -0000 On Wed, 13 Jul 2011, Joel M. Halpern wrote: > For ISPs providing bridged residential services, the ISP normally > operates on the basis that it gets registration information from all the > devices in the home. Thus, it does not need to generate ND > solicitations. Is there some description of this behaviour somewhere, what would this feature be called that I can ask vendors if they have in their equipment? Just to be sure, we're now saying that reachability won't be had from the outside unless the internal device keeps itself "registered" with the ISP router. -- Mikael Abrahamsson email: swmike@swm.pp.se From jmh@joelhalpern.com Wed Jul 13 09:31:06 2011 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 8EC8311E8156 for ; Wed, 13 Jul 2011 09:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzK+z-V9OPNb for ; Wed, 13 Jul 2011 09:31:06 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 0627811E814C for ; Wed, 13 Jul 2011 09:31:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 603D63246B60; Wed, 13 Jul 2011 09:31:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D67BF32462B0; Wed, 13 Jul 2011 09:31:04 -0700 (PDT) Message-ID: <4E1DC845.2050607@joelhalpern.com> Date: Wed, 13 Jul 2011 12:31:01 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: /64 ND DoS References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4E1DBFA0.1050103@joelhalpern.com> In-Reply-To: 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: Wed, 13 Jul 2011 16:31:06 -0000 I asked our PMs about this after some earlier discussions, and for many BRAS deployments of IPv6, this restriction is a natural side-effect of normal and desired behavior. I do not know what the feature name is as used in product. (I worry more about what it does, not what it is called in the marketting literature. Sorry.) Yours, Joel On 7/13/2011 12:07 PM, Mikael Abrahamsson wrote: > On Wed, 13 Jul 2011, Joel M. Halpern wrote: > >> For ISPs providing bridged residential services, the ISP normally >> operates on the basis that it gets registration information from all >> the devices in the home. Thus, it does not need to generate ND >> solicitations. > > Is there some description of this behaviour somewhere, what would this > feature be called that I can ask vendors if they have in their equipment? > > Just to be sure, we're now saying that reachability won't be had from > the outside unless the internal device keeps itself "registered" with > the ISP router. > From jared@puck.nether.net Wed Jul 13 09:45:49 2011 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 8E6CC11E8189 for ; Wed, 13 Jul 2011 09:45:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGOeNVAgdmdf for ; Wed, 13 Jul 2011 09:45:49 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id E953311E8188 for ; Wed, 13 Jul 2011 09:45:48 -0700 (PDT) Received: from [IPv6:2001:418:3f4:2:217:f2ff:fecf:8ee1] ([IPv6:2001:418:3f4:2:217:f2ff:fecf:8ee1]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p6DGjepb018363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Jul 2011 12:45:41 -0400 (EDT) (envelope-from jared@puck.nether.net) Subject: Re: [ipv6] Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Wed, 13 Jul 2011 12:45:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1D927FBF-53DA-4EF6-BE1A-8B45623ECA44@puck.nether.net> References: <4E1CDD14.7020702@globis.net> <82wrfmocir.fsf@mid.bfk.de> <4E1D51F4.7040103@globis.net> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [IPv6:2001:418:3f4::5]); Wed, 13 Jul 2011 12:45:41 -0400 (EDT) Cc: Ray Hunter , "ipv6@ietf.org 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, 13 Jul 2011 16:45:49 -0000 On Jul 13, 2011, at 4:11 AM, Mikael Abrahamsson wrote: > On Wed, 13 Jul 2011, Ray Hunter wrote: >=20 >> So where's the limit for ND and prefix length on today's = implementations and platforms? >=20 > Todays L3 switches typically have an ND/ARP table size limitations in = the 1-4k entry range. >=20 >> What if SLAAC was limited to using 20 bits or even just 16 bits of = MAC BIA information or even in extremis dare I say 12 bits? >=20 > /120 would be more doable. When I think of ND table size per customer, = I'm thinking limitation to 16-32 entries, after that the customer needs = to get a router. We have seen problems in the 2^11 or 2^12 in IPv4 land with = directly-connected customer lans. The ability for the Mac <-> IP (ARP) = to work properly is a serious issue with reasonable routers. I think the larger issue here is that an ARP either = solicited/unsolicited does not cause an entry to age. That is what = happens in IPv6 (NDP) land, so that's an issue IMHO. - Jared= From rja.lists@gmail.com Wed Jul 13 09:51:19 2011 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 5CD6E11E81A3 for ; Wed, 13 Jul 2011 09:51:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLFziJBLstn9 for ; Wed, 13 Jul 2011 09:51:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFE6E11E81A2 for ; Wed, 13 Jul 2011 09:51:18 -0700 (PDT) Received: by vws12 with SMTP id 12so6459282vws.31 for ; Wed, 13 Jul 2011 09:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=VsjOfyyM3aP1JDaTVx0p+k5Cgowq1BkRVVfDS28idUg=; b=XJZqvK4fnzkdNfctFZfmF/tzwJyBk64y6pW7FbqQ63eujYpPNt8FV8F3Juvog5Gk4l oWS3/58B+uKtRzW9BQoIxFgxZoqRB3ydfRokGo4PDTALdyQ856Iov9NStRGxH4YeQK7l EO/xpqusIS9SyaxqQBPzqEMQKna0UbdBBiRyw= Received: by 10.52.93.203 with SMTP id cw11mr1531281vdb.1.1310575877915; Wed, 13 Jul 2011 09:51:17 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id k14sm918356vdu.13.2011.07.13.09.51.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jul 2011 09:51:17 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: /64 ND DoS Date: Wed, 13 Jul 2011 12:51:15 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 13 Jul 2011 16:51:19 -0000 On Weds 13 July 2011 at 11:54:08 -0400, Joel Halpern wrote: > There appear to be several different cases, which can be addressed > by different reasonable mechanisms (not firewalls, and not lengthening > the subnet prefix.) > > For ISPs, I would assume the primary concern is routers connecting > to subnets used to provide services. A non-dynamic approach to ND > can address that. > > For ISPs providing bridged residential services, the ISP normally > operates on the basis that it gets registration information > from all the devices in the home. Thus, it does not need > to generate ND solicitations. Agreed. I do think it would be useful to have an informational document that describes the issue, describes the several cases, and outlines some reasonable mechanisms (possibly separate mechanisms for each case), both for the benefit of network operations folks and also for the benefit of equipment suppliers. Perhaps I am confused, but such a document sounds more like an IPv6 Ops WG item than an IPv6 WG item. So I'm wondering whether this thread belongs over there rather than here. Yours, Ran From pch-b2B3A6689@u-1.phicoh.com Wed Jul 13 09:53:14 2011 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 5F42621F8768 for ; Wed, 13 Jul 2011 09:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.528 X-Spam-Level: X-Spam-Status: No, score=-8.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR8cznZNcsCC for ; Wed, 13 Jul 2011 09:53:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id CEAA621F8872 for ; Wed, 13 Jul 2011 09:52:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qh2g5-0001ieC; Wed, 13 Jul 2011 18:52:49 +0200 Message-Id: To: Arturo Servin Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: In-reply-to: Your message of "Wed, 13 Jul 2011 09:14:15 -0400 ." Date: Wed, 13 Jul 2011 18:52:42 +0200 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, 13 Jul 2011 16:53:14 -0000 In your letter dated Wed, 13 Jul 2011 09:14:15 -0400 you wrote: > What's the point? > > If you asume unrealistic scenarios to prove your concept, then you >have a problem with your solution. > > The problem is that you have a link where the attacker can have >2^64 different addresses to spoof and it can send NS request at any >rate. I guess I completely misunderstand what your are trying to say. Without specific L2 and L3 measures, already today, a local attacker can send NS requests for around 2^64 different addresses. Nothing I proposed changes that. So, I said I want to deal with a remote attack. And then you suggested that I made local attacks worse. But now you mention a local attack works already today. So I missing the point to are trying to make. From jared@puck.nether.net Wed Jul 13 10:01:46 2011 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 8127511E80D9 for ; Wed, 13 Jul 2011 10:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWUQLBppegB5 for ; Wed, 13 Jul 2011 10:01:46 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D781E11E80BD for ; Wed, 13 Jul 2011 10:01:45 -0700 (PDT) Received: from [IPv6:2001:418:3f4:2:217:f2ff:fecf:8ee1] ([IPv6:2001:418:3f4:2:217:f2ff:fecf:8ee1]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p6DH1fsh063699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Jul 2011 13:01:42 -0400 (EDT) (envelope-from jared@puck.nether.net) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Wed, 13 Jul 2011 13:01:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E2E260F-B607-4AFB-BF82-2C48D0363BFE@puck.nether.net> References: To: Arturo Servin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [IPv6:2001:418:3f4::5]); Wed, 13 Jul 2011 13:01:43 -0400 (EDT) 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, 13 Jul 2011 17:01:46 -0000 On Jul 13, 2011, at 9:14 AM, Arturo Servin wrote: > What's the point? >=20 > If you asume unrealistic scenarios to prove your concept, then you > have a problem with your solution. >=20 > The problem is that you have a link where the attacker can have > 2^64 different addresses to spoof and it can send NS request at any > rate. I think what's most interesting is that the nature of the "threat" on = the IPv6 capable Internet is the ability to generate high PPS rate = activity easily. One needs to look no further than the risk and high = PPS attacks on the IPv4 side of things. It's quite reasonable to expect = to have 10k or more unique hosts(source IPs) participating in an attack. If you are a CDN, Major Web Property, or even Residential provider your = risk in IPv4 is one per host or routed IP. The scale involved here is = much larger by design, and the potential of a poorly behaving NDP = implementation to be overwhelmed is quite easy. Not many vendors can = handle 10k or 100kpps in their control-plane. To (re)state the biggest design issue with NDP again, it's outlined in = 7.3 of the v6nd-enhance draft: -- snip -- 7.3. NDP Protocol Gratuitous NA Per RFC 4861, section 7.2.5 and 7.2.6 [RFC4861] requires that unsolicited neighbor advertisements result in the receiver setting it's neighbor cache entry to STALE, kicking off the resolution of the neighbor using neighbor solicitation. -- snip -- Forcing an entry to STALE if you see an unsolicited NA (assuming it = matches the existing NA) seems unnecessary and counterproductive as it = can interrupt traffic to existing hosts. Solving a remotely-exploitable specification problem is much different = than solving a layer-2 compromise. Those are different risks and = require a different solution and mitigation, (eg: duplicate IP detection = in v4 and various layer-2 security features dhcp-guard, etc). - Jared= From pch-b2B3A6689@u-1.phicoh.com Wed Jul 13 10:03:28 2011 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 9B2CE11E817A for ; Wed, 13 Jul 2011 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.232 X-Spam-Level: X-Spam-Status: No, score=-8.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poEerKkyUB7K for ; Wed, 13 Jul 2011 10:03:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id AC66C11E8144 for ; Wed, 13 Jul 2011 10:03:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qh2qL-0001iiC; Wed, 13 Jul 2011 19:03:25 +0200 Message-Id: To: RJ Atkinson Subject: Re: /64 ND DoS From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Wed, 13 Jul 2011 12:51:15 -0400 ." Date: Wed, 13 Jul 2011 19:03:18 +0200 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, 13 Jul 2011 17:03:28 -0000 In your letter dated Wed, 13 Jul 2011 12:51:15 -0400 you wrote: >Perhaps I am confused, but such a document sounds more like an IPv6 Ops WG >item than an IPv6 WG item. So I'm wondering whether this thread belongs >over there rather than here. I started this thread to see if RFC-4861 can improved to the point that just an IPv6 router and a bunch of IPv6 hosts can survive this kind of DoS without any extra devices, configuration, etc. The thread then quickly degenerated into something that belongs more in v6ops. But my preference would be to build it into RFC-4861 instead of all kinds of ah-hoc measures (so far we have seen at least long prefixes, firewalls, explicit registration) From wesley.george@twcable.com Wed Jul 13 11:14:37 2011 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 5B7C121F8BF7 for ; Wed, 13 Jul 2011 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXgzboIYUtCK for ; Wed, 13 Jul 2011 11:14:36 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 78BED21F8BED for ; Wed, 13 Jul 2011 11:14:33 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,526,1304308800"; d="scan'208";a="235221101" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jul 2011 14:13:06 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 13 Jul 2011 14:14:32 -0400 From: "George, Wesley" To: "Joel M. Halpern" , Mikael Abrahamsson Date: Wed, 13 Jul 2011 14:14:31 -0400 Subject: RE: /64 ND DoS Thread-Topic: /64 ND DoS Thread-Index: AcxBel+1zKMvp+CARD+96kkafEEKIAAA+24g Message-ID: <34E4F50CAFA10349A41E0756550084FB0AC176DB@PRVPEXVS04.corp.twcable.com> References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4E1DBFA0.1050103@joelhalpern.com> <4E1DC845.2050607@joelhalpern.com> In-Reply-To: <4E1DC845.2050607@joelhalpern.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 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, 13 Jul 2011 18:14:37 -0000 For some value of "normal and desired" anyway... Smells like a major scale = problem to me for the BRAS to have to maintain that much state, at least if= you're not making a distinction between devices which are directly connect= ed (one pc directly connected to the modem, or a couple hanging off of a sw= itch directly connected to the modem) and those who have a router (even if = it's not NATing) in between and potentially many more devices connected beh= ind it. At least for the case with a router, the alternative is to use IPv6 Prefix = Delegation and allow the downstream CPE router to handle the registration (= be it ND or DHCP) of the devices within the local network. It doesn't elimi= nate the problem of ND DoS, but it does abstract it from the ISP router. Un= fortunately it probably pushes it onto a router that is even less capable o= f handling the issue without dying, but that's still preferable to killing = the ISP router and affecting many more customers at once. Thanks, Wes George -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Joe= l M. Halpern Sent: Wednesday, July 13, 2011 12:31 PM To: Mikael Abrahamsson Cc: ipv6@ietf.org Subject: Re: /64 ND DoS I asked our PMs about this after some earlier discussions, and for many BRAS deployments of IPv6, this restriction is a natural side-effect of normal and desired behavior. I do not know what the feature name is as used in product. (I worry more about what it does, not what it is called in the marketting literature. Sorry.) Yours, Joel On 7/13/2011 12:07 PM, Mikael Abrahamsson wrote: > On Wed, 13 Jul 2011, Joel M. Halpern wrote: > >> For ISPs providing bridged residential services, the ISP normally >> operates on the basis that it gets registration information from all >> the devices in the home. Thus, it does not need to generate ND >> solicitations. > > Is there some description of this behaviour somewhere, what would this > feature be called that I can ask vendors if they have in their equipment? > > Just to be sure, we're now saying that reachability won't be had from > the outside unless the internal device keeps itself "registered" with > the ISP router. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From christopher.morrow@gmail.com Wed Jul 13 11:35:04 2011 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 DE23C228006 for ; Wed, 13 Jul 2011 11:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCO7-67GjN2A for ; Wed, 13 Jul 2011 11:35:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56940228016 for ; Wed, 13 Jul 2011 11:35:04 -0700 (PDT) Received: by iye7 with SMTP id 7so6888444iye.31 for ; Wed, 13 Jul 2011 11:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C0nYjjtS4/cpP0Lm7IiH7/9n+ArDA6xhR+fOvGIIoQQ=; b=tTdemSXR7/f6DMtDc1nmHMvwBN0QF/Lvz04ZGdgpLlVkqskPDI/4x7y1WU4XToxPcz 2vT9fHUAbKzr0MEfPgIAYEPBdORi56h4zZjRaPbwlPqT6FmICpK7Pjso07j9iMS835Mi dDPpY5pPUyWZidvcyeUYnryqCsRSbJshmctNU= MIME-Version: 1.0 Received: by 10.231.253.25 with SMTP id my25mr1243581ibb.126.1310582103968; Wed, 13 Jul 2011 11:35:03 -0700 (PDT) Received: by 10.231.153.207 with HTTP; Wed, 13 Jul 2011 11:35:03 -0700 (PDT) In-Reply-To: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> Date: Wed, 13 Jul 2011 14:35:03 -0400 Message-ID: Subject: Re: /64 ND DoS From: Christopher Morrow To: Fred Baker 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: Wed, 13 Jul 2011 18:35:05 -0000 On Tue, Jul 12, 2011 at 4:39 PM, Fred Baker wrote: > > On Jul 12, 2011, at 4:48 AM, Philip Homburg wrote: > >> Occasionally the subject comes up: /64 (and SLAAC) is bad because it is >> easy to DoS routers by getting to perform too much ND. > > I suppose the same might be true of ARP. Has it been observed in the wild? same does happen with arp, yes... and yes, observed in several fields. From jhw@apple.com Wed Jul 13 17:04:47 2011 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 9F0AB11E8104 for ; Wed, 13 Jul 2011 17:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.699 X-Spam-Level: X-Spam-Status: No, score=-106.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD25c2mqXpr1 for ; Wed, 13 Jul 2011 17:04:47 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 95D6111E8103 for ; Wed, 13 Jul 2011 17:04:39 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LOA00K78QUB56B2@mail-out.apple.com> for ipv6@ietf.org; Wed, 13 Jul 2011 17:04:07 -0700 (PDT) X-AuditID: 11807137-b7c4bae0000013e5-03-4e1e32e8cd63 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 4B.BC.05093.8E23E1E4; Wed, 13 Jul 2011 17:06:00 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOA002IDQUVX160@kencur.apple.com> for ipv6@ietf.org; Wed, 13 Jul 2011 17:04:07 -0700 (PDT) Subject: Re: /64 ND DoS From: james woodyatt In-reply-to: Date: Wed, 13 Jul 2011 17:04:07 -0700 Message-id: <2B229EF3-4C51-4527-A8EB-EEDDDFBD3537@apple.com> References: <6ABB2F79-BE30-416B-8A6E-5F0389A37D2F@cisco.com> <22F6318E46E26B498ABC828879B08D4F1B4835@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <22F6318E46E26B498ABC828879B08D4F1B502A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> To: IETF IPv6 X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OTfeFkZyfwbNNBhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpFGx4IJ7BUbD+k1MF5k7WLk5JAQMJFYsPcpO4QtJnHh3nq2 LkYuDiGBdiaJaTNes4AkeAUEJX5Mvgdkc3AwC8hLHDwvCxJmFtCS+P6olQWifjKTxO5N18GG CguIS1zb/4ERxGYTUJH4dvkuE4jNKWAsMWvjQ2YQm0VAVWL24+0sEIN0JNobzrJC7LKR+HDp F9TQn0wSDzauAisSEZCV2L/pEhvEpfISi1s+M05gFJiF5L5ZCPfNQnLfAkbmVYyCRak5iZWG ZnqJBQU5qXrJ+bmbGEFh11BovoNx+1+5Q4wCHIxKPLybjsr6CbEmlhVX5h5ilOBgVhLhncQv 5yfEm5JYWZValB9fVJqTWnyIUZqDRUmcl1UHKCWQnliSmp2aWpBaBJNl4uCUamA0LNPZvfy7 bnXWse+TC24d2ZyVfNhOJjF91/td1UdWPpxwtmimxVLOixKB+/1i86sfaERXB/28wrRJ7tCM ee+/Pj/C85I1ue01w94FrJ61PDOE/8nlFdfO9/LSW6epOYtp71H1L8fWyHGxb6tYqzqBXfXs bzHp2sRop0dvs0VMvi16qax/UeeWEktxRqKhFnNRcSIAKmUJ0jcCAAA= 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, 14 Jul 2011 00:04:47 -0000 On Jul 13, 2011, at 01:00 , Philip Homburg wrote: > > I'm not aware of any system today that in the presence of just SLAAC can > figure out where the stateful firewall is hiding in the network and how to > get it to open the port you need automatically (i.e. whenever a host allocate > a passive socket). > > If you want to go that route, then IMHO, there is a huge amount of work to be > done. Certainly to get it to work transparently for every possible protocol > that runs on top of IPv6. I don't believe there are any implementations, but I did propose a system to do this: It provoked an interesting and illustrative discussion once people understood just what ubiquitous deployment of a protocol to do this would mean for Internet privacy. -- james woodyatt member of technical staff, core os networking From vishwas.ietf@gmail.com Wed Jul 13 17:57:01 2011 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 E39D621F8AFE for ; Wed, 13 Jul 2011 17:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=1.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ERQuW28rLO for ; Wed, 13 Jul 2011 17:57:01 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0A1F0C34 for ; Wed, 13 Jul 2011 17:56:12 -0700 (PDT) Received: by vws12 with SMTP id 12so6833190vws.31 for ; Wed, 13 Jul 2011 17:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3GBzi5RHCRbiu+KMbmRDb0J8tE5uozdQ9sLYjLRyScg=; b=dpmTSortL76smy7hKe8pCQQiPRSEVkKlOKPSabXpUYwOhp+XZj9OXBb9+9e2300Fkl uIR3oq5E6gd8XNf3oysWF8Uz3994P5eEV1afAg9ktPdNra2gUjd+9y8LoDWsbYPFAw6Y IrcG0AjLulGPK1UZj5tiDq5ZUW7kZCCFfYKYc= MIME-Version: 1.0 Received: by 10.52.29.141 with SMTP id k13mr1805530vdh.391.1310604972331; Wed, 13 Jul 2011 17:56:12 -0700 (PDT) Received: by 10.52.164.226 with HTTP; Wed, 13 Jul 2011 17:56:12 -0700 (PDT) In-Reply-To: References: <4e18d0c5.2727440a.7a71.2906@mx.google.com> Date: Wed, 13 Jul 2011 17:56:12 -0700 Message-ID: Subject: Re: Doubt in Router Advertisement Message From: Vishwas Manral To: Thiruma valavan Content-Type: multipart/alternative; boundary=20cf307c9b0cd1145e04a7fcff67 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, 14 Jul 2011 00:57:02 -0000 --20cf307c9b0cd1145e04a7fcff67 Content-Type: text/plain; charset=ISO-8859-1 Hi Thiruma, The packet capture looks good. I did not get the question however. If there is a question on technology you can mail me, however if the question is on an implementation we can take it offline. Thanks, Vishwas On Wed, Jul 13, 2011 at 5:43 AM, Thiruma valavan wrote: > Vishwas, > > I am having one more doubt in IPv6 Fragmentation > > Router Interface MTU 1500, Host A wants to send a packet with 3,000 data > bytes but MTU is 1500, so it needs to fragment the packet. > > As per RFC 2460, First Packet 40 bytes (IPv6 Header) + 8 bytes Fragment > Header + 1452 Data = 1500 > > Second Packet 40 bytes (IPv6 Header) + 8 bytes Fragment Header > + 1452 Data = 1500 > > Third Packet 40 bytes (IPv6 Header) + 8 bytes > Fragment Header + 96 Data = 1500 > > > > > > > > Thanks, > Thiru > > > > ------------------------------ > Date: Sat, 9 Jul 2011 15:05:47 -0700 > From: vishwas.ietf@gmail.com > To: rathiguru@hotmail.com; ipv6@ietf.org > Subject: Re: Doubt in Router Advertisement Message > > Hi Thiruma, > > From the specs it is clear that the MTU is optional. However if MTU sending > is enabled it should be sent on change too. > > Sounds like a bug in the implementation to me. > > Thanks, > Vishwas > > > > Sent from my Palm Pre on AT&T > > ------------------------------ > On Jul 9, 2011 2:51 AM, Thiruma valavan wrote: > > Hi IETF Group, > > While testing IPV6 Router Advertisement part, I noticed some behaviour that > if I changed router interface MTU value, it won't send Router Advertisement > message immediately instead of waiting to next interval time. > > Is that normal behaviour, > > Thanks & Regards, > Thirumavalavan P > Calsoflabs India Pvt Ltd,Bangalore > ATLEN Group of Company > Mob: +91 9790758035 > --20cf307c9b0cd1145e04a7fcff67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thiruma,
=A0
The packet capture looks good. I did not get the question however.
=A0
If there is a question on technology you can mail me, however if the q= uestion is on an implementation we can take it offline.
=A0
Thanks,
Vishwas
On Wed, Jul 13, 2011 at 5:43 AM, Thiruma valavan= <rathiguru@h= otmail.com> wrote:
Vishwas,
I a= m having one more doubt in IPv6 Fragmentation=A0
Rou= ter Interface MTU 1500, Host A wants to send a packet with 3,000 data bytes= but MTU is 1500, so it needs to fragment the packet.
As = per RFC 2460, First Packet 40 bytes (IPv6 Header) + 8 bytes Fragment Header= + 1452 Data =3D 1500 =A0
=A0 =A0 =A0 =A0 =A0 =A0 Second Packet=A040 bytes (IPv6 Header) + 8 bytes F= ragment Header + 1452 Data =3D 1500 =A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Third Packet =A0 =A0= =A040 byt= es (IPv6 Header) + 8 bytes Fragment Header + =A0 =A096 Data =3D =A01500=A0<= /span>

=A0


=

=


Thanks,Thiru=20
=A0


Date: Sat, 9 Jul 2011 15:05:47 -0700
From: vishwas.ietf@gmail.com
To: rathiguru@hotmail.com;= ipv6@ietf.org
Subject: Re: Doubt in Router Advertisement Message

Hi Thiruma,

From the specs it is clear that the MT= U is optional. However if MTU sending is enabled it should be sent on chang= e too.

Sounds like a bug in the implementation to me.

Thanks,=
Vishwas
Sent from my Palm Pre on AT&T
On Jul 9, 2011 2:51 AM, Thiruma valavan <rathiguru@hotmail.com> wrote:

Hi IE= TF Group,

While testing IPV6 Router Advertisement part, I= noticed some behaviour that if I changed router interface MTU value, it wo= n't send Router Advertisement message immediately instead of waiting to= next interval time.

Is that normal behaviour,=A0

Thanks & R= egards,
Thirumavalavan P=20
Calsoflabs India Pvt Ltd,Bangalore
ATLEN Group of Company

--20cf307c9b0cd1145e04a7fcff67-- From vishwas.ietf@gmail.com Wed Jul 13 17:58:38 2011 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 5737D11E81EB for ; Wed, 13 Jul 2011 17:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f32PI8iBPviw for ; Wed, 13 Jul 2011 17:58:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE4D11E8181 for ; Wed, 13 Jul 2011 17:58:32 -0700 (PDT) Received: by vxi40 with SMTP id 40so6796835vxi.31 for ; Wed, 13 Jul 2011 17:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MynuLCa1dalf9C60eO7F4dipMwaH6pudOGIBDrZQHZ4=; b=wV4YscNKUPGp8GY5rXkN4WJemOHajPUk//CD4+JzPfrJr76p/sKMC4po9GS6r+tq08 MxZXSxY2Xxoe8dEYtJOeJJ3P2l/5cup20Te/pzdOgTruWXIcuaXIugwY7TLBVp6ex06e UBfLeiZSWLhCZbzECXr9z4Oh3UunRPmeYjN3g= MIME-Version: 1.0 Received: by 10.52.181.234 with SMTP id dz10mr1803713vdc.190.1310605111653; Wed, 13 Jul 2011 17:58:31 -0700 (PDT) Received: by 10.52.164.226 with HTTP; Wed, 13 Jul 2011 17:58:31 -0700 (PDT) In-Reply-To: <878vs33mns.fsf@cisco.com> References: <4e18d0c5.2727440a.7a71.2906@mx.google.com> <878vs33mns.fsf@cisco.com> Date: Wed, 13 Jul 2011 17:58:31 -0700 Message-ID: Subject: Re: Doubt in Router Advertisement Message From: Vishwas Manral To: Anupam Kapoor Content-Type: multipart/alternative; boundary=bcaec547c4cf1ef4ce04a7fd08b5 Cc: IETF IPv6 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: Thu, 14 Jul 2011 00:58:38 -0000 --bcaec547c4cf1ef4ce04a7fd08b5 Content-Type: text/plain; charset=ISO-8859-1 Hi Anupam, You are right the RFC allows the optional MTU update. However I would think that if an MTU is sent earlier, it should be resent on MTU change/ update. Thanks, Vishwas On Tue, Jul 12, 2011 at 1:53 AM, Anupam Kapoor wrote: > "Vishwas Manral" writes: > > ,---- > | > From the specs it is clear that the MTU is optional. However if MTU > | > sending is enabled it should be sent on change too. > | > > | > Sounds like a bug in the implementation to me. > `---- > from thiruma's mail it seems that RA's are not sent *immediately* after > changing mtu values. from rfc, as vishwas has pointed out, sending mtu > is optional. > > following snippet from rfc-4861, sec: 6.2.4 > > The information contained in Router Advertisements may change through > actions of system management. For instance, the lifetime of > advertised prefixes may change, new prefixes could be added, a router > could cease to be a router (i.e., switch from being a router to being > a host), etc. In such cases, the router MAY transmit up to > MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the > same rules as when an interface becomes an advertising interface. > > > from above, to me at least, it seems that, the behavior that you see > doesn't point to a flawed implementation. > > kind regards > anupam > --bcaec547c4cf1ef4ce04a7fd08b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Anupam,
=A0
You are right the RFC allows the optional MTU update. However I would = think that if an MTU is sent earlier, it should be resent on MTU change/ up= date.
=A0
Thanks,
Vishwas
On Tue, Jul 12, 2011 at 1:53 AM, Anupam Kapoor <= span dir=3D"ltr"><akapoor@cisco.com= > wrote:
"Vishwas Manral" <<= a href=3D"mailto:vishwas.ietf@gmail.com">vishwas.ietf@gmail.com> wri= tes:

,----
| > From the specs it is clear that the MTU is optiona= l. However if MTU
| > sending is enabled it should be sent on change = too.
| >
| > Sounds like a bug in the implementation to me.
`----
from thiruma's mail it seems that RA's are not sent = *immediately* after
changing mtu values. from rfc, as vishwas has pointe= d out, sending mtu
is optional.

following snippet from rfc-4861, = sec: 6.2.4

=A0 The information contained in Router Advertisements may change throu= gh
=A0 actions of system management. =A0For instance, the lifetime of=A0 advertised prefixes may change, new prefixes could be added, a router<= br>=A0 could cease to be a router (i.e., switch from being a router to bein= g
=A0 a host), etc. =A0In such cases, the router MAY transmit up to
=A0 MA= X_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the
=A0 s= ame rules as when an interface becomes an advertising interface.

from above, to me at least, it seems that, the behavior that you see
doesn't point to a flawed implementation.

kind regards
anupam

--bcaec547c4cf1ef4ce04a7fd08b5-- From akapoor@cisco.com Wed Jul 13 20:46:19 2011 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 BE86111E8083 for ; Wed, 13 Jul 2011 20:46:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqO2lkok8sFY for ; Wed, 13 Jul 2011 20:46:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 72ACA11E80DC for ; Wed, 13 Jul 2011 20:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akapoor@cisco.com; l=361; q=dns/txt; s=iport; t=1310615175; x=1311824775; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=WP7Nm5ZVHK5OyNeuvlcTfk0eWJgXRsoQOYCPbZAj3To=; b=bG9lyZ1edmCAtBFHpZOUWNrAXIAVMQH1QqfEN0St4CUQht0iiR0XCWaW RdG5QnhA6ND831Xpn/6+ja1uT9+JcuBYNEDZ75NUcVN3C9L3fGwb0mdVq kLaVWrKtmaxcYkyixNS/Ps1/NjhmqGZ5AvcJyIgZeAoGjA+Qwzi4PMe7Y c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK9lHk5Io8UR/2dsb2JhbABTp093rEueGQ6GLASHUYsTiVyGfA X-IronPort-AV: E=Sophos;i="4.65,527,1304294400"; d="scan'208";a="101960453" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 03:46:13 +0000 Received: from seldon (dhcp-64-103-156-104.cisco.com [64.103.156.104]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6E3kCib024680; Thu, 14 Jul 2011 03:46:12 GMT From: Anupam Kapoor To: Vishwas Manral Subject: Re: Doubt in Router Advertisement Message References: <4e18d0c5.2727440a.7a71.2906@mx.google.com> <878vs33mns.fsf@cisco.com> Date: Thu, 14 Jul 2011 09:16:12 +0530 In-Reply-To: (Vishwas Manral's message of "Wed, 13 Jul 2011 17:58:31 -0700") Message-ID: <871uxt5xtn.fsf@cisco.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF IPv6 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: Thu, 14 Jul 2011 03:46:19 -0000 Vishwas Manral writes: ,---- | > You are right the RFC allows the optional MTU update. However I would | > think that if an MTU is sent earlier, it should be resent on MTU | > change/ update. `---- thanks for confirming. fundamental question imho is *when* should the update be sent, and *not* if... kind regards anupam From joelja@bogus.com Thu Jul 14 20:00:37 2011 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 9FB8521F8725 for ; Thu, 14 Jul 2011 20:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtx+gZ2wQzkf for ; Thu, 14 Jul 2011 20:00:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D105F21F861B for ; Thu, 14 Jul 2011 20:00:36 -0700 (PDT) Received: from zorch.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6F30TV2046891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2011 03:00:30 GMT (envelope-from joelja@bogus.com) Subject: Re: /64 ND DoS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Thu, 14 Jul 2011 20:00:29 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> References: To: RJ Atkinson X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 15 Jul 2011 03:00:31 +0000 (UTC) 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, 15 Jul 2011 03:00:37 -0000 On Jul 13, 2011, at 9:51 AM, RJ Atkinson wrote: > On Weds 13 July 2011 at 11:54:08 -0400, Joel Halpern wrote: >> There appear to be several different cases, which can be addressed >> by different reasonable mechanisms (not firewalls, and not lengthening >> the subnet prefix.) >> >> For ISPs, I would assume the primary concern is routers connecting >> to subnets used to provide services. A non-dynamic approach to ND >> can address that. >> >> For ISPs providing bridged residential services, the ISP normally >> operates on the basis that it gets registration information >> from all the devices in the home. Thus, it does not need >> to generate ND solicitations. > > Agreed. > > I do think it would be useful to have an informational document > that describes the issue, describes the several cases, and outlines > some reasonable mechanisms (possibly separate mechanisms for each case), > both for the benefit of network operations folks and also for > the benefit of equipment suppliers. we discussed some possible (but certainly incomplete) mitigations in: http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 but we also proposed changes to v6nd so that's why we brought it to 6man > Perhaps I am confused, but such a document sounds more like an IPv6 Ops WG > item than an IPv6 WG item. So I'm wondering whether this thread belongs > over there rather than here. possibly, probably it straddles both groups. > Yours, > > Ran > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From washam.fan@gmail.com Thu Jul 14 20:01:32 2011 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 AEA1211E807A for ; Thu, 14 Jul 2011 20:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.987 X-Spam-Level: X-Spam-Status: No, score=-2.987 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaG3+qmgTFG2 for ; Thu, 14 Jul 2011 20:01:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1A6611E8079 for ; Thu, 14 Jul 2011 20:01:31 -0700 (PDT) Received: by wwe5 with SMTP id 5so614541wwe.13 for ; Thu, 14 Jul 2011 20:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=v+gb/A0cxCak7pMSsP0tcjK0K7Cppjhu8saUAikgfr4=; b=x/umjjCIM6JGPSyr7aJodMTaqenbakQT1kol04Espk6cWSpPNBbV4HLHfAoUGcw1xU RJEU78nFTd4knJVyTRFpg8+t7KR5vIBNrF7LRmtd6DEqJP/Qj0fDljt3KPgwFpNqCLiz NroB8A9YKO2ethjnlX4z/AIqOk1Qv8Hwo7fo0= MIME-Version: 1.0 Received: by 10.216.58.136 with SMTP id q8mr2434038wec.97.1310698890776; Thu, 14 Jul 2011 20:01:30 -0700 (PDT) Received: by 10.216.71.138 with HTTP; Thu, 14 Jul 2011 20:01:30 -0700 (PDT) Date: Fri, 15 Jul 2011 11:01:30 +0800 Message-ID: Subject: Is it legal to set IID to 0? From: Washam Fan To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 15 Jul 2011 03:01:32 -0000 Hi, I don't know if it is legal when I manually set a unicast address with IID=0. Linux allows that and RFC4291 doesn't explicitly prohibit that. I assume it is legal, Right? THanks in advance. washam From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Jul 14 20:19:05 2011 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 2591921F8622 for ; Thu, 14 Jul 2011 20:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv2SrL2e9bZN for ; Thu, 14 Jul 2011 20:19:04 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94321F8610 for ; Thu, 14 Jul 2011 20:19:04 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QhYve-0001Hq-23; Fri, 15 Jul 2011 12:49:02 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 501F93B342; Fri, 15 Jul 2011 12:49:01 +0930 (CST) Date: Fri, 15 Jul 2011 12:49:00 +0930 From: Mark Smith To: Washam Fan Subject: Re: Is it legal to set IID to 0? Message-ID: <20110715124900.0f8ef34f@opy.nosense.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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, 15 Jul 2011 03:19:05 -0000 Hi, On Fri, 15 Jul 2011 11:01:30 +0800 Washam Fan wrote: > Hi, > > I don't know if it is legal when I manually set a unicast address with > IID=0. Linux allows that and RFC4291 doesn't explicitly prohibit that. > I assume it is legal, Right? > That's the subnet router anycast address, so you probably shouldn't use it without the anycast flag being set when you assign it. Using it as a conventional unicast address might make it interact unexpectedly/badly with things like duplicate address detection. See RFC5453, "Reserved IPv6 Interface Identifiers". Regards, mark. From washam.fan@gmail.com Thu Jul 14 22:38:29 2011 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 7B18221F8726 for ; Thu, 14 Jul 2011 22:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vQVE2fsvEjP for ; Thu, 14 Jul 2011 22:38:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF0FC21F8725 for ; Thu, 14 Jul 2011 22:38:28 -0700 (PDT) Received: by wyj26 with SMTP id 26so664773wyj.31 for ; Thu, 14 Jul 2011 22:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=325JAYHUNYowOTpNT1VgJUEMdIEAFRV+9mGYcr3hxHY=; b=ittlUQHxYjMl0tP/DoPd+B20tc+p4pSYaAuHl3pIFsuHI7rFX1ziylpSA0lnwMhDah 84ub5Pu41JrlfviOTyC82d378KRBUwLY8AnrGq4S/XSCNl3qq9FSeOTRdbKY210x/oil pVaoUdPI+eGS2YvsU3Z49LZgT4MioY/Q+LCvk= MIME-Version: 1.0 Received: by 10.216.235.83 with SMTP id t61mr2574887weq.112.1310708307679; Thu, 14 Jul 2011 22:38:27 -0700 (PDT) Received: by 10.216.71.138 with HTTP; Thu, 14 Jul 2011 22:38:27 -0700 (PDT) In-Reply-To: <20110715124900.0f8ef34f@opy.nosense.org> References: <20110715124900.0f8ef34f@opy.nosense.org> Date: Fri, 15 Jul 2011 13:38:27 +0800 Message-ID: Subject: Re: Is it legal to set IID to 0? From: Washam Fan To: Mark Smith 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: Fri, 15 Jul 2011 05:38:29 -0000 Thanks Mark, I was not aware of that before. Thanks again, washam 2011/7/15 Mark Smith : > Hi, > > On Fri, 15 Jul 2011 11:01:30 +0800 > Washam Fan wrote: > >> Hi, >> >> I don't know if it is legal when I manually set a unicast address with >> IID=0. Linux allows that and RFC4291 doesn't explicitly prohibit that. >> I assume it is legal, Right? >> > > That's the subnet router anycast address, so you probably shouldn't use > it without the anycast flag being set when you assign it. Using it as a > conventional unicast address might make it interact > unexpectedly/badly with things like duplicate address detection. > > See RFC5453, "Reserved IPv6 Interface Identifiers". > > > Regards, > mark. > From washam.fan@gmail.com Fri Jul 15 00:03:51 2011 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 0B6DA21F8669 for ; Fri, 15 Jul 2011 00:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGASWeuqtRC9 for ; Fri, 15 Jul 2011 00:03:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 499B721F8666 for ; Fri, 15 Jul 2011 00:03:50 -0700 (PDT) Received: by wyj26 with SMTP id 26so701840wyj.31 for ; Fri, 15 Jul 2011 00:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=a7nMIykFNt2nTdHuuVQdickp1G/vOKwS4WHEKeg+dyY=; b=fHuMy8ecvet+YUzP71iPB1rg2/J5HnjfxZxeHL3V8EppLiE3ee/OdI3qvE5q3oMt+L Ew9TR53YdxcJAIhy2786hkoQLglLLdUXRIL+DX1JDA8RDIbRSOX/YFT2kb1Q5rAD/882 1N9XMQD4JxcjhWSdi9W/Ibb3fQF9oT3fON9Yc= MIME-Version: 1.0 Received: by 10.216.176.76 with SMTP id a54mr185177wem.112.1310713427709; Fri, 15 Jul 2011 00:03:47 -0700 (PDT) Received: by 10.216.71.138 with HTTP; Fri, 15 Jul 2011 00:03:47 -0700 (PDT) Date: Fri, 15 Jul 2011 15:03:47 +0800 Message-ID: Subject: unicast address with non 64 bit prefix From: Washam Fan To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 15 Jul 2011 07:03:51 -0000 Hi, I quoted this paragraph from RFC4291: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. But I am not sure how to interpret the text in a correct way. If I assign an ordinary unicast address (except reserved anycast addresses mentioned in RFC5453) to an interface and the address doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be constructed in Modified EUI-64 format? We are providing WebUI for our customer to manually assign IPv6 addresses, we want to do hygiene check before the actual move. Thanks in advance washam From kerlyn2001@gmail.com Fri Jul 15 04:27:02 2011 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 D14B321F8622 for ; Fri, 15 Jul 2011 04:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFX+S390mMBp for ; Fri, 15 Jul 2011 04:27:02 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCC021F861A for ; Fri, 15 Jul 2011 04:27:02 -0700 (PDT) Received: by iwn39 with SMTP id 39so1162613iwn.31 for ; Fri, 15 Jul 2011 04:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UxpE2PsWc/DcIX1OjyquyChkbBNK3Gt/8a5fDc+P+eI=; b=VmZZt4jnsjECooUR0i2ALKdM2B44tJBy72Z2u9ZHJeaXNkoPugjyJWmY2iAwdFKDKz zxmN0xoM2SRdjqmOAPSdjtqJ9p9NMtBGnAHNwF38H0qdcmJeQHoZP9QKMwBdlAAL069R inYI5/uadsqoc6UAiIzDpusvZ/Jtoi21UKeiM= MIME-Version: 1.0 Received: by 10.42.149.68 with SMTP id u4mr3917485icv.108.1310729219953; Fri, 15 Jul 2011 04:26:59 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.42.224.66 with HTTP; Fri, 15 Jul 2011 04:26:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jul 2011 07:26:59 -0400 X-Google-Sender-Auth: P2k82cOZZXBC8Z8psRmCt78Fqlg Message-ID: Subject: Re: unicast address with non 64 bit prefix From: Kerry Lynn To: Washam Fan Content-Type: multipart/alternative; boundary=90e6ba1eff0c8d523904a819ed17 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, 15 Jul 2011 11:27:02 -0000 --90e6ba1eff0c8d523904a819ed17 Content-Type: text/plain; charset=ISO-8859-1 See also section 2.5.4 of RFC 4291: "All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1." So I'd say the answer is the IID MUST be 64 bits long, and MUST satisfy the properties of uniqueness discussed in 2.5.1 (and set the "u" bit accordingly). An IID in modified EUI-64 format satisfies these requirements, but in general IIDs are formed according to rules specified by the particular "IP over ..." RFC, e.g. RFC 4944. For example, an actual EUI-64 may be preferred for interfaces that have them. Finally, those with privacy concerns may elect methods for creating IIDs that mask the underlying hardware identifier; see RFC 3041. HTH, -K- On Fri, Jul 15, 2011 at 3:03 AM, Washam Fan wrote: > Hi, > > I quoted this paragraph from RFC4291: > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > But I am not sure how to interpret the text in a correct way. > > If I assign an ordinary unicast address (except reserved anycast > addresses mentioned in RFC5453) to an interface and the address > doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be > constructed in Modified EUI-64 format? > > We are providing WebUI for our customer to manually assign IPv6 > addresses, we want to do hygiene check before the actual move. > > Thanks in advance > washam > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --90e6ba1eff0c8d523904a819ed17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See also section 2.5.4 of RFC 4291:
"All Global Unicast addresses = other than those that start with binary
=A0000 have a 64-bit inte= rface ID field (i.e., n + m =3D 64), formatted as
=A0described in= Section 2.5.1."

So I'd say the answer is the IID MUST be 64 bits lo= ng, and MUST
satisfy=A0the properties of uniqueness discussed in = 2.5.1 (and set the
"u"=A0bit accordingly). =A0An IID in= modified EUI-64 format satisfies these
requirements, but in general IIDs are formed according to rules specif= ied
by the particular "IP over ..." RFC, e.g. RFC 4944.= =A0For example, an
actual EUI-64 may be preferred for interfaces= that have them.
Finally,=A0those with privacy concerns may elect methods for creating<= /div>
IIDs=A0that mask the underlying hardware identifier; see RFC 3041= .

HTH, -K-

On Fr= i, Jul 15, 2011 at 3:03 AM, Washam Fan <washam.fan@gmail.com> wrote:
Hi,

I quoted this paragraph from RFC4291:

=A0 For all unicast addresses, except those that start with the binary
=A0 value 000, Interface IDs are required to be 64 bits long and to be
=A0 constructed in Modified EUI-64 format.

But I am not sure how to interpret the text in =A0a correct way.

If I assign an ordinary unicast address (except reserved anycast
addresses mentioned in RFC5453) to an interface and the address
doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be
constructed in Modified EUI-64 format?

We are providing WebUI for our customer to manually assign IPv6
addresses, we want to do hygiene check before the actual move.

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

--90e6ba1eff0c8d523904a819ed17-- From rja.lists@gmail.com Fri Jul 15 06:31:16 2011 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 671F821F864F; Fri, 15 Jul 2011 06:31:16 -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_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lAqWR184T62; Fri, 15 Jul 2011 06:31:15 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9A92C21F85C0; Fri, 15 Jul 2011 06:31:15 -0700 (PDT) Received: by qyk29 with SMTP id 29so892891qyk.10 for ; Fri, 15 Jul 2011 06:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=nqry6kXWiIjCHSL/FBU3elfHlJXGUXZnBB/aEBA1xBg=; b=FNbckt44itmTL5Q9OYVMJUfG4f43n4m8I7vd+PuyCHth6aj38stX5Fp8GCp/WHhh+j XUIr6MpWxOX/X+9bSnDDDhUzcFPhGiTV7n4K7GLRwTHBYyxgLNZL5zwVn7DQmeTjA827 Emsg3hBMhraJuq+Hr0ILvAQbkS26ln2/Azgxg= Received: by 10.224.208.196 with SMTP id gd4mr3207142qab.101.1310736674884; Fri, 15 Jul 2011 06:31:14 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id p4sm886052qct.24.2011.07.15.06.31.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jul 2011 06:31:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Best venue to begin addressing the "/64 ND DoS" concerns ? From: RJ Atkinson In-Reply-To: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> Date: Fri, 15 Jul 2011 09:31:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> To: ipv6@ietf.org, v6ops@ietf.org X-Mailer: Apple Mail (2.1084) 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, 15 Jul 2011 13:31:16 -0000 On 14 Jul 2011, at 23:00 , Joel Jaeggli wrote: > On Jul 13, 2011, at 9:51 AM, RJ Atkinson wrote: >=20 >> On Weds 13 July 2011 at 11:54:08 -0400, Joel Halpern wrote: >>> There appear to be several different cases, which can be addressed=20= >>> by different reasonable mechanisms (not firewalls, and not = lengthening >>> the subnet prefix.) >>>=20 >>> For ISPs, I would assume the primary concern is routers connecting=20= >>> to subnets used to provide services. A non-dynamic approach to ND >>> can address that. >>>=20 >>> For ISPs providing bridged residential services, the ISP normally=20 >>> operates on the basis that it gets registration information=20 >>> from all the devices in the home. Thus, it does not need >>> to generate ND solicitations. >>=20 >> Agreed. >>=20 >> I do think it would be useful to have an informational document >> that describes the issue, describes the several cases, and outlines=20= >> some reasonable mechanisms (possibly separate mechanisms for each = case), >> both for the benefit of network operations folks and also for >> the benefit of equipment suppliers. >=20 > we discussed some possible (but certainly incomplete) mitigations in: >=20 > http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 >=20 > but we also proposed changes to v6nd so that's why we brought it to = 6man >=20 >> Perhaps I am confused, but such a document sounds more like an IPv6 = Ops WG=20 >> item than an IPv6 WG item. So I'm wondering whether this thread = belongs=20 >> over there rather than here. >=20 > possibly, probably it straddles both groups. (First, a broad apology for cross-posting this note, which is in a thread that originated on the IPv6 WG mailing list. I encourage authors of follow-up notes to consider whether their follow-up=20 might belong only on 1 of these 2 lists. WG Chair guidance=20 about proper place for follow-up discussion would also be welcome. :-) I apologise for being unclear. The document I was trying to propose in the quoted text above was NOT about protocol changes, but instead would focus on extant mitigations -- so the document I was proposing would more obviously seem to fit in IPv6 Ops WG. To some extent, I would prefer an approach where IPv6 Ops would work on that informational document (threats/concerns, operational use cases, existing mitigations that could be deployed) first. Then, if there were use cases not adequately covered by the material in that (proposed) IPv6 Ops WG document, the IPv6 WG could use that IPv6 Ops WG document to examine potential protocol specification changes on a much more=20 informed basis. I am concerned that the current document is inadvertently=20 "putting the cart in front of the horse" by going straight=20 to the IPv6 WG, without starting with an informational=20 "issues and existing-mitigations" type document over in the=20 IPv6 Ops WG. Operator input on this topic would be strongly=20 beneficial since this is fundamentally an operations issue. I'm also concerned that most of the operational folks are active=20 in the IPv6 Ops WG , while only some of those folks are active=20 in IPv6 WG. So it would seem better to start working these concerns over there and later, after the IPv6 Ops WG has reached some conclusions about the issues/existing mitigations, possibly bring that output to the IPv6 WG to drive discussion of potential protocol specification changes in a more informed way than we seem to be achieving just now. Perhaps I am=20 more nearly an outlier in my concern that we not start with protocol modification discussions and instead start with a separate document covering the concerns/issues, use cases, and existing/known mitigations (possibly organised by use case). Yours, Ran Atkinson From pch-b2B3A6689@u-1.phicoh.com Fri Jul 15 10:35:09 2011 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 D251621F8B8C; Fri, 15 Jul 2011 10:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDHbGPv9-qUK; Fri, 15 Jul 2011 10:35:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9D56521F8B70; Fri, 15 Jul 2011 10:35:08 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QhmI4-0001iqC; Fri, 15 Jul 2011 19:35:04 +0200 Message-Id: To: RJ Atkinson Subject: Re: Best venue to begin addressing the "/64 ND DoS" concerns ? From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> In-reply-to: Your message of "Fri, 15 Jul 2011 09:31:12 -0400 ." Date: Fri, 15 Jul 2011 19:35:01 +0200 Cc: v6ops@ietf.org, 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, 15 Jul 2011 17:35:10 -0000 In your letter dated Fri, 15 Jul 2011 09:31:12 -0400 you wrote: >To some extent, I would prefer an approach where IPv6 Ops would work >on that informational document (threats/concerns, operational use cases, >existing mitigations that could be deployed) first. Then, if there >were use cases not adequately covered by the material in that (proposed) >IPv6 Ops WG document, the IPv6 WG could use that IPv6 Ops WG document >to examine potential protocol specification changes on a much more >informed basis. I could be wrong, but the impression I got from the various ops lists is that the way you deal with this attack is to avoid using RFC-4862 and/or RFC-4861. For example: - Just use link local on a link between two routers - Configure a much longer prefix (/120) - Have /128s on separate interfaces - Use a static neighbor cache and then disable ND - (From draft-gashinsky-v6nd-enhance) Have hosts inject /128s And there is also - Use a statefull firewall (and break end-to-end connectivity). draft-gashinsky-v6nd-enhance give a nice overview, but more importantly already tries to modify RFC-4861. If v6ops first wants to spend time writing a requirements document, then that's fine with me. But to me it seems more productive to explore the design space, write an informational document about that and then solicit feedback from v6ops on whether there are any options that seem to make some kind of sense in their environment. >Operator input on this topic would be strongly >beneficial since this is fundamentally an operations issue. I would classify a protocol that is at the heart of IPv6 and that is subject of a relatively low-tech DoS as a protocol problem and not as an ops problem. (Of course, it remains an ops problem until the protocol is fixed) From brian.e.carpenter@gmail.com Fri Jul 15 15:25:31 2011 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 216B421F8A58 for ; Fri, 15 Jul 2011 15:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbmJm-rDsUqX for ; Fri, 15 Jul 2011 15:25:30 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9CED821F85B9 for ; Fri, 15 Jul 2011 15:25:29 -0700 (PDT) Received: by fxe4 with SMTP id 4so4112479fxe.27 for ; Fri, 15 Jul 2011 15:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V11epzAVwY+AGijXlGP15PKoLkQYQofNgorIDr/k66U=; b=m3D8Jo1D7dkQlfvp72ESk2xYka034SLWzP+Vw8HjzZI4J/kjmcNAMTwMKVzd5jvcSd ToTppAMDkhYGIV5iROUpKqKnACMRWfxTybVBoBQ7YVmP5rev9U+w7exQFZEP/1YOCWRy ntI3V4cv2gdYSrK3rZyBtdsB1NpUV4363oToA= Received: by 10.223.72.80 with SMTP id l16mr6001216faj.33.1310768726327; Fri, 15 Jul 2011 15:25:26 -0700 (PDT) Received: from ?IPv6:2001:388:f000::35? ([2001:388:f000::35]) by mx.google.com with ESMTPS id w15sm1075256faj.47.2011.07.15.15.25.23 (version=SSLv3 cipher=OTHER); Fri, 15 Jul 2011 15:25:25 -0700 (PDT) Message-ID: <4E20BE47.5040700@gmail.com> Date: Sat, 16 Jul 2011 10:25:11 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Washam Fan Subject: Re: unicast address with non 64 bit prefix References: In-Reply-To: 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: Fri, 15 Jul 2011 22:25:31 -0000 The authors of RFC 4291 chose not to use the upper case normative keyword convention defined in RFC 2119. Therefore, 'required' means what in means in plain English (i.e. REQUIRED in RFC2119ish). Brian On 2011-07-15 19:03, Washam Fan wrote: > Hi, > > I quoted this paragraph from RFC4291: > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > But I am not sure how to interpret the text in a correct way. > > If I assign an ordinary unicast address (except reserved anycast > addresses mentioned in RFC5453) to an interface and the address > doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be > constructed in Modified EUI-64 format? > > We are providing WebUI for our customer to manually assign IPv6 > addresses, we want to do hygiene check before the actual move. > > Thanks in advance > washam > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From kerlyn2001@gmail.com Fri Jul 15 17:57:56 2011 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 36F2F21F8794 for ; Fri, 15 Jul 2011 17:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp+O3uBWr9Zf for ; Fri, 15 Jul 2011 17:57:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46E2521F8788 for ; Fri, 15 Jul 2011 17:57:55 -0700 (PDT) Received: by iye7 with SMTP id 7so1741849iye.31 for ; Fri, 15 Jul 2011 17:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ySbKHpZfUh2TfpuzcluWTTcGUfFXVppDgUe7jLlJDc4=; b=ZGKDVhSkt3Le3dHpECZATGE8fKsNIyWVYrRrL4OPGSalMjQBOIYpviht//uMCNJFfs D9yxCfVb4XxvYgG6An2JHc/v/P9Ak45y9v7yaiWfs/zYHMymp7GW9jFOnfJ+dUid3XWX f5RNDD9/LvuNgcIL6l9Nmt9zT3T21F5lmspU4= MIME-Version: 1.0 Received: by 10.42.149.68 with SMTP id u4mr4666459icv.108.1310777874847; Fri, 15 Jul 2011 17:57:54 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.42.224.66 with HTTP; Fri, 15 Jul 2011 17:57:54 -0700 (PDT) In-Reply-To: <4E20BE47.5040700@gmail.com> References: <4E20BE47.5040700@gmail.com> Date: Fri, 15 Jul 2011 20:57:54 -0400 X-Google-Sender-Auth: ggk1oUQ-c42Yq4qnSDxj8cjUpXE Message-ID: Subject: Re: unicast address with non 64 bit prefix From: Kerry Lynn To: Brian E Carpenter Content-Type: multipart/alternative; boundary=90e6ba1eff0c9c194404a82541c4 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, 16 Jul 2011 00:57:56 -0000 --90e6ba1eff0c9c194404a82541c4 Content-Type: text/plain; charset=ISO-8859-1 Brian, you're quite right. I had in mind only one particular class of IID. Washam, see Appendix A of RFC 4291 regarding modified EUI-64 IIDs with "u"=0. Also, RFC 3041 has been obsoleted; see RFC 4941 and its errata if privacy issues apply in your situation. -K- On Fri, Jul 15, 2011 at 6:25 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > The authors of RFC 4291 chose not to use the upper case normative > keyword convention defined in RFC 2119. Therefore, 'required' means > what in means in plain English (i.e. REQUIRED in RFC2119ish). > > Brian > > On 2011-07-15 19:03, Washam Fan wrote: > > Hi, > > > > I quoted this paragraph from RFC4291: > > > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long and to be > > constructed in Modified EUI-64 format. > > > > But I am not sure how to interpret the text in a correct way. > > > > If I assign an ordinary unicast address (except reserved anycast > > addresses mentioned in RFC5453) to an interface and the address > > doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be > > constructed in Modified EUI-64 format? > > > > We are providing WebUI for our customer to manually assign IPv6 > > addresses, we want to do hygiene check before the actual move. > > > > Thanks in advance > > washam > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > --90e6ba1eff0c9c194404a82541c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, you're quite right. =A0I had in mind only one particular class o= f IID.

Washam, see Appendix A of RFC 4291 regarding modi= fied EUI-64 IIDs
with "u"=3D0. =A0Also, RFC 3041 has be= en obsoleted; see RFC 4941 and
its errata if privacy issues apply in your situation.

-K-


On Fri, Jul 1= 5, 2011 at 6:25 PM, Brian E Carpenter <brian.e.carpenter@gmail.c= om> wrote:
The authors of RFC 4291 chose not to use the= upper case normative
keyword convention defined in RFC 2119. Therefore, 'required' means=
what in means in plain English (i.e. REQUIRED in RFC2119ish).

=A0 Brian

On 2011-07-15 19:03, Washam Fan wrote:
> Hi,
>
> I quoted this paragraph from RFC4291:
>
> =A0 =A0For all unicast addresses, except those that start with the bin= ary
> =A0 =A0value 000, Interface IDs are required to be 64 bits long and to= be
> =A0 =A0constructed in Modified EUI-64 format.
>
> But I am not sure how to interpret the text in =A0a correct way.
>
> If I assign an ordinary unicast address (except reserved anycast
> addresses mentioned in RFC5453) to an interface and the address
> doesn't start with 000, MUST the prefix be 64 bits? MUST the IID b= e
> constructed in Modified EUI-64 format?
>
> We are providing WebUI for our customer to manually assign IPv6
> addresses, we want to do hygiene check before the actual move.
>
> Thanks in advance
> washam
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= br> > -------------------------------------------------------------------- >
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--90e6ba1eff0c9c194404a82541c4-- From washam.fan@gmail.com Sat Jul 16 09:02:57 2011 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 5D36321F8679 for ; Sat, 16 Jul 2011 09:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWjnmk182eH9 for ; Sat, 16 Jul 2011 09:02:56 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6A65621F8672 for ; Sat, 16 Jul 2011 09:02:56 -0700 (PDT) Received: by wwg11 with SMTP id 11so2040514wwg.1 for ; Sat, 16 Jul 2011 09:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=93gelC6XoQTGiZBGYdvm8DYMursFGOvXhhvoq+Nc01U=; b=ARE/Z9GpeJ6gL8+0RdTJnlf4PlZO9X0PONZZr8oiyhGu5Mi7ZHMVJVxfp+0wG17phf H88Aevq6O2u3RVYnSyUgNc/DZQJj91ecFpR6tIf+ki+LkWMpxXiBadUJmNRqOVdm4Raj 8ZGzpgZTxiLGWvXXlgxo5ilGuHOFO9Rek5F14= MIME-Version: 1.0 Received: by 10.216.66.147 with SMTP id h19mr1393142wed.97.1310832175552; Sat, 16 Jul 2011 09:02:55 -0700 (PDT) Received: by 10.216.71.138 with HTTP; Sat, 16 Jul 2011 09:02:55 -0700 (PDT) In-Reply-To: References: <4E20BE47.5040700@gmail.com> Date: Sun, 17 Jul 2011 00:02:55 +0800 Message-ID: Subject: Re: unicast address with non 64 bit prefix From: Washam Fan To: Kerry Lynn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Brian E Carpenter 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, 16 Jul 2011 16:02:57 -0000 THanks Kerry and Brian, Now we provide 3 parameters to our customers to configure a IPv6 address manually: 128bit address, subnet prefix and default gateway (optional, if it is provided, it should be within the same subnet with the 128bit address). Should we set subnet prefix to a fixed value 64 if the 128bit address starts with 001-111? (ipv6 is a new feature in our appliance, we don't have much experiences about it) Thanks, washam PS: should we allow our customer configure 128bit address starting with 000 in the first place? 2011/7/16 Kerry Lynn : > Brian, you're quite right. =A0I had in mind only one particular class of = IID. > Washam, see Appendix A of RFC 4291 regarding modified EUI-64 IIDs > with "u"=3D0. =A0Also, RFC 3041 has been obsoleted; see RFC 4941 and > its errata if privacy issues apply in your situation. > -K- > > > On Fri, Jul 15, 2011 at 6:25 PM, Brian E Carpenter > wrote: >> >> The authors of RFC 4291 chose not to use the upper case normative >> keyword convention defined in RFC 2119. Therefore, 'required' means >> what in means in plain English (i.e. REQUIRED in RFC2119ish). >> >> =A0 Brian >> >> On 2011-07-15 19:03, Washam Fan wrote: >> > Hi, >> > >> > I quoted this paragraph from RFC4291: >> > >> > =A0 =A0For all unicast addresses, except those that start with the bin= ary >> > =A0 =A0value 000, Interface IDs are required to be 64 bits long and to= be >> > =A0 =A0constructed in Modified EUI-64 format. >> > >> > But I am not sure how to interpret the text in =A0a correct way. >> > >> > If I assign an ordinary unicast address (except reserved anycast >> > addresses mentioned in RFC5453) to an interface and the address >> > doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be >> > constructed in Modified EUI-64 format? >> > >> > We are providing WebUI for our customer to manually assign IPv6 >> > addresses, we want to do hygiene check before the actual move. >> > >> > Thanks in advance >> > washam >> > -------------------------------------------------------------------- >> > 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 fred@cisco.com Sat Jul 16 10:38:57 2011 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 7B94121F874E; Sat, 16 Jul 2011 10:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.375 X-Spam-Level: X-Spam-Status: No, score=-104.375 tagged_above=-999 required=5 tests=[AWL=-1.776, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0a8raq2w8mF; Sat, 16 Jul 2011 10:38:56 -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 AB82521F8726; Sat, 16 Jul 2011 10:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2712; q=dns/txt; s=iport; t=1310837937; x=1312047537; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=VkPSyHw9FzxlRz9YqZ/7CcrwQ1APEkUiZofALL+GoCA=; b=PWwQfPJznQjI0tjDUu5IO+de+WraAq0FEbP4I8rCtu069ZSnwhhOZJW1 aoc1AIn8GHmrxTFXmnYTZ87RKNbnm9FyNMWNoE+/eMKbVVw3pfKf2ThPG GFXI3RPyNfs8W4Glgk2t6AeZ7GPHACxB0snv38iburPw5qIVOGhq964qx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGjMIU6rRDoH/2dsb2JhbABSp3V3iHyiWJ1DhV1fBIdUixKFAYt0 X-IronPort-AV: E=Sophos;i="4.67,214,1309737600"; d="scan'208";a="3602199" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 16 Jul 2011 17:38:55 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6GHcsaH030148; Sat, 16 Jul 2011 17:38:54 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Sat, 16 Jul 2011 10:38:54 -0700 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Sat, 16 Jul 2011 10:38:54 -0700 Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 16 Jul 2011 10:38:45 -0700 Message-Id: <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, 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, 16 Jul 2011 17:38:57 -0000 On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote: > I apologise for being unclear. The document I was trying to propose = in the quoted text above was NOT about protocol changes, but instead = would focus on extant mitigations -- so the document I was proposing = would more obviously seem to fit in IPv6 Ops WG. Sounds reasonable to me. One general consideration in this note. In addition to the fact of = multiple prefixes on a LAN, IPv6 Privacy Addresses (RFC 4491) are a case = in which a single interface (and therefore MAC address) might = legitimately have multiple addresses within the same prefix. Unless I am = mistaken, Windows by default creates an address daily but keeps each = such address active for a week, so any case in which Windows would use = one IPv4 address, at any given time it will consider seven IPv6 = addresses to be active. In addition, virtual machines in data centers = amplify address use; one could imagine the address of a virtual machine = serving a single user or service to be the counterpart of a = locator+identifier in the sense that RFC 1992 uses the terms. So a part = of the advice to implementers is to expect a much larger number of = active addresses at any given time to be normal. There are of course ways to simplify that in implementation. In a = host/router's neighbor tables, it would make sense to keep a "used" = flag. At least for routers (which normally have most of the hosts in a = subnet as neighbors most of the time), it is common to periodically = ARP/ND each address unicast and cull the table if it fails to respond = (rather than simply timing the address out). One could modify that = slightly by setting a flag in the neighbor entry when a datagram is sent = to the address, and on the periodic sweep culling addresses that were = not used and refreshing addresses that have been used. There is also a place for LRU-style behavior. If the neighbor table is = finite in size, keep an LRU list, moving used and new entries to the = tail and simply overwriting entries from the front when needed. If there = is no hard bound on the neighbor table besides the size of memory, one = could imagine sweeping at a rate comparable to its size - every mumble = time units culling/refreshing a percentage of the table.=20 Where I worry is the concept of a hard limit on address count per MAC = address, due to the existence of virtual hosts. Speaking as a vendor of = the equipment we're concerned about here, I would rather provide an = option that enables the administrator to buy more memory if that's = what's needed than force him into a situation that might be suboptimal = for his network.=20= From fred@cisco.com Sat Jul 16 10:42:06 2011 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 4856421F869D; Sat, 16 Jul 2011 10:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.304 X-Spam-Level: X-Spam-Status: No, score=-104.304 tagged_above=-999 required=5 tests=[AWL=-1.705, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAJZo2+1idxh; Sat, 16 Jul 2011 10:42:04 -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 CA56621F867D; Sat, 16 Jul 2011 10:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=562; q=dns/txt; s=iport; t=1310838124; x=1312047724; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=qRYEiywIbn+Ijn38ZdtLkFVXcIginHYmJHR8J9vslFQ=; b=FRFaEZeClZUugOrQdsHEDzAt4yihDQWljvJ2RnuicezjJJG+xryn5+lM kcFnmXp1wVAKVLTjMvuEcCCCWIRsLCU5pDbMW4q0oFKtOlkyYFW9f2geN lJ+0wmrlNqUclf/hVfmC5SbAiSH5c9nxsvH+lkYSlcc6th2ZaBkZBWFOQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABDNIU6rRDoH/2dsb2JhbABSp3V3iHyiWJ1DhV1fBIdUixKFAYt0 X-IronPort-AV: E=Sophos;i="4.67,214,1309737600"; d="scan'208";a="3602996" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2011 17:42:04 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6GHg3hG031554; Sat, 16 Jul 2011 17:42:03 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Sat, 16 Jul 2011 10:42:03 -0700 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Sat, 16 Jul 2011 10:42:03 -0700 Subject: Re: Best venue to begin addressing the "/64 ND DoS" concerns ? Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 16 Jul 2011 10:41:55 -0700 Message-Id: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson 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, 16 Jul 2011 17:42:06 -0000 On Jul 15, 2011, at 10:35 AM, Philip Homburg wrote: > I could be wrong, but the impression I got from the various ops lists = is that > the way you deal with this attack is to avoid using RFC-4862 and/or = RFC-4861. I can imagine using DHCPv6 instead of SLAAC (RFC 4862 and the RS/RA = component of RFC 4861). The counterpart to ARP is the NS/NA component of = RFC 4861; I think you might find that helpful to keep. That said, I do think you may find SLAAC more scalable than DHCPv6 = address allocation. At least that's why it was developed.= From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 16 19:02:45 2011 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 1CFDB21F86C2; Sat, 16 Jul 2011 19:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mbuE2-YHwv2; Sat, 16 Jul 2011 19:02:44 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33321F86C1; Sat, 16 Jul 2011 19:02:44 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiGgo-0008KX-Hp; Sun, 17 Jul 2011 11:32:38 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 319473B342; Sun, 17 Jul 2011 11:32:38 +0930 (CST) Date: Sun, 17 Jul 2011 11:32:37 +0930 From: Mark Smith To: Fred Baker Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Message-ID: <20110717113237.0137abcd@opy.nosense.org> In-Reply-To: <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson 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, 17 Jul 2011 02:02:45 -0000 On Sat, 16 Jul 2011 10:38:45 -0700 Fred Baker wrote: > > On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote: > > > I apologise for being unclear. The document I was trying to propose in the quoted text above was NOT about protocol changes, but instead would focus on extant mitigations -- so the document I was proposing would more obviously seem to fit in IPv6 Ops WG. > > Sounds reasonable to me. > > > Where I worry is the concept of a hard limit on address count per MAC address, due to the existence of virtual hosts. Speaking as a vendor of the equipment we're concerned about here, I would rather provide an option that enables the administrator to buy more memory if that's what's needed than force him into a situation that might be suboptimal for his network. The quite novel technique of allocation transient addresses to applications/processes to assist with firewalling also takes advantage of IPv6's large address space and that hosts can have multiple addresses at once. It'd be a shame to loose the opportunity to do that or similar innovative things with the large IPv6 address space - "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host", Peter M. Gleitz and Steven M. Bellovin https://www.cs.columbia.edu/~smb/papers/tarp.pdf ___________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From washam.fan@gmail.com Sat Jul 16 19:45:42 2011 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 D181921F8763 for ; Sat, 16 Jul 2011 19:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJHmW+HgfMMy for ; Sat, 16 Jul 2011 19:45:42 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC4721F86F4 for ; Sat, 16 Jul 2011 19:45:41 -0700 (PDT) Received: by wwe5 with SMTP id 5so1547289wwe.13 for ; Sat, 16 Jul 2011 19:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PArnXBDaYWUkPBN1YJON8JE6xPoX2X1HVbv+2xWjjD4=; b=xs06NKlpuoDxB4FhteOo4PSyokdlh1u1c0YB7o7ezIcsQ5UW63L7VUSlF9QQ7y20UH dAuw6c2a4bEjJ0feUIl9uz1O1TbpA8+qKjmskGbPSkIK/QcW0QYfPhLdcf30r+Z22Otl ANOgL+AZA/eOmb/cRdVLQam+Fjw4S1yPZ7ywQ= MIME-Version: 1.0 Received: by 10.216.176.76 with SMTP id a54mr1676449wem.112.1310870739546; Sat, 16 Jul 2011 19:45:39 -0700 (PDT) Received: by 10.216.71.138 with HTTP; Sat, 16 Jul 2011 19:45:39 -0700 (PDT) In-Reply-To: References: <4E20BE47.5040700@gmail.com> Date: Sun, 17 Jul 2011 10:45:39 +0800 Message-ID: Subject: Re: unicast address with non 64 bit prefix From: Washam Fan To: Kerry Lynn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 17 Jul 2011 02:45:42 -0000 Hi Kerry, Yes, they can be derived from PIO. But is there any possibility customers manually set subnet prefix? Now, we disable SLAAC on the appliance (due to it provides important services like web proxy/cache, web filtering, traffic monitoring) and use the 3 parameters to configure IPv6 addresses. #ip -6 addr add / dev eth0 #ip -6 route add default via in our current design, the customer is allowed to set prefix-len to non-64 value like 65. But according to discussions in this thread, it seems to me we SHOULD NOT allow our customers to set prefix-len to non-64 value unless they assign an address starting with 000.(Ask again, should we allow our customers to assign an address starting with 000 in first place?) Are you saying we should only allow customers to set IID. let prefix-len and gw-addr derived from ND interactions? As I stated before, we are adding ipv6 feature to our product, we don't expect ipv6 will be used by majority of our customers ( IPv6 is disable by default on our products). But we want to do the right thing at the begining. THanks, washam 2011/7/17 Kerry Lynn : > The subnet prefix generally comes from the router on the link > via Router Advertisements (e.g., Google radvd). =A0It's not > something the customer needs to set. > -K- > > On Sat, Jul 16, 2011 at 12:02 PM, Washam Fan wrote= : >> >> THanks Kerry and Brian, >> >> Now we provide 3 parameters to our customers to configure a IPv6 >> address manually: 128bit address, subnet prefix and default gateway >> (optional, if it is provided, it should be within the same subnet with >> the 128bit address). Should we set subnet prefix to a fixed value 64 >> if the 128bit address starts with 001-111? >> (ipv6 is a new feature in our appliance, we don't have much >> experiences about it) >> Thanks, >> washam >> PS: should we allow our customer configure 128bit address starting >> with 000 in the first place? >> >> >> 2011/7/16 Kerry Lynn : >> > Brian, you're quite right. =A0I had in mind only one particular class = of >> > IID. >> > Washam, see Appendix A of RFC 4291 regarding modified EUI-64 IIDs >> > with "u"=3D0. =A0Also, RFC 3041 has been obsoleted; see RFC 4941 and >> > its errata if privacy issues apply in your situation. >> > -K- >> > >> > >> > On Fri, Jul 15, 2011 at 6:25 PM, Brian E Carpenter >> > wrote: >> >> >> >> The authors of RFC 4291 chose not to use the upper case normative >> >> keyword convention defined in RFC 2119. Therefore, 'required' means >> >> what in means in plain English (i.e. REQUIRED in RFC2119ish). >> >> >> >> =A0 Brian >> >> >> >> On 2011-07-15 19:03, Washam Fan wrote: >> >> > Hi, >> >> > >> >> > I quoted this paragraph from RFC4291: >> >> > >> >> > =A0 =A0For all unicast addresses, except those that start with the = binary >> >> > =A0 =A0value 000, Interface IDs are required to be 64 bits long and= to be >> >> > =A0 =A0constructed in Modified EUI-64 format. >> >> > >> >> > But I am not sure how to interpret the text in =A0a correct way. >> >> > >> >> > If I assign an ordinary unicast address (except reserved anycast >> >> > addresses mentioned in RFC5453) to an interface and the address >> >> > doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be >> >> > constructed in Modified EUI-64 format? >> >> > >> >> > We are providing WebUI for our customer to manually assign IPv6 >> >> > addresses, we want to do hygiene check before the actual move. >> >> > >> >> > Thanks in advance >> >> > washam >> >> > -------------------------------------------------------------------= - >> >> > 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 kauer@biplane.com.au Sat Jul 16 20:35:42 2011 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 043F921F86B9 for ; Sat, 16 Jul 2011 20:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioIl09q0PxsC for ; Sat, 16 Jul 2011 20:35:39 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 101B621F86C1 for ; Sat, 16 Jul 2011 20:35:37 -0700 (PDT) Received: from merimb6.lnk.telstra.net ([120.151.11.220] helo=[192.168.150.69]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QiI8k-00045t-M1 for ipv6@ietf.org; Sat, 16 Jul 2011 23:35:34 -0400 Subject: Re: unicast address with non 64 bit prefix From: Karl Auer To: ipv6@ietf.org In-Reply-To: References: <4E20BE47.5040700@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-G74gJL4V2pIapXVbpoD+" Date: Sun, 17 Jul 2011 13:35:31 +1000 Message-ID: <1310873731.2385.7.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 17 Jul 2011 03:35:42 -0000 --=-G74gJL4V2pIapXVbpoD+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2011-07-17 at 10:45 +0800, Washam Fan wrote: > in our current design, the customer is allowed to set prefix-len to > non-64 value like 65. But according to discussions in this thread, it > seems to me we SHOULD NOT allow our customers to set prefix-len to > non-64 value unless they assign an address starting with 000.(Ask > again, should we allow our customers to assign an address starting > with 000 in first place?) I suggest either a warning/confirm if they use a non-64-bit IID ("You have just configured a non-standard interface ID! Proceed?") or alternatively have a checkbox somewhere "allow non-64-bit (non-standard) interface IDs". Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-G74gJL4V2pIapXVbpoD+ 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) iEYEABECAAYFAk4iWHMACgkQMAcU7Vc29oeutACfZi0UlqIZIHFBJaXnEmvGpLgR VdwAn2k4ks4uHNIJjCXQvNu7PxOQEe79 =kGjn -----END PGP SIGNATURE----- --=-G74gJL4V2pIapXVbpoD+-- From pch-b2B3A6689@u-1.phicoh.com Sun Jul 17 01:54:37 2011 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 DE81121F8634; Sun, 17 Jul 2011 01:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kF+QGQBKFcr; Sun, 17 Jul 2011 01:54:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5008121F862F; Sun, 17 Jul 2011 01:54:35 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QiN79-0001jMC; Sun, 17 Jul 2011 10:54:15 +0200 Message-Id: To: Mark Smith Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> In-reply-to: Your message of "Sun, 17 Jul 2011 11:32:37 +0930 ." <20110717113237.0137abcd@opy.nosense.org> Date: Sun, 17 Jul 2011 10:53:53 +0200 X-Mailman-Approved-At: Sun, 17 Jul 2011 03:55:12 -0700 Cc: RJ Atkinson , v6ops@ietf.org, ipv6@ietf.org, Fred Baker 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, 17 Jul 2011 08:54:38 -0000 In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote: >The quite novel technique of allocation transient addresses to >applications/processes to assist with firewalling also takes advantage >of IPv6's large address space and that hosts can have multiple >addresses at once. It'd be a shame to loose the opportunity to do that >or similar innovative things with the large IPv6 address space - A more scalable approach is to simply route a /96 to the host. There paper already suggests that: "If necessary in a given environment, this could be faked by hav- "ing a host pretend to be a stub router; however, this would require "the host to participate in routing protocols, which is generally "considered to be a bad idea. A better solution would be to extend "NDP to handle host address prefix lengths. I guess the authors didn't know about DHCPv6 prefix delegation. I think the same applies to hosts with lots of VMs: maintaining a potentially large number of NC entries for a single MAC address is unlikely to scale. This is what routing is designed for. From sander@steffann.nl Sun Jul 17 04:59:11 2011 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 2BF8321F86AE; Sun, 17 Jul 2011 04:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOKtNoz6waYC; Sun, 17 Jul 2011 04:59:10 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id F3FD621F862F; Sun, 17 Jul 2011 04:59:09 -0700 (PDT) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id C66BD2002; Sun, 17 Jul 2011 13:54:06 +0200 (CEST) Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: Date: Sun, 17 Jul 2011 13:54:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , 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, 17 Jul 2011 11:59:11 -0000 Hi, > I think the same applies to hosts with lots of VMs: maintaining a = potentially > large number of NC entries for a single MAC address is unlikely to = scale. > This is what routing is designed for. Then why are there 64 bits in the IID? And I don't think it has anything = to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses = scales as well as 1000 IPv6 addresses on 1000 MAC addresses. It might = make a difference for the switch, but not for ND/NC. - Sander PS: I consider having the possibility of having a large amount of IPv6 = addresses on one interface a great feature, not something I would want = to limit. From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 17 05:23:29 2011 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 B0FA921F85CB; Sun, 17 Jul 2011 05:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9wkJBk8qlnX; Sun, 17 Jul 2011 05:23:29 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id E2D4C21F85B8; Sun, 17 Jul 2011 05:23:28 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiQNW-00061G-7q; Sun, 17 Jul 2011 21:53:22 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 88A153B346; Sun, 17 Jul 2011 21:53:21 +0930 (CST) Date: Sun, 17 Jul 2011 21:53:20 +0930 From: Mark Smith To: Sander Steffann Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Message-ID: <20110717215320.73e71245@opy.nosense.org> In-Reply-To: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , ipv6@ietf.org, Philip Homburg 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, 17 Jul 2011 12:23:29 -0000 On Sun, 17 Jul 2011 13:54:06 +0200 Sander Steffann wrote: > Hi, > > > I think the same applies to hosts with lots of VMs: maintaining a potentially > > large number of NC entries for a single MAC address is unlikely to scale. > > This is what routing is designed for. > > Then why are there 64 bits in the IID? And I don't think it has anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses scales as well as 1000 IPv6 addresses on 1000 MAC addresses. It might make a difference for the switch, but not for ND/NC. > As people have observed, this is also a problem with IPv4 and ARP with a large enough subnet, so it isn't unique to IPv6, it's just that the size of IPv6 subnets is large and therefore it becomes more of an issue. I think the ultimate root cause is that the creation of neighbor cache entries is triggered by data plane traffic, rather than created by a control plane protocol i.e. a neighbor registration protocol. I think that means that what ever mitigations are put in place, they'll likely always be fundamentally vulnerable to data plane traffic attacks. If changing the way ND NS/NAs work is an option, then it might be better to adopt or use as a model the 6lowpan neighbor registration protocols, or perhaps review the ES-IS protocol as a model. That is obviously a large and wholesale change, however I think it would be the only way to truly eliminate any data plane traffic attacks on neighbor resolution. > - Sander > PS: I consider having the possibility of having a large amount of IPv6 addresses on one interface a great feature, not something I would want to limit. > Regards, Mark. From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 17 06:18:44 2011 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 83C8621F862F; Sun, 17 Jul 2011 06:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTASfi42E9Ki; Sun, 17 Jul 2011 06:18:43 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD1A21F861E; Sun, 17 Jul 2011 06:18:43 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiRF3-0007Cw-3U; Sun, 17 Jul 2011 22:48:41 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 7BD853B346; Sun, 17 Jul 2011 22:48:40 +0930 (CST) Date: Sun, 17 Jul 2011 22:48:40 +0930 From: Mark Smith To: Mark Smith Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Message-ID: <20110717224840.574ab41f@opy.nosense.org> In-Reply-To: <20110717215320.73e71245@opy.nosense.org> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, IPv6 Operations , Philip Homburg 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, 17 Jul 2011 13:18:44 -0000 On Sun, 17 Jul 2011 21:53:20 +0930 Mark Smith wrote: > On Sun, 17 Jul 2011 13:54:06 +0200 > Sander Steffann wrote: > > > Hi, > > > > > I think the same applies to hosts with lots of VMs: maintaining a potentially > > > large number of NC entries for a single MAC address is unlikely to scale. > > > This is what routing is designed for. > > > > Then why are there 64 bits in the IID? And I don't think it has anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses scales as well as 1000 IPv6 addresses on 1000 MAC addresses. It might make a difference for the switch, but not for ND/NC. > > > > As people have observed, this is also a problem with IPv4 and ARP with > a large enough subnet, so it isn't unique to IPv6, it's just that the > size of IPv6 subnets is large and therefore it becomes more of an issue. > > I think the ultimate root cause is that the creation of neighbor cache > entries is triggered by data plane traffic, rather than created by a > control plane protocol i.e. a neighbor registration protocol. I think > that means that what ever mitigations are put in place, they'll likely > always be fundamentally vulnerable to data plane traffic attacks. > > If changing the way ND NS/NAs work is an option, then it might be > better to adopt or use as a model the 6lowpan neighbor registration > protocols, or perhaps review the ES-IS protocol as a model. That is > obviously a large and wholesale change, however I think it would be the > only way to truly eliminate any data plane traffic attacks on neighbor > resolution. > Actually, that level of change might not be that necessary. If the destination address for the Duplicate Address Detection probes was changed to the all-nodes rather than the solicited nodes multicast address, then all receving nodes could immediately create a neighbor cache entry for the new device if one doesn't already exist. From that point on, Neighbor Unreachability Detection would then take care of maintaining the neighbor cache entry, and deleting it if the host disappears. > > - Sander > > PS: I consider having the possibility of having a large amount of IPv6 addresses on one interface a great feature, not something I would want to limit. > > > > Regards, > Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 17 07:11:13 2011 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 61A9421F8505; Sun, 17 Jul 2011 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=1.261, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsmGQbnfLQV7; Sun, 17 Jul 2011 07:11:13 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2071221F8550; Sun, 17 Jul 2011 07:11:11 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiS3m-0008Du-Ah; Sun, 17 Jul 2011 23:41:06 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E157F3B346; Sun, 17 Jul 2011 23:41:05 +0930 (CST) Date: Sun, 17 Jul 2011 23:41:05 +0930 From: Mark Smith To: Philip Homburg Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Message-ID: <20110717234105.04069322@opy.nosense.org> In-Reply-To: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, IPv6 Operations 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, 17 Jul 2011 14:11:13 -0000 On Sun, 17 Jul 2011 15:37:00 +0200 Philip Homburg wrote: > In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote: > >Actually, that level of change might not be that necessary. If the > >destination address for the Duplicate Address Detection probes was > >changed to the all-nodes rather than the solicited nodes multicast > >address, then all receving nodes could immediately create a neighbor > >cache entry for the new device if one doesn't already exist. From that > >point on, Neighbor Unreachability Detection would then take care of > >maintaining the neighbor cache entry, and deleting it if the host > >disappears. > > And then a router reboots. How does it find out about all the nodes already > there? > Good point, there would need to be a message to solicit addresses. An NS to the all nodes address with an unspecified (::) target address perhaps. So perhaps the changes required would be mostly limited to - - DADs to all-nodes rather than solicited node addresses - nodes receiving the DAD use that to create a neighbor cache entry - NUD takes care of maintaining the validity of those entries - ND NS to all nodes with an unspecified target address solicits NAs from all nodes to cover the router (or any device) reboot situation Anycast addresses would be an issue because DAD isn't performed by them. Perhaps a special "DAD" could be performed for them which causes the receiving devices to record their presence, but a normal NS/NA transaction for the anycast address is triggered if the anycast address is attempted to be used and hasn't been fully resolved. From pch-b2B3A6689@u-1.phicoh.com Sun Jul 17 06:35:10 2011 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 973BA21F8620; Sun, 17 Jul 2011 06:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.039 X-Spam-Level: X-Spam-Status: No, score=-8.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Dgof6j7ffj; Sun, 17 Jul 2011 06:35:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C682521F8565; Sun, 17 Jul 2011 06:35:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QiRUo-0001h5C; Sun, 17 Jul 2011 15:34:58 +0200 Message-Id: To: Mark Smith Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> In-reply-to: Your message of "Sun, 17 Jul 2011 21:53:20 +0930 ." <20110717215320.73e71245@opy.nosense.org> Date: Sun, 17 Jul 2011 15:34:38 +0200 X-Mailman-Approved-At: Sun, 17 Jul 2011 07:31:44 -0700 Cc: ipv6@ietf.org, IPv6 Operations 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, 17 Jul 2011 13:35:10 -0000 In your letter dated Sun, 17 Jul 2011 21:53:20 +0930 you wrote: >I think the ultimate root cause is that the creation of neighbor cache >entries is triggered by data plane traffic, rather than created by a >control plane protocol i.e. a neighbor registration protocol. I think >that means that what ever mitigations are put in place, they'll likely >always be fundamentally vulnerable to data plane traffic attacks. I don't think that is true. But that is for later. >If changing the way ND NS/NAs work is an option, then it might be >better to adopt or use as a model the 6lowpan neighbor registration >protocols, or perhaps review the ES-IS protocol as a model. That is >obviously a large and wholesale change, however I think it would be the >only way to truly eliminate any data plane traffic attacks on neighbor >resolution. I think we should just put the various design options on the table. See how they work, how many changes they require etc. But before that, the question now on the table is whether v6ops wants to spend more time figuring out what can be done with the current standards and/or what guidance they can give for new options. From pch-b2B3A6689@u-1.phicoh.com Sun Jul 17 06:37:10 2011 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 B3D2521F8557; Sun, 17 Jul 2011 06:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.332 X-Spam-Level: X-Spam-Status: No, score=-8.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt9suM-KPHMO; Sun, 17 Jul 2011 06:37:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0097C21F8551; Sun, 17 Jul 2011 06:37:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QiRWn-0001i7C; Sun, 17 Jul 2011 15:37:01 +0200 Message-Id: To: Mark Smith Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> In-reply-to: Your message of "Sun, 17 Jul 2011 22:48:40 +0930 ." <20110717224840.574ab41f@opy.nosense.org> Date: Sun, 17 Jul 2011 15:37:00 +0200 X-Mailman-Approved-At: Sun, 17 Jul 2011 07:31:44 -0700 Cc: ipv6@ietf.org, IPv6 Operations 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, 17 Jul 2011 13:37:10 -0000 In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote: >Actually, that level of change might not be that necessary. If the >destination address for the Duplicate Address Detection probes was >changed to the all-nodes rather than the solicited nodes multicast >address, then all receving nodes could immediately create a neighbor >cache entry for the new device if one doesn't already exist. From that >point on, Neighbor Unreachability Detection would then take care of >maintaining the neighbor cache entry, and deleting it if the host >disappears. And then a router reboots. How does it find out about all the nodes already there? From pch-b2B3A6689@u-1.phicoh.com Sun Jul 17 07:57:30 2011 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 EE0BD21F874B; Sun, 17 Jul 2011 07:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.518 X-Spam-Level: X-Spam-Status: No, score=-8.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inuKdcx04I3q; Sun, 17 Jul 2011 07:57:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 07CB621F869C; Sun, 17 Jul 2011 07:57:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QiSmU-0001iBC; Sun, 17 Jul 2011 16:57:18 +0200 Message-Id: To: Mark Smith Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> In-reply-to: Your message of "Sun, 17 Jul 2011 23:41:05 +0930 ." <20110717234105.04069322@opy.nosense.org> Date: Sun, 17 Jul 2011 16:57:06 +0200 Cc: ipv6@ietf.org, IPv6 Operations 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, 17 Jul 2011 14:57:31 -0000 [I dropped v6ops] In your letter dated Sun, 17 Jul 2011 23:41:05 +0930 you wrote: >Good point, there would need to be a message to solicit addresses. An >NS to the all nodes address with an unspecified (::) target address >perhaps. > >So perhaps the changes required would be mostly limited to - > >- DADs to all-nodes rather than solicited node addresses >- nodes receiving the DAD use that to create a neighbor cache entry >- NUD takes care of maintaining the validity of those entries >- ND NS to all nodes with an unspecified target address solicits NAs > from all nodes to cover the router (or any device) reboot situation So my proposal would be to add an option to RA. This option specifies a time over which nodes should distrubute updating the router (random number between zero and the timeout). At the selected time, the node then starts NUD on the router. Note that it has to do that for all of its addresses. Which is not part of ND at the moment. This should be enough. When a node boots it sends an RS. When a node adds a new address (not triggered by an RA) it may need to go over its list of routers and update them. Routers can always add the option to their RAs. But an alternative is to do that only when they become overloaded. From huitema@microsoft.com Sun Jul 17 09:09:33 2011 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 7C98C21F84E3; Sun, 17 Jul 2011 09:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.774 X-Spam-Level: X-Spam-Status: No, score=-10.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWj2cfErGGR4; Sun, 17 Jul 2011 09:09:33 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0821F84EF; Sun, 17 Jul 2011 09:09:31 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 17 Jul 2011 09:09:31 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.323.2; Sun, 17 Jul 2011 09:09:31 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.52]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Sun, 17 Jul 2011 09:09:30 -0700 From: Christian Huitema To: Philip Homburg , Mark Smith Subject: RE: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Thread-Topic: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Thread-Index: AQHMRJHLOaNFypP8jkSb4kdkNNCU2pTwpJNw Date: Sun, 17 Jul 2011 16:09:29 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> In-Reply-To: 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 Cc: IPv6 Operations , "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, 17 Jul 2011 16:09:33 -0000 >So perhaps the changes required would be mostly limited to - > >- DADs to all-nodes rather than solicited node addresses >- nodes receiving the DAD use that to create a neighbor cache entry >- NUD takes care of maintaining the validity of those entries >- ND NS to all nodes with an unspecified target address solicits NAs > from all nodes to cover the router (or any device) reboot situation I am not sure this addresses the problem too well. The DOS issue manifests = itself at the gateway, and the main issue is the remote DOS: attacker sends= packets to a very large number of putative IPv6 addresses in the subnet ma= naged by the local gateway, causing the size of the neighbor cache to explo= de. If we want to protect the cache in the gateway, let's do that. The solu= tion has to be a tweak in the implementation of ND in the gateway, along th= e lines of: - Upon arrival of a packet from the local network: - If the source address is already in ND cache, keep it there - if the source address is not already in the ND cache: Perform some quota check on the source MAC address, If the quota is exceeded, drop the packet to protect against local DOS If the quota is not exceeded, perform ND for the source address - Upon arrival of a packet bound to the local subnet - If the destination address is already in ND cache, route the packet; - If the destination address is not in ND cache: If the table is "too full," drop the packet Else, perform ND The basic idea is that remote parties should only be sending to addresses t= hat have already been discovered in the local subnet. This is, in a way, a = weak form of stateful filtering. It needs to be implemented softly, because= routers/gateways sometime lose their memory, so we want to allow for some = dynamic learning if the tables are not already populated. The proposed tweaks amount to making ND learn faster. They are fine in gene= ral, but they have the side effect of making local DOS easier. A local atta= cker could generate a large number of addresses, etc. -- Christian Huitema From moore@network-heretics.com Sun Jul 17 09:49:19 2011 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 9DA0E21F8572; Sun, 17 Jul 2011 09:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asOVBGvymxFi; Sun, 17 Jul 2011 09:49:18 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id B62F821F8571; Sun, 17 Jul 2011 09:49:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 4AE8220B59; Sun, 17 Jul 2011 12:49:18 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 17 Jul 2011 12:49:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=+shK3DVam7QeuXt48s1v9+z4u+w=; b=GyxajoIuzazOEjbWPR9ithgZOIp6ueECtZJvp/TETD1LonP92ymNUY8NJY9/Dbgyv63FNuFBm39Rbjr5+qyTCv1wtz4fHOQMDSnVIU+ZFnKH8BFk+fR+o/fRlrCwUHU+1qpB4iJrBdvAhpDx8aEnJQFpfyZiY7zBU6Tvewjh1hw= X-Sasl-enc: aL1Le2Bf6TDFXl62x2aJKl+yD6qrs/bxH1gAVR0N7mvX 1310921357 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id C3D574416E8; Sun, 17 Jul 2011 12:49:16 -0400 (EDT) Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Date: Sun, 17 Jul 2011 12:49:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53A6850D-5B2F-458D-AE35-53AF978AC630@network-heretics.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> To: Christian Huitema X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , "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, 17 Jul 2011 16:49:19 -0000 On Jul 17, 2011, at 12:09 PM, Christian Huitema wrote: >> So perhaps the changes required would be mostly limited to - >>=20 >> - DADs to all-nodes rather than solicited node addresses >> - nodes receiving the DAD use that to create a neighbor cache entry >> - NUD takes care of maintaining the validity of those entries >> - ND NS to all nodes with an unspecified target address solicits NAs >> from all nodes to cover the router (or any device) reboot situation >=20 > I am not sure this addresses the problem too well. The DOS issue = manifests itself at the gateway, and the main issue is the remote DOS: = attacker sends packets to a very large number of putative IPv6 addresses = in the subnet managed by the local gateway, causing the size of the = neighbor cache to explode. If we want to protect the cache in the = gateway, let's do that. The solution has to be a tweak in the = implementation of ND in the gateway, along the lines of: >=20 > - Upon arrival of a packet from the local network: > - If the source address is already in ND cache, keep it there > - if the source address is not already in the ND cache: > Perform some quota check on the source MAC address, > If the quota is exceeded, drop the packet to protect against = local DOS > If the quota is not exceeded, perform ND for the source address >=20 > - Upon arrival of a packet bound to the local subnet > - If the destination address is already in ND cache, route the packet; > - If the destination address is not in ND cache: > If the table is "too full," drop the packet > Else, perform ND >=20 > The basic idea is that remote parties should only be sending to = addresses that have already been discovered in the local subnet. This = is, in a way, a weak form of stateful filtering. It needs to be = implemented softly, because routers/gateways sometime lose their memory, = so we want to allow for some dynamic learning if the tables are not = already populated. >=20 > The proposed tweaks amount to making ND learn faster. They are fine in = general, but they have the side effect of making local DOS easier. A = local attacker could generate a large number of addresses, etc. As a defense against remote attack, I'm thinking that routers should = limit the percentage of their ND caches that are associated with = nonexistent hosts. I suspect there are circumstances when it makes = sense to have "passive" hosts, perhaps even large numbers of them, which = the local router isn't aware of until traffic from outside arrives for = them. =20 It might also make sense to rate-limit ND messages sent as a result of = inbound traffic - if this rate of such ND messages exceeds a certain = threshold, drop incoming packets for hosts not in the ND cache at = random. Regarding local attack, I doubt that the right thing to do is for = routers to give preference to addresses already in the ND cache. It = seems like that would just invite DoS attack, by having the attacking = host flood the router's ND cache at regular intervals (especially if the = ND cache entry timeout were a constant). A better idea might be for = routers to give preference to addresses that are actually being used to = exchange traffic. That might mean associating a count or timestamp with = each ND cache entry. (which admittedly can introduce its own set of = issues under certain conditions). And I wonder whether ND cache entries should have a "half-life" rather = than a strict timeout. That still leaves the possibility of an attack where a local host = generates large numbers of addresses, and actually uses each of them to = exchange traffic with a remote host. As long as hosts can easily and = quickly change their interfaces' MAC addresses, I don't see an easy way = to deal with that.... though perhaps platforms could rate-limit the = ability of applications to do that. Keith From sander@steffann.nl Sun Jul 17 11:46:58 2011 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 3C42E21F856D; Sun, 17 Jul 2011 11:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjx+q9j5e5mx; Sun, 17 Jul 2011 11:46:57 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id AE0A421F8565; Sun, 17 Jul 2011 11:46:57 -0700 (PDT) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id 583712004; Sun, 17 Jul 2011 20:41:55 +0200 (CEST) Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <53A6850D-5B2F-458D-AE35-53AF978AC630@network-heretics.com> Date: Sun, 17 Jul 2011 20:41:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22D9631E-38CE-4B74-91E0-C352DE3A8768@steffann.nl> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <53A6850D-5B2F-458D-AE35-53AF978AC630@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: Christian Huitema , IPv6 Operations , "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, 17 Jul 2011 18:46:58 -0000 Hi, > As a defense against remote attack, I'm thinking that routers should = limit the percentage of their ND caches that are associated with = nonexistent hosts. I suspect there are circumstances when it makes = sense to have "passive" hosts, perhaps even large numbers of them, which = the local router isn't aware of until traffic from outside arrives for = them. =20 >=20 > It might also make sense to rate-limit ND messages sent as a result of = inbound traffic - if this rate of such ND messages exceeds a certain = threshold, drop incoming packets for hosts not in the ND cache at = random. It might be a good idea to increase the timers on the hosts that are in = the cache, or to start refreshing those cache entries actively before = they run out. In such a situation we might want to keep the pool of = verified existing hosts as large as possible to keep the dropping of = good packets to a minimum. Sander From v6ops@globis.net Sun Jul 17 12:00:45 2011 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 1124B21F86BC; Sun, 17 Jul 2011 12:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12sj79fX93bA; Sun, 17 Jul 2011 12:00:44 -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 E5A7B21F86C4; Sun, 17 Jul 2011 12:00:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BB6EC87004E; Sun, 17 Jul 2011 21:00:30 +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 F39jp6GCTD3M; Sun, 17 Jul 2011 21:00:13 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 6FFF08700DE; Sun, 17 Jul 2011 21:00:13 +0200 (CEST) Message-ID: <4E23313D.4040906@globis.net> Date: Sun, 17 Jul 2011 21:00:13 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: ipv6@ietf.org, IPv6 Operations Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Content-Type: multipart/alternative; boundary="------------010509050804070209080500" 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, 17 Jul 2011 19:00:45 -0000 This is a multi-part message in MIME format. --------------010509050804070209080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Subject: > Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? > From: > Philip Homburg > Date: > Sun, 17 Jul 2011 15:37:00 +0200 > > To: > Mark Smith > CC: > ipv6@ietf.org, IPv6 Operations > > Precedence: > list > References: > > <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> > > <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> > <20110717113237.0137abcd@opy.nosense.org> > > > <20110717215320.73e71245@opy.nosense.org> > <20110717224840.574ab41f@opy.nosense.org> > In-Reply-To: > Your message of "Sun, 17 Jul 2011 22:48:40 +0930 ." > <20110717224840.574ab41f@opy.nosense.org> > Message-ID: > > Message: > 8 > > > In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote: > >> >Actually, that level of change might not be that necessary. If the >> >destination address for the Duplicate Address Detection probes was >> >changed to the all-nodes rather than the solicited nodes multicast >> >address, then all receving nodes could immediately create a neighbor >> >cache entry for the new device if one doesn't already exist. From that >> >point on, Neighbor Unreachability Detection would then take care of >> >maintaining the neighbor cache entry, and deleting it if the host >> >disappears. >> > > And then a router reboots. How does it find out about all the nodes already > there? > > > It's not just a router rebooting that's a problem: a temporarily split-brain L2 link (think spanning tree thrashing at the time when a node registers) could cause the same problem. There has to be some time related or event related (or both) trigger to refresh (not just when a L3 event like a node restart or interface up/down occurs). Something has to give IMVHO, because AFAIK all of the current mitigation measures all rely on scarcity of either attacker or target addresses, which just isn't reality assuming mass-deployment of SLAAC. How can you effectively (rate) filter if you can't tell good from bad? I agree with Philip that there should be a number of options put on the table, and the various trade offs examined. The conclusion might be that there needs to be various forms of ND, that are media dependent. Or small tweaks might help. Or it might be that the current compromise really is the best achievable. But let's see. regards, RayH --------------010509050804070209080500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Subject:
Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ?
From:
Philip Homburg <pch-v6ops@u-1.phicoh.com>
Date:
Sun, 17 Jul 2011 15:37:00 +0200
To:
Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
CC:
ipv6@ietf.org, IPv6 Operations <v6ops@ietf.org>
Precedence:
list
References:
<D4F95C5E-20A3-4B1E-8211-07B7831F3E89@gmail.com> <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <E3161138-0CAA-44E8-A329-E71408D0AE61@gmail.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <m1QiN79-0001jMC@stereo.hq.phicoh.net> <A1924BC2-B42D-4A06-8122-ABFF325E1CF4@steffann.nl> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org>
In-Reply-To:
Your message of "Sun, 17 Jul 2011 22:48:40 +0930 ." <20110717224840.574ab41f@opy.nosense.org>
Message-ID:
<m1QiRWn-0001i7C@stereo.hq.phicoh.net>
Message:
8		 

In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote:
  
>Actually, that level of change might not be that necessary. If the
>destination address for the Duplicate Address Detection probes was
>changed to the all-nodes rather than the solicited nodes multicast
>address, then all receving nodes could immediately create a neighbor
>cache entry for the new device if one doesn't already exist. From that
>point on, Neighbor Unreachability Detection would then take care of
>maintaining the neighbor cache entry, and deleting it if the host
>disappears. 
    

And then a router reboots. How does it find out about all the nodes already
there?
It's not just a router rebooting that's a problem: a temporarily split-brain L2 link (think spanning tree thrashing at the time when a node registers) could cause the same problem. There has to be some time related or event related (or both) trigger to refresh (not just when a L3 event like a node restart or interface up/down occurs).

Something has to give IMVHO, because AFAIK all of the current mitigation measures all rely on scarcity of either attacker or target addresses, which just isn't reality assuming mass-deployment of SLAAC.

How can you effectively (rate) filter if you can't tell good from bad?

I agree with Philip that there should be a number of options put on the table, and the various trade offs examined.

The conclusion might be that there needs to be various forms of ND, that are media dependent. Or small tweaks might help.
Or it might be that the current compromise really is the best achievable. But let's see.

regards,
RayH
--------------010509050804070209080500-- From dr@cluenet.de Sun Jul 17 11:56:21 2011 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 87D8B21F84D5; Sun, 17 Jul 2011 11:56:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7e9Pb3lhJFT; Sun, 17 Jul 2011 11:56:21 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id C0C6921F84D4; Sun, 17 Jul 2011 11:56:20 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 1DA00108094; Sun, 17 Jul 2011 20:56:19 +0200 (CEST) Date: Sun, 17 Jul 2011 20:56:19 +0200 From: Daniel Roesen To: v6ops@ietf.org, "ipv6@ietf.org" Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Message-ID: <20110717185619.GA29575@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "ipv6@ietf.org" References: <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Mailman-Approved-At: Sun, 17 Jul 2011 12:48:52 -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: Sun, 17 Jul 2011 18:56:21 -0000 On Sun, Jul 17, 2011 at 04:09:29PM +0000, Christian Huitema wrote: > The basic idea is that remote parties should only be sending to > addresses that have already been discovered in the local subnet. Breaks with any VRRP setup. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From huitema@microsoft.com Sun Jul 17 13:14:59 2011 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 2F38721F86AC; Sun, 17 Jul 2011 13:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.739 X-Spam-Level: X-Spam-Status: No, score=-10.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v00Aa24md0E8; Sun, 17 Jul 2011 13:14:58 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id A314221F86A2; Sun, 17 Jul 2011 13:14:58 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 17 Jul 2011 13:14:57 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.323.2; Sun, 17 Jul 2011 13:14:58 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.52]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Sun, 17 Jul 2011 13:14:57 -0700 From: Christian Huitema To: Daniel Roesen , "v6ops@ietf.org" , "ipv6@ietf.org" Subject: RE: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Thread-Topic: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Thread-Index: AQHMRLqgDrnSMVwba0mziuhfQBJqRJTw8AMA Date: Sun, 17 Jul 2011 20:14:56 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F1BC20B@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <20110717185619.GA29575@srv03.cluenet.de> In-Reply-To: <20110717185619.GA29575@srv03.cluenet.de> 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-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, 17 Jul 2011 20:14:59 -0000 > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of D= aniel Roesen > On Sun, Jul 17, 2011 at 04:09:29PM +0000, Christian Huitema wrote: >> The basic idea is that remote parties should only be sending to=20 >> addresses that have already been discovered in the local subnet. > > Breaks with any VRRP setup. VRPP is probably a special case of a router losing its memory...=20 In any case, as Ray Hunter noted, you need to somehow "tell good from bad" = if you want to filter effectively. My suggestion is that an address from wh= ich traffic has been sourced locally is more likely to be "good" than an ad= dress that appears for the first time in a packet coming from afar. This is= effectively the property used by most stateful firewalls, so there is some= operational experience with that.=20 There are indeed a few issues, e.g. the local server who expects remote TCP= connections but remains otherwise silent, or the router that was just rebo= oted, or swapped in, and has no idea about the current working set. The sol= ution to the server issue has to be some kind of keep-alive, e.g. with ND. = The solution to the "router with no memory" is probably a looser control du= ring a "learning" period, possibly combined with some form of fast ND refre= sh. Of course, there are no good solutions against a local host who is actively= trying to DOS a local router. Keith pointed out that local hosts can gener= ate as many MAC addresses as they want... But then, there are meatspace sol= utions to this kind of things. -- Christian Huitema From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 17 16:31:23 2011 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 060F721F84FA; Sun, 17 Jul 2011 16:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoCXsC7PN8hy; Sun, 17 Jul 2011 16:31:22 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 321A521F84F8; Sun, 17 Jul 2011 16:31:22 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qiant-0001Ev-KQ; Mon, 18 Jul 2011 09:01:17 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0B8CB3B342; Mon, 18 Jul 2011 09:01:17 +0930 (CST) Date: Mon, 18 Jul 2011 09:01:16 +0930 From: Mark Smith To: Christian Huitema Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Message-ID: <20110718090116.73f183e1@opy.nosense.org> In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "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, 17 Jul 2011 23:31:23 -0000 Hi Christian, On Sun, 17 Jul 2011 16:09:29 +0000 Christian Huitema wrote: > >So perhaps the changes required would be mostly limited to - > > > >- DADs to all-nodes rather than solicited node addresses > >- nodes receiving the DAD use that to create a neighbor cache entry > >- NUD takes care of maintaining the validity of those entries > >- ND NS to all nodes with an unspecified target address solicits NAs > > from all nodes to cover the router (or any device) reboot situation > > I am not sure this addresses the problem too well. The DOS issue manifests itself at the gateway, and the main issue is the remote DOS: attacker sends packets to a very large number of putative IPv6 addresses in the subnet managed by the local gateway, causing the size of the neighbor cache to explode. If we want to protect the cache in the gateway, let's do that. I agree the attack is most likely going to be aimed at a remote router, however I've also realised that a local host cache may also be a target on a multi-user host. With virtualisation and (groan) "cloud computing", these are becoming more common again. > The solution has to be a tweak in the implementation of ND in the gateway, along the lines of: > > - Upon arrival of a packet from the local network: > - If the source address is already in ND cache, keep it there > - if the source address is not already in the ND cache: > Perform some quota check on the source MAC address, > If the quota is exceeded, drop the packet to protect against local DOS > If the quota is not exceeded, perform ND for the source address > > - Upon arrival of a packet bound to the local subnet > - If the destination address is already in ND cache, route the packet; > - If the destination address is not in ND cache: > If the table is "too full," drop the packet > Else, perform ND > > The basic idea is that remote parties should only be sending to addresses that have already been discovered in the local subnet. This is, in a way, a weak form of stateful filtering. It needs to be implemented softly, because routers/gateways sometime lose their memory, so we want to allow for some dynamic learning if the tables are not already populated. > > The proposed tweaks amount to making ND learn faster. They are fine in general, but they have the side effect of making local DOS easier. A local attacker could generate a large number of addresses, etc. > True, it is vulnerable to a local DoS, although I think thats much better than a remote DoS, because I think local attackers have more of a vested interest in the router being available, and local segments are fairly commonly controlled. In SP environments, there are a lot of spoofing related attacks e.g. RAs, so the measures that SPs put in place to sanitise their customers' traffic tends to mitigate these local DoS attacks. I definitely see addressing the remote DoS to be the main priority. If the solutions to that can also help mitigate some of the local DoS methods that's all the better, however I think they're less of a threat, and ones we've already had experience with because similar ones exist in IPv4. Regards, Mark. From fred@cisco.com Sun Jul 17 16:45:14 2011 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 2F96721F8754; Sun, 17 Jul 2011 16:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.069 X-Spam-Level: X-Spam-Status: No, score=-105.069 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3kG1azmRXCN; Sun, 17 Jul 2011 16:45:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8221F8757; Sun, 17 Jul 2011 16:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2356; q=dns/txt; s=iport; t=1310946313; x=1312155913; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=brZIgxBAsFrLB/BWdXhkkQ9wMe6iWoFt/PNuC8ONFB8=; b=Fbq+2Bmor67zAMQsAmIgRwPTpmyDXkFeZ8BDHgwV3q7ai2UdLrx1WEIH i5OxtYq/HrOceO1qJH4esKyXDWgWAkxyCaS9zEGVsb5sVAuxdoHxre1kx Tcd/wPW+Q5NgxLdUDTpBt3/CaKIK32GzkV5x44hTXqRlES92iLXJUcsms A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOVyI06rRDoH/2dsb2JhbABRp3J3iHykZp0HhV1fBIdUixKFAYt0 X-IronPort-AV: E=Sophos;i="4.67,219,1309737600"; d="scan'208";a="3781211" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2011 23:45:12 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6HNjB92007099; Sun, 17 Jul 2011 23:45:11 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Sun, 17 Jul 2011 16:45:12 -0700 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Sun, 17 Jul 2011 16:45:12 -0700 Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sun, 17 Jul 2011 16:44:46 -0700 Message-Id: <529A223D-1FDE-41D8-944F-35BB78F93382@cisco.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson 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, 17 Jul 2011 23:45:14 -0000 On Jul 17, 2011, at 1:53 AM, Philip Homburg wrote: > In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote: >> The quite novel technique of allocation transient addresses to >> applications/processes to assist with firewalling also takes = advantage >> of IPv6's large address space and that hosts can have multiple >> addresses at once. It'd be a shame to loose the opportunity to do = that >> or similar innovative things with the large IPv6 address space - >=20 > A more scalable approach is to simply route a /96 to the host. There = paper > already suggests that: >=20 > "If necessary in a given environment, this could be faked by hav- > "ing a host pretend to be a stub router; however, this would require > "the host to participate in routing protocols, which is generally > "considered to be a bad idea. A better solution would be to extend > "NDP to handle host address prefix lengths. >=20 > I guess the authors didn't know about DHCPv6 prefix delegation. >=20 > I think the same applies to hosts with lots of VMs: maintaining a = potentially > large number of NC entries for a single MAC address is unlikely to = scale. > This is what routing is designed for. One issue to think about has to do with virtual machines. If I have one = physical platform that appears to the network to be many virtual = platforms, I would likely want to give it many IPv6 addresses. In a = cloud computing environment, if I move a virtual machine from one = platform to another, I would like to move the address and its routing, = by changing the MAC address associated with the IPv6 address. Forcing a = /96 here would limit my options - to change the routing, I would be = forced to change the address, which is something in a cloud computing = environment that I don't want to do. I could imagine a mix of the proposals, though. I could imagine using a = /80 for a rack or a /96 per platform for virtual machines that reside = there, with a smattering of /128s within the data center for virtual = machines that have moved - and if there was a long term movement, I = could imagine renumbering the machine by adding a new address to it in = its new /96, changing the DNS name, waiting an appropriate interval, and = then removing the old address's /128 from routing and from the virtual = machine.= From joelja@bogus.com Sun Jul 17 17:54:19 2011 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 C0E6121F8A55; Sun, 17 Jul 2011 17:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.071 X-Spam-Level: X-Spam-Status: No, score=-103.071 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otJ5Xs6X+DCp; Sun, 17 Jul 2011 17:54:19 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B674E21F8A58; Sun, 17 Jul 2011 17:54:18 -0700 (PDT) Received: from zorch.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6I0s9aD059879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jul 2011 00:54:10 GMT (envelope-from joelja@bogus.com) Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <529A223D-1FDE-41D8-944F-35BB78F93382@cisco.com> Date: Sun, 17 Jul 2011 17:54:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69169B31-1608-41D5-82C7-A649FA959AA7@bogus.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <529A223D-1FDE-41D8-944F-35BB78F93382@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 18 Jul 2011 00:54:13 +0000 (UTC) Cc: RJ Atkinson , v6ops@ietf.org, ipv6@ietf.org, Philip Homburg 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, 18 Jul 2011 00:54:19 -0000 On Jul 17, 2011, at 4:44 PM, Fred Baker wrote: >=20 > On Jul 17, 2011, at 1:53 AM, Philip Homburg wrote: >=20 >> In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote: >>> The quite novel technique of allocation transient addresses to >>> applications/processes to assist with firewalling also takes = advantage >>> of IPv6's large address space and that hosts can have multiple >>> addresses at once. It'd be a shame to loose the opportunity to do = that >>> or similar innovative things with the large IPv6 address space - >>=20 >> A more scalable approach is to simply route a /96 to the host. There = paper >> already suggests that: >>=20 >> "If necessary in a given environment, this could be faked by hav- >> "ing a host pretend to be a stub router; however, this would require >> "the host to participate in routing protocols, which is generally >> "considered to be a bad idea. A better solution would be to extend >> "NDP to handle host address prefix lengths. >>=20 >> I guess the authors didn't know about DHCPv6 prefix delegation. >>=20 >> I think the same applies to hosts with lots of VMs: maintaining a = potentially >> large number of NC entries for a single MAC address is unlikely to = scale. >> This is what routing is designed for. >=20 > One issue to think about has to do with virtual machines. If I have = one physical platform that appears to the network to be many virtual = platforms, I would likely want to give it many IPv6 addresses. In a = cloud computing environment, if I move a virtual machine from one = platform to another, I would like to move the address and its routing, = by changing the MAC address associated with the IPv6 address. Forcing a = /96 here would limit my options - to change the routing, I would be = forced to change the address, which is something in a cloud computing = environment that I don't want to do. Practically speaking you can also achieve the host mobility that large = layer-2's achieve through an l3 mobility approach. eg. the host uses an = igp to advertise it's availability (that is, the nexthop for a prefix = which it has bound to it) within the datacenter... This (could) reduce = the visibility of the subnet to which the host is attached. (it doesn't = have to be externally reachable for example, host address assignments = may be independent of local topology etc. I can't say I've done it with = end systems but we do do a similar thing with load balancers (which are = linux boxes running bgp), where they are ebgp peered with the DC border = using a private AS and you you can take a load-balancer or prefix out of = service or move it by withdrawing the prefix on one load balancer or = advertise it on another. vmware vmotion for example is happy to work across layer-3 networks, the = hosts however need intervention when their numbering changes. > I could imagine a mix of the proposals, though. I could imagine using = a /80 for a rack or a /96 per platform for virtual machines that reside = there, with a smattering of /128s within the data center for virtual = machines that have moved - and if there was a long term movement, I = could imagine renumbering the machine by adding a new address to it in = its new /96, changing the DNS name, waiting an appropriate interval, and = then removing the old address's /128 from routing and from the virtual = machine. I was mostly interested in solving the problem independently of the = subnet size. My assumption is that due to slaac, that I'm going to be = using /64 subnets for networks which have hosts on them... while much of = the exposed side of a DC probably doesn't rely on slaac and is in fact = point-to-point links, places where hosts connect probably are. if the = mac address ends up being encoded in the address at any point it seems a = little silly to split the difference between /64 and /80, both are = trivially big enough to blow up the unpoliced ND cache or dos the = routers cpu. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From kauer@biplane.com.au Mon Jul 18 05:25:43 2011 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 069CD21F8BA4 for ; Mon, 18 Jul 2011 05:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV-Hw4pz0kRO for ; Mon, 18 Jul 2011 05:25:39 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7E821F8B46 for ; Mon, 18 Jul 2011 05:25:36 -0700 (PDT) Received: from ppp-45-20.grapevine.net.au ([203.129.45.20] helo=[192.168.2.4]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QimtB-00010S-Lm for ipv6@ietf.org; Mon, 18 Jul 2011 08:25:33 -0400 Subject: PMTUD and MTU < 1280 From: Karl Auer To: IETF IPv6 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Yyb9Hc+keWLweRgnyn+y" Date: Mon, 18 Jul 2011 22:25:30 +1000 Message-ID: <1310991930.2724.17.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 18 Jul 2011 12:25:43 -0000 --=-Yyb9Hc+keWLweRgnyn+y Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6. It contains these two paragraphs towards the end of Section 4: A node MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum link MTU. Note: A node may receive a Packet Too Big message reporting a next-hop MTU that is less than the IPv6 minimum link MTU. In that case, the node is not required to reduce the size of subsequent packets sent on the path to less than the IPv6 minimun link MTU, but rather must include a Fragment header in those packets [IPv6- SPEC]. What does that mean - "insert a Fragment header"? And it may not be *required* to reduce the size of subsequent packets, but does that mean it *can* if it wants to? And isn't inserting a whole new header a bit counterproductive if someone is telling your your packets are too big already? All in all I have this strong feeling I'm missing something obvious. Any clues gratefully received. Regards, K. PS: [IPv6-SPEC]" refers to RFC1883, "Internet Protocol, Version 6 (IPv6) Specification". I've read it again, especially the section on the Fragment header, but am none the wiser. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-Yyb9Hc+keWLweRgnyn+y 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) iEYEABECAAYFAk4kJjMACgkQMAcU7Vc29oeHvwCfVzbTaWsQOwQRB+HHzkEdq9E/ J68AoKErdenesiUIqax1GDVHkd9p7bn1 =zbKi -----END PGP SIGNATURE----- --=-Yyb9Hc+keWLweRgnyn+y-- From pch-b2B3A6689@u-1.phicoh.com Mon Jul 18 05:47:11 2011 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 8925C21F8BF2 for ; Mon, 18 Jul 2011 05:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRjoJGr-HEwS for ; Mon, 18 Jul 2011 05:47:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9408D21F8AFE for ; Mon, 18 Jul 2011 05:47:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QinDo-0001fiC; Mon, 18 Jul 2011 14:46:52 +0200 Message-Id: To: Karl Auer Subject: Re: PMTUD and MTU < 1280 From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Mon, 18 Jul 2011 22:25:30 +1000 ." <1310991930.2724.17.camel@karl> Date: Mon, 18 Jul 2011 14:46:38 +0200 Cc: IETF IPv6 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, 18 Jul 2011 12:47:11 -0000 In your letter dated Mon, 18 Jul 2011 22:25:30 +1000 you wrote: >I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6. > >It contains these two paragraphs towards the end of Section 4: > > A node MUST NOT reduce its estimate of the Path MTU below the IPv6 > minimum link MTU. > > Note: A node may receive a Packet Too Big message reporting a > next-hop MTU that is less than the IPv6 minimum link MTU. In that > case, the node is not required to reduce the size of subsequent > packets sent on the path to less than the IPv6 minimun link MTU, > but rather must include a Fragment header in those packets [IPv6- > SPEC]. > >What does that mean - "insert a Fragment header"? And it may not be >*required* to reduce the size of subsequent packets, but does that mean >it *can* if it wants to? And isn't inserting a whole new header a bit >counterproductive if someone is telling your your packets are too big >already? All in all I have this strong feeling I'm missing something >obvious. Any clues gratefully received. I think that there was a tunneling protocol that would need the fragment ID in the fragment header to do fragmentation on the lower layer or something like that. It never made much sense to me. From fweimer@bfk.de Mon Jul 18 07:07:20 2011 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 E4A8121F85BB for ; Mon, 18 Jul 2011 07:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBGQuqlxpvFm for ; Mon, 18 Jul 2011 07:07:16 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id B43CF21F85CB for ; Mon, 18 Jul 2011 07:07:15 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QioTW-0000fT-K2; Mon, 18 Jul 2011 14:07:10 +0000 Received: by bfk.de with local id 1QioTW-0008E5-H8; Mon, 18 Jul 2011 14:07:10 +0000 From: Florian Weimer To: Karl Auer Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> Date: Mon, 18 Jul 2011 14:07:10 +0000 In-Reply-To: <1310991930.2724.17.camel@karl> (Karl Auer's message of "Mon, 18 Jul 2011 22:25:30 +1000") Message-ID: <82sjq3vg1d.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 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, 18 Jul 2011 14:07:21 -0000 * Karl Auer: > I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6. > > It contains these two paragraphs towards the end of Section 4: > > A node MUST NOT reduce its estimate of the Path MTU below the IPv6 > minimum link MTU. > > Note: A node may receive a Packet Too Big message reporting a > next-hop MTU that is less than the IPv6 minimum link MTU. In that > case, the node is not required to reduce the size of subsequent > packets sent on the path to less than the IPv6 minimun link MTU, > but rather must include a Fragment header in those packets [IPv6- > SPEC]. I've recently submitted an erratum to section 5 of RFC 2460, which contains a similar requirement. The requirement makes it impossible to serve IPv6 services in a stateless fashion, so it's clearly bogus. (Technically, you could always include the Fragment header, but that would be an ugly kludge.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From brian@innovationslab.net Mon Jul 18 08:51:47 2011 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 91DE521F8BE9; Mon, 18 Jul 2011 08:51:47 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCuOZM11xKQV; Mon, 18 Jul 2011 08:51:46 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C7C7621F8BE7; Mon, 18 Jul 2011 08:51:46 -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 B574588153; Mon, 18 Jul 2011 08:51:46 -0700 (PDT) Received: from clemson.local (unknown [75.94.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E3E1A130002; Mon, 18 Jul 2011 08:51:45 -0700 (PDT) Message-ID: <4E245695.6070204@innovationslab.net> Date: Mon, 18 Jul 2011 11:51:49 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: DISCUSS: draft-ietf-6man-flow-3697bis and reserving bits from the flow label X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org IESG" 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, 18 Jul 2011 15:51:47 -0000 6MAN Participants, During IESG evaluation, a DISCUSS position was raised on whether or not several of the bits (4 was suggested) be reserved as a discriminator to identify how the flow label is being used. We had a discussion in 2010 on separating the current 20 bits of flow label into sub-fields (discussion started around this point in the mailing list archives : http://www.ietf.org/mail-archive/web/ipv6/current/msg12031.html). The consensus from that mailing list discussion was to not divide the flow label for several reasons: 1. Encoding semantics was too complex to handle at line rate 2. A 16-bit flow label may be too easy to predict 3. These fields are not protected in anyway, so there is little trust in the values set The above reasons led to the decision to retain the flow label as a single 20-bit field as it is currently defined in 3697bis. Since this is a DISCUSS position, the goal of this message is to educate the IESG on our line of thinking and allow other WG participants to chime in with other reasons I have omitted for keeping the flow label a single entity within the IPv6 header. Regards, Brian From joelja@bogus.com Mon Jul 18 09:51:01 2011 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 C1A8821F8B93; Mon, 18 Jul 2011 09:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.764 X-Spam-Level: X-Spam-Status: No, score=-102.764 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxmNRWnrAr6J; Mon, 18 Jul 2011 09:51:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6B21F8B8A; Mon, 18 Jul 2011 09:51:00 -0700 (PDT) Received: from [172.16.24.51] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6IGovJo053129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jul 2011 16:50:57 GMT (envelope-from joelja@bogus.com) Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Mon, 18 Jul 2011 09:50:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> To: Sander Steffann X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 18 Jul 2011 16:50:59 +0000 (UTC) Cc: IPv6 Operations , ipv6@ietf.org, Philip Homburg 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, 18 Jul 2011 16:51:01 -0000 On Jul 17, 2011, at 4:54 AM, Sander Steffann wrote: > Hi, >=20 >> I think the same applies to hosts with lots of VMs: maintaining a = potentially >> large number of NC entries for a single MAC address is unlikely to = scale. >> This is what routing is designed for. >=20 > Then why are there 64 bits in the IID? And I don't think it has = anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC = addresses scales as well as 1000 IPv6 addresses on 1000 MAC addresses. = It might make a difference for the switch, but not for ND/NC. ieee eui-64 uses 64 bits therefore some interface types (firewire ports = for example) have 64 bit mac address. we will eventually run out of 48 = bit mac addresses given there are only 16.7 million oui blocks... > - Sander > PS: I consider having the possibility of having a large amount of IPv6 = addresses on one interface a great feature, not something I would want = to limit. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nordmark@acm.org Mon Jul 18 15:39:44 2011 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 3B52021F881C for ; Mon, 18 Jul 2011 15:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOphoKg6l-3b for ; Mon, 18 Jul 2011 15:39:43 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0221F86A6 for ; Mon, 18 Jul 2011 15:39:43 -0700 (PDT) Received: from [192.168.1.102] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p6IMdW2O030603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 18 Jul 2011 15:39:35 -0700 Message-ID: <4E24B625.1010301@acm.org> Date: Mon, 18 Jul 2011 15:39:33 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Karl Auer Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> In-Reply-To: <1310991930.2724.17.camel@karl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 18 Jul 2011 22:39:44 -0000 On 7/18/11 5:25 AM, Karl Auer wrote: > I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6. > > It contains these two paragraphs towards the end of Section 4: > > A node MUST NOT reduce its estimate of the Path MTU below the IPv6 > minimum link MTU. > > Note: A node may receive a Packet Too Big message reporting a > next-hop MTU that is less than the IPv6 minimum link MTU. In that > case, the node is not required to reduce the size of subsequent > packets sent on the path to less than the IPv6 minimun link MTU, > but rather must include a Fragment header in those packets [IPv6- > SPEC]. > > What does that mean - "insert a Fragment header"? And it may not be > *required* to reduce the size of subsequent packets, but does that mean > it *can* if it wants to? And isn't inserting a whole new header a bit > counterproductive if someone is telling your your packets are too big > already? All in all I have this strong feeling I'm missing something > obvious. Any clues gratefully received. The motivation for the fragment header insertion was to be able to support stateless IPv6->IPv4 translators (with multi-path routing), such as RFC 2765. Such a translator normally sets DF (don't fragment) in the IPv4 packets. But should the IPv4 path MTU drop below 1300 (meaning that a translated 1280 byte IPv6 packet wouldn't fit), then DF can't be set. In that case a unique IP ID field is needed. The fragment header contains a unique ID which will be used by the translator. I hope that helps clarify the motivation, Erik From brian.e.carpenter@gmail.com Mon Jul 18 16:00:48 2011 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 6843121F877D; Mon, 18 Jul 2011 16:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.617 X-Spam-Level: X-Spam-Status: No, score=-103.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTW78c+cRZAe; Mon, 18 Jul 2011 16:00:47 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEB3821F8762; Mon, 18 Jul 2011 16:00:47 -0700 (PDT) Received: by vxi40 with SMTP id 40so3463320vxi.31 for ; Mon, 18 Jul 2011 16:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vK6BbF7S9xwbXCtqqz4uUbKC7D9EP7ysNLftoCdTXiY=; b=sRTDrvWVR+GNB8Zgt+Luy7jj1er/bIOlJcZiLP3/o6LMOvTxeMqmtw+cFqN69Gn4P5 zSzvLZ8Itrp30zIkZWwfI2Z/XeTdvT6JdJ8aG2PDL09qvicn9Y/DNGLwAEPa9fHXDxnm U7ksv+mYfk7cYgZi2QTyV1aHC/gY2LmzcMrKU= Received: by 10.52.64.142 with SMTP id o14mr2444347vds.100.1311030047191; Mon, 18 Jul 2011 16:00:47 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g7sm1985394vdv.33.2011.07.18.16.00.44 (version=SSLv3 cipher=OTHER); Mon, 18 Jul 2011 16:00:46 -0700 (PDT) Message-ID: <4E24BB1A.8060304@gmail.com> Date: Tue, 19 Jul 2011 11:00:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman Subject: Re: DISCUSS: draft-ietf-6man-flow-3697bis and reserving bits from the flow label References: <4E245695.6070204@innovationslab.net> In-Reply-To: <4E245695.6070204@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Mailing List , "iesg@ietf.org IESG" 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, 18 Jul 2011 23:00:48 -0000 On 2011-07-19 03:51, Brian Haberman wrote: > 6MAN Participants, > During IESG evaluation, a DISCUSS position was raised on whether or > not several of the bits (4 was suggested) be reserved as a discriminator > to identify how the flow label is being used. We had a discussion in > 2010 on separating the current 20 bits of flow label into sub-fields > (discussion started around this point in the mailing list archives : > http://www.ietf.org/mail-archive/web/ipv6/current/msg12031.html). > > The consensus from that mailing list discussion was to not divide > the flow label for several reasons: > > 1. Encoding semantics was too complex to handle at line rate > > 2. A 16-bit flow label may be too easy to predict > > 3. These fields are not protected in anyway, so there is little trust in > the values set > > The above reasons led to the decision to retain the flow label as a > single 20-bit field as it is currently defined in 3697bis. Since this > is a DISCUSS position, the goal of this message is to educate the IESG > on our line of thinking and allow other WG participants to chime in with > other reasons I have omitted for keeping the flow label a single entity > within the IPv6 header. I would add three points: 4. A somewhat similar idea was proposed to the WG in draft-carpenter-6man-flow-update-01 (March 2010), although it only used one bit: "o If the most significant bit (MSB) of the flow label is 0 and the flow label is not all-zero, then the remaining 19 bits MUST obey the rules of [RFC3697]. o If the MSB of the flow label is 1, the remaining 19 bits MAY obey a locally defined set of rules and those bits MAY be changed en route." There was painfully strong consensus against this approach at IETF77 and IETF78. 5. The DISCUSS says "This specification uses the full size of the flow label. Since it has no discriminator to indicate that it is being used for load balancing, no other use can be made of this field." It isn't completely true that the draft precludes any other use. It precludes any other use *without signaling*. If (for example) Intserv/RSVP was used to signal a flow label value as part of a Tspec, it could have a specific meaning. 6. This is a bit of a FUD argument, but changing the flow label size at this point might cause interop problems for any existing deployment that conforms to RFC 3697. The current 3697bis proposal is very unlikely to cause such problems. Regards Brian Carpenter From fweimer@bfk.de Tue Jul 19 02:00:33 2011 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 626AC21F86BD for ; Tue, 19 Jul 2011 02:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f11ix7gyw1ac for ; Tue, 19 Jul 2011 02:00:29 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECFE21F863A for ; Tue, 19 Jul 2011 02:00:29 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qj6A9-0000WH-Eh; Tue, 19 Jul 2011 09:00:21 +0000 Received: by bfk.de with local id 1Qj6A9-0004nh-9W; Tue, 19 Jul 2011 09:00:21 +0000 From: Florian Weimer To: Erik Nordmark Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> Date: Tue, 19 Jul 2011 09:00:21 +0000 In-Reply-To: <4E24B625.1010301@acm.org> (Erik Nordmark's message of "Mon, 18 Jul 2011 15:39:33 -0700") Message-ID: <82ipqyd4re.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 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, 19 Jul 2011 09:00:33 -0000 * Erik Nordmark: > The motivation for the fragment header insertion was to be able to > support stateless IPv6->IPv4 translators (with multi-path routing), > such as RFC 2765. > > Such a translator normally sets DF (don't fragment) in the IPv4 > packets. But should the IPv4 path MTU drop below 1300 (meaning that a > translated 1280 byte IPv6 packet wouldn't fit), Stateless gateways cannot perform path MTU discovery, so they don't know about path MTU, and need to send packets with DF=3D0. > then DF can't be set. In that case a unique IP ID field is needed. The > fragment header contains a unique ID which will be used by the > translator. Why wouldn't the translator be able to pull a random ID out of thin air? How would it generate a unique 16 bit IP ID field from a unique 32 bit IP ID field? It can't just discard the upper 16 bits and pretend that they aren't required to ensure uniqueness. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From kauer@biplane.com.au Tue Jul 19 04:26:59 2011 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 7B4C021F86F9 for ; Tue, 19 Jul 2011 04:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dGXqBlQJY4b for ; Tue, 19 Jul 2011 04:26:55 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 225AD21F86E8 for ; Tue, 19 Jul 2011 04:26:53 -0700 (PDT) Received: from ppp-45-20.grapevine.net.au ([203.129.45.20] helo=[192.168.2.4]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qj8Ru-00053z-RC for ipv6@ietf.org; Tue, 19 Jul 2011 07:26:50 -0400 Subject: Re: PMTUD and MTU < 1280 From: Karl Auer To: IETF IPv6 In-Reply-To: <4E24B625.1010301@acm.org> References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gqCKjlwVBNdpWDForKmu" Date: Tue, 19 Jul 2011 21:26:47 +1000 Message-ID: <1311074807.2724.74.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 19 Jul 2011 11:26:59 -0000 --=-gqCKjlwVBNdpWDForKmu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-07-18 at 15:39 -0700, Erik Nordmark wrote: > The motivation for the fragment header insertion was to be able to=20 > support stateless IPv6->IPv4 translators (with multi-path routing), such= =20 > as RFC 2765. >=20 > Such a translator normally sets DF (don't fragment) in the IPv4 packets.= =20 > But should the IPv4 path MTU drop below 1300 (meaning that a translated= =20 > 1280 byte IPv6 packet wouldn't fit), then DF can't be set. In that case= =20 > a unique IP ID field is needed. The fragment header contains a unique ID= =20 > which will be used by the translator. >=20 > I hope that helps clarify the motivation, Thanks Erik. I've read the explanation in RFC 2765, and sort of see the motivation, but it doesn't help me understand exactly what the node should be doing. That is, the "why" is slightly clearer, but the "what" is not. What, exactly, is a node supposed to do when it receives a PTB < 1280 after it has sent an ordinary packet? a) fragment at 1280, regardless of the returned PMTU value b) fragment so as to produce fragments of sizes equal to or smaller than the returned PMTU value, but don't "remember" the returned PMTU value c) create a new packet that is identical to the original packet but has a fragment header inserted (i.e., forms a fragment sequence one fragment long, with More-Fragments=3D0 in the fragment header) d) fail to send the packet e) something else...? Only b) seems remotely useful, but it makes a mockery of the idea that a PMTU of 1280 is required for IPv6. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-gqCKjlwVBNdpWDForKmu 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) iEYEABECAAYFAk4lae0ACgkQMAcU7Vc29ofpZACgw4OhaSRcGKedhLKivS9Nbz7u xUwAoMK9/CzsGjzJGmQwFQLbZiCdjQdW =teBA -----END PGP SIGNATURE----- --=-gqCKjlwVBNdpWDForKmu-- From fweimer@bfk.de Tue Jul 19 04:46:41 2011 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 455BB21F858E for ; Tue, 19 Jul 2011 04:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqmoFPJ4pHTy for ; Tue, 19 Jul 2011 04:46:37 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 131AC21F84FB for ; Tue, 19 Jul 2011 04:46:36 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qj8kz-0006th-Fa; Tue, 19 Jul 2011 11:46:33 +0000 Received: by bfk.de with local id 1Qj8kz-0001B9-CV; Tue, 19 Jul 2011 11:46:33 +0000 From: Florian Weimer To: Karl Auer Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <1311074807.2724.74.camel@karl> Date: Tue, 19 Jul 2011 11:46:33 +0000 In-Reply-To: <1311074807.2724.74.camel@karl> (Karl Auer's message of "Tue, 19 Jul 2011 21:26:47 +1000") Message-ID: <82fwm2bihy.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 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, 19 Jul 2011 11:46:41 -0000 * Karl Auer: > What, exactly, is a node supposed to do when it receives a PTB < 1280 > after it has sent an ordinary packet? > > a) fragment at 1280, regardless of the returned PMTU value > > b) fragment so as to produce fragments of sizes equal to or smaller than > the returned PMTU value, but don't "remember" the returned PMTU value > > c) create a new packet that is identical to the original packet but has > a fragment header inserted (i.e., forms a fragment sequence one fragment > long, with More-Fragments=3D0 in the fragment header) > > d) fail to send the packet > > e) something else...? > > Only b) seems remotely useful, but it makes a mockery of the idea that a > PMTU of 1280 is required for IPv6. b) seems impossible to implement because ICMP messages cannot be reliably mapped to individual packets. Thats why d) isn't an option either (trivial DoS vector). c) is required by the IPv6 RFC, but this is broken. a) is consistent with optional PMTUD, so it seems the sanest choice. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nordmark@acm.org Tue Jul 19 08:15:26 2011 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 4ED6021F8A4F for ; Tue, 19 Jul 2011 08:15:26 -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=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnRe74v71fPb for ; Tue, 19 Jul 2011 08:15:25 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7108921F8A51 for ; Tue, 19 Jul 2011 08:15:25 -0700 (PDT) Received: from [192.168.1.102] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p6JFFCtY032003 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2011 08:15:15 -0700 Message-ID: <4E259F7D.2010600@acm.org> Date: Tue, 19 Jul 2011 08:15:09 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Karl Auer Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <1311074807.2724.74.camel@karl> In-Reply-To: <1311074807.2724.74.camel@karl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 19 Jul 2011 15:15:26 -0000 On 7/19/11 4:26 AM, Karl Auer wrote: > Thanks Erik. I've read the explanation in RFC 2765, and sort of see the > motivation, but it doesn't help me understand exactly what the node > should be doing. That is, the "why" is slightly clearer, but the "what" > is not. > > What, exactly, is a node supposed to do when it receives a PTB< 1280 > after it has sent an ordinary packet? > > a) fragment at 1280, regardless of the returned PMTU value Correct; fragment as if the path mtu was 1280. But in addition, insert a fragment header even for packets that don't require fragmentation. Erik > b) fragment so as to produce fragments of sizes equal to or smaller than > the returned PMTU value, but don't "remember" the returned PMTU value > > c) create a new packet that is identical to the original packet but has > a fragment header inserted (i.e., forms a fragment sequence one fragment > long, with More-Fragments=0 in the fragment header) > > d) fail to send the packet > > e) something else...? > > Only b) seems remotely useful, but it makes a mockery of the idea that a > PMTU of 1280 is required for IPv6. > > Regards, K. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nordmark@acm.org Tue Jul 19 08:18:56 2011 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 A243221F8A4F for ; Tue, 19 Jul 2011 08:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kofTASYDl3pp for ; Tue, 19 Jul 2011 08:18:56 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 32F6221F8A7D for ; Tue, 19 Jul 2011 08:18:55 -0700 (PDT) Received: from [192.168.1.102] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p6JFIfN4009588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2011 08:18:44 -0700 Message-ID: <4E25A050.6050102@acm.org> Date: Tue, 19 Jul 2011 08:18:40 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Florian Weimer Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <82ipqyd4re.fsf@mid.bfk.de> In-Reply-To: <82ipqyd4re.fsf@mid.bfk.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 19 Jul 2011 15:18:56 -0000 On 7/19/11 2:00 AM, Florian Weimer wrote: > * Erik Nordmark: > >> The motivation for the fragment header insertion was to be able to >> support stateless IPv6->IPv4 translators (with multi-path routing), >> such as RFC 2765. >> >> Such a translator normally sets DF (don't fragment) in the IPv4 >> packets. But should the IPv4 path MTU drop below 1300 (meaning that a >> translated 1280 byte IPv6 packet wouldn't fit), > > Stateless gateways cannot perform path MTU discovery, so they don't know > about path MTU, and need to send packets with DF=0. It is the end hosts that perform pmtu discovery; the translator just maps from IPv6 to IPv4 and vice versa. Look at RFC 2765 for the details. >> then DF can't be set. In that case a unique IP ID field is needed. The >> fragment header contains a unique ID which will be used by the >> translator. > > Why wouldn't the translator be able to pull a random ID out of thin air? Then different fragmented datagrams between the same source and dest traveling through different translators could get the same ID, resulting in a risk of (persistent) incorrect reassembly. > How would it generate a unique 16 bit IP ID field from a unique 32 bit > IP ID field? It can't just discard the upper 16 bits and pretend that > they aren't required to ensure uniqueness. Sure it can; the assumption is that for each the fragment IDs are assigned sequentially or otherwise can be truncated to 16 bits. (I haven't checked what is in RFC on this point though.) Erik From pch-b2B3A6689@u-1.phicoh.com Tue Jul 19 08:51:45 2011 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 AA2CC11E8088 for ; Tue, 19 Jul 2011 08:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHfMPxPpQhll for ; Tue, 19 Jul 2011 08:51:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 31ADA21F84DA for ; Tue, 19 Jul 2011 08:51:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QjCZv-0001fWC; Tue, 19 Jul 2011 17:51:23 +0200 Message-Id: To: Erik Nordmark Subject: Re: PMTUD and MTU < 1280 From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <82ipqyd4re.fsf@mid.bfk.de> <4E25A050.6050102@acm.org> In-reply-to: Your message of "Tue, 19 Jul 2011 08:18:40 -0700 ." <4E25A050.6050102@acm.org> Date: Tue, 19 Jul 2011 17:51:05 +0200 Cc: IETF IPv6 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, 19 Jul 2011 15:51:45 -0000 In your letter dated Tue, 19 Jul 2011 08:18:40 -0700 you wrote: >Then different fragmented datagrams between the same source and dest >traveling through different translators could get the same ID, resulting >in a risk of (persistent) incorrect reassembly. How can it be persistently incorrect? If translators generate random numbers the chance of collission depends on the number of packets being assembled at the same time. So that should be in the order of 1 in 10000 or so. Of course, this already requires a lot of reordering. Then the data will also be covered by a TCP or UDP checksum. >> How would it generate a unique 16 bit IP ID field from a unique 32 bit >> IP ID field? It can't just discard the upper 16 bits and pretend that >> they aren't required to ensure uniqueness. > >Sure it can; the assumption is that for each >the fragment IDs are assigned sequentially or otherwise can be truncated >to 16 bits. (I haven't checked what is in RFC on this point though.) RFC-2460 doesn't seem to require sequential. For IPv4 it is good security practice to make it random. From nordmark@acm.org Tue Jul 19 09:36:39 2011 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 5FCBE21F8538 for ; Tue, 19 Jul 2011 09:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.049 X-Spam-Level: X-Spam-Status: No, score=-104.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvJzNCz-sWy2 for ; Tue, 19 Jul 2011 09:36:38 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0A421F84FD for ; Tue, 19 Jul 2011 09:36:21 -0700 (PDT) Received: from [192.168.1.102] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p6JGa6pZ020160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2011 09:36:13 -0700 Message-ID: <4E25B275.6000700@acm.org> Date: Tue, 19 Jul 2011 09:36:05 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Philip Homburg Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <82ipqyd4re.fsf@mid.bfk.de> <4E25A050.6050102@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 19 Jul 2011 16:36:39 -0000 On 7/19/11 8:51 AM, Philip Homburg wrote: > In your letter dated Tue, 19 Jul 2011 08:18:40 -0700 you wrote: >> Then different fragmented datagrams between the same source and dest >> traveling through different translators could get the same ID, resulting >> in a risk of (persistent) incorrect reassembly. > > How can it be persistently incorrect? Depends whether it is truly random, or pseudo-random, or random initial value plus an monotonic increment. > If translators generate random numbers the chance of collission depends on > the number of packets being assembled at the same time. So that should be > in the order of 1 in 10000 or so. Of course, this already requires a lot of > reordering. > > Then the data will also be covered by a TCP or UDP checksum. > >>> How would it generate a unique 16 bit IP ID field from a unique 32 bit >>> IP ID field? It can't just discard the upper 16 bits and pretend that >>> they aren't required to ensure uniqueness. >> >> Sure it can; the assumption is that for each >> the fragment IDs are assigned sequentially or otherwise can be truncated >> to 16 bits. (I haven't checked what is in RFC on this point though.) > > RFC-2460 doesn't seem to require sequential. For IPv4 it is good security > practice to make it random. RFC 2460 doesn't use MUST/SHOULD/MAY RFC 2119 language, hence it is a bit hard to gauge the strength of its text. RFC 2460 does contain this text: * "recently" means within the maximum likely lifetime of a packet, including transit time from source to destination and time spent awaiting reassembly with other fragments of the same packet. However, it is not required that a source node know the maximum packet lifetime. Rather, it is assumed that the requirement can be met by maintaining the Identification value as a simple, 32- bit, "wrap-around" counter, incremented each time a packet must be fragmented Erik From pch-b2B3A6689@u-1.phicoh.com Tue Jul 19 10:32:41 2011 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 809C021F867A for ; Tue, 19 Jul 2011 10:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.523 X-Spam-Level: X-Spam-Status: No, score=-8.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbzV7Ejarv3e for ; Tue, 19 Jul 2011 10:32:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8B321F8678 for ; Tue, 19 Jul 2011 10:32:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QjE9q-0001jgC; Tue, 19 Jul 2011 19:32:34 +0200 Message-Id: To: Erik Nordmark Subject: Re: PMTUD and MTU < 1280 From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <82ipqyd4re.fsf@mid.bfk.de> <4E25A050.6050102@acm.org> <4E25B275.6000700@acm.org> In-reply-to: Your message of "Tue, 19 Jul 2011 09:36:05 -0700 ." <4E25B275.6000700@acm.org> Date: Tue, 19 Jul 2011 19:32:15 +0200 Cc: IETF IPv6 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, 19 Jul 2011 17:32:41 -0000 In your letter dated Tue, 19 Jul 2011 09:36:05 -0700 you wrote: >On 7/19/11 8:51 AM, Philip Homburg wrote: >> How can it be persistently incorrect? > >Depends whether it is truly random, or pseudo-random, or random initial >value plus an monotonic increment. Truly random sounds a bit expensive for a translator. Yes, pseudo-random is what you want. And any kind of counter, no matter how it is initialized, doesn't count as random. >RFC 2460 doesn't use MUST/SHOULD/MAY RFC 2119 language, hence it is a >bit hard to gauge the strength of its text. >RFC 2460 does contain this text: > * "recently" means within the maximum likely lifetime of a packet, > including transit time from source to destination and time spent > awaiting reassembly with other fragments of the same packet. > However, it is not required that a source node know the maximum > packet lifetime. Rather, it is assumed that the requirement can > be met by maintaining the Identification value as a simple, 32- > bit, "wrap-around" counter, incremented each time a packet must > be fragmented I guess the most fun can be had if a host implements a counter, but then accidentally writes out the counter as a little endian value. But I guess that is easy to solve. Harder to solve would be the case where the IPv6 host is actually a busy server, say a DNS server, that doesn't want to keep any state and just has the link MTU set to 1280. From samita.chakrabarti@ericsson.com Tue Jul 19 12:38:18 2011 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 31BAA21F858D; Tue, 19 Jul 2011 12:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7Zhd+aapG+w; Tue, 19 Jul 2011 12:38:17 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7838621F8577; Tue, 19 Jul 2011 12:38:17 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6JJc2F3001195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2011 14:38:14 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.121]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 19 Jul 2011 15:38:10 -0400 From: Samita Chakrabarti To: "int-area@ietf.org" , "ipv6@ietf.org" Date: Tue, 19 Jul 2011 15:38:09 -0400 Subject: Optimization of RFC 4861 for Energy-aware networks Thread-Topic: Optimization of RFC 4861 for Energy-aware networks Thread-Index: AcxGS2OJwJ0R+2XYTa2StJzeYKZCZA== Message-ID: <16D60F43CA0B724F8052D7E9323565D71E6728BEFC@EUSAACMS0715.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_16D60F43CA0B724F8052D7E9323565D71E6728BEFCEUSAACMS0715e_" MIME-Version: 1.0 Cc: Erik Nordmark 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, 19 Jul 2011 19:38:18 -0000 --_000_16D60F43CA0B724F8052D7E9323565D71E6728BEFCEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all: In 6lowpan workgroup, we developed draft-ietf-6lowpan-nd which provides op= timization of IPv6 ND for IEEE802.15.4 devices by avoiding all-node and sol= icited-node multicast messages for the most part and providing a method for= device registration with a IPv6 Border router in a route-over topology an= d as well as single-hop topology. In the last IOT workshop at IETF, it has been brought up that the 6lowpan-n= d like document may be useful in many other cases where devices are not IEE= E 802.15.4 devices but the nodes are basically energy-aware and like to sav= e energy as much as possible. 'Hello' or periodic advertisement/solicitati= on messages generally work well for line-powered devices, yet reducing the = periodic messages may be useful for less power consumption for each connect= ed device and therefore reducing overall energy consumption of the network.= Needless to say that the reduced number of messages and avoidance of perio= dic all-node or solicited-node multicast messages are critical for some low= -powered device operations. With EUI-64 IID, a DAD is not necessary if the = deployment may choose to do so. Here is an attempt to put together the first draft for generic optimization= for energy-aware IPv6 networks: http://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-nd-00 Comments are welcome. Would like the help from the community to shape this = document up for generic energy optimization for IPv6 ND in applicable case= s. This document also discusses a way of prefix dissemination for address a= uto-configuration which may be useful in future home network in a single pr= efix scenario. With the proliferation of internet-of-things, it might be he= lpful to do address auto-configuration in some isolated situations. More work is needed in this document - it is the initial effort to begin wi= th. Regards, -Samita --_000_16D60F43CA0B724F8052D7E9323565D71E6728BEFCEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello=20 all:
 
In 6lowpa= n=20 workgroup, we developed  draft-ietf-6lowpan-nd which provides optimiza= tion=20 of IPv6 ND for IEEE802.15.4 devices by avoiding all-node and solicited-node= =20 multicast messages for the most part and providing a method for device=20 registration with a IPv6 Border router in a route-over topology  and a= s=20 well as single-hop topology.
 
In the la= st IOT=20 workshop at IETF, it has been brought up that the 6lowpan-nd like document = may=20 be useful in many other cases where devices are not IEEE 802.15.4 devices b= ut=20 the nodes are basically energy-aware and like to save energy as much as=20 possible.  'Hello' or periodic advertisement/solicitation messages=20 generally work well for line-powered devices, yet reducing the periodic mes= sages=20 may be useful for less power consumption for each connected device and ther= efore=20 reducing overall energy consumption of the network. Needless to say that th= e=20 reduced number of messages and avoidance of periodic all-node or solicited-= node=20 multicast messages are critical for some low-powered device operations. Wit= h=20 EUI-64 IID, a DAD is not necessary if the deployment may choose to do so.=20
 
Here is a= n attempt=20 to put together the first draft for generic optimization for energy-aware I= Pv6=20 networks:
 
 
http://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-n= d-00
 
Comments = are=20 welcome. Would like the help from the community to shape this document up f= or=20 generic energy optimization for IPv6 ND  in applicable cases. This doc= ument=20 also discusses a way of prefix dissemination for address auto-configuration= =20 which may be useful in future home network in a single prefix scenario. Wit= h the=20 proliferation of internet-of-things, it might be helpful to do address=20 auto-configuration in some isolated situations.
More work= is=20 needed in this document - it is the initial effort to begin=20 with.
 
Regards,
-Samita
--_000_16D60F43CA0B724F8052D7E9323565D71E6728BEFCEUSAACMS0715e_-- From brian.e.carpenter@gmail.com Tue Jul 19 18:02:44 2011 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 027BC21F8AB9 for ; Tue, 19 Jul 2011 18:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.616 X-Spam-Level: X-Spam-Status: No, score=-103.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK5qEyaPyhC4 for ; Tue, 19 Jul 2011 18:02:41 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C082921F8AAA for ; Tue, 19 Jul 2011 18:02:40 -0700 (PDT) Received: by vws12 with SMTP id 12so4406852vws.31 for ; Tue, 19 Jul 2011 18:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l4DoeabQtipl5KKabNpq8lu0A6IoKcmeeAEPcF+5/Xo=; b=WK5FEb6V6Ulb1giQfWiy4cUTVgxZ50U/I/vYIAOgXxC3xSEYJtutvxSkLmcRh5GmjS Hq1ofXYBAHaPXNFLp1HFdmkGUR+SOmowSwpIfZnKdrGbzSyy2HxnDn6RO+gMnk57k9oz TCFYS3xa7kE3RXXcdw//qnl+DY95U85skLMw0= Received: by 10.52.92.84 with SMTP id ck20mr8031405vdb.376.1311123759876; Tue, 19 Jul 2011 18:02:39 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id cn9sm833238vdc.44.2011.07.19.18.02.37 (version=SSLv3 cipher=OTHER); Tue, 19 Jul 2011 18:02:39 -0700 (PDT) Message-ID: <4E262935.9020509@gmail.com> Date: Wed, 20 Jul 2011 13:02:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Erik Nordmark Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <1311074807.2724.74.camel@karl> <4E259F7D.2010600@acm.org> In-Reply-To: <4E259F7D.2010600@acm.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 20 Jul 2011 01:02:44 -0000 On 2011-07-20 03:15, Erik Nordmark wrote: > On 7/19/11 4:26 AM, Karl Auer wrote: > >> Thanks Erik. I've read the explanation in RFC 2765, and sort of see the >> motivation, but it doesn't help me understand exactly what the node >> should be doing. That is, the "why" is slightly clearer, but the "what" >> is not. >> >> What, exactly, is a node supposed to do when it receives a PTB< 1280 >> after it has sent an ordinary packet? >> >> a) fragment at 1280, regardless of the returned PMTU value > > Correct; fragment as if the path mtu was 1280. > But in addition, insert a fragment header even for packets that don't > require fragmentation. It's always been my understanding that an interface sending IPv6 packets MUST implement some (unspecified) form of framentation and reassembly *below layer 3* if the link MTU is less than 1280. In other words a PTB for a packet of length 1280 is an unrecoverable violation. For example, if you're tunneling IPv6 over an IPv4 network whose PMTU (to the other end of the tunnel) is, to take a random example, 576, the tunnel end points could use IPv4 fragmentation and reassembly to provide a 1280 MTU for the IPv6 traffic. Of course this doesn't cover the NAT64 case; so what? NAT breaks many things. We just have to rely on the real world, where the layer 2 link MTU is pretty much always 1500 today. Brian From nordmark@acm.org Tue Jul 19 22:28:19 2011 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 75DF021F891D for ; Tue, 19 Jul 2011 22:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkzRXVyl-0pT for ; Tue, 19 Jul 2011 22:28:19 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1276C21F8877 for ; Tue, 19 Jul 2011 22:28:18 -0700 (PDT) Received: from [192.168.1.102] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p6K5S3qA010160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2011 22:28:07 -0700 Message-ID: <4E266763.7020406@acm.org> Date: Tue, 19 Jul 2011 22:28:03 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: PMTUD and MTU < 1280 References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <1311074807.2724.74.camel@karl> <4E259F7D.2010600@acm.org> <4E262935.9020509@gmail.com> In-Reply-To: <4E262935.9020509@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 20 Jul 2011 05:28:19 -0000 On 7/19/11 6:02 PM, Brian E Carpenter wrote: >> Correct; fragment as if the path mtu was 1280. >> But in addition, insert a fragment header even for packets that don't >> require fragmentation. > > It's always been my understanding that an interface sending IPv6 packets > MUST implement some (unspecified) form of framentation and reassembly > *below layer 3* if the link MTU is less than 1280. In other words a > PTB for a packet of length 1280 is an unrecoverable violation. > > For example, if you're tunneling IPv6 over an IPv4 network whose PMTU (to > the other end of the tunnel) is, to take a random example, 576, the tunnel > end points could use IPv4 fragmentation and reassembly to provide a 1280 MTU > for the IPv6 traffic. That would be true for tunneling IPv6 over IPv4. But the topic was the wording in RFC 2460 that was added to make it feasible to build (stateless) translators between IPv6 and IPv4. > Of course this doesn't cover the NAT64 case; so what? NAT breaks many things. > We just have to rely on the real world, where the layer 2 link MTU is pretty > much always 1500 today. We do have language in RFC 2460 to handle this particular case. Erik From pch-b2B3A6689@u-1.phicoh.com Wed Jul 20 01:09:33 2011 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 2918C21F8782 for ; Wed, 20 Jul 2011 01:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJje2uAa8YJ0 for ; Wed, 20 Jul 2011 01:09:32 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3342E21F8761 for ; Wed, 20 Jul 2011 01:09:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QjRqO-0001j6C; Wed, 20 Jul 2011 10:09:24 +0200 Message-Id: To: Erik Nordmark Subject: Re: PMTUD and MTU < 1280 From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <1310991930.2724.17.camel@karl> <4E24B625.1010301@acm.org> <1311074807.2724.74.camel@karl> <4E259F7D.2010600@acm.org> <4E262935.9020509@gmail.com> <4E266763.7020406@acm.org> In-reply-to: Your message of "Tue, 19 Jul 2011 22:28:03 -0700 ." <4E266763.7020406@acm.org> Date: Wed, 20 Jul 2011 10:09:18 +0200 Cc: IETF IPv6 , Brian E Carpenter 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, 20 Jul 2011 08:09:33 -0000 In your letter dated Tue, 19 Jul 2011 22:28:03 -0700 you wrote: >On 7/19/11 6:02 PM, Brian E Carpenter wrote: >> For example, if you're tunneling IPv6 over an IPv4 network whose PMTU (to >> the other end of the tunnel) is, to take a random example, 576, the tunnel >> end points could use IPv4 fragmentation and reassembly to provide a 1280 MTU >> for the IPv6 traffic. > >That would be true for tunneling IPv6 over IPv4. >But the topic was the wording in RFC 2460 that was added to make it >feasible to build (stateless) translators between IPv6 and IPv4. Personally, I think it is just bad design to require extra complexity in every IPv6 stack in the world, just to accodate a transition technology that essentially hasn't been used in the last 15 years, that provides no benefit to hosts that allocate fragment IDs randomly (as is good security practice for IPv4) and provides marginal benefits for hosts that allocate IDs sequentially. I would suggest that the stateless translator protocols be updated to not use this feature and allocate a random 16-bit ID themselves. And schedule the feature to be remove from the IPv6 standard. From pch-b2B3A6689@u-1.phicoh.com Wed Jul 20 09:17:28 2011 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 1541D21F8620 for ; Wed, 20 Jul 2011 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhu5rc6LiGkN for ; Wed, 20 Jul 2011 09:17:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 41C5321F861E for ; Wed, 20 Jul 2011 09:17:26 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QjZSc-0001iNC; Wed, 20 Jul 2011 18:17:22 +0200 Message-Id: To: Erik Nordmark Subject: Re: Fwd: New Version Notification for draft-nordmark-6man-impatient-nud-01.txt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Thu, 07 Jul 2011 13:41:41 -0700 ." <4E161A05.6050605@acm.org> Date: Wed, 20 Jul 2011 18:17:13 +0200 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, 20 Jul 2011 16:17:28 -0000 In your letter dated Thu, 07 Jul 2011 13:41:41 -0700 you wrote: >A new version of I-D, draft-nordmark-6man-impatient-nud-01.txt has been >successfully submitted by Erik Nordmark and posted to the IETF repository. A few remarks about this draft: 1) It must be somewhere in RFC-4861, but it is not easy to find and it's probably best to help implementors here: if a NCE for a router transitions to UNREACHABLE state and there are still default routers in REACHABLE, STALE, DELAY, or PROBE state then delete all destination Cache entries for that router. 2) Similar for redirect. If there is a Destination Cache entry and it resulted from a redirect, then delete it. Also update the host state description for the destination cache to include a redirected flag. 3) As long as the the NCE is in UNREACHABLE state, there won't be any Destination Unreachable ICMPs. I think there are two ways of dealing with that: - delete the NCE entry after some time. This requires the operator to balance between keeping the entry longer of getting timely ICMPs. - After while, just send ICMPs back while forwarding the packet. I don't know if anybody ever did this. This may result in duplicate packets. But there is something wrong with the connection anyhow. In general I think this a good approach. From nordmark@acm.org Wed Jul 20 10:18:10 2011 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 1B08D21F867F for ; Wed, 20 Jul 2011 10:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.269 X-Spam-Level: X-Spam-Status: No, score=-104.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OSjbPAQyoZp for ; Wed, 20 Jul 2011 10:18:09 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id A124B21F8640 for ; Wed, 20 Jul 2011 10:18:09 -0700 (PDT) Received: from [192.168.1.102] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p6KHHt7G020332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2011 10:18:03 -0700 Message-ID: <4E270DBF.2020001@acm.org> Date: Wed, 20 Jul 2011 10:17:51 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Fwd: New Version Notification for draft-nordmark-6man-impatient-nud-01.txt References: In-Reply-To: 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: Wed, 20 Jul 2011 17:18:10 -0000 On 7/20/11 9:17 AM, Philip Homburg wrote: > In your letter dated Thu, 07 Jul 2011 13:41:41 -0700 you wrote: >> A new version of I-D, draft-nordmark-6man-impatient-nud-01.txt has been >> successfully submitted by Erik Nordmark and posted to the IETF repository. Thanks for your review. > A few remarks about this draft: > 1) It must be somewhere in RFC-4861, but it is not easy to find and it's > probably best to help implementors here: if a NCE for a router transitions > to UNREACHABLE state and there are still default routers in REACHABLE, > STALE, DELAY, or PROBE state then delete all destination Cache entries > for that router. The RFC in section 5.2 says to redo next-hop selection; it doesn't say to delete destination cache entries anywhere AFAIK. That should be sufficient even with the introduction of the UNREACHABLE state. > 2) Similar for redirect. If there is a Destination Cache entry and it resulted > from a redirect, then delete it. Also update the host state description > for the destination cache to include a redirected flag. I don't understand why this draft requires adding a redirect flag in RFC 4861. While such a flag might be useful in an implementation, it seems to be orthogonal to these proposed changes; whether the NCE becomes deleted (as in 4861 today) or marked as UNREACHABLE (with these changes) the same next-hop selection needs to be triggered. (Perhaps that should be stated more explicitly in the draft.) > 3) As long as the the NCE is in UNREACHABLE state, there won't be any > Destination Unreachable ICMPs. Good point - I didn't realize the exact wording in section 7.2.2. FWIW it says If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT solicitations, address resolution has failed. The sender MUST return ICMP destination unreachable indications with code 3 (Address Unreachable) for each packet queued awaiting address resolution. > I think there are two ways of dealing with > that: > - delete the NCE entry after some time. This requires the operator to > balance between keeping the entry longer of getting timely ICMPs. > - After while, just send ICMPs back while forwarding the packet. I don't > know if anybody ever did this. This may result in duplicate packets. But > there is something wrong with the connection anyhow. We could do the latter my augmenting the above text to also say to send ICMP destination unreachables (with code 3) when the packet is sent using a NCE that is in UNREACHABLE state. Erik > In general I think this a good approach. > From pch-b2B3A6689@u-1.phicoh.com Wed Jul 20 10:58:21 2011 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 2A28521F8B0F for ; Wed, 20 Jul 2011 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.539 X-Spam-Level: X-Spam-Status: No, score=-4.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaYtPuyDZVf2 for ; Wed, 20 Jul 2011 10:58:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 165D121F8ABC for ; Wed, 20 Jul 2011 10:58:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qjb2E-0001iVC; Wed, 20 Jul 2011 19:58:14 +0200 Message-Id: To: Erik Nordmark Subject: Re: Fwd: New Version Notification for draft-nordmark-6man-impatient-nud-01.txt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <4E270DBF.2020001@acm.org> In-reply-to: Your message of "Wed, 20 Jul 2011 10:17:51 -0700 ." <4E270DBF.2020001@acm.org> Date: Wed, 20 Jul 2011 19:58:05 +0200 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, 20 Jul 2011 17:58:21 -0000 In your letter dated Wed, 20 Jul 2011 10:17:51 -0700 you wrote: >> A few remarks about this draft: >> 1) It must be somewhere in RFC-4861, but it is not easy to find and it's >> probably best to help implementors here: if a NCE for a router transitio >ns >> to UNREACHABLE state and there are still default routers in REACHABLE, >> STALE, DELAY, or PROBE state then delete all destination Cache entries >> for that router. > >The RFC in section 5.2 says to redo next-hop selection; it doesn't say >to delete destination cache entries anywhere AFAIK. >That should be sufficient even with the introduction of the UNREACHABLE >state. I don't think the algorithm in 5.2 works all that well. In RFC-4861, when NUD has failed, the NCE is deleted. However, this does not actually signal anything to Destination Cache entries. There is only some wording that some things need to be done. Without any specification on how that is triggered exactly. Deleting, or otherwise marking as invalid the DCEs that correspond to the failing router is the easiest way to get the right result. >> 2) Similar for redirect. If there is a Destination Cache entry and it result >ed > from a redirect, then delete it. Also update the host state description >> for the destination cache to include a redirected flag. > >I don't understand why this draft requires adding a redirect flag in RFC >4861. While such a flag might be useful in an implementation, it seems >to be orthogonal to these proposed changes; whether the NCE becomes >deleted (as in 4861 today) or marked as UNREACHABLE (with these changes) >the same next-hop selection needs to be triggered. (Perhaps that should >be stated more explicitly in the draft.) In general, you can't figure out if NCE entry is the result of a redirect. You would have to examine the DCE to see if the destination is off-link. The easiest way is to always delete DCEs that refer to the NCE. The conceptual Destination Cache doesn't have to concept of entries that need next-hop selection. Now, this may not be the place to actually update all those parts of RFC-4861. But giving some hints on how things can be implemented may help. >We could do the latter my augmenting the above text to also say to send >ICMP destination unreachables (with code 3) when the packet is sent >using a NCE that is in UNREACHABLE state. While dropping the packet or also forwarding it using the last known MAC? From rja.lists@gmail.com Wed Jul 20 14:35:39 2011 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 B13B621F8888 for ; Wed, 20 Jul 2011 14:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwxaU6CR7sJ4 for ; Wed, 20 Jul 2011 14:35:35 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9860321F88A0 for ; Wed, 20 Jul 2011 14:35:35 -0700 (PDT) Received: by qwc23 with SMTP id 23so529145qwc.31 for ; Wed, 20 Jul 2011 14:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=UExOVzvmSmbyuzBLKyDoSc8dqM3gpnZ0/anFWe8yMCw=; b=GFEdyTlRMTYwSlCTn/JQXa0WfMHwb7yKMcObPSQy5zXw4q2OUx4iEU16j2Od0QX3Vd jDbOIxwG/fYeCvU4E2q1Rh1ehI3oW2HzmpiuP0XS+WCf/ZK5J1eioUJ8b+PhedvUCNu7 pEFOj5NZ5qp3I6bptXLzV7xZ+hpdXtAooupAs= Received: by 10.229.31.202 with SMTP id z10mr7254645qcc.260.1311197734960; Wed, 20 Jul 2011 14:35:34 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id s14sm405577qct.18.2011.07.20.14.35.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 14:35:33 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: PMTUD and MTU < 1280 Date: Wed, 20 Jul 2011 17:35:31 -0400 Message-Id: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 20 Jul 2011 21:35:39 -0000 Earlier, Brian Carpenter wrote: > It's always been my understanding that an interface sending IPv6 = packets > MUST implement some (unspecified) form of framentation and reassembly > *below layer 3* if the link MTU is less than 1280. In other words a > PTB for a packet of length 1280 is an unrecoverable violation. I also understand that the IPv6 specifications say that=20 the minimum IPv6 MTU for any link type is 1280 bytes. I am not sure the specs insist that an IPv6 implementation=20 must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes=20 as "unrecoverable". (I haven't re-read the IPv6 specs recently.) I understand that some deployed IPv6 implementations will tolerate and support Packet-Too-Big messages with a link MTU at least as small as 576 -- following the Postel Principle of "generous in what one accepts" and being practical about several radio link technologies that do not support a 1280 byte IP MTU. Such implementations are more resilient than the IPv6 specifications require; this is helpful. > For example, if you're tunneling IPv6 over an IPv4 network whose PMTU > (to the other end of the tunnel) is, to take a random example, 576, > the tunnel end points could use IPv4 fragmentation and reassembly > to provide a 1280 MTU for the IPv6 traffic. One could do that. Over low-bandwidth radio links the overhead of doing that would effectively make it preferable to deploy an IPv6::IPv4 = translator or some other protocol translation scheme (and continue with IPv4 = forever,=20 at least on that link) than to encapsulate IPv6 in anything more than=20 just the radio link layer just to meet the 1280 byte requirement. As I recall, I noted this problem to the IPv6 WG back in the middle = 1990s.[1] Sadly. that prediction seems to have come true. So I understand that = today,=20 over some deployed radio link technologies, several IPv6 implementations = use=20 the raw link encapsulation and fragment IPv6 into chunks at that raw = link MTU size (even though that is below 1280 bytes). > Of course this doesn't cover the NAT64 case; so what? NAT breaks many = things. > We just have to rely on the real world, where the layer 2 link MTU is = pretty > much always 1500 today. I agree that the IEEE standard Ethernet link MTU is very widely deployed today. Many, possibly most, Ethernet switches also support a link MTU somewhat over 9K bytes. =20 I'm told that SONET links most commonly use the old FDDI link MTU = (roughly 4500 bytes). =20 ATM links, which seem to be going away, most commonly support an IP MTU = near 9180 bytes (which value seems to have driven the Jumbo Ethernet = implementations). =20 However, there are still a number of link types, mostly radio link types=20= (as near as I can tell), that have a link MTU well below 1280 bytes. As=20= near as I can tell, IPv6 would have been much better off selecting 512 = bytes as the minimum IPv6 MTU size.[1] It is very unfortunate that IPv6 specifies this very large minimum MTU = size (i.e. 1280 bytes), because it is impeding the ability of various = organisations=20 to deploy IPv6 on a number of existing links that already support IPv4. This is just the kind of obstacle to deployment that IPv6 does not need. Specifying the value 1280 is not solving a real technical problem, IMHO. = =20 A lower value would facilitate faster, easier, simpler, and more = widespread=20 deployment and use of IPv6, IMHO. IPv4 can run over nearly any link without protocol changes or requiring special case handling. Sadly, IPv6 cannot make the same claim. One = hopes=20 IPv6 implementers will be tolerant of IPv6 MTUs below 1280 bytes, = because they do exist in the deployed world and aren't going away anytime soon. Yours, Ran Atkinson [1] = = From jhw@apple.com Wed Jul 20 14:44:28 2011 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 6E5E921F8888 for ; Wed, 20 Jul 2011 14:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.682 X-Spam-Level: X-Spam-Status: No, score=-106.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRBcQa0g-q3q for ; Wed, 20 Jul 2011 14:44:28 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0316621F880C for ; Wed, 20 Jul 2011 14:44:27 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LON00BH7J1KD9O1@mail-out.apple.com> for ipv6@ietf.org; Wed, 20 Jul 2011 14:44:27 -0700 (PDT) X-AuditID: 1180711d-b7c5fae000001427-18-4e274bfccaa5 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 relay13.apple.com (Apple SCV relay) with SMTP id 20.2E.05159.CFB472E4; Wed, 20 Jul 2011 14:43:24 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LON007QJJ21LS90@koseret.apple.com> for ipv6@ietf.org; Wed, 20 Jul 2011 14:44:26 -0700 (PDT) Subject: Re: PMTUD and MTU < 1280 From: james woodyatt In-reply-to: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> Date: Wed, 20 Jul 2011 14:44:23 -0700 Message-id: References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUiON1OXfePt7qfwdHVZhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpF7bewFO1gqbl1sY2tgPMLcxcjJISFgIjH53UQ2CFtM4sK9 9UA2F4eQQCeTxMd9T8ESvAKCEj8m32PpYuTgYBaQlzh4XhYkzCygJfH9USsLRP0yJon1k1+A 1QsLKEqcfPMabAGbgIrEt8t3mUBsTgFbib0zuhlB5rAIqEq0t7hAzBGUuDpzGliYV8BGorlD DiQsBGQu+LaZFSQsAlQ9/5wAxJXyEotbPjNOYBSYheS2WQi3zUJy2wJG5lWMgkWpOYmVhsZ6 iQUFOal6yfm5mxhBIddQKLuDcf9P/kOMAhyMSjy8jnzqfkKsiWXFlbmHGCU4mJVEeBX/qfkJ 8aYkVlalFuXHF5XmpBYfYpTmYFES5836oeonJJCeWJKanZpakFoEk2Xi4JQCBm/P8V9MO66Z toYLTjNn/x3dz+f87WLGzo5UkZ9V+yXviB54lrdkwveI2FqVG7Ny59yp6l6xriL507q8MqYW n4d9V8TrPTZ7+dqs/Zpqs6E5Ofg176I9p44VxnDvPDF/89sXqqE+x51jNq8V4P5z2ftOs5px f32pbO96szubd+lKq7/9HsIUqMRSnJFoqMVcVJwIAI1bdEM1AgAA 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, 20 Jul 2011 21:44:28 -0000 On Jul 20, 2011, at 14:35 , RJ Atkinson wrote: > One hopes IPv6 implementers will be tolerant of IPv6 MTUs below 1280 bytes, because they do exist in the deployed world and aren't going away anytime soon. Those hopes are not well placed. I am aware of at least one packet filter implementation-- which might be refined in the future, one hopes, to conform fully with RFC 6092-- that treats this behavior as a resource exhaustion attack and drops flows accordingly. -- james woodyatt member of technical staff, core os networking From rute.sofia@ulusofona.pt Wed Jul 20 16:51:29 2011 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 05B5A21F8658 for ; Wed, 20 Jul 2011 16:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um3Wxq2lkiSP for ; Wed, 20 Jul 2011 16:51:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC46021F8550 for ; Wed, 20 Jul 2011 16:51:24 -0700 (PDT) Received: by wwe5 with SMTP id 5so502012wwe.13 for ; Wed, 20 Jul 2011 16:51:23 -0700 (PDT) Received: by 10.227.182.2 with SMTP id ca2mr8345891wbb.89.1311205883523; Wed, 20 Jul 2011 16:51:23 -0700 (PDT) Received: from linux-phf7.site (89-181-195-204.net.novis.pt [89.181.195.204]) by mx.google.com with ESMTPS id 20sm591386wbw.2.2011.07.20.16.51.22 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 16:51:22 -0700 (PDT) Message-ID: <4E2768E6.80808@ulusofona.pt> Date: Thu, 21 Jul 2011 00:46:46 +0100 From: Rute Sofia Organization: SITI/ULHT/COFAC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Optimization of RFC 4861 for Energy-aware networks References: <16D60F43CA0B724F8052D7E9323565D71E6728BEFC@EUSAACMS0715.eamcs.ericsson.se> In-Reply-To: <16D60F43CA0B724F8052D7E9323565D71E6728BEFC@EUSAACMS0715.eamcs.ericsson.se> Content-Type: multipart/alternative; boundary="------------040300040306050907070905" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rute.sofia@ulusofona.pt List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 23:51:29 -0000 This is a multi-part message in MIME format. --------------040300040306050907070905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Samita, I will contribute, but do you have a specific deadline for us to send you comments? BR, Rute Sofia On 07/19/2011 08:38 PM, Samita Chakrabarti wrote: > Hello all: > In 6lowpan workgroup, we developed draft-ietf-6lowpan-nd which > provides optimization of IPv6 ND for IEEE802.15.4 devices by avoiding > all-node and solicited-node multicast messages for the most part and > providing a method for device registration with a IPv6 Border router > in a route-over topology and as well as single-hop topology. > In the last IOT workshop at IETF, it has been brought up that the > 6lowpan-nd like document may be useful in many other cases where > devices are not IEEE 802.15.4 devices but the nodes are basically > energy-aware and like to save energy as much as possible. 'Hello' or > periodic advertisement/solicitation messages generally work well for > line-powered devices, yet reducing the periodic messages may be useful > for less power consumption for each connected device and therefore > reducing overall energy consumption of the network. Needless to say > that the reduced number of messages and avoidance of periodic all-node > or solicited-node multicast messages are critical for some low-powered > device operations. With EUI-64 IID, a DAD is not necessary if the > deployment may choose to do so. > Here is an attempt to put together the first draft for generic > optimization for energy-aware IPv6 networks: > http://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-nd-00 > Comments are welcome. Would like the help from the community to shape > this document up for generic energy optimization for IPv6 ND in > applicable cases. This document also discusses a way of prefix > dissemination for address auto-configuration which may be useful in > future home network in a single prefix scenario. With the > proliferation of internet-of-things, it might be helpful to do address > auto-configuration in some isolated situations. > More work is needed in this document - it is the initial effort to > begin with. > Regards, > -Samita > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Rute Sofia, PhD (rute.sofia@ulusofona.pt) Scientific Director for Technology Research Unit in Informatics Systems and Technologies (SITI) Coordinator of the Internet Architecture and Networking Lab (IAN Lab) University Lusofona, Portugal rute.sofia@ulusofona.pt http://siti.ulusofona.pt Tel.: 217 515 500 Fax: 21 757 7006 ....................................................... --------------040300040306050907070905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Samita,

I will contribute, but do you have a specific deadline for us to send you comments?

BR,
Rute Sofia

On 07/19/2011 08:38 PM, Samita Chakrabarti wrote:
Hello all:
 
In 6lowpan workgroup, we developed  draft-ietf-6lowpan-nd which provides optimization of IPv6 ND for IEEE802.15.4 devices by avoiding all-node and solicited-node multicast messages for the most part and providing a method for device registration with a IPv6 Border router in a route-over topology  and as well as single-hop topology.
 
In the last IOT workshop at IETF, it has been brought up that the 6lowpan-nd like document may be useful in many other cases where devices are not IEEE 802.15.4 devices but the nodes are basically energy-aware and like to save energy as much as possible.  'Hello' or periodic advertisement/solicitation messages generally work well for line-powered devices, yet reducing the periodic messages may be useful for less power consumption for each connected device and therefore reducing overall energy consumption of the network. Needless to say that the reduced number of messages and avoidance of periodic all-node or solicited-node multicast messages are critical for some low-powered device operations. With EUI-64 IID, a DAD is not necessary if the deployment may choose to do so.
 
Here is an attempt to put together the first draft for generic optimization for energy-aware IPv6 networks:
 
 
 
Comments are welcome. Would like the help from the community to shape this document up for generic energy optimization for IPv6 ND  in applicable cases. This document also discusses a way of prefix dissemination for address auto-configuration which may be useful in future home network in a single prefix scenario. With the proliferation of internet-of-things, it might be helpful to do address auto-configuration in some isolated situations.
More work is needed in this document - it is the initial effort to begin with.
 
Regards,
-Samita

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



-- 
Rute Sofia, PhD (rute.sofia@ulusofona.pt)
Scientific Director for Technology
Research Unit in Informatics Systems and Technologies (SITI)
Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
University Lusofona, Portugal
rute.sofia@ulusofona.pt

http://siti.ulusofona.pt
Tel.: 217 515 500 Fax: 21 757 7006
.......................................................
--------------040300040306050907070905-- From samita.chakrabarti@ericsson.com Wed Jul 20 17:18:10 2011 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 9ED4F21F8AD6 for ; Wed, 20 Jul 2011 17:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.798 X-Spam-Level: X-Spam-Status: No, score=-6.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mPMqAVDJpgr for ; Wed, 20 Jul 2011 17:18:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id A6C7121F89C1 for ; Wed, 20 Jul 2011 17:18:06 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6L0I4lG000344; Wed, 20 Jul 2011 19:18:06 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.121]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 20 Jul 2011 20:17:58 -0400 From: Samita Chakrabarti To: "rute.sofia@ulusofona.pt" , "ipv6@ietf.org" Date: Wed, 20 Jul 2011 20:17:58 -0400 Subject: RE: Optimization of RFC 4861 for Energy-aware networks Thread-Topic: Optimization of RFC 4861 for Energy-aware networks Thread-Index: AcxHN/7aV6vtntXdRxuxCu7iKOqZ/gAADVTQ Message-ID: <16D60F43CA0B724F8052D7E9323565D71E672DDA1F@EUSAACMS0715.eamcs.ericsson.se> References: <16D60F43CA0B724F8052D7E9323565D71E6728BEFC@EUSAACMS0715.eamcs.ericsson.se> <4E2768E6.80808@ulusofona.pt> In-Reply-To: <4E2768E6.80808@ulusofona.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_16D60F43CA0B724F8052D7E9323565D71E672DDA1FEUSAACMS0715e_" 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, 21 Jul 2011 00:18:10 -0000 --_000_16D60F43CA0B724F8052D7E9323565D71E672DDA1FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rute, I will contribute, but do you have a specific deadline for us to send you c= omments? BR, Rute Sofia [[SC ] ] Thanks. If you provide comments in next few weeks, that will b= e good, I believe. -Samita On 07/19/2011 08:38 PM, Samita Chakrabarti wrote: Hello all: In 6lowpan workgroup, we developed draft-ietf-6lowpan-nd which provides op= timization of IPv6 ND for IEEE802.15.4 devices by avoiding all-node and sol= icited-node multicast messages for the most part and providing a method for= device registration with a IPv6 Border router in a route-over topology an= d as well as single-hop topology. In the last IOT workshop at IETF, it has been brought up that the 6lowpan-n= d like document may be useful in many other cases where devices are not IEE= E 802.15.4 devices but the nodes are basically energy-aware and like to sav= e energy as much as possible. 'Hello' or periodic advertisement/solicitati= on messages generally work well for line-powered devices, yet reducing the = periodic messages may be useful for less power consumption for each connect= ed device and therefore reducing overall energy consumption of the network.= Needless to say that the reduced number of messages and avoidance of perio= dic all-node or solicited-node multicast messages are critical for some low= -powered device operations. With EUI-64 IID, a DAD is not necessary if the = deployment may choose to do so. Here is an attempt to put together the first draft for generic optimization= for energy-aware IPv6 networks: http://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-nd-00 Comments are welcome. Would like the help from the community to shape this = document up for generic energy optimization for IPv6 ND in applicable case= s. This document also discusses a way of prefix dissemination for address a= uto-configuration which may be useful in future home network in a single pr= efix scenario. With the proliferation of internet-of-things, it might be he= lpful to do address auto-configuration in some isolated situations. More work is needed in this document - it is the initial effort to begin wi= th. Regards, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- Rute Sofia, PhD (rute.sofia@ulusofona.pt) Scientific Director for Technology Research Unit in Informatics Systems and Technologies (SITI) Coordinator of the Internet Architecture and Networking Lab (IAN Lab) University Lusofona, Portugal rute.sofia@ulusofona.pt http://siti.ulusofona.pt Tel.: 217 515 500 Fax: 21 757 7006 ....................................................... --_000_16D60F43CA0B724F8052D7E9323565D71E672DDA1FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rute,

I will contribute, but do you have a specific deadline for us to sen= d you=20 comments?

BR,
Rute Sofia
[[SC ] ]  Thanks.   = If you=20 provide comments in next few weeks, that will be good, I=20 believe.

-Samita 

On 07/19/2011 08:38 PM, Samit= a=20 Chakrabarti wrote:
Hello= =20 all:
 
In 6l= owpan=20 workgroup, we developed  draft-ietf-6lowpan-nd which provides=20 optimization of IPv6 ND for IEEE802.15.4 devices by avoiding all-node a= nd=20 solicited-node multicast messages for the most part and providing a met= hod=20 for device registration with a IPv6 Border router in a route-over=20 topology  and as well as single-hop topology.
 
In th= e last IOT=20 workshop at IETF, it has been brought up that the 6lowpan-nd like docum= ent=20 may be useful in many other cases where devices are not IEEE 802.15.4=20 devices but the nodes are basically energy-aware and like to save energ= y as=20 much as possible.  'Hello' or periodic advertisement/solicitation= =20 messages generally work well for line-powered devices, yet reducing the= =20 periodic messages may be useful for less power consumption for each=20 connected device and therefore reducing overall energy consumption of t= he=20 network. Needless to say that the reduced number of messages and avoida= nce=20 of periodic all-node or solicited-node multicast messages are critical = for=20 some low-powered device operations. With EUI-64 IID, a DAD is not neces= sary=20 if the deployment may choose to do so.
 
Here = is an=20 attempt to put together the first draft for generic optimization for=20 energy-aware IPv6 networks:
 
 
http://tools.ietf.org/html/draft-chakrabarti-n= ordmark-energy-aware-nd-00
 
Comme= nts are=20 welcome. Would like the help from the community to shape this document = up=20 for generic energy optimization for IPv6 ND  in applicable cases. = This=20 document also discusses a way of prefix dissemination for address=20 auto-configuration which may be useful in future home network in a sing= le=20 prefix scenario. With the proliferation of internet-of-things, it might= be=20 helpful to do address auto-configuration in some isolated=20 situations.
More = work is=20 needed in this document - it is the initial effort to begin=20 with.
 
Regards,
-Samita

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



--=20
Rute Sofia, PhD (rute.sofia@ulusofona.pt)
Scientific Director for Technology
Research Unit in Informatics Systems and Technologies (SITI)
Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
University Lusofona, Portugal
rute.sofia@ulusofona.pt

http://s=
iti.ulusofona.pt
Tel.: 217 515 500 Fax: 21 757 7006
.......................................................
--_000_16D60F43CA0B724F8052D7E9323565D71E672DDA1FEUSAACMS0715e_-- From brian.e.carpenter@gmail.com Wed Jul 20 18:12:20 2011 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 C7BAA21F8A80 for ; Wed, 20 Jul 2011 18:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.615 X-Spam-Level: X-Spam-Status: No, score=-103.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQI9UsMTCgJV for ; Wed, 20 Jul 2011 18:12:20 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 30EB421F8A7D for ; Wed, 20 Jul 2011 18:12:20 -0700 (PDT) Received: by qyk29 with SMTP id 29so567417qyk.10 for ; Wed, 20 Jul 2011 18:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TArJRou69XDK73VKFGfbkDTgEN/qBZawLa7hX99vN7c=; b=mkRvQ3nW9kweLeNMMyIifOMAJL1eLq3hAglEzQ9nHZSRn4Ev2SPA956mJZQAl5oYS9 UCy3SM2N07epsQthH/7gcXybsTWgKP4WGB9J9JkJcaIHIqKTAHVX6bClX/8Yu0MeHQ1U 9RbGR5f7zs9X89IvmUxes4aVtUussdepPtLPU= Received: by 10.224.208.195 with SMTP id gd3mr4085859qab.282.1311210738582; Wed, 20 Jul 2011 18:12:18 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id gx5sm4311213qab.15.2011.07.20.18.12.14 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 18:12:16 -0700 (PDT) Message-ID: <4E277CF2.7050706@gmail.com> Date: Thu, 21 Jul 2011 13:12:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: I-D Action: draft-chown-6man-tokenised-ipv6-identifiers-00.txt References: <20110704125354.9467.35310.idtracker@ietfa.amsl.com> In-Reply-To: <20110704125354.9467.35310.idtracker@ietfa.amsl.com> 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: Thu, 21 Jul 2011 01:12:20 -0000 Hi, In some ways I'd rather defer discussion of this draft until 6renum has clarified the requirements somewhat. However, two comments for now: 1. I don't find that this draft, admittedly preliminary, clearly defines what a tokenised IID is. If it just means a configured IID, why not say so? 2. I see a major security issue in that a malicious host could apparently give itself any IID that it wants - in the example in the draft, any host could declare itself to be the DNS server. There needs to be an anti-spoofing mechanism. Regards Brian Carpenter From narten@us.ibm.com Wed Jul 20 19:37:01 2011 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 6C64E21F8AF7 for ; Wed, 20 Jul 2011 19:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ39SkPhETbs for ; Wed, 20 Jul 2011 19:37:01 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id CDE1D21F86D6 for ; Wed, 20 Jul 2011 19:37:00 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p6L24RZs025650 for ; Wed, 20 Jul 2011 22:04:27 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p6L2ahXs095138 for ; Wed, 20 Jul 2011 22:36:43 -0400 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 p6KKag0q030621 for ; Wed, 20 Jul 2011 14:36:42 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-48-39-42.mts.ibm.com [9.48.39.42]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p6KKafE0030579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2011 14:36:41 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p6L2aeYK015174; Wed, 20 Jul 2011 22:36:40 -0400 Message-Id: <201107210236.p6L2aeYK015174@cichlid.raleigh.ibm.com> To: Jared Mauch Subject: Re: /64 ND DoS In-reply-to: <1E2E260F-B607-4AFB-BF82-2C48D0363BFE@puck.nether.net> References: <1E2E260F-B607-4AFB-BF82-2C48D0363BFE@puck.nether.net> Comments: In-reply-to Jared Mauch message dated "Wed, 13 Jul 2011 13:01:40 -0400." Date: Wed, 20 Jul 2011 22:36:40 -0400 From: Thomas Narten Cc: ipv6@ietf.org, Arturo Servin 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, 21 Jul 2011 02:37:01 -0000 playing catchup ... Jared Mauch writes: > To (re)state the biggest design issue with NDP again, it's outlined > in 7.3 of the v6nd-enhance draft: > -- snip -- > 7.3. NDP Protocol Gratuitous NA > Per RFC 4861, section 7.2.5 and 7.2.6 [RFC4861] requires that > unsolicited neighbor advertisements result in the receiver setting > it's neighbor cache entry to STALE, kicking off the resolution of the > neighbor using neighbor solicitation. > -- snip -- > Forcing an entry to STALE if you see an unsolicited NA (assuming it > matches the existing NA) seems unnecessary and counterproductive as > it can interrupt traffic to existing hosts. It shouldn't. A STALE entry is still usable, but it's a flag that says "verify that this entry is still correct, it may no longer be correct". You then wait a little while, and hope that TCP connections that are flowing through the specific entry get ACKs for the data they are sending, which in turn should get the state changed back to VALID. All without any additional ND traffic. Only if a node is sending traffic to a neighbor in a STALE state, and no TCP "forward progress" indications (i.e. ACKs) are updating the entry, then you send out a a (unicast) NS. Changing the above text in RFC cited above would significantly change the robustness of NUD. One would no longer detect failures where connectivity between neighbors is only unidirectional. I also do not understand how such a change would actually address the problem described in draft-gashinsky-v6nd-enhance-00.txt. Thomas From pch-b2B3A6689@u-1.phicoh.com Wed Jul 20 23:31:08 2011 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 546C821F84E6 for ; Wed, 20 Jul 2011 23:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QGNCb-1H4qX for ; Wed, 20 Jul 2011 23:31:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9A80511E8077 for ; Wed, 20 Jul 2011 23:31:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qjmmi-0001ibC; Thu, 21 Jul 2011 08:31:00 +0200 Message-Id: To: RJ Atkinson Subject: Re: PMTUD and MTU < 1280 From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Wed, 20 Jul 2011 17:35:31 -0400 ." <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> Date: Thu, 21 Jul 2011 08:30:51 +0200 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, 21 Jul 2011 06:31:08 -0000 In your letter dated Wed, 20 Jul 2011 17:35:31 -0400 you wrote: >I am not sure the specs insist that an IPv6 implementation >must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes >as "unrecoverable". (I haven't re-read the IPv6 specs recently.) Some services, like big DNS server cannot afford to do PMTU. It requires them to store the original DNS reply just in case an ICMP comes back. Without that, the host will see that its first request fails and has to retry. Over time, this will happen again and again because big servers cannot maintain all PMTU state forever. >It is very unfortunate that IPv6 specifies this very large minimum MTU size >(i.e. 1280 bytes), because it is impeding the ability of various organisations > >to deploy IPv6 on a number of existing links that already support IPv4. The root cause of this are routers that don't do fragmentation. Any lower minimum MTU would force any host that cannot maintain PMTU state to fragment in small sizes, which is bad for the 99% of the world that has MTUs bigger than 1280. I'd say that for any link that is mostly reliable, adding a fragmentation layer should not cost more than 16 bits. There are even the payload length, flow label and traffic class fields ready to be abused if need be. So it can we without any increase in length. >IPv4 can run over nearly any link without protocol changes or requiring >special case handling. Sadly, IPv6 cannot make the same claim. One hopes >IPv6 implementers will be tolerant of IPv6 MTUs below 1280 bytes, because >they do exist in the deployed world and aren't going away anytime soon. I don't think that silently doing something that goes against the standard is a good thing. From marka@isc.org Thu Jul 21 00:13:08 2011 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 63A1D21F85EA for ; Thu, 21 Jul 2011 00:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRmRor1EJZzh for ; Thu, 21 Jul 2011 00:13:05 -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 8719621F8B58 for ; Thu, 21 Jul 2011 00:13:05 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id A09B1C9484; Thu, 21 Jul 2011 07:12:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (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 12AEE216C7B; Thu, 21 Jul 2011 07:12:52 +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 0BF22120CFF1; Thu, 21 Jul 2011 17:12:48 +1000 (EST) To: Philip Homburg From: Mark Andrews References: Subject: Re: PMTUD and MTU < 1280 In-reply-to: Your message of "Thu, 21 Jul 2011 08:30:51 +0200." Date: Thu, 21 Jul 2011 17:12:48 +1000 Message-Id: <20110721071248.0BF22120CFF1@drugs.dv.isc.org> Cc: ipv6@ietf.org, RJ Atkinson 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, 21 Jul 2011 07:13:08 -0000 In message , Philip Homburg writes: > In your letter dated Wed, 20 Jul 2011 17:35:31 -0400 you wrote: > >I am not sure the specs insist that an IPv6 implementation > >must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes > >as "unrecoverable". (I haven't re-read the IPv6 specs recently.) > > Some services, like big DNS server cannot afford to do PMTU. It requires them > to store the original DNS reply just in case an ICMP comes back. This was originally noted in draft-ietf-ipngwg-bsd-frag-00 (January 1998) and became IPV6_USE_MIN_MTU (RFC 3542, May 2003). Now if we can just get it into POSIX .... And, yes, nameservers do set this option. FreeBSD's implementation however is partially broken. See: http://www.freebsd.org/cgi/query-pr.cgi?pr=158307. > Without that, the host will see that its first request fails and has to retry > . > Over time, this will happen again and again because big servers cannot > maintain all PMTU state forever. It takes multiple requests usually and yes the state does get lost within minutes on busy nameservers. What should have been specified is that hosts need to fragment packets into roughly equal sizes fragments. This reduces the probabilty of having to deal with multiple PTB packets. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nalini.elkins@insidethestack.com Thu Jul 21 21:37:43 2011 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 5488421F8786 for ; Thu, 21 Jul 2011 21:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=1.404, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIr5YGj54bjM for ; Thu, 21 Jul 2011 21:37:41 -0700 (PDT) Received: from nm22.access.bullet.mail.sp2.yahoo.com (nm22.access.bullet.mail.sp2.yahoo.com [98.139.44.149]) by ietfa.amsl.com (Postfix) with SMTP id DB23221F8782 for ; Thu, 21 Jul 2011 21:37:41 -0700 (PDT) Received: from [98.139.44.102] by nm22.access.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 04:37:39 -0000 Received: from [98.139.44.75] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 04:37:39 -0000 Received: from [127.0.0.1] by omp1012.access.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 04:37:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 351396.64819.bm@omp1012.access.mail.sp2.yahoo.com Received: (qmail 91773 invoked by uid 60001); 22 Jul 2011 04:37:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311309459; bh=Xm1JzLZRIxcU7qDa9aW4OUegxHIwks3Bg3KrOnwuz04=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=2MxKSbmgMqn+VNo/MWkdv8x95B1Z5C3IH4sV4ef0LBna4PI0NZmqRpZSGCEoV3gEgVr/MT5kyTqxR3vh0VvRXZfMTijbjH5GI6pelhSmh0/HwO33fWdd3L2WlDPXx5zng62OKi5VQFYRUzT/yACEKK70dJLo7PrZfMEnb4AnT2U= X-YMail-OSG: DNn24yAVM1nEUSBOwO7YsC9YYLvMAj_NXfx9lD5R_rQ0J51 RQ2DuRd.9ucEP.I5VEbNYuGjimL1iYlFDbAvo5fG0.TX.Vck402Nu3u4_qdK M1afIMYlVryFoASeBHmSoSx7fCyLT1_KOkZujmwJztRNi.H1Pu_LsEaEAZX. v6pmkOxmR3wITxvqgNpvn4Vwt0TyydE7n2DHFeAWl_Ox93YRWXagdv8oEbkN WQx2fqWzpd8AhFemSiOWX_Bh_3B1dDftIgYza0IAAufaOvOJOaZH5TvkHQXf rbV3a4fsVTcAvx703crbraLyStmLC7e7zoKJe1gcwHGEuYORL3ph1b4n2EHf S9PSA42tWDGynloeC.6eN5mS4WJbqKJpoENIB7uqSK75pnDDIrMEpAJRtf.J _zTf1L1Mkvc0wkvirzufBFivSZNYP7kvFzMMXxmz.IB9NatuvVrCHVe9uSZe l Received: from [24.6.68.48] by web2804.biz.mail.ne1.yahoo.com via HTTP; Thu, 21 Jul 2011 21:37:38 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311309458.77451.YahooMailClassic@web2804.biz.mail.ne1.yahoo.com> Date: Thu, 21 Jul 2011 21:37:38 -0700 (PDT) From: nalini.elkins@insidethestack.com Subject: IPv6 Diagnostic Option To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1419993237-1311309458=:77451" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 04:37:43 -0000 --0-1419993237-1311309458=:77451 Content-Type: text/plain; charset=us-ascii Hello Folks, Would love to get feedback on an Internet Draft we have submitted. The issue we are addressing is that the IP Identification field which was available with IPv4 in the main header is available with IPv6 only in the Fragment Header. Please see: http://tools.ietf.org/id/draft-elkins-6man-ipv6-diagnostic-header-00.txt We do have a revision (version 01) which is attached. The submission system is closed so we will update it formally when it reopens on July 25th. Thanks! Nalini Elkins Inside Products, Inc. (831) 659-8360 --0-1419993237-1311309458=:77451 Content-Type: text/plain; name="draft-elkins-6man-ipv6-diagnostic-header-01.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-elkins-6man-ipv6-diagnostic-header-01.txt" DQo2bWFuIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBOLiBFbGtpbnMNCkludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElu c2lkZSBQcm9kdWN0cw0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgdHJh Y2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBLcmF0emtlDQpF eHBpcmVzOiBKYW51YXJ5LCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJQk0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0u IEFja2VybWFubg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBCQ0JTIG9mIE1pY2hpZ2FuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBKdWx5IDIwMTENCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJUHY2IERpYWdub3N0aWMgT3B0aW9uDQogICAgICAgICAg ICAgICAgICAgZHJhZnQtZWxraW5zLTZtYW4taXB2Ni1kaWFnbm9zdGljLWhl YWRlci0wMS50eHQNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQpUaGlzIElu dGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNl IHdpdGggdGhlIHByb3Zpc2lvbnMNCm9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0K DQpJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrDQpGb3JjZSAoSUVURiksIGl0 cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0IG90 aGVyIGdyb3Vwcw0KbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCkludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocyANCmFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9i c29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IA0KdGltZS4gSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJl ZmVyZW5jZSBtYXRlcmlhbA0Kb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQpUaGUgbGlzdCBvZiBjdXJyZW50 IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dA0KDQpUaGUgbGlz dCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJl IGFjY2Vzc2VkIGF0DQpodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s DQoNClRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSmFudWFy eSA0LCAyMDEyLg0KDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KQ29weXJpZ2h0 IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlIGRvY3VtZW50DQphdXRob3JzLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLg0KDQpUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu ZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsIFByb3Zpc2lvbnMNClJlbGF0aW5n IHRvIElFVEYgRG9jdW1lbnRzIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIA0KZWZmZWN0IG9uIHRoZSBkYXRlIG9mIHB1Ymxp Y2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2Ug DQpkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCANCnJlc3BlY3QgdG8gdGhp cyBkb2N1bWVudC4NCg0KQWJzdHJhY3QNCg0KVGhlIElQdjQgbWFpbiBoZWFk ZXIgY29udGFpbmVkIGEgMTYtYml0IElQIElkZW50aWZpY2F0aW9uIChJUElE KSBmaWVsZA0KdG8gYmUgdXNlZCBmb3IgZnJhZ21lbnRhdGlvbiBhbmQgcmVh c3NlbWJseS4gIEluIHByYWN0aWNlLCB0aGlzIGZpZWxkIA0Kd2FzIGNvbW1v bmx5IHVzZWQgYnkgbmV0d29yayBkaWFnbm9zdGljaWFucyBmb3IgdHJhY2tp bmcgcGFja2V0cy4gSW4gDQpJUHY2LCB0aGUgSVBJRCBoYXMgYmVlbiBtb3Zl ZCB0byB0aGUgRnJhZ21lbnQgaGVhZGVyLiAgQSBuZXcgRGlhZ25vc3RpYw0K T3B0aW9uIGZvciBJUHY2IHdoaWNoIGNhbiBiZSBzZW50IHdpdGggZXZlcnkg cGFja2V0IGFzIGEgcGFydCBvZiB0aGUgDQpEZXN0aW5hdGlvbiBPcHRpb25z IEhlYWRlciB3aXRoIGEgNjQtYml0IElQSUQgaXMgZGVmaW5lZCBpbiB0aGlz IA0KZG9jdW1lbnQuDQoNCkVsa2lucyAgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA0LCAyMDEyICAgICAgICAgICBbUGFnZSAwMV0NCg0K DA0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIElQdjYgRGlh Z25vc3RpYyBPcHRpb24gICAgICAgSnVseSAyMDExDQoNClRhYmxlIG9mIENv bnRlbnRzDQoNCjEuIEludHJvZHVjdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAyDQoyLiBDb252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4gMw0KMy4gQXBwbGljYWJpbGl0eSAgLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u IDMNCjQuIElQdjYgRGlhZ25vc3RpY3MgSGVhZGVyIEZvcm1hdCAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzDQogICA0LjEuIERlc3Rp bmF0aW9uIE9wdGlvbnMgSGVhZGVyIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4gNA0KICAgNC4yLiBEaWFnbm9zdGljIE9wdGlvbiAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDUNCiAg IDQuMy4gSW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiA2DQo1LiBCYWNrd2FyZCBDb21wYXRp YmlsaXR5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4gNg0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDYNCjcuIElBTkEg Q29uc2lkZXJhdGlvbnMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLiA2DQoxMC4gUmVmZXJlbmNlcyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4g NiANCiAgICAxMC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiA3IA0KICAgIDEwLjIuIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uIDcNCjExLiBBY2tub3dsZWRnbWVudHMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiA4DQoN Cg0KMS4gSW50cm9kdWN0aW9uDQoNCkluIElQdjQsIHRoZSAxNiBiaXQgSVAg SWRlbnRpZmljYXRpb24gKElQSUQpIGZpZWxkIGlzIGxvY2F0ZWQgYXQgYW4g DQpvZmZzZXQgb2YgNCBieXRlcyBpbnRvIHRoZSBJUHY0IGhlYWRlciBhbmQg aXMgZGVzY3JpYmVkIGluIFJGQzc5MSANCltSRkM3OTFdLiBJbiBJUHY2LCBp dCBpcyBhIDMyIGJpdCBmaWVsZCBjb250YWluZWQgaW4gdGhlIEZyYWdtZW50 IEhlYWRlcg0KZGVmaW5lZCBieSBzZWN0aW9uIDQuNSBvZiBSRkMyNDYwIFtS RkMyNDYwXS4gVW5mb3J0dW5hdGVseSwgdW5sZXNzIA0KZnJhZ21lbnRhdGlv biBpcyBiZWluZyBkb25lIGJ5IHRoZSBzb3VyY2Ugbm9kZSwgdGhlIHBhY2tl dCB3aWxsIG5vdA0KY29udGFpbiB0aGlzIEZyYWdtZW50IEhlYWRlciwgYW5k IHRoZXJlZm9yZSB3aWxsIGhhdmUgbm8gSWRlbnRpZmljYXRpb24NCmZpZWxk Lg0KDQpUaGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSVBJRCBmaWVsZCBp cyB0byBlbmFibGUgZnJhZ21lbnRhdGlvbiBhbmQNCnJlYXNzZW1ibHksIGFu ZCBhcyBjdXJyZW50bHkgc3BlY2lmaWVkIGlzIHJlcXVpcmVkIHRvIGJlIHVu aXF1ZSB3aXRoaW4NCnRoZSBtYXhpbXVtIHNlZ21lbnQgbGlmZXRpbWUgKE1T TCkgb24gYWxsIGRhdGFncmFtcy4gVGhlIE1TTCBpcyBvZnRlbiAyDQptaW51 dGVzLg0KDQpJbiBwcmFjdGljZSwgdGhlIElQSUQgZmllbGQgaXMgdXNlZCBm b3IgbW9yZSB0aGFuIGZyYWdtZW50YXRpb24uDQpEdXJpbmcgbmV0d29yayBk aWFnbm9zdGljcywgcGFja2V0IHRyYWNlcyBtYXkgYmUgdGFrZW4gYXQgbXVs dGlwbGUgDQpwbGFjZXMgYWxvbmcgdGhlIHBhdGggb3IgYXQgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24uIFRoZW4sIHBhY2tldHMgDQpjYW4gYmUgbWF0 Y2hlZCBieSBsb29raW5nIGF0IHRoZSBJUElELiBPYnZpb3VzbHksIHRoZSB0 aW1lIGF0IGVhY2ggDQpkZXZpY2Ugd2lsbCBkaWZmZXIgYWNjb3JkaW5nIHRv IHRoZSBjbG9jayBvbiB0aGF0IGRldmljZTsgc28gYW5vdGhlciANCm1ldHJp YyBpcyByZXF1aXJlZC4gVGhpcyBtZXRob2Qgb2YgdGFraW5nIG11bHRpcGxl IHRyYWNlcyBhbG9uZyB0aGUgcGF0aA0KaXMgb2Ygc3BlY2lhbCB1c2Ugb24g bGFyZ2UgbXVsdGktdGllciBuZXR3b3JrcyB0byBzZWUgd2hlcmUgdGhlIHBh Y2tldA0KbG9zcyBvciBwYWNrZXQgY29ycnVwdGlvbiBpcyBoYXBwZW5pbmcu ICBNdWx0aS10aWVyIG5ldHdvcmtzIGFyZSB0aG9zZSANCndoaWNoIGhhdmUg bXVsdGlwbGUgcm91dGVycyBvciBzd2l0Y2hlcyBvbiB0aGUgcGF0aCBiZXR3 ZWVuIHRoZSBzZW5kZXINCmFuZCB0aGUgcmVjZWl2ZXIuDQoNClRoZSBpbmNs dXNpb24gb2YgdGhpcyBvcHRpb24gbWFrZXMgaXQgZWFzaWVyIGZvciBhIGRl dmljZSBpbiB0aGUgbWlkZGxlDQpvZiB0aGUgbmV0d29yayBvciBvbiB0aGUg cmVjZWl2aW5nIGVuZCBvZiB0aGUgbmV0d29yayB0byBpZGVudGlmeSBmbG93 cyANCmJlbG9uZ2luZyB0byBhIHNpbmdsZSBub2RlLCBldmVuIGlmIHRoYXQg bm9kZSBtaWdodCBoYXZlIGEgZGlmZmVyZW50IElQDQphZGRyZXNzLiBGb3Ig ZXhhbXBsZSwgaWYgdGhlIHNlbmRpbmcgbm9kZSBpcyBhIG1vYmlsZSBsYXB0 b3Agd2l0aCBhIA0Kd2lyZWxlc3MgY29ubmVjdGlvbiB0byB0aGUgSW50ZXJu ZXQuICANCg0KRWxraW5zICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDQsIDIwMTIgICAgICAgICAgIFtQYWdlIDAyXQ0KDQoMDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgSVB2NiBEaWFnbm9zdGlj IE9wdGlvbiAgICAgICBKdWx5IDIwMTENCg0KDQpIYXZpbmcgc2FpZCB0aGF0 LCBhIGtub3duIHByb2JsZW0gd2l0aCB0aGUgdW5pcXVlbmVzcyBvZiB0aGUg SVB2NCBJRCBpcyANCnRoYXQgc2luY2UgdGhlIGZpZWxkIGlzIG9ubHkgMTYg Yml0cywgdGhlbiBmb3IgaGlnaCBzcGVlZCBkZXZpY2VzLCANCndyYXBwaW5n IHdpbGwgb2NjdXIuIEFzIGRpc2N1c3NlZCBpbiBSRkM0OTYzIFtSRkM0OTYz XSBhbmQgDQpkcmFmdC1pZXRmLWludGFyZWEtaXB2NC1pZC11cGRhdGUtMDIu dHh0IFtEcmFmdC1pcHY0LWlkXSwgaWYgdGhlIA0KdW5pcXVlbmVzcyByZXF1 aXJlbWVudCB3ZXJlIHN0cmljdGx5IGVuZm9yY2VkLCBhbGwgY29ubmVjdGlv bnMgd291bGQgYmUgDQpsaW1pdGVkIHRvIGEgbWF4aW11bSBzcGVlZCBvZiA2 LjQgTWJwcy4gQ2xlYXJseSwgdGhpcyB1bmlxdWVuZXNzIA0KcmVxdWlyZW1l bnQgaXMgd2lkZWx5IGlnbm9yZWQuDQoNCkluIGZhY3QsIHRoZSBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgSVBJRCBmaWVsZCB2YXJpZXMuICBTb21lIA0KaW1w bGVtZW50YXRpb25zIGhhdmUgdGhlIHNhbWUgSVBJRCBjb3VudGVyIGZvciBh bGwgY29ubmVjdGlvbnM7IHNvbWUgDQpoYXZlIGFuIElQSUQgY291bnRlciBv biBhIHBlciBjb25uZWN0aW9uIGJhc2lzLiAgU29tZSBpbXBsZW1lbnRhdGlv bnMNCmluY3JlbWVudCB0aGUgSVBJRCBieSBvbmUgZWFjaCB0aW1lIGEgcGFj a2V0IGlzIHNlbnQgb3V0OyBzb21lDQppbmNyZW1lbnQgYnkgdHdvLiAgDQoN CkluIElQdjYsIHRoZSBJUElEIGZpZWxkLCB3aGljaCBpcyBpbiB0aGUgRnJh Z21lbnQgSGVhZGVyLCBoYXMgYmVlbiANCmluY3JlYXNlZCB0byAzMiBiaXRz LiBUaGlzIG1heSBuZWVkIHRvIGJlIHJlY29uc2lkZXJlZCBhcyBkYXRhIHJh dGVzIA0KaW5jcmVhc2UgYnV0IGlmIHRoZSBJUElEIGlzIHVzZWQgZm9yIGZy YWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHkgDQphbG9uZSwgdGhlIHJlcXVp cmVtZW50IGZvciB1bmlxdWVuZXNzIHdpdGhpbiB0aGUgTVNMIHBlcmlvZCBp cyANCmdlbmVyYWxseSBub3QgYW4gaXNzdWUgdG9kYXkuIFJGQzQ5NjMgW1JG QzQ5NjNdIGRpc2N1c3NlcyB0aGUgaXNzdWUgb2YgDQpyZWFzc2VtYmx5IGVy cm9ycyBhdCBoaWdoIGRhdGEgcmF0ZXMgZm9yIElQdjQgd2l0aCBhIDE2LWJp dCBjb3VudGVyLg0KDQpIb3dldmVyLCBmb3IgaXRzIGRlLWZhY3RvIGRpYWdu b3N0aWMgbW9kZSB1c2FnZSwgYW4gSVBJRCBuZWVkcyB0byBiZSANCmF2YWls YWJsZSB3aGV0aGVyIG9yIG5vdCBmcmFnbWVudGF0aW9uIG9jY3VycywgYW5k IG5lZWRzIHRvIGJlIHVuaXF1ZQ0KaW4gdGhlIGNvbnRleHQgb2YgdGhlIGVu dGlyZSBzZXNzaW9uLCBhbmQgYWNyb3NzIGFsbCB0aGUgY29ubmVjdGlvbnMN CmNvbnRyb2xsZWQgYnkgdGhlIHN0YWNrLiBUaGUgcHJvYmxlbSBvZiAzMiBi aXQgY291bnRlcnMgaXMga25vd24NCmFuZCBoYXMgYmVlbiByZXNvbHZlZCBp biBhcmVhcyBzdWNoIGFzIFNOTVAgY291bnRlcnMgYnkgY3JlYXRpbmcgDQo2 NC1iaXQgY291bnRlcnMgYXMgZGVzY3JpYmVkIGluIFJGQzI4NjMgW1JGQzI4 NjNdLg0KDQpUaGlzIGRvY3VtZW50IHdpbGwgYWRkcmVzcyBhIHdheSB0byBt YWtlIHRoZSBJUHY2IElQSUQgZmllbGQgYXZhaWxhYmxlIA0KYW5kIHVuaXF1 ZSBmb3IgaXRzIHZhbHVhYmxlIGRpYWdub3N0aWMgdXNhZ2UuIEEgRGlhZ25v c3RpYyBPcHRpb24gd2hpY2gNCmlzIGFuIGltcGxlbWVudGF0aW9uIG9mIHRo ZSBEZXN0aW5hdGlvbiBPcHRpb25zIEhlYWRlciBpcyBwcm9wb3NlZA0Kd2hp Y2ggbWF5IGJlIHNlbnQgYnkgc3RhY2tzIGluIGRpYWdub3N0aWMgbW9kZS4g VGhlIGltcGxlbWVudGF0aW9uDQpNQVkgcHJvdmlkZSB0aGUgb3B0aW9uIG9m IGVpdGhlciB0dXJuaW5nIG9uIHRoZSBEaWFnbm9zdGljIE9wdGlvbiBmb3IN CmFsbCBjb25uZWN0aW9ucyBvciB0dXJuIGl0IG9uIGp1c3QgZm9yIHNwZWNp ZmljIGNvbm5lY3Rpb25zLiAgVGhlIG1vcmUNCnNvcGhpc3RpY2F0ZWQgdXNh Z2Ugb2YgdGhpcyBvcHRpb24gd291bGQgYmUgdG8gc2VuZCBpdCBmb3IgYSBz aW5nbGUNCmNvbm5lY3Rpb24gb25seS4NCg0KDQoyLiBDb252ZW50aW9ucyB1 c2VkIGluIHRoaXMgZG9jdW1lbnQNCg0KVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1Qi LCANCiJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJN QVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KZG9jdW1lbnQgYXJlIHRv IGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMyMTE5IFtSRkMy MTE5XS4NCg0KRWxraW5zICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDQsIDIwMTIgICAgICAgICAgIFtQYWdlIDAzXQ0KDQoMDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgSVB2NiBEaWFnbm9zdGlj IE9wdGlvbiAgICAgICBKdWx5IDIwMTENCg0KDQozLiAgQXBwbGljYWJpbGl0 eQ0KDQpUaGUgYmFzZSBJUHY2IHN0YW5kYXJkLCBSRkMyNDYwLCBbUkZDMjQ2 MF0gYWxsb3dzIHRoZSB1c2Ugb2YgDQpleHRlbnNpb24gaGVhZGVycyBzdWNo IGFzIHRoZSBEZXN0aW5hdGlvbiBPcHRpb25zIEhlYWRlciBpbiBvcmRlcg0K dG8gZW5jb2RlIG9wdGlvbmFsIGRlc3RpbmF0aW9uIGluZm9ybWF0aW9uIGlu IGFuIElQdjYgcGFja2V0LiANCkV4dGVuZGVkIGRpYWdub3N0aWMgaW5mb3Jt YXRpb24gc3VjaCBhcyB0aGlzIE1VU1QgYmUgc2VudCBieSANCmltcGxlbWVu dGF0aW9ucyB1cG9uIHJlcXVlc3QuIFRoZSBwcm9wb3NlZCBEaWFnbm9zdGlj IE9wdGlvbiBpcyBhbiANCmltcGxlbWVudGF0aW9uIG9mIHRoZSBEZXN0aW5h dGlvbiBPcHRpb25zIEhlYWRlci4NCg0KDQo0LiAgSVB2NiBEaWFnbm9zdGlj IE9wdGlvbiBGb3JtYXQNCg0KNC4xICBEZXN0aW5hdGlvbiBPcHRpb25zIEhl YWRlcg0KDQpUaGUgRGVzdGluYXRpb24gT3B0aW9ucyBIZWFkZXIgaXMgdXNl ZCB0byBjYXJyeSBvcHRpb25hbCBpbmZvcm1hdGlvbg0KdGhhdCBuZWVkIGJl IGV4YW1pbmVkIG9ubHkgYnkgYSBwYWNrZXQncyBkZXN0aW5hdGlvbiBub2Rl KHMpLiBUaGUgDQpEZXN0aW5hdGlvbiBPcHRpb25zIEhlYWRlciBpcyBpZGVu dGlmaWVkIGJ5IGEgTmV4dCBIZWFkZXIgdmFsdWUgb2YgNjANCmluIHRoZSBp bW1lZGlhdGVseSBwcmVjZWRpbmcgaGVhZGVyIGFuZCBpcyBkZWZpbmVkIGlu IFJGQzI0NjAgW1JGQzI0NjBdLg0KDQoNCjQuMi4gIElQdjYgRGlhZ25vc3Rp YyBPcHRpb24gDQoNClRoZSBJUHY2IERpYWdub3N0aWMgT3B0aW9uIGlzIGFu IGltcGxlbWVudGF0aW9uIG9mIHRoZSBEZXN0aW5hdGlvbg0KT3B0aW9ucyBI ZWFkZXIgKE5leHQgSGVhZGVyIHZhbHVlID0gNjApLiBJdCBpcyB1c2VkIGlu IGEgcGFja2V0IHNlbnQNCmJ5IGEgbm9kZSB0byBmYWNpbGl0YXRlIGRpYWdu b3N0aWNzIGJ5IGluZm9ybWluZyB0aGUgcmVjaXBpZW50IGFuZA0KcGFzc2l2 ZSB2aWV3ZXJzIG9mIHRoZSBwYWNrZXQgc3VjaCBhcyBwYWNrZXQgY2FwdHVy ZSBmYWNpbGl0aWVzIG9mIA0KdGhlIHBhY2tldCdzIElQIElkZW50aWZpZXIu IA0KDQpUaGUgSVB2NiBEaWFnbm9zdGljIE9wdGlvbiBpcyBlbmNvZGVkIGlu IHR5cGUtbGVuZ3RoLXZhbHVlIChUTFYpIA0KZm9ybWF0IGFzIGZvbGxvd3M6 DQoNCg0KMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg IDIgICAgICAgICAgICAgICAgICAgMw0KMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQor LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgIE9wdGlvbiBU eXBlICB8IE9wdGlvbiBMZW5ndGggfA0KKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0K fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgICAgICAgICAgICAg ICAgSVAgSWRlbnRpZmllciAgICAgICAgICAgICAgICAgICAgICAgICArDQp8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCnwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpF bGtpbnMgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNCwg MjAxMiAgICAgICAgICAgW1BhZ2UgMDRdDQoNCgwNCg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBJUHY2IERpYWdub3N0aWMgT3B0aW9uICAg ICAgIEp1bHkgMjAxMQ0KDQoNCk9wdGlvbiBUeXBlDQoNClRCRCA9IDB4WFgg KFRCRCkgIFtUbyBiZSBhc3NpZ25lZCBieSBJQU5BXSBbUkZDMjc4MF0NCg0K DQpPcHRpb24gTGVuZ3RoDQoNCjgtYml0IHVuc2lnbmVkIGludGVnZXIuIExl bmd0aCBvZiB0aGUgb3B0aW9uLCBpbiBvY3RldHMsIGV4Y2x1ZGluZyB0aGUN Ck9wdGlvbiBUeXBlIGFuZCBPcHRpb24gTGVuZ3RoIGZpZWxkcy4gVGhpcyBm aWVsZCBNVVNUIGJlIHNldCB0byA2NC4NCg0KDQpJUCBJZGVudGlmaWVyDQoN ClRoZSBJUCBJZGVudGlmaWVyIG9mIHRoZSBwYWNrZXQgZm9yIDY0IGJpdHMu DQoNClRoZSBhbGlnbm1lbnQgcmVxdWlyZW1lbnQgZm9yIHRoZSBJUCBJZGVu dGlmaWVyIG9wdGlvbiBpcyA4bis2Lg0KDQpUaGUgdHdvIGhpZ2hlc3Qtb3Jk ZXIgYml0cyBvZiB0aGUgT3B0aW9uIFR5cGUgZmllbGQgYXJlIGVuY29kZWQg dG8gDQppbmRpY2F0ZSBzcGVjaWZpYyBwcm9jZXNzaW5nIG9mIHRoZSBvcHRp b247IGZvciB0aGUgSVAgSWRlbnRpZmllcg0Kb3B0aW9uLCB0aGVzZSB0d28g Yml0cyBNVVNUIGJlIHNldCB0byAwMC4gVGhpcyBpbmRpY2F0ZXMgdGhlIGZv bGxvd2luZw0KcHJvY2Vzc2luZyByZXF1aXJlbWVudHM6DQoNCiAgIG8gIDAw IC0gc2tpcCBvdmVyIHRoaXMgb3B0aW9uIGFuZCBjb250aW51ZSBwcm9jZXNz aW5nIHRoZSBoZWFkZXIuDQogICANCiAgIG8gIFRoZSBkYXRhIHdpdGhpbiB0 aGUgb3B0aW9uIGNhbm5vdCBjaGFuZ2UgZW4gcm91dGUgdG8gdGhlIHBhY2tl dCdzDQogICAgICBmaW5hbCBkZXN0aW5hdGlvbi4NCgkgIA0KICAgICAgVGhl IElQdjYgRGlhZ25vc3RpYyBPcHRpb24gTVVTVCBiZSBwbGFjZWQgYXMgZm9s bG93czoNCgkgIA0KICAgbyAgQWZ0ZXIgdGhlIFJvdXRpbmcgSGVhZGVyLCBp ZiB0aGF0IGhlYWRlciBpcyBwcmVzZW50DQogICANCiAgIG8gIEJlZm9yZSB0 aGUgRnJhZ21lbnQgSGVhZGVyLCBpZiB0aGF0IGhlYWRlciBpcyBwcmVzZW50 DQoNCiAgIG8gIEJlZm9yZSB0aGUgQUggSGVhZGVyIG9yIEVTUCBIZWFkZXIs IGlmIGVpdGhlciBvbmUgb2YgdGhvc2UgDQogICAgICBoZWFkZXJzIGFyZSBw cmVzZW50Lg0KDQpGb3IgZWFjaCBJUHY2IHBhY2tldCBoZWFkZXIsIHRoZSBJ UHY2IERpYWdub3N0aWMgT3B0aW9uIE1VU1QgTk9UIGFwcGVhcg0KbW9yZSB0 aGFuIG9uY2UuIEhvd2V2ZXIsIGFuIGVuY2Fwc3VsYXRlZCBwYWNrZXQgTUFZ IGNvbnRhaW4gYSBzZXBhcmF0ZQ0KSVB2NiBEaWFnbm9zdGljIE9wdGlvbiBh c3NvY2lhdGVkIHdpdGggZWFjaCBlbmNhcHN1bGF0aW5nIElQIGhlYWRlci4N Cg0KVGhlIGluY2x1c2lvbiBvZiBhIElQdjYgRGlhZ25vc3RpYyBPcHRpb24g aW4gYSBwYWNrZXQgYWZmZWN0cyB0aGUgDQpyZWNlaXZpbmcgbm9kZSdzIHBy b2Nlc3Npbmcgb2Ygb25seSB0aGlzIHNpbmdsZSBwYWNrZXQuIE5vIHN0YXRl IGlzIA0KY3JlYXRlZCBvciBtb2RpZmllZCBpbiB0aGUgcmVjZWl2aW5nIG5v ZGUgYXMgYSByZXN1bHQgb2YgcmVjZWl2aW5nIGEgDQpJUHY2IERpYWdub3N0 aWMgT3B0aW9uIGluIGEgcGFja2V0Lg0KDQpFbGtpbnMgICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEphbnVhcnkgNCwgMjAxMiAgICAgICAgICAgW1Bh Z2UgMDVdDQoNCgwNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICBJUHY2IERpYWdub3N0aWMgT3B0aW9uICAgICAgIEp1bHkgMjAxMQ0KDQoN CjQuMy4gIEltcGxlbWVudGF0aW9uIENvbnNpZGVyYXRpb25zDQoNCkluIGlt cGxlbWVudGF0aW9uLCBhbiBpbXBsZW1lbnRpbmcgc3RhY2sgbWF5IHNlbmQg dGhpcyBhZGRpdGlvbmFsIGhlYWRlcg0KZm9yIGFsbCBjb25uZWN0aW9ucywg cGVyIGhpZ2hlciBsZXZlbCBwcm90b2NvbCBvciBpbiBhIG1vcmUgDQpzb3Bo aXN0aWNhdGVkIHVzYWdlLCBmb3IgYSBzaW5nbGUgY29ubmVjdGlvbiBvciBm bG93IG9ubHkuDQoNClRoZSBpbml0aWF0aW9uIG9mIHRoaXMgaGVhZGVyIE1V U1QgYmUgZG9uZSB2aWEgYSAnRGVidWcgb24nLydEZWJ1ZyBvZmYnIA0Kc3dp dGNoLiBUaGF0IGlzLCBhIGRpYWdub3N0aWNpYW4gbWF5IGRlY2lkZSB0aGF0 IHRoaXMgaGVhZGVyIGlzIHJlcXVpcmVkDQpmb3IgYSBjZXJ0YWluIHRpbWVm cmFtZSBvciBmb3IgYSBjZXJ0YWluIHNldCBvZiBwYWNrZXRzIGFmdGVyIGEg bmV0d29yaw0KcHJvYmxlbSBpcyBlbmNvdW50ZXJlZC4gVGhlIGRpYWdub3N0 aWNpYW4gbWF5IHRoZW4gaXNzdWUgYSBjb21tYW5kIHRvIA0KdGhlIHN0YWNr IGluZGljYXRpbmcgdGhhdCBhZGRpdGlvbiBvZiB0aGUgSVAgSWRlbnRpZmll ciBoZWFkZXIgc2hvdWxkIA0Kbm93IGJlZ2luLiBUaGlzIGlzIHRoZSAnRGVi dWcgb24nIHN0YXRlLiBBZnRlciBhIGNlcnRhaW4gYW1vdW50IG9mIHRpbWUs DQp0aGVuICdEZWJ1ZyBvZmYnIHNob3VsZCBiZSBpc3N1ZWQgYXMgYSBjb21t YW5kLiAgQWx0ZXJuYXRpdmVseSwgdGhlIA0Kc3RhY2sgbWF5IGhhdmUgYSBm aXhlZCB0aW1lIChmb3IgZXhhbXBsZSwgNSBtaW51dGVzKSBhZnRlciB3aGlj aCBkZWJ1ZyANCm1vZGUgd2lsbCBhdXRvbWF0aWNhbGx5IGJlIHR1cm5lZCBv ZmYuIEluIHRoZWlyIGRlZmF1bHQgY29uZmlndXJhdGlvbiwgDQpJUHY2IG5v ZGVzIFNIT1VMRCBOT1QgaW5jbHVkZSB0aGlzIG9wdGlvbiBpbiBJUHY2IHBh Y2tldHMgdGhhdCB0aGV5IA0Kb3JpZ2luYXRlLiAgVGhhdCBpcywgdGhlIHN3 aXRjaCBvciBzdGF0ZSBTSE9VTEQgZGVmYXVsdCB0byAnRGVidWcgb2ZmJy4N Cg0KQWRkaXRpb25hbGx5LCBpbXBsZW1lbnRlcnMgTVVTVCBwZXJtaXQgYSBz eXN0ZW0gYWRtaW5pc3RyYXRvciB0byBlbmFibGUNCm9yIGRpc2FibGUgaW5j bHVkaW5nIHRoaXMgb3B0aW9uIGluIG9yaWdpbmF0ZWQgSVB2NiBwYWNrZXRz IG9uIGF0IGxlYXN0DQphIHBlci1VcHBlci1Qcm90b2NvbCBiYXNpcyAoZS5n LiBhdCBsZWFzdCBwcm92aWRlIGVuYWJsZS9kaXNhYmxlIA0Kc2VwYXJhdGUg a25vYnMgZm9yIElDTVAsIFVEUCwgVENQLCBvciBTQ1RQLCBpbiBhZGRpdGlv biB0byBhIGtub2IgdG8gDQplbmFibGUgb3IgZGlzYWJsZSBmb3IgYWxsIElQ djYgcGFja2V0cyksIGFuZCBTSE9VTEQgcGVybWl0IGl0IGFsc28gdG8gDQpi ZSBlbmFibGVkIG9yIGRpc2FibGVkIG9uIGEgcGVyLWZsb3cgYmFzaXMuICBU aGlzIGNvbmZpZ3VyYXRpb24gDQpmbGV4aWJpbGl0eSB3b3VsZCBpbmNyZWFz ZSB0aGUgcG90ZW50aWFsIHZhbHVlIG9mIHRoaXMgbmV3IG9wdGlvbiwgYW5k IA0Kd291bGQgbm90IGluY3JlYXNlIGltcGxlbWVudGF0aW9uIGNvbXBsZXhp dHkgdW5kdWx5Lg0KDQpBZGRpdGlvbmFsbHksIHdlIHN1Z2dlc3QgdGhhdCBz dGFja3MgaW1wbGVtZW50IGEgc2VwYXJhdGUgSVBJRCBjb3VudGVyDQpwZXIg Y29ubmVjdGlvbiByYXRoZXIgdGhhbiBhIHNpbmdsZSBjb3VudGVyIGZvciBh bGwgY29ubmVjdGlvbnMuIA0KDQoNCjUuIEJhY2t3YXJkIENvbXBhdGliaWxp dHkNCg0KVGhlIHNjaGVtZSBwcm9wb3NlZCBpbiB0aGlzIGRvY3VtZW50IGlz IGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBhbGwgDQp0aGUgY3VycmVudGx5 IGRlZmluZWQgSVB2NiBleHRlbnNpb24gaGVhZGVycy4gQWNjb3JkaW5nIHRv IFJGQzI0NjAgDQpbUkZDMjQ2MF0sIGlmIHRoZSBkZXN0aW5hdGlvbiBub2Rl IGRvZXMgbm90IHJlY29nbml6ZSB0aGlzIG9wdGlvbiwgaXQgDQpzaG91bGQg c2tpcCBvdmVyIHRoaXMgb3B0aW9uIGFuZCBjb250aW51ZSBwcm9jZXNzaW5n IHRoZSBoZWFkZXIuDQoNCg0KRWxraW5zICAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDQsIDIwMTIgICAgICAgICAgIFtQYWdlIDA2XQ0K DQoMDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgSVB2NiBE aWFnbm9zdGljIE9wdGlvbiAgICAgICBKdWx5IDIwMTENCg0KNi4gU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMNCg0KVGhpcyBvcHRpb24gbWlnaHQgYmUgdXNl ZnVsIHRvIHNlY3VyaXR5IGdhdGV3YXlzIHNlZWtpbmcgdG8gaWRlbnRpZnkg DQpvcGVyYXRpb25hbCBzZWN1cml0eSBpc3N1ZXMgb3IgaW4gcHJldmVudGlu ZyBSZXBsYXkgQXR0YWNrcy4NCg0KDQo3LiBJQU5BIENvbnNpZGVyYXRpb25z DQoNCkEgRGVzdGluYXRpb24gT3B0aW9uIHJlcXVpcmVzIGFuIElQdjYgT3B0 aW9uIE51bWJlciBvciBUeXBlIFtSRkMyNDYwXSANCndoaWNoIGlzIDggYml0 cy4NCg0KSEVYLi4uLi4uLi4uYWN0Li5jaGcuLnJlc3QgKDUgYml0cykNCi0t LS0gICAgICAgIC0tLS0gLS0tICAtLS0tDQpUQkQgICAgICAgICAgMDAgICAw ICAgIFRCRCAgIElQdjYgRGlhZ25vc3RpYyBPcHRpb24NCg0KRm9yIHRoZSBJ UHY2IE9wdGlvbiBOdW1iZXIgKFR5cGUpLCB0aGUgZmlyc3QgdHdvIGJpdHMg aW5kaWNhdGUgdGhhdCANCnRoZSBJUHY2IG5vZGUgc2tpcCBvdmVyIHRoaXMg b3B0aW9uIGFuZCBjb250aW51ZSBwcm9jZXNzaW5nIHRoZSBoZWFkZXIgDQpp ZiBpdCBkb2VzIG5vdCByZWNvZ25pc2UgdGhlIG9wdGlvbiB0eXBlLiAgVGhl IHRoaXJkIGJpdCBpbmRpY2F0ZXMgDQp0aGF0IHRoZSBPcHRpb24gRGF0YSBt dXN0IG5vdCBjaGFuZ2UgZW4tcm91dGUsIHdoaWNoIHBlcm1pdHMgdGhpcw0K b3B0aW9uIHRvIGJlIHByb3RlY3RlZCBieSB0aGUgSVAgQXV0aGVudGljYXRp b24gSGVhZGVyLg0KDQoNCjEwLiBSZWZlcmVuY2VzDQoNCjEwLjEuIE5vcm1h dGl2ZSBSZWZlcmVuY2VzDQoNCltSRkM3OTFdIFBvc3RlbCwgSi4sICJJbnRl cm5ldCBQcm90b2NvbCIsIFJGQyA3OTEgLyBTVEQgNSwgU2VwdGVtYmVyDQox OTgxLg0KDQpbUkZDMjQ2MF0gRGVlcmluZywgUy4gYW5kIFIuIEhpbmRlbiwg IkludGVybmV0IFByb3RvY29sLCBWZXJzaW9uIDYNCihJUHY2KSBTcGVjaWZp Y2F0aW9uIiwgUkZDIDI0NjAsIERlY2VtYmVyIDE5OTguDQoNCltSRkMyODYz XSBLLiBNY0Nsb2docmllLCBLLiwgS2FzdGVuaG9seiwgRi4gIlRoZSBJbnRl cmZhY2VzIEdyb3VwIA0KTUlCIiwgUkZDIDI4NjMsIEp1bmUgMjAwMC4NCg0K W1JGQzIxMTldIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4g UkZDcyB0byBJbmRpY2F0ZSANClJlcXVpcmVtZW50IExldmVscyIsIEJDUCAx NCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCltSRkMyNzgwXSBCcmFkbmVy LCBTLiwgUGF4c29uLCBWLiAiSUFOQSBBbGxvY2F0aW9uIEd1aWRlbGluZXMg DQpGb3IgVmFsdWVzIEluIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBhbmQgUmVs YXRlZCBIZWFkZXJzIiwgUkZDIDI3ODAsDQpNYXJjaCAyMDAwLg0KU2VlIGFs c286DQpodHRwOmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaXB2 Ni1wYXJhbWV0ZXJzDQoNCg0KMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNl cw0KDQpbUkZDNDk2M10gSGVmZm5lciwgSi4sIE1hdGhpcywgTS4sIENoYW5k bGVyLCBCLiwgIklQdjQgUmVhc3NlbWJseSANCkVycm9ycyBhdCBIaWdoIERh dGEgUmF0ZXMiLCBSRkMgNDk2MywgSnVseSAyMDA3Lg0KDQpbRHJhZnQtaXB2 NC1pZF0gVG91Y2gsIEouLCAiVXBkYXRlZCBTcGVjaWZpY2F0aW9uIG9mIHRo ZSBJUHY0IElEIA0KRmllbGQiLCBkcmFmdC1pZXRmLWludGFyZWEtaXB2NC1p ZC11cGRhdGUtMDIudHh0LCBNYXJjaCAyMDExDQoNCkVsa2lucyAgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA0LCAyMDEyICAgICAgICAg ICBbUGFnZSAwN10NCg0KDA0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIElQdjYgRGlhZ25vc3RpYyBPcHRpb24gICAgICAgSnVseSAyMDEx DQoNCg0KMTEuIEFja25vd2xlZGdtZW50cw0KDQpUaGUgYXV0aG9ycyB3b3Vs ZCBsaWtlIHRvIHRoYW5rIEZyZWQgQmFrZXIsIEJpbGwgSm91cmlzLCBKb3Nl IElzaWRybyANClIuIEouIEF0a2luc29uIGFuZCBKYW1lcyBBc2h0b24gZm9y IHRoZWlyIHJldmlld3MgYW5kIHN1Z2dlc3Rpb25zIHRoYXQNCm1hZGUgdGhp cyBkb2N1bWVudCBiZXR0ZXIuDQoNClRoaXMgZG9jdW1lbnQgd2FzIHByZXBh cmVkIHVzaW5nIDItV29yZC12Mi4wLnRlbXBsYXRlLmRvdC4NCg0KDQpBdXRo b3JzJyBBZGRyZXNzZXMNCiAgIE5hbGluaSBFbGtpbnMNCiAgIEluc2lkZSBQ cm9kdWN0cywgSW5jLg0KICAgMzZBIFVwcGVyIENpcmNsZQ0KICAgQ2FybWVs IFZhbGxleSwgQ0ENCiAgIFVuaXRlZCBTdGF0ZXMNCg0KICAgUGhvbmU6ICsx IDgzMSA2NTkgODM2MA0KICAgRW1haWw6IG5hbGluaS5lbGtpbnNAaW5zaWRl dGhlc3RhY2suY29tDQoNCg0KICAgTGF3cmVuY2UgS3JhdHprZQ0KICAgSUJN DQogICA4MTIxIEdsZW5icml0dGxlIFdheQ0KICAgUmFsZWlnaCwgTkMgMjc2 MTUNCiAgIFVuaXRlZCBTdGF0ZXMgDQoNCiAgIFBob25lOiArMSA4MDAtODc2 LTg4MDENCiAgIEVtYWlsOiBrcmF0emtlQHVzLmlibS5jb20NCg0KDQogICBN aWNoYWVsIEFja2VybWFubg0KICAgQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBv ZiBNaWNoaWdhbg0KICAgUC5PLiBCb3ggMjg4OA0KICAgRGV0cm9pdCwgTWlj aGlnYW4gNDgyMzENCiAgIFVuaXRlZCBTdGF0ZXMNCg0KICAgUGhvbmU6ICsx IDMxMCA0NjAgNDA4MA0KICAgRW1haWw6IG1hY2tlcm1hbm5AYmNic21pLmNv bQ0KDQpFbGtpbnMgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVh cnkgNCwgMjAxMiAgICAgICAgICAgW1BhZ2UgMDhdDQoMCg== --0-1419993237-1311309458=:77451-- From roland.bless@kit.edu Thu Jul 21 22:41:54 2011 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 9DE4321F866A; Thu, 21 Jul 2011 22:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETJGdMEovsHQ; Thu, 21 Jul 2011 22:41:53 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22A21F8669; Thu, 21 Jul 2011 22:41:52 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1Qk8Ub-0001kM-Na; Fri, 22 Jul 2011 07:41:51 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1Qk8Ub-0004nJ-JS; Fri, 22 Jul 2011 07:41:45 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 788C6A800D4; Fri, 22 Jul 2011 07:41:45 +0200 (CEST) Message-ID: <4E290D99.3030300@kit.edu> Date: Fri, 22 Jul 2011 07:41:45 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: v6ops@ietf.org Subject: Re: [v6ops] IPv6 Diagnostic Option References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> In-Reply-To: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1311313311.417554000 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, 22 Jul 2011 05:41:54 -0000 Hi, On 22.07.2011 06:38, nalini.elkins@insidethestack.com wrote: > Would love to get feedback on an Internet Draft we have submitted. > The issue we are addressing is that the IP Identification field which > was available with IPv4 in the main header is available with IPv6 > only in the Fragment Header. I don't think that your proposed solution is necessary, since IPv6 has the Flow Label, that - if set by the source - may be very well suited for your purpose (tracking flows along a path). Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ for more details. Kind regards, Roland From ek@google.com Thu Jul 21 23:35:41 2011 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 B82E911E8070 for ; Thu, 21 Jul 2011 23:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.939 X-Spam-Level: X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUg+krSb4a5g for ; Thu, 21 Jul 2011 23:35:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A50EA11E8079 for ; Thu, 21 Jul 2011 23:35:40 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p6M6Zd2V014712 for ; Thu, 21 Jul 2011 23:35:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311316539; bh=kRxK+sWY51G7WW35LXKetz0sROs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rvQkpbu9JXDcqvju1lUq7AuDr0MqyHBy25r69OGVh9WsKXonvGpDOQM9JOytYaaJ0 aRy9yTY4rOZ8w8AAYbXEg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=n1lMcD61CynWY3v2gjeyYj8Yz5Vf/yAPsNgET9yljKj1QOrAhKHTkQs86ufN7qN+V dhgcjBH6yTH4KLaDGF7yw== Received: from qwf7 (qwf7.prod.google.com [10.241.194.71]) by wpaz13.hot.corp.google.com with ESMTP id p6M6ZbuG010893 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 21 Jul 2011 23:35:38 -0700 Received: by qwf7 with SMTP id 7so1264190qwf.24 for ; Thu, 21 Jul 2011 23:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ioT0gSkT6dA+jd5vmIusFdyjhJj6uUO4BeADtmOmLsU=; b=M1IrWQ6H5/fpV2lN8ivPhzl2g16oxjPbYRfpzLrPlAyfmD8pjVeTS6gnxbQkeznMpy NCfQtj4VCE/QOrrVxEeQ== MIME-Version: 1.0 Received: by 10.224.200.5 with SMTP id eu5mr976844qab.189.1311316537786; Thu, 21 Jul 2011 23:35:37 -0700 (PDT) Received: by 10.229.136.66 with HTTP; Thu, 21 Jul 2011 23:35:37 -0700 (PDT) In-Reply-To: <4E290D99.3030300@kit.edu> References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> Date: Fri, 22 Jul 2011 15:35:37 +0900 Message-ID: Subject: Re: [v6ops] IPv6 Diagnostic Option From: Erik Kline To: Roland Bless Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: v6ops@ietf.org, 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, 22 Jul 2011 06:35:41 -0000 > I don't think that your proposed solution is necessary, since > IPv6 has the Flow Label, that - if set by the source - may be > very well suited for your purpose (tracking flows along a path). > Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ > for more details. Agreed. I also think use of the flowlabel will prove operationally simpler. Some devices drop IPv6 packets that have any kind of headers, even fragment headers, since they lack the ability to look beyond these headers at line rate. From roland.bless@kit.edu Fri Jul 22 00:59:56 2011 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 2E23F21F869E; Fri, 22 Jul 2011 00:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpC5DPeEb1US; Fri, 22 Jul 2011 00:59:55 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD4D21F869D; Fri, 22 Jul 2011 00:59:54 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1QkAeA-0006zQ-OA; Fri, 22 Jul 2011 09:59:52 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1QkAeA-0003kj-Dc; Fri, 22 Jul 2011 09:59:46 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 3FD52A80036; Fri, 22 Jul 2011 09:59:46 +0200 (CEST) Message-ID: <4E292DF2.5000607@kit.edu> Date: Fri, 22 Jul 2011 09:59:46 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Erik Kline Subject: Re: [v6ops] IPv6 Diagnostic Option References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1311321592.459773000 Cc: v6ops@ietf.org, 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, 22 Jul 2011 07:59:56 -0000 Hi Erik, On 22.07.2011 08:35, Erik Kline wrote: >> I don't think that your proposed solution is necessary, since >> IPv6 has the Flow Label, that - if set by the source - may be >> very well suited for your purpose (tracking flows along a path). >> Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ >> for more details. > > I also think use of the flowlabel will prove operationally simpler. Yes, fully agree since a) the Flow Label is part of the standard common IPv6 header, thus always present and easier to process (even in the fast path) as you also pointed out. b) Useful Flow Label support in end-systems (i.e., setting the Flow Label correctly) is more likely than support for this newly suggested additional option, once it would have been adopted. c) it is really unclear how you would enable the use of the proposed option in end-systems on demand. In case of debugging a network problem you need to enable this option later, if not too late. Regards, Roland From arturo.servin@gmail.com Fri Jul 22 04:37:13 2011 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 B27E221F87BD; Fri, 22 Jul 2011 04:37:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd6JFf3YtSrx; Fri, 22 Jul 2011 04:37:13 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB2621F8793; Fri, 22 Jul 2011 04:37:12 -0700 (PDT) Received: by qwc23 with SMTP id 23so1759066qwc.31 for ; Fri, 22 Jul 2011 04:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=w3JeqfAVcBJtcInSOvBhvYsRvx/fY4TXfWKVO1WO9cM=; b=mQLC6MQsQPSBy6GBFv32g6dGPstyG4EsD5mG2arIKgl9ij01B0rT41/d/5Ud3mO9qM oNQ191NQoVm37rIx0Yh+AH/w2yxRynKKjFfyBKN4cXSn5QJ5Dn7slkEXuhjacG7qdKdv 1/ik51m0+dadZHMhzexpYocvtsNAa4nQSkDvI= Received: by 10.224.179.195 with SMTP id br3mr1205083qab.284.1311334632355; Fri, 22 Jul 2011 04:37:12 -0700 (PDT) Received: from [192.168.1.101] (r186-48-209-197.dialup.adsl.anteldata.net.uy [186.48.209.197]) by mx.google.com with ESMTPS id w12sm856284qct.12.2011.07.22.04.37.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 04:37:11 -0700 (PDT) Subject: Re: [v6ops] IPv6 Diagnostic Option Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <4E292DF2.5000607@kit.edu> Date: Fri, 22 Jul 2011 08:37:06 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9B486090-29D8-41C9-87B2-01D5F8D9FECE@gmail.com> References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> <4E292DF2.5000607@kit.edu> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) 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, 22 Jul 2011 11:37:13 -0000 Nalini Basically I agree with what others said. If there were any reason for not using the flow label, I think = you should state it very clearly in the document.=20 Regards, .as On 22 Jul 2011, at 04:59, Roland Bless wrote: > Hi Erik, >=20 > On 22.07.2011 08:35, Erik Kline wrote: >>> I don't think that your proposed solution is necessary, since >>> IPv6 has the Flow Label, that - if set by the source - may be >>> very well suited for your purpose (tracking flows along a path). >>> Please see = http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ >>> for more details. >>=20 >> I also think use of the flowlabel will prove operationally simpler. >=20 > Yes, fully agree since > a) the Flow Label is part of the standard common IPv6 header, thus > always present and easier to process (even in the fast path) as > you also pointed out. > b) Useful Flow Label support in end-systems (i.e., setting the Flow > Label correctly) is more likely than support for this newly > suggested additional option, once it would have been adopted. > c) it is really unclear how you would enable the use of the proposed > option in end-systems on demand. In case of debugging a network > problem you need to enable this option later, if not too late. >=20 > Regards, > Roland > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Internet-Drafts@ietf.org Fri Jul 22 07:30:03 2011 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 0E8AE21F854D; Fri, 22 Jul 2011 07:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD-A4RgRCATn; Fri, 22 Jul 2011 07:30:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6321F8ABC; Fri, 22 Jul 2011 07:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-6man-flow-ecmp-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110722143002.30991.75727.idtracker@ietfa.amsl.com> Date: Fri, 22 Jul 2011 07:30:02 -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: Fri, 22 Jul 2011 14:30:03 -0000 --NextPart 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 : Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Author(s) : B. Carpenter, et al Filename : draft-ietf-6man-flow-ecmp-05.txt Pages : 10 Date : 2011-07-22 The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-flow-ecmp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-22072118.I-D@ietf.org> --NextPart-- From nalini.elkins@insidethestack.com Fri Jul 22 09:03:09 2011 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 7B72421F8B1A for ; Fri, 22 Jul 2011 09:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRe9AioukOIU for ; Fri, 22 Jul 2011 09:03:08 -0700 (PDT) Received: from nm13-vm1.access.bullet.mail.sp2.yahoo.com (nm13-vm1.access.bullet.mail.sp2.yahoo.com [98.139.44.161]) by ietfa.amsl.com (Postfix) with SMTP id 8298321F8B16 for ; Fri, 22 Jul 2011 09:03:08 -0700 (PDT) Received: from [98.139.44.99] by nm13.access.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 16:03:07 -0000 Received: from [98.139.44.81] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 16:03:07 -0000 Received: from [127.0.0.1] by omp1018.access.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 16:03:07 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 667894.5196.bm@omp1018.access.mail.sp2.yahoo.com Received: (qmail 7131 invoked by uid 60001); 22 Jul 2011 16:03:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311350587; bh=Nza1SIJoEDTGbFKLgocPXlRKFgsKAJpqT8kaHwMsu1Q=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YvOlptHXzjrT4CYCzK2Va6sCJlar9C91Cb6LJzbF/QhK4ETO7ryGLFQn3vPEllN5KG9Q9ZjebjOyzByvB6ymPJ5H+1/VXDSMVwXuABRxPh3wUkqEpwFOXEc5RSQrl5N6UX+FUyer13+rDmekHBdV0JOY5Bnel+qy3BVob+q640E= X-YMail-OSG: Vohx_TEVM1lYvOO701BP3jPJEro6D9zHPZKLWEcxm73SHV0 PbtuogXiWUyI.p9Qa34Dr1m9UVwAIg4El1mlATvDI1oq8wA2e.DAOSApkUf2 Du.CGQLNG.3QqwqrL30EAewSLn8tznfGsJtEh_FG4m.gq5f325XNtt9rBHV. GkBpUsE65xF6bIL7X30NuEjUt0qx.BI133BZ8MMYJ8j_M8oDR_m3dHXUxgYf 1I4cX0eVR.PcoCF4caYgHgnk5AQLob4FpNmHkBRlj3PjYeLXpm5iTHgEjK__ Z4uOfPrgmzNXfX_nuH6josTT_FJmUj6m6SD8t8EgI24fgZ_T81Cm3TwWzVm7 ACne7IoP0lLLLOhHrcnbm1GJk_xsPoSvq8TtexAxLMABphdo5HmXa3G0Kp4E XH7yOcXcW_S_.6xxj6j0W3F.WqkpMGay8Et9fBQ3psWtwbMH7ucndQRcSv4n 4fdER.juX1Wc1MUFMsulvRNxZNvusUgDIrQ-- Received: from [24.6.68.48] by web2808.biz.mail.ne1.yahoo.com via HTTP; Fri, 22 Jul 2011 09:03:06 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311350586.900.YahooMailClassic@web2808.biz.mail.ne1.yahoo.com> Date: Fri, 22 Jul 2011 09:03:06 -0700 (PDT) From: nalini.elkins@insidethestack.com Subject: Re: [v6ops] IPv6 Diagnostic Option To: v6ops@ietf.org, ipv6@ietf.org In-Reply-To: <4E290D99.3030300@kit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:03:09 -0000 Thanks to all for your comments. But, there may be some confusion as to what we are trying to achieve. The Proposed Flow Label field, in our opinion, does not meet our requirements. The reasons are as follows: 1. The Flow Label, as defined, is a unique and (generally speaking) static identifier per flow. Its purpose is to distinguish one flow from another. 2. Our proposed field increments per packet WITHIN a flow. The intended purpose is to distinguish one packet from another not one flow from another. 3. The Flow Label is only 20 bits which is not sufficient to hold even the existing 32 bit ID. We are proposing a 64-bit ID. Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com --- On Thu, 7/21/11, Roland Bless wrote: > From: Roland Bless > Subject: Re: [v6ops] IPv6 Diagnostic Option > To: v6ops@ietf.org > Cc: ipv6@ietf.org > Date: Thursday, July 21, 2011, 10:41 PM > Hi, > > On 22.07.2011 06:38, nalini.elkins@insidethestack.com > wrote: > > Would love to get feedback on an Internet Draft we > have submitted. > > > The issue we are addressing is that the IP > Identification field which > > was available with IPv4 in the main header is > available with IPv6 > > only in the Fragment Header. > > I don't think that your proposed solution is necessary, > since > IPv6 has the Flow Label, that - if set by the source - may > be > very well suited for your purpose (tracking flows along a > path). > Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ > for more details. > > Kind regards, > Roland > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Fri Jul 22 13:48:25 2011 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 67D3921F8B01 for ; Fri, 22 Jul 2011 13:48:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdRRfgRXQMrs for ; Fri, 22 Jul 2011 13:48:24 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5AA621F8AFA for ; Fri, 22 Jul 2011 13:48:24 -0700 (PDT) Received: by yie30 with SMTP id 30so1707816yie.31 for ; Fri, 22 Jul 2011 13:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=RWHWCARXCqJYQ1xpQYReF3iscE1dXFEQM0zwfoSRr9Y=; b=DZtgR4pjDHQ3Enfzg1C1hQVa/6qCZda/V2o1IYaKlau10u5Ctjh+Zip2ZBNHSPUqmc A4o68N9KkBRufGivud+3+IjjI5dB7GDA3fLXhkV6KYES/+UB72IRu5rdK9BVoQ8fh++i zfQvXKSmZ2DJJHguGMTSDKPljV08iGflTATwc= Received: by 10.150.254.20 with SMTP id b20mr2553876ybi.91.1311367704193; Fri, 22 Jul 2011 13:48:24 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id v13sm3978242ybb.13.2011.07.22.13.48.22 (version=SSLv3 cipher=OTHER); Fri, 22 Jul 2011 13:48:23 -0700 (PDT) Message-ID: <4E29DE62.6020807@gmail.com> Date: Sat, 23 Jul 2011 08:32:34 +1200 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-flow-ecmp-05.txt] 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: Fri, 22 Jul 2011 20:48:25 -0000 This version, posted after the cutoff by special permission, is intended to respond to the various IESG comments. Details are in the tracker at https://datatracker.ietf.org/doc/draft-ietf-6man-flow-ecmp/ Brian -------- Original Message -------- Subject: I-D ACTION:draft-ietf-6man-flow-ecmp-05.txt Date: Fri, 22 Jul 2011 07:30:02 -0700 From: Internet-Drafts@ietf.org Reply-To: 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 : Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Author(s) : B. Carpenter, et al Filename : draft-ietf-6man-flow-ecmp-05.txt Pages : 10 Date : 2011-07-22 The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-05.txt From kauer@biplane.com.au Fri Jul 22 15:42:58 2011 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 C9F0B21F8A55 for ; Fri, 22 Jul 2011 15:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJTUcsbZtJwz for ; Fri, 22 Jul 2011 15:42:57 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 56EC421F8AE4 for ; Fri, 22 Jul 2011 15:42:55 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.201]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QkOQm-0002Gc-V9 for ipv6@ietf.org; Fri, 22 Jul 2011 18:42:53 -0400 Subject: Re: [v6ops] IPv6 Diagnostic Option From: Karl Auer To: ipv6@ietf.org In-Reply-To: <9B486090-29D8-41C9-87B2-01D5F8D9FECE@gmail.com> References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> <4E292DF2.5000607@kit.edu> <9B486090-29D8-41C9-87B2-01D5F8D9FECE@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+C32evT6DK350ilHMR4Z" Date: Sat, 23 Jul 2011 08:42:50 +1000 Message-ID: <1311374570.2650.17.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 22 Jul 2011 22:42:58 -0000 --=-+C32evT6DK350ilHMR4Z Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2011-07-22 at 08:37 -0300, Arturo Servin wrote: > If there were any reason for not using the flow label, I think you > should state it very clearly in the document.=20 Well, the obvious ones are a) your diagnostic may not be tracking a flow, but single packets or groups of packets that are only part of a flow. It may even be trying to figure out why a flow is not working. b) something else may be using the flow label such that modifying it for debugging purposes is impossible. > On 22 Jul 2011, at 04:59, Roland Bless wrote: > > a) the Flow Label is part of the standard common IPv6 header, thus > > always present and easier to process (even in the fast path) as > > you also pointed out. True, but if it is in use, you have a flow you can't diagnose (at least not by using the flow label). Bear in mind that the flow label may even change in transit (if I read the burbling, ever-changing discussion on flow labels correctly, which I may well not have). > > b) Useful Flow Label support in end-systems (i.e., setting the Flow > > Label correctly) is more likely than support for this newly > > suggested additional option, once it would have been adopted. Not sure I see your point here. As soon as the flow label is being used by end systems - correctly OR incorrectly - it can no longer be used by diagnostic tools, or at least not if they need to modify the flow label values. > > c) it is really unclear how you would enable the use of the proposed > > option in end-systems on demand. In case of debugging a network > > problem you need to enable this option later, if not too late. Presumably debugging tools would be able to do it. Having a debugging tool after the fact is still better than having no tool at all. My chief worry is that if you start inserting headers in a packet stream to debug it, you are changing what it is you are debugging - for example, possibly causing fragmentation where none was occurring before. The flow label has the nice property that it is in every packets anyway. However, there are plenty of classes of problem where an additional header would not affect the situation, and for those problems, this seems like a useful addition. As a generic debugging tool, it seems to me the diagnostic header is the most general and flexible, for all that it is not appropriate in some situations. And it doesn't seem to actually *hurt* anything, or at least no more than any other headers might. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-+C32evT6DK350ilHMR4Z 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) iEYEABECAAYFAk4p/OIACgkQMAcU7Vc29ofwqQCcDYLnUWGg1S1aACc/YK3sUY88 A6IAoMuTtRImL9hqzoWsLhjPI1k/irBn =rdr4 -----END PGP SIGNATURE----- --=-+C32evT6DK350ilHMR4Z-- From brian.e.carpenter@gmail.com Fri Jul 22 16:07:05 2011 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 5B3E721F8B61 for ; Fri, 22 Jul 2011 16:07:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX6-HvVfAlPw for ; Fri, 22 Jul 2011 16:07:04 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A83221F8B18 for ; Fri, 22 Jul 2011 16:07:04 -0700 (PDT) Received: by gxk19 with SMTP id 19so1764625gxk.31 for ; Fri, 22 Jul 2011 16:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NpAYxGG0MFDjzFMkg13B3nUKuQkgHJaUZjGfVc8Qdy4=; b=nNAV+NA3jLw6aHZuhQakpKExuA7l6XUZLMLRhZNCrjshaalIHat0fDnuzEN0qC6tme 72E3YCk6l/+J+h4RpMcJHUYZtJt5/7XpQoP3MFuvCjw30jS64q5k3IYH52PEbby6uvAI 0DfiJN0xTVCmz/5fgvm9IVP9+2zKw+8xgvi0k= Received: by 10.236.175.34 with SMTP id y22mr2803375yhl.143.1311376024123; Fri, 22 Jul 2011 16:07:04 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id o47sm2570720yhn.2.2011.07.22.16.07.01 (version=SSLv3 cipher=OTHER); Fri, 22 Jul 2011 16:07:03 -0700 (PDT) Message-ID: <4E2A0290.4030408@gmail.com> Date: Sat, 23 Jul 2011 11:06:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karl Auer Subject: Re: [v6ops] IPv6 Diagnostic Option References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> <4E292DF2.5000607@kit.edu> <9B486090-29D8-41C9-87B2-01D5F8D9FECE@gmail.com> <1311374570.2650.17.camel@karl> In-Reply-To: <1311374570.2650.17.camel@karl> 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: Fri, 22 Jul 2011 23:07:05 -0000 On 2011-07-23 10:42, Karl Auer wrote: > On Fri, 2011-07-22 at 08:37 -0300, Arturo Servin wrote: >> If there were any reason for not using the flow label, I think you >> should state it very clearly in the document. > > Well, the obvious ones are > > a) your diagnostic may not be tracking a flow, but single packets or > groups of packets that are only part of a flow. It may even be trying to > figure out why a flow is not working. > > b) something else may be using the flow label such that modifying it for > debugging purposes is impossible. > >> On 22 Jul 2011, at 04:59, Roland Bless wrote: >>> a) the Flow Label is part of the standard common IPv6 header, thus >>> always present and easier to process (even in the fast path) as >>> you also pointed out. > > True, but if it is in use, you have a flow you can't diagnose (at least > not by using the flow label). Bear in mind that the flow label may even > change in transit (if I read the burbling, ever-changing discussion on > flow labels correctly, which I may well not have). Since it's not protected by any checksum, it may be changed maliciously and undetectably. The 3697bis draft being reviewed now by the IESG states that it must not be changed once it has been set to a non-zero value, but also recognises that certain (relatively paranoid) firewalls may change it anyway. More to the point, 3697bis makes very specific recommendations as to how the flow label should be set by default. It is not a set of free bits. >>> b) Useful Flow Label support in end-systems (i.e., setting the Flow >>> Label correctly) is more likely than support for this newly >>> suggested additional option, once it would have been adopted. > > Not sure I see your point here. As soon as the flow label is being used > by end systems - correctly OR incorrectly - it can no longer be used by > diagnostic tools, or at least not if they need to modify the flow label > values. Exactly. Brian > >>> c) it is really unclear how you would enable the use of the proposed >>> option in end-systems on demand. In case of debugging a network >>> problem you need to enable this option later, if not too late. > > Presumably debugging tools would be able to do it. Having a debugging > tool after the fact is still better than having no tool at all. > > My chief worry is that if you start inserting headers in a packet stream > to debug it, you are changing what it is you are debugging - for > example, possibly causing fragmentation where none was occurring before. > The flow label has the nice property that it is in every packets anyway. > However, there are plenty of classes of problem where an additional > header would not affect the situation, and for those problems, this > seems like a useful addition. > > As a generic debugging tool, it seems to me the diagnostic header is the > most general and flexible, for all that it is not appropriate in some > situations. And it doesn't seem to actually *hurt* anything, or at least > no more than any other headers might. > > Regards, K. > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dwing@cisco.com Fri Jul 22 19:32:53 2011 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 0B4AD21F8B78 for ; Fri, 22 Jul 2011 19:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.89 X-Spam-Level: X-Spam-Status: No, score=-104.89 tagged_above=-999 required=5 tests=[AWL=-2.291, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UX8dVXCduit for ; Fri, 22 Jul 2011 19:32:52 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DD91021F8B4B for ; Fri, 22 Jul 2011 19:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6417; q=dns/txt; s=iport; t=1311388372; x=1312597972; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=pehndT+SQ3VSG50xakcJACaH89Nudp/69vwV/UDYT5Y=; b=cj4zF8MpO26CxKhau7INk7u0wBkqtrnDANhm4Pth6AhtJm9+h9z68IIc xZ02Rmk3u6DjZoP+rMo6M9OJr790nxj2dGeMrHGCXLWT95jpWnrtMsWC/ zOETODQ/exzzZWFw7bvetpArOuUIPkUTvY0PXX6dU11yHjSUGTrztW10N I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8AAFoyKk6rRDoI/2dsb2JhbABTl36Ba41ld4h8BJ8qnh6GPwSHVZwY X-IronPort-AV: E=Sophos;i="4.67,250,1309737600"; d="scan'208";a="5678476" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2011 02:32:51 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6N2Wofj022342; Sat, 23 Jul 2011 02:32:50 GMT From: "Dan Wing" To: "'RJ Atkinson'" , References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> In-Reply-To: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> Subject: RE: PMTUD and MTU < 1280 Date: Fri, 22 Jul 2011 19:32:50 -0700 Message-ID: <01d101cc48e0$d15dee90$7419cbb0$@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: AcxHJQwkXcSteuXPQ6ads0toPimuWgBuycSA 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: Sat, 23 Jul 2011 02:32:53 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > RJ Atkinson > Sent: Wednesday, July 20, 2011 2:36 PM > To: ipv6@ietf.org > Subject: Re: PMTUD and MTU < 1280 > > Earlier, Brian Carpenter wrote: > > It's always been my understanding that an interface sending IPv6 > packets > > MUST implement some (unspecified) form of framentation and reassembly > > *below layer 3* if the link MTU is less than 1280. In other words a > > PTB for a packet of length 1280 is an unrecoverable violation. > > I also understand that the IPv6 specifications say that > the minimum IPv6 MTU for any link type is 1280 bytes. > > I am not sure the specs insist that an IPv6 implementation > must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes > as "unrecoverable". (I haven't re-read the IPv6 specs recently.) IPv6 specs have always said that ICMPv6 packet-too-big for less than the minimum MTU should cause the IPv6 host to send packets (of that minimum MTU size) with an additional fragmentation header. This existed in the first IPv6 RFC, RFC1883 (when the IPv6 minimum MTU was 576): 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 576. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 576, 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 528 octets (576 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. and in the current IPv6 RFC, RFC2460: 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. -d > I understand that some deployed IPv6 implementations will > tolerate and support Packet-Too-Big messages with a link MTU > at least as small as 576 -- following the Postel Principle > of "generous in what one accepts" and being practical about > several radio link technologies that do not support a > 1280 byte IP MTU. Such implementations are more resilient > than the IPv6 specifications require; this is helpful. > > > For example, if you're tunneling IPv6 over an IPv4 network whose PMTU > > (to the other end of the tunnel) is, to take a random example, 576, > > the tunnel end points could use IPv4 fragmentation and reassembly > > to provide a 1280 MTU for the IPv6 traffic. > > One could do that. Over low-bandwidth radio links the overhead of > doing > that would effectively make it preferable to deploy an IPv6::IPv4 > translator > or some other protocol translation scheme (and continue with IPv4 > forever, > at least on that link) than to encapsulate IPv6 in anything more than > just the radio link layer just to meet the 1280 byte requirement. > > As I recall, I noted this problem to the IPv6 WG back in the middle > 1990s.[1] > Sadly. that prediction seems to have come true. So I understand that > today, > over some deployed radio link technologies, several IPv6 > implementations use > the raw link encapsulation and fragment IPv6 into chunks at that raw > link > MTU size (even though that is below 1280 bytes). > > > Of course this doesn't cover the NAT64 case; so what? NAT breaks many > things. > > We just have to rely on the real world, where the layer 2 link MTU is > pretty > > much always 1500 today. > > I agree that the IEEE standard Ethernet link MTU is very widely > deployed > today. Many, possibly most, Ethernet switches also support a link MTU > somewhat over 9K bytes. > > I'm told that SONET links most commonly use the old FDDI link MTU > (roughly 4500 bytes). > ATM links, which seem to be going away, most commonly support an IP MTU > near > 9180 bytes (which value seems to have driven the Jumbo Ethernet > implementations). > However, there are still a number of link types, mostly radio link > types > (as near as I can tell), that have a link MTU well below 1280 bytes. > As > near as I can tell, IPv6 would have been much better off selecting 512 > bytes > as the minimum IPv6 MTU size.[1] > > It is very unfortunate that IPv6 specifies this very large minimum MTU > size > (i.e. 1280 bytes), because it is impeding the ability of various > organisations > to deploy IPv6 on a number of existing links that already support IPv4. > > This is just the kind of obstacle to deployment that IPv6 does not > need. > Specifying the value 1280 is not solving a real technical problem, > IMHO. > A lower value would facilitate faster, easier, simpler, and more > widespread > deployment and use of IPv6, IMHO. > > IPv4 can run over nearly any link without protocol changes or requiring > special case handling. Sadly, IPv6 cannot make the same claim. One > hopes > IPv6 implementers will be tolerant of IPv6 MTUs below 1280 bytes, > because > they do exist in the deployed world and aren't going away anytime soon. > > Yours, > > Ran Atkinson > > [1] proceedings/94dec/area.and.wg.reports/ipng/ipngwg/ipngwg-minutes- > 94dec.txt> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dwing@cisco.com Fri Jul 22 19:34:23 2011 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 406D421F8BE5 for ; Fri, 22 Jul 2011 19:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.755 X-Spam-Level: X-Spam-Status: No, score=-104.755 tagged_above=-999 required=5 tests=[AWL=-2.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8j2q9tl31mz for ; Fri, 22 Jul 2011 19:34:22 -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 9A79D21F8BE2 for ; Fri, 22 Jul 2011 19:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1204; q=dns/txt; s=iport; t=1311388462; x=1312598062; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=i7HxuSoO1w+kqLFDYu+oPryWnHOGGBzdl++PbThVYds=; b=fQ+0hANfkcbRCT6jD+dMALXcQA9+NaoMpVdDmV4mfkqIaoDZ5GLHJnXV jW8WbM7ZmBdrOmyQY8qrBjZrpzUvi2sLhUxAOqotdPV/sqDZHt+zQs2pK iQvvvPZSfKRNQTKfkIEt5s0q8vDmZJbovjMhRGtuGyRlENnN0nfbA6R5Z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8AAFoyKk6rRDoI/2dsb2JhbABTl36Ba41ld4kAnyqeHoY/BIdVnBg X-IronPort-AV: E=Sophos;i="4.67,250,1309737600"; d="scan'208";a="5679373" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jul 2011 02:34:22 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6N2YLKj022835; Sat, 23 Jul 2011 02:34:21 GMT From: "Dan Wing" To: "'james woodyatt'" , "'RJ Atkinson'" References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> In-Reply-To: Subject: RE: PMTUD and MTU < 1280 Date: Fri, 22 Jul 2011 19:34:21 -0700 Message-ID: <01d201cc48e1$0784d8d0$168e8a70$@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: AcxHJkDlwpNixcDNR4qLEfF6EqKWowBup9uA Content-Language: en-us 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, 23 Jul 2011 02:34:23 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > james woodyatt > Sent: Wednesday, July 20, 2011 2:44 PM > To: RJ Atkinson > Cc: ipv6@ietf.org > Subject: Re: PMTUD and MTU < 1280 > > On Jul 20, 2011, at 14:35 , RJ Atkinson wrote: > > > One hopes IPv6 implementers will be tolerant of IPv6 MTUs below 1280 > bytes, because they do exist in the deployed world and aren't going > away anytime soon. > > Those hopes are not well placed. > > I am aware of at least one packet filter implementation-- which might > be refined in the future, one hopes, to conform fully with RFC 6092-- > that treats this behavior as a resource exhaustion attack and drops > flows accordingly. Its behavior violates the last paragraph of Section 5 of RFC2460. -d > > -- > james woodyatt > member of technical staff, core os networking > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From roland.bless@kit.edu Sat Jul 23 13:48:17 2011 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 DFDD021F8BE4 for ; Sat, 23 Jul 2011 13:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJdQN-1F01F6 for ; Sat, 23 Jul 2011 13:48:17 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC01521F8BE1 for ; Sat, 23 Jul 2011 13:48:16 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1Qkj7G-0008F3-Dd; Sat, 23 Jul 2011 22:48:14 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id C7FEAA80139; Sat, 23 Jul 2011 22:48:05 +0200 (CEST) Message-ID: <4E2B3384.2030905@kit.edu> Date: Sat, 23 Jul 2011 22:48:04 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Karl Auer Subject: Re: [v6ops] IPv6 Diagnostic Option References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> <4E292DF2.5000607@kit.edu> <9B486090-29D8-41C9-87B2-01D5F8D9FECE@gmail.com> <1311374570.2650.17.camel@karl> In-Reply-To: <1311374570.2650.17.camel@karl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1311454094.347014000 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, 23 Jul 2011 20:48:18 -0000 Hi Karl, On 23.07.2011 00:42, Karl Auer wrote: > Well, the obvious ones are > > a) your diagnostic may not be tracking a flow, but single packets or > groups of packets that are only part of a flow. It may even be trying to > figure out why a flow is not working. The draft was lacking a clear problem statement so that wasn't clear to me. >> On 22 Jul 2011, at 04:59, Roland Bless wrote: >>> a) the Flow Label is part of the standard common IPv6 header, thus >>> always present and easier to process (even in the fast path) as >>> you also pointed out. > > True, but if it is in use, you have a flow you can't diagnose (at least > not by using the flow label). Bear in mind that the flow label may even Depends on what you want to diagnose. > change in transit (if I read the burbling, ever-changing discussion on > flow labels correctly, which I may well not have). That shouldn't be the case though, see Brian's reply. >>> b) Useful Flow Label support in end-systems (i.e., setting the Flow >>> Label correctly) is more likely than support for this newly >>> suggested additional option, once it would have been adopted. > > Not sure I see your point here. As soon as the flow label is being used > by end systems - correctly OR incorrectly - it can no longer be used by > diagnostic tools, or at least not if they need to modify the flow label > values. My point was referring to the case when the flow label is being used as intended, not for other purposes. >>> c) it is really unclear how you would enable the use of the proposed >>> option in end-systems on demand. In case of debugging a network >>> problem you need to enable this option later, if not too late. > > Presumably debugging tools would be able to do it. Having a debugging > tool after the fact is still better than having no tool at all. My point was that you cannot assume that every end-system has such debugging tool installed and that you can turn it on remotely. So using special end-systems as debugging tools sending these special packets out is IMHO a different setting... > My chief worry is that if you start inserting headers in a packet stream > to debug it, you are changing what it is you are debugging - for Yes. Regards, Roland From kauer@biplane.com.au Sat Jul 23 17:39:43 2011 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 0043D21F8BD8 for ; Sat, 23 Jul 2011 17:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY5j2Ny0m88f for ; Sat, 23 Jul 2011 17:39:41 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7F51A21F8BC8 for ; Sat, 23 Jul 2011 17:39:40 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.201]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QkmjJ-0001AZ-QC for ipv6@ietf.org; Sat, 23 Jul 2011 20:39:37 -0400 Subject: Re: [v6ops] IPv6 Diagnostic Option From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4E2B3384.2030905@kit.edu> References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> <4E292DF2.5000607@kit.edu> <9B486090-29D8-41C9-87B2-01D5F8D9FECE@gmail.com> <1311374570.2650.17.camel@karl> <4E2B3384.2030905@kit.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MOJIvY53cgR29uhpo7hM" Date: Sun, 24 Jul 2011 10:39:36 +1000 Message-ID: <1311467976.2650.154.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: 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, 24 Jul 2011 00:39:43 -0000 --=-MOJIvY53cgR29uhpo7hM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2011-07-23 at 22:48 +0200, Roland Bless wrote: > The draft was lacking a clear problem statement so that wasn't clear to m= e. The proposer has put a fairly clear one into this discussion, hope it ends up in the next draft :-) > Depends on what you want to diagnose. That's always true. No tool will fit all situations. The question about this one, as for all such things, is simply "is it worth having?" > > change in transit (if I read the burbling, ever-changing discussion on > > flow labels correctly, which I may well not have). >=20 > That shouldn't be the case though, see Brian's reply. "Shouldn't be the case" is a far cry from "won't be the case". And the cases where what you expect is not what you get are exactly the cases where a flow-label-independent tool would likely be Very Nice To Have. > My point was referring to the case when the flow label is being used > as intended, not for other purposes. And my point was that "as intended" is very far from clear (and IMO rather unlikely ever to be clear). > My point was that you cannot assume that every end-system has such > debugging tool installed and that you can turn it on remotely. This is true of all end-to-end debugging tools...? I suppose I'm saying that you've not convinced me as to why we should NOT have a diagnostic header. Your arguments all say, in one way or another, that there are situations where it won't be useful. But that is true for all such things. To convince me to be against this proposal, I would need to see - arguments that show how it is a bad thing - arguments that show how it is a useless thing - arguments that show how it will not work - arguments that show how it is not needed "Not needed" is different from "useless". "Not needed" means that while the thing it does is useful, that thing can be done using an existing tool. I think most of your points are well-made, I just don't think they are showstoppers for this proposed new header. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-MOJIvY53cgR29uhpo7hM 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) iEYEABECAAYFAk4racIACgkQMAcU7Vc29oeSZQCgh60fzZvntqwhGdanm0Nq3+SR Aq0AnRbN0d/lh0w1SxESsNUEeE/uNvbN =cLoJ -----END PGP SIGNATURE----- --=-MOJIvY53cgR29uhpo7hM-- From bob.hinden@gmail.com Sun Jul 24 10:03:20 2011 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 4E96F21F85F6 for ; Sun, 24 Jul 2011 10:03:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cixkil9dzoL8 for ; Sun, 24 Jul 2011 10:03:19 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id D436521F85C0 for ; Sun, 24 Jul 2011 10:03:19 -0700 (PDT) Received: by pzk6 with SMTP id 6so6711630pzk.26 for ; Sun, 24 Jul 2011 10:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=OG9V9y5LWke5Zm9lGeyBLEMAz95Ki2zefVoqOoD1PfA=; b=h4B/c1eHsZmsZa2bhzVNX+JfC8BqcrRvO8pJfncIqzGy4+y6ZzbdIwyXXvEb4Ewm0n 0Nix1Ox1RkR4/Z8+x4H3+WvnkWsd2huALER7mRJltdb6UlqZVxB8kwi0S2AZXShxRHGh jOre2dmBegvfRvqKVx1CzSY7SVpJfWy9tZCV4= Received: by 10.68.52.196 with SMTP id v4mr6583915pbo.508.1311526997983; Sun, 24 Jul 2011 10:03:17 -0700 (PDT) Received: from dhcp-445b.meeting.ietf.org (dhcp-445b.meeting.ietf.org [130.129.68.91]) by mx.google.com with ESMTPS id d1sm3792392pbj.56.2011.07.24.10.03.16 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jul 2011 10:03:17 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Need Jabber Scribe and Minute taker for 6man session Date: Sun, 24 Jul 2011 13:03:14 -0400 Message-Id: To: 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden 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, 24 Jul 2011 17:03:20 -0000 Hi, The 6man chairs are looking for volunteers to take minutes and for = jabber scribes. If you are interested please let the chairs know. It's = your opportunity to contribute to the overall quality of the meeting = materials. Thanks, Bob & Brian From dwing@cisco.com Mon Jul 25 06:36:29 2011 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 5C7E221F872F for ; Mon, 25 Jul 2011 06:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.347 X-Spam-Level: X-Spam-Status: No, score=-104.347 tagged_above=-999 required=5 tests=[AWL=-2.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4yzAPFB+6LA for ; Mon, 25 Jul 2011 06:36:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E16A021F871E for ; Mon, 25 Jul 2011 06:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2484; q=dns/txt; s=iport; t=1311600987; x=1312810587; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=MJJ3MfiMTKnrkIMzBcEvt1RM+ut3BuZvEAAwlRITsuw=; b=PMmdHju+MX7Hu1MhMeIhRTKsXqSXeBIE06B3Du4R03HIIU9MiW6x27eQ zS4PEVXP/CaTaVnSId+49jg1IX8MF5d2XnBE89ZXuhfSDOQt7IRYZ4MEM +QAndyoMQBoCOVhtxKPJ3WogxiKr71+KXvcEvBcX3gehhjcU5CJyC3E2S c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAL1wLU6rRDoJ/2dsb2JhbAA0AQEBAQIBAQEBBQwBG0oLBQcBBAIKDwIEAQEBMwcUBhIWDQ4IAQEFFw8Yl1uBa41qd4h8BKIZnXWGPwSHJpxG X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6112663" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jul 2011 13:36:26 +0000 Received: from dwingWS (sjc-vpn7-1405.cisco.com [10.21.149.125]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6PDaPAt024489; Mon, 25 Jul 2011 13:36:25 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> <01d201cc48e1$0784d8d0$168e8a70$@com> <010826E2-D6DF-488D-B5C4-CE14E47C7EE7@free.fr> In-Reply-To: <010826E2-D6DF-488D-B5C4-CE14E47C7EE7@free.fr> Subject: RE: PMTUD and MTU < 1280 Date: Mon, 25 Jul 2011 09:36:23 -0400 Message-ID: <04db01cc4acf$d9074600$8b15d200$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxKx81J7tGrsca9Tg2qObusHP6mSQAB+ehw Content-Language: en-us Cc: ipv6@ietf.org, 'RJ Atkinson' 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, 25 Jul 2011 13:36:29 -0000 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Monday, July 25, 2011 8:38 AM > To: Dan Wing > Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org > Subject: Re: PMTUD and MTU < 1280 >=20 >=20 > Le 23 juil. 2011 =E0 04:34, Dan Wing a =E9crit : >=20 > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf > Of > >> james woodyatt > >> Sent: Wednesday, July 20, 2011 2:44 PM > >> To: RJ Atkinson > >> Cc: ipv6@ietf.org > >> Subject: Re: PMTUD and MTU < 1280 > >> > >> On Jul 20, 2011, at 14:35 , RJ Atkinson wrote: > >> > >>> One hopes IPv6 implementers will be tolerant of IPv6 MTUs below > 1280 > >> bytes, because they do exist in the deployed world and aren't going > >> away anytime soon. > >> > >> Those hopes are not well placed. > >> > >> I am aware of at least one packet filter implementation-- which > might > >> be refined in the future, one hopes, to conform fully with RFC = 6092- > - > >> that treats this behavior as a resource exhaustion attack and drops > >> flows accordingly. > > > > Its behavior violates the last paragraph of Section 5 of RFC2460. >=20 > Violation _only in case_ of "an IPv6 packet that is sent to an IPv4 > destination". But how does one determine an IPv6 packet is, or isn't, going=20 to an IPv4 destination? I don't think it's possible to determine if there is an IPv6/IPv4 translator on the path. -d > If the destination is IPv6, a PMTU below 1280 remains therefore a > network failure. > This authorizes a simple IPv6 host to refuse packets beyond 1280 = octets > and to have no support of packet-reassembly. >=20 > Right? >=20 > Regards, > RD >=20 >=20 >=20 > > > > -d > > > >> > >> -- > >> james woodyatt > >> member of technical staff, core os networking > >> > >> > >> > >> = -------------------------------------------------------------------- > >> 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 dwing@cisco.com Mon Jul 25 11:50:22 2011 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 349CC21F8BA6 for ; Mon, 25 Jul 2011 11:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.127 X-Spam-Level: X-Spam-Status: No, score=-104.127 tagged_above=-999 required=5 tests=[AWL=-1.828, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqJ9E63lheeL for ; Mon, 25 Jul 2011 11:50:21 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD0F21F885C for ; Mon, 25 Jul 2011 11:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3275; q=dns/txt; s=iport; t=1311619821; x=1312829421; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=qE80Pdd0wpTCGEulb1utcyN4Yhe/ptNmHlX+KTmt9P0=; b=kkXZ5HB1yBGmmGv7QQ07u3gBStOFFSwWHiaOsTEAPWyJGnxd2IxWivY4 LjdEjTOFeF4mIHdbQfEjv9momm6hLi9+KmNoaGYiHj1BhckX2epVB4lA5 OInFmhyQXM1Z9eTYPBMWBmNS2k3KLFw64tTPaZwD8UN4usbDcA5R6g2hw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAA+6LU6rRDoG/2dsb2JhbAApCwEBAQECAQEBAQUMARtKCwUHAQQCCg8CBAEBNAcUBhIWDQ4IAQEFFw8Yl1uBa41sd4h8BKFYniSGPwSHJpxG X-IronPort-AV: E=Sophos;i="4.67,264,1309737600"; d="scan'208";a="6222556" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jul 2011 18:50:20 +0000 Received: from dwingWS (sjc-vpn5-1896.cisco.com [10.21.95.104]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6PIoJI0029568; Mon, 25 Jul 2011 18:50:19 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> <01d201cc48e1$0784d8d0$168e8a70$@com> <010826E2-D6DF-488D-B5C4-CE14E47C7EE7@free.fr> <04db01cc4acf$d9074600$8b15d200$@com> <98B94666-CD24-4D1A-B25F-F6238CC3708E@laposte.net> In-Reply-To: <98B94666-CD24-4D1A-B25F-F6238CC3708E@laposte.net> Subject: RE: PMTUD and MTU < 1280 Date: Mon, 25 Jul 2011 14:50:19 -0400 Message-ID: <071801cc4afb$b3ead4a0$1bc07de0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxK8k2ECM4NLCxCSWmRf6fnhcsRBAACKxZQ Content-Language: en-us Cc: ipv6@ietf.org, 'RJ Atkinson' 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, 25 Jul 2011 18:50:22 -0000 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] > Sent: Monday, July 25, 2011 1:43 PM > To: Dan Wing > Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org > Subject: Re: PMTUD and MTU < 1280 >=20 > Dan, >=20 > 1. > The point I wanted to check is just, slightly reformulated): > "May a simple IPv6 host have no support of packet-reassembly, and > simply accept packets up to 1280 octets." The earlier part of this thread was talking about sending; you're now bringing up receiving. IMO, if the packet came from IPv4, and that IPv4 network had a small MTU (e.g., 576) causing fragmentation, then such an IPv6 receiver will be unable to receive the packet. > In my understanding, the answer should be yes. > - This doesn't depend on whether sources know or not whether their > destinations are IPv6 or IPv4 only. > - If the destination happens to be IPv6, current RFC's don't permit > intermediate nodes to refuse 1280 packets as being too big. >=20 > 2. > How sources can be sure to have e2e transparency in IPv6 is a = different > question, but IMHO an important one. >=20 > For instance, if a destination address is obtained from the DNS in a > AAAA, with no A for the same URL and without any well-known prefix > indicating that there is an embedded-IPv4-address, I hope the source > can be guaranteed that e2e transparency won't be broken? I don't think so. DNS64 comes to mind. > I won't have time personally to contribute much on this, but the > subject would usefully be clarified, IMHO. The RFCs are pretty clear, IMO. Implementers don't want to read them all the way. -d > Regards, > RD >=20 >=20 > Le 25 juil. 2011 =E0 15:36, Dan Wing a =E9crit : >=20 > >>>> > >>>> ... > >>> > >>> Its behavior violates the last paragraph of Section 5 of RFC2460. > >> > >> Violation _only in case_ of "an IPv6 packet that is sent to an IPv4 > >> destination". > > > > But how does one determine an IPv6 packet is, or isn't, going > > to an IPv4 destination? I don't think it's possible to determine > > if there is an IPv6/IPv4 translator on the path. > > > > -d > > > > > >> If the destination is IPv6, a PMTU below 1280 remains therefore a > >> network failure. > >> This authorizes a simple IPv6 host to refuse packets beyond 1280 > octets > >> and to have no support of packet-reassembly. > >> > >> Right? > >> > >> Regards, > >> RD > >> > >> > >> > >>> > >>> -d > >>> > >>>> > >>>> -- > >>>> james woodyatt > >>>> member of technical staff, core os networking > >>>> > >>>> > >>>> > >>>> = ------------------------------------------------------------------ > -- > >>>> 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 despres.remi@laposte.net Mon Jul 25 10:43:02 2011 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 BB08B21F8C00 for ; Mon, 25 Jul 2011 10:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxMM29Mw8LUa for ; Mon, 25 Jul 2011 10:43:02 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0F39421F8BDC for ; Mon, 25 Jul 2011 10:43:01 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 30E7870000A0; Mon, 25 Jul 2011 19:43:00 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 9603C700009E; Mon, 25 Jul 2011 19:42:59 +0200 (CEST) X-SFR-UUID: 20110725174259614.9603C700009E@msfrf2117.sfr.fr Subject: Re: PMTUD and MTU < 1280 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <04db01cc4acf$d9074600$8b15d200$@com> Date: Mon, 25 Jul 2011 19:42:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98B94666-CD24-4D1A-B25F-F6238CC3708E@laposte.net> References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> <01d201cc48e1$0784d8d0$168e8a70$@com> <010826E2-D6DF-488D-B5C4-CE14E47C7EE7@free.fr> <04db01cc4acf$d9074600$8b15d200$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 25 Jul 2011 11:59:15 -0700 Cc: ipv6@ietf.org, 'RJ Atkinson' 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, 25 Jul 2011 17:43:02 -0000 Dan,=20 1. The point I wanted to check is just, slightly reformulated): "May a simple IPv6 host have no support of packet-reassembly, and simply = accept packets up to 1280 octets." In my understanding, the answer should be yes. - This doesn't depend on whether sources know or not whether their = destinations are IPv6 or IPv4 only.=20 - If the destination happens to be IPv6, current RFC's don't permit = intermediate nodes to refuse 1280 packets as being too big. 2.=20 How sources can be sure to have e2e transparency in IPv6 is a different = question, but IMHO an important one. For instance, if a destination address is obtained from the DNS in a = AAAA, with no A for the same URL and without any well-known prefix = indicating that there is an embedded-IPv4-address, I hope the source can = be guaranteed that e2e transparency won't be broken?=20 I won't have time personally to contribute much on this, but the subject = would usefully be clarified, IMHO. Regards, RD =20 Le 25 juil. 2011 =E0 15:36, Dan Wing a =E9crit : >>>>=20 >>>> ... >>>=20 >>> Its behavior violates the last paragraph of Section 5 of RFC2460. >>=20 >> Violation _only in case_ of "an IPv6 packet that is sent to an IPv4 >> destination". >=20 > But how does one determine an IPv6 packet is, or isn't, going=20 > to an IPv4 destination? I don't think it's possible to determine > if there is an IPv6/IPv4 translator on the path. >=20 > -d >=20 >=20 >> If the destination is IPv6, a PMTU below 1280 remains therefore a >> network failure. >> This authorizes a simple IPv6 host to refuse packets beyond 1280 = octets >> and to have no support of packet-reassembly. >>=20 >> Right? >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>>=20 >>> -d >>>=20 >>>>=20 >>>> -- >>>> james woodyatt >>>> member of technical staff, core os networking >>>>=20 >>>>=20 >>>>=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 >>> -------------------------------------------------------------------- >=20 From marka@isc.org Mon Jul 25 19:58:42 2011 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 F2E8121F8C21 for ; Mon, 25 Jul 2011 19:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0yzUhvEVlKe for ; Mon, 25 Jul 2011 19:58:41 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 01D8021F8C20 for ; Mon, 25 Jul 2011 19:58:40 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8B8725F999B; Tue, 26 Jul 2011 02:58:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (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 7AE2B216C88; Tue, 26 Jul 2011 02:57:54 +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 97231122A4CD; Tue, 26 Jul 2011 12:57:51 +1000 (EST) To: "Dan Wing" From: Mark Andrews References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> <01d201cc48e1$0784d8d0$168e8a70$@com> <010826E2-D6DF-488D-B5C4-CE14E47C7EE7@free.fr> <04db01cc4acf$d9074600$8b15d200$@com> <98B94666-CD24-4D1A-B25F-F6238CC3708E@laposte.net> <071801cc4afb$b3ead4a0$1bc07de0$@com> Subject: Re: PMTUD and MTU < 1280 In-reply-to: Your message of "Mon, 25 Jul 2011 14:50:19 -0400." <071801cc4afb$b3ead4a0$1bc07de0$@com> Date: Tue, 26 Jul 2011 12:57:51 +1000 Message-Id: <20110726025751.97231122A4CD@drugs.dv.isc.org> Cc: 'RJ Atkinson' , =?iso-8859-1?Q?'R=E9mi_Despr=E9s'?= , 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, 26 Jul 2011 02:58:42 -0000 In message <071801cc4afb$b3ead4a0$1bc07de0$@com>, "Dan Wing" writes: > > -----Original Message----- > > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] > > Sent: Monday, July 25, 2011 1:43 PM > > To: Dan Wing > > Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org > > Subject: Re: PMTUD and MTU < 1280 > > = > > > Dan, > > = > > > 1. > > The point I wanted to check is just, slightly reformulated): > > "May a simple IPv6 host have no support of packet-reassembly, and > > simply accept packets up to 1280 octets." > > The earlier part of this thread was talking about sending; you're > now bringing up receiving. > > IMO, if the packet came from IPv4, and that IPv4 network had a small > MTU (e.g., 576) causing fragmentation, then such an IPv6 receiver > will be unable to receive the packet. > > > In my understanding, the answer should be yes. > > - This doesn't depend on whether sources know or not whether their > > destinations are IPv6 or IPv4 only. > > - If the destination happens to be IPv6, current RFC's don't permit > > intermediate nodes to refuse 1280 packets as being too big. > > = > > > 2. > > How sources can be sure to have e2e transparency in IPv6 is a different > > question, but IMHO an important one. > > = > > > For instance, if a destination address is obtained from the DNS in a > > AAAA, with no A for the same URL and without any well-known prefix > > indicating that there is an embedded-IPv4-address, I hope the source > > can be guaranteed that e2e transparency won't be broken? > > I don't think so. DNS64 comes to mind. > > > I won't have time personally to contribute much on this, but the > > subject would usefully be clarified, IMHO. > > The RFCs are pretty clear, IMO. Implementers don't want to read > them all the way. And there is missing functionality in the API's. IPV6_USE_MIN_MTU doesn't force a fragment header to be added to packets less than 1280 octets for example and I'm not aware of any other API hooks which will do this. As a result a node still has to do some parts of path mtu discovery even if it doesn't want to and it is undesirable for it to do so. RFC 3542 This specification defines a mechanism to avoid path MTU discovery by sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger than the minimum MTU and this feature has been enabled the IP layer will fragment to the minimum MTU. To control the policy about path MTU discovery, applications can use the IPV6_USE_MIN_MTU socket option. A application should be able to send a IPv6/UDP packet, without resorting to using raw sockets, and not have a PTB be generated as a result. Mark > -d > > > > Regards, > > RD > > = > > > = > > > Le 25 juil. 2011 =E0 15:36, Dan Wing a =E9crit : > > = > > > >>>> > > >>>> ... > > >>> > > >>> Its behavior violates the last paragraph of Section 5 of RFC2460. > > >> > > >> Violation _only in case_ of "an IPv6 packet that is sent to an IPv4 > > >> destination". > > > > > > But how does one determine an IPv6 packet is, or isn't, going > > > to an IPv4 destination? I don't think it's possible to determine > > > if there is an IPv6/IPv4 translator on the path. > > > > > > -d > > > > > > > > >> If the destination is IPv6, a PMTU below 1280 remains therefore a > > >> network failure. > > >> This authorizes a simple IPv6 host to refuse packets beyond 1280 > > octets > > >> and to have no support of packet-reassembly. > > >> > > >> Right? > > >> > > >> Regards, > > >> RD > > >> > > >> > > >> > > >>> > > >>> -d > > >>> > > >>>> > > >>>> -- > > >>>> james woodyatt > > >>>> member of technical staff, core os networking > > >>>> > > >>>> > > >>>> > > >>>> ------------------------------------------------------------------ > > -- > > >>>> 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 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From despres.remi@laposte.net Mon Jul 25 14:47:32 2011 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 B77B521F86BF for ; Mon, 25 Jul 2011 14:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkdOIvVWt-87 for ; Mon, 25 Jul 2011 14:47:32 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6996521F8BDC for ; Mon, 25 Jul 2011 14:47:29 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3714F940067; Mon, 25 Jul 2011 23:47:22 +0200 (CEST) Subject: Re: PMTUD and MTU < 1280 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <071801cc4afb$b3ead4a0$1bc07de0$@com> Date: Mon, 25 Jul 2011 23:47:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> <01d201cc48e1$0784d8d0$168e8a70$@com> <010826E2-D6DF-488D-B5C4-CE14E47C7EE7@free.fr> <04db01cc4acf$d9074600$8b15d200$@com> <98B94666-CD24-4D1A-B25F-F6238CC3708E@laposte.net> <071801cc4afb$b3ead4a0$1bc07de0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 26 Jul 2011 01:04:10 -0700 Cc: 6man 6man-wg 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, 25 Jul 2011 21:47:32 -0000 Le 25 juil. 2011 =E0 20:50, Dan Wing a =E9crit : >> -----Original Message----- >> From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] >> Sent: Monday, July 25, 2011 1:43 PM >> To: Dan Wing >> Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org >> Subject: Re: PMTUD and MTU < 1280 >>=20 >> Dan, >>=20 >> 1. >> The point I wanted to check is just, slightly reformulated): >> "May a simple IPv6 host have no support of packet-reassembly, and >> simply accept packets up to 1280 octets." >=20 > The earlier part of this thread was talking about sending; you're > now bringing up receiving. Yes. The point made is about the difference between IPv6-to-IPv4 and = IPv6-to-IPv6 PMTU's (an IPv6 PTB with MTU < 1280 remaining excluded, = AFAIK, if both source and destination are IPv6.)=20 > IMO, if the packet came from IPv4, and that IPv4 network had a small > MTU (e.g., 576) causing fragmentation, then such an IPv6 receiver > will be unable to receive the packet. The point is only about IPv6 to IPv6. >> In my understanding, the answer should be yes. >> - This doesn't depend on whether sources know or not whether their >> destinations are IPv6 or IPv4 only. >> - If the destination happens to be IPv6, current RFC's don't permit >> intermediate nodes to refuse 1280 packets as being too big. >>=20 >> 2. >> How sources can be sure to have e2e transparency in IPv6 is a = different >> question, but IMHO an important one. >> For instance, if a destination address is obtained from the DNS in a >> AAAA, with no A for the same URL and without any well-known prefix >> indicating that there is an embedded-IPv4-address, I hope the source >> can be guaranteed that e2e transparency won't be broken? >=20 > I don't think so. DNS64 comes to mind. In my understanding, a host that requests both for A's and AAAA's, and = receives no A, knows it talks to an IPv6-only host, with or without = DNS64. There may be other ways to know it, e.g. for some IPv6-only sensors = talking only with IPv6-capable dedicated servers.=20 In any case, I have no problem with leaving this subject, as many others = may be found more urgent. Thanks, RD >> I won't have time personally to contribute much on this, but the >> subject would usefully be clarified, IMHO. >=20 > The RFCs are pretty clear, IMO. Implementers don't want to read > them all the way. >=20 > -d >=20 >=20 >> Regards, >> RD >>=20 >>=20 >> Le 25 juil. 2011 =E0 15:36, Dan Wing a =E9crit : >>=20 >>>>>>=20 >>>>>> ... >>>>>=20 >>>>> Its behavior violates the last paragraph of Section 5 of RFC2460. >>>>=20 >>>> Violation _only in case_ of "an IPv6 packet that is sent to an IPv4 >>>> destination". >>>=20 >>> But how does one determine an IPv6 packet is, or isn't, going >>> to an IPv4 destination? I don't think it's possible to determine >>> if there is an IPv6/IPv4 translator on the path. >>>=20 >>> -d >>>=20 >>>=20 >>>> If the destination is IPv6, a PMTU below 1280 remains therefore a >>>> network failure. >>>> This authorizes a simple IPv6 host to refuse packets beyond 1280 >> octets >>>> and to have no support of packet-reassembly. >>>>=20 >>>> Right? >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> -d >>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> james woodyatt >>>>>> member of technical staff, core os networking >>>>>>=20 >>>>>>=20 >>>>>>=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 >>>>> = ------------------------------------------------------------------- >> - >>>=20 >=20 >=20 From bob.hinden@gmail.com Tue Jul 26 04:55:50 2011 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 A80F421F8AEE for ; Tue, 26 Jul 2011 04:55:50 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-kvPE3bO0CU for ; Tue, 26 Jul 2011 04:55:49 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C360421F8ADC for ; Tue, 26 Jul 2011 04:55:49 -0700 (PDT) Received: by yie30 with SMTP id 30so229921yie.31 for ; Tue, 26 Jul 2011 04:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=z94NwYj/lkmWGi0H+2sZbzbA2uJIk9DGf7nEDQd2veQ=; b=hIo0pCy7j34FmqpV2YHZ/7AerPz/bCqfqURugN5NQ69JTdnKHxjkl5rf4W/6m66C5g lla7NFj54UK5o5eXZXEIwmLbZUzh/o2Hkegyt01Qk31oxWgnj0ztS58C7ZalH9b2bphx rJGid0FdeiE3HbXjQDebfPjSxP+7YkWJvf4vg= Received: by 10.142.55.7 with SMTP id d7mr3772971wfa.440.1311681348926; Tue, 26 Jul 2011 04:55:48 -0700 (PDT) Received: from dhcp-4314.meeting.ietf.org (dhcp-4314.meeting.ietf.org [130.129.67.20]) by mx.google.com with ESMTPS id r8sm499548pbd.28.2011.07.26.04.55.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 04:55:47 -0700 (PDT) Subject: Re: Need Jabber Scribe and Minute taker for 6man session Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Tue, 26 Jul 2011 07:55:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <828AA295-3471-4F60-AF53-7229430204EC@gmail.com> References: To: 6man Mailing List X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden 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, 26 Jul 2011 11:55:50 -0000 We still need volunteers for a meeting taker and jabber scribe. Bob & Brian On Jul 24, 2011, at 1:03 PM, Bob Hinden wrote: > Hi, >=20 > The 6man chairs are looking for volunteers to take minutes and for = jabber scribes. If you are interested please let the chairs know. It's = your opportunity to contribute to the overall quality of the meeting = materials. >=20 > Thanks, > Bob & Brian >=20 From arifumi@nttv6.net Tue Jul 26 13:42:13 2011 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 6E6F121F86D8 for ; Tue, 26 Jul 2011 13:42:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0GOc0uLMSi0 for ; Tue, 26 Jul 2011 13:42:12 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 554A521F86AD for ; Tue, 26 Jul 2011 13:42:12 -0700 (PDT) Received: from [127.0.0.1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.4/8.14.4) with ESMTP id p6QKbhJR058214; Wed, 27 Jul 2011 05:37:44 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Privacy Bit in the policy table Re: rfc3484-bis issue 2: privacy addresses Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <971D6F0B-9109-42EC-ABE0-1A5E3AB99741@nttv6.net> Date: Wed, 27 Jul 2011 05:37:43 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8CCFAD4E-E1C8-4B23-80C0-4177AA9E227C@nttv6.net> References: <5440EBA2-DDA9-46B9-B417-68148C6382CD@ecs.soton.ac.uk>, <4FD1E7CD248BF84F86BD4814EDDDBCC1513D42BE0C@EUSAACMS0703.eamcs.ericsson.se> <971D6F0B-9109-42EC-ABE0-1A5E3AB99741@nttv6.net> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) Cc: Tim Chown , Suresh Krishnan 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, 26 Jul 2011 20:42:13 -0000 All, let me re-post the candidate extended policy table format below. > For example, if we extend the policy table to have Privacy column like = below, >=20 > Prefix Precedence Label Privacy > ::1/128 60 0 OFF > fc00::/7 50 1 OFF > ::/0 40 2 ON > ::ffff:0:0/96 30 3 OFF > 2002::/16 20 4 OFF > 2001::/32 10 5 OFF > ::/96 1 10 OFF > fec0::/10 1 11 OFF >=20 > a temporary address will be used only when a destination address = longest matches ::/0 entry in this table. This is rather simple form of privacy extension control. Only the destination prefix determines whether the privacy extension for = the source prefix should be used or not. In this case, even if a host has multiple prefixes, the source prefix = does not have effect on it. It seems to me that this satisfies the needs we discussed just now. If we want to use both destination and source prefixes to control the = usage of privacy extension, we need additional mechanisms like Label. Or, any other implementation form ? On 2011/06/29, at 14:28, Arifumi Matsumoto wrote: > Hi Suresh, >=20 > On 2011/06/29, at 4:32, Suresh Krishnan wrote: >=20 >> Hi Tim, >> There is already a programmatic switch for this in RFC5014 = (IPV6_PREFER_SRC_TMP/IPV6_PREFER_SRC_PUBLIC). Applications wishing to = override system policy may do so by using this API. >=20 > Yes. An application can control which kind of address to choose by = that API. >=20 > Our question is whether we should have a way to configure host-wide = policy about when to use temporary address or not. >=20 > For example, if we extend the policy table to have Privacy column like = below, >=20 > Prefix Precedence Label Privacy > ::1/128 60 0 OFF > fc00::/7 50 1 OFF > ::/0 40 2 ON > ::ffff:0:0/96 30 3 OFF > 2002::/16 20 4 OFF > 2001::/32 10 5 OFF > ::/96 1 10 OFF > fec0::/10 1 11 OFF >=20 > a temporary address will be used only when a destination address = longest matches ::/0 entry in this table. >=20 > Please note that this is about address selection and not about whether = a host should generate temporary address for a received RA prefix. >=20 > As Tim mentioned, if we agree to have this kind of new tool, after = that, we should discuss about policy distribution of this added column. >=20 > Best regards, >=20 >>=20 >> Cheers >> Suresh >>=20 >> ________________________________________ >> From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] On Behalf Of Tim = Chown [tjc@ecs.soton.ac.uk] >> Sent: Tuesday, June 28, 2011 10:38 AM >> To: ipv6@ietf.org >> Subject: rfc3484-bis issue 2: privacy addresses >>=20 >> The second issue is surrounding IPv6 privacy addresses (RFC4941). >>=20 >> Section 3.1 of RFC4941 states: >> "this document assumes that when a node initiates outgoing >>=20 >> communication, temporary addresses can be given preference over >> public addresses when the device is configured to do so. >> [ADDR_SELECT] = mandates implementations to provide a mechanism, which >> allows an application to configure its preference for temporary >> addresses over public addresses. It also allows for an >> implementation to prefer temporary addresses by default, so that the >> connections initiated by the node can use temporary addresses = without >> requiring application-specific enablement." >>=20 >>=20 >> This suggests there should be a mechanism for a host to choose = whether to use temporary or public addresses. RFC3484 talks about = preferring temporary or public addresses in Rule 7. In practice, = implementations seem to prefer privacy addresses (to initiate = connections) when they are enabled. At the moment, RFC3484-bis says = nothing different or new for privacy addresses. >>=20 >>=20 >> Should there be a configuration switch for privacy extensions = somewhere, and if so how is this controlled - locally or via a policy = distribution mechanism? >>=20 >>=20 >> In IETF80, the suggestion to 'tell' a host whether it should use = privacy addresses by using an RA flag was not well received. There was = at least one comment at IETF80 that the privilege to carry the traffic = and the privilege to turn on/off the privacy extension should be = different. >>=20 >>=20 >> Comments please. >>=20 >>=20 >> Tim >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > -- > Arifumi Matsumoto > NGN System Architecture Project > NTT Service Integration Laboratories > E-mail: arifumi@nttv6.net > TEL +81-422-59-3334 FAX +81-422-59-6364 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From arifumi@nttv6.net Tue Jul 26 13:47:08 2011 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 E725D11E80B7 for ; Tue, 26 Jul 2011 13:47:07 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4dV+rAFGlvJ for ; Tue, 26 Jul 2011 13:47:06 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 16C5911E80AF for ; Tue, 26 Jul 2011 13:47:00 -0700 (PDT) Received: from [127.0.0.1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.4/8.14.4) with ESMTP id p6QKjhOM058266 for ; Wed, 27 Jul 2011 05:45:44 +0900 (JST) (envelope-from arifumi@nttv6.net) From: Arifumi Matsumoto Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13-545977957 Subject: Re: Privacy Bit in the policy table Re: rfc3484-bis issue 2: privacy addresses Date: Wed, 27 Jul 2011 05:45:43 +0900 In-Reply-To: <8CCFAD4E-E1C8-4B23-80C0-4177AA9E227C@nttv6.net> To: ipv6@ietf.org References: <5440EBA2-DDA9-46B9-B417-68148C6382CD@ecs.soton.ac.uk>, <4FD1E7CD248BF84F86BD4814EDDDBCC1513D42BE0C@EUSAACMS0703.eamcs.ericsson.se> <971D6F0B-9109-42EC-ABE0-1A5E3AB99741@nttv6.net> <8CCFAD4E-E1C8-4B23-80C0-4177AA9E227C@nttv6.net> Message-Id: X-Mailer: Apple Mail (2.1084) 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, 26 Jul 2011 20:47:08 -0000 --Apple-Mail-13-545977957 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And the corresponding distributing protocol format was already there in = the previous version. :) http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00 We just dropped this bit in the latest -01 version. Best regards, On 2011/07/27, at 5:37, Arifumi Matsumoto wrote: > All, >=20 > let me re-post the candidate extended policy table format below. >=20 >> For example, if we extend the policy table to have Privacy column = like below, >>=20 >> Prefix Precedence Label Privacy >> ::1/128 60 0 OFF >> fc00::/7 50 1 OFF >> ::/0 40 2 ON >> ::ffff:0:0/96 30 3 OFF >> 2002::/16 20 4 OFF >> 2001::/32 10 5 OFF >> ::/96 1 10 OFF >> fec0::/10 1 11 OFF >>=20 >> a temporary address will be used only when a destination address = longest matches ::/0 entry in this table. >=20 > This is rather simple form of privacy extension control. > Only the destination prefix determines whether the privacy extension = for the source prefix should be used or not. > In this case, even if a host has multiple prefixes, the source prefix = does not have effect on it. >=20 > It seems to me that this satisfies the needs we discussed just now. >=20 >=20 > If we want to use both destination and source prefixes to control the = usage of privacy extension, > we need additional mechanisms like Label. >=20 >=20 > Or, any other implementation form ? >=20 >=20 > On 2011/06/29, at 14:28, Arifumi Matsumoto wrote: >=20 >> Hi Suresh, >>=20 >> On 2011/06/29, at 4:32, Suresh Krishnan wrote: >>=20 >>> Hi Tim, >>> There is already a programmatic switch for this in RFC5014 = (IPV6_PREFER_SRC_TMP/IPV6_PREFER_SRC_PUBLIC). Applications wishing to = override system policy may do so by using this API. >>=20 >> Yes. An application can control which kind of address to choose by = that API. >>=20 >> Our question is whether we should have a way to configure host-wide = policy about when to use temporary address or not. >>=20 >> For example, if we extend the policy table to have Privacy column = like below, >>=20 >> Prefix Precedence Label Privacy >> ::1/128 60 0 OFF >> fc00::/7 50 1 OFF >> ::/0 40 2 ON >> ::ffff:0:0/96 30 3 OFF >> 2002::/16 20 4 OFF >> 2001::/32 10 5 OFF >> ::/96 1 10 OFF >> fec0::/10 1 11 OFF >>=20 >> a temporary address will be used only when a destination address = longest matches ::/0 entry in this table. >>=20 >> Please note that this is about address selection and not about = whether a host should generate temporary address for a received RA = prefix. >>=20 >> As Tim mentioned, if we agree to have this kind of new tool, after = that, we should discuss about policy distribution of this added column. >>=20 >> Best regards, >>=20 >>>=20 >>> Cheers >>> Suresh >>>=20 >>> ________________________________________ >>> From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] On Behalf Of Tim = Chown [tjc@ecs.soton.ac.uk] >>> Sent: Tuesday, June 28, 2011 10:38 AM >>> To: ipv6@ietf.org >>> Subject: rfc3484-bis issue 2: privacy addresses >>>=20 >>> The second issue is surrounding IPv6 privacy addresses (RFC4941). >>>=20 >>> Section 3.1 of RFC4941 states: >>> "this document assumes that when a node initiates outgoing >>>=20 >>> communication, temporary addresses can be given preference over >>> public addresses when the device is configured to do so. >>> [ADDR_SELECT] = mandates implementations to provide a mechanism, which >>> allows an application to configure its preference for temporary >>> addresses over public addresses. It also allows for an >>> implementation to prefer temporary addresses by default, so that the >>> connections initiated by the node can use temporary addresses = without >>> requiring application-specific enablement." >>>=20 >>>=20 >>> This suggests there should be a mechanism for a host to choose = whether to use temporary or public addresses. RFC3484 talks about = preferring temporary or public addresses in Rule 7. In practice, = implementations seem to prefer privacy addresses (to initiate = connections) when they are enabled. At the moment, RFC3484-bis says = nothing different or new for privacy addresses. >>>=20 >>>=20 >>> Should there be a configuration switch for privacy extensions = somewhere, and if so how is this controlled - locally or via a policy = distribution mechanism? >>>=20 >>>=20 >>> In IETF80, the suggestion to 'tell' a host whether it should use = privacy addresses by using an RA flag was not well received. There was = at least one comment at IETF80 that the privilege to carry the traffic = and the privilege to turn on/off the privacy extension should be = different. >>>=20 >>>=20 >>> Comments please. >>>=20 >>>=20 >>> Tim >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> -- >> Arifumi Matsumoto >> NGN System Architecture Project >> NTT Service Integration Laboratories >> E-mail: arifumi@nttv6.net >> TEL +81-422-59-3334 FAX +81-422-59-6364 >>=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 > -------------------------------------------------------------------- --Apple-Mail-13-545977957 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii htt= p://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00
We just dropped this bit in the latest -01 = version.

Best = regards,

On 2011/07/27, at 5:37, = Arifumi Matsumoto wrote:

All,

let me re-post the candidate extended = policy table format below.

For example, = if we extend the policy table to have Privacy column like = below,

=        Prefix =        Precedence Label =  Privacy
=        ::1/128 =             &n= bsp; 60     0 =      OFF
       fc00::/7 =             &n= bsp;50     1 =      OFF
       ::/0 =             &n= bsp;    40     2 =       ON
       ::ffff:0:0/96 =         30 =     3 =      OFF
       2002::/16 =             20=     4 =      OFF
       2001::/32 =             10=     5 =      OFF
       ::/96 =             &n= bsp;    1    10 =      OFF
       fec0::/10 =             &n= bsp;1    11 =      OFF

a temporary = address will be used only when a destination address longest matches = ::/0 entry in this table.

This is rather simple form = of privacy extension control.
Only the destination prefix determines = whether the privacy extension for the source prefix should be used or = not.
In this case, even if a host has multiple prefixes, the source = prefix does not have effect on it.

It seems to me that this = satisfies the needs we discussed just now.


If we want to use = both destination and source prefixes to control the usage of privacy = extension,
we need additional mechanisms like Label.


Or, = any other implementation form ?


On 2011/06/29, at 14:28, = Arifumi Matsumoto wrote:

Hi = Suresh,

On 2011/06/29, = at 4:32, Suresh Krishnan wrote:

Hi Tim,
There is already a programmatic = switch for this in RFC5014 (IPV6_PREFER_SRC_TMP/IPV6_PREFER_SRC_PUBLIC). = Applications wishing to override system policy may do so by using this = API.

Yes. An = application can control which kind of address to choose by that = API.

Our question is = whether we should have a way to configure host-wide policy about when to = use temporary address or not.

For example, if = we extend the policy table to have Privacy column like = below,

=        Prefix =        Precedence Label =  Privacy
=        ::1/128 =             &n= bsp; 60     0 =      OFF
       fc00::/7 =             &n= bsp;50     1 =      OFF
       ::/0 =             &n= bsp;    40     2 =       ON
       ::ffff:0:0/96 =         30 =     3 =      OFF
       2002::/16 =             20=     4 =      OFF
       2001::/32 =             10=     5 =      OFF
       ::/96 =             &n= bsp;    1    10 =      OFF
       fec0::/10 =             &n= bsp;1    11 =      OFF

a temporary = address will be used only when a destination address longest matches = ::/0 entry in this table.

Please note = that this is about address selection and not about whether a host should = generate temporary address for a received RA = prefix.

As Tim = mentioned, if we agree to have this kind of new tool, after that, we = should discuss about policy distribution of this added = column.

Best = regards,


Cheers
Suresh

________________________________________
From: ipv6-bounces@ietf.org = [ipv6-bounces@ietf.org] On Behalf Of Tim Chown = [tjc@ecs.soton.ac.uk]
Sent: Tuesday, June 28, 2011 = 10:38 AM
To: ipv6@ietf.org
Subject: = rfc3484-bis issue 2: privacy = addresses

The second issue is surrounding = IPv6 privacy addresses = (RFC4941).

Section 3.1 of RFC4941 = states:
"this document assumes that when a node initiates = outgoing

communication, temporary = addresses can be given preference = over
public addresses when the device is configured to do = so.
[ADDR_SELECT<http://tools.i= etf.org/html/rfc4941#ref-ADDR_SELECT>] mandates implementations = to provide a mechanism, which
allows an application to = configure its preference for = temporary
addresses over public = addresses.  It also allows for = an
implementation to prefer temporary addresses by default, = so that the
connections initiated by the = node can use temporary addresses = without
requiring application-specific = enablement."


This suggests there should be a = mechanism for a host to choose whether to use temporary or public = addresses.  RFC3484 talks about preferring temporary or public = addresses in Rule 7.  In practice, implementations seem to prefer = privacy addresses (to initiate connections) when they are enabled. =  At the moment, RFC3484-bis says nothing different or new for = privacy addresses.


Should there be a configuration = switch for privacy extensions somewhere, and if so how is this = controlled - locally or via a policy distribution = mechanism?


In IETF80, the suggestion to = 'tell' a host whether it should use privacy addresses by using an RA = flag was not well received. There was at least one comment at IETF80 = that the privilege to carry the traffic and the privilege to turn on/off = the privacy extension should be = different.


Comments = please.


Tim

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


--
Arifumi = Matsumoto
NGN System = Architecture Project
NTT = Service Integration Laboratories
E-mail: arifumi@nttv6.net
TEL +81-422-59-3334 FAX = +81-422-59-6364

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

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

<= /div>
= --Apple-Mail-13-545977957-- From alexandru.petrescu@gmail.com Tue Jul 26 14:10:37 2011 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 0FFB621F87C9 for ; Tue, 26 Jul 2011 14:10:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zK+kXrO6L3D for ; Tue, 26 Jul 2011 14:10:36 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 230AB21F8639 for ; Tue, 26 Jul 2011 14:10:36 -0700 (PDT) Received: by gwb20 with SMTP id 20so721134gwb.31 for ; Tue, 26 Jul 2011 14:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Btlp8qrtAOUYNTlXma159wa06F87vMv6/DKoXK9O3PE=; b=oI4OVoXqLvauSn/456qGtm6roeFFBFt1uI1ruSGJ6Thkp5z+96/tQeNVhZA3/n+PvI QlqM91oZ2fsn5OGFjhW652ePgIYLnevdyiqDfT/rdwRqNvdGWi1/8FqgRK61bD91A0uk kpQVIe8kBsm5DQ3baUSNlkgyjMRdjvFFVBXp0= Received: by 10.142.73.8 with SMTP id v8mr4338320wfa.112.1311714623805; Tue, 26 Jul 2011 14:10:23 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id g5sm542438wfh.10.2011.07.26.14.10.22 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 14:10:23 -0700 (PDT) Message-ID: <4E2F2D3C.5070200@gmail.com> Date: Tue, 26 Jul 2011 23:10:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipv6@ietf.org Subject: 2^64 is 10s of trillions (not just trillions) 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, 26 Jul 2011 21:10:37 -0000 2^64 is 10s of trillions (not just trillions) and only for anglo-saxons. 2^64 is exabytes of memory (not giga, nor tera, nor peta). I am not sure you look at adapting nd for these figures. Alex From jari.arkko@piuha.net Tue Jul 26 14:47:50 2011 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 3424C21F8797 for ; Tue, 26 Jul 2011 14:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-HxXeUl8bnp for ; Tue, 26 Jul 2011 14:47:49 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8E01521F8793 for ; Tue, 26 Jul 2011 14:47:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 099A62CE66 for ; Wed, 27 Jul 2011 00:47:48 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B468eTvr5wEu for ; Wed, 27 Jul 2011 00:47:47 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 303E52CC4B for ; Wed, 27 Jul 2011 00:47:47 +0300 (EEST) Message-ID: <4E2F3602.2070201@piuha.net> Date: Tue, 26 Jul 2011 17:47:46 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF IPv6 Mailing List Subject: pointer to the core draft 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, 26 Jul 2011 21:47:50 -0000 I mentioned this draft on the mike line today: http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors Implementing Tiny COAP Sensors The authors are developing COAP and IPv6-based sensor networks for environments where lightweight implementations, long battery lifetimes, and minimal management burden are important. The memo shows how different communication models supported by COAP affect implementation complexity and energy consumption, far more so than mere changes in message syntax. Our prototype implements a multicast-based IPv6, UDP, COAP, and XML protocol stack in less than 50 assembler instructions. While this extremely minimal implementation is suitable only for limited applications and makes a number of assumptions, the general conclusions point to need for further work in developing the COAP multicast and observation frameworks. Comments appreciated. Jari From alexandru.petrescu@gmail.com Tue Jul 26 15:04:04 2011 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 85CC811E8136 for ; Tue, 26 Jul 2011 15:04:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O2GAAh1kgCU for ; Tue, 26 Jul 2011 15:04:03 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90A4211E812D for ; Tue, 26 Jul 2011 15:04:03 -0700 (PDT) Received: by gxk19 with SMTP id 19so764411gxk.31 for ; Tue, 26 Jul 2011 15:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=QwzzuMzmfetWWlzfrwSWvCjnyphMpIAtoAe0hEjrRy0=; b=UVRNVYF+w0bUMt0IJJFrXPOG33R/Su17dJqnS9LBbZLI6QD9BRLEIODjql+KWE0ii2 Vyh1OR2mxFGI3/xhWXsYnMvU6VskFVLk7bK+ux7S3TvvAs1vR1zgD5q3QALvstPJHlld OILyIBf6JOgRVcWc+iNx6cW9eJqgFC3cCn1ck= Received: by 10.142.248.30 with SMTP id v30mr4247251wfh.27.1311717842858; Tue, 26 Jul 2011 15:04:02 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id t20sm565460wfe.12.2011.07.26.15.04.01 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 15:04:02 -0700 (PDT) Message-ID: <4E2F39CF.20005@gmail.com> Date: Wed, 27 Jul 2011 00:03:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipv6@ietf.org Subject: comments on ipv6-over-mstp 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, 26 Jul 2011 22:04:04 -0000 Comments on draft draft-lynn-6man-6lobac-00: - needs a section on multicast address mapping; it may not be straightforward: it may need to _not_ send all ip-multicasted messages to 255 link-layer address: the solicited-node multicast address includes the octet address (as opposed to eg ethernet 6octets) hence it could send it to that octet address (not 255). - 1 Poll for Master - sounds as RS, why not mapping one into another? 2 Reply to Poll for Master sounds as RA, same. - MLD mapping could be as well useful. Alex From joelja@bogus.com Tue Jul 26 15:05:37 2011 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 21A1E11E812D for ; Tue, 26 Jul 2011 15:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w3mhrxDWoCM for ; Tue, 26 Jul 2011 15:05:36 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 96A2411E80A2 for ; Tue, 26 Jul 2011 15:05:31 -0700 (PDT) Received: from [IPv6:2001:df8::80:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:80:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6QM5RgA048906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jul 2011 22:05:28 GMT (envelope-from joelja@bogus.com) Subject: Re: 2^64 is 10s of trillions (not just trillions) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <4E2F2D3C.5070200@gmail.com> Date: Tue, 26 Jul 2011 18:05:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2F2D3C.5070200@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Tue, 26 Jul 2011 22:05:28 +0000 (UTC) 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, 26 Jul 2011 22:05:37 -0000 If you're commenting on v6nd draft I don't think we have any intention = of connecting ~1.8 * 10^19 hosts to a subnet... On Jul 26, 2011, at 5:10 PM, Alexandru Petrescu wrote: > 2^64 is 10s of trillions (not just trillions) and only for = anglo-saxons. >=20 > 2^64 is exabytes of memory (not giga, nor tera, nor peta). >=20 > I am not sure you look at adapting nd for these figures. >=20 > Alex > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From alexandru.petrescu@gmail.com Tue Jul 26 15:09:28 2011 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 7312B21F85FF for ; Tue, 26 Jul 2011 15:09: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_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOwi0nh2jFy5 for ; Tue, 26 Jul 2011 15:09:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04F8E21F85A7 for ; Tue, 26 Jul 2011 15:09:24 -0700 (PDT) Received: by gwb20 with SMTP id 20so769441gwb.31 for ; Tue, 26 Jul 2011 15:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vTB9cBkZM2C13oeskA5ETendHLgVnXgfsIrVJQcnD5g=; b=TAyK20RhCUXNZVvlyl6ncHaYxbN2lsEZoDNY/5HB3tEh7N8LNmu4m09Zqq+X8l6EGG VgaOgPRkQfFm856Fte6OmDiBBg49rbc5TE7IrkGC5uuorWS7AHxxDfIonvpuQgxOQ7mj zJru9qFlW9gKNdfKVHuETw3JhVg6D6dnQxAdY= Received: by 10.142.188.17 with SMTP id l17mr4244758wff.156.1311718164366; Tue, 26 Jul 2011 15:09:24 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id t20sm572004wfe.0.2011.07.26.15.09.23 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 15:09:23 -0700 (PDT) Message-ID: <4E2F3B10.9030304@gmail.com> Date: Wed, 27 Jul 2011 00:09:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joel Jaeggli Subject: Re: 2^64 is 10s of trillions (not just trillions) References: <4E2F2D3C.5070200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 26 Jul 2011 22:09:28 -0000 Le 27/07/2011 00:05, Joel Jaeggli a écrit : > If you're commenting on v6nd draft I don't think we have any intention of connecting ~1.8 * 10^19 hosts to a subnet... Yes, commenting on the v6nd draft. Listening to the disxcussion it so sounde to me that these were ND optimizations such as to support 2^64 nodes in a subnet. Alex > > > On Jul 26, 2011, at 5:10 PM, Alexandru Petrescu wrote: > >> 2^64 is 10s of trillions (not just trillions) and only for anglo-saxons. >> >> 2^64 is exabytes of memory (not giga, nor tera, nor peta). >> >> I am not sure you look at adapting nd for these figures. >> >> Alex >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From joelja@bogus.com Tue Jul 26 15:20:24 2011 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 305C021F84D5 for ; Tue, 26 Jul 2011 15:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1fcQyC1KbUA for ; Tue, 26 Jul 2011 15:20:23 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C944D228006 for ; Tue, 26 Jul 2011 15:20:22 -0700 (PDT) Received: from [IPv6:2001:df8::80:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:80:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6QMKIiY049944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jul 2011 22:20:19 GMT (envelope-from joelja@bogus.com) Subject: Re: 2^64 is 10s of trillions (not just trillions) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Joel Jaeggli In-Reply-To: <4E2F3B10.9030304@gmail.com> Date: Tue, 26 Jul 2011 18:20:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77C38E1C-219F-4956-B379-4F9E5253C122@bogus.com> References: <4E2F2D3C.5070200@gmail.com> <4E2F3B10.9030304@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Tue, 26 Jul 2011 22:20:19 +0000 (UTC) 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, 26 Jul 2011 22:20:24 -0000 On Jul 26, 2011, at 6:09 PM, Alexandru Petrescu wrote: > Le 27/07/2011 00:05, Joel Jaeggli a =E9crit : >> If you're commenting on v6nd draft I don't think we have any = intention of connecting ~1.8 * 10^19 hosts to a subnet... >=20 > Yes, commenting on the v6nd draft. >=20 > Listening to the disxcussion it so sounde to me that these were ND = optimizations such as to support 2^64 nodes in a subnet. goal is: to retain entries for things that we know under duress =09 to be able to learn new addresses when that router is resource = constrained by prioritizing activities. the implicit assumption is that memory is a limited commodity and there = are higher priority things for the control plane processor to be doing = instead of discovering hosts that don't exist due to incoming unicast = packets... =09 > Alex >=20 >>=20 >>=20 >> On Jul 26, 2011, at 5:10 PM, Alexandru Petrescu wrote: >>=20 >>> 2^64 is 10s of trillions (not just trillions) and only for = anglo-saxons. >>>=20 >>> 2^64 is exabytes of memory (not giga, nor tera, nor peta). >>>=20 >>> I am not sure you look at adapting nd for these figures. >>>=20 >>> Alex >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>=20 >=20 From kerlyn2001@gmail.com Tue Jul 26 15:30:48 2011 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 1E23C21F86BB for ; Tue, 26 Jul 2011 15:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVMtAm5wYtxT for ; Tue, 26 Jul 2011 15:30:46 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91821F86AE for ; Tue, 26 Jul 2011 15:30:46 -0700 (PDT) Received: by pzk6 with SMTP id 6so1473633pzk.26 for ; Tue, 26 Jul 2011 15:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+Yym6fYkueF9acWM4TphuSqaH01rZy6FiRJe08xa848=; b=lnl1zTm+Hz7x3BPUPAx1cvN0hSgFT0MGUuLG4tdxVbdZNWUPLid1aez7ZmC75GQUGy EwqMy72egU8x05GkAv/bwpHcBRguPrPB3W9S39JqkWvzGKoEYfxQJ1WP+NjaSlQ4zhHj IfPsmhaibQmcw4bW27jM/BAgXeIlP/ja60IKM= MIME-Version: 1.0 Received: by 10.68.64.103 with SMTP id n7mr11440662pbs.229.1311719444149; Tue, 26 Jul 2011 15:30:44 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.68.42.167 with HTTP; Tue, 26 Jul 2011 15:30:44 -0700 (PDT) In-Reply-To: <4E2F39CF.20005@gmail.com> References: <4E2F39CF.20005@gmail.com> Date: Tue, 26 Jul 2011 18:30:44 -0400 X-Google-Sender-Auth: 9igglzYCTBelhz5BNbQUH7LTAJo Message-ID: Subject: Re: comments on ipv6-over-mstp From: Kerry Lynn To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=bcaec5304f3783753704a9007b09 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, 26 Jul 2011 22:30:48 -0000 --bcaec5304f3783753704a9007b09 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 26, 2011 at 6:03 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Comments on draft draft-lynn-6man-6lobac-00: > > - needs a section on multicast address mapping; it may not be > straightforward: it may need to _not_ send all ip-multicasted messages to > 255 link-layer address: the solicited-node multicast address includes the > octet address (as opposed to eg ethernet 6octets) hence it could send it to > that octet address (not 255). > > The current version is -01; see section 9 It is a non-goal (perhaps this should be stated explicitly in the I-D) to modify the current MS/TP state machines (other than the extension for larger data frames already proposed in BACnet). The only currently available option is 255 (all-nodes). We *could* look at MS/TP as a multicast challenged data link and support functions like NS via RFC 4861 extensions as discussed in IPv6 ND Optimization for Energy-aware Devices Plan B would be to look at using the 128-254 address range for multicast mapping, but then we diverge from co-existence and possibly need to modify state machines. > - 1 Poll for Master - sounds as RS, why not mapping one into another? > 2 Reply to Poll for Master sounds as RA, same. > > These are MAC control frames that are part of token generation (or recovery from a lost token). Again, modification of the MS/TP MAC is a non-goal. See section 2 for MS/TP MAC requirements. > - MLD mapping could be as well useful. > > Can you say more about this? Thanks, -K- > Alex > ------------------------------**------------------------------**-------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6 > ------------------------------**------------------------------**-------- > --bcaec5304f3783753704a9007b09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 26, 2011 at 6:03 PM, Alexandru Petrescu = <alexandru.petrescu@gmai= l.com> wrote:
Comments on draft =A0draft-lynn-6man-6lobac-00:

- needs a section on multicast address mapping; it may not be straightforwa= rd: it may need to _not_ send all ip-multicasted messages to 255 link-layer= address: the solicited-node multicast address includes the octet address (= as opposed to eg ethernet 6octets) hence it could send it to that octet add= ress (not 255).

The current version is -01; see section 9
<= br>
It is a non-goal (perhaps this should be stated explicitly in= the I-D)
to modify the current MS/TP state machines (other than = the
extension for larger data frames already proposed in BACnet).

The only currently available option is 255 (all-nodes). = =A0We *could*
look at=A0MS/TP as a multicast challenged data link= and support
functions=A0like NS via RFC 4861 extensions as discussed in

Plan B would = be to look at using the 128-254 address range for
multicast mapping, but then we diverge from co-existence and
possibly need to modify state machines.
=A0
- 1 Poll for Master - sounds as RS, why not mapping one into another?
=A02 Reply to Poll for Master sounds as RA, same.

These are MAC control frames that are part of token g= eneration
(or recovery from a lost token). =A0Again, modification= of the MS/TP
MAC is a non-goal. =A0See section 2 for MS/TP MAC r= equirements.
=A0
- MLD mapping could be as well useful.

Can you say more about this?

Thanks, -K-
=A0
Alex
-------------------------------------------------------------= -------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------= -------

--bcaec5304f3783753704a9007b09-- From brian@innovationslab.net Thu Jul 28 07:45:46 2011 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 6FB8621F8B34 for ; Thu, 28 Jul 2011 07:45:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mhlc4cjZF4hZ for ; Thu, 28 Jul 2011 07:45:45 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id E10EB21F8B2D for ; Thu, 28 Jul 2011 07:45:45 -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 8044D8815E; Thu, 28 Jul 2011 07:45:45 -0700 (PDT) Received: from dhcp-61f9.meeting.ietf.org (unknown [IPv6:2001:df8:0:96:222:41ff:fefb:b014]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 202271369598; Thu, 28 Jul 2011 07:45:45 -0700 (PDT) Message-ID: <4E31761B.4050002@innovationslab.net> Date: Thu, 28 Jul 2011 10:45:47 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: IETF 81 6MAN Meeting Minutes X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bob Hinden 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, 28 Jul 2011 14:45:46 -0000 All, The minutes from Tuesday's meeting are now available at http://www.ietf.org/proceedings/81/minutes/6man.txt. Many thanks to Fred Baker for taking minutes and to the Wes George & Joel Jaeggli tag team for being the Jabber scribe. Please let the chairs now if you find any errors/issues with the minutes. Regards, Brian & Bob From jari.arkko@piuha.net Thu Jul 28 10:55:18 2011 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 BC16F11E80E2 for ; Thu, 28 Jul 2011 10:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMKZxY8kEcSy for ; Thu, 28 Jul 2011 10:55:17 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1F23B11E807B for ; Thu, 28 Jul 2011 10:55:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0B6672CE66; Thu, 28 Jul 2011 20:55:15 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6nnAzGMrfiw; Thu, 28 Jul 2011 20:55:14 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4DDC72CC4B; Thu, 28 Jul 2011 20:55:13 +0300 (EEST) Message-ID: <4E31A280.1040504@piuha.net> Date: Thu, 28 Jul 2011 13:55:12 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: JP Vasseur , Jonathan Hui Subject: AD reviews of draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header References: <4DFBC587.9090807@piuha.net> In-Reply-To: <4DFBC587.9090807@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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: Thu, 28 Jul 2011 17:55:18 -0000 JP, Jonathan, Has there a been response to the two reviews from June? I'd like to move these drafts forward... Jari Jari Arkko kirjoitti: > I have reviewed this draft. Some of the issues from the other draft > are visible in this one as well, and I saw two additional substantive > issues: > > - we need to specify the behavior with regards to the data in this > option better > - the text about processing packets in RPL border routers should be > written in a different manner > > Both of these should be easily addressed, however. Please revise the > draft and we can send the draft to IETF Last Call. > > Here are my comments in more detail: > >> Datagrams being forwarded within a RPL domain MUST include a RPL >> Option. For datagrams sourced within a RPL domain, the RPL Option >> MAY be included in the datagram itself. > > I'm not sure I understand the difference or its motivation. Do you > really mean that a packet might not have the option until it hits the > first router? Or are you just talking about something that happens > internally on a host, but on the wire all packets would still have the > option? Also, since the tunnel (or something else) is used to include > the option for datagrams sourced outside the RPL domain, wouldn't it > be easier to just say this: > > "Datagrams sent between nodes within an RPL domain MUST include an RPL > Option." > >> For datagrams sourced >> outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in >> [RFC2473 ] SHOULD be used to >> include a RPL Option. > > This text should be aligned with whatever conclusion we will have for > the issue that I raised with the other document. > >> To help avoid IP-layer fragmentation, the RPL Option has a maximum >> size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain >> SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop >> Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional >> extension headers or options needed within RPL domain). >> > > There's a same MTU issue here as in the other document. > >> The action taken by using the RPL Option and the potential set of >> sub-TLVs carried within the RPL Option MUST be specified by the RFC >> of the protocol that use that option. No TLVs are defined in this >> document. >> > > I think you should define the behavior when a node encounters a > sub-TLV that it does not recognize. E.g., ignore and move on to the > next sub-TLV. Or do you want a stricter policy? In any case, for > future extensions it will be necessary to know how they are treated by > legacy RPL nodes. > >> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due >> to the added cost and complexity required to process and carry a >> datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers >> ] >> describes >> how to avoid using IPv6-in-IPv6 tunneling in such specific cases and >> the risks involved. >> > > Again, the same comments as in the other draft. Please delete this > paragraph. > >> For datagrams exiting the RPL domain, RPL Border Routers MUST remove >> the RPL Option from the datagram. If the RPL Option was included >> using tunneled mode and the RPL Border Router serves as the tunnel >> end-point, removing the outer IPv6 header serves to remove the RPL >> Option as well. Otherwise, the RPL Border Router assumes that the >> RPL Option was included using transport mode and MUST remove the RPL >> Option from the IPv6 Hop-by-Hop Option header. >> > > The part about removing the RPL option even in a non-tunneled case > relates to the issue of supporting that particular mode of operation. > > But in addition, I wonder if you should write the above text not in > terms of packet modification operations but rather in terms of > forwarding decision outcomes. Like this, for instance: > > "For datagrams destined to the RPL Border Router the router processes > the packet in the usual way. For instance, if the RPL Option was > included using tunneled mode and the RPL Border Router serves as the > tunnel end-point, the router removes the outer IPv6 header, at the > same removing the RPL Option as well. Datagrams destined elsewhere > within the same RPL domain are forwarded to the right interface. > Datagrams destined outside the RPL domain are dropped." > >> 6. Usage of the RPL Option >> >> The RPL Option is only for use within a RPL domain. RPL routers MUST >> process and include the RPL Option when forwarding datagrams to other >> nodes within the RPL domain. Routers on the edge of a RPL domain >> MUST remove the RPL Option when forwarding datagrams to nodes outside >> the RPL domain. > > What is it that this section says that is not already covered by > sections 2 and 5: > > Sect 2: Datagrams being forwarded within a RPL domain MUST include a > RPL Option. > > Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 > header serves to remove the RPL Option as well. Otherwise, the RPL > Border Router assumes that the RPL Option was included using transport > mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option > header. > >> This option may be used to mount several potential attacks since >> routers may be flooded by bogus datagram containing the RPL option. >> It is thus RECOMMENDED for routers to implement a rate limiter for >> datagrams using the RPL Option. >> > > Please open this up a bit. What specific danger does flooding by bogus > datagrams and RPL options cause? What would be the default settings > for the rate limiter? > >> Opt Data Len: 8-bit field indicating the length of the option, in >> octets, excluding the Option Type and Opt Data Len fields. >> >> Down 'O': 1-bit flag as defined in Section 11 of >> [I-D.ietf-roll-rpl >> ]. >> >> >> Rank-Error 'R': 1-bit flag as defined in Section 11 of >> [I-D.ietf-roll-rpl >> ]. >> >> >> Forwarding-Error 'F': 1-bit flag as defined in Section 11 of >> [I-D.ietf-roll-rpl >> ]. >> >> >> RPLInstanceID: 8-bit field as defined in Section 11 of >> [I-D.ietf-roll-rpl >> ]. >> >> >> SenderRank: 16-bit field as defined in Section 11 of >> [I-D.ietf-roll-rpl >> ]. >> >> >> Values within the RPL Option are expected to change en-route. > > This specification needs to describe what the behavior of a router is > with the content of the option. I think this is easy, you should just > add to the end: "The processing shall follow the rules described in > Section 11.2 of [roll-rpl]. > > As an aside, the entire Section 11 is marked in roll-rpl as > non-normative. I don't think that's actually right as far as 11.2 > goes, because it contains tons of MUSTs and SHOULDs. Perhaps you want > to fix that in AUTH48... > > Jari > > From jpv@cisco.com Thu Jul 28 11:47:21 2011 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 D683111E810D for ; Thu, 28 Jul 2011 11:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLRBufesrKFR for ; Thu, 28 Jul 2011 11:47:08 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B8E8C5E801D for ; Thu, 28 Jul 2011 11:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=19496; q=dns/txt; s=iport; t=1311878827; x=1313088427; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=uq9arg+53MQuuC/KQN2ZyIAvTGzhBrKDPdeVJy7L9GE=; b=l2hN+F+OVSxzDe3pg6CaqFL6O9H21KDI0cJQ9FExT5mWZSw0yaGrJDXu cIze2U028sQs9QPoh0gk9QXT0MZjVocTkHnshu4thtd2syYb2ntA067Hw Fw9V0dt/3eQxGmQw5/irj3z5HJelGFjZcZnKcfXZOXVGj3BeYYzipSSrz w=; X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208,217";a="7492987" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jul 2011 18:47:07 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SIl3cX020770; Thu, 28 Jul 2011 18:47:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 11:47:05 -0700 Received: from dhcp-13dd.meeting.ietf.org ([10.21.90.36]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 11:47:05 -0700 Subject: Re: AD reviews of draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_6DAFB831-8A15-4D44-8BBC-5CBCAC6AB82C" From: JP Vasseur In-Reply-To: <4E31A280.1040504@piuha.net> Date: Thu, 28 Jul 2011 14:47:04 -0400 Message-Id: References: <4DFBC587.9090807@piuha.net> <4E31A280.1040504@piuha.net> To: "Jari Arkko" X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 28 Jul 2011 18:47:05.0325 (UTC) FILETIME=[BEF671D0:01CC4D56] Cc: IETF IPv6 Mailing List , Jonathan Hui 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, 28 Jul 2011 18:47:22 -0000 --Apple-Mail=_6DAFB831-8A15-4D44-8BBC-5CBCAC6AB82C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks a lot Jari, sorry for the delay, Jonathan and I just had a = discussion and will send a proposal this week. Thanks. JP. On Jul 28, 2011, at 1:55 PM, Jari Arkko wrote: > JP, Jonathan, >=20 > Has there a been response to the two reviews from June? I'd like to = move > these drafts forward... >=20 > Jari >=20 > Jari Arkko kirjoitti: > > I have reviewed this draft. Some of the issues from the other draft > > are visible in this one as well, and I saw two additional = substantive > > issues: > > > > - we need to specify the behavior with regards to the data in this > > option better > > - the text about processing packets in RPL border routers should be > > written in a different manner > > > > Both of these should be easily addressed, however. Please revise the > > draft and we can send the draft to IETF Last Call. > > > > Here are my comments in more detail: > > > >> Datagrams being forwarded within a RPL domain MUST include a RPL > >> Option. For datagrams sourced within a RPL domain, the RPL Option > >> MAY be included in the datagram itself. > > > > I'm not sure I understand the difference or its motivation. Do you > > really mean that a packet might not have the option until it hits = the > > first router? Or are you just talking about something that happens > > internally on a host, but on the wire all packets would still have = the > > option? Also, since the tunnel (or something else) is used to = include > > the option for datagrams sourced outside the RPL domain, wouldn't it > > be easier to just say this: > > > > "Datagrams sent between nodes within an RPL domain MUST include an = RPL > > Option." > > > >> For datagrams sourced > >> outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in > >> [RFC2473 ] SHOULD be used to > >> include a RPL Option. > > > > This text should be aligned with whatever conclusion we will have = for > > the issue that I raised with the other document. > > > >> To help avoid IP-layer fragmentation, the RPL Option has a maximum > >> size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain > >> SHOULD have a MTU of at least 1280 + 44 (outer IP header, = Hop-by-Hop > >> Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional > >> extension headers or options needed within RPL domain). > >> =20 > > > > There's a same MTU issue here as in the other document. > > > >> The action taken by using the RPL Option and the potential set of > >> sub-TLVs carried within the RPL Option MUST be specified by the RFC > >> of the protocol that use that option. No TLVs are defined in this > >> document. > >> =20 > > > > I think you should define the behavior when a node encounters a > > sub-TLV that it does not recognize. E.g., ignore and move on to the > > next sub-TLV. Or do you want a stricter policy? In any case, for > > future extensions it will be necessary to know how they are treated = by > > legacy RPL nodes. > > > >> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable = due > >> to the added cost and complexity required to process and carry a > >> datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers > >> = ] > >> describes > >> how to avoid using IPv6-in-IPv6 tunneling in such specific cases = and > >> the risks involved. > >> =20 > > > > Again, the same comments as in the other draft. Please delete this > > paragraph. > > > >> For datagrams exiting the RPL domain, RPL Border Routers MUST = remove > >> the RPL Option from the datagram. If the RPL Option was included > >> using tunneled mode and the RPL Border Router serves as the tunnel > >> end-point, removing the outer IPv6 header serves to remove the RPL > >> Option as well. Otherwise, the RPL Border Router assumes that the > >> RPL Option was included using transport mode and MUST remove the = RPL > >> Option from the IPv6 Hop-by-Hop Option header. > >> =20 > > > > The part about removing the RPL option even in a non-tunneled case > > relates to the issue of supporting that particular mode of = operation. > > > > But in addition, I wonder if you should write the above text not in > > terms of packet modification operations but rather in terms of > > forwarding decision outcomes. Like this, for instance: > > > > "For datagrams destined to the RPL Border Router the router = processes > > the packet in the usual way. For instance, if the RPL Option was > > included using tunneled mode and the RPL Border Router serves as the > > tunnel end-point, the router removes the outer IPv6 header, at the > > same removing the RPL Option as well. Datagrams destined elsewhere > > within the same RPL domain are forwarded to the right interface. > > Datagrams destined outside the RPL domain are dropped." > > > >> 6. Usage of the RPL Option > >> > >> The RPL Option is only for use within a RPL domain. RPL routers = MUST > >> process and include the RPL Option when forwarding datagrams to = other > >> nodes within the RPL domain. Routers on the edge of a RPL = domain > >> MUST remove the RPL Option when forwarding datagrams to nodes = outside > >> the RPL domain. > > > > What is it that this section says that is not already covered by > > sections 2 and 5: > > > > Sect 2: Datagrams being forwarded within a RPL domain MUST include a > > RPL Option. > > > > Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 > > header serves to remove the RPL Option as well. Otherwise, the RPL > > Border Router assumes that the RPL Option was included using = transport > > mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option > > header. > > > >> This option may be used to mount several potential attacks since > >> routers may be flooded by bogus datagram containing the RPL option. > >> It is thus RECOMMENDED for routers to implement a rate limiter for > >> datagrams using the RPL Option. > >> =20 > > > > Please open this up a bit. What specific danger does flooding by = bogus > > datagrams and RPL options cause? What would be the default settings > > for the rate limiter? > > > >> Opt Data Len: 8-bit field indicating the length of the option, = in > >> octets, excluding the Option Type and Opt Data Len fields. > >> > >> Down 'O': 1-bit flag as defined in Section 11 of > >> [I-D.ietf-roll-rpl > >> = ]. > >> > >> > >> Rank-Error 'R': 1-bit flag as defined in Section 11 of > >> [I-D.ietf-roll-rpl > >> = ]. > >> > >> > >> Forwarding-Error 'F': 1-bit flag as defined in Section 11 of > >> [I-D.ietf-roll-rpl > >> = ]. > >> > >> > >> RPLInstanceID: 8-bit field as defined in Section 11 of > >> [I-D.ietf-roll-rpl > >> = ]. > >> > >> > >> SenderRank: 16-bit field as defined in Section 11 of > >> [I-D.ietf-roll-rpl > >> = ]. > >> > >> > >> Values within the RPL Option are expected to change en-route. > > > > This specification needs to describe what the behavior of a router = is > > with the content of the option. I think this is easy, you should = just > > add to the end: "The processing shall follow the rules described in > > Section 11.2 of [roll-rpl]. > > > > As an aside, the entire Section 11 is marked in roll-rpl as > > non-normative. I don't think that's actually right as far as 11.2 > > goes, because it contains tons of MUSTs and SHOULDs. Perhaps you = want > > to fix that in AUTH48... > > > > Jari > > > > >=20 >=20 --Apple-Mail=_6DAFB831-8A15-4D44-8BBC-5CBCAC6AB82C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Thanks a lot Jari, sorry for the delay, Jonathan and I just had a discussion and will send a proposal
this week.

Thanks.

JP.

On Jul 28, 2011, at 1:55 PM, Jari Arkko wrote:

AD reviews of draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header

JP, Jonathan,

Has there a been response to the two reviews from June? I'd like to move
these drafts forward...

Jari

Jari Arkko kirjoitti:
> I have reviewed this draft. Some of the issues from the other draft
> are visible in this one as well, and I saw two additional substantive
> issues:
>
> - we need to specify the behavior with regards to the data in this
> option better
> - the text about processing packets in RPL border routers should be
> written in a different manner
>
> Both of these should be easily addressed, however. Please revise the
> draft and we can send the draft to IETF Last Call.
>
> Here are my comments in more detail:
>
>> Datagrams being forwarded within a RPL domain MUST include a RPL
>> Option.  For datagrams sourced within a RPL domain, the RPL Option
>> MAY be included in the datagram itself.
>
> I'm not sure I understand the difference or its motivation. Do you
> really mean that a packet might not have the option until it hits the
> first router? Or are you just talking about something that happens
> internally on a host, but on the wire all packets would still have the
> option? Also, since the tunnel (or something else) is used to include
> the option for datagrams sourced outside the RPL domain, wouldn't it
> be easier to just say this:
>
> "Datagrams sent between nodes within an RPL domain MUST include an RPL
> Option."
>
>>   For datagrams sourced
>>    outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in
>>    [RFC2473 <http://tools.ietf.org/html/rfc2473>] SHOULD be used to
>> include a RPL Option.
>
> This text should be aligned with whatever conclusion we will have for
> the issue that I raised with the other document.
>
>> To help avoid IP-layer fragmentation, the RPL Option has a maximum
>> size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain
>> SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop
>> Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional
>> extension headers or options needed within RPL domain).
>>  
>
> There's a same MTU issue here as in the other document.
>
>> The action taken by using the RPL Option and the potential set of
>> sub-TLVs carried within the RPL Option MUST be specified by the RFC
>> of the protocol that use that option.  No TLVs are defined in this
>> document.
>>  
>
> I think you should define the behavior when a node encounters a
> sub-TLV that it does not recognize. E.g., ignore and move on to the
> next sub-TLV. Or do you want a stricter policy? In any case, for
> future extensions it will be necessary to know how they are treated by
> legacy RPL nodes.
>
>> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due
>> to the added cost and complexity required to process and carry a
>> datagram with two IPv6 headers.  [I-D.hui-6man-rpl-headers
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.hui-6man-rpl-headers>]
>> describes
>> how to avoid using IPv6-in-IPv6 tunneling in such specific cases and
>> the risks involved.
>>  
>
> Again, the same comments as in the other draft. Please delete this
> paragraph.
>
>> For datagrams exiting the RPL domain, RPL Border Routers MUST remove
>> the RPL Option from the datagram.  If the RPL Option was included
>> using tunneled mode and the RPL Border Router serves as the tunnel
>> end-point, removing the outer IPv6 header serves to remove the RPL
>> Option as well.  Otherwise, the RPL Border Router assumes that the
>> RPL Option was included using transport mode and MUST remove the RPL
>> Option from the IPv6 Hop-by-Hop Option header.
>>  
>
> The part about removing the RPL option even in a non-tunneled case
> relates to the issue of supporting that particular mode of operation.
>
> But in addition, I wonder if you should write the above text not in
> terms of packet modification operations but rather in terms of
> forwarding decision outcomes. Like this, for instance:
>
> "For datagrams destined to the RPL Border Router the router processes
> the packet in the usual way. For instance, if the RPL Option was
> included using tunneled mode and the RPL Border Router serves as the
> tunnel end-point, the router removes the outer IPv6 header, at the
> same removing the RPL Option as well. Datagrams destined elsewhere
> within the same RPL domain are forwarded to the right interface.
> Datagrams destined outside the RPL domain are dropped."
>
>> 6. Usage of the RPL Option
>>
>>    The RPL Option is only for use within a RPL domain.  RPL routers MUST
>>    process and include the RPL Option when forwarding datagrams to other
>>    nodes within the RPL domain.  Routers on the edge of a RPL domain
>>    MUST remove the RPL Option when forwarding datagrams to nodes outside
>>    the RPL domain.
>
> What is it that this section says that is not already covered by
> sections 2 and 5:
>
> Sect 2: Datagrams being forwarded within a RPL domain MUST include a
> RPL Option.
>
> Sect 5: ... serves as the tunnel end-point, removing the outer IPv6
> header serves to remove the RPL Option as well.  Otherwise, the RPL
> Border Router assumes that the RPL Option was included using transport
> mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option
> header.
>
>> This option may be used to mount several potential attacks since
>> routers may be flooded by bogus datagram containing the RPL option.
>> It is thus RECOMMENDED for routers to implement a rate limiter for
>>    datagrams using the RPL Option.
>>  
>
> Please open this up a bit. What specific danger does flooding by bogus
> datagrams and RPL options cause? What would be the default settings
> for the rate limiter?
>
>>    Opt Data Len:  8-bit field indicating the length of the option, in
>>          octets, excluding the Option Type and Opt Data Len fields.
>>
>>    Down 'O':  1-bit flag as defined in Section 11 of
>>          [I-D.ietf-roll-rpl
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>>
>>
>>    Rank-Error 'R':  1-bit flag as defined in Section 11 of
>>          [I-D.ietf-roll-rpl
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>>
>>
>>    Forwarding-Error 'F':  1-bit flag as defined in Section 11 of
>>          [I-D.ietf-roll-rpl
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>>
>>
>>    RPLInstanceID:  8-bit field as defined in Section 11 of
>>          [I-D.ietf-roll-rpl
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>>
>>
>>    SenderRank:  16-bit field as defined in Section 11 of
>>          [I-D.ietf-roll-rpl
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>>
>>
>>    Values within the RPL Option are expected to change en-route.
>
> This specification needs to describe what the behavior of a router is
> with the content of the option. I think this is easy, you should just
> add to the end: "The processing shall follow the rules described in
> Section 11.2 of [roll-rpl].
>
> As an aside, the entire Section 11 is marked in roll-rpl as
> non-normative. I don't think that's actually right as far as 11.2
> goes, because it contains tons of MUSTs and SHOULDs. Perhaps you want
> to fix that in AUTH48...
>
> Jari
>
>


--Apple-Mail=_6DAFB831-8A15-4D44-8BBC-5CBCAC6AB82C-- From wwwrun@rfc-editor.org Thu Jul 28 13:19:43 2011 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 C605921F8B25 for ; Thu, 28 Jul 2011 13:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09ieRz7BFuev for ; Thu, 28 Jul 2011 13:19:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAD421F8B23 for ; Thu, 28 Jul 2011 13:19:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E9C0E98C4EF; Thu, 28 Jul 2011 13:19:42 -0700 (PDT) To: kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, bob.hinden@gmail.com, brian@innovationslab.net Subject: [Technical Errata Reported] RFC5952 (2872) From: RFC Errata System Message-Id: <20110728201942.E9C0E98C4EF@rfc-editor.org> Date: Thu, 28 Jul 2011 13:19:42 -0700 (PDT) Cc: rjsmith2@cisco.com, ipv6@ietf.org, rfc-editor@rfc-editor.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, 28 Jul 2011 20:19:43 -0000 The following errata report has been submitted for RFC5952, "A Recommendation for IPv6 Address Text Representation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=2872 -------------------------------------- Type: Technical Reported by: Richard J. Smith Section: 5 Original Text ------------- For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. Corrected Text -------------- For these addresses, mixed notation is RECOMMENDED if the following conditions are met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix, and the entire address is not either the unspecified IPv6 address "::" or the loopback IPv6 address "::1". Notes ----- RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5952 (draft-ietf-6man-text-addr-representation-07) -------------------------------------- Title : A Recommendation for IPv6 Address Text Representation Publication Date : August 2010 Author(s) : S. Kawamura, M. Kawashima Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From kawashimam@vx.jp.nec.com Thu Jul 28 17:05:08 2011 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 D06B511E80A2 for ; Thu, 28 Jul 2011 17:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTYOfomv8uUN for ; Thu, 28 Jul 2011 17:05:08 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id CC5FD11E809C for ; Thu, 28 Jul 2011 17:05:07 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6T0551T021642; Fri, 29 Jul 2011 09:05:05 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6T055M00379; Fri, 29 Jul 2011 09:05:05 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6T04Y3p005089; Fri, 29 Jul 2011 09:05:04 +0900 (JST) Received: from kogoro.jp.nec.com ([10.26.220.12] [10.26.220.12]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-99623; Fri, 29 Jul 2011 09:04:10 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-9556; Fri, 29 Jul 2011 09:04:10 +0900 To: rjsmith2@cisco.com, ipv6@ietf.org Subject: Re: [Technical Errata Reported] RFC5952 (2872) In-reply-to: <20110728201942.E9C0E98C4EF@rfc-editor.org> Message-Id: <20110729090410kawashimam@mail.jp.nec.com> References: <20110728201942.E9C0E98C4EF@rfc-editor.org> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Fri, 29 Jul 2011 09:04:10 +0900 Content-Type: text/plain; charset=iso-2022-jp 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: Fri, 29 Jul 2011 00:05:08 -0000 Hi Richard, Thank you for your report. I think this is better discussed in 6man. But I think it is not an error. Section 5 describes "Embedded IPv4 Addresses" for mixed notation. IPv6 unspecified address and IPv6 loopback address are out of scope. Moreover, the 80-bit all-zeros prefix is not "IPv4-compatible IPv6 address". We should not use the 80-bit all-zeros prefix to identify embedded IPv4 addresses. I didn't understand what you mean. Please describe more detail. Regards, Masanobu > >The following errata report has been submitted for RFC5952, >"A Recommendation for IPv6 Address Text Representation". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=2872 > >-------------------------------------- >Type: Technical >Reported by: Richard J. Smith > >Section: 5 > >Original Text >------------- >For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. > > >Corrected Text >-------------- >For these addresses, mixed notation is RECOMMENDED if the following conditions are met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix, and the entire address is not either the unspecified IPv6 address "::" or the loopback IPv6 address "::1". > > >Notes >----- >RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC5952 (draft-ietf-6man-text-addr-representation-07) >-------------------------------------- >Title : A Recommendation for IPv6 Address Text Representation >Publication Date : August 2010 >Author(s) : S. Kawamura, M. Kawashima >Category : PROPOSED STANDARD >Source : IPv6 Maintenance >Area : Internet >Stream : IETF >Verifying Party : IESG $B!q(B(._.) ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From frnkblk@iname.com Thu Jul 28 18:19:40 2011 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 8903021F8B31; Thu, 28 Jul 2011 18:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YuWKuITqeEo; Thu, 28 Jul 2011 18:19:40 -0700 (PDT) Received: from premieronline.net (smtp2-5.premieronline.net [96.31.0.30]) by ietfa.amsl.com (Postfix) with ESMTP id A234F21F8B30; Thu, 28 Jul 2011 18:19:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 2205779-1729245 for multiple; Thu, 28 Jul 2011 20:19:38 -0500 From: "Frank Bulk" To: "'Christian Huitema'" , "Philip Homburg" , "Mark Smith" References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Subject: RE: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Date: Thu, 28 Jul 2011 20:19:36 -0500 Message-ID: <000701cc4d8d$94d0c860$be725920$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMRJHLOaNFypP8jkSb4kdkNNCU2pTwpJNwgBHsZZA= Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (useraccess) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=12 Friend=777 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 870, in=13506195, out=50842, spam=0 Known=true ip=199.120.69.26 X-Mailman-Approved-At: Thu, 28 Jul 2011 18:22:45 -0700 Cc: IPv6 Operations , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 01:19:40 -0000 Just like some routers allow one to partition the RIB between v4 and v6 address space, the ND cache could be customizably split between good and "bad" cache (i.e. 80-20), with the bad operating on a FIFO basis with some kind of customizable COPS-style rate-limiter attached to that "bad" cache. This would give the network guy the necessary knobs to manage ND DoS. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Sunday, July 17, 2011 11:09 AM To: Philip Homburg; Mark Smith Cc: IPv6 Operations; ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? >So perhaps the changes required would be mostly limited to - > >- DADs to all-nodes rather than solicited node addresses >- nodes receiving the DAD use that to create a neighbor cache entry >- NUD takes care of maintaining the validity of those entries >- ND NS to all nodes with an unspecified target address solicits NAs > from all nodes to cover the router (or any device) reboot situation I am not sure this addresses the problem too well. The DOS issue manifests itself at the gateway, and the main issue is the remote DOS: attacker sends packets to a very large number of putative IPv6 addresses in the subnet managed by the local gateway, causing the size of the neighbor cache to explode. If we want to protect the cache in the gateway, let's do that. The solution has to be a tweak in the implementation of ND in the gateway, along the lines of: - Upon arrival of a packet from the local network: - If the source address is already in ND cache, keep it there - if the source address is not already in the ND cache: Perform some quota check on the source MAC address, If the quota is exceeded, drop the packet to protect against local DOS If the quota is not exceeded, perform ND for the source address - Upon arrival of a packet bound to the local subnet - If the destination address is already in ND cache, route the packet; - If the destination address is not in ND cache: If the table is "too full," drop the packet Else, perform ND The basic idea is that remote parties should only be sending to addresses that have already been discovered in the local subnet. This is, in a way, a weak form of stateful filtering. It needs to be implemented softly, because routers/gateways sometime lose their memory, so we want to allow for some dynamic learning if the tables are not already populated. The proposed tweaks amount to making ND learn faster. They are fine in general, but they have the side effect of making local DOS easier. A local attacker could generate a large number of addresses, etc. -- Christian Huitema _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From kawashimam@vx.jp.nec.com Fri Jul 29 11:42:31 2011 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 1546921F8922 for ; Fri, 29 Jul 2011 11:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p1ijOte2L6a for ; Fri, 29 Jul 2011 11:42:30 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id DC6E621F86DC for ; Fri, 29 Jul 2011 11:42:29 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6TIgQ4w007053; Sat, 30 Jul 2011 03:42:26 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6TIgQT24646; Sat, 30 Jul 2011 03:42:26 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6TIgQDD006797; Sat, 30 Jul 2011 03:42:26 +0900 (JST) Received: from chojiro.jp.nec.com ([10.26.220.28] [10.26.220.28]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-121998; Sat, 30 Jul 2011 03:41:36 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-342; Sat, 30 Jul 2011 03:41:35 +0900 To: "Rich Smith (rjsmith2)" Subject: RE: [Technical Errata Reported] RFC5952 (2872) In-reply-to: References: Message-Id: <20110730034136kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Sat, 30 Jul 2011 03:41:35 +0900 Content-Type: text/plain; charset=iso-2022-jp 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, 29 Jul 2011 18:42:31 -0000 Hi Richard, Thank you for your reply. >These sections clearly indicate that addresses with the first 96 bits > all-zero have embedded IPv4 addresses. I don't think so. You have missed note below in Section 2.5.5.1. =================================================================== Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" must be a globally-unique IPv4 unicast address. =================================================================== ::(Unspecified Address) and ::1(Loopback Address) are not globally-unique IPv4 unicast address. We should not use the 96-bit all-zeros prefix to identify embedded IPv4 addresses. We have to check last 32 bits of the address. Thus, we don't need any addition. It is not an error. >By the way, I want to thank you for authoring this RFC, since it solves > a major problem we have, which is searching for and matching IPv6 addresses > that are represented as text. Thank you for your feedback. I'm so glad to hear that. :-) Regards, Masanobu >RFC-4291 (IP Version 6 Addressing Architecture), which RFC-5952 references, has a section 2.5.5 called "IPv6 Addresses with Embedded IPv4 Addresses". Presumably, this is what RFC-5952 is referring to. Section 2.5.5 two subsections. The first subsection 2.5.5.1 is called "IPv4-Compatible IPv6 Address". Let me copy it here: > >2.5.5.1. IPv4-Compatible IPv6 Address > > The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 > transition. The format of the "IPv4-Compatible IPv6 address" is as > follows: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > > Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > > The "IPv4-Compatible IPv6 address" is now deprecated because the > current IPv6 transition mechanisms no longer use these addresses. > New or updated implementations are not required to support this > address type. > >In addition, in RFC-4291 has a section 2.2 called "Text Representation of Addresses", which has the following paragraph regarding mixed IPv6 / IPv4 addresses: > > 3. An alternative form that is sometimes more convenient when dealing > with a mixed environment of IPv4 and IPv6 nodes is > x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of > the six high-order 16-bit pieces of the address, and the 'd's are > the decimal values of the four low-order 8-bit pieces of the > address (standard IPv4 representation). Examples: > > 0:0:0:0:0:0:13.1.68.3 > > 0:0:0:0:0:FFFF:129.144.52.38 > > or in compressed form: > > ::13.1.68.3 > > ::FFFF:129.144.52.38 > >These sections clearly indicate that addresses with the first 96 bits all-zero have embedded IPv4 addresses. It does say that this prefix is deprecated, but deprecated or not, RFC-4291 clearly defines 96 bits of zero to contain an embedded IPv4 address, and then shows it in at least two examples. > >Thus my confusion from this paragraph in RFC-5952, section 5: > >5. Text Representation of Special Addresses > > Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and > IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses > embedded in the low-order 32 bits of the address. These addresses > have a special representation that may mix hexadecimal and dot > decimal notations. The decimal notation may be used only for the > last 32 bits of the address. For these addresses, mixed notation is > RECOMMENDED if the following condition is met: the address can be > distinguished as having IPv4 addresses embedded in the lower 32 bits > solely from the address field through the use of a well-known prefix. > Such prefixes are defined in [RFC4291] and [RFC2765] at the time of > this writing. If it is known by some external method that a given > prefix is used to embed IPv4, it MAY be represented as mixed > notation. Tools that provide options to specify prefixes that are > (or are not) to be represented as mixed notation may be useful. > >specifically "solely... through the use of a well-known prefix" then citing RFC-4291. > >RFC-4291 does define 96 bits of zero as a well-known IPv4 address prefix, as I've pasted above. > >If it was your intention that readers of RFC-5952 IGNORE section 2.5.5.1 of RFC-4291, then YOU MUST MAKE THAT CLEAR because NOTHING in RFC-5952 says to do that. In fact, just the opposite is at least implied, and implied because sections 2.2 and 2.5.5.1 clearly show 96-bit all-zeros prefix indicate an embedded IPv4 address, and RFC-5952 references this standard with no additional clarification other than to go solely by the address prefix. > >So, I want it made clear EITHER: a) Ignore section 2.5.5.1 of RFC-4291, which is to say that the 96-bit all-zero prefix is NOT intended to indicate an embedded IPv4 address, or b) make it clear that at least :: and ::1 are not to be treated as embedded IPv4 addresses because they are, in fact, well-known IPv6 addresses. The latter was my suggestion from the original errata. > >If you require further clarification, then let me know. I don't know if I can make it any clearer. I've pasted the relevant sections of RFC-5952 and RFC-4291. But, if this is not enough, then I can try to provide more information if you need it. > >By the way, I want to thank you for authoring this RFC, since it solves a major problem we have, which is searching for and matching IPv6 addresses that are represented as text. > >Thanks. > > --Rich > > >-----Original Message----- >From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] >Sent: Thursday, July 28, 2011 5:04 PM >To: Rich Smith (rjsmith2); ipv6@ietf.org >Subject: Re: [Technical Errata Reported] RFC5952 (2872) > > >Hi Richard, > >Thank you for your report. >I think this is better discussed in 6man. > >But I think it is not an error. >Section 5 describes "Embedded IPv4 Addresses" for mixed notation. >IPv6 unspecified address and IPv6 loopback address are out of scope. > >Moreover, the 80-bit all-zeros prefix is not "IPv4-compatible IPv6 address". >We should not use the 80-bit all-zeros prefix to identify embedded IPv4 addresses. > >I didn't understand what you mean. >Please describe more detail. > >Regards, >Masanobu > > >> >>The following errata report has been submitted for RFC5952, >>"A Recommendation for IPv6 Address Text Representation". >> >>-------------------------------------- >>You may review the report below and at: >>http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=2872 >> >>-------------------------------------- >>Type: Technical >>Reported by: Richard J. Smith >> >>Section: 5 >> >>Original Text >>------------- >>For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. >> >> >>Corrected Text >>-------------- >>For these addresses, mixed notation is RECOMMENDED if the following conditions are met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix, and the entire address is not either the unspecified IPv6 address "::" or the loopback IPv6 address "::1". >> >> >>Notes >>----- >>RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable. >> >>Instructions: >>------------- >>This errata is currently posted as "Reported". If necessary, please >>use "Reply All" to discuss whether it should be verified or >>rejected. When a decision is reached, the verifying party (IESG) >>can log in to change the status and edit the report, if necessary. >> >>-------------------------------------- >>RFC5952 (draft-ietf-6man-text-addr-representation-07) >>-------------------------------------- >>Title : A Recommendation for IPv6 Address Text Representation >>Publication Date : August 2010 >>Author(s) : S. Kawamura, M. Kawashima >>Category : PROPOSED STANDARD >>Source : IPv6 Maintenance >>Area : Internet >>Stream : IETF >>Verifying Party : IESG > >$B!q(B(._.) >======================================== > NEC AccessTechnica, Ltd. > Product Development Department > Masanobu Kawashima > kawashimam@vx.jp.nec.com > http://www.necat.co.jp/ >======================================== > $B!q(B(._.) ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From internet-drafts@ietf.org Fri Jul 29 13:05:10 2011 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 0F56411E8099; Fri, 29 Jul 2011 13:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEhUzFe-QNOf; Fri, 29 Jul 2011 13:05:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A156721F8A62; Fri, 29 Jul 2011 13:05:09 -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-flow-3697bis-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110729200509.28038.72300.idtracker@ietfa.amsl.com> Date: Fri, 29 Jul 2011 13:05:09 -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: Fri, 29 Jul 2011 20:05:10 -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= IETF. Title : IPv6 Flow Label Specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Filename : draft-ietf-6man-flow-3697bis-07.txt Pages : 17 Date : 2011-07-29 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-07.txt From brian.e.carpenter@gmail.com Fri Jul 29 13:20:05 2011 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 73F0A11E808E for ; Fri, 29 Jul 2011 13:20:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5szi3X6lx41t for ; Fri, 29 Jul 2011 13:20:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9452811E808D for ; Fri, 29 Jul 2011 13:20:04 -0700 (PDT) Received: by fxe6 with SMTP id 6so2986538fxe.31 for ; Fri, 29 Jul 2011 13:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=bzGf23Gq3GF2kyCPNRAYrx66+/3+p5gFziSlAW+ASXk=; b=TpICNBphkjh4xDd7yeA0An5Ot1y7KLfHMKgSSrN2EEcRZ66CInLN8oweI86TJnokk1 wIS7/kS3j1Dvt3s1OF+U5ariEUrHBwnURfMZ8FRv42yyhs91EGNB/ATjCDfMoc5vcpWX 1d/1u61CIT+y5+az+MtYTRJzeVygzaj11iz8I= Received: by 10.223.158.130 with SMTP id f2mr2395753fax.61.1311970803627; Fri, 29 Jul 2011 13:20:03 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x2sm1093980fal.20.2011.07.29.13.20.01 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 13:20:02 -0700 (PDT) Message-ID: <4E3315EA.7000308@gmail.com> Date: Sat, 30 Jul 2011 08:19:54 +1200 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-flow-3697bis-07.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: Fri, 29 Jul 2011 20:20:05 -0000 This update is intended to respond to all the IESG comments. For an overview of where the three flow label drafts are at, see https://datatracker.ietf.org/doc/search/?name=draft-ietf-6man-flow&activeDrafts=on&search_submit= Brian -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-flow-3697bis-07.txt Date: Fri, 29 Jul 2011 13:05:09 -0700 From: internet-drafts@ietf.org Reply-To: 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 : IPv6 Flow Label Specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Filename : draft-ietf-6man-flow-3697bis-07.txt Pages : 17 Date : 2011-07-29 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-07.txt _______________________________________________ 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 jonhui@cisco.com Fri Jul 29 14:38:32 2011 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 C6E4511E80AD for ; Fri, 29 Jul 2011 14:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He9xTjOq6Y9y for ; Fri, 29 Jul 2011 14:38:31 -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 A1CB311E8096 for ; Fri, 29 Jul 2011 14:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=10762; q=dns/txt; s=iport; t=1311975511; x=1313185111; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=z+GfAtcqwkFAGQwHIV73VbFxIdUY3gOL9nTCcVBBmmo=; b=m3NeapWCuWPdC6ReO3IuXsvNuUW0NEEQrBgnnytbu+hpcI86SiWmxsny QfStReXrgqT/cmnLL7Akw+DMXDU2GPetqNbGx/Mvn1e0Xf6KHxfBuxRtn VgKEWHUL5RwN3oFGxVVEx4YZ7UceV2/v5YYJtOZH5GYdriqa4kCXXyBJ+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHgnM06rRDoG/2dsb2JhbAA0AQEBAQIBFAErMxIFDAxSFFEHJBMHp1F3iHwEoVqeMYViXwSHWosgkQM X-IronPort-AV: E=Sophos;i="4.67,289,1309737600"; d="scan'208";a="7932166" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2011 21:38:31 +0000 Received: from sjc-vpn4-1418.cisco.com (sjc-vpn4-1418.cisco.com [10.21.85.137]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6TLcTag003035; Fri, 29 Jul 2011 21:38:30 GMT Subject: Re: AD review of draft-ietf-6man-rpl-routing-header Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <4DF29EAA.1060103@piuha.net> Date: Fri, 29 Jul 2011 14:38:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DF29EAA.1060103@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: IETF IPv6 Mailing List , draft-ietf-6man-rpl-routing-header@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, 29 Jul 2011 21:38:32 -0000 Hi Jari, Thanks for the review. As you did below, I too need to apologize for = the delay in responding. See my responses below: On Jun 10, 2011, at 3:46 PM, Jari Arkko wrote: > I have reviewed this draft. >=20 > I have a number of comments, most of which are at this point questions = and discussion items. The comments are included below in three = categories: technical comments, editorial comments, and comments = relating to feedback from other people that may not been fully handled = yet. In general, the draft is well written and largely ready to move to = a Proposed Standard RFC. However, there are a couple of issues that we = need to discuss: MTU requirements, recommendations to consider = alternative designs that exist only as Internet Drafts, and the = feasibility of the loop check. >=20 > I also need to apologize that it has taken far too long for me to do = this review. There's no good excuse, but I've had some number of other = documents in the queue this spring, day job requirements, and I knew I = needed to review this document carefully. The rpl-option draft is next = on my reading queue, probably reviewed by Monday. >=20 > Technical: > =3D=3D=3D=3D=3D=3D=3D >=20 >> links within a RPL domain SHOULD have >> a MTU of at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE (+ >> additional extension headers or options needed within RPL domain) >> octets. >> =20 >=20 > I thought that 6LOWPAN was an important link layer for the application = of RPL. Yet, RFC 4944 specifies a MTU of 1280 octets. The above = requirement seems to be in contradiction with what is available on = 6LOWPAN. Am I missing some extension of 6LOWPAN that changes the MTU, or = some other link layer that is expected to be used with RPL? If I'm not = missing anything, wouldn't this cause a problem? It would seem that = either you cannot run RPL on 6LOWPAN, run 6LOWPAN on non standard MTU = values (and we know MTU negotiation is difficult), or you have to change = the expectations of other nodes in the IPv6 Internet about the minimum = assured MTU. >=20 > Please clarify/resolve/tell me what I am missing. Yes, 6LoWPAN is one of the target link layers. I agree that this = statement is problematic with strict adherence to RFC 4944. Note, = however, that there are IEEE 802.15.4 variants (i.e. 802.15.4g) that = support frame lengths up to 2KB. I'm not sure it would be wise to limit = the capabilities of alternative IEEE 802.15.4 link technologies. I would propose to remove the cited statement. It is unnecessary given = that the next revision of this draft will require tunneling. >> A common network configuration for a RPL domain is that all nodes >> within a LLN share a common prefix. The SRH introduces the CmprI, >> CmprE, and Pad fields to allow compaction of the Address[1..n] vector >> when all entries share the same prefix as the IPv6 Destination >> Address field of the packet carrying the SRH. >=20 > So all segments are treated based on how many bytes they have in = common with the destination address. But the destination address keeps = changing as we go through the intermediate hops. Is it necessary to = clarify that the comparison/shared prefix is with the final destination = address, NOT the address that happens to be in the destination address = field currently? The intent really was to utilize the current IPv6 Destination value = since all entries except the last will carry the same CmprI prefix = bytes. Now, I can see there is an issue when we consider the final = entry controlled by CmprE. The intent was that CmprE would only differ = when operating in "transport mode" and the SRH would thus be removed = according to Section 5 of the draft. >> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due >> to the added cost and complexity required to process and carry a >> datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers = ] describes >> how to avoid using IPv6-in-IPv6 tunneling in such specific cases and >> the risks involved. >> =20 >=20 > This sounds like a recommendation to do something in a draft that has = not been through the working group and approved as the something that is = a sound practice. Unless the reference is normative, I think it is = inappropriate to refer to an Internet draft in this manner. >=20 > What I would recommend is to (1) change the "... SHOULD use = IPv6-in-IPv6 tunneling ..." statement to a MUST in this draft, (2) = remove the above text, and (3) make the corresponding changes to Section = 5. Then we can take hui-6man-rpl-headers through the working group and = provide a second, more light-weight approach that extends what we have = RFC-to-be-draft-ietf-6man-rpl-routing-header. >=20 > (FWIW, I think the problem begins when one adds the first byte to a = packet somewhere along the route. It does not not matter so much how = many bytes one adds, just the SRH or also the IP header. Most of the = complications on MTUs and so one start at that point. In any case, SRHs = may not be trivially small either. Assuming 64-bit prefix compression an = SRH for 4 hops would be 40 bytes.) In general, I agree with your concern. However, after re-reading the = draft, do is it necessary to mandate a particular solution (i.e. RFC = 2473)? Instead, how do you feel about the following modified text: To deliver a datagram, a router MAY specify a source route to reach the destination using a SRH. There are two cases that determine how to include an SRH with a datagram. 1. When the source node inserts an SRH, it may do so directly within the datagram itself. 2. When an intermediate node inserts an SRH, it should do so in a way that does not cause path MTU issues and ensures ICMP errors caused by inserting the SRH return to the source of the SRH rather than the original datagram. One such method is IPv6-in-IPv6 tunneling [RFC 2473]. >> If such addresses appear more than once and are separated by at least >> one address not assigned to that router, the router MUST drop the >> packet and SHOULD send an ICMP Parameter Problem, Code 0, to the >> Source Address. >> =20 > ... >=20 >> else if 2 or more entries in Address[1..n] are assigned to >> local interface and are separated by at least one >> address not assigned to local interface { >> discard the packet >> } >> =20 >=20 > The text and the code appear to disagree about whether to send an ICMP = Parameter Problem message. Please align. I assume that an ICMP message = is needed. Agree. >> Because this document specifies that SRH is only for use within a RPL >> domain, such attacks cannot be mounted from outside the RPL domain. >> As described in Section 5 = , RPL Border Routers MUST drop datagrams >> entering or exiting the RPL domain that contain a SRH in the IPv6 >> Extension headers. >> =20 >=20 > This is good, and I think the security considerations are sufficient. = However, I would be happier if the draft also recommended that by = default, non-RPL routers and firewalls should drop packets with SRH. = This would help ensure that SRH does not accidentally enter any network = and expose some vulnerability. The practical effect that I'm looking for = is, for instance, not having my Linux kernel process SRH unless I've = configured it to use RPL. Agree. > Editorial: > =3D=3D=3D=3D=3D=3D >=20 >> In the above scenario, datagrams traveling from source, S, to >> destination, D, have the following packet structure: >>=20 >>=20 >> +------+------+------+--------//-+ >> | IPv6 | IPv6 | IPv6 | Packet | >> | Src | Dst | SRH | Payload | >> +------+------+------+--------//-+ >> =20 >=20 > This figure is not as clear as it could be. Are the src and dst field = referring to the IPv6 header fields? Would this picture be better if you = showed the IPv6 header explicitly? Please clarify. Yes, the src and dst fields are IPv6 header fields. Will update the = figure to be more explicit. >> CmprE 4-bit unsigned integer. Number of prefix octets >> from the segment that are elided. For example, a >> SRH carrying a full IPv6 address in Addresses[n] >> sets CmprE to 0. >> =20 >=20 > I understood the definition CmprI, but I do not understand this, at = least not at the point of the above text. What is "the segment" that you = are referring to above? SRH carries multiple segments. Please clarify. >=20 > Little further down it becomes clear that CmprE refers to the = compression of the last segment. Please make this clear already in the = above text. Correct. Will clarify in the next revision. > Comments relating to feedback from others: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > The ADs have received a question from Joseph Reddy, who was asking if = the set of addresses in the SRH should also include the source address = of the node inserting the SRH. His justification for this was the need = to be able to send an ICMP error back to this node. Do we have an = answer? When using tunneling, the ICMP error should go back to the source of the = outer IPv6 header. > In April, Thomas Narten made some comments on the list and I didn't = think that the discussion finished with any conclusion. Are his concerns = (e.g., from his e-mail on April 29th) valid or not valid? I would like = the working group to conclude this issue one way or the other. I refer = to his comments regarding the feasibility of the loop check in = particular. His e-mail is at = http://www.ietf.org/mail-archive/web/ipv6/current/msg13887.html FWIW I = agree with Thomas' editorial comment on Section 2 clarity. That should = be easy to fix. My personal belief is that LLN devices will generally have more = computation capability relative to communication capability, so I'm not = terribly concerned with the processing overhead. That said, I'm not a = fan of the loop check and would prefer less complexity. We only = required such checks to deal with security concerns that have been = raised in the past with RH0. If others feel that the checks are = unnecessary or have alternative suggestions, I'm more than happy to make = the changes. Thanks. -- Jonathan Hui From jonhui@cisco.com Fri Jul 29 14:55:45 2011 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 04CA921F867A for ; Fri, 29 Jul 2011 14:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL0fA2kNxrlx for ; Fri, 29 Jul 2011 14:55:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36F21F861E for ; Fri, 29 Jul 2011 14:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=9055; q=dns/txt; s=iport; t=1311976540; x=1313186140; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tS8RGpJLY16fKryH+WdFjK8qCaQXBzCZTZR47w6dJnc=; b=hdgwSon8XGSXvfM9eHMtlcBOWzFUeRmLf6vUoHbhiyHU1TUraoorlqQA f0i2hN+X79fKzlihSxOn7X2C/wsH5kb2QIfmls6UIp+BiB2ffaJh5EKNp kvKwCPZ2eOVo/Ayd1v1C5+/u+a409AF/jAh6YwNBc3pzVpGKH3XtWVOm+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKErM06rRDoJ/2dsb2JhbAA0AQEBAQIBFAErMxIFDAxSFFEHPqdRd4h8BKFini2FYl8Eh1qLIJED X-IronPort-AV: E=Sophos;i="4.67,289,1309737600"; d="scan'208";a="7931903" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jul 2011 21:55:39 +0000 Received: from sjc-vpn4-1418.cisco.com (sjc-vpn4-1418.cisco.com [10.21.85.137]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6TLtcgv011528; Fri, 29 Jul 2011 21:55:38 GMT Subject: Re: AD review of draft-ietf-6man-rpl-option Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <4DFBC587.9090807@piuha.net> Date: Fri, 29 Jul 2011 14:55:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DFBC587.9090807@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: IETF IPv6 Mailing List , draft-ietf-6man-rpl-option@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, 29 Jul 2011 21:55:45 -0000 Hi Jari, Again, thanks for your review and apologize for the delay. See my = responses below: On Jun 17, 2011, at 2:22 PM, Jari Arkko wrote: > I have reviewed this draft. Some of the issues from the other draft = are visible in this one as well, and I saw two additional substantive = issues: >=20 > - we need to specify the behavior with regards to the data in this = option better > - the text about processing packets in RPL border routers should be = written in a different manner >=20 > Both of these should be easily addressed, however. Please revise the = draft and we can send the draft to IETF Last Call. >=20 > Here are my comments in more detail: >=20 >> Datagrams being forwarded within a RPL domain MUST include a RPL >> Option. For datagrams sourced within a RPL domain, the RPL Option >> MAY be included in the datagram itself. >=20 > I'm not sure I understand the difference or its motivation. Do you = really mean that a packet might not have the option until it hits the = first router? Or are you just talking about something that happens = internally on a host, but on the wire all packets would still have the = option? Also, since the tunnel (or something else) is used to include = the option for datagrams sourced outside the RPL domain, wouldn't it be = easier to just say this: >=20 > "Datagrams sent between nodes within an RPL domain MUST include an RPL = Option." Agree. >> For datagrams sourced >> outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in >> [RFC2473 ] SHOULD be used to = include a RPL Option. >=20 > This text should be aligned with whatever conclusion we will have for = the issue that I raised with the other document. Agree. See my response to your other review. >> To help avoid IP-layer fragmentation, the RPL Option has a maximum >> size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain >> SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop >> Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional >> extension headers or options needed within RPL domain). >> =20 >=20 > There's a same MTU issue here as in the other document. Agree. See my response to your other review. >> The action taken by using the RPL Option and the potential set of >> sub-TLVs carried within the RPL Option MUST be specified by the RFC >> of the protocol that use that option. No TLVs are defined in this >> document. >> =20 >=20 > I think you should define the behavior when a node encounters a = sub-TLV that it does not recognize. E.g., ignore and move on to the next = sub-TLV. Or do you want a stricter policy? In any case, for future = extensions it will be necessary to know how they are treated by legacy = RPL nodes. Yes, we need to define the behavior. I'm comfortable with specifying an = skip-over-and-continue policy for unknown sub-TLVs. >> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due >> to the added cost and complexity required to process and carry a >> datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers = ] describes >> how to avoid using IPv6-in-IPv6 tunneling in such specific cases and >> the risks involved. >> =20 >=20 > Again, the same comments as in the other draft. Please delete this = paragraph. Agree. >> For datagrams exiting the RPL domain, RPL Border Routers MUST remove >> the RPL Option from the datagram. If the RPL Option was included >> using tunneled mode and the RPL Border Router serves as the tunnel >> end-point, removing the outer IPv6 header serves to remove the RPL >> Option as well. Otherwise, the RPL Border Router assumes that the >> RPL Option was included using transport mode and MUST remove the RPL >> Option from the IPv6 Hop-by-Hop Option header. >> =20 >=20 > The part about removing the RPL option even in a non-tunneled case = relates to the issue of supporting that particular mode of operation. >=20 > But in addition, I wonder if you should write the above text not in = terms of packet modification operations but rather in terms of = forwarding decision outcomes. Like this, for instance: >=20 > "For datagrams destined to the RPL Border Router the router processes = the packet in the usual way. For instance, if the RPL Option was = included using tunneled mode and the RPL Border Router serves as the = tunnel end-point, the router removes the outer IPv6 header, at the same = removing the RPL Option as well. Datagrams destined elsewhere within the = same RPL domain are forwarded to the right interface. Datagrams destined = outside the RPL domain are dropped." The intent was to allow operation where a device within the RPL domain = could source a packet destined outside the RPL domain and not use = tunneling. In this case, we would like to simply remove the option at = the border router rather than drop the packet. Do you see cases where = removing the option is unacceptable? >> 6. Usage of the RPL Option >>=20 >> The RPL Option is only for use within a RPL domain. RPL routers = MUST >> process and include the RPL Option when forwarding datagrams to = other >> nodes within the RPL domain. Routers on the edge of a RPL domain >> MUST remove the RPL Option when forwarding datagrams to nodes = outside >> the RPL domain. >=20 > What is it that this section says that is not already covered by = sections 2 and 5: >=20 > Sect 2: Datagrams being forwarded within a RPL domain MUST include a = RPL Option. >=20 > Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 = header serves to remove the RPL Option as well. Otherwise, the RPL = Border Router assumes that the RPL Option was included using transport = mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option = header. Agree. Will remove the redundant text. >> This option may be used to mount several potential attacks since >> routers may be flooded by bogus datagram containing the RPL option. >> It is thus RECOMMENDED for routers to implement a rate limiter for >> datagrams using the RPL Option. >=20 > Please open this up a bit. What specific danger does flooding by bogus = datagrams and RPL options cause? What would be the default settings for = the rate limiter? The option contains information that can affect the operation of RPL. = For example, an inconsistent Rank value can cause a RPL router to reset = its trickle timer. After some careful thought, I'm not sure specifying a default setting = for a rate limiter is the best approach. Determining what is acceptable = vs. unacceptable can vary greatly between different deployments and = environments. But rather than rate limiting, how about the following: This option may be used to mount several potential attacks since routers may be flooded by bogus datagrams containing the RPL option. In particular, an inconsistent Rank value can cause a RPL router to reset its DIO Trickle timer. Thus, it is RECOMMENDED that a RPL router monitor triggers caused by receiving a RPL option and log conditions when the average rate is higher than expected. >> Opt Data Len: 8-bit field indicating the length of the option, in >> octets, excluding the Option Type and Opt Data Len fields. >>=20 >> Down 'O': 1-bit flag as defined in Section 11 of >> [I-D.ietf-roll-rpl = ]. >>=20 >> Rank-Error 'R': 1-bit flag as defined in Section 11 of >> [I-D.ietf-roll-rpl = ]. >>=20 >> Forwarding-Error 'F': 1-bit flag as defined in Section 11 of >> [I-D.ietf-roll-rpl = ]. >>=20 >> RPLInstanceID: 8-bit field as defined in Section 11 of >> [I-D.ietf-roll-rpl = ]. >>=20 >> SenderRank: 16-bit field as defined in Section 11 of >> [I-D.ietf-roll-rpl = ]. >>=20 >> Values within the RPL Option are expected to change en-route.=20 >=20 > This specification needs to describe what the behavior of a router is = with the content of the option. I think this is easy, you should just = add to the end: "The processing shall follow the rules described in = Section 11.2 of [roll-rpl]. Agree. > As an aside, the entire Section 11 is marked in roll-rpl as = non-normative. I don't think that's actually right as far as 11.2 goes, = because it contains tons of MUSTs and SHOULDs. Perhaps you want to fix = that in AUTH48... Right. Thanks. -- Jonathan Hui From kawashimam@vx.jp.nec.com Fri Jul 29 22:05:05 2011 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 82AAD21F8C9C for ; Fri, 29 Jul 2011 22:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n03OU2Vfyd0W for ; Fri, 29 Jul 2011 22:05:00 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id E831421F8CBE for ; Fri, 29 Jul 2011 22:04:59 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6U54uK2026646; Sat, 30 Jul 2011 14:04:56 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6U54ua13988; Sat, 30 Jul 2011 14:04:56 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6U54uHr011711; Sat, 30 Jul 2011 14:04:56 +0900 (JST) Received: from kogoro.jp.nec.com ([10.26.220.12] [10.26.220.12]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-122856; Sat, 30 Jul 2011 14:03:16 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-3158; Sat, 30 Jul 2011 14:03:15 +0900 To: "Rich Smith (rjsmith2)" Subject: RE: [Technical Errata Reported] RFC5952 (2872) In-reply-to: Message-Id: <20110730140316kawashimam@mail.jp.nec.com> References: Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Sat, 30 Jul 2011 14:03:16 +0900 Content-Type: text/plain; charset=iso-2022-jp 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, 30 Jul 2011 05:05:05 -0000 Hi Richard, >Now the algorithm cannot actually rely solely on the prefix, > but in fact must also examine the embedded address to make sure > it is a valid IPv4 unicast address. Exactly. >It would be much easier to code the algorithm to check only for > the prefixes "::" and "::ffff" (from RFC-4291), and then specifically > make an exception for the well-known IPv6 "::" (unknown) and "::1" > (loopback) addresses. This is what I have done now in my code, > which leaves the above mentioned four addresses (supposedly) incorrectly > formatted. Your code is correct. Moreover, except merely loopback address from the embedded address. Many codes(like a inet_ntop) are same behavior, or do nothing. But, I've never heard any trouble about "loopback" and "unspecified". Thus, it is reasonable code. Regards, Masanobu >I understand your point, which is that regardless of the prefix, if the embedded address is not a globally unique IPv4 address, then the special formatting does not apply. > >I still think it is not clear that this is the intended interpretation of RFC-5952 given the phrase "solely... through the use of a well-known prefix". Now the algorithm cannot actually rely solely on the prefix, but in fact must also examine the embedded address to make sure it is a valid IPv4 unicast address. > >This interpretation presents other irritations when coding RFC-5952's recommendations as an algorithm because the algorithm must make a special case for at least the following other addresses beyond :: and ::1. > > ::ffff:ffff (not ::255.255.255.255) > ::ffff:0:0 (not ::ffff:0.0.0.0) > ::ffff:0:1 (not ::ffff:0.0.0.1) > ::ffff:ffff:ffff (not ::ffff:255.255.255.255) > >It would be much easier to code the algorithm to check only for the prefixes "::" and "::ffff" (from RFC-4291), and then specifically make an exception for the well-known IPv6 "::" (unknown) and "::1" (loopback) addresses. This is what I have done now in my code, which leaves the above mentioned four addresses (supposedly) incorrectly formatted. > >Thanks for your prompt replies, and I will now leave you alone :-) > > --Rich > > >-----Original Message----- >From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] >Sent: Friday, July 29, 2011 11:42 AM >To: Rich Smith (rjsmith2) >Cc: ipv6@ietf.org >Subject: RE: [Technical Errata Reported] RFC5952 (2872) > > >Hi Richard, > >Thank you for your reply. > >>These sections clearly indicate that addresses with the first 96 bits >> all-zero have embedded IPv4 addresses. > >I don't think so. >You have missed note below in Section 2.5.5.1. > >=================================================================== >Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" >must be a globally-unique IPv4 unicast address. >=================================================================== > >::(Unspecified Address) and ::1(Loopback Address) are not > globally-unique IPv4 unicast address. >We should not use the 96-bit all-zeros prefix to identify > embedded IPv4 addresses. >We have to check last 32 bits of the address. >Thus, we don't need any addition. It is not an error. > > >>By the way, I want to thank you for authoring this RFC, since it solves >> a major problem we have, which is searching for and matching IPv6 addresses >> that are represented as text. > >Thank you for your feedback. >I'm so glad to hear that. :-) > >Regards, >Masanobu > > >>RFC-4291 (IP Version 6 Addressing Architecture), which RFC-5952 references, has a section 2.5.5 called "IPv6 Addresses with Embedded IPv4 Addresses". Presumably, this is what RFC-5952 is referring to. Section 2.5.5 two subsections. The first subsection 2.5.5.1 is called "IPv4-Compatible IPv6 Address". Let me copy it here: >> >>2.5.5.1. IPv4-Compatible IPv6 Address >> >> The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 >> transition. The format of the "IPv4-Compatible IPv6 address" is as >> follows: >> >> | 80 bits | 16 | 32 bits | >> +--------------------------------------+--------------------------+ >> |0000..............................0000|0000| IPv4 address | >> +--------------------------------------+----+---------------------+ >> >> Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" >> must be a globally-unique IPv4 unicast address. >> >> The "IPv4-Compatible IPv6 address" is now deprecated because the >> current IPv6 transition mechanisms no longer use these addresses. >> New or updated implementations are not required to support this >> address type. >> >>In addition, in RFC-4291 has a section 2.2 called "Text Representation of Addresses", which has the following paragraph regarding mixed IPv6 / IPv4 addresses: >> >> 3. An alternative form that is sometimes more convenient when dealing >> with a mixed environment of IPv4 and IPv6 nodes is >> x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of >> the six high-order 16-bit pieces of the address, and the 'd's are >> the decimal values of the four low-order 8-bit pieces of the >> address (standard IPv4 representation). Examples: >> >> 0:0:0:0:0:0:13.1.68.3 >> >> 0:0:0:0:0:FFFF:129.144.52.38 >> >> or in compressed form: >> >> ::13.1.68.3 >> >> ::FFFF:129.144.52.38 >> >>These sections clearly indicate that addresses with the first 96 bits all-zero have embedded IPv4 addresses. It does say that this prefix is deprecated, but deprecated or not, RFC-4291 clearly defines 96 bits of zero to contain an embedded IPv4 address, and then shows it in at least two examples. >> >>Thus my confusion from this paragraph in RFC-5952, section 5: >> >>5. Text Representation of Special Addresses >> >> Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and >> IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses >> embedded in the low-order 32 bits of the address. These addresses >> have a special representation that may mix hexadecimal and dot >> decimal notations. The decimal notation may be used only for the >> last 32 bits of the address. For these addresses, mixed notation is >> RECOMMENDED if the following condition is met: the address can be >> distinguished as having IPv4 addresses embedded in the lower 32 bits >> solely from the address field through the use of a well-known prefix. >> Such prefixes are defined in [RFC4291] and [RFC2765] at the time of >> this writing. If it is known by some external method that a given >> prefix is used to embed IPv4, it MAY be represented as mixed >> notation. Tools that provide options to specify prefixes that are >> (or are not) to be represented as mixed notation may be useful. >> >>specifically "solely... through the use of a well-known prefix" then citing RFC-4291. >> >>RFC-4291 does define 96 bits of zero as a well-known IPv4 address prefix, as I've pasted above. >> >>If it was your intention that readers of RFC-5952 IGNORE section 2.5.5.1 of RFC-4291, then YOU MUST MAKE THAT CLEAR because NOTHING in RFC-5952 says to do that. In fact, just the opposite is at least implied, and implied because sections 2.2 and 2.5.5.1 clearly show 96-bit all-zeros prefix indicate an embedded IPv4 address, and RFC-5952 references this standard with no additional clarification other than to go solely by the address prefix. >> >>So, I want it made clear EITHER: a) Ignore section 2.5.5.1 of RFC-4291, which is to say that the 96-bit all-zero prefix is NOT intended to indicate an embedded IPv4 address, or b) make it clear that at least :: and ::1 are not to be treated as embedded IPv4 addresses because they are, in fact, well-known IPv6 addresses. The latter was my suggestion from the original errata. >> >>If you require further clarification, then let me know. I don't know if I can make it any clearer. I've pasted the relevant sections of RFC-5952 and RFC-4291. But, if this is not enough, then I can try to provide more information if you need it. >> >>By the way, I want to thank you for authoring this RFC, since it solves a major problem we have, which is searching for and matching IPv6 addresses that are represented as text. >> >>Thanks. >> >> --Rich >> >> >>-----Original Message----- >>From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] >>Sent: Thursday, July 28, 2011 5:04 PM >>To: Rich Smith (rjsmith2); ipv6@ietf.org >>Subject: Re: [Technical Errata Reported] RFC5952 (2872) >> >> >>Hi Richard, >> >>Thank you for your report. >>I think this is better discussed in 6man. >> >>But I think it is not an error. >>Section 5 describes "Embedded IPv4 Addresses" for mixed notation. >>IPv6 unspecified address and IPv6 loopback address are out of scope. >> >>Moreover, the 80-bit all-zeros prefix is not "IPv4-compatible IPv6 address". >>We should not use the 80-bit all-zeros prefix to identify embedded IPv4 addresses. >> >>I didn't understand what you mean. >>Please describe more detail. >> >>Regards, >>Masanobu >> >> >>> >>>The following errata report has been submitted for RFC5952, >>>"A Recommendation for IPv6 Address Text Representation". >>> >>>-------------------------------------- >>>You may review the report below and at: >>>http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=2872 >>> >>>-------------------------------------- >>>Type: Technical >>>Reported by: Richard J. Smith >>> >>>Section: 5 >>> >>>Original Text >>>------------- >>>For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. >>> >>> >>>Corrected Text >>>-------------- >>>For these addresses, mixed notation is RECOMMENDED if the following conditions are met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix, and the entire address is not either the unspecified IPv6 address "::" or the loopback IPv6 address "::1". >>> >>> >>>Notes >>>----- >>>RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable. >>> >>>Instructions: >>>------------- >>>This errata is currently posted as "Reported". If necessary, please >>>use "Reply All" to discuss whether it should be verified or >>>rejected. When a decision is reached, the verifying party (IESG) >>>can log in to change the status and edit the report, if necessary. >>> >>>-------------------------------------- >>>RFC5952 (draft-ietf-6man-text-addr-representation-07) >>>-------------------------------------- >>>Title : A Recommendation for IPv6 Address Text Representation >>>Publication Date : August 2010 >>>Author(s) : S. Kawamura, M. Kawashima >>>Category : PROPOSED STANDARD >>>Source : IPv6 Maintenance >>>Area : Internet >>>Stream : IETF >>>Verifying Party : IESG >> >>$B!q(B(._.) >>======================================== >> NEC AccessTechnica, Ltd. >> Product Development Department >> Masanobu Kawashima >> kawashimam@vx.jp.nec.com >> http://www.necat.co.jp/ >>======================================== >> > >$B!q(B(._.) >======================================== > NEC AccessTechnica, Ltd. > Product Development Department > Masanobu Kawashima > kawashimam@vx.jp.nec.com > http://www.necat.co.jp/ >======================================== > $B!q(B(._.) ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From rjsmith2@cisco.com Fri Jul 29 10:25:29 2011 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 0458C5E8003 for ; Fri, 29 Jul 2011 10:25:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68pY3LW-FhpD for ; Fri, 29 Jul 2011 10:25:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B2BEA21F8AF7 for ; Fri, 29 Jul 2011 10:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rjsmith2@cisco.com; l=8098; q=dns/txt; s=iport; t=1311960327; x=1313169927; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=eRbQO5oHYetWWmWreGWKAWnMzRG3BZOJna/iSE3Uonw=; b=jBiOg98us41eEZCYHuwp+PlXHeOk0RRB8xzf5PGeAa8xUuz2Htpo27Uh ObXrN6fsPKG3wuKtkJUj/FfrfIZJ5QokFmbWAZLyyh6WVnbf/Yh6j941t I9iDWusyw+uhpOPmNshQUVDZJAK21tdr3LETFQJedFxhi+cO5ExzlVarl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAAC/sMk6rRDoJ/2dsb2JhbAA0AQEBAQMLCQESAQ5bBQIBCREBAwEBAgMGBQEGDQIBDQEBAwIBEzsDCwgBAQUBFgwbhDCTPY9Yd4kAI6BEjR8BkQmBKIF7KwSBXDRfBIdakC+LdEk X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7860094" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jul 2011 17:25:24 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6THPOhi005188; Fri, 29 Jul 2011 17:25:24 GMT Received: from xmb-sjc-21a.amer.cisco.com ([171.70.151.152]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 10:25:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Technical Errata Reported] RFC5952 (2872) Date: Fri, 29 Jul 2011 10:25:19 -0700 Message-ID: In-Reply-To: <20110729090410kawashimam@mail.jp.nec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC5952 (2872) Thread-Index: AcxNgy2g8b5p3oeKSxe6zP0I9vZLwwAjaQ4g References: <20110728201942.E9C0E98C4EF@rfc-editor.org> <20110729090410kawashimam@mail.jp.nec.com> From: "Rich Smith (rjsmith2)" To: "Masanobu Kawashima" , X-OriginalArrivalTime: 29 Jul 2011 17:25:23.0137 (UTC) FILETIME=[7F71AB10:01CC4E14] X-Mailman-Approved-At: Sun, 31 Jul 2011 08:57:04 -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: Fri, 29 Jul 2011 17:27:26 -0000 RFC-4291 (IP Version 6 Addressing Architecture), which RFC-5952 references, has a section 2.5.5 called "IPv6 Addresses with Embedded IPv4 Addresses". Presumably, this is what RFC-5952 is referring to. Section 2.5.5 two subsections. The first subsection 2.5.5.1 is called "IPv4-Compatible IPv6 Address". Let me copy it here: 2.5.5.1. IPv4-Compatible IPv6 Address The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 transition. The format of the "IPv4-Compatible IPv6 address" is as follows: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" must be a globally-unique IPv4 unicast address. The "IPv4-Compatible IPv6 address" is now deprecated because the current IPv6 transition mechanisms no longer use these addresses. New or updated implementations are not required to support this address type. In addition, in RFC-4291 has a section 2.2 called "Text Representation of Addresses", which has the following paragraph regarding mixed IPv6 / IPv4 addresses: 3. An alternative form that is sometimes more convenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). Examples: 0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:FFFF:129.144.52.38 or in compressed form: ::13.1.68.3 ::FFFF:129.144.52.38 These sections clearly indicate that addresses with the first 96 bits all-zero have embedded IPv4 addresses. It does say that this prefix is deprecated, but deprecated or not, RFC-4291 clearly defines 96 bits of zero to contain an embedded IPv4 address, and then shows it in at least two examples. Thus my confusion from this paragraph in RFC-5952, section 5: 5. Text Representation of Special Addresses Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses embedded in the low-order 32 bits of the address. These addresses have a special representation that may mix hexadecimal and dot decimal notations. The decimal notation may be used only for the last 32 bits of the address. For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. Such prefixes are defined in [RFC4291] and [RFC2765] at the time of this writing. If it is known by some external method that a given prefix is used to embed IPv4, it MAY be represented as mixed notation. Tools that provide options to specify prefixes that are (or are not) to be represented as mixed notation may be useful. specifically "solely... through the use of a well-known prefix" then citing RFC-4291. RFC-4291 does define 96 bits of zero as a well-known IPv4 address prefix, as I've pasted above. If it was your intention that readers of RFC-5952 IGNORE section 2.5.5.1 of RFC-4291, then YOU MUST MAKE THAT CLEAR because NOTHING in RFC-5952 says to do that. In fact, just the opposite is at least implied, and implied because sections 2.2 and 2.5.5.1 clearly show 96-bit all-zeros prefix indicate an embedded IPv4 address, and RFC-5952 references this standard with no additional clarification other than to go solely by the address prefix. So, I want it made clear EITHER: a) Ignore section 2.5.5.1 of RFC-4291, which is to say that the 96-bit all-zero prefix is NOT intended to indicate an embedded IPv4 address, or b) make it clear that at least :: and ::1 are not to be treated as embedded IPv4 addresses because they are, in fact, well-known IPv6 addresses. The latter was my suggestion from the original errata. If you require further clarification, then let me know. I don't know if I can make it any clearer. I've pasted the relevant sections of RFC-5952 and RFC-4291. But, if this is not enough, then I can try to provide more information if you need it. By the way, I want to thank you for authoring this RFC, since it solves a major problem we have, which is searching for and matching IPv6 addresses that are represented as text. Thanks. --Rich -----Original Message----- From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] Sent: Thursday, July 28, 2011 5:04 PM To: Rich Smith (rjsmith2); ipv6@ietf.org Subject: Re: [Technical Errata Reported] RFC5952 (2872) Hi Richard, Thank you for your report. I think this is better discussed in 6man. But I think it is not an error. Section 5 describes "Embedded IPv4 Addresses" for mixed notation. IPv6 unspecified address and IPv6 loopback address are out of scope. Moreover, the 80-bit all-zeros prefix is not "IPv4-compatible IPv6 address". We should not use the 80-bit all-zeros prefix to identify embedded IPv4 addresses. I didn't understand what you mean. Please describe more detail. Regards, Masanobu > >The following errata report has been submitted for RFC5952, >"A Recommendation for IPv6 Address Text Representation". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=2872 > >-------------------------------------- >Type: Technical >Reported by: Richard J. Smith > >Section: 5 > >Original Text >------------- >For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. > > >Corrected Text >-------------- >For these addresses, mixed notation is RECOMMENDED if the following conditions are met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix, and the entire address is not either the unspecified IPv6 address "::" or the loopback IPv6 address "::1". > > >Notes >----- >RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC5952 (draft-ietf-6man-text-addr-representation-07) >-------------------------------------- >Title : A Recommendation for IPv6 Address Text Representation >Publication Date : August 2010 >Author(s) : S. Kawamura, M. Kawashima >Category : PROPOSED STANDARD >Source : IPv6 Maintenance >Area : Internet >Stream : IETF >Verifying Party : IESG $B!q(J(._.) ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From rjsmith2@cisco.com Fri Jul 29 13:05:11 2011 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 A405121F8A62 for ; Fri, 29 Jul 2011 13:05:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC8DFXQWLGmd for ; Fri, 29 Jul 2011 13:05:05 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 775C421F8A56 for ; Fri, 29 Jul 2011 13:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rjsmith2@cisco.com; l=11181; q=dns/txt; s=iport; t=1311969905; x=1313179505; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=m+Cffy4f7zMzLB+pNGVdiw9YyUY19CBJNYdLyaW9VeA=; b=ReUFP5Ctd17LyNCH/a5EB+pzo6zM0ed88Z0HEj6k6r3x29fD4V2JENIj KCNCAuqmA66Hs8gmqJIX1R14e8nkGeqESxRRHlE8ncR5JVItOaMwrbkqK tVWzld9AdXzJ+K23nxxu+bMZ5KOccAL9dQascuNMaRl6rZ7IkhHtax7ro w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAADURM06rRDoI/2dsb2JhbAA0AQEBAQMLCQESAQ5PDAUCAQkRAQMBAQIDBgUBBg0CAQ0BAQMCARM7AwsIAQEFFwwbhDCTRo9Zd4kAI6B7jR8BkRKBKIF7KwSBXDRfBIdakC+LdEk X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7905194" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2011 20:05:04 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TK54A4011082; Fri, 29 Jul 2011 20:05:04 GMT Received: from xmb-sjc-21a.amer.cisco.com ([171.70.151.152]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 13:05:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Technical Errata Reported] RFC5952 (2872) Date: Fri, 29 Jul 2011 13:05:02 -0700 Message-ID: In-Reply-To: <20110730034136kawashimam@mail.jp.nec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC5952 (2872) Thread-Index: AcxOH0hHQ81nfyCSSNeLLl1pI+cVzQACVLNA References: <20110730034136kawashimam@mail.jp.nec.com> From: "Rich Smith (rjsmith2)" To: "Masanobu Kawashima" X-OriginalArrivalTime: 29 Jul 2011 20:05:04.0320 (UTC) FILETIME=[CE462C00:01CC4E2A] X-Mailman-Approved-At: Sun, 31 Jul 2011 08:57:04 -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: Fri, 29 Jul 2011 20:05:11 -0000 I understand your point, which is that regardless of the prefix, if the embedded address is not a globally unique IPv4 address, then the special formatting does not apply. I still think it is not clear that this is the intended interpretation of RFC-5952 given the phrase "solely... through the use of a well-known prefix". Now the algorithm cannot actually rely solely on the prefix, but in fact must also examine the embedded address to make sure it is a valid IPv4 unicast address. This interpretation presents other irritations when coding RFC-5952's recommendations as an algorithm because the algorithm must make a special case for at least the following other addresses beyond :: and ::1. ::ffff:ffff (not ::255.255.255.255) ::ffff:0:0 (not ::ffff:0.0.0.0) ::ffff:0:1 (not ::ffff:0.0.0.1) ::ffff:ffff:ffff (not ::ffff:255.255.255.255) It would be much easier to code the algorithm to check only for the prefixes "::" and "::ffff" (from RFC-4291), and then specifically make an exception for the well-known IPv6 "::" (unknown) and "::1" (loopback) addresses. This is what I have done now in my code, which leaves the above mentioned four addresses (supposedly) incorrectly formatted. Thanks for your prompt replies, and I will now leave you alone :-) --Rich -----Original Message----- From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] Sent: Friday, July 29, 2011 11:42 AM To: Rich Smith (rjsmith2) Cc: ipv6@ietf.org Subject: RE: [Technical Errata Reported] RFC5952 (2872) Hi Richard, Thank you for your reply. >These sections clearly indicate that addresses with the first 96 bits > all-zero have embedded IPv4 addresses. I don't think so. You have missed note below in Section 2.5.5.1. =================================================================== Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" must be a globally-unique IPv4 unicast address. =================================================================== ::(Unspecified Address) and ::1(Loopback Address) are not globally-unique IPv4 unicast address. We should not use the 96-bit all-zeros prefix to identify embedded IPv4 addresses. We have to check last 32 bits of the address. Thus, we don't need any addition. It is not an error. >By the way, I want to thank you for authoring this RFC, since it solves > a major problem we have, which is searching for and matching IPv6 addresses > that are represented as text. Thank you for your feedback. I'm so glad to hear that. :-) Regards, Masanobu >RFC-4291 (IP Version 6 Addressing Architecture), which RFC-5952 references, has a section 2.5.5 called "IPv6 Addresses with Embedded IPv4 Addresses". Presumably, this is what RFC-5952 is referring to. Section 2.5.5 two subsections. The first subsection 2.5.5.1 is called "IPv4-Compatible IPv6 Address". Let me copy it here: > >2.5.5.1. IPv4-Compatible IPv6 Address > > The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 > transition. The format of the "IPv4-Compatible IPv6 address" is as > follows: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > > Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > > The "IPv4-Compatible IPv6 address" is now deprecated because the > current IPv6 transition mechanisms no longer use these addresses. > New or updated implementations are not required to support this > address type. > >In addition, in RFC-4291 has a section 2.2 called "Text Representation of Addresses", which has the following paragraph regarding mixed IPv6 / IPv4 addresses: > > 3. An alternative form that is sometimes more convenient when dealing > with a mixed environment of IPv4 and IPv6 nodes is > x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of > the six high-order 16-bit pieces of the address, and the 'd's are > the decimal values of the four low-order 8-bit pieces of the > address (standard IPv4 representation). Examples: > > 0:0:0:0:0:0:13.1.68.3 > > 0:0:0:0:0:FFFF:129.144.52.38 > > or in compressed form: > > ::13.1.68.3 > > ::FFFF:129.144.52.38 > >These sections clearly indicate that addresses with the first 96 bits all-zero have embedded IPv4 addresses. It does say that this prefix is deprecated, but deprecated or not, RFC-4291 clearly defines 96 bits of zero to contain an embedded IPv4 address, and then shows it in at least two examples. > >Thus my confusion from this paragraph in RFC-5952, section 5: > >5. Text Representation of Special Addresses > > Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and > IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses > embedded in the low-order 32 bits of the address. These addresses > have a special representation that may mix hexadecimal and dot > decimal notations. The decimal notation may be used only for the > last 32 bits of the address. For these addresses, mixed notation is > RECOMMENDED if the following condition is met: the address can be > distinguished as having IPv4 addresses embedded in the lower 32 bits > solely from the address field through the use of a well-known prefix. > Such prefixes are defined in [RFC4291] and [RFC2765] at the time of > this writing. If it is known by some external method that a given > prefix is used to embed IPv4, it MAY be represented as mixed > notation. Tools that provide options to specify prefixes that are > (or are not) to be represented as mixed notation may be useful. > >specifically "solely... through the use of a well-known prefix" then citing RFC-4291. > >RFC-4291 does define 96 bits of zero as a well-known IPv4 address prefix, as I've pasted above. > >If it was your intention that readers of RFC-5952 IGNORE section 2.5.5.1 of RFC-4291, then YOU MUST MAKE THAT CLEAR because NOTHING in RFC-5952 says to do that. In fact, just the opposite is at least implied, and implied because sections 2.2 and 2.5.5.1 clearly show 96-bit all-zeros prefix indicate an embedded IPv4 address, and RFC-5952 references this standard with no additional clarification other than to go solely by the address prefix. > >So, I want it made clear EITHER: a) Ignore section 2.5.5.1 of RFC-4291, which is to say that the 96-bit all-zero prefix is NOT intended to indicate an embedded IPv4 address, or b) make it clear that at least :: and ::1 are not to be treated as embedded IPv4 addresses because they are, in fact, well-known IPv6 addresses. The latter was my suggestion from the original errata. > >If you require further clarification, then let me know. I don't know if I can make it any clearer. I've pasted the relevant sections of RFC-5952 and RFC-4291. But, if this is not enough, then I can try to provide more information if you need it. > >By the way, I want to thank you for authoring this RFC, since it solves a major problem we have, which is searching for and matching IPv6 addresses that are represented as text. > >Thanks. > > --Rich > > >-----Original Message----- >From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] >Sent: Thursday, July 28, 2011 5:04 PM >To: Rich Smith (rjsmith2); ipv6@ietf.org >Subject: Re: [Technical Errata Reported] RFC5952 (2872) > > >Hi Richard, > >Thank you for your report. >I think this is better discussed in 6man. > >But I think it is not an error. >Section 5 describes "Embedded IPv4 Addresses" for mixed notation. >IPv6 unspecified address and IPv6 loopback address are out of scope. > >Moreover, the 80-bit all-zeros prefix is not "IPv4-compatible IPv6 address". >We should not use the 80-bit all-zeros prefix to identify embedded IPv4 addresses. > >I didn't understand what you mean. >Please describe more detail. > >Regards, >Masanobu > > >> >>The following errata report has been submitted for RFC5952, >>"A Recommendation for IPv6 Address Text Representation". >> >>-------------------------------------- >>You may review the report below and at: >>http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=2872 >> >>-------------------------------------- >>Type: Technical >>Reported by: Richard J. Smith >> >>Section: 5 >> >>Original Text >>------------- >>For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. >> >> >>Corrected Text >>-------------- >>For these addresses, mixed notation is RECOMMENDED if the following conditions are met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix, and the entire address is not either the unspecified IPv6 address "::" or the loopback IPv6 address "::1". >> >> >>Notes >>----- >>RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable. >> >>Instructions: >>------------- >>This errata is currently posted as "Reported". If necessary, please >>use "Reply All" to discuss whether it should be verified or >>rejected. When a decision is reached, the verifying party (IESG) >>can log in to change the status and edit the report, if necessary. >> >>-------------------------------------- >>RFC5952 (draft-ietf-6man-text-addr-representation-07) >>-------------------------------------- >>Title : A Recommendation for IPv6 Address Text Representation >>Publication Date : August 2010 >>Author(s) : S. Kawamura, M. Kawashima >>Category : PROPOSED STANDARD >>Source : IPv6 Maintenance >>Area : Internet >>Stream : IETF >>Verifying Party : IESG > >$B!q(J(._.) >======================================== > NEC AccessTechnica, Ltd. > Product Development Department > Masanobu Kawashima > kawashimam@vx.jp.nec.com > http://www.necat.co.jp/ >======================================== > $B!q(J(._.) ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ========================================