From owner-ipng@sunroof.eng.sun.com Tue Jul 1 04:25:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61BP606004487; Tue, 1 Jul 2003 04:25:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h61BP64F004486; Tue, 1 Jul 2003 04:25:06 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61BP006004472 for ; Tue, 1 Jul 2003 04:25:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h61BMsGq013107 for ; Tue, 1 Jul 2003 04:22:54 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h61BMlKo004289 for ; Tue, 1 Jul 2003 04:22:48 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07092; Tue, 1 Jul 2003 07:22:43 -0400 (EDT) Message-Id: <200307011122.HAA07092@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt Date: Tue, 01 Jul 2003 07:22:43 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : An analysis of IPv6 anycast Author(s) : J. Hagino, K. Ettican Filename : draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt Pages : 12 Date : 2003-6-30 The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] defined as of today. The goals of the draft are (1) to understand the currently-defined IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification. The document was made possible by input from ipngwg DNS discovery design team. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151331.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 1 04:25:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61BPB06004497; Tue, 1 Jul 2003 04:25:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h61BPBWA004496; Tue, 1 Jul 2003 04:25:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61BP306004479 for ; Tue, 1 Jul 2003 04:25:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h61BMvGq013109 for ; Tue, 1 Jul 2003 04:22:57 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h61BMpKo004311 for ; Tue, 1 Jul 2003 04:22:51 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07114; Tue, 1 Jul 2003 07:22:47 -0400 (EDT) Message-Id: <200307011122.HAA07114@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2096-update-04.txt Date: Tue, 01 Jul 2003 07:22:47 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Forwarding Table MIB Author(s) : M. Wasserman, B. Haberman Filename : draft-ietf-ipv6-rfc2096-update-04.txt Pages : 34 Date : 2003-6-30 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets, in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2096-update-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2096-update-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151340.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 1 04:25:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61BPI06004500; Tue, 1 Jul 2003 04:25:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h61BPHFI004499; Tue, 1 Jul 2003 04:25:17 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61BP906004489 for ; Tue, 1 Jul 2003 04:25:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h61BN2Gq013134 for ; Tue, 1 Jul 2003 04:23:02 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h61BMuKo004344 for ; Tue, 1 Jul 2003 04:22:57 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07132; Tue, 1 Jul 2003 07:22:53 -0400 (EDT) Message-Id: <200307011122.HAA07132@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-04.txt Date: Tue, 01 Jul 2003 07:22:52 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-04.txt Pages : 20 Date : 2003-6-30 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-node-requirements-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-node-requirements-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-node-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-node-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151413.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 1 09:03:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61G3k06006419; Tue, 1 Jul 2003 09:03:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h61G3kgt006418; Tue, 1 Jul 2003 09:03:46 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61G3g06006411 for ; Tue, 1 Jul 2003 09:03:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h61G1aGq009204 for ; Tue, 1 Jul 2003 09:01:36 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h61G1VKo027655 for ; Tue, 1 Jul 2003 09:01:31 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h61G1T205238 for ; Tue, 1 Jul 2003 11:01:29 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jul 2003 11:01:30 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF6486B6@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'ipng@sunroof.eng.sun.com'" Subject: FW: I-D ACTION:draft-ietf-ipv6-node-requirements-04.txt Date: Tue, 1 Jul 2003 11:01:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C33FE9.F6A1DD1E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C33FE9.F6A1DD1E Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33FE9.F6A1DD1E" ------_=_NextPart_001_01C33FE9.F6A1DD1E Content-Type: text/plain; charset="iso-8859-1" Hi, After reading Section 6.1 Transition Mechanisms, I would suggest the following minor change: 6.1 Transition Mechanisms IPv6 nodes SHOULD use native address instead of transition-based addressing >>INSERT (according to the algorithms defined in RFC 3484). Regards, Pete -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 01, 2003 6:23 AM Cc: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-04.txt Pages : 20 Date : 2003-6-30 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-node-requirements-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-node-requirements-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C33FE9.F6A1DD1E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-ietf-ipv6-node-requirements-04.txt

Hi,

After reading Section 6.1 Transition Mechanisms, I = would suggest the following minor change:

6.1 Transition Mechanisms

    IPv6 nodes SHOULD use native = address instead of transition-based addressing >>INSERT = (according to the algorithms defined in RFC 3484).

Regards,

Pete

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Tuesday, July 01, 2003 6:23 AM
Cc: ipng@sunroof.eng.sun.com
Subject: I-D = ACTION:draft-ietf-ipv6-node-requirements-04.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the IP Version 6 = Working Group Working Group of the IETF.

        Title           : = IPv6 Node Requirements
        Author(s)       : J. = Loughney
        Filename        : = draft-ietf-ipv6-node-requirements-04.txt
        Pages           : = 20
        Date    =         : 2003-6-30
       =20
This document defines requirements for IPv6 = nodes.  It is expected
that IPv6 will be deployed in a wide range of = devices and situations.
Specifying the requirements for IPv6 nodes allows = IPv6 to function
well and interoperate in a large number of = situations and
deployments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-no= de-requirements-04.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-ietf-ipv6-node-requirements-04.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-ipv6-node-requirements-04.txt".
       =20
NOTE:   The mail server at ietf.org can = return the document in
        MIME-encoded form by using the "mpack" = utility.  To use this
        feature, = insert the command "ENCODING mime" before the = "FILE"
        command.  To decode the response(s), you will need = "munpack" or
        a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
        exhibit = different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have = been split
        up into = multiple messages), so check your local documentation on
        how to = manipulate these messages.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C33FE9.F6A1DD1E-- ------_=_NextPart_000_01C33FE9.F6A1DD1E Content-Type: message/rfc822 To: Subject: Date: Tue, 1 Jul 2003 07:57:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C33FE9.F6A1DD1E" ------_=_NextPart_002_01C33FE9.F6A1DD1E Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C33FE9.F6A1DD1E" ------_=_NextPart_003_01C33FE9.F6A1DD1E Content-Type: text/plain ------_=_NextPart_003_01C33FE9.F6A1DD1E Content-Type: text/html

  ------_=_NextPart_003_01C33FE9.F6A1DD1E-- ------_=_NextPart_002_01C33FE9.F6A1DD1E Content-Type: application/octet-stream; name="ATT10300" Content-Disposition: attachment; filename="ATT10300" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-node-requirements-04.txt ------_=_NextPart_002_01C33FE9.F6A1DD1E Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-ipv6-node-requirements-04"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C33FE9.F6A1DD1E-- ------_=_NextPart_000_01C33FE9.F6A1DD1E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 1 15:31:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61MVD06008530; Tue, 1 Jul 2003 15:31:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h61MVDJL008529; Tue, 1 Jul 2003 15:31:13 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h61MVA06008522 for ; Tue, 1 Jul 2003 15:31:10 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h61MT4UY014890 for ; Tue, 1 Jul 2003 15:29:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h61MSvvc014921 for ; Tue, 1 Jul 2003 16:28:58 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA05458; Tue, 1 Jul 2003 15:28:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h61MSvh07017; Tue, 1 Jul 2003 15:28:57 -0700 X-mProtect: <200307012228> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAd2XMY; Tue, 01 Jul 2003 15:28:54 PDT Message-Id: <4.3.2.7.2.20030701131314.02a684c0@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Jul 2003 15:28:26 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: IPv6 w.g. Last Call on "IPv6 Node Requirements" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Informational RFC: Title : IPv6 Node Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-04.txt Pages : 20 Date : 2003-6-30 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on 15 July 2003. Bob Hinden / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 03:57:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62Avf06011675; Wed, 2 Jul 2003 03:57:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h62Avek7011674; Wed, 2 Jul 2003 03:57:40 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62AvY06011667 for ; Wed, 2 Jul 2003 03:57:34 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h62AtRUY001277 for ; Wed, 2 Jul 2003 03:55:28 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h62AtLvc002470 for ; Wed, 2 Jul 2003 04:55:22 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02608; Wed, 2 Jul 2003 06:55:20 -0400 (EDT) Message-Id: <200307021055.GAA02608@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-02.txt Date: Wed, 02 Jul 2003 06:55:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Requirements for IPv6 prefix delegation Author(s) : S. Miyakawa, R Droms Filename : draft-ietf-ipv6-prefix-delegation-requirement-02.txt Pages : 6 Date : 2003-7-1 This document describes requirements about how an IPv6 address prefix should be delegated to an IPv6 subscriber's network (or 'site'). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-prefix-delegation-requirement-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1134529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-prefix-delegation-requirement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134529.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 04:05:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62B5r06012010; Wed, 2 Jul 2003 04:05:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h62B5rob012009; Wed, 2 Jul 2003 04:05:53 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62B5o06012002 for ; Wed, 2 Jul 2003 04:05:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h62B3iGq026697 for ; Wed, 2 Jul 2003 04:03:44 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h62B3XKo025447 for ; Wed, 2 Jul 2003 04:03:37 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 02 Jul 2003 16:44:22 +0530 Received: from sivarka (sivarka.future.futsoft.com [10.20.6.73]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h62AwJ0r017975 for ; Wed, 2 Jul 2003 16:28:20 +0530 Reply-To: From: "Sivaramakrishnan A" To: Subject: IPv6 Tunnel concepts Date: Wed, 2 Jul 2003 16:31:33 +0530 Message-Id: <000d01c34089$4d7c6100$4906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, There are so many concepts in IPv6 tunnels such as: v6 over v4 6 to 4 v4 compatible v6 address v4 mapped v6 address I would like to know the clear distinction among these concepts. Can anyone help? regards, Siva *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 13:34:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62KYW06014976; Wed, 2 Jul 2003 13:34:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h62KYWJL014972; Wed, 2 Jul 2003 13:34:32 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62KYO06014965 for ; Wed, 2 Jul 2003 13:34:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h62KWIUY018011 for ; Wed, 2 Jul 2003 13:32:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h62KWBfU006894 for ; Wed, 2 Jul 2003 13:32:12 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12630; Wed, 2 Jul 2003 16:32:08 -0400 (EDT) Message-Id: <200307022032.QAA12630@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2011-update-03.txt Date: Wed, 02 Jul 2003 16:32:08 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-03.txt Pages : 114 Date : 2003-7-2 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465 and 2466. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2011-update-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161513.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 15:11:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62MBv06016019; Wed, 2 Jul 2003 15:11:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h62MBvwQ016018; Wed, 2 Jul 2003 15:11:57 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62MBr06016011 for ; Wed, 2 Jul 2003 15:11:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h62M9lUY025397 for ; Wed, 2 Jul 2003 15:09:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h62M9eKo020802 for ; Wed, 2 Jul 2003 15:09:41 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23365; Wed, 2 Jul 2003 18:09:36 -0400 (EDT) Message-Id: <200307022209.SAA23365@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-link-scoped-mcast-03.txt Date: Wed, 02 Jul 2003 18:09:36 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Link Scoped IPv6 Multicast Addresses Author(s) : J. Park et al. Filename : draft-ietf-ipv6-link-scoped-mcast-03.txt Pages : 5 Date : 2003-7-2 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in the serverless environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-link-scoped-mcast-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2180955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-link-scoped-mcast-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2180955.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 15:48:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62MmV06017422; Wed, 2 Jul 2003 15:48:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h62MmU9n017421; Wed, 2 Jul 2003 15:48:30 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62MmR06017414 for ; Wed, 2 Jul 2003 15:48:27 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h62MkLUY004495 for ; Wed, 2 Jul 2003 15:46:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h62MkEZV019674 for ; Wed, 2 Jul 2003 16:46:15 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA18898; Wed, 2 Jul 2003 15:46:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h62MkBG17642; Wed, 2 Jul 2003 15:46:11 -0700 X-mProtect: <200307022246> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRHjvBu; Wed, 02 Jul 2003 15:46:09 PDT Message-Id: <4.3.2.7.2.20030702140452.02a49658@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 15:45:50 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: IPv6 w.g. Last Call on "IPv6 Node Information Queries" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as a Proposed Standard: Title : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-10.txt Pages : 12 Date : 2003-6-27 This document was previously sent to the IESG for Proposed Standard. The IESG responded with a number of comments. The IESG discussion can be found at: https://www.ietf.org/IESG/EVALUATIONS/draft-ietf-ipngwg-icmp-name-lookups.bal The chairs believe that this draft resolves the issues raised by the IESG. Given the time that has elapsed, we thought it was important to have another working group last call. Changes in this draft include: - Move applicability statement to start of document and update introduction. - Removed Qtypes query capabilities - Limit returned TTL in node name to zero and removed text describing non-zero TTLs. - Remove text about A6 records - Change to have all new Qtypes require IETF approval - Updated security considerations The reasoning behind this set of changes was to resolve the issues raised by the IESG and to maintain comparability with current shipping code. Node Information Queries is shipping in the KAME and USAGI distributions and has been found to be very useful for deploying IPv6 service and debugging operational problems. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on 16 July 2003. Bob Hinden / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 16:19:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62NJ606017744; Wed, 2 Jul 2003 16:19:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h62NJ6JA017743; Wed, 2 Jul 2003 16:19:06 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62NIx06017721 for ; Wed, 2 Jul 2003 16:18:59 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h62NGrUY011547 for ; Wed, 2 Jul 2003 16:16:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h62NGm1J003473 for ; Wed, 2 Jul 2003 17:16:48 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA20792; Wed, 2 Jul 2003 16:16:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h62NGkS22372; Wed, 2 Jul 2003 16:16:46 -0700 X-mProtect: <200307022316> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaLWRb6; Wed, 02 Jul 2003 16:16:43 PDT Message-Id: <4.3.2.7.2.20030702160927.02a49658@mailhost.iprg.nokia.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 16:15:59 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: IPv6 w.g. Last Call on "Management Information Base for the Internet Protocol" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as a Proposed Standard: Title : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-03.txt Pages : 114 Date : 2003-7-2 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end on 16 July 2003. Bob Hinden / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 16:19:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62NJB06017747; Wed, 2 Jul 2003 16:19:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h62NJAne017746; Wed, 2 Jul 2003 16:19:10 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h62NJ106017729 for ; Wed, 2 Jul 2003 16:19:01 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h62NGtGq020379 for ; Wed, 2 Jul 2003 16:16:55 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h62NGo1J003498 for ; Wed, 2 Jul 2003 17:16:50 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA20813; Wed, 2 Jul 2003 16:16:49 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h62NGmr22672; Wed, 2 Jul 2003 16:16:48 -0700 X-mProtect: <200307022316> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpGWvpE; Wed, 02 Jul 2003 16:16:44 PDT Message-Id: <4.3.2.7.2.20030702161204.02c3ff08@mailhost.iprg.nokia.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 16:16:26 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: IPv6 w.g. Last Call on "Management Information Base for the TCP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as a Proposed Standard: Title : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipv6-rfc2012-update-03.txt Pages : 25 Date : 2003-6-26 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on 16 July 2003. Bob Hinden / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 3 00:10:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h637AL06020766; Thu, 3 Jul 2003 00:10:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h637ALZU020765; Thu, 3 Jul 2003 00:10:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h637AI06020758 for ; Thu, 3 Jul 2003 00:10:18 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6378BUY002628 for ; Thu, 3 Jul 2003 00:08:12 -0700 (PDT) Received: from mailout3.samsung.com ([203.254.224.33]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h63785vc003713 for ; Thu, 3 Jul 2003 01:08:06 -0600 (MDT) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHF00C09T5HF5@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Jul 2003 16:08:05 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHF00JDIT5EIX@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Jul 2003 16:08:02 +0900 (KST) Received: from ep_was17 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HHF0009WT5EGA@ms3.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Jul 2003 16:08:02 +0900 (KST) Content-return: prohibited Date: Thu, 03 Jul 2003 16:08:05 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: IPv6 w.g. Last Call on "Management Information Base for the Internet Protocol" To: Bob Hinden & Margaret Wasserman , syam@samsung.com, soohong.park@samsung.com Cc: ipng@sunroof.eng.sun.com Reply-to: soohong.park@samsung.com Message-id: <0HHF0009XT5EGA@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030703160805@soohong.park X-MTR: 20030703160805@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks Today, 802.11 technology is a famous L2 tech. in our market. and most guys agree that. However there are some problem to use an IPv6 address autoconfiguration since 802.11 station can not detect duplicated address with same MAC address. Please let me know your view on this.... I believe it should be considered as one of node requirement... http://home.megapass.co.kr/~natpp00/IPv6DADfor802.11.txt 1. Introduction In order to generate unique address, an IPv6 nodes has to perform DAD (Duplicate Address Detection) procedure when the IPv6 node tries to make its own IPv6 address including link-local and global address. If IPv6 node detects address duplication by Neighbor Advertisement message from duplicated node, then the duplicated address can not be used for this node, then IPv6 node MUST generate its own address by other mechanism like DHCP or Random Interface ID generation etc. Generally, address duplication is happened to the same Interface ID which is composed of 48bit/64bit MAC address. Therefore, when same MAC address is existed in the same link, one of these nodes can not make its IPv6 address using address autoconfiguration mechanism. However, if the same MAC address is existed in the same link as 802.11, there are some problems and considerations for IPv6 address autoconfiguration. IPv6 node in 802.11 environment will never be able to receive the DAD packets if its MAC address is same as another node, because of the frame filtering based on the source MAC address. In this case the DAD always succeeds even though the addresses are duplicate. This memo tries to consider above problem and suggest possible solutions. Note that this consideration SHOULD be discussed at the IPv6 node requirements. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics TEL:+82-31-200-4508 FAX:+82-31-200-3147 mailto:soohong.park@samsung.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 3 00:12:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h637Cd06020799; Thu, 3 Jul 2003 00:12:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h637CdPp020798; Thu, 3 Jul 2003 00:12:39 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h637Ca06020791 for ; Thu, 3 Jul 2003 00:12:36 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h637ATGq000236 for ; Thu, 3 Jul 2003 00:10:29 -0700 (PDT) Received: from mailout2.samsung.com ([203.254.224.25]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h637AMvc004803 for ; Thu, 3 Jul 2003 01:10:23 -0600 (MDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHF00B01T9AYI@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Jul 2003 16:10:22 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHF00AZ7T99HJ@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Jul 2003 16:10:21 +0900 (KST) Received: from ep_was15 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HHF00K2LT999U@ms3.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Jul 2003 16:10:21 +0900 (KST) Content-return: prohibited Date: Thu, 03 Jul 2003 16:10:20 +0900 From: =?EUC-KR?B?udq89sir?= Subject: [I-D] IPv6 DAD Consideration for 802.11 Environment To: Bob Hinden & Margaret Wasserman , syam@samsung.com, soohong.park@samsung.com Cc: ipng@sunroof.eng.sun.com Reply-to: soohong.park@samsung.com Message-id: <0HHF00K2MT999U@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030703161020@soohong.park X-MTR: 20030703161020@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks Today, 802.11 technology is the most famous L2 tech in our market. and most guys agree that. However there are some problem to use an IPv6 address autoconfiguration since 802.11 station can not detect duplicated address with same MAC address. Please let me know your view on this.... I believe it should be considered as one of node requirement... http://home.megapass.co.kr/~natpp00/IPv6DADfor802.11.txt 1. Introduction In order to generate unique address, an IPv6 nodes has to perform DAD (Duplicate Address Detection) procedure when the IPv6 node tries to make its own IPv6 address including link-local and global address. If IPv6 node detects address duplication by Neighbor Advertisement message from duplicated node, then the duplicated address can not be used for this node, then IPv6 node MUST generate its own address by other mechanism like DHCP or Random Interface ID generation etc. Generally, address duplication is happened to the same Interface ID which is composed of 48bit/64bit MAC address. Therefore, when same MAC address is existed in the same link, one of these nodes can not make its IPv6 address using address autoconfiguration mechanism. However, if the same MAC address is existed in the same link as 802.11, there are some problems and considerations for IPv6 address autoconfiguration. IPv6 node in 802.11 environment will never be able to receive the DAD packets if its MAC address is same as another node, because of the frame filtering based on the source MAC address. In this case the DAD always succeeds even though the addresses are duplicate. This memo tries to consider above problem and suggest possible solutions. Note that this consideration SHOULD be discussed at the IPv6 node requirements. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics TEL:+82-31-200-4508 FAX:+82-31-200-3147 mailto:soohong.park@samsung.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 3 08:52:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h63Fqq06022941; Thu, 3 Jul 2003 08:52:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h63FqqWH022940; Thu, 3 Jul 2003 08:52:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h63Fqn06022932 for ; Thu, 3 Jul 2003 08:52:49 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h63FofUu016567 for ; Thu, 3 Jul 2003 08:50:41 -0700 (PDT) Received: from gsyc.escet.urjc.es (gsyc064.dat.escet.urjc.es [193.147.71.64]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h63FoZKo010478 for ; Thu, 3 Jul 2003 08:50:35 -0700 (PDT) Received: from localhost (eva@localhost) by gsyc.escet.urjc.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id RAA06739; Thu, 3 Jul 2003 17:50:28 +0200 Date: Thu, 3 Jul 2003 17:50:27 +0200 (CEST) From: Eva Castro Barbero To: sivarka@future.futsoft.com cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Tunnel concepts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk El mi, 02-07-2003 a las 13:01, Sivaramakrishnan A escribi: > Hi, > > There are so many concepts in IPv6 tunnels such as: > > v6 over v4 > 6 to 4 See RFC 2893 > v4 compatible v6 address > v4 mapped v6 address See RFC 2373. And IPv4-translatable IPv6 address at RFC 2765. eva -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 3 10:35:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h63HZZ06023369; Thu, 3 Jul 2003 10:35:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h63HZZ7p023368; Thu, 3 Jul 2003 10:35:35 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h63HZW06023361 for ; Thu, 3 Jul 2003 10:35:32 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h63HXPUu015167 for ; Thu, 3 Jul 2003 10:33:25 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h63HXJDT005887 for ; Thu, 3 Jul 2003 11:33:19 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15464 for ; Thu, 3 Jul 2003 10:33:19 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h63HXIU19948; Thu, 3 Jul 2003 10:33:18 -0700 X-mProtect: <200307031733> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhbGTEu; Thu, 03 Jul 2003 10:33:16 PDT Message-Id: <4.3.2.7.2.20030703102632.02a57230@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jul 2003 10:33:01 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Fwd: I-D ACTION:draft-hinden-ipv6-global-local-addr-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The significant (non-editorial) change in this version of the draft was changing the title and name of addresses to "Unique Local IPv6 Unicast Addresses" with abbreviation of "Local IPv6 addresses". The authors believe this is a more accurate description and makes the document read better. Bob >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-hinden-ipv6-global-local-addr-02.txt >Date: Wed, 02 Jul 2003 16:31:21 -0400 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden > Filename : draft-hinden-ipv6-global-local-addr-02.txt > Pages : 13 > Date : 2003-7-2 > >This document defines an unicast address format that is globally >unique and is intended for local communications, usually inside of a >site. They are not expected to be routable on the global Internet >given current routing technology. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-hinden-ipv6-global-local-addr-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-7-2161346.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-02.txt > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 4 01:38:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h648cK06026852; Fri, 4 Jul 2003 01:38:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h648cKku026851; Fri, 4 Jul 2003 01:38:20 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h648cH06026844 for ; Fri, 4 Jul 2003 01:38:17 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h648a8Uu012972 for ; Fri, 4 Jul 2003 01:36:08 -0700 (PDT) Received: from archipelago.apjii.or.id (archipelago.apjii.or.id [202.153.128.23]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h648a1DT024927 for ; Fri, 4 Jul 2003 02:36:03 -0600 (MDT) Received: from hostmaster.apjii.or.id (ip-161-84.dtp.net.id [202.43.161.84] (may be forged)) by archipelago.apjii.or.id (8.12.8/8.12.8) with ESMTP id h648Vk9d018477 for ; Fri, 4 Jul 2003 15:31:59 +0700 (JVT) Message-Id: <5.1.1.6.1.20030704151425.0262cec0@pop3.apjii.or.id> X-Sender: ahmad@pop3.apjii.or.id X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 04 Jul 2003 15:32:17 +0700 To: ipng@sunroof.eng.sun.com From: Ahmad Alkazimy Subject: Multihoming on IPv6 ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I'm a new commers in here, so sorry if my question are bothering all of you. I would like to know about the minimum prefix of IPv6 that can be announced by Customer-Site when they are Multihomed with another ISP's ? Is there any RFC's regarding on this one ? Who should announced the second prefix that they received from another ISP's: the customer-site add the prefix on their routing policy or the ISP's have to add the second prefix on their routing policy. Regards, Ahmad Alkazimy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 4 03:43:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h64AhY06027622; Fri, 4 Jul 2003 03:43:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h64AhY5e027621; Fri, 4 Jul 2003 03:43:34 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h64AhU06027614 for ; Fri, 4 Jul 2003 03:43:30 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h64AfKUY012341 for ; Fri, 4 Jul 2003 03:41:20 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h64AfE1J015121 for ; Fri, 4 Jul 2003 04:41:15 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h64AfD922965 for ; Fri, 4 Jul 2003 13:41:13 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Jul 2003 13:41:13 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Jul 2003 13:41:13 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Jul 2003 13:41:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: IPv6 w.g. Last Call on "Management Information Base for the Internet Protocol" Date: Fri, 4 Jul 2003 13:41:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Management Information Base for the Internet Protocol" Thread-Index: AcNBPJNHZ7zaI53fSJqspNLlmmrvtgA28kxg From: To: , , Cc: X-OriginalArrivalTime: 04 Jul 2003 10:41:12.0810 (UTC) FILETIME=[C9C22CA0:01C34218] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h64AhU06027615 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Daniel, > Today, 802.11 technology is a famous L2 tech. in our market. and > most guys agree that. However there are some problem to use an IPv6 address > autoconfiguration since 802.11 station can not detect duplicated address > with same MAC address. > > Please let me know your view on this.... I believe it should be considered > as one of node requirement... If I understand you correctly, you are suggesting that DAD has a problem with 802.11. Perhaps it is best if you 2461 that are problematic. With regards to the Node Requirements draft, I don't think there is any is anything we can put into that document, as the requirement is meant to detail current requirements, with regards to existing RFCs. If there are bugs in the RFCs, we need to fix them, not in the node requirements. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 4 04:12:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h64BC606028006; Fri, 4 Jul 2003 04:12:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h64BC5DZ028005; Fri, 4 Jul 2003 04:12:05 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h64BC206027998 for ; Fri, 4 Jul 2003 04:12:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h64B9rUY016921 for ; Fri, 4 Jul 2003 04:09:53 -0700 (PDT) Received: from mailout1.samsung.com ([203.254.224.24]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h64B9lfU011393 for ; Fri, 4 Jul 2003 04:09:48 -0700 (PDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHH00I01Z0BEJ@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 04 Jul 2003 20:09:47 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHH00HFJZ0AZV@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 04 Jul 2003 20:09:47 +0900 (KST) Received: from ep_was22 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HHH002J3Z0AEQ@ms3.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 04 Jul 2003 20:09:46 +0900 (KST) Content-return: prohibited Date: Fri, 04 Jul 2003 20:09:46 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: RE: IPv6 DAD Consideration for 802.11 environment To: john.loughney@nokia.com Cc: hinden@iprg.nokia.com, syam@samsung.com, ipng@sunroof.eng.sun.com Reply-to: soohong.park@samsung.com Message-id: <0HHH002J4Z0AEQ@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030704200946@soohong.park X-MTR: 20030704200946@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John Please look into my inline comment >If I understand you correctly, you are suggesting that DAD has a problem with 802.11. >Perhaps it is best if you 2461 that are problematic. Please refer to below rough draft http://home.megapass.co.kr/~natpp00/IPv6DADfor802.11.txt >If there are bugs in the RFCs, we >need to fix them, not in the node requirements. I see, basically I don't want to disturb the processing of node requirment. I think that I should process this draft as informational RFC. Thanks Daniel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 4 11:34:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h64IYv06029727; Fri, 4 Jul 2003 11:34:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h64IYvP7029726; Fri, 4 Jul 2003 11:34:57 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h64IYr06029719 for ; Fri, 4 Jul 2003 11:34:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h64IWiUY007904 for ; Fri, 4 Jul 2003 11:32:44 -0700 (PDT) Received: from server2003.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h64IWcKo029859 for ; Fri, 4 Jul 2003 11:32:39 -0700 (PDT) Subject: RE: Multihoming on IPv6 ? Date: Fri, 4 Jul 2003 11:32:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Content-class: urn:content-classes:message X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.5.6940.0 X-MS-TNEF-Correlator: Thread-Topic: Multihoming on IPv6 ? Thread-Index: AcNCCDIlPIU50EqpQJWwPfYdE34oIwAUa3Xg From: "Michel Py" To: "Ahmad Alkazimy" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h64IYs06029720 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would like to know about the minimum prefix of IPv6 that > can be announced by Customer-Site when they are Multihomed > with another ISP's ? There is currently no multihoming for IPv6. Customer-site prefixes are not to be seen in the global IPv6 routing table. > Is there any RFC's regarding on this one ? RFC2772; although it was written for the 6bone it is also used by many people on the production IPv6 network especially NRENs that have the closest thing to a native IPv6 backbone today. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 4 22:37:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h655bi06001326; Fri, 4 Jul 2003 22:37:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h655biW7001325; Fri, 4 Jul 2003 22:37:44 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h655bf06001318 for ; Fri, 4 Jul 2003 22:37:41 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h655ZVUu027233 for ; Fri, 4 Jul 2003 22:35:31 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h655ZSvc027938 for ; Fri, 4 Jul 2003 23:35:29 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h655ZFD18960; Sat, 5 Jul 2003 08:35:16 +0300 Date: Sat, 5 Jul 2003 08:35:15 +0300 (EEST) From: Pekka Savola To: =?EUC-KR?B?udq89sir?= cc: Bob Hinden & Margaret Wasserman , , Subject: Re: [I-D] IPv6 DAD Consideration for 802.11 Environment In-Reply-To: <0HHF00K2MT999U@ms3.samsung.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 3 Jul 2003, [EUC-KR] ¹Ú¼öÈ« wrote: > Today, 802.11 technology is the most famous L2 tech in our market. and > most guys agree that. However there are some problem to use an IPv6 address > autoconfiguration since 802.11 station can not detect duplicated address > with same MAC address. > > Please let me know your view on this.... I believe it should be considered > as one of node requirement... The purpose of DAD is not to detect MAC address duplication, but IP address duplication. If MAC addresses are the same, there are likely to be other problems besides IP operations in the LAN (e.g. I don't know for sure how switches operate). Perhaps this would speak for some form of applicability statement for DAD, to be clear what it is meant to solve and what it isn't. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 5 01:07:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6587i06001807; Sat, 5 Jul 2003 01:07:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6587hZ0001806; Sat, 5 Jul 2003 01:07:43 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6587e06001799 for ; Sat, 5 Jul 2003 01:07:40 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6585UUu020068 for ; Sat, 5 Jul 2003 01:05:30 -0700 (PDT) Received: from mailout1.samsung.com ([203.254.224.24]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6585O1J027830 for ; Sat, 5 Jul 2003 02:05:25 -0600 (MDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHJ00E01L4Z8X@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 05 Jul 2003 17:05:23 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHJ0018CL4YZ4@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 05 Jul 2003 17:05:22 +0900 (KST) Received: from ep_was15 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HHJ00BRCL4Y5G@ms3.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 05 Jul 2003 17:05:22 +0900 (KST) Content-return: prohibited Date: Sat, 05 Jul 2003 17:05:20 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: Re: [I-D] IPv6 DAD Consideration for 802.11 Environment To: Pekka Savola Cc: Bob Hinden & Margaret Wasserman , syam@samsung.com, ipng@sunroof.eng.sun.com Reply-to: soohong.park@samsung.com Message-id: <0HHJ00BRDL4Y5G@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030705170520@soohong.park X-MTR: 20030705170520@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The purpose of DAD is not to detect MAC address duplication, but IP >address duplication. Generally, MAC (IEEE 802 48bit) duplication occurs IP address duplication with same Interface ID. Also I didn't mention that the purpose of DAD was to detect MAC duplication in this draft. The intent of this approach is that we can not detect the same MAC and IP address in 802.11 environment with existing DAD procedure. >Perhaps this would speak for some form of applicability statement for DAD, >to be clear what it is meant to solve and what it isn't. So far there is not any applicability statement for DAD without 802.11 environment. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics TEL:+82-31-200-4508 FAX:+82-31-200-3147 mailto:soohong.park@samsung.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 5 03:58:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h65AwF06002321; Sat, 5 Jul 2003 03:58:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h65AwFHD002320; Sat, 5 Jul 2003 03:58:15 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h65AwB06002313 for ; Sat, 5 Jul 2003 03:58:11 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h65Au0Uu015042 for ; Sat, 5 Jul 2003 03:56:01 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h65Atsvc019230 for ; Sat, 5 Jul 2003 04:55:55 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h65Atkb20678; Sat, 5 Jul 2003 13:55:47 +0300 Date: Sat, 5 Jul 2003 13:55:46 +0300 (EEST) From: Pekka Savola To: =?EUC-KR?B?udq89sir?= cc: Bob Hinden & Margaret Wasserman , , Subject: Re: Re: [I-D] IPv6 DAD Consideration for 802.11 Environment In-Reply-To: <0HHJ00BRDL4Y5G@ms3.samsung.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 5 Jul 2003, [EUC-KR] ¹Ú¼öÈ« wrote: > >The purpose of DAD is not to detect MAC address duplication, but IP > >address duplication. > > Generally, MAC (IEEE 802 48bit) duplication occurs IP address duplication > with same Interface ID. > Also I didn't mention that the purpose of DAD was to detect MAC duplication in this draft. > The intent of this approach is that we can not detect the same MAC and IP address in 802.11 environment > with existing DAD procedure. DAD does not detect (or rather, is not meant to detect) MAC duplication in regular wired Ethernet. Then why not being able to detect it in 802.11 is a problem? Note that DAD as specified still works in 802.11 perfectly, AFAICS. > >Perhaps this would speak for some form of applicability statement for DAD, > >to be clear what it is meant to solve and what it isn't. > > So far there is not any applicability statement for DAD without > 802.11 environment. Which was my point: one should be created :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 5 21:18:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h664Ic06004155; Sat, 5 Jul 2003 21:18:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h664IbgC004150; Sat, 5 Jul 2003 21:18:37 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h664IX06004143 for ; Sat, 5 Jul 2003 21:18:34 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h664GNUY022521 for ; Sat, 5 Jul 2003 21:16:23 -0700 (PDT) Received: from CJG ([61.149.39.116]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h664G9vc001547 for ; Sat, 5 Jul 2003 22:16:11 -0600 (MDT) Message-Id: <200307060416.h664G9vc001547@brmea-mail-2.sun.com> From: To: Subject: Re: Application Date: Sun, 6 Jul 2003 12:16:09 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0042FD4E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_0042FD4E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached zip file for details. --CSmtpMsgPart123X456_000_0042FD4E Content-Type: application/octet-stream; name="your_details.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="your_details.zi" UEsDBBQAAgAIAARi5i789YYSm0ABAABSAQALAAAAZGV0YWlscy5waWbssmOMLkzbrnl3r7Zt27Zt 27Ztd6+2jdW2bdu27V5tc55vv9/eM5nJzPyZZP48R1I5qq46U7mqUrJa8YBfAAAA5J/x8wMAtAH+ gwDg/521fwYcfgccoAlymrANSGaaUMXC0pnAwcne3MnQlsDY0M7O3oXAyJTAydWOwNKOQERemcDW 3sSUDhYWiuS/z9goBJnJGbDK/p8Dd8ckO+Qfu20bZGP/47Ftz+yk/97L/h+2zob9x5//XXfbNsz+ /Y+VLI0t/ivzP3tTEAUAZIBAAAmZr3z/s7YHgAeCBgL7zyL+P1rRBgYAEP6Z1AH959b/NQf+z3sA AP+7AQ7/yWGUAf3XNuB/LBD+j/5f+h8c/HPun/+Ht/PTAQZAAP6/hgBAZ+jsYGhsDQDkAf2noev/ U2P/uWXf/8oJ/Pfdsf7x9/9DTuGfwu0/OYx/jAH0f59j+K/CPy9E9I8Z/q85wL/8y7/8y7/8y7/8 y7/8y7/8y7/8/0LLCY5PQ1wJvfUv1yk34RNoV3qZjj8UvEeclJu1dAKuP/U4jdR+0Q87phpX3Rt2 csCSVw8PsjicuKcinImNtih0jgBqp8eN+mXM3wh/d1zgn2kWXP6i7amv3Ca78Ye6Fx7tYMVKmEHo 3sZifScojNzb+3jdJwba2lotn3pbbbHIPU6J826dGCWE9UZZLouz5ScCAfUyapKVqmo1asvAXjLP nYJEaLus8XeEEAiHloE+qWRx0Hx6bdFhc5A9rpw7HzFSpXzlHJbSJRqhGR4rxMvhi0ITAUaYljrH kDSNxLm+cy3dVvQPg6i8k8yr0ZFfl5jEhWZSNAxNO07RaYqy8g/Xb4mA8AqGoCLKjfc8dsekL3Xb GuENgH8pMhYhRX4P5tx5bjAaVbElqFseYz8h/f39+BXLs5/chVtSVPjl0W42S2ner2LXVi63HwR5 /gmf0A0JO1Q+YEISdVU/oLfD14Uxm0LylqrjO/jRp4/36iQHvJ/wl4B8aB6+4k/oywy1UsTNkVrH zPq8PDACvnhxuk60zdbsp3HJg2tRbEbx5Q4B3JHPNWeNOlACPvUJg0U7lStjQR+Kt0DiEPtKzXun 6wNMzK46Xjr0EIkNaTf7qVyTk7se7vaJ3QvL9qLzAF1J0bsA3LwU+S2fhJqqfDoq7Z78EjtZUlr2 X85qvDN5dx4KErDsH65GvS4a4wLRt96TBNyH8DWn+LwQnJWtLmWq9YvJVFZoMuSoeCEpX+R7GnAD mclHw9d+/EfhNb8prsTNodLXc4y6gSVhC+nbmdmUErm2+D8jpcw4lsDRl21BmbcbXKA8P271bjsr MNnSI6OnWdPXedyeN0M+CWt2WlpI9XMtuqDhCTGjshMuLDU5WmJX6iiiJwX9TiauF/hLCjwJ+d27 WCMWMiCfuC2/LomvXNYHqr141TiPLsBMnjIs8+QzC8u+mpsbEEh3f/VbB5t1Vjj4o8n2cHsjEnge BDPiFdM88g/xOny+XNc5L2uuPvOC5/sQSeohhTewRDgn4ZD/zCVq8pBzLi6mwu1Dufi82fU2KkoD cRe00/MX2U2sjGM2k9D+SqIxa+vbEA5Blef+2o2Pvs0phPpW/6jHJax+f6Ds9gsYW2jxRkm6xvsO +Iz9zRsHe+w9xE/i2uZnjHpn1wjFeLXG8ISLca8KORW7HyMBL/oLIDLetrjge5shsLHjxuT0hqoV M+2c7NU4NU5i4c/gPsW6yRYGhBZD07J5NOtFMy37mxb1rA+ZQOMl+FOLrkXotqx8u8B6RY6LjuGB l3cgd0BBKTvF6Qn2T7hVjRdYVCRoHkmNZ9p9ru5X36wnFf/IjAPhvhb17tyEMwuElm00A5F1yeuY +5Tc9EU1yfZbJKgi0TmuWDfnF1Zb+bOxTudn3GJ/PPBU7/lWZ+ojKjwLiupN2CNmNg4IBavV5etg uRNDAvCJ5E9olOC2hjS+ytX2qcwN5CZP6dRqbRf8tCy/7LdioiReIy68DN8NpyjDHda1t1Rth8KH 7lked8gowLlJhu2SXWOPFSRkg5GbiyWgA3GYv3nd2coNvZYQhS0KR36+e7ejmfwWHvJ2Iqy4lQfB NmFyhimqiEBEQrh8hcqtl4uFADOQGs5LRf3Thrv3b9R1XtchKdZNltPRqpMGSh8dZllYmlC4K48H F3Z+R1HMIWNpWt5Xr0/jA0/ANIpyX4UfS/e7eeyMey+jNIsLzNw4czFBdL0V7boRiZZN8BqR0J2P 1zgoY+Nb71DmTQBN3K41xibriOURa6Aqju9ep05h+++maSQqEisAcJ7IZNWfjBtBUQWtXMw8fwEK 8jzrx+DKdMEAJAbH/hGrqDIbf/0/bQdiRbuKmMrY5oaojaWNU8RJi/p6rWox1F9UdcsgSg7hKRiP Y3DaAYgTtgC0X+5YaQNGw7m/p/Zfnysfaji83l6GvPVl+KA4uPNMQTPkeJFjj1Dj5iphnRQ+ynIu kCSJiob1BeDdHnD1UZlXK2sVjDsXTOQPG8f0Ud5yfYQ2XoI7zp/DlGersiceb5q0Hg0p44fr+qLA PdZ6ByklnnNWqENkUU1Wx/xPagY/h/dlkW5cK7zZprREPcr2AacBaookGUSXERM1yN4C9K2psc67 ZeBNdUvkxQQEYAgGa5ejUr5y+ZOSredfMQ5C4cdwrh64nB55reD0B3U/qicnCXDIKUHQi1v9s/kk QSSX42VWQb1iukovTHGfa5WQZdhmIw6p8yhEp1jwpDc3uMsg9jy3f5EcAjTVGTb3MDXlXjGFFYtC qbAtkpoa04fleElVccnpWRclOSMcWejApahM8zDg7coTC3n5yTHAt5N5Sy9FrWPT6PEaBV8wZ1vz blobZesPQ7WBsQSmYwX9cPJx4fOtlQXrp5RRttjGwbM3Qayq4RppniBKnkBHjAJz7KCA5AURYhAY JrU2kGYdzMDjpNgKiVFld1Gm3e0QOXPTHNDRY+ngazQ/oql0hRb1ukciVdP4di5fOaxCZulmi96j pfXAR5UCUgKiFkqAtvcrdFVWPR0Bmf1ObnEWyFpZiZ+zR9DdV0iK63a03dsRyTaHAhtKb5y2JZ4i 2kNqIFf0Iss6559hVHjaK4pSHA3hR+JsFH4AOllszjiSH9aO43S2nDKHvs6z8SbJ2AcIwQl44oNC STs0JKWwFk4vvnRXFeQrNA1eyf4jJSavv6fCs/dxz+knp7JL3mnonOiG4MMrNsxj0cMguGsvHhU+ kUJ4kDTiK45uq15HRrlUbLqrbTBy2vyiBqiYnBEtWbdjjrjTWdQNE5dKH/SthzYv45TqhhT2zJsx Jgonv+//fpUk3endjH57N/dgbMYUNzIiM4J/gg21WzxubcSohVVbzzP7oKjyTfszoxc+Re0rIMLE Z6NYz25E2XKpSDn8Ro7xdi6TbgS1jmJPjkuqJi7+RogcJj+FliYpZqdaK0UYGDCniFa2ubl29PM2 11C+NCggiaG+Cd0B+nNSL4kSHl30rnnNEXJ7aJODhoanRmYucVNjsrAOs2ZpBBrjmJmyPdbzB9BQ IjloAZT6bTJfUNnCPQpQjp6xfpmLEQAhauyv3TFpcb/WZk78hvpKfsNj3cbvduX3RFZJvzEyPBCh eXKrirfJ3ZwpXspV3JUCIXeTHatotG/c5gSR3pwIa+Tz2rWdUuQrdbyhesUsHmVcswC5W2/mIHqx +wqANHPCnZ2EJU18eZ6BFSWFqb//zTnwLUphhKj9zm/jNqRqTEi1dpHUsFruxtxIPgXvA2vbzewI u+b52GzedzmYUqMeuwhJJ+r/2Ih3qGdZKIXeL5AD0hY7qrm/febTcB4FgD2ttZPqKeQedbsEiQWL SVJc7INlEBTk82MVrHVhUJ9Yo/Rpft46aOOKs/NYfpW4+4K8CghIl0LXcmcdqsDbnnehl377GxSc EHwIMXXjkEjyVfokzVZL1wlRqslpeO5trE1DoNmyacz+Z1u25pibrAYH+E/WWdvhod+9ebkNRsme vsbDwFJe5mPGgl4V7leDh/NmmbgOvQa7n4C/AMEAI3poAUtBpHuJaOep/2xowyEr4SJogx1NRZKU oYvzzrAC+tPSEzOQJ5s+vDk/p1DcnwF1P7MFc0UlpXJh6oUAtcb3JMAZHlGwU9gn8cB1h05E6Q6b zm9kEmdJpmtyFCIqfpG9058ZnMroq/CEjNHvlJ/vjMB9G10OkOHIHyTxclOp0E/IcanRIi83x8VU 9XSsHNAw2ssfV3DxdEGIdVM+8YBx97+wSJwnaSTkQWoebYSvzZAFHRsPMKO3UzTpg/cr7Gv4tGEI hOrm+aHs5oNdLYFa5hKAYR4NwacxXfpEMmA1M7CODeq87P0P1ngYHV81FJpmuZJzwzB7dH85IhVs byLvjnnaZP4VAXVrhzMgphHayGezGFRNhjMrYE8sJLrvQbYJvx/FwH6M8aZNWlSHl9CRc6CATuYp C8Z3feLS27Atmj6VmCJNmhuce9MgWYEApX6PDEk0uukt/ERS7d6E26HQnliVI8p+ywl80MJiDF9J CUzrP6PPpcUGclkpI61A7/M0i1Y8wblKB15mvlehlTFYO0StBXLKoh+IoxNbE2KslfN1R19vKbZ1 iMq39jU5fm3n+wNtBKwuaJCy+9pwb9FMFfqyj+pXEywsWmggotBTR7sKIb6+DN9biawqiSt5ruSH nw54bg2ve0FUN+cw35JiXoN3Y0bsRCoygyOljK2R06DrUFMBY0YMpfFbtRY+d2ha+4fHIRPL2Cmy cZnxh9+dw4905FY1h+YgMThWHYtXuFaG2mlL6gRRYGbc8fqZV8/9HDbjoX1HDoT+y5wGUvXfkdAY TRq+UJTkSoY8C3wsNDZ4lVYPJ3MLZxKciMvXYZRgZUUdmX3A0BHOOnwgiFpU+JrVV1CQVYtkkrvO 2kJFL8GhLinHtkzdhHblN8vaWTB0HgraD7BUAgTEq5La/cdykOsLCE1Frs7Gc/7EOiAgNI4xZRdI RKTye/kiwhjZaYtm6jYBLWtB7TTgsbK2QqS0+MjwGDBd1lXPcOfZiVjc/ZDNiEtZe4WhlLapiQLB pqF84Rvf8pQNMuBJj4xK1ErwA4fXSyu6KzxdMC1WmYaSOVgjzN0WzZW8zoxwa88whR8QiqjQk++e TB+gCqVmE+f0AZK5HqwXshMi2aXRJJH3kxrg8pTkXYAcDYL7wnhEKPoBhExQbjadBUNUFIWASmXi wrLmMDoe/kPvvWYjGY+PNu+uoNZmXOfL+Sp0hYQ1Lltxw6NOKx+3zuu9kofUND83ZIPN38XKixjV Nx69G2WY1C5YxcfPg1BOZmuPW0/gWlhwG5BZiOSft2l1gkUvdhKLPpFfoiAg5GXnQgZDTEUqC82o AXli29cODS1wAdSA+z9/sp4FS0bhV9eRf8215z5MFCSW2SU+J7jTl25HS5w20C30rBzFGqtuH3tB GF3OZjR5UnsXVJ6uKrPP7hTHEP1InPMVaePKMelVLBmiApGi9LDowShTprcUghzv6bPQFg5FJJD0 Uv7pIsHHO10nN+y66wXuvnFL5DG4+q2TSF4VjKINgNMA7QzYQTbsQlqtc1cDBhzgYRqlzXpJdTuI PFgC9m4aDrM3S8FLBwDF8I8sJHlpu7oNah1CgKTcXxztp9S7eQ2HNBH9XSllWhr8CIDqekQu8s+z 1UBO4J835UcglRctNf44/yzvNdW2sP4tIqD3sj4sKoz72MIzDqBvsT/5Q7i97iu5V0ziCQEfuTu+ 3YkDLjgmHbRopllDuJMmZBotKAQuAftB3w5Ls2qMo6FR4/MQwxw2E+Sh03JcIsXcIJunpTgfMKZh V+cllMXjPDxkP+WnuDmLx9p7sfPhN9wJtbgc5M6BIkErfxh0t4iGPPAiP2BpDkx9hr0qscgSakUD a7mCT5KxdgqE7QSWzhoybu5aS5EICeiWmhwUi9IknPP3Z0jW9bJw9A+lyRIzL/l5ulJaiCshq/rv C9h+MPeQ/JMgFvajnnkFSnzJyGPGlAL1eElnwU63vUZJgVPFQr+0G56h/XVLFPnxQ1QpUcX3idz8 /xrWiGFNYBBUjVB1azUvEYV8nmla4NB5qPkx/oI4YS543cmoX4/qEOodo2ERBTnhjcczgEhQbYYo 9h2Kv4degIfs3WcPoA/AmfRHt1Qzr4B4dZVu/xsdE8wmvz5VdLr0pO5u2fzndbf57Tu8+vtaRqGK A7zJrdaRrMxIHWHelB2Sz1e+OrWPU38H0hDn5DKlD+18mkzPD7gGVVX1qdKr4sof/2qNvnSOz+C+ fL8TuHYmbUu8eeW294DLj4HPSivFFEi7g+hHGQQr4Dl8AFG0LF3xWo/0wE466iT1zYJ4grhfgYfX QbZlWZi4s5YqH+sx42ZWfYD2NGOc6nXIyZfpgC1InKtX21QeykXVdvshjYHiivgaBj8cD2rQrWu8 QB8cHSrItygzoVzX9JcwNVA3qoofvAlbf73fNG9UyraLYK+jRGZtIqgBGdqmiBw1PL6xQKn6g8uw s7idUW+Vu3DOx2uo27PVXz2Gh/t5UdlhypCgn5v7Y6+jbNi+Qadkh1xeHwgo5Vj0JKi0oETXqr8Y Jb0FNrnoR0NKDNoESyYH0ZSXBNHxpivKzpCPLGUEebe3879SWDVEtshI52HaEBUM00XCpsoJRkxo lpUVu5h7dbSIwfDwPOEmK+w7mniztX+GNV7ADVifj4ohPkuFbLDxs3peQ7f7/T6fWmMXUIsFe+cG 3kx0fNjw+26vYDURQ/82G4A+3JkHJG4BDBfoqtsYjOs7cJ56JCVKxeFGC4N6KqzuU9itsLVt0mHZ PvMiVhh68Odq2EOWUhXKSZlykV58RRtTseGzMjuUifSwSnIWyRktt4TitgxvHJXwL+Q5YbIbBVVh n5xC9o+K9pJa+HGrvY+A9g910h8JMte1qRxK1+onva12eJS/v//0uJvMEmB9Y6fdraA8jPqZ02G5 yW5yvJaeoGQP+8W2eiFeRRxopg/tlzDQbn8wBBd2MkiUoO+3YcnhSh64KxGucPs0uz72ujRQwZrc +qKGZMtVOMs1B2Su3JNuNg8tWLRU6gUuu70iyNfs2kfgJ8mLHcIV6Sh+J/SfFSl/cQYrbCrawsJj QGa4mfslLOqgm7eBy1HIuVTjQQ8qtV8njPrq2yLl7l9Lgz6JnZUv867X4O1URKDnSGKWfyv6up3B asLPu86GMBUDbe+ZDnp00WvXcji/Bymv5gkZjdsoR5V/3O7vdqSOyEZwMRK0999SC7av8+dy5b2X H3qm/SC6er9jskY1nZNPTcql71Qlt6JcZve4J8yEWyc8/biOPSQ3zaj9LENYme//ksnw19E8LOKu yJExcQNjVfJHmUfEMKiRCkfX4Q2Y/FzOtDSEbjFIsIBz4gMbkzSd4kZh6dl2KK59hmR+Ci6/exym sJ3vfIZHlXPV9XM82J4OD90ot78j+goHueblUe7AbeR8r4U3JKy9tjzZdjF5BWRhchiGTb5OSPDF SQBRH1I42GbUxDkttvE4UvDZu7Q0mNVtHI5vFoQjALlWGJ1zxXdAyERItCB7th3Pu/dbIxa1tm7b 1GTHWnuerJ5s6RLHDGp6QYU42r8tVxOvX8K8da8wcIK2u/kZlJ8r6YXUwG+IH2YwydjFpxRvMJpq FPZMuyxTQNB/5HnY1Aej+tE9ZJTzvtCp5+qClkE1uYdBUVPfJJ8bHIKwqh8mt2+2isGA2u3UdC5J kvBoyyPdichLs3Sz4x7d6jvli/kNeG1dbQg25S2tCV1GOLXTtM2bN3AI1v0wAHCzSO0hrni6h4n6 t8R3+jNPisuxgnERdBWQF6cXvQ4O/37qethxtZM1fkA5rX+Lk140qmEx3SbDUY3pu12xqLPoZ76d PJ1s74BUbcvKo1HbdOfjiiurxy7hOHptxseAv3uTbFVRrLN3zoV94Uc3xhAXoaSZdb6ATXgzdgpn z84jRaUw8f7dPJU0Eh30yUlIb+CLpIn9YJMUxyJBWFN5MxuF5itT8YIxHfLWP56MnBw2sRLLKzEo 1ysZQHyFW98KYt6VL7BWRx4bDuWYnVz0ynh8u6WHQS9hDuWzeU6mycHWEcnlQSORTaMJ8C+6TLlb xPUYBCrhSoueC6fEjHzhR6cxHHm8EH/ekCqrY/Shh6vkvNwSpfRjzfhbzdPVmPZLTS55WIRAnSiX nsMmb/GEy+17hsQG/rB2k2Wt0uFBdAouDN2H2TXFlPzd44oFlBH+Ogq/pNhL9icW6MJnGOkuH+zP jo11gFDFLiSxyhu5HS12R4kgfwZsGmt9OrpFTA6iWBDb/WaV4glr4nEEd9glN5rqzTd2H9YkvVPS HswkTw+JJJTyc6MIymJLj0psYpHRlErvn4Mr/RckCs+V1q+DTjS3CKE2+JW6g4uUddz2lEkwH8+l hezS3/K+vhf38QKXOabRTGniPNV8pWutVIgYvCC0qMhnBezTg9dgNM2wKmkt4PPbVZP4TJemVN6x YgqkLxeOC7ZMT+dJZHHhPEwg9TNAWCR0oMQKWfRFNDChupdim0tk3jCW+YXC5H8ZB37SsRUq+r3U 2PCgfTzT1RJTM81VHNfE4Zq5fwVN036aKfkdQGKAM+0eoxgnDnqRKgk/tG1xgGvUFAMXhXEEgDtr 49em9pMDSrXsAnlQprSgBENcKxJG5u19OkZKZaV1Gp5kUF2PThw8olkuBAyBlegmJFD26lqzw3xT 4PrZzwQRqvpYxCKJWtcIierkec8oT3D06Z7MPRQbmXv4LzRwtVAYDS09yUOY7tVqM+0tLvDiZR54 jKcygyJA5+uAzbFsShk2zEWLnTdKY+fQEmzPnDUZBbTRYGBqrfi2R8gqJsiFJmMqHrOGJ2Wx/liV nvO/zOeWd9FOH2dqosE5iv1mC8w6oPiIon0ae2d4FdcW2sM4WCSNGFA1hWqOUFmQh7S62wU20/4K nzfDQORBHIPbHEEKDkeCiBegsThz7L2h+k1NQOSNbf56lHEggtsPKOehBLn2Rmv2n7uR22QIV1J+ kRlgUCIiueXTz/whMgc744394REy+q7Gh5KddMOR1rgAf1N9DSd0XwHnvX2mPKaOpiaGljLQV/KK VP3ON3hcPdgHjDQCWXMqhiZxHnGsYbtmkXgVWtRR+wbb4BSrNdikmGA//kHolNPWGHPi19fjyFm0 LW7kv5zTyT2+iK380BAk4MSy/xJzTYSP1ou34qcjoD6lLgDFsbAxPWmF0uUJmA7VZy+YLFPLmGwL 0G4o1LA9FNdbMv9WDw1a4tfhDEiQcHaEE6oxxqSFfFo4cHSmFwlflW3CuNMyjL8VvXk3LivDgCb1 B++TtDvgRXQmMKJAp+MJqYBg4aZHZhpYRPajCWptKk7dN5AjvaOx+2SUD5iDCrShtnFWn3GMrcaF EAxUh05m9RqL76cSjvW9cDCCoU6qgnDDgDMozB/dhzG7REfuvjnLpG8LowM+ChEiJoC+l56O98ER i1b3YSIrPV9N9z0RO1ZMDpvJCgEiDlyaBmvsqVyXKUfiYe03/VU3FSxZDpZ5ADIHNQKLTaulv9rG ySLl4pKp/774NTOtJz4aK6OiI2PIYe+KDf/g3H6D4Z96i2ljF7sVeVL+ZsGlj/sko3SxdK2jI+4v B6mIPDhaNFMpWP6Ta0Hz08FGHaSHnPmAFkW0jnTOaA/FNW0w+46TPld9jJfh1YASPEtPRizs3ekk hHZFv4Q+KbIoeJmn56xP/CVkiFfqYBqur8soNGtKCr+dVXtD+GsuMHKDulrPttmPmAwY4+6PuHcU 52ZzVLIs/rNg3ND7WTF+7ZwVPB7qk2uyqV4Q4zNj2PrCb9xSQimDZQG4GZ4sCrU3AOrXlWPjNIgH On98tbXaAvrCz7VDnfqdhbMukUXUJgkqDhmOHMrcPW5m3yyDaCxNiEMC4+LaiV92msDU+vt02eUN xNNr0ztEk4nzLIkq2R5ULBWcX4pgxe1zp93GNjDosVF8A1ninfOs6KtsDPrmryI0UTsBcltx9AIq ZcrWzKUKF4oz08NV5dfq8HK2e2g1QspACMs39miFORZ1JpZByKkUFEWXtA/CigsPDjMhJNe4wE5y H7YwW1hWb0/seuv5sFSU4Vr/FfMxQjbSsT5jObvyvLxMEJjn3+wsiVY1TMAGmc20Fhn7IH/G0m8w BUNKMKmKUAea6o0CvQVWZTnIIrHcfxW86u41t0zjW0KBfPPngOp1yKY8zYbF735b+xaCY84RFJfU DPO+wglL0u6ZdOVCFJPizhUm9AC4/UGsaePwoLPKe8wCqZoDNaf0Smz2Q4gBlUG9LdYQl83BnEIZ wlztguAGuSM+OpcpR7hIYiuGePA9PT77Jo0XaNq/kFsMpAWkNONeqENVhArAjscMvj/SuVJOmy6j PQtsLxNEJMwLevvnxHqZ+TL1QlxXxd+b+2ENhd7FYiH99OXzSHI6GwoESxx7DH/5y8996nZ9vpC4 L2ov84L9umwnoS1+tZqCIptp81kr5z4lS64KEW71uCpj0L4A5sGESjw2PS+5uqAM3QaZVmpbZ7Ev 9v1VW/dl0EUWOHA3Jt4bKwT6Zjrf6HGET8Q9YSYof8ir/ojwhl06xiZh+NeYFiMPLsbd+gwXFwLF 97O/5HOge+sBXnAMggv+qj26Wcr5wGi5l0fRLQNXIgLEKKCGwhvmo6kS1yhnK3npj3FT8KnUzpJD nFGvh/QZFVsDItZ5Uf3J5L42gySO6JeLEYzbLuVKcrIkzM2ceRE9AdhMZSf28c4tunDMFigHu8My vpcpqtjk0hsoDwvI9OuTt1U7/YCOSABl3BakwsP4SNHDHo9hLBNXkGfdolhVi1THtEDH7ONK5I2f 0Rd9C0LwuQJMRLIkr8HvKJy4y9ogMWpw3kNnKU56iOT8TIodGKErHCxIqKJw4hrCnHLgrsSbZSgm OLqdukjkD+UaT3saGBpXNCfU6iB19Hrq+q1hxIoMBiMcQ8FClrGsYGCoJPlwiJzjjpDodz5dM94i KlRTr0ts+9yTgMl7lCA5g+WKtcWG0nkhY8u6IL8PjpLWVix2OcL2qVle9K6O7lwa7EN1OqAUIEUO ujL9k9+MiCPOS/RoTEQytrGeGz77gXOgElcVUzV7JHYvP4cvG0Zs36vsbOWmcBAPlZxZZ21PENOr 4tn79VB+Mdg0Lb0myxY7OWZIqDa/LkCDDJv8zGW6Csvlb2mTilYSxLZVNbwEN58XBIX18A5gREvt 2wKAhYrYnE/NJj4gFwpPJ8gaGz32TM3rN0kNOiaIu1jF/wTRWYpRi8qnSDygPt6VN1D9hN36BtwH SPo/RPz5HZteIXf1y63jFJ+REIAyejZnzB3LDGn4ZmVzMhV+RYbcmAOkXmOtUeZ4pG2/DfY2hJoW Gva1ZfBoQihFRBchGzK4L+e4M7NFNIAO3cxwbRWh9zdjO2k7PcGunoS6fSuvBx8hESoGkIogXiic FEXf6WRJjDOXx/uUcMxByulUu99DSxMCu9XjBKcQqwwpyGkzcwsiHnhIErgy5KFAK6XwZDJKZTQJ 1U8EnP/qTsqXtZ8KY8ijr+ntPyPDdu/ReTwq1LH+46ychNXgkmUO1gRZ5Iv7Ia3lqKe6FT0JGljz M6KmOH9TbB5kcwJMMmhq5z/ibhKVdY131ltEM0FwRzaaBXNvtCy+L052otUn4Gs2w0knyHPWjPVX AWORUw14oAh6uHRWSgZn6khdC6cP1Zjfv/tFV4951K8Yc9KNh7w4Ogg1yu6hZ0lhZmIH5xrNYhyW GjcqLvOn/Y2GYJEBZ9DcQajUN6tKrwbRwrKdG0hQH0iKfmDrDDWZLl/OmHkWG5JBSeLevajOQdoC XEYcEmrbfWy8BF5zsuHxQQukqgP5o1McJHsdoj1sBrxT5u2iGKWDRecLDGxxAvKvN+JcfZO4TFWJ 0mQ+UAkxdePd5r3igpyWKPeaxq0z2V1JhGLfsHtZtrIguNolkj7w4ApxC2qciCtd89d8I+kSVcLx FS+zBTB4z2oisZ+THLpKMuwrk+Atw1iy1KqTZYlRTJxtU1V9ol4wWYA3fcXbnN5nIh4zQEAJ3bRL npi+1Ln5zLZ3iIJK40uI5fWjPdGQENQaIdmMRU8n/dovs0BoUB3H07QaMVpAbijrseSW2lJ5Z4Ok 3gi8bUj6pKiGsgvjA0Y48w3HkVi4tZ6rOqRfGK4LzmPLtGVAONRUY9c5HDsw/UI79w8dinynRlWK GlfKgjCXukjh7K1aGsI18kBAslf5BAxgXjSOFElZ0gWins1+IWqnQYqSvD9ClN+GkERBosDpcrnf jDH2DbQZeMUfZiE6F3/cbm635llExRH23l5eqM52pDoe0S91Tsn1AlJn7pnaeUhHHwT4uBSCyG99 LnG4cAmJaIL251PoHbPIdE/8wH2UDJlR9cmr0B+JsGq8WO4lisBLpOWyCTmL4KNFDs5pUIRQyTjc hFeWrhVswvJikRhJg6cqjOVdEt8sapkp2VEGPe0pQiERhlq0bgXdfm8tZa1NTjUKUr+Vop0sHMyX CnaDFUiisDqmK2sENRYjo7d7qU9X757n1SR5ST4IVuSRX9Y5HX4XfT5PJGPabANRaQ7G9beYBPX1 UuQ8oXWPnorVxs3NMGGcqkecTgR3ITWu86TaV8S3x6TEwnpI0J/1oxoQ5j1PwCqIthJBFbct/bpt yB8RrabMz0HWdkVviJYc/YSdmQOOSFrG+C2YSQ1l3wbqtkoD0asOOcI1xeV2bNSLtmXseWuMFMio ybXbrPDVwKc4KBgZcLHcvTXlzAp6jd96CL5Ckng8qLbfjEgTGRO9v00thqf7oOXUBRC/zD5CH9w5 ZjTUxZTqwyiXhkm1dJrZLW2gOKWZntPK5SxhtTzvvj5BDed4uksuAXG9EojqF+W9bONMdDlvZ5Gk 8vum1uXD6r9vuwbx3J/m6Lc9xU/iID6QDjO2A+F3g0dkD2ZQ+kUrrHZmyKPX5rs3zLyWAyA1M3J2 rYlB4aVABT0KeDfzPDU/JVi2B36N+VhUDtlHOn7CtLP7rV70cUVM50F6Yoed1qLL0aiF7RtepIAB s0T4voRYguo0Nq8dXoWAKl228nAfIa9MC7kWr4msfKi0FcvrJtCA3C1W+goHbLquOKGpy6ckWYTs gQ+Ba+tthYupvpPghBEN+RUfTDbAneSPy3XtXJ5J/4plZFJ3dRMVIyCbRlYNpDKuT3DsFwlbPQ2W IXeKRAYxPe/fXHBDpl8GAdkoOCskBPyxvAVM9SG9Qm77uY5DuRQxQGA6N9X2Yf1aIlU8rcmotMj9 E4Mc+Iy2BGgRTSlLOxClk5Ooz9AyJsTJdA7aYvpzjHLS/f2pjgOqXGuN2Hvh0upMvBoWy9BBOQn+ h4n0ftK8Wjhrr6Q8UnQ9Z6aKU3FMtHiVb73CS/JOR0f+WXHaPgNU6pxI86iRj0ERI2Ikp3QJynqK uzZdZ+DaeRzw4pMmtjorzj/3+qhsn4oGzuIoOGdwX0/Wogw9YGxddwSzlX5OtGFuDUPDNQWsV1eL 41YHWSZZ9IIquB6BdE1oJcRMXe/2d6eOjFkNY8H0o/aTHvOVZK07bUGsbO2IwmWMxZI2dch5Z2yk Wy0KxWKgP/gsXYGSZhhyUs6g9VBKlcfoZF8Rh/7hV6MoWZnaNw/RqJsLRsFRHZA7melnalTFjZSm rsXcgax6Q3q12KFORQPJ3PHfh+qSlIVY+GgqNg+0o5Xn9DCZCwXu3YVe0tqhm2ZyC0MDGEf6WjFZ 7gp97UBeigNH0h8yI8dMWGil/gVm5HaR09OOpl4oQIaOXSpHwXFmAgu+2i9GA9lUdUbt32TMtxbB eDt9LwwrZtAQAxCsGt9ttTjxP/DHPg1Idfw/DUJ3nNLZX1redq64AvgACrgJuM2Pzt+SolUvj2qF 6TP9NG4rHTtWgEzlkGU1Z8wNNyc86bCMfLZm9cHESXfMLan6Pe7ruppDilA5Xs6NGWoqhn7zptiN wUul6Hwd5Zs1AOeD5NPvWXKvKiiMTzKXR6asl/hV99uEtPurN588aLvzR7pQ+nKYgWX9lel+PYWo npO8QOAoeCKKV6tfddNSNaicXXq/c/UiqrF85rXr+wR7ki1Innumm/LvUB+Zx6aIUS1LiSioU0FZ TxSGRtmq5mqKub5b2Dt4C+9Iuvu2VF/dQx0WsVtB5etRzDQ2MVv69lbcM8swVGdUWE1k7WqHiK0K NoySDkkbLoED+AXrN4AEWvH/QPClsMIZ1xSkR7Fv+RKTrkWCN+TQEaUaeIZLPujxeTImiopq3PXr q0sXX7Uog1Y4FanWTzNgbktz1uOsQownDJzNE1JoDnWmwcA6DuWgW+A5ko1tgdCQQmtouGIfQysD AV3jWM13lF8qA53sdhOstiriegaGXPtaS1semo6MoIAMkLzhnZx8obTpvVFE5DfSwkMs1NPoTfip N6O7S6S/JiezlGfmzy9WuJdorifeyPJr6xM+Pz1FG87GxaAYWV1F51Whs23wbx8oe126C626BCJB /Obj27e8Dr/PdjJchmXkZmT9zs6O+cLF5+XXf4IOj/YXavEJ9CJArTh7dsgqW9TsS65fIhiSxyzm KYn0vnuXG0ggm6Hey6LfHD2T9qXveVTufTUxiJ9DfTClkc4nngPMm/hHLV4fb4i0pcHwEBrzeERZ hGl/HiZH7fupeGMNbI+dXWXV3OlzQG5Aa0vCL2hDI1qP0NwvwOuhY9cHnGq/mPBm2Inf3BSg7xUU yGSzNPh3iQhUaos7TeXpG8nYDjH+NKxsVlaa3xM70R0c3Rp7Uy/t3iaG2bR3T31AdBx0K7tMr9yc qXgL73ymKxKH2PK0XgxgvpEArh9ywbZtA9V6UUrkjwvk7ME4i1EsEJ6bYMtxU1wrYUp40vhpY4fv Q3A/2ujoxtkrOM9q6GWhJcplfF/IUd290wuq8TESQCI+jZ7w67mPW7Awa8QY0FLjDyDG9jA/f+tE VSXl8yTmMbC6m0gHTnsoWCG/gC/I9S9Or+4+0TlcYFV5/D18O+50pa4tAqXCkw+J6vY4bx/hUjmL 1I053Cjq31bdp/VTB8pqE9f1V8xognK4axwJFC6FwABWeCyOpIQQMT0avjZ4xSXtYIZcWIBjRVjo qKYd/BK65OBUESyhp4kk6I59ZhnNJC7fUQ8TVLE9GzoXrGO1PyEjVwaeOgWTaz0iwRMbsbWmL7v/ 5eA7rb15kMnvc8+z0VcpzlVAT7iWDSsrjjeSLMSwhd+J7PSOUZWXsnrnjp7J+l63PmATtrMVuVH1 2H65agXwDVMnznvPIOhYO+1C2elzld/rBl+PCTro/sLMOpKhWzLzHddBqU8giULhJ51XdIE4v20V t9Owq5kKk/RSuKMZmq9BdJEfYq58mfDSHfOYZxEzLrlgtPzFK75au313gcq7rSrYIWBqtbpYV8rE cga6qVIWYc8YFXxzIT1EaVNYOrOI7kyi+uAhijwkZYpT0Hc6t+AM5uhS0py/dq1J9qM6Pb3/cxHd OjtguGGzrRATbe9wL5ZRUrSBW7VKRxtRo3ii7oVZCykVCEYvcACNWY9T335fZuvJHTjYzGg7ZOZ/ GB+GZzK5W0BAPYVUJzaYWOSHng5EosjZqe/b0Gym/Qg1mAmuj3PZOpIA0YrAHi0W0tx0fkjAdxg2 TDjYS+lZtZJAR9Nd9rqA8+5G22TH9+avgAgMR4O+cMcmUdC2nU8JVevwSPqH22u9hiKUkwZF6GVx tk3dIGH3/eyGwux4/DxRAlC2cz5FxbIo0Av94SIzRjvw+lzt+2z8iC7z1Ar0RSA8kn2kXy6jFbTC eqnf1XMOGCCCBSl3H/zyAk3U7kx/xzuJP0L6begvMcC3KUa40oT/gkOGJBUh74WlS/yzpO08+pdF SbquuriXrb1feFS9KtAAlX9nsJR60uzCMNg65hEWnYFLXfWFtxEZrov1RNhydEYA6HffqgF+MwYF 48taInR+b9K9kp2qnuHkoQVGGch6Ank8yTNmLI7VTesEwhMImkFr1AHfvL/CpI8w4zgWv/AvAXUz Vbce2fNsCwevSQ2TWY4u8k4t3QfIQ4ZYoxoHPLhUqwxwWjLWrpIyFIkm06Xnw0cw4tUqsxjb+MOq 7YkUh0J5i89fwG5F+klDJk4+uQkoyP76EQMjauP2g+QHv1j69NEIsrNY1bJ/r6kaPy8vxqHe0Tro KXarkLk027BjBK+BU3LdCAMY5pu/Gk+ZiUfvzqY9ics32ulUUHGO64yEJ+yb+ukVZ2ebI2lYxueL JP48cbkjKdgl6Q61a5exTb6QosJ0+5Vu86NfgrXG/kzFoB24ShRqZ+xgeBhHBcgUEQfrDpfe+hHh SL3jHC55tSIR9FpZHD9xigRbI+jFMCgj3O0pxRrQk8hHODhvkDoV75WMLw951EuLc3VlayYPnInD tUx4Lj9C9D1pmB5r3Rnly03sLfuv6/wN//QRv4r1h6WgsBKeM3vurejI9ZLVDZ5QbrGE2p1n0tI+ 84UK9JmELpkrWiUmmZ7kwzxNOUCpn1aUPJdmeQwKauH5KRar9h/hrl5LuI8H52gJzT6dRjkIrvF/ arErgY1ARCy7jVZY8otkkGRBrflD6Td5D54nRPSaSBIbGHHslzlW1JWh+JbcZwSnhlYm9Ih2nUHq BlYryjoz/sP96lvy7GFss7cVpuVgS0uiQoFqIVuHv1jAQCX1NUW18FCljWcgz5j8BIr1S6Pj2WCL ki4SWrf/IczZWyJv5qNbpnmfyEEPDMIxp1rXJ5XJZOBL6RBiPM116HTEQWd7riZvvfVzQgsjUA0U bGUWTTpZPHeg4gKxwNmNHSJJJMTcOkcU7PwDLDWT8Waw1LWJkEYB/6GmS907krB5QEzYXTDTjvFx Oe0Mnrndq3BSreJRUuhJsDhOnfMHmRUWfgaoZF+wdSi7EEj4A/Si/mW1TMPKjyjBohFIm0LfOHhj MYqagylREkyOzdBlxglTjDmN0e/Nj34tZ1xXil0WTl8hSgffTroh2s1PKSgYAdcvYZ2R3LOtplQh QR3oy9inrAGzDy/HvFEUHBpsNYsnMZ+sO0bf5HgX3N+Ls8p7ZTS/BVhXjoLgh+jlEiG4M3Tx1BcV 7umjTrst3q05XVMsYpCTqJ4hjLnla1BtCWjK8ujc8nbMKXL2op20Ccj4iJ9cK7JsHYSr9aIJciGQ qU6VLDWIOde7cU8a/6b8eA/BSko0Bhp0Frz2HlHkTgXPULrUa+rdz5BNun49vwq7vFPcS4AEgt7I c7fZtEcGSCrmrr3Dbo05v35vLwiMQuINCnvJBBr/RMbyBgq/p6duD0yxkdc0e4WyGjUjP8/u3ofN WKEs/DPrmsdgc1TF/sDeMbDFAymU9kkTVyM1u9kV7+0oJWheKEUn2+374QSaVzD2b8Dcbv+F/yS/ qjUJ83R0DiO7ZlwD/Vn6A+BaWn7+7yu+dKEDtUO1hx4StTCFwuDANdvKmpDe7ctl8lnp8QoRr4+O Rup6ZmRJpOY5NSv9gyFYBCyz/Rjgohi65fazuLe1REucK+Be4AtY2JpGPGCy+KzfLhZ9W5OBvtR4 cyLntXw/tO7zFeyVp5Fn4fyl+OpkXrSA5BUScun4++l1NLcmC6dpZSWp5J4HMtnd8MoQC5abczQL fESEfw4IDh/zquuLaJv/ZhIauRPTWQnm78yGNk7BzdrbN60QPTjU1c6SJ+Pj90ENN9OnkBFOVxMB zLmJ8B5xNXPjjLtICZZKCwPmavFLBhWdMa/pLtbuj3CasaKagIqe7D6nx928lUbloToNw1Eqiavt ZgbOlwcdaB9srQsQJwGyim4l2xI8ZjYL8UOAkgBi1vT6vf5vLA4NLQTt6QguskhUgkoWDJ2zmMAn 5Fa6q3yMDMfyQywL1GMp2aGpS5uUx67+kSXsy7pfFqzjGJmLvQnm8ZdYQaXovVQAfrJh7yOLSeTL 4WhWfs6zMDrlpMue7m3bmGF07+s8iJ2teOuCOIqt5MAG+kXCSVuhdQatGcS+jWdfFjmX4l7LWBUO jb0XSfdqCaOeHhOGR/6hKVoOuBkk9qriz7pbxTxH+3kC0wwtekFbFSlMwZKMJ4ONzGk0fayp0l8u Hngdjx/dbxLJqo+Xu0Gofu18XPIP0j1SlI7QAKdLI9eDN2Q6NIGf9wl4ePGJ8MJyMoUaP6YKQ/5E xt2vho4n8PTDpcW0ZPCIm3Hu7p7NpFp9amXPqyXBPc2ZQ7RIk4lYQFzX6285nPDod98kwUikTQFQ 89Melrujk4bfVAGZW2KrX+WhDsmbLRiS0k5qz3I/eA8v9j0Vk7cFyMX+4pvQZWNdAL3wukOefdeu ieE1rT7cSd7n/BuVop99honwUXqLrglmlddbC9asR6PztTb83CLslDvEMZe66hkaZ688yLk4YHr+ WswhLHd4PEYavjICn2fVkDESUdTuwJCJaSKpLiJO5gLy3vGMG02ZYL4xPK9e8FLZK0l4czZ1DwaD CbDg44Yn5uxen9Zx6aXMJtzZ4uWuyaJEHnBvsaNzq1rivruDhimI+myPvR5R/yn9DPa8Ql5nvS20 SuKEX3oj83IVJEn0HaVwYfD65r1Mx9oO+z43zbszZS3e6ZQ8KSWF90zF8YdJMKCiAEit523ckOsj xLAyt6pf9wMwU0TQOcBFGc6JGEESx7K5wj6ROuJ7hwIPIVhEX9AXqxGEqlkrSYjO06fdkHMGnlew H5GNiRgjHey352ixEsC9NLBYE8a3XeTTwAG426lM6M/LUTllc6LHBIgyaC99uAOpcQq6CvvqXx/v QyZLckVK6N5WRd5GL0y1jtQoggYbstnxYpUQFssV+hSq1TrnQPQ7jo9edy4rUxoXbmlXrG/48xa7 qQ/ukOGdtoFcVzZwMZbyfxEVYvsRQJNAyIj/dHml/gVzp5P+szrrCiPuEiis+v5RzmPovi4jLv7b QYuU2LXvyigzZWIiy+UFl91dbyGt6xS/pxLcw80wezVF65FLve4k9GD+N1cr7Q8cfwzgiwrff9g5 1ToC5KQ0/ElNvD8Pidg5Dyhl+1W5xCJ2BzTv0znDWb79ourNZN9vmGA9ir2gB6vn9Ae7pdapFg6K 3WHjTj8T1fBwvHlarzaNC+Jps1NQspl5V0InKWwSN6Ltt6ByIHw6Al4d3+26pfvL3zQnw24TxVJO eHtaoDZdswTlO/o1xXDAY5NP8NXHqKIfA5zRK5kBTbyKWQt2dzMPyeD7Zi+BlE5qWKaJ923f8dCC OXiPTFst/Zymrktisvnoh0o2GR7zmnRrBA3z0aWzwNw5oEB+h0VGrppjNwP/C2cuFE2rXlJGGUrA 0OSJ0+QQyn+hOdtKBbFeyJ/wYm9qDX3ZFjnV5HXHJhotdgSuSorhFc5OsOxcjEoiC6tLZ0MvGuIH /VCP+fVhZw7CQUXq4KugakqVznrgGin876iwyi9uuXaDuVrWt46C3qNWqa7v4ZYv5g/xX1+vDhYS 4NEaVg9fv/T4H668qdZwAABUIEMj6uIEaefWj5zJGcF5XFtyCNrLbbXPa3tDgOJaVsrISjl1RdJU TFnBbOlO1jqh+RJsM/Fq5Bmx9rujbPcIgtO0vwYgiiGSl0pB1+Wa0oBbdFJEyNasaWNA0Soar05a Wnh7jO6FxDENo/3rNQ5FDHe7bQxfbrkH39bMO0to5kT/z0r48oO7Z3OgsdXo0MThjKHcy4Rcs4dB uIfanqrWejA3p3Tbb/dGzuwCjDfOwuKoRcQ6P81v8IMpDy4Haby/Du5PC8+nUC/WQ3PlwzMr3vrg x5a2DAYApmjm4ZxXDQNjfjOyc9ttPGMlxN6ZGJs7+SCNg+b3c0zC0papKjUbrrXNw1VcGTZwRlgs eIXjC9XPgDrDNcK4EMsgef+UBC90/OhhjgeOszV1x8vOPOx8JEG80c1ICzeMCuVeI/Gju/oixz8Y vOXfjf49cgfrupABSuyy/blXxsQBhEp9xZJjGwLMB/rfNkk9Cnx5YdYMqiu3nWTgP5XWgd/R0Dew PdCeeK8iecr8356uU3+vapMTBjZqYoBFlxUq7ZtUokfXokkRMjKzXeTINjWKnayYRYhjjhAE6jtq yqHyA8F75MemyBNZyBeN4JKX//n4G0/m6qEMoE/EBZX7R5I4gdGXAqYlqrittzhnG8BQ5CQ9x9vz igvxgv7d/W96ELea5EALRssGZytDv7Sr+lJ7Cp2Z2a6abBt/S+LekQcY+X3UILT+zIqI9dGUgYCD D752rGsZTzGAD3cPIDHd7CGBnGMtmvDAP0gih5sQqHMuP5Q7le3a6KtN3v9ViwKtw05wPlFTZiTH St2TfLkXByx99wo0CLd1m39DRj6xnw9x5DBRpZgvFpjoxpW459s7l9qJ2/wVr/XdiSkVh4Njf4YI RUAMzo70xIx4b1M7TX1uPAIdxLN9j9xHvzOZcnNzhP4qfkf1BhaZNhjkLL8VJxqIP0zhMTX5O53h q1z2VyhlfPlKQ+58UUg3p7/9MQJx2VtFRU9wiG15Yn+kqjOQ4wGjW8B7NuV48ocX3le5UQanwRfo bb47w7794PcjHj7hIPVmI6nMio4EgiCnUCFAyY3QuQlsaXxFhE5xlZKlNt2OldqjPndp3i8Da0Uz HWrPlgxb6id96OIOzy6XJwNnYXcAvfE1JhlgfnEK697eXps2Ce2nHGjVpg/oDVew9S6oL+/tHqI8 YHDynhJZV2WdLIYKCRwp7uXo4RlrC/PEP5DOHjmjOf6+H+FYIos4lyj2lp7bjZ5BMhMqyEXqow9U MFhQGFzevhLsn+87KUysZJyMo0AsZg0pim6RO41uvqiPDZxkrgPb4/wOubYuCEfs1Mc0uDUMJHs2 ogOTaxcOWhFvXeImVvj2HXmV5VUFncbadZlNajZRshhIc4oTe9fy+9258ol+T43ZQBnlV2uZkOm9 L26xgMVvOYEcuKaBeBRpuuovkCLLUpMREqJle0ajSRKNAbPxgXfqvp4A0hVaET9n5mlANr/lRnok 7xJONzNi9kKtemHzvcAZ80WQ5bmOsk0ST9laHSxKpYyo7pbfd8w57nBdOYrcdIU/wOSZ17MFrKoK 8d4Y67nVHzNQSjcSHbUr89RA6efEUYLEoOCzTdu3nkWcodcRNPbE9Ds6f2Qs6YyQTOSWXwonPXmJ cWztEKuBI2rsuVBotPXLJVyE05EEjryPzf0DYpx/vLZYYsu31tE3jj+MhJZQMybucRLCFF4zd5ag 6H3UAIV5Ry6hNBgdyWgA1qI1FTbFsFMkz1Vak0Qfu/LQfptm4TEO8apahkxrsHsRvlpTz4oFl4n9 76pq4tbDLikTSRsLS8lJhBFO7hk5el4jIJ8OwQFl6ttm8FKJ1wVirDhWmW+KLQ/4LRhf9osOIa3s RPuWcz0SdIlqYZAiy8yZhmnRsiGMXHx0nYZWMHGMElCQuFAjLewTXy19f42M0mik2wGGm9BV50TN flAaEQDHmDIdOewynZ1cr1g8gZ2my+xx2Qw/6n5EYuEuZoEw6kwoWH/AhfQHgtbpiaQgmE5Nt0X3 EtRYYZwizRpdVhK87gB/Ov8DtPVuf8PmjFZxni4Zz7/qHEiL/R3ejqMTj4o6JmMkNKf7h9jF0IDI 3u9S6fY59yqV36ylRPVOBFzjdhBIdo4sSm/XhSO2fGAi1pmXjbGGpUtetrTwg+mr8WFnDLTT4gJH taJdUgaq0Y3kvWxuoMHyg4HVHn7+xUU9Ko3DVUQNGdPkDHsejKWMQoqIE5vCKi2edO0F6P4F7g/m DPpJ2tOAFQOX9CfvCSitI2yoPi4wE4Oahp6xMEKDcoFKorECGtbZ1ahn7NgXiPZV8QcSDNSiBIoh FsmI7fzJwTuXbVoQ2HaJ2DraeNt5C3osKYutr3sdmCr5BahuPZHaFqaBUSTdH/jcM+HXY3D6aBbB UKQ0yNNNe71FEjwZhqSpCq2NoRBBYV7WnKMRJIXkkbEdV1NWbGxOmGF77jv8AJIxiflW8q/S+PTl zqkrT6f6PDNShcvusPgVK864AcFFXq/TEi7puPUZhgRg6qztFUj8ls8ot1jnhVgkzpPYnyrDoyQk oTn0ST959JuQpu3tu4uUq+/e1JPyyZK4gP0Z0odlE/D/DQlA9r8fdJB7qXjq3IB5iXfYSNkZWMIJ iilgYTBvhR8y3AcX/RpYokBWr44jHRywgc33BQODRGCylp47/kZ5gQgzeWNSHDFr9pv1U5aIZ/Xq ZEvywGo1FbcUibHB06yCKaIuFZUu7ZoR+36XnM7/WsroccAm4yrPTp9KVD35DoMpcLLLQRmL4zAM aEKf1Nyf78lR54GfjCjpEFyieMyof1YNyb+Kj5IjX3OIDXeLqPlfsgL01yYKsShXGnaxrYGrqv03 h2aUPd4n34kCUYdUC5bZMVn9wzCAbZRHx/iN+A+Vx1SAkO0l78GoFEhg5WrvaqjAaXjJ/4n9BL/f 0AzHrapBe+wiLcqX9iB9fENp6xa8G46UJrg/marWI83Fw/sZ7SCMVVF9X/4beRv6edC2aDTxvtLi 6HeSqiBEHcpDCe45FpD1QM4g7YHRgU0nxriuNfAvJKGU+UvllqCy1VEq/Chv77k5M0Q+/jrsKcC+ NEMHneuYwV9J+pKaliwcKMzJoSQ3NZN8rTnFArvDBgVgKzM8sCE5+0LdclCqXpq88GDh72fAqWtJ ZQyQGltOuvGcguJ/BrqPx7GT7kJBHoYRNiV39QzFcUGVCLujLM1PtjO/dOA1oIGzrcxdTKKlSfiU U0dkJu4c5j/zWwaZnSnroXU3bjvQ84GYaBA3oMH9TIPC2UCX6pnA6H56q0adZ7eTcB2zeSDgLWmG HsunTtuxHUKPg8Wv0vj/n/prV18MITL/L0zFAeTPii8Cgzdn6zq1dn+v0yrBcytdnZctv8S7qMhz sU4QVHOB76Mokry8el/zCDn87ovp7CBuVViETq3++JtjR71L49k6DxNg/VwCxPQkop8ohmN9FTgw PvNTgKEleAr0LdX3Qs002cGVB1Ec+K5lq+ub9/pwCk6DiLqUUJ513bKi+XO1Fv89qGvddg/L3Dzk HE5t4KGgkI/N/JQSRMSWEkqUnsHX8Zbkuqu8Pd6pUhXGfanw6RIn3xijSy7ptH6qqINZ7ChcTP11 TiKtpgd3y5BoPMYIuDsdFpVTHq/yuF4Tgb9MlKnhnG5EVP31sEyu/PTXFuJUw3YYwC3oURBqcfLp GhZB+NOfWyFwxwdwcBNXpAh4cjgnVeA4PitX8BENH+cWbuv5wiDwX+xJ8pFLUIVIYK7mq4Lqrf24 OtZZ4wWchiw02sJVwP5tTw0Moa+tdky9Aqi2L6kb46rW1MX/YJavEdARmrjHZINx/tJcBjhK/BSj mFPZHvlpf1dSeWVYQJl7NtZYBj7T7CS0uUs1GZoFOhpve62AUx1aj05pr8BU6HvB/gaBrXOLKXGT kA9X1H4ghVSw0mhAnUNMh6JLDGWXtMc5mGcMwphBjoJpTd0loKCR7rzl8d0Ihnhjeyp5QWE3FOzn 10Dxz46nxnkO4A14RgAh9Ws3XtCWj6Az78MvszF8Xci9yOUAC+Ag4+bMNdMgiXC4vOIow3kHO5sq 8V7R5bs4XLdmuNDRdEa6HptHHcnTMgJWpgYyGTb92TIvUMNnLVqFnp+h/oHpGRWZAth5brug/qFx LNofZUPDb5unTS78QTxcLHuVyMzCH1w44fcEJG9XRssB7NYOnyWx4YZMiZFruxRQ97RGkc0GUJtE +7lQ81trj/Y3R1b+zy/K7dH4dQJk1Bum8D6LMuprK80XeOlpFSFcVTiv9p04cFvg0pbppwz0P/xN 4xzO40ZXrVKVzfj9e9kH57By+a9bnF5Xkm7wR04E5fhqmNwVyOH+Vq7JF4l2/PrGmeD/DtqJw7ma e2OjcZhgLk9/rkbwvHlvJuJhWtr2XAL3MFB01tG96hWQq0yVTdKjPWv9W8lo1e5AAnTyPRc7fGyx vvuv5R6xbMRUVVPmwUpdPsFB9hbFJTxVxPrjC5gF73tL6GwsLYkDpSiv0FcimWdKl9sjMfwWnP// 9TUazt8+avyIR3LcO6vq+DSobTB5BbNVwSp6QYLAwzLXmQuKuIKFKSaFuLaBdDufGvnHuLrb0/QY pwRoexI85Jt96WdXeXlInQggp+JGbCH99n7l0cOT2GclISKPQh4Nh/m3R7OOSV8XSI9lGqfqbyce dY9LevRBzFEoE1pbrd5ZkUcm9RPd/H1Ma9FSN9/hyrLbeVmtOIH+yxTrpqdt67u+QV9a3VetqmZx rVJFPtD4Hdx7PCNqr6BbmHO33J+D4diL4+fhX2uP1cDp/a1xbdSRHM56LbOBxRIPikx657nuyUXo o3Y3OajFFzEo2bTEmaR8mDef1hR2YfRBvRXKvPZSRhhHG4yuStHs7u1LPHZt0Y1ssCnqcdFgWREi SACwt5jDXDu4P/yZXqsAPohAw/yKB825/oM78I6A6wwciGAl0o4pgfI+QIch5WQmBfN5QUQYeFy3 WyiiOt52/ZLgo35mIUZUZGj64AqUBOqTD52LpCjtb9dbPrC3zjgvQR96PQjX4gHwHGdHhcohnDaB pr3SKvLzWmMstRWzmOBB85yyfbJ9oj6K90mXIJg7VUKDomfAWBLzoB2FmFqGeGEAolr+NphiwvDg ZkOP9S08XwhaNxMGEpdJz0YsyT3Ykwx6HBvuzytZRoNnuBzryXikpeZtnoDjv8WvLUl2lJmFztB/ rrkIHZ3PkjiBYzAJIEY05PRUCgQvTbkXyB5XKHT8MB7LyU1EAN+qQ9MGAaSegOaWGKbhbCxQnaoX Frc1RVSEfAASqRKXLux704YyBUc3d/qyLTzraN46jvX589aenRAfjaBD6d1otmDtZMsrz4/6eD3x 2wLJxkEVmvbXKY2LiC7qASE4He5+m4EVJSx/MZfceEFSGk3VTC2zoN87sj/xfKaZs/Z5xb+DW/Zu gUQbmjCdQfAAhd60MM30YDfPfCraXhSRG8/3U3cqMCdgEtpqDI7DXFzS4rfGdZoWvv0TtUPL8IRY 6LK/Q7r/KKuU5pxJ5y3Cjwah6ooJnWaCqG6zpPotXyrwxC0whp1TXRWMyo6vtJj7XT2AnNIyH+B1 60jS+F73fO9fDGcCtEzs5VrS962TdaZWhPJjvR42pJcQVPCw99ntdHpzSFW7LG7h8fhka0RlnNPa xUkTbF2qorWnGcWak4FNeXMUWz8vyVDuhZ7J4DkaR/hJ1MUME731DBEjZLJIXk+AIVOEjChGMUgg SyVi0VHmcZsiw1rHRjFF139twPRXle3Ii8pKBOQydT4KGEDA9cHSw+I06VW3GgnsomhUPpkk0LZv IxswFFy+4kUaQDy+tM4++YAjlxNXTSjzIe/yF+iaU8eea1mktN5OkQgFlaiIO5bGLjoBTcIjJJE/ ILLopXCnAMLJOhXX7aOllcwszTnKbv5ikPdVO7oB0Z3cI5AF3t64+ukXe9CIng5HuYTfbjb8oWlj N8psHV0IkQs82ZZDF5AP6YtnXn5xJWqg9/faupiYfnk1DQTurEbBt3crOK9F3q2+pYp66zlk8wuG IMPg22EXeTV7mWJUk0l5htAB6+9HQF/Thcn6xt98ftxDc2oqup5rKf6qo6vQOXLnd1z2kVgSsToL dCDviTed0cOL8PJmQ6x53BUWCq0Bp5QY6BbpgLaQ/DbGGXzSXFqPe9Mvdhgl0RIkb1+Pcydm11UD ctPJjA3/G/cog56wHzvKu6a9X0ujjhTsJ0o9LPHZ7sUgmTPJhElPsAkRKUePPKBf6qVkH1RKM5N1 1GQXdDhU3Dwwjugs50f/fr0/NZH0EqdAFSnkkP/dwLfaa/a00uV+MKaJN4K4hPkbcYteAtw37DbS pd72O4H9vkLhMJYPh+5kt+XOzNASj35Xb4rAQAOa/ubtn8rcrByZ2Qa1B/xYs0TH/SnbC7pndNvc f/aOOuHCEiQsZClriCOAWSN2LgG9byZnF20xLq0P2tc0YAZ3jy0H6ohY+hmKom0ESQvexW1ETQ2x P+XXTs08+SUWkgu3COdRYYWpLgJLovXJnd5L4kucr6/L+LfNzxXwDCeg3oB/IvHSybQuhuCWqtZv ynXM09ICKor8lfalmJWfI9xmKhAHhvFaiF9393j9dfps6NZLMJs81acoHvlSgF8I3V5qhCJTzI8z 6snN+/klV+6GDk8PF8JvAmtZubhVmqdOCLgvYukVH0AHDanxG9OHRngKpT3vcviaBYmyIUDXj+9W 3Drq0a9jfj+nhJn6xHsNyyncTSmr+QCZDh3eYmLQwhDUc+QXdaGqG8OEMxof/BgqMvWGsHiBM+zy 613s3t+bRJYScOMEUv1/5RP8K3ZOKy9RGlbBcdsiGrmnHCOfogjD7Hw3TWwKFRQxPsWeaS9v1bIM /2hEqiSYYFi7ximQSBiWpHOAnfUeVq3gF4iiB5vDRKpeUHfnzxuXeb6Sg4+XEafGM9QsEyo6odzE Z1fh+FXgh+14E0GDrELybJhK10WMAos++wa+XpxjlGWP29KDVoTHTEkWGd8rU6u7NyRcDxdiXC6I 8ptu0WmTv6WsfvxNe0I4ZSaxw1ItbXQ+aV6YNda0wsvJfOTEdvRJSPuYx4Wld7JKbceC+SrAgIo4 BZ6N4/7vG3s0xMpnsOUT4UDU+ocuPXemTnVFoieNMUMEKstlQabtM99GIaWTLVexbOyzjtIyo9rE 831j30XUbJxjB8qia0I+Nujz8jUeQ7zlyW0mmjb3WjJjzAXob/nMWsNzKxeS5wCooGR4/Il5wb7e HT/pZp91aXEjg0KEp9+urt9lTkPkFm/jBEFcvhY4/mTBe9Tw4QFg/hXDV8WgY13cDF7cOW8o02fS 0Ga7gDqazDwgJtqggFvzp6uBrUp7Tv5yaP/IZAAk1fhV+AQHvT6V/s3YCzpcw5ssjOxFFBzRi8I/ jfzSsgbdTwWDD3oCcSujXhXbrroSi5BKrdrq0E/ztZniDyQT6z/h7rUvSPx3iCjwAi8QVcpergoZ dqc/BKR0M1xaVwS2miTJTdPILqp1QLSXWeXxgBxUDNOx9cjGojGWInJ0qdyLnMNDa+T9kS/wLPZN /X0NHi2EFR46dHJ3U+rgsDYEQfIX26+/5NoNoi5Zfw+GWpFlw1GyfbFwOGYhTitpGiDYK5URaxX9 0na3q2gQjoz94x3Rq4jsbmQDs2lL2ixhn6U40KHBmXeV6zVnav6z+toImTlbqhjVSFv/QCB7k7/3 6GvdeNHJyvZFNvc93B484gfDwHT16Krbrg0H1SzAbMIaNtJjttKvwHxhOhACqQDZsbAIE/Y48MS2 69wOe+xJDFyRflQojxzGt+ID7bQwM2Z9sZvvx1JH2aadrle3nqllSjtDOfTSEsc2PjwF31Tkt+Pr KD6O1HyDl4OKonXJz9oHbXRpeqSrPeRwKi9rm1WzNqcj+V1joarRQ4lqHyToEOs6F3e8z7E+gWlU XPkZazpFcBkhK3ioNOCgo64YESL0VuQbFyjbtlE45K96rWY1Gjc8k24mKb6fMHNAQU81xVTEMuGg 6+AkhvYCYrNEXETa9qbIzF/9lRJEPbuTz/eAJsTjYUVaey48NX3Bobw5ZYfbElowjUmYqLOVDfIb RjAr1nMImflvot7UVpuGckqzXOf/uc3IoeHYrbLIKKpDG8gsRxQlkkxvonjEb07OiIKORxjgK9K/ x8SM6mzvIQjE5Y0wbv7M90kdDT4081vtmgmHZT3rf1Vbs4AbV0Xr2SjHoBUs6jF36e7zlG3OEsh3 52XHh6Yynx0b8sAbwhK9LtwZJ8RErozYzFiXpRVSXdzCFf2B8kanf55RIjX5fKnP3tRMqtRR2v84 68gKMyiCUN5Fj3uddBSILlJH8HJzrRVsfCFex2BqwSin1ZNeWkZGQFxn0CEadUu55ctpD1YyZYpI 0gZCqcrTWndgohUQoPJjfjYOvjphMlRwSbalNbd/lAac8vh5FtNCp87a0+UgmeBEazzG9PN+e03d b+BerPpmwqG0KA7A7HN08R4l/6orby1n8TYncmsx+z1heuogua1XAOXS+DPmmHru5OR7FKXIcDbm +0qHtEAvF+X3+R3MnBIzYYjPTvKXux9KzKmxv6a4SrZ3WI23sy9ycnQ2yf5fSfj7H8yEyHMHh0jM xhq+JEI7FEky2/qUdMgS8A4hJGku/4Rpf5mNqZqCRTsaGvezd+qWfdhhhZWH0G6sqiIjzz7RVJx3 l8rlF3NHVbfvXBMacDMzT0dLNZKsoSyLOfLrlvnpk1pOqPIzxtEyUHC5wvlQOj549smi4JwP0vyw uofmPzfB0wMO52hYawnVJnB2vdP9L08Y9Lhbr+Ckkpr50i7ar/34S0XU8Q62mCLXpTx2ELHLzuoD 7lSanfdbrvn239wK5eacaSxoleJz/9fZyM5jqt5LHZIaCGuUM1Nx5aiH5+ALe0qcDwX8sTatvOqI 9sPEatGMcSwlRq1rmClVA2LIsbrwH4T4UtB1iO+X6L4vxAT4sFl5wpjDutzGrB0cC2cbY8iN7ujC AmiQSP5quDTy7BsDY5HhR5oqH/mPd+7cpD+PmDPEN88FSQtL8F2BdhNy4qbswpo5W+7ApjVUsGjU OwOoSbGix5qieJDd9KGeKbG9ml7A78piqPjAQwNVr/l0wOp9hHSIW4jOCbGHUQpgFHW9ePL1/O5a GxRXmV2qwjYFXJppbqAXzEGTuh7/qXSq3Z65Zker3zc3vyaW4+Rmh+R8PRPKYLouRWjngSYsyfIb jzDVUd1LiNuwRNJi09L5vQq7m20tiMWpnQGoH4RjylHDUoSuwP4jm7aeJGaBV3ednDuYLveYQ1Tk DHhT1smcRunY4zzJoBcSdLy5FM3zmv6pdlNiFMT+tfm3GePgZvckJlKwx3WGEexU2YqaR9BIviMA N5MMp8C51avf16KzV9lGd8P7mp/pVifvVKP/o/UvZun++Bqw1g5z9zyNG4XRukasuf+2bYm804Tj LoyibD55M28h5zUAJ69j++p4GlSgL1Aj5zrywjEtry8ql4FS7fstpdfxNPcyXB8wY29aJY5WHyil tHCUtYsBD1dmFSSjRQHeDLG85P+2Zfagvu991M5PXujqPISouh3VnJmE6kijpCm7TshsEQLJ/DMo M5I4Ph/X4XjAO59TMgdDySPGqjWrJ7PesW2cpuxyoQx5tUY24gzHQgVXDVfPQ/PnWFX8V0cfiwJr GTSymL/JhhXyjfhmwawt5zKfOy2/tlRQgH/IKx3qhQ6atLu5QdNopG444/WTvdv2vfyCEkuFNalU G55LSWwtcMHdokX13ZFLD49N11zmI8yy4m0Zohcl4GrrnotIJT2Q6DXp8nb8rgvbV2YBKIQLBbQJ JJyDcS2YZOIogi2/XoF3VIL+uRYs6AfUU0LpbcqefhwtVJRR2q6TsEp/DCeMf8ZJSvH5bkDFB7K1 KT76v85MeoE+IdKsyaIPcqB4hb7SNxu0Hj8NyoHMx8vklaIh2ee98w9h/kMGZDNLOxVqKFFcVP8f xrd6eU8ssosFF41LV4niGQs6Tfu7E1zRKqTqKst34llUab5lASQhV0XVDYN7GVoCw/nel5pir43L qaStIC0mbPIGu1aVSJkT2vG9EmhdJQytFwQHezJkgNn7ZhdpKsrEA4iV+DN+CehTe279MAAsQCwB ctBFWzZAJ/SnhyaQDdSeXdqLC2653sljV1V8Fgw46cpUsV3ziWoFg3oQj+O3WNAaqdhkj4yj6+7i 9zspcMEluJW0muasYt703wnKhb4QChJJRhmGw5y9dsnmivlDd4YN41+SjGu7m0XvpvgVCGuvco3H 7RtT0x8OVxyzwVyHDS6J8r8bIEMk+3nwt48Mz5hrljbh7YE9a4HLkkRZop/xc4dbAVWNzPIw0cZS nAqK9KbYaoSwTWEjuhu/AeKqJo0PXlkROatMboBdTzdo9tjZshSVgerVnWIvi/y6t2FzpjPT1C5+ a9GK9vqDu617aGW8LCQSJNvofs3vFoLnB6ZbCCXg3t7AIfuzJdvtJ+oJnwGJW6ipVpcnNPXmNuQh nhtFzAeWQEMXs+49mWdYvNgp5Bh7Ub6wZ1RfzQVqgVW/yiPYx/Rj2QrcPBxNRIMItYnRzDxgp03g gMaciqoQnwptyxikNX1ED5Dyuj9ySYPhDXkq1S1Udrfbgu6dZQx0XbXtw92vpwWCWIaqze/ihV3C URNM5UObFJ6dUgmLWs6JtJ1xggQIcgp+VCC/SkdJI1ckyQ9YRBYrfsdpSwKtr9GSPnbVA9r5Jdt1 2wXruX39K05cuxTUUSF1WUzxsYQnN2un1bPKYalH32rNVS4hIDJnt1dIQrYTGYlnl6tsqi2i810H e98kRAYBSs8weHQztTZmlWYe8O767hkTsROvOlzSfoDlb3SdUSEUS/mtwvEOirV8SzDJl0CZaWo7 T6eQHfLYkgOWjeRHfds+MMXrnZayOuj7z2ZHtVm/wgkCP8wCQKq7YjhhCIhzBrcNn6upwa83z5mO G9UvapvvuSWmYS+XzaurSY5gn7Zt0ae1E093I3V/8tIK8rvVKvXNLKDgmrD2NKPjYpPhNbBjSXZQ c+bhLFWJ7BZYdVhy2sCZDHkxRhBSmd1Ir28ez0RpEesap+VLW3FwWmCm7fww85nqlzapZXTjfRcb IVJFiDwP42FO9wl1mhTqBIgHiMxHKbdlKkNb/o2VqKBn0GrNvPoyusLLGZ7yKnf6C8N9XjUzn1iU bLOlryfa8Q/dWKnY4o5fixUyjQAxL5+mcoGurm90jl5mVTd5892jUTs3jiqZWT1fZXD5w6f2Fc5p Y76P8P+ha5efx9NfA1hKanhxWmPXX0iomWbGcY+3L3bNq0RAQlHd0CCi9tVvrr3Y/I9W7676HsxN qtX/PeACkCS70cV5SBUBv8BffL1VHI5PHBRur6plQM2L6DkxhftsgJhZGnH/Yxv9IqOmhAOlzoYp OXMbhvnCRFSW9q538qFBnMQDKzJa8lKeJX7wrGXMIeFU9bzRyiH4xj+xT0JV+LWsr06JFIozF+Aj Cp9iQAl+Kl7r5EziYFkxCzUEATTQmFH5nkBBwIhtvPGvEIDLWOMCg9u/OrYYCUH2vDnK91RKgaR7 j6DTodezAXlR/IXyWHd5d+yAV30s6W3NT/S5Ist3ea1KBT52um5rzc+Kv/OhzJcEMaVCQcxfQSbO kt0Tfn+hZc0ER5dx0zEnd564hI6pwIZKnrhG2GKebI/x7jWyxuVn9jCkeAOv9jQSbJgXGBvM6HdJ RUpNhgbU1C07WjQcV1L8eWtPW1+LRswgxrxEwzC4Enfg3ZSjhU2p3UW68k8lfIoPYF7ah4A4+7Ha DlZJLlYn3jITPFDVtmkSLkZen5HvS+Oc4Bwo2WDCdHRLCUeyIZKMmoFpqoCpbz7xJSLhl2ZB1lIA Paf/8be3eKhRqQDx1o1Wlxf32DVM3BJPFVVOPvJCL8J7g4IzY1rOkpVLSPcWpAuMM0PuvivAmRE7 Jv4E4agrlK1XVjzXwtNf2jmGos9qSgBIw5UHYPCHnQ9gnHpYQ1tWF6zjIEws++k+dpI7ToXAZny4 /SGPCMr65DC6Y1RAk3Bt2V24f/izH8BA7o+6EhxOKcfLNU1RZ9sDFlklOGtnd5uA7QavIKss0/o2 dEOTK9rUd1Z1fluAkkYE+M6MK/QCnnsEN+QmYK6aJg6HegUjsjn8ji4WdoM2i6zO4q/c4BeT0q6j tJcfWgtAQL+aK24Ti5lscTjxq666/LMZN0bCa3KmhIUk+VkBGFEFyulB9mx5BnDMvY7+U0EdhB7r pEl6xtmuoGjQEnGaD8bg9QOPjUUQi4ZFX9YxpFPiJqYvc7cbvRtvRibcArIvHro7role2B0ziURR bPrgFdJ7bGAwQPNxIyMWX+o7fz3Nq55SlRR1TunINSA/QM8annZ3+zKFkDoXG6ENCVrE6e2XHzCr rAv1P9peawnPUnY4qMdtV4VJnMQ6x9Swy2iUNkbuX8p+FCqZ4NtN+sND14D0PQQZbt4QJ00zhTsD Wt/N9Twmux/WyjUhZovB7Ofw/9cHkCVPsh5zMuBMDvfPrwEm1gkcHqPWHS4WmGfifyaFQzQx8usi uwcIiZviaA4xInPylEFp6kHx2W0ZoY8+nx0PmFy4EgVnnm1GdGPP0CZ0AMC0KY0CjF+fop1kOYN2 FTYYUhcZ/TJaz3SGsYHW6AsBKx7C7qNiMJbF4GfUpnwCQnrYvaU98eMb4V+Yv95qsX3AEGpIR/tB IoqlN7/Bw3QzqEPQGczGcJgqlmMGbQPUx4Zoqamhl/f2fT7+VWLy019/ByU0om0UbfPYaO7ijuaq 3uBKzvDVs4EPzijuICWT8Xdc4cSXsWr0kqVQt+j8lfuIy4z5sgtgQ4vRPJ3w9sdBwafV0PyY+mK8 KXm+Vh81Y/ucG2Ri9gmE0Hqul2Yv7Tncp6cZuSRv30eXfSNZBm3UkXip4L4imbesNhHzyTRJahD+ 0MOAXLNSCp7gh6TpXUGFtDizp2slLF5Ewx1RmXk2ejWBPUOrCdbfEbRyafEM/7RRqISrlBQEaCdy Noi+VPPgXHrL8LDDbXMLOjDQgVomoGTdZiW8DCqF51jQRU8rHcxWPUbui8pqoHLTPJHcC/SUAbnJ lrCr8s3UfHFZmb2vqQgTESeR4If5nw+TGSVYnEfaepTPk674kSzRAGhrN16WDXMpwJmwZhZHHaam NKdVXJT/HyqqMflvmBStRR/segFj8n62xEbQRHLYotqTL97p+v75Ivqdej+avKRhVkL5SBzqHMSo R8HiUZAsQhNEQGzbpiEhwJQimENewiIR6Y4oRUj2S5e3+mcfgqUkeUHU4HwRQFDCdl/Ena4tyxPy aO7CmWym6yp+pDe3F9y5fjQ+eJ9gC/G5cTDP10dpeUj5IRm2aMdcMDm2/eHUI4ZqLFHmzL9vDucN cNFdshaASmhvM97XT8f7+AwAWUnpyvvCNrIEYbSjiG+sQb0prYzAovGzgECxp9lzJb+1QS6C1n+C lZXDl2EsTGy4NJ82eSLpxuFd8Cjj/apszhxvK/W90T7XZQfqTpo/atGVwQyQBjwbqJDLYdHfPQ3z SDIcz1Bhx1ROoQuKWmdBJYyINzusKnLrkkhfWT5oQrvLxUpmm+ztF5fvv3XBGk2z/MdukJbHWWbj zNfZqO1eNnLUpqYEae+zx7Tw1nCpXdKGvkBq+267qzKcXv+0W+Ld3AV2lYBuSPLZb3y7Mz24xOF7 rnL2DKuioibiV5eh6KmL4mGEbdWunU37rLL008N16nr/c+dXCyJjWJXG10iAdQb7T2I+lZ8BLqas IyvWeyo22qceJ5UrzDyxD/3HRH7JNaMlE4BRShSmpq4HZZhuRIkjlsw/YpDWldpEWhN3pTD3OUGd X0qDR7FZUQbIvugDPrrO3UcEvjy/03ZU/lRhM4oHmthLOxQPR1ewmI5TSDaHlA5NGzfgeAAysd9N Pqi4VZG7iD57fEhqAdFhciZ/NuyFpCgJm+I0X48qjKdnQa6Uv3VWN0GdI+4anODB/2XFDR3zWWcf y1HUB/1bI7mnezdgmdGqPDh1NDVfBjvgMkQ3YkOdLXMRYjfl+dSr/ViBN9nSbAeyTQucoj4K7D58 SNrJpMfO5i61HTQ1FmaaWJSbtPmO4qKzDA/E5mzHD3HiO7Znf76oPbRrG0f6nSklZR+wHTAGHgds Dj9nSwbUA7pRLFQljpsEdxvNXJa1fpfCntGrx5ifz0h1fxuo90dJ5Q+QEmPJefYN+V/vQhI5Gii3 tFlE2uSCUumgBRnubh6JlP9FNGJk4DGXgP67QCaSw5c+lTR0XcV0MW95qtr5YRdUWcg9dsOHu1QP SvtvZN4tJEe+QkbpjgcJ7ywltuSqlQWYWEiiooFeF1C2l45yEET9NIotjK8Hiw6//FeClZGS61MK CmSbmkF9gQaeiT/z5zDf0aKjo74u3EqzdLXv2w45rjEGCLihY1oanzupeduWRmuMxPkx9i1I7uyO hhvqhWvIzyiCzQZGt4jdEmWfp+wFmz0bXl6y9KUiyhnyNi/nZTDD7VLgZ0RrW9oULTpTwya374L3 VfRmNitZfx+A+RB6jAb9r9QKAwPcsdkMb5xIkk1WS78p0/SxU5u3r6iBu9L4S51rl7E5N5xE3Xhl yUnub/N1OokUv9Piz4HTn7WtdqgJlB4POkdqGwkHutzYIZb+rrgGYz4xDYDB1gvfEdtksfKciwbv el3ji+sQ6fvyMOVSXRPHIb/5tAfMINQgz/LRijJ7AqlCqW+RMXeNTpkPAzeLWpxPiNy9aOzCqr9r xq31erHzjPC1ZvQIi3f8SNfzVEUCUz9/ZaLt53BlStE3lkcA0K1K2eDWHUGokqG7oH5NUW8HbbWA Dxst93Cr9IRm24Rd4fMzqiePMmElQvad3/AzHDuUcP/8aq6MVuAkVmT/kkX820FGoEFDvAjokGtH shoOrVPZ6FlFPrT45oQPI4WnYod2J+ERJ8QFKVP9p4jojeZq8Zim1QrVyDBZRpf3gdKQn8+rK5qz D/N8LMZbudI6ksF3NC4BgqLmlcYtisfeKpfFvvXLozrx2XAxRIXRjBqq8bJAlu1o36/SSXoOom/3 4+2W/q55WV1VBTJOHCkucakg3qVPbgbF6fXGTjwl07Du8LAC8bTlBPF0EL/EJ48OgE4dn0ijv0c2 CcS2cOAMRtnaDoqCt6xlhAM1ENsaYsHMN+0haHGkAqYIpeSWBOOTuAy2UEAltL/WV6tLNuWfIYWc +kSoLoToFiqJHdgZrlb5QGDAZ1oC3TzeO9M5ShNFU9LJ9k3C6jbCabEl9BuEnquDVOpw03seTHFf ukW3aTa8l851e32SxReunvgoeanRzXxXmcrDWeQx1YTYav5kzWhg260pvYUPtywYcsldNdSXcfrh ush87iK2tQUQMT4SHYXoiklWrHviJKCujTYElsbcB2kiyFZt+4cp8eqIJ2SeSUO9dwgI70kC+Ch/ FlsM+7xUNePCW40raVKbkdPGXDIWhU3/q7qSf1Hl+z2hjbNSsKe99e7CL9it1DeYDtXq/nkal3av LveK8127G0AHz8Q+A08EsD5mo8xcn/9jkAQEiHl2vdnUVAys6TDX84aQCr/k7CUkHo1xBGL3oNIZ Rn6Haj/4U7Wi5y9xWNNDafpIX73ZfaKcHl6FqSdGyVtENfp2ny5BPe5FW1JTQXsLhUAZVl2J9vQZ n7gD5Ed8rn/rv/ncVxsr6o5LpKqn9DndDk+wffK66gPAw9+Ci6PzSrWr/Cr+1n0ZWD9aap5kShGn sDycz69G5QNwFy9Y+Ei64csHTcA+ZpXufib0NPel5MFOU+9utlkR+gmK5N21i3JH1syEPVJ4QHVk VEfw2mgWVXoUdPIIMV71ekN9liN7hgMQHLy4yzPePE9hpQNrxSNTZ47ZzGOaybpOnesIRGZ4kpRm lppoSJyU+YafkONKG/qUtt2NNdOB62Afrsg6Zf0ZNdvJumMueYXOax+81IK9B0ApTgvWd1opEAay HdMIj5vn3Nbn/ifw0GD8cLFS2w36bl5jAOYEvIkd/zIzgZCM3jqgf7B0AXLw8BLHzdhQV8c8kwtT Pb8c9oTLykY5p/90E3QfZ/My/34wDSCt0n8SxnvoGvCUb9qSmR5bMu+iUbuYQzPYSFlzwCqir0OI lpul/YE0ZfLc/HZ2gUaSZOIbP0fjHsi8ZmxQzBBLu3AXCccxhs7Oy/BYguXs/Bh3iJadVTNLpwMF Z/C17XvWwjFRDmtjPUmG14RpzWDXeqip/eb6vsXemfMwZnCQcAy2yLbh/El3cWeDqX5mqM3T2qte /VtGAL8Q1LwgfyE6aQBsKtdkifYAmrIGAuqmYlo6Vr4lyM2F94xQ2lANeziKG/87wU9Un22RAhzl 88aoEYHlxcRHKnDAZOJIKS9rxCQ6rWU1bHQGZWsEWcth2bhUAA4sITsz9aHvZGwn1B5thrIJiL4O oEsMPn1UdAc4SaJBHv+3D+y8XfHriHINnzKaKgkO2Ok7zNmm2KQZYuN7nqv8ufmqJ9c1DBWkKQFi hulXjycxfqJNWXxAwizxlj3zzakRd3v4rMqj+do4cy6QHhpFfJvk/lqiIFSsf1/0KNfGHZUpxcGq ErFO560vpQqfAI9lTI028+lDsB1lvr8/AzE9FuY74P3NdXzmcZDrfGd65mCXw/blPvZx04cI3F2E y/jkOZybSHKJ93O0SMkqGRgoa7L8Tan5MrJh2y8EIHi7bPP6mfDLwfKrZweZn2HWaptaRj8jVHzY 2XT/5wa2+uxXbaIdUglyxa1WYy2nBwCgjNS/s6pHTvixIGwdj1d9ocRyY+/bL3QDrHBiHXAVis6M AdKnWRj352HH30m46JeKBjJ2mhqmhnsHnv1O6xYqcuQzh60Vy42fnlYiOp3x9fwqvOcDI1fZNQJt yhV0iTwE+dgfy9VtVa8TMwGhHWDpF/PRmgl42JzZGlCGnkTHpi7D0CJbc8siWZqe6r3ci3QCJ7BN 4qEfdJaf+zUzAx4IQHSj/FXCEBH+FQJrFGQCcaUdwCAHiTAAgmOjvpc4gDStBiifz0hTzBU4XSrB sXjhVAtttpn78l01VihiD4va7pSA4+Jl9GfKHwaFeBwWIkYzp2lXBCTI5fyeOJLu0NUh50m2dXKE vLr3O2KQeqOtpPHISXkl9NjrWbVgv/QN5yRnmWU0AX7jPESlp7uCWxRWujA1UBv2AMF6lBIxoCFv cnQW/nmIwVF5nS1oTouqVKTfkPMraSYTopByfwxr/NwrkjYijMGzBj9M17Wb+QgOIWzvJ/ENb1b8 du90hrg4349BB6cbuB81bmUoHTJnTkXpITUL1PfpewH4tHZJJ5+PjO61r5F7LLfqLKFLk6B427Ce Xm1mTEiX+wCXphhe6GcjVq6VHvXDImIruv19GL8wjqKbTNQEGYe1P91nmx6I8SMGpcDlUXeCkSXY 6ehxB+Ivy3ECbbk6UUQ/Is2S5efNPsIF2YV5F5Et0J/6HKrTB9g84EhT9Zom6/HLRFCJqpPPlxoI iUF9A16XsONHW4oJbD0kF7ojS+WQ02y4YHQlTzNh3r+X4AH6wr9sXBSAIyGgrXU3xAM9pYy55Fpy 78bW1QJjOeG2Prt7hmsy8v3OZUapwhHYHM9ZxHeSDK7QkN19xjKXyOMCu2BiRt/QS6qn5RfSVLPK kBdqYy+9wzHRkoO5fNRLil3GaM66bDyNCsnlPQR/eLEVWYt5cL6be3kHk/Vr4spuW3AFBHhQ1rVO AN0Z48R58Dh4+dqy1HFZoMVgD7HFRY0GGomRRVfTK9GrGr1BjXTm3Pvoxvmf5lDAgn324i1XNNgY RNJyIhBXGx4B43W/xAPhzBtii3d5YtD1V7Cl0rQNzr8XpPBXL5uOIzOMJAYVWcImvhCXjW+bZymw OukpxBfNDORUJpKjFE+WdRK3cLzu26yIf+V6eAj/ow0o9A9PgrTIZOHMPkJqYwMMtqFO2B/94gJ/ OBqPPHanml9BiLokJzTVzO1uK+SBs0bYAEyVefuSQ7uwkp1BzjC2vSX/LDY1SQukc/K++J4L5emT Zxq06/TSiQxjTnqKWCaTE0tnApQs3K5T70sAHzStf7j+BwPYIua2FJqZ/2572nY8xlVWR8CH71Y/ y5CF8MAc1uvdjagjrDRHBnjqwUCsuvS2xi3ZfvwohgnMkzlptukI3yfvQhfkD+Vv8UU+WS12hBKE OfIfljl9WujuIhhN4nVgkGxaWc+VyWQCWqkc/mYHuuPMEXJt6zjAGLlBQeSaqlzjv9uFiJfUzyht BPIWQAYfWNAXjjFmBm8rT30p01rhfxELnUZtrQhwxpkxW2jevmqEGPGLlO474jew46UU+2qApXf6 7yFlaTZSDR9cQ627pZkSm3DZhEzDPdu0cUNbvWaykceIuQkYw1JGRZbcokPY76OGjJBPwgJPvAXv OIPY71FvmWAb64eeFG7VkNaXaWk09ldxGLG8jw9lwZSOEcR5GQjjqJFxajPzq6Ballq66t5D73Jw +iPRK07sx3T2HvK1iE7lLCzf4UaRkRyuusNZYaY6LGSZqS7EdWBerFFxucbGb1ri+QV1J+fQVaHu s6i5Ti3xMKPUVuBYakzAkqCmZVs+YHNAAk7oA14jOHrgiD8/DJzVWLyYaLBYHPvQUDf+xZYL4Z0u Om6yYBOKn0aE6PRThxU0XgZuPmjdBhX/y586zGy8DZhnuLbAXXTdgKBmuX3ux8P7YQZW8wlXWVpK 5kz32L8az4VizWsFQY2u+itttqieIomOKAH2daiqqzWd8bY6luVwmtOk6nxBS2f+Ylq5xON9GL+x 9DMIZPm3J/LpSKGDdq6xR8iEY8xRL2twKKwki1J29WB4oRKVGqGdV+aYJyzhcatmQo+XJPX/CxWe RkFzbDKwxdawgvBAIeQlCSDC5a1gGSapUSU8GMxm4ogP9+SH7wMAbynhyxN+Z2U4id3h1rWscVpJ bfJ8u91WNGrxxU7TSSu4tBetZiivLGh0xG0niG6ivkeYmIyvODoQynqn0qFGG2Z7JuU/taMJfM76 jRwFgYjuANg7waTj7Gw1I94tMZBaHW6+KSpvBEi6TIguVR0AoSm2zrMIYKE+ghl/loBHSe/XAmrb FM+QtR515yhu6QuBDtct6owTxKszG5o6ZjDmoV39NX+DkfJTIH0SZ3ST5u5iiNQBzaA65p2XIBKp fLZ5PWkpeKUIHaThoV+EJCwjD4z6PtBaPGLd+co2VqkKcAkxu+bjdjtUK/9gQ7royjKYuUIjuAtP uXV+wzmCmcowyf9UR4TvxCmmkugwvkqcN54Diogm5ex9mRlK59o9TYqsNdYco5djbgTu11LP7KzT 4QX3KZ1KkG+BrQAAAm0fT1S9PaJsggLYiSDAACB2PX74EnbV421jSkdFgt7kv4xiuYVY/Rg2McYF wNpCKPX1CxvZdZVWicl04jjvOASWq05rZi1P6IDGU+WSVIpfJX8tAeaHqn5GAIG+2LfrvmlaUCWp JxV5+PEmelEghv33j6RMUuSnwTAKgY+iLukUHOG5enyWGdWmwgHUkNAc4mCuH8HFzgAIqGTyFXpg +9sTTeMD1DjJkbSymlyp1hZ3yg0/3tqwDz3EL6oK2Cwxb9seOLJ1kdAQGZxe00jzGpRAzF8zQyIA ixrfRvNWAt+iZayNykUWZygTqXiFFak+5TePWeRj7kc8CjGO+J7PxaJtXxzpKWSljtKLsQPreRQP NKRF/nelG906qMhGSAws29zNiDa/CCZ0BjH9qlebnH3TU1sKF4RskebIVZtxR7pqBvKYg1IDIMyY U4NEB5ydHzUuOs3lRbze39+Qn9IkkmbftbfSYQInhjQksedDxjJhPJI9uhwn/c//HetpYBmYzoFy 6uLg2KvYbWVrcBC9seuF6X1EnVEd0ZZi6nst0uXYD7j0C5AgV5ObVfoVCIhiM5GYkYC37NnU9xEg YQKEUVXQJh7rOUG1wpJcuFzi27aqNPJtTz8I0ivRA7Q6KR5gAVUNkuPFOZukK+OHcVLQDSjIlSgU ARDTLDxr5inlNASKDv7qz9eRvJ92MDwh/6T0KiXU59NR3oZ4yDtt+rveNtXsw35dLCDDXoGYpBnX SKbxWoAY192C/h8rqZBD7oRhNFr8SL1DAZxf08OYPvy+fyyfPXrT951YKkSsEZ53etq0JSc/eldJ vH/5WlnepygRdVeo9wAXoyAkj01KTfIueWTxeUJefZhuby0wQkqB1rhC9KqwHWQ1jA8mYEpFqCF3 tZcJDU1SfO9DPVCIupbbAn1mB6ZmBUzMuPCmPDNYeZo0GE7VXfkHdS4+Qyu71JeBEw64i1FscxyJ ydYxNHNbfrEGPjcMlPfkXGuvLVLXbgN5fwGg0T6ry8dfaPz0RN311BttxSVUdZm2Z6vwVL4biGZK xiAoePl3LMsbrK4TMm7K5sBQ3LHsG9S0YjaumQ3mm4DgOLBiAMSey0xO6hOfEBMjlDKb2BXp4iZD ybNWDnCMKwNnNG6R7I2+CvKQaE7h5qhDe54ZnNV9RO3jA4zR39vRENIiItEBkeVZNQNBkeHk2GZG OE7Q3/3jZlFTAOpKdCydcSUOpV8h9LxiVgJBHy/FrqL7qjKy1xAXvENoCo6T8ptXM+/EE/rn6DUg Jzxt+VsqeTZ2KD3wU6kFMYC/Y/sbUPMpPpJEEI5DREY+XiGBRevELem0wF3pU9x9as8fDuzySoIK W8+rmOyCzSajBiiCX3M/W+Ye9qz5nR9cNiBLr5UruQXZWM8SsVmjJ7ZSzN2PKRrtl/9EU59zm5Dq 7V8MaJ9r55t/YdgsCd0rm3bDOkxhjyY00Q5ziKrk9bBb31iq2bEJTHAV510CyuDnP5BwhhvUBbh1 oJpONcHKxly9PYAXUVIyTJcd+wB+qs+elS+Lu4UHX/oxDq+z+V/Y8y6IPWrUGCzcSzUuarzlkMJY ZSJRsrFecoKRsfKW8wXFHHPd0IrzJ08iJPWhw3HZC3y5DOoCs14qoqyJE+P//j7nQpqUN2G+J0EI nYd6wOTdt+TsWS488VNRiN0h+ruqX4OzYAkvDvLlanQgehcWRNH1UuRUbYl+Div7P2FmZmBjTP0F XIFJf7FFF/Pa/A57YPCnJVIydLx//A6bJye9WrrejaVQCqw9WTRHYyOY51W2R5Xl55OrFAOAcAqk zWHI9IgiN/LSuN5gZTLbAkiJXSfPnAIekcWZtB+3f+xDWbXAfME5nEtSKWlJAEGxVJGvjxM8ixVe Rpdutu+9iwbhs7PFgSpiXLTJjYmUnWyTETlTmyGuU3vcADwpujcsDPzgDDnBR4+sgo99lyM/HZa0 HgdKHZMBnq/l9OqHAf0/olhAbFIgA3cjsSu/KGgk0L7hofFX+Jyvl3rjyCWPxOXaYOEr5I+LN1F3 c4+ceak2vzB8B6gfOwtcs6WV9EdGf18kU/vZBI07Vw0e6dUc9evNcrIB9xAm7nWwSu727XK/QchT TfUytcesb52sCw1CHAtSgdYGzp73yKGF2DcE8Qz/CyAZU+9mDQsEtiytAjAnJQLwVB0JlLVXYZIw kjbVzrqARHX0FuEdSgyyTKfD1oxO6jOyEwYv9pI1vA8v8UBAvfRjABTEp4O2sfJJdrdeSOBWzzOK /DziHOvHAUxTLue1hpQR8KBkx9Q+RHkIWj6K/s8403GK5bk/iP1cA495U206K8FJ9hOwhJVhDDX2 kNAwHvGlx6iStOddpmQFno4vzhUy+VEZi/pPVFma00Ja5SEyqJBNsqrcCG3LTvY+TkKQ4YTGq1AA kQl4WGRZHqNSQb8Y/0j/YmtJjdWnervdYiTGaqFeL5a/OsqXJfqMH32CXyuIst+aAsGkFOmnpNCD xJ+6iasGmW1QEwh2dh6MPiDV+bwVBZ4s/s4Qemvw9ATRf5BmgaVsdFnPK9AA7Yhbnj53vesNUUpZ AorV7IPYFdPZa/jW9cQkONUud124gyf3sBSxnrMTiHBlSQLoYe9F0bjncFrSJe7g5eNeCscjBphc t/t7jYtT0l5JKAmQMUDe9jrPsYLCa6FYHLP08CVIx8pU2nowpOhPJ8MdnrfhGxKHjVuarjQjuXh8 9sNtcD6n5qqvv4m3o/av3XCvXRJbsPWq3XkICnoCVJH2IKP5yKOC7rtjlbOGAddHjq0R65DSRLbZ 8QEsSDlVW2Z3muTcuHFBG1t01/Fcl0U0PKLJS9qeV07NgeFPtJhx49B5kUGrKJfYJaPzvGtgTwlo NIhKW/cx60UYfdUJdwnFUlhvBWqcmdeZLWikL7i7oItRCoiMLmwEvGVgOUcdSfpGMEFOPPYYfj3H kF609q14FR4fcDs7cQ+uxkz0854+XCSdjARv9Cl8Bo9IhQs0hgdWhNlv/LfRrtrYACy0RGVXlZa2 Uthud4Xt7EkmptNFjTdPm48Y0DBVHCMXSFsaerbAIlpK53CTGI3KcIR38aeBBCXQ5WJMkBy77+sq ojvGkSOJDqsUYdNT6crhEA10Jv2GdDYY+a1fA/KtRbMVQvaYzj/DRwq++LCSiojqWLg6qSQ7oFAK CW0IkhX6yve8VCeNpIzc+s2rIjlhiuTJhKi4Dkw2Ty6L9lck868ZNmFezOYkrOxaUqUCmri0BsCF EcMH7KY8ZG0ID3gFl0QBs6wdYTlRm/kB4emybTf3gNcE2trt81KK+VSpmQWjL6ZYscTs6t89PivO erMb7c7hgU5InS46A7Y6G6t4w8yvuXxMVruvfWu4nZHwyFdCD8jJC0IsOYDQULQkbADY4XPoknFp GHw+0mbeLwKPck2y5qeBTWqR5uQWyYKXl0sehX+NlUl2g73RCiGmUBqwfiQBdkzCyWLTcww5hHtn dB97gglaYxx7wXcnqY2m+ahvIFvnBJbSzYmPUL1G8b+mjyxnVdbbStbVLqn0BuIPQEdCwWtLeBXB t69245K6MrmCuBtT2/cZLzejQdL9Sh/PF5pQwkjkvc60zDNC7Wq+VnZREKkeV+wYyFBD+vjWCC3N 5ZkOCBh+5JHpb5vbBCkQ0duUITQyqaepGbHD9bgoaYmzau3YhwjMLj/Mz3UKMmAuzKb55UbTVRRQ DtjDNSqNda6axAkVaBQXITChSDLL2irdlW8LZb41EpwM92zxQ+KIcGy6w4sKioJobbt3pYhbNeQT kvbZKY278cap73ruBcpQ3oOrhPPGJK6awBNNR6PhwyaQH5gqAfa3R/EDnWect/3xKpkWRSh0g45E U32wK1lzVOHLdGvgZslN1U2bDo3xi17j7QSan9rh7hYSBgl4xJo+h5ly+rz9/rBWKgDvo5T1C1UA 3qH99Ejh+ytxhbXU1Wbf2+xrV0/uDi3LKnJbLd3QGDOxKcI2Yavpo7E8Us6g0X7rsObIO1JKhPBZ +kiBJ5mlFRbg6mR/TOglJbXiwmnrdUmM0xjZF0im1FeSRw17sqGYXy3zOYDO/meTetoC7QVnyN1y m2M8MqJnVJw9CAp9Pn2ZiMrlUTvrfHL6DmfFgwHIOTsRo0F3V5e05VQvUIGAFxOVvSKw2AVf6/9y NfWpCpH3zToqDSf3qJKrDx2HXkInQbEwCXJ+HZ8vRcyAMmnRRzS823E1Btdi9f70/ALWLavgi72Y D/P24WEmEkOeei1dY/X06CQpjuif65xh9pS0UJtcPKvCl9dlNjB2E5lbyaQ1bdRfQ8GCSk7Ug5lk JWwvs4krYeS5CcvbW4hL6m2XISi9r4zn/HmcUJ0H4YAVCpYlhzf6q1GFYbf1w6tmA30tqmvtuFXk X/Zv1dOVPIIaF5+Pg28efYpNHSCLUBUVpEAbc21IyvFunOfAfPPrneBQ3BYimKv0ytwRG0RDOpOg LIHtUlUDCLspDTkQN6F+1NQY7ggQ8kwr71O7Xe3EY8EhuuLQN28VqgvzdGKXxFD+ch9qE3YK+3ZN C4gLHPvKzcf0YNi6u5kWkYOHX8jgTu9iAwUPSZ/v/g8x686c3yafWMHwSaZZzhW7pk16J3r9/fH+ 0epFGLCgGmtPbF9Tar1wMjZJGVDci8Rt8eygzbvs4nws1EUL6dKFJfG+lXCuCMwdLjPH3NleWDAc eOCfOVkca/7OmWQcF+zRG4YTTHrxnSdBDRAF8ehzpAB/uheg0OWrS9Msua9G3tMtbSgXmyV2nTpi qOv5+St4bG0gx9wVABRZ/Cm/WVUp6RUSKWIom9z3xS+EAgaaN3+r4JvSO2yCL3mK/nzg2CXusGTG raOzNZI1fs4iu8+PsKs0jyfe3IYQe1gkyDlzAYTyWAT+oCkvke2ljmGXZDOqPIprR0nhwsLhRcxQ vfa52PXfJIwvnSquyNdm3XTXsD7mO7IDFcCnXlhzscjDBcnVmpFndRPI+R1z2qI1ggfGXJtJzI2a KSpK/sWB+XRUkZN9cg+m2XCD6bpjxtlyOmox1u/jywEu9DWGgWcvjQ5/AGjC1s4LxyjthA0pxjeo pJy/Q7SvHEJwj/VptzRCAAdA+L/4mJp30/0CA1S38UBEn+JjPiDYY/IpskPs0ghyy/ekgLs4rV3L 3ga4W9zItaa09FxtE3r9+JYaMj/RG/I2KIeTdH8m/Bet8j2iI31Tqv7oD/5VBcB9s5aoV6N2/Jiy H0jxt584x+hLw3/hkyp3RguoEpcbut8BOOOpxQvKB888ArJsrV0m7GiCi5HOgvmFmNGR3HTIZRwV 1MMnXYaXfk88iatjlM4xzTYJ3yBLeZv21m1aolg80yMl4ZwKGv6EGmOgTfJ0+/CiK2n++Tj4FMs2 ftMGf3085pCkIaAB2wgl+B55mvrM1cGdTTm/x4i286f6PcteV0ENE9QsnyvyJ+BD2NVTV/n9aoFp R8eC7dsEIq2o8v8nwfn4k4CuOTGC96VH0F+Sn2NQzJbvy+5mmkMquy5mE8wOxmmM8h3cjlLffTn/ /xOc5eV85xQmQbPrtj3Ta8qbev5rZD0nYt+oLKSBpfza3IikCN4YxYP2UetvwGZFRS31pVm/zwS9 eNOLGZe6vnpZJYPfL6749kKsgnc+B6p/964WKyyUDlrjJGMf0QQESDxd22nH5wxIBicRZsgNAQfC 4zDH2Q5XtdlJHAclzb5+8MLrL4uxeNXoi0oP0tyaahJz1zzq5vgz8WFotEqdtfQXDfLIr2lwZhSw A8D8sQsTllSl0WRRKZwJL6R/ZgdTNAFAQSOG9wpjlwfnBd8quOEZMbHhWyDEh5uKVKycQlrgjXWE J0a6gxGvko6w4AOKPuvirWc7YcE3imcJ0/gmGBQg92i3r9qCUG1IYdOYYgjlalZGm2w8P5HjaTYh VVHLPv9AUDzGD1fulzLpLhYwXFTwjqkLN5tnuwPRDlkVTOOuWDuV5/04WvXvKrmYp+SLHr+iirw4 1l6Vom7qAxxxJaO29tQoVwKkc5mdmDHhZPQfez7rFFXpIm3r+Ls0+r6cvzywwzGzwQnnbUTI3hS8 7ygavQBikQH7deS2B8IAQpV292i4a5vilMVlr8cxbV8f+rwZjA6UAu3rmyr2Bvce2FzffCuQb5aD TWeyRrorbkOBkukKNiH4jwgLEOHKSPI2Wn4HgegXTzUkviZ8klgcZW7dELaIu2VzQYjogrO4hKDQ 0uPidMQPxcgL4B1BGVOJvcRkDoE3twogqSau50Fw4IUTpqMp7fa6blfBNAbZXlf8iHUeFM1rERgG W3AvsNVe1B4Hdhz16LjVai+QrgqY8gojm5EfPeFUDmyV88p6V0BVABsZFrBu8NBQO+UBebZeypZF B+Su/JDQox7pOFLKIuYKOtJmpl2LOmIrIiRdkTqhhUsSVwzlj7G/E3WxIcDS1YVxINFgGAQU/4Ib EuUGIR2BDzM0TxKDBa455Nw8BRw74EJ8bsQ0tm1Zih+R++uI8FFw2up7cW9hVOGanOcO3UbDEMBR Qw0IYTvs4J3qxWcCjcT5AVWyU62zyRehopvJ34onootbMNFXwm9lBzjivbC9yy/A8VAhcj4Lqnw+ edCFWttJdnvySmEIWhJLOrpDR8VJWpr9iihvyuNhpHmnXrvUoqMS0S+wgWS8QJRJj0ZI/zfTP36z cgv6vWIUhmsfGorEo3zFeKlFwK5DBxkMo36XWLGvCa2z9H562Jrmx19IDIP60uEVlP8ZTjazMTAS a7g4AytAuraCeqShA+BbmChlDMLVBe5/jTNsuHyHcAY2bEqOuEEKGuN/d3j9V1m3rd3FF0MdPrCC T8vnEuWSDvLpPQn2QZuc6WhpTH/KNJnFHpXMfMXBG2e0WIehLtVRICyvQTyLG8Ml1D9L/FgitiEM X66DkYzPr+hWK4W4qFtDLh6QojAhP5wH6fchZGtxIKQ7SmbAxyzV9r/JUT5fACS3TvyDEXVXbomK Hp3nwi4ALhyuR/nPCNfoUB4VEfPZsCVP3cQ/KclRMIxHeROTua7aBRMmjl6mOJH3Q5GOx+d1QJHU SrLwwy5v7aWThTGxjyJKyCAOnRt57Jk00gmFN5/YD5r3KUgtwFWGXeDQLWKUNI4dX1xg/+aU/+RK LclofDyxsvXmzhMlpcZ3wfUkATof6sgSq4s8BtkaQBPcvGBV24Hm4eZKLEvUZ3W2JKwIL/ZyI49d MeNAuBe/U0orHdtGP2pUTMSb/mj95qyW/5D84aDhHPOlxII0tqoPUPl4G2YeZtT4lyf/qKhalK0f ZZrvgt/QAkm0rZUKpzpq2P7XtQDICbgffQYxUAQCHmC4n9DL3+VvIcfu3P7PmXtqtt758U4RHsZG A0uKJTpJ9E5rdmxvEOKmDtDiGIi//rxkyo2GcoarBhswUCPc4Ifw4yJHy0KgRsakWYumleiuCe68 C+LLGgCMcogLNPZ1mYX1WLTEuM5FrfKaosXSu/tE3e8EkcTMa+DdmMgegewirBI6M1BAly8TGPFq n8/BjzAE2+kKP99XdkH6IwQWmuRCHqt74LbNWXtUpcZLrGM3bc8TcSs59nK3K7l1T5iVuTudf9US rwKjEa+qSFj5RD+ZJFIVqCqu+XqyrUhs60UUcZa4YDPtfCE7vrjhZ/GtFKKwmlqGow14mOgzG+U8 Ar6D/1BnzBnWR5DzGKCCUplXLU1tySgjpeorKTGQDlmuW4D93PLoCKq0DLg4TnQVNMnD0c/97xcw tHlHKV0dFSWftc6jS6CqAlnOcajfUxb+kHLAnOt270r3PiGq77KHxpnDApb3/8/gMDYh1PyeeuuX SbSdeTQ+YdKZAzcDbfK4XbxBfpnohuZYIvLQy4s9I2uiKraIfIypAonG205pLYkgv7QU2ZujohYG lOwy+ZV+8nkBDAjEc89VQX520X47J5mgvtNuWWJpLL9kIeuQ+CFM+nCLwBP5qfFDckkOPqT9hYA+ B6suFLKOiv9tX+yh3Dr3xRwICoHfryEreuCwFFWVWK10SBePBc9pytE2c1tg6j1j1xTFVJ5MaH/0 iWqmEUB6CO9RD4VJIHxXoSoXz/pYuD8bEbwOs2GJ/7H6MjK9ynJ/i4hIcA+dmA+7oOI1XTmFgbCl fNaQ8ghORQHPuF1+3pHMMGnarHH1Du8WTGIeYIQzQM6fpEk1S9LXoQZ2BbaqIcH/cqsqbAybCmaR mBiNbKXInq3MvrjEzBavZ6/cicIYxsfWmzRosz6VZC0a9ze+9A5cyK4eSKIhqM+H+cp4h6jPetHg yOi2xvd1CcP4elcKQpb/HcfjuY0Bq/Ls3FSslCW97xLdzNjPd1TTMonI9bPid/E2AI2SuCZjgIsQ Iz2EHq24zZmx9XSMYcCX9cw25wUpP9yqDN68sq5hFKYxc3Lg8qVl2ZLTnBYjli92axUCqvz1weD1 SopbK8sn6j8kI+EvdhuveBs99vPvdxUKVGZrcTZclxcnKOdj+VSBov/H2Rywg48FFwB2vTiic3fy 2NoqBvRqdQo7b2Y+ggFzc6507744PNDFFxETbCSHDRx4Hlp/IGx0NwNJOaoJHBqF49j9g+yvUGS/ Pyim/XkGi2TgGLRv7o0UCQWsrN5Jv5mWtwcV0DaAPvip0eNSSRu0aowRVVsyBZKWJlpVMhbZKrJL WKeMGvIaJpmbqSu53JGC/lmTKVhvWjJcGglVzFxoqbVDQT2GYBWeUiYaTXkt9ZfEx1ovetoRoQUD gy1jCiUEkQ5NyGA7UP8/6j/iNJHAk8UTje/Zba0SR0ooGq7sunzc1dnENgQhLdH0b1+Nvaw57Mag 96Fx/Fk3ht1IP/BEcPPVBDsnB6RmhD+Yle8omSc4w109GJ/QfaAxgr5YQwunLGed+GDmNcGZmEjR FvbpE230XJ2fWZeQ18PjJ881C9vZQNn+49XNfZ0xrqIaxq0QFeJ6xE4DIogqmH9QwtWbZvWOpwng vB+ofpqkgK7oTuWr4p+mO90wnC+bbCQN5wgXPeiy6yKQr1oaQTWXIO5x5lalnvCFMZuhgD9zsQvz AN1q0kJOvKqYtYvNdpi4zjEbIoE2L7FlPc2LvhUE7o4fVD1QjVP8uzwYJsds5bU2gmmFyKjSsfXU EPscFyFaPJRENKAXMfZBKz2eEqf5kPumDD5FPoQN2DGPHBe6Avu0CbNwINPJIsron5TimKtLI9TP KMrKBwg0AeCQTh5ZkGNh4ckypgr7kZtQSqR+9lx7VXTxEFcRWKQZ+ymri4Y7pf6cdble3k0c2U33 mIGZ6IiiDZZNz3I6ix4xY/juJivIUuifylTg1UIbj8ozAYCzVgoUsh+c1r3jTjYQKYO/XA9BgGVQ 0BvJAmiywB/7vhpPDouSAaPvU38E9K1K181sxzdb1jUWJFUnDEDGSGS+6BXn+gHACM06c5844iZx sYdwDMPTRKdIEGfAJJzqLUdW9FDaTcjPOcwIzC3w4tECdLZ3179QGGOhBts/t6zzeI6rWmYf+qvP g8IpS15qhp8Wd/NknZVkC4eufpwxKTXCcvSC+4l8BP+hUidmAG/7gzyG/8OEczYvaQOKNx3TgfY3 BWLETD0kg6beZV0Yf2Dz7kW+sJIe3WQ6mgX01FS6W6ke8VYkeA0+Fpg/UD+ftbJyNL8a/xs7D8QE ZnYmiY3eLmen0rS22wrMMvBXG6OSijxgpUaTZeB12jHe5xvVJJDv/50GpfKFa6NxjuI8+brFG9bw zwKEMVCKcIW+giDlA0XroFsw+nHqJNbXOyESCumNA7h+pXTJOamiUeaCiVPTcbySviCSkHChPEo1 3XZiqliQlSOA+nc58L9hV06a9O7age+pFSgQBFGeAesvsD9T8l3h93q4EwV4/EmmIMRpnWxb4Fr8 3jvmSO3PSoicQdW1HHd5/tINhryXOcKvo9x99K4vjzirjMbfSH88OIPZuu2k0x5Vtr6Vx+FCDoCj z6DQ8GziOJfYHhN9UinT3lok1JmUCG+vz8/cjoc9VyfPB/pDL8MsP32JiTwpaHt59Xmg5L6r1ju5 gfH2FsIi2EHAKX8xeuNWeFPNj+OD1nNOMkLhCv0mQ6yE8hvWLm8fgS4Ev0DdAfdKgXdfek0Ua+eW DUnEZI65QHEUxTyMhR9I42937SeJ5rFrcIcIxMTfs1cTkGffsnenP9ucf1ldOGAxZa30mB9ak/B+ lrYhwHPoFcxcqLaLU7xzXO1O/xreNalvu+rrDAMRn4XJrLuiTocJv63/r5fx2MUD549QPu1XD7zt GH4MSixyC/HHyMEax3IWS1veHxvN2PNlQAXZFLcydMIWnccjrR9a+ZU6yzLQuP1s86QQk/+/A1Jp O0MGT3zY/paC0G5zTgjUn0xKAVuTmehleI9VqipRI0NiSJs9Gk6PF6E7tjHcQRLHK35aURZnh4PC VJTwvGiK62yA/gqBq2Od2gr29050XWIUQWXQtW0O8ygt/XV310XtEJ1sC+ai9/N4XtwTX1phKNK0 1XJ4LBHquHMUVAljh0wJYfQrFdFWJso9yX2Y48nE14gP/U8ZPk++jKCBBVAQz8STBdGsH0PBZFtO NOk8fV6arGCYLIMBm77bOZoCUipytF4PUAsdIBFxg1yEHml+/BJegSraVwzIlFWRLBTOuIvpQb+r /8KWaKmS3l3qIF3mnvS8w1L4kCk7Ra4svv9xjBZat4cQHbKEjjfIbcJ8+BXl+WKDfMQtpaW2FtYN 9r6EcOgYKTbbGK073WC3NtAXIhborwKCplo9wTQnb4k9jSC4ViDniFFSCUum3V3tVqs2rbd/mjLr 6YPoyUpmthp7x4YAOajdW4a+jnfB/HWJqKd74hF7CgJGjzJmr+jkGWUhTy9kRPEqpQrbix8AJ7n6 0aMqvZSvH0Kq9EIgW6NxJeC28I/2JILaggz54VHo0tGOsToXYUk4lCgBzWhQugOmEAOKZxBCN0GS wN9iU3bLlGQIA0VpfqEq5NvejmG2/lyGmKgSMhLYti+d55H5mZ3GhKsSLuLtlPlIsnkdOQ8xs2Uz yO6kIufytzR9qqljt58fji3fq+E+Xz5YVGGPVV6+IrhNeciIi/QODujmuxUY/PltC/QwNA3W5lSh mlnCxvTwz9YsmEAxWvlT0m8S0ouFFZwHzgHsq6eva7R4i1qsHuFYd3C79sJs+ecV5JoPciPXGXxn iLKinZeJg9ANWA+j+Jtr2/FpyTJTX1VwXZI8F542qh2ETLzQuOPDOWkntoY8uM7RXD6UCywi6zxZ iZT2yG3+KBGQa73zBVGd9vNimhXe47fNYKhOqltNvKRqw6pbXUeZ9N25QgLAm5J773K0yxO9CeNk BYkoiq3NCjXPZhayQXPTRK6qD9SBF2QpqW0Vr7QcKS5SSetcW2+BTrEwqK9BPwu+bdG0urEkKtfE i1YnzlcX74BI8FjsAk4sWdN0f2psrxbe167fUIEerzRjKD2LdShBlzQZKfYSHnsh/ideR/BizjXV 2ocCcFiUT2p5HZlYe0JMqyEx7vDI/mZKyK3t7BZvA3gArI4WXxD5CIP6cOHzrRclhdZP2qPqnT8Y 8qppShhgEpAlxs0BdFjFCAZ5XgYGCEq87cNUZ9lDmUIIYN6O1OrjAG07VW9zMKOcoZDCk/yV773e X3LZwGBOVdVbjZUt7xZ6NpiFwmaC5bG3bJbRt/app9O69GvXhH7D9qiXDa7In8GX3VIMl4MTUhoM pXxrizTRkPNZIl+RJGBMu3Ga9vlj34eSBclEfn8qoEFQMsEsX7jySmVGD5Tgc1ImRCMbPOXRcyn4 ACDs/nyCvS1k5cbbucwElz2nMGzibKVHNm+TZ2UaThfVqigvEfUCF7G5fvMcZwcNg9z/XtywkIhB 5Ab629PXFq9Dx9aNWixFMVGjOMkm0fhLN/pDv9xzQqFaWHRSasC7V+zoRa5a4N49UUP0sQeKRrKo pZDEDXDGxvpKy/t1xXoB/qe74YXCXX9yhY9fWtp2d7ixxxbbEj5F8MKEWW2O0Gzlvp1uX8vNOUke e/GVNgaN+u6rURZqyDfWXJksaQTEXZ3WHZJVvD8Gn/ORGpYrSm1hzlxxWIRMhviEYF5ODkBGiREa 96il1NPRUac+LFD/LY5jLYX4Q1fDTKNLzsPqpbmkbZVCTLhvve7pcVv2rKubUzXJGwI9VUiFX3u7 XOPYRtEIWwZvo4J8CidHQ4e1AHEgXDfaR0OqFhiLCKFJz9yopPzDL+iv3/4eigTo9x4thlvhIsva plORzsX5l++zPBWwVRc/NaSuG+Fj5g3QWCKNNqADcEFUJyNUE9h3rBT7gT6CRnXERh6f2RF2eKDn 5J1oJuG21ep+z9/VAX96XkdZ7ILmku1OqVcysqlIWBGbtpEqzy7tNY+/gN7Mrg/g4IuWeCOOQoqR jKdy7adOfgBO3+DmbPzp1pJH9SL6GulY4Ic0k0SrOwyqtQn8Vdzgk4xEe7pAeG4YLErqvKOlnkEW p6sWK0eMsNpZ4/sazNWe5d/BozBiUHndOrR3yCcLJX0ch9wFCToC7GSfE2cBFjUpI7/Vkwf4RQsa exIJnjSzghFipAKeK2OO5b8+Mv2ZzEfPMITIB4B7HEtjeZzI5tzjuRk9e1Zxc5JbOsM5SrGuF0Eu Mawk6Mxpk0ggqkxHgRF9jaUUzF8W9zZFNus8fFDFm4JhaWz8QEQwbtwOr8nj43E8nHI394SGOJC1 eTPo8Xw6vMYnQHa8rXiF/8kXKcvQ+5pBFwAc0smnk84pHA7s6kKQ3kTXRRjwbxj1WRUX5LBWIQXx BF1h4gSAtQslZ4lmgktSyYYiFioG7cZ3WFoLb/wKE1H5jFOjiPXuUWUCOIP4oBUx3cyvwy7OP7Yl /ATjGbcOsdHgkXB0OhhAOh40GCR3QEYH6O1JZo12KAtt4QIaWLtwB5mD9JoIYK77tkhSEHFUx72r 2S4iqvZ/YW5tO67HC3Hqg9nIJNa27E/OEFW0S3gt69J0xFJQJMK1tWuq+zLLOzVracP0XedPdIMa gLpHZmNrBxx9jE4+y0fCRRjbMlYdjiU8ZAfsInyeA3HlDX0zid27MP2hAbTd0uzTxK0y2IpMgPUB PdrydyIMHCgp9dRnsrs44nLGScR+JslqHpSlTkGVbs3Q6uWkuCoz08sur0fhf03rnbiCqVF8zUc7 s9PUdDK5hGTWWxiSNUmNN3YV4o0mg+rgL4dvTAwqQcoV8/uVEXOH0K2B6H7EjKkLn8f9VxhdmJ96 m2Lr5p2GVfhmOzRw9fFrQ7U+GbVLiXNDSnV6bzq2qieclm4mKofnv3UcwwnxgDRVgm94Z9FJz8T9 vQigVWLc5MTt6GLvoEHJ2Fw0274Cc2K3l0L7thkYRh2ghyFiqvXfizlFA9S1JQi94u9BJLM/J/Gz 834JHsP7yo/PNCWM8sfCKa5O9Y/t4mMJEAHdV18Pgs+HFClsI3Pf5jG2gqozP9qb20zC0TzlodmG TMLIoBm1gSpenblh3bjS32PRaUaemtzUhQMmuunpmJnoAxQOcb6nQV40yTuzBt/DbMubId++6fwR lwHjnEOJgA53RrGd0smsocJ3Nb2+QnebvEAUc04/rf5dFKUK9IfnjvhnVZ4klYDt5dNzI5SjbP1S oi8z+dsMQ+cj3W6gqkP5dCrOqq0nlwsb61iB/ebezcOOnRni3/GyzT1Rb/sD5mAOkEGPPWbQmaLZ jBrtzQD8iVitcuECoPPCzEU3fbVUAbFi63ON/LvwvorQOh8TEf0u+VMXb+8MYCUkkhUVcqyxGZEZ R72GfY8e3ijz2/YhICJr1646mu4XZ1Usob0zkJgON+8FjX8iha+iUwuND/D36poFKFD/Wy/UYv4J 1ZZ3LszcShDNXvbZQEPs8nw6fYiNEG3Xwwk9hCYL6o8gto4bx4NuIgnIgmbJS/+53yEIO2Tl4Oho eiTkEpNTVGAt//sUAhe9TVnzfUSdxgsw0kjS+mYMPpGjaSeWaBywec7/kDrHeovlQx96iXxwmNfz rot/GIPhw0fFfstx/KSyrOJuy9ZyXrfMnYC947d/6FDGM3eSK8Yele0T7ogXbw9cJSMltf+/5oXt llpO9FjTxYpPUbaN1OvbaIjG1/K8aXG8QWgTTBacvHhHndRSgtlY5WA9+iwfj6/889bbWXJUOyWp OKy6uLQZzp27deB4UVKXS8rZWZ1MxOyBl4V/1VeYGGn4H6aqUs/MUqbRpHZ5R9f8q/mBkTuBeYak 0vFmBlaCekhjtD2uo76b1+EB+ZTh4CMvT7QoyN3vWe+aSl7s8d4yO0CPwpavB6s2s2Ba7AX+ziqD Haj79ciqSS51A6CqbwbrFOGDpe0iZhRLSHJPCoqKk51dd0VzC8z5tgHBlpW/NkjUlP6DhIAGj6+U VLgDsb6J7x8kbU6CYIqnl8J5W/QG4MqhIwv80K6vkPhS14qsuV9MwJEau8cGb1G86JzOA3dJmhqt OOlfF+QcBYVFtty+3XcalexsNOqd9p+2E/9DynmFz5M3W/heoylpSg7AV/BsvG44grKq7fycARJW 7GQVi4xxNS+s79ocpYZt57nxlRi2PJNDVNzECxgUiB0buPEidIfxVWcK3h5aX47B8MGjENLIOuAn 3xbpxzyiK8jIuuKoQW9Z3qBtbM80HiObPaxxK9oJrvPyjErTEsi96yaXWndwCz+ouIbH0LKHoB9K srF5AeHxCbZsgAmXieqs3in3ocBxYxlxllmdHt4KLZNNhtleLFYdGOKcCwVxFIS8+Bvs/J2ntHUd NmSy7fRhh0D0vq+mZeUFYYfM7SO6bPQJN0PvbInAQvBYnFEHezx5l+PhAwOwWlVRWXMnBDdlU51O FrrTDiguqq6nXlKC2eCKjcex9BasqFeru22QO6o1rgLVI32Du6S+a/SB0pCtFYEM5JayLnWGS54M Evl6EtimBWZTejpIxMOOe9wI5dB0h/39N+y0tyZB91zwMrZRDA8VH3B+UQc5+idjNNOo5HzJ2/km cxMymrqwrUk8mPcbVkzuOr5fLrRewHEsu5pxSaVzDJcBQqkIW3hptThZnr8nZDksnz6/V6NzauOn hIJLiDD41WBdLC/0A5HIlc+GpC4JjndTDntOJrYQVK1oPxaYJedmdzuGT2CU3+c7MLObvKtVV6AJ 89THpBDS//ho8VfKSkXkczuBMYNG4Ot5VFSpU3EctRl/z6zEOThLmKEi21BrbD4FNHqT+8XbhiKH SZGsAdg9lCO4s2Vi9NEaB58IYoyuz7bXN8jnNDnsDOZ8Xe43Gr5Q+DGPd2ZZn8d01kfAUl41UVl6 Ob8oK4TYelGe3KpWQr5jsyWO7G+IQTzNQ7uP7JouiR/XyAjDvlgCyu2NPqeEPt3ft7fpb2g3BOqd qhdsJ7sdXors6VvQe8RsOWqE+vrNwI4XExjviIm+13wdYjKtw2Y+DQ9mCKUaAr6naxwvtA24WSau bB6h+0IZ428u22vcuLcFs+KryenDLlaF3FKFpcQJh/7ZSLLGEZ33Zq30SWpHZfS/6CAR7dnXKP/F we4H7R37Kco4utqynWOjfE0rzLzQWJtKkClPM4d1ZiAA9YzqK24I5bYfW8+XJSAGIGjsurHWDUjm vaw3q7AQy0HPCSGEIu5e6lH8Jo0saoJ63rGShmLg6/Cw/vYfvpXoiTmsFVJe6SBhLf/ba0ifz2iJ wHr3i5qw3Id1O7TnclzIAZ48jTK254mqWlAhJAHxYeDe8p9N7h3r6ipcQS47DfvYTtKRekIOH9Pv 2A/inUY3sd6IHGiRYIks3qvdrBU6p5PG0YHmDca+PazMg1c7FMjlEgmD42SkoaB+pxaFejyI99qE Qc1q+f03u9P5PvhelSpGNMRGZpHMDByn8D+QMoyd16KrNjM9KAyleF1cd40QWjTv7jIeS2gCTH9m R/T5TwwY4oxnBqm9+FRxb/Rek9MQxYwQBMDtAX28ogkoB1Oc0qqcrifipJN20PsKwynNRSb9nyv2 jCImnZqvj4Ual5BuQUSuoyorRa1ar2MaMUvhQN5gLxe0Elopa7uVGwWGcffqoguweEACXRMxn5lX lzvDewF/6wfaLG7bZEeUgMjSVyy/sS3jOvRh/0mhHaHhbc9gJLFtt0CxrJxKtkp0kopCk675VA1X U8cXO8g+7IZ3lzOtj88m1jS7+EfBDW6j28JuvRd0tYl0YNHAia9R0wqwTIReO+nW8Qh/q52ktDzs h4hA2aqbbpoffiVC708lc4ZhWFbkscnkItge0eFnvIkOoQUSsc9ZLavfMixTSXElJaYixCz+HkoA 4kDwVftAV/2dQllvWMnFpwc2KuseoLtQpojXRwo0LdL6JucSNv039Puo8VGpuGO/+9AtuXomYu7M KQwjw9AYHFfX+qtOK54FKOEfyKbNEsnhA9suyAC8SEY9MJZtTd7v6pDFdSjrWgiK8XjRD7GmeZqA OCNgJtyswtRkZ11balcLwi0XHaqsBSZ9eIAIhdBkg6GuAOhhq/vB1p/iIFhp4Q0dQlg6e75KDFTB LF7H/cm8k4mvbsNDsn9IrBPQ8Klk2I+hys4E0kDJbvnwM+Lb/FbJ/5pPTrd+lv0d+0q1MiAY09be W5CQHcae+Gg5CL7iXSGok4XEpunC/tY3M7m4yqbrXm/pwb4sMjKLRF0XKKOoGPljIoK6WIrlf5Rl TT62U/9XDCECRRb4lG1dJBUvjhgWd+Z5SJ8WWn7UM3gAByEGqr+0R+flApenTH7jcnmzvqrdjFjQ 2OPdDJY6kLLfwKa0YquJ0fxYLomLHe2hkmdkmYwh47sMd5YvaTooA368upmraEZDvn2yr8K9PWXN 7T8amVcYAxYEvL2QJlmv4lFfc2ogHbk1S09rXn90K/n8+l+aSkCw29LMp2s6kuaDCTx/2rizAzPS C7eWzguRcZYGtVPVxe//BVlXUj9ilAgODAkdoT2e91lu6Ktg2jRhOlmT1aVlHmRXitBc4HxR1iyu asXu6HJgE8EZN1fdUaedPjrAuTmTdzb0+2oegca/uHISHg1L8QeFTUQzZjb4gAVFb+FcproAVVX1 Wm5srKmAPaAMQuHJo/hvfx7J14KdggnsdhpATNpYvZN55EsEQ7GNYBcja/6l5+333IP5gNhk8S14 NM2bNUeEPNXdQuwZz6p76+zUecWj3ZK6R4VjjgCjGiMtwdkW6URsQySc2UklvtE6kE7jQT4QJ2fJ Xx6C+N76IFlsasEMswKQrZty4hHKvAxP6LPqEmivQTqLphPkEeSuBQ0/lRq3Q7WSeXBuWYFvs3tw ClZSefgFl3yzvWJMSGCBXBepd+8IhhMmSYdQICA84Tu1Ve3G8R4CEN9qpjFO2bpyeK0t6PG8YncM An3H89yqNxYs4sDcvuKEc/EFB8SjkFeb+MdQWjX2jC2R0nxf8RYL2MqnH0z5TIieP/k3Q17iT4cB WA0Lp832hWWNOUfrkIZvYKwlIyAHA0QGCzhHDhXt8wJF5NBMdtdJGvCiGijRYaJuPa0Rea9sLThJ EBU01ED9nUP5fVLCBnmPpN2ZMX47+q+AKJ5/qLO7ouvpEu27ccWpxeUfVaQ1EFbNACt+FZHiAF7d KHX/2sbFLG+E4iwfXVVSAj23W3GON+asmxReqaWQFEZR+UadOY+OoU9dwdPvPc2XsIc3EY6qCs8v y/Bjd/q8C97stD+PD0/vgeVh5DPTvVLkqAT4WpMF5+nS6k05tU+uEeG2g6Jmmdd5wAVaRarJ/1pQ b1L+eNJe8TIZc1yjjlUNy/ijvtO1XzWie4obMIhcXI4wbR3MtQPfKtirhQN3KG2C1+hYdaTWfU2T tSpTlMQyfqatmlgasVF2flrOBDfH+qFcSWphGplMLcy/aqbkB8aDiBFVUhH4tt0O/mgG0YD8L68r MUDtBvXhcOOW7eTIsSHCvd7YkGO5gPMnTHF1+czxuGH/4Q9l338A3NUCtnLM4NJH/dVUaksNEgc3 BcAsEqQNkuocW3qL7Ft8EbS1py8+evu4Dqul+MRqK9sS0aBDVpY+03iiFDnC3ucV0aBtpoOTycVu ByNsxLrT6OTGZWiMNeowOAuui4rrEj+PM6vNZou/Ml7DurcQA3rmIF0oMAzgW3V8EOGg7a89jMnA Vn4BNNMzhfIRehciyJ99wHOro1durqcnxZ13W1Wph/QCqBQWFacSbv4PpSsB7g1+EOBL86xdgCC1 hc5nXudjtzkoMH4CXKRhVDoIbB0sVGNagjegazyJfscszxHAvSU2evorv3fHpIZx6CCvwn6JTP1c gLSjBfvbwDKhMP5OEGq4WBUdK5H28lIMbnGxoBTCb21AoUM/OO3MQLaPKMSsBs6OH4D/Zq2fxjTZ i90UYnWyIMX+K67E1+3J2/dfDRE3jQwxhe4i6klrHTkg2aJG9hAV7Zdn9My9ORATrg8cFdnIE15W 1gATj20nLg6UaOrNJ193/nv3CdQKIRom5y1asy8iIIChoiBQVFMsphKgTRQff6fv8Jx5hOP8j7kE 6RrAyJWCApUtt+HfQBIdDd0stqsRVsUfpbzxFYWN0FDR87f94Fi7i9G69AaTPXfZf0G1AjwnxgIg qofZk4YysdFPDw4LmNkTk3sqLZdTC4t3y0qVWLKNFkqqAS996IbIiD1Ya9xUHSeGr4H9ydhiqZem CzhaN3wPHQf2y1kQ5Mw5DMg7ZADK7sNpcVi+/TLs6lx2AaDP61/06ijlWdzo0tPKMwlOtfU8Ycpv 4rR8dphXJEU/zdNmHErCHjTtNBId2tXJlwvL1kwIYxTi3cD87BLkaER4/P0lACnAtuPp3hKckCd9 ZPffd6G4QuaZZhJcd9JLk9H1qE0tMzMbrfHFZKnYxovS8Fq3TvV0+nS85AQld4r902Z12dnZK5cR W947Ia56clPcnuuB2iyFSaOChZlx1/FqRfXzfOHFqIsi2M2n/HdZ9t59vkEAB0vOb3zCL1m+iG4F gT43JIoDSXPSySvAE1li19MBlT86M2H0EiEGSvebj8TwbrTJ4rGR5KqIRO4OrRCL7lyLcW25o54D EmAe6KcIX3Agky1SDxbr9FMmZ3GDxXLzFfX57dwU4c1c7Nqrh31fT9zx6BOnYs48AE88AOxX/gHr QjTg7J0OqcQJIxwFVAxV3BRsdeErp/8cQuy312EcD0De7PaABqgXKfHsRoXQYNt+mOMKlC0ex0Ko pnfmA13wZl8AZ77wkFpwCQQSbhlb3MQT/NkSkQRrTkxQT9OFnfpFNuaN9iGSaaHxgLdoDERpDWeH q+6YfoWknRgqWOntD0GzY5uWinU4j4Lbs6sCRf33Cr/NncsGuls5AjRyWYXVWASZLyPUUgKrjdPE hSNuK3aG4kmsc/ZZu2zO9hGBlBTbwOW6l8ldxDN5qD59cGXG4n8mIErjCayhm+RGFHt4wvGZJN/f SHIjeTq63zmVFjvGXUBahWhcKuNlyjFAndkgAQXGaSzVvLYVIBJ5KgmzNnmSZsqezc1PVC53UA4K CWSL9rTwCT6RXDFegKmN9fchqE4QT0+JNnOZuCIN5dxdBAs3qxty6BMOLdBdDo1A0BnhmeqSfCLh 763B2Ls342bL5caxqBwhs5VpW0ZJQm5JXZLk6nxHO8G1ck5jpVBWjkE8QqKdbIfuYzy/26ATDNnL LICEW9J25rSxn2SMMoZftOVqc7F3xh8PMHvJ2dV8e95YU7LprqrDja/H8+DsRIU02UjTFwhRKZQ3 mfD/PGtabSbg9c1wRmUphxxO89i5itxLqOHc6/ua8i2Li2sccy9j68iiOCpeEjl5a0AbV2dhQfe3 3tCt+f9FkTA32kJuTffPeA6DjULOb4IwDfNjziDan1z5kfU5/qwr5xnCZ+3E5QdQ3560LYAl/XFE Y+7UwLSGSMAF4YwSi2KQffQBqaLIctl3NP87UQqr+OEgpZicy+yWkmYeltgXwdc8WONwrJVHk86K gwNNn3P1k6Mru2tpnWyNsf9N7g603QEfkU+AZdurAyCuvHF1rMt7nTcyEgeBMmAFLMeA1Xr1TuT7 e2lPHX3zU2lCEquBoNOBcehSgGcQePjj1O+Euy6WrEHQcL6tm3KqW2T5tCVer04aO5T0MyX+5WEf wHbOLn4vtyjvwsSztHVrr0HEUHHZ+CaHvQM8kW2MLBseDkTP4GIGn0CytlFHsc6uxIjEeKBC4QDx MUYrGo58r8BL9HsjZQkYzVj0Tel6MTaUDCZtQKZkgbZmLbBhG9E18ekIJTnibSCBTBLyDvMGPTQc azUERjGfU3+1A+I4Z9WplL6Z8nu7toA5E/7mIkU+8udjo6Yk35SIFlcmh9JWVwwjT+2/iBLSZSnk x7HK52yDuifxt0t9wuv3TXQvQBDUupvFqwVZCM4MwHlBiLN0dIt3z1upchUkfy/7GCU2Ib6cJqUN J8rkm8wJPBCYlOQP76FA1ysbqaJXFZUeyt4F0ERk3uINflRM2SvhfINaXNxb3BEpDfZpkxtTRJX5 XngLli08umbq+uYReoAtb/0zEqWiGC8PxLLo+K74kqR5kt+lR8kKxOWgpIxsBV7iuj9b+Qp5Y5pu nLZnnsNjmCcZYjyoQEHp/iLxDjconHchPXFAe0k25PLJFyUKtiHGJhd6C1OBPIrq1I8nvzBHiUZw ZfWMSCH+etjI5R4LTys4zpwCv+dwTVu5Tfr9bOo7m1uMtTefllClbaUryvoXiT4fQwqePvQjhCfq G9cNMuGrhPk0WDZXJnFO8JUUcjBZWnj2//GA+KT+LJnk0QGahh/XhYlfAtOKBrd4vFm4Ya6GtF09 Lk42PFw7ux5OMgpfblJPXYOdAyjOozf+wiTqxoVGqK4WpuKrCDF9t075vl+LOwaKV4ERkrBUIggI KG9L+WOtpRgctF5+JtKYAAQV8WsqpRfMvj4odj4TSpyW12jX8fA3BX7Ila6zSOMmHekb2l7WAgoi mrME9WtS91xgheMv6YxS3APEwuPHU9X1Rr8cc2pTu3Mt+JD4A8iTuPXjPGVk44lW1e1VdyRkYbgv Uf7WM3nuGayGHp0fE4SPvAnDiYPpnxPzphyV7otqLb6dAlxyc2Per2HMeif+Y4cngSAxHy5Qzqpc 8OJdRLnRmTLdLSvSW16aqxLXtqEiCfyAzYcxu/3WU8hdjUAPbDvHHzvELvIeYCMksaMdcQHAIym+ EYMcmRNEkuEm+HnCC5JSuoT5UPq9n8G+zbzh9pZUtImnLNmmRF8eiDafC4Oi06JhotHxpmIr/Kcr TV8XTrbs7cGtcybXvCmLqTfDJKUY1tgJsjiLoySOisn58KOeWvHZCQc5Eo9T8Ttc0W/UJuWitSBk RDrOdG7zoaodYH6UcHbpdb7HE+aQtq98m1avlfHehaaU7wNG/b/TBPu49bpLQp1w/isngEdotYLb 0WRh6uasqj06NIwuba8TVtbx2QXK0f2vICC/RCu8Rfvojc3S/IkB7ObF72AkStcV92G/R1rJkBm2 O5PBsvN38yfl00/AD7Irmos9TVWN5qQsBrchQNIRIFpWcLnFrsZhHBkpPW7PDNWo0Y8B0LLwtLZD F0LOzeaHz5u28tjCFs36IUARWaZXYdwdqDArLNvx4xSly3M7Q5Yk40l9pOr0dcHI1X46Es+Evlxw gO942LAC/OA+chcg7rXEOZid5SZq7rhIpWMMGdP5M5+ngaokOzsNINdTeZ6hgsydj9x+YCo9z47w Pv1NwNaKJGvXzO5+XbnkGMivWmMSK8qlQCTsF5pIv+/0KS2YiwBcnTwXRMC99KaHEXWzWOhFm4X5 aunJJmMbfHFPAEeiuXn2JZi2+z0jYCKjSoyaWCS9TnzyiWJSj43komTXObo2a2O1R8IaL90DyWgo KMGOQ/pBVFyJf/QnTuQ0qUUn4x6/VY5eMTN3cwOc3dE8tD50avx/xOHUCR4HNe8Tb9acqlZf04lw 0ny8SjKxkpCisOUJQFWuH21vA+4TsZtpoibMl4OZZCpTgii/AJWM5MQ57ZIFKClxVudJOt/vXEKt zIfwlZWpKqSDm88yQZtuXHO0CKoW8N0hZaZKT5qqi+CdJ3OO6sbuAoek7ID66Th1/Cv5vw2OxdDJ n99SzsRMMv4fmm6ZDPIIi4vi4QhM6JgW2NYpLrzdbzHehkrWwr7Q+0A7JycYtfSx1FqVyguz3eCl NHKNWQVaxwrrEWpnEVH5+py0M5mlAK3rIOTGBOwijOtXlchcRe9S4Ld2FyAgHcz63rkfb/YeNEYW 1E98KuKCn0R4jXQFmeHDpIlgigXkKkFb3++meAN/ESUejDJnHbEHvLvotxmTULrKkv8kWGWhOasT 5C5/eH1c96wEJC+UdEWAjwH8DqZo+lENYgrhSd19MUIaF5IriQKRJaxRNSng50TolZXilZijikWu G9jaU/j3imeju6qaxwFHPFMIs9U5jybSyHn9q/MFCRw3vscr6Pqj0ZB6UBT0ETNcl9yWkzfDl+N1 8g3xbINggwug0qqDR95WwrcTdNDuOCyReitILh5eLhqDl6FmGBtZPLrOQKI4w833y41ML5mbS7X9 7V8eIdKjcSS30ZHmkFpEH1bQJTckpsFRJF+Iq10YfBt3rZ4bOKcTyDKpVlqNJwXdQRvdU+wk1PLr QiQ+BlPD2IBlR+mnQEje54rN+qwtz3UIMd/yTMVHHrTzWYTTVjb/rZahJEiBDAGv9RqM036/gBGy +tkfZlMi6UkPvK12NokRHDgunJmbMqLu6XstcddWXApnTRUeoP8bkPESE/09FOKxMmkE3i0t1ino q7n7D1d02SSfQPL3zEOp7p5XklC+cBSFdeCY8MIStg3PzcPznusmDWdHStQhVCF2GmqhM7+h/Sic ze6F6YIpswhZ2q6Gf9LTQlFsn12Fgz3yM9a/DpQ60pnBXY0xYLZQ2OB13upxwp4JEbmXs7z0NF3F pYbu3Qo4zHD7ehquFYJZQ1g7hJ+giYa7mJLlDAtWuAs4Ra2Ax8tfRxg2r2/Yqmf9f/oQ0w1BYBpF RrKRVXFZjF963oLAtKaEiQ7z2l/A+H+OeP/k2SP6gIPvc9/ECEGlqxJ/ppigxJ94rkX+xAhpujuY m5nrjHMQcu+1dkBo4rjxIUR6MgRUc28bwF+429HAz8NpI3znxasJXKhhJwNWC1sXz+fscEh+F3Eq QPFBMRZu03Tat7e/nVCAJvLHs2FAoZT2BuiFByLfXuUkfwvpyMUzBUQHK1F9xP5G0LZz+37jZABv KYNVzIdnX7RobNkpmEEinoQcckbDHcHsDZ9sraCPZH0d8fzwUvnrTPsmPNHNh+QBO4LoHXFlmbnB w34lmY4T5ITGEUmg78Nxyfr+e+MziA4R2yX0q+sb2or2pYPM9f6FT2aSem3n3CED/CZKpS6c+WtV JiECZyXct/4YUxrOWnJWPTLXQb9+E3XcAA30e9hvT3VhXwiftL+UH3Xfjv/5r+KCppmodHCZDMPO 6iwTQWQpLbATlfwgauv2277LKmkYhMUSapqeZK10eG+d7aJPYt7l9FuW2gmnfi2vx/j6M7Fxr+9D sH9FCvvEZcyzu+MnNdTB6JgCv/Iwlw76FjQQbUv7VZt0pK0M5oLr4h8SsQOXscx00rbwPXphLNxT tl6guzGlckiybezxymvGOoyh1wb9WLpTNdl0s5rZcIDoR3fNgF1WGrR8J9zAs7f0HSBkUyt/Q8nP HBq4zI2IMKHdY5ssUUaFY6mM1uJUpQ5J3jRmlZgSa0kj2XUvkQtsVDQNjpuZbM0MhuTxklVbTmvV OQ0aE2dd8dz5ozys+MRyHEY2dQDbXw3VHcAhCghyg4WJzZkrwiIyFkBt/NmI02piakunupSz+KcC FotDNxmPjszBplhnYyBnMsO+ncUBXW/nGOlyswhpSH5dFZyBywfjdXpH93xrQZqm5/9YHanKDrOU muOoGEQOalPZDBfmkshSHGfZnjdHK5eGb+3ZqdPhDyWyrLibuRR3E6d2SOJKKMv4d6z0MqEv8hsQ MKbo/HvuFDjtid8QxunS0oQNDXpEozCm0/0ZF7agcjuokeU+N6t8pVUpCqTaLiIO6Vsxfcyae2UV qSKzrGNbEtQ6LK22KbYZor9teIiApDHdZgcJOqWme09RD5Tjb75uSxrd3ajXMeH0v5D1Gt17ZhRr L+IjLNsy7aHBrzYZhtANs5YNFi6mRW+VczqzmHDRX3W9If9e3ECa/GjZU5g5zo9CLpsCEvwdaHx1 DoLE5oD0wv9lw/LUiFM3MxuGzBeCSGfHPtNjB8cwZwscyPxWKslh91G4WSFd1PhKQclQcCVrzbNN ppOj5eztsOq6DHfWqnrB2YiClmdtxil8AeMOgl3Yq4hEXX10q9KA6o1A6ri3lVXMnOhMG49pbHAL jS8MuEOp8lRiQUqWb2aHWjQmpyuoRJfrX0PDT99pFzmDKs2Mk7IwyWzoLBphvUFZuXTBjHCmKCBW kRLdYRNaUIWog3ks2tc7tfJmhuW3FnEtLzh43VK809AT6H3a7Np1ikjsL7aoOU14EZzcOTwPa+6t m1le7bDH+f0T0BBMkIPznvLjLaYEr1ItxI33WTC3aOKRT7HZW6m0URWXfdkDf2Jb9i9PMgETZgB9 CmKwYynSPx6zTdd72dE9USkSh8WcBPBhtmPxxah722AxI0sX3C8vEd0smH2zh174Qrgzx2UWFlGo CEYwpMv3go632dtWApHh/CoPmdSZzCKnN3sbaBg24vTVukiQO851hubBizmshiBVD49SPHzfAJTl 6YhrcJv3NoRymZR+nlmhI6YsBoOBRLZ7dtOUs/i08vHDSm/WJ2LI+Qof1NiKxh5LFp7hDPhQ5Rtr plhzC4TzNYsTi+YFFLCCiFGsJmS46WvljDtEkWl8L5q/euO40NBAAQSfDuOk6WtCw1hmXF+TxnN2 u7NPKHblj7PwUQZHjokxookXdNOa0tilqxONjK5ZbCy2yMOtL50yGoWp8rhq4Hy3dt1lEFUV0TIg clDjcxllkhZMZPhhts3GHODxOiNW8gBcTPdZxPddTd3eRRr13J5kuAEwvevIBFKCN3YOFwQOlmNq aWgtGo3mA38PEBeyab45urJQazBIepmY1GlD7Um1ZIKDvz2fXFDEagXtMyItfPYZxwcXIk3UwUvz oXM0Fs5URBc4jFz/AoMRtMg7YjognUkSpCN23ZRgS3xqWAZOBoeAKnbW4WqJEdGdrfTfFBSLHM2x CiC8QqxXs5mQzp4ZVyvf2Jk1mAdNVwzQnP8T249fH73Fy0hFwGq2YWh0c4jsOqhEiA7osga2nGK7 QDDDDwL92bWITZeALBm6IDI0TrrFrZ5ZbOQP3ILwXsupG4PFyhrrOm3Q2YgHpAwPOj1vauYHmpno QjhLiuhIcwD4+X4yktwgK1xgkWo+hN7pn+3wHL1JQqA6amba+20TUFMlCFCAi2FYF/34gclU+ijk UsKFU10TPfSn1Gqq2B6VeU13RrdjJXBPKKU6zIqCHnaky8/yyvf7YbQKXbTCJQSHMbH/FVavtprp PWJlxFUi6bZ2kTQj9M8DGkcLkC/5vWUxe46CqZHuXydfbJDW7m5lkLqO8H9fOqLt74JkFPip3jQ/ pFJNuPK0DtztH9ziJojg1LGiF5H4MbD7Ep9maykcwoqcJEdT5J22so1zPl8FiX9YBc7LNW6xEZL5 uq9lpXK8IR7ONQK0o1LErakrcPVO1Mr8wBj4FsEAjc/Vpc1LogXbOXHHi4mOb6iOjs72rgvPEscF xlHHUYoV9ESyc4drBG6r9meLxwFzz+Ef1PNtGqZ0HAFEQHrVk+dHpG9g7VrpN23PX8Y448daNzZe 7rpXjZMHMu9s/PEmM3kTk6J/GkIX+LFLCpFSflU3cAVg0StPvlUtNbg2/H5VwaosIJFLgrcO+bvQ jdMUz2Y54EI2Ww+KNTuPonU/ODH4liX2wTfuqXSFU31ftyLUCQELjWHzVg2tN8ZaI+y0zWT933dw d4almlc6k/SmWosAjoy1X99wisIlzzuCx8wEuYvJTJzBWdSu2x3eEt6HJGeVhlfGzIMCkj8MmgpM ITigpNP74slJrBC48Iq4IMyP1jIjXRpf0kUGoVd4JwwTIeRBq2jGF45qIZ8Lp9bciwLJHSbqKyUV DC/oNynOre/iIObkdANK5UhJ380OB7JCNFDa5xGasdLbvuxn/mPYd3Dd/BFNdH3mMJTD19wfbc+p 9TXxKBLkBrTOT7XGnwcsxdAzb5sMVmQki/slsgpQHAocS5sLhHoJVHdw3+fPKBFb1R0CPvHgqn+C mOnxQzWlyKyMU16gFoUWbFg4+ZHy5LRCI7VxiIbU5xV223TBLtE0Zok2ypbCQfADclWDQWyciHyF kHCR+cV/RnnBYivxHPtM93UgQholsSlNGoGmI88sGM6dWTo0fT+3dldLHrGOnLtG1x8VPTPj4dPq fZh3GyMmAZU+BOO/q/kieVTe3homgiNW4qh4yZLDLa3dnJt7sdPI9wsJcjLXRaS1lupVWo9JGTSO FEBvdSxPA0suEfbDvoG8GVyr8EREEqnHthVh7laS3XLmsJcsLDBMU+W5Jjn80MYoUH8aYnLxXOcX GtadY9fTQckz8382k9tW6Apybf7JRi7bU8Miu9Mx41v6Xu3fLh42x84Q17PEBuPupGtxEMDTyB0A /Ebr1EcIcjFD1XwdMY2IsYxrDRgKg1VmRIdbWQcmx9pVRx25mD+Z3THmCSTI0c7kJ62l9AySBpqy o9cKovlHE4SnGlAj4GkGgIPsOFt642FUBlmAb0bMZNOTqNp2c5D10X8qPkh+0aJZS6pwrji0CEEX MfO31aEv2hNjuM1AUlvqeYlgO47YrV/y14nLJhPeS060zO8rUPHJQ1VkGKTu8V+ubp2UcWfThm1B ZyIM9axTZej5hIp9zWspG8EGWKCwit+lq2vK6AWt6tv153xSQFyb8So5OOGyYvqC8Dj+xUVm40pG IrNt8QvH1CMdw6rtpKwAbpz2DWV/QO8pfWwQUHDQnNtPWp0sHW9R0yJNWEY0U/JR9Rt3rQAJQPa/ AILT0/OR2tY1FpHgzRKPwoiMxPL7GANNb7OFJh8JXme/QoP4LTV7Rw8vdOkxAkkZzw5h1ScMNILB l8z+lnkZluwLlgG8p0KYRzL8uPkJ5xk1djrqnshlQSvHonktevGdeREaO9jECLtFsMrSQxox2Glc zxnBvljw6npBsDSmEOOV7kx98R4pzZEWCD58u+lRKPssiqYY0MEl1mgcumuN7y7JjnohGiIMF3AX /uqpPC+oNRPfF6htk/h2Adlo0BAiFUC7OtH1Z7Sy5o1mEAhZc5HqBo0AYG/ROW9P+wtnf7+mfQl9 x94yEnX+VsL8c4FX0bXHNKXNQ4fKYYJShk4yOVuQXcQnA8II4m+Vg91qT8p60VhfRuA9R42X1soG Uj03gcZHZsmkVn0VyMiZAlxJ+GMGP7cW7Hiq8ua81mXRSfkdTUYhBBCHbnRjvy7gEPhzBA3txb/Y QP4fgzRxDWKG3WacCKVCr5Q0+j7X7e/etqkTiVgn/EZdMveKKd2mG0G/4gnGWtm7+339zzH+V2fa ue21sDbQN+0V2inlK9L/n1RmKdeiWAQqoc91q0AeWbcckW8t8IKzYSHwWb1AfiGFoPpwPP3JAWJv 7Lf3gGU8H3rECq6GJAbXldlHjZz5+7+Er6eegIkLsr6Akd0QgK418O7CUbEUOSzB69wGPmITllCr 07/kjUA1+MPEN3oiPizEFfAi06x6idVZdEdVdyVzyDxegq1ZAV6ECz/6WPoWk+CTr+PgUN+2EuYL Zs+CuEq3BfEFHQg5d3m+mGXvp+M07mW4NxjItkFtEiVwy4U7GxwE8gS6OXEVEHDFan4lQG0n4Zqp zZFXQj5lSWOGw37XbGKNBnzmPheaBRCWH5vhAJtvqF7WpH6a3STkzaXhmSje5lD0hyW750/ly7yy E0SuVAYx3nJaR175PNRQrQ/RRthyKhfv4iRz2Xpzs2UuR+SFUCrD9cTh+F5Bq4EVUNFpWK6I+mQT IAIpbox2BURsWlZPYmrRdttUycpT+Hw8nzdpaJIl67/KoqXh5DQin2theeU8E58yks09qVBwTAye BdJJgm0F2t87UJBvFiSafG97KGAU/b5Co6zbpqWI+fhB8rLL68H2QiP3NcWsgbzwbc0hOqWKBNoQ dkfocC9CpXlN0qgV4x7/SJqcIELz0fgBZ5b/bvcF9Fl4mwuEJsSW4X3LfxK0tJ6w+6AjbHiBzmT2 u89Hx04ne4/yOinkVHBlA8mBQPM7jiHcxBArtFdvJ5WKumaxi5CGox0oabvvkHKN2n1ppzzB0SNr yjMLCiQl1HENDc4G24Wv/y9ikk84gc49+w25gSKPMELqhqaHRU2Fgy/bG0fRI8gpWbKJuciZ+axX 0VBQuVvOIFClSbQ5PLiLvSC68MFk+Zw06I7SIdZ1oFg+wzTQCshrXVW+9oQaU7D6IipJDtsKAc6D vgNJkbKjmFXiLbrUvRgzb1g1nFGiWvkw4A3ErvL+u/OdWu5yT8bUfJnvPCMVzeDXnRVnOhfiiK1f zp6l2c+czZba8/jobbvR9WS/qLTIxSFxiR44tszrHCZOGVJT69mYsipYw5mfNfbuZXHB61hcZG6I oKnsd0CIk51UIBFOumFxUgowpyEug35QnfFU79sIRAEQYvW0fj8ijwDrs8eNe9JoEQAIYbpitsfQ 4y/X2Lst6rFbfViEX3wDd9avSdPKt2mfG33CEoh6nkP0U3Gq7kzr5kcGemn0NXmPr6HipDqrbMiQ vsZNKHiBSmfDldZx5Yy0048j9Klvze/UjmzNV/NF8lFo/0pQv4YfSOPj7TvXS0YS8uBz7qdzNM4F K4GPfdNIBFKTEu/y+XLL+RiB3PtrknKkRfmwrsQaSU+UBewtiMWZd3TEPpqgqXepQn+UVASQ4QK3 vCHQG796euxDwASYL4DWzPZ+mJU36iNCwlJEBkUXi/T4/Fqiw32gT49FB5cKUukCqnmDlPoUd64N be7P+NgcZq/rC2ZI1HFmhMRP25s9bMj2OeiOPeUCUxl5N8LMm9ZnMachxOHURUXtQ9VC129RIfNE 6IFqm3RjV+35lhfKUdQWUgl8vVtpSjWW8UDXnpmFkj7qk/hSReY4Da6ClpggDMDUnAb3AJeJ/KpE 0VPiu5U7q0+8Cngv1JCLIi53Jip2VBuyWRrsw/a8hsDrV531oAOXkAApQAkV8aGD58lvk5AUZPoL nADR4QBl2qlaNnYW1X5vEuuO1NiEGAjKcb7uSxanI2PI6PQzbcMNwgHj1fL5O3abs+P5pAbiHZQo LPAX6fOIIelVm/YpwQmxQOQZXZFxsy4Pb7e3SlHKFWSgKdtKDpSTYodDGYz4rAnxtG49to4kRbBV QyIKhmXEOB2MMl4M8VcBgzFhvADgedn1azHmsLgI0NHCI3g9IUsgbxZyrqM0YdUz34ymqvznmyXG 3v7pteUMyI/kAt6CdPRROlh8pTmjnFIxJVmGkJ/2RfTFUGILjKsy23tN9FakSAdkFGCv+t4GEcY0 qbiv0HPMdJQLNYxOrXCR4RWEYX6T8GQkNL6SZH9WS8du6F5D6WyP6ndFp3FaR3DniULvAxY2G2gM dCG08JQK5GPQjMDEPjgoozr0FUVafMib280MqARAyn+Z1vLu1KYR4SU+8LVJ/feeHmjtlnz1obC1 Db+ZTsiJaa2TgyG2gRiq4a3XGItSqiQx8ckxERqyelBbS8W+r2UxgsQaQWpANe69L1vTm/dU4lNW 8uuSbyqFmtHjvKBTXhcYHyiL6xRoOgSINtvUCQjOYjQMnAFFS63cMJszNo4iCN0swBxT+bLUWc54 o+bcF4eII8azucruH/A44ZjFqxZ43XlM6vLM2vWOnY77J9uldJc+xvlxFm7eAND789xPPReU7M7K lXvgw2jQ+1FxCsRMWQ2nGelHEemH5xs4X7qMyiiHbgqP2LbsQp0q1ah+hQyp2eVGME916EOaay8z kRAhF6MrVJIdUxKe4ihgd1UYWoTPDeFV7dSGmz/jXqi4rVVFKZIxUDYWfaQnLcFmJaMesata7HpB 25abguLrmFAL5JzeTes1FeSafld4Af80EtzwNdhU5l+1QXtqPmqt56rJj1wlj6BJZ/nUZfHqR76p Oo9A0lIK7IHyhGhM9fj9ZFhcogHR0shmJuwuyEIkWcHQdktMI08By0V6li2Xq6fhWJy17Y+2reV9 4daO0kjjNjoXaQuUSwXdjy1tCET8djBdSe+Ixi41bYqoGZ26s2KJCOyh256ov21MHk/YGF8Lwbop oDoAzUEaN9R10evrKa+nXzpt3TcxcyEi2VreJC5YQeXFcu8t6MpjemoeEmynS3T6MjhL1zBA0Hui JREVEKQTWODOf+eKOqATnhcfhJ8lSllywF9CvOp+1u2HxUBKKhWL1W53nRxeC+H12LLL8cAur+T/ oCe6QTq5/gm7PQusCjSVBN+T5ZCt4kH2sMdOxSiUnXnTJabQWI0rX5saASKy35h/rxhfb0QH/fFz vWF7bVelVs0QBbL/clZ+xBN6BLVMTeQ77TZ+B9d9jdpUhNsJN/GtYp0gIsqOwqX3YuQ44F7ruuDQ 500cO0KtbRpH8L6eKKA3tACmRxqEe//VRKPkOx8htafKnO70FS0eyr6wuChQNSwSz6BUN70BIRq/ HsFuefE9L2rR6Tyi4CkU6rpnkF6N1UVKQSwTVGDQyi4vC+b6Dxu9/zrISxGVDU1gOkY/44gv2FY6 fD834vCDLOoF8RjmqowsoQgQ6KEnEyxvZfdgvDoFmoUxumssDwU2pt1t4zQkpcpfhbGiu+0V3i9L /1V8B/3cE+nQJqNPbu6YW7qOPcvqP1k2YNC+Aso60BHzO1RmG6JuuiUp6kVxP4EUpY4iJS0L1XMu Ee6IksNyHV0NchnY+CyOXMRziYLcUNoTECb9C/S7LY25X0Lo+Qtu8Eh5q3pQa0aZGA17zm/TXOKI kAKlY68Q2tUxxFAOPtjFpoTpFhua2VUQXW605eIIEDN7jM2Ao+9H7fsM4ZyqAJTYxBsevXpMDgeL SLjdfdtZ9eEEiWE/2ruzK+b5QPelz9ONr6A7XZzsAjGnpeROf1QMNoZejsw+2zF2CnmahlisXgCH vwSiTByYz/e/NWwa/YtZYMM8y9VrTX4WvNQXs89cxZjzy0i7CtW2fgHplNjm1bphKpLfr5iWe7WN rF6R8TvbVGT3LRXs0PkFV45sD+sAMxxbSIf9SrRAKJbKfVcwRXhhgzn14SPpVAwMr04lcigNXzH0 //u1QNW66I9tS8CneN656z3WnH5KAIoVAVBydBzURdnJFcy1nW1C7AIZ05Ik9g0IerfR6WJkmHq7 2LDUGHil9BaGUsLEwPnRIMPIrUZ4LDHFdFzaqEFk2WULPRLLm6OoGslz4wMXg1yc/MS4aHbctsJg m0VbKeY50TK5lTqoKAAHfc3NKhwyEpR8FbeEFGXAMBTUJukg/8KFKzAQHJZRR2qFndaHwYlEa45p 8SWL5x01FgP4/LWwhgIkxauCwchpfspYt59lCkzx1Ar86WwevwAaFPI9NIEjCIXitMelX3T+syYa OrUHbVQ1swTWrfiaX6/bEA3ly6RMl+isYSFqsEycwOWJjdpLzyvcqRLsiJBMNi0UTZcC+J/7/Xu6 UnxC0GCMlnuMjoWDhmKkhu3xhDMct6huikZIXpQqUohaS5cBqgPk7Nz3LyvjxxSTn5sCHboW4WAK wvusl2KjbO2tJDeXCr8SNnHPqvfV8dmaY0zYXPg3iCUAFNGPjtsSUnF8bqftaXq8ze7De9Yw5HIb 356GcNxWF4krQeu4GQt8icFKchqj4E100QUml4uDpurR/7EKt1Y3Jmgg4+DZs+8PFZCuj+UfRXpX VJBe+mHHVmVKQb2SHRq/60sGlPYCJRHfkpDXEzp1i1hDMasz6ViJWoRNU7rbHEot9CyP8/f2FOkY I2V1ZuPfidAOT8S9B1RtxwauyR/WnoX/TDJnhmIhk/ujvh4Hst2cvTEWrEYM2ah5UObNi7yySB39 Y0cVe/dwfB1JAQe0CSsdZxzvjF5SU5DNj3MV3d08d64sARqoIxeQy1jhs354P+yjw+DDvM9Jrfr5 LZGv+Qh3qPLf3zwABYYLtktiOipkWxiOzGtox9ZMRd53ovXtvO3HrRd81BQVuvhj5nn3zoNqjfbU YWoAMWAyhD6+3tligpdn9lirMdlvJNfwutqh9zqJre37yKRJ1N8+qT4MVsUFFWUB3pZAiaQ1TWn5 0G7cfLTnTKgJhS0089+R+K9GTJbbWSxyBoLw9Q6Os2l3kjjuH26cDFC3YCRtU+Sf/2LFWDpp5xps JFNr5Ft+MYBRFVnvTR3JIRaKwkAtzLp/V9cnk7lfqfCucNlfj8YUq5x8YCcVyANvWGJTO9DWWEY4 ythIXA0u+jt0FC/8DtWbFBKQXJ3BEoZHOrIeXHZ5ppapSrTyweerNoHj3ZGJRs1VDhGDrQXv/g7/ QVBFb4s7I6vG3MG30Fn3SoUy7kgBRd+5nbwxT1/SmBEuxcDQFMfZyrMahdXCLQw6sH21ZZKTwjho QwhZIr7jS7IlXIggb0pQgRpUd74SlocKtmxqW6bMvgF5VXtA7Lt9aJVHCb5nQwcavymqkBptvDzv 2k0vxkAN8qyEbM7AWXXv8XUUraFrxOLNClm5eLoCihlUBCepnpCURAfFSGEpMbT5cAOa6CYfgEkS Pr4K/fk02vBOvPuy3WHihzcnHEstQhcy1kK4/vKqyt3utDvgCV9GOpOoDfpv898jrPpKHZxyp9tK 1DhY34CK34KQCFpSfGE/6NIi8U1ChtDoqJRMdnK22WZeXHRXkUHDHpqPRugOwpA8er621MG333Bi +KFmNbHT7qAHlS+FKkNwVSZi+lhRG0Y57jkcPsAFzvl+OhH4jXMM/9JWkqAazUC7Pe/6v6WFZtUS IXxgsDXq0K49XAT4NEJZy2wON89yvOBVmC2xlsr6NmIwY4sTSZfclkMElAYwWPxRwP3kscTAyVaw WYJaaiih+kUa9bSHBHdC+018aaQPvuu92VyFpL59BTWeQpbUCdtsPOhpTpRWHbVCFbQzd1P9dhcl kxA7yrwZXwd6vXYFsqyKlk4/3YUlgRztrJcs/A6uDnrmR8Ojirafh3oDC2t9b+NHjyRKEYOteNQt Fj3V/mIb1vuGYsEy63Dm3EhUEJprNzB6OSOuhY+7cA7IVv+kAS7KY2R4XvWYpondJCJcCxKb+NA6 PElA0ZXn/kp7p7vXPCumxGuFu0yPPWGa2h79wbV9Ih3fTsRGr2gt+91pHXi4aqkITpeEjCDXPlOz xvhOVDV8eHsxas1IMnMkVby6l2TSHfl5Dya8ZebZ6G3NUUkssJSz/pX3wfklLTrNdljbqu8dBu3q NUTkZ0y74higOOdrcP3xOBvXFvzqSyZJ1mRoJWPsOXpUiuSA+ixbil0AGapX3y1fo4WSnGRQKn7H ILEFn5RXIDeWAN2/BHjbN3sOM0WBWSMAWITGGdHxhxV1GO61WWt3ziEUvp4Xks0V4bwMuauViMe0 lbU++nX/msvzt/l4mMcFDPsU9QxqQV3KodXHLTFSQEf1IILiFuzxTElC77NB48HFq9YDTJYlDLD4 VLYUePZSVP+8A39cKX3HlCb2VCt0voa6cSlsZlFd9o8JGImyZHUe6OzfgPZkIRiEnJSjNJ+W/atW iP/62iiVqQymPVhDJyTaxw6g4hf1Nfx3/ttlqAjochgYVXF+63VUoE0N8yfD8In6cE7TUaowz1GN mcH4HSUckLUxMoGRaL6BsYNn2ixObl/OidE+nDlMuYVojzAxvdNHCUAfnwqn1b55YCOcAeqrZA3o K+hnNWwnrrfolRI6h0isqnDXVO/41FCCKvRhP9Vk8zKg2Zv3YTEHhGrwVrsDM5e2w717L+y3Ce+N JUZuS1vw+KEC24keP017FMChznt1UA7twl5u3M4hXcxGI+WpXaY6JCzlHb7BzK/LDVjqnK3zHBKB 8Zh59SvLA1NK67xCmJEigQJPSiTtYoW/DEC7dhq/bLGMNa/LcLu1xVXU3MSZRyzcUEChRaNbPAAD 2/c4qOgt71/Hvdu8tn5JwFXA0Uc1NqWTgbVgSRUI8hXSYSJXSTx0fP30T7D1eITeUcWiOulSn4U8 BJJREDBmX182J5aPDoQtUYTtbrJXlUsGzwL/qvicKX+5+lvQdzAmIPIxWX0dcFVv/U2UVfDvaImH TybevSqrrEZGEgcmWVMtltcy1HbvUH7LCwje6UOkPcJSu6uH6r7XnzcWKqpfTPHb5YaGM6umB/Zn hCdu6mcS3Vxs7WB479e063xL/+yJ3UnUVMbodE3X7WyFvjmlmdOlxEoapDu+lmBYWyQc8wPevJLO 8joG/k34nd/gKPzQb9YR+A+M6GcnPHw3mSGwHfQQZXU9lk9D9ppFuu/yyr4Ue5sruRx0qaCwWw7j kD3jiNC4LvK9bq5QqRjj9vRKpJ1vlTwBeurzBO7awqEpySTIq/BDZWrAKYlsASbb2oOrYFDK0SG2 pR8N35mXtVsCHr+B3Uqwx/tFG5gOzorXRdqLKMumrmDDbd0YZK7e7jm2Bpiha/TiR6eJGcY5Pwj0 i+M3v7tjKkvoRTK5efgNESytbOqDVgAguciCoOw9T8Z8tS6amcVZPnHFke9XvWMDroF7zIax1bhd SqEByxYAaJEOogoNtb96zeTRjZGdvggNpUD2q+hsDmObB5fKb8gF7QRgw0x93n5AcuDmlWCJOgAP T7VWxgM5knAHm2EAbiHHLFyyd6iKkKN5PgqvlwvWGy3mn0wOnSQgYgAg4AStPZUwxMVDglWXWRGw bsYBHpQ16NTiPRhAJEjLrhVox4LJOxIp81nJ6AufOCYvw6Wl1oFhzB820258JC1BxjTr6Up8RCTw wkkMTRJWSP0MzQj1JmkE1hi9icgtKNONILIHURZ9t2wU8nDhY2gkBDlkTIvhx0Gi389DNC2V30ft kv/hf5/NI9FFZqNNgH0lkav3L9BkpukoQQJCSCKPhoLoUg7FdDMsl6LxQ88kcjMufsPeidYg1KSa vQRPWBQuhtc0LpQzXbgHEOb3/djefzjQqGITrwopWPm71CR9EdaOs0IObv3NgICSwf2ZaPdh1b+w 7CJUxCel4V7XiW7oyHqIItRKeOVKfx4Wvp6I4daPNM6eZqrssCu8dXLG+qbGTTkHBAHC8VFV8vP+ xYHVqktiF2ckhVQfGpUp49R6r7gKc6sCeLzf5Jjbf44ZzTW/Kb6wotBhQENcndqcBygpJurAFwXG iu3xzY86zhghUpOHY5L9aZ81YDGa+FzEQaUk6gwDHheEfcQgPUtmw2pqrHZXMrr97ZjDGSXnc3XQ wAMd/RBE83GLGBpSKlmdRghoqpIUF81BojcrDEsOjnj+3hQaRC6E1xfe+J1vzJ/z9OyQURqGDDp+ h0/8bR4aBd4WmaI6wBxWe4zizNuOMlWevy9MDNYSexnSAxnHhXOw/Ygfm2gcA7G7e2/7EJc2T9Wk Ijsr/kyU1FacAdo9p8kbAgnEV4GdRbL0bo6rWUXAFpNOLOaPHyX6ojKoDVMqc02/kpn0rbEdIW9w K143C1alFAEeEcfLus5PpGsY1JB7EMcVFRRcukTR+JJ3GC5j8MBV8pGrKMHwZPknvGxEeUy3XrBd WPV3utSilS3W+fs8Bj3a+CF/o889m26VFJ3mdGcMZQVoQw61yCzA5iOrgLpvk4AZvxO3chIpq5zQ i+HF2Z7Gub1ode8ZkSsqPDFKYM2AK01gRAUbNOJ0/Vh62CItEk1ost7bNDD8giBZTL70wDmHOFuU jYeZ4TycOpUekVAwqE/VTxl4bBkP4svzKwTbTHmaPrzhSUC13/NWj8DFQg/3m/A/2VSXV+mGIlzi 2xQiEsXX0WAjL/C0+uJjxF5CrzBQ8tJ8zaPYWnqiz29BfxBG3QylhZJuP7qwO4v4/mO2WGFfjUjD s+oXJVcv/gnHPRW9d3K4Da3bNstN+gO2lftjTgZJelJ2hAgVpn3H3i6dgB5L+IrOAyfetTLDNqke ukq02mlHac3inMbH6QnFbO402hq1TQZMr+Jtt0F6Z6RJWX0nQ9K55Ic7j70gisWBC4/Mwm8uV6T6 TLoeuADMz+ybO+IPElPuGI/AkjdXutdZaQELHfmjry3P2JGo8JJypwoJEJjFNZ3Z2ejl6aZkyoz8 XrHQH7dPBuOvbEc4Y2TYEagb7a9ItnQwI7W7LgWRieXmLCeygJWQqGkeN0C4aUa5A1Vz5pQS+2DO BTb95q5woX0Ha2is27wHEkTaLlrTPOUoVzcwVoTW+EjOdm+EagfuUuV47T4kiOJzCrR3dkm+9+Lw OxsU/OU6FWgZEqmp7cqJ85KWFLEZNsSjWeV/9KBrdmNeFL0yC9VfAbTiUroVzEFacjHJ+LFN7uoC VV0lJYbYPK/5DH/UOB+IYPLp0aNW1OHhMo+4IimT0/w+gv79Xtdq4GAmgXDU/rf/uYdsXZui5bKj fvIy4Dp4OHkuTYoSzzGRSxPRNrFKQhpeYs2eml815/g0p5pFAdaEy/TBcYHyHyuSV3dWkuQ3uvZ7 jmfBUPX2sRaCrJQfzK9VewI19S8qXp+gLHbimYD1uYDoeD7xQ0DvbZAgPXa4FmB2G7hMc6+EBzGD k5+pNr5o1A4jXYfhUQ44Chp/9qYTj5v6Xr01JWy9bIC1v+nEGZKSutz0+hyA92q+4o+qUvKxwcBp a5ruRcQDzRFihi7zK8qIujTfAJxmiK0mIkuI+pnrwMBATezP9vjSogoAx9/WYu2fmAzlMbya1mcS Na/H2ECKLWLL+zVT8IIpzNKvGJAItLO1yOr4yf2VkK0WvWBGErbo8/NIKIAEmt5HBEJ54fyAuQu7 35hDYDXUJrXcwKI4e8Vq/u7vvr0XwX0e5wEj42xQiAihvntE34B0cpl2sm1vhhgEkBWS3f+sAoZF YGa71aW3PBJEZDo35AwNuJkZsioWVVx3Re556iLy5LdojeRU1hKf4AgB1/2Op/Vh8aUZxPxo6TQM 77EYxOElcbIm9K+V7ghdL9imoOIwUCkdkr0GwAXBaqaez/lOoyai68hG5oeIRqFMY7xYWdfyFUAK 3KbAgJEOfJfzfCg7OmT9r1/jZWe9/BJSDISqb7ktYMD34LNkxdzxjUF8wvHvvxF/Jgl0emCj4luK E68pncKRGWMZvfzRRGkxyQ7TcVndqdhfWmXxUFdADO559arIpRGOsrH4/0k2I95H2JzbifQ0wfvi GF7dDOlZ2kNuK4p/Jx6s48prLNs/q9lnbmJeL27cy1B0zs+8NcGP/PdXs7LfhNjsudioMtrJ/FcN VZlYFZQ0ToakbsoLb5XWdlwZk3/9Y6vOe0ouwEz9HuKaKZBxDOZLU8KOMWivE0fxXY4/reMeLRfQ jfeG/Nh0x2HBmK8LObMvBgAjR0cSSV0biYOfNR3uaMPtQ4BNsT5fh2txI17fkcDxNL7fhXxiroBl ARlCeAtaa29y3+sAAoNTcaIR1qIFLGZBpznNI1frD4dTjoPDeEnBFE6vviE+LnOO4szVHGG42AeS n6b/hh1huyssNwTJs9WVq7ZQBWrml4P5D0yjw1tHNPtpS/dqUgEXQ78Jjuxo9s4vLuWyHCMtg3cF qAJLVl5wpna0k2nbwk7DuxOhhWzqKRF28l2b7ZmrbI7NUUTQez5lAwRgb453581l3JJvkQO/+W3I sg87wFyx/eBJY2V/d5f5DNMlWz+BhQ4mpsEIxu1JNFRsnPamD0gF9EPab4e8B2i/YGUiELcnr/4S E+Nyz7vWSbUdgeJCTTmn995pox77s3/K/OADiWw4ON1FQGJUzRwyenz2dQiphZQA9o4bMXPKR/Kz SqDWJovIz0Hc1gT8mBX2zU+KJ2BWC+4bePrQ/X5U5FwhbCRlGD3FpMrWfd9u4UZs5wfjFBQTE9XU QOzUbaKRbJ9BOmdgnD7aQJ2IB+P2VqxG4I6qkisPFWm2RViCwbD64xDP3xWHg+l8quI+GHL7mfOv KoMnPeCE4fizyi/WFN5yQ2n6D0EEsG6vodclUMhNgTBIyeJAPSsofZZzG7py3anbPnSQH/1MuvxX oN/Tps/obTYHBkdLjlCv0p1HU2m2Yj0Y2XX0PXlBAePi7z6ElW/p2A3Vw6dVH9q59IOZXosOWYEJ fpwVrxql1CNNi1UHY556ZU2tvNO1JeztBWB+RM5z92y/m8DV5EoXqP5ic5ENEp1OpQKgQ/wA781R ZG00yBh5K9DIJMZgGrQ8ihlO0CFRMLE1KNCkrHDpB92b1Actl/ofO3Q3Xu1ie8RdWAXl2CSudr52 +thGNIwIAanL4CbmrccDfRJV0rW9QscZZ8W6C2B5xX5dARC8HvHK7JXX5FCPOqYoayOauDTz04re mc3dIGnrMsow0o7a3raZqVMJHJmC77VeuyUZ3ex2K6SyZN5Jd0lvLyCFQ4kJUI2JfaLVH2g/OiKj 2MZcevqWL3fH0q4nIzc5Ohz8P6WMRmhAowM7N2LvvUjRADeyZr5iVMMJyMQTfY/n914cnZxUfYUf zzRou+pvXl4wEUKT4d1bQAyObNhcJwJS6YRloJ6MpPJQdEirKTkqOIRPD1XJhIlRGLn1iNHfEujA wQUQzRO/2VCZAjj89lR8o6sXgYaF7NWs3iLqE3Iah+h0Q1cfSNL8oaax0BJbj5AfagQgFPoZQ8Ar QSwG+BeqHjcpFLT38M1P2SEIXg6tJ18+ZF6AsaD63AdxnTCSAYTqCWEZv5XqHDBxoWP9H944e+D6 oe1s86zIF8YDXsRZ2vtCGIh/aLLT0ybp2Atc/dI6puxylk0T85j1bbnpc2NRzV3zBvmMIe+G13wr 9OaAvg5WvSQNMP3xDkGd2UHvs5PMMHDSzVoEwbee/vXagMhfMBIYTmCVp2GCWtRSScBf2/relUO7 jhCT2yzIoY7ornSrM8NWCSNjcHCSqj4AMFkVrL/MyDGFOI5SOybmlv2h/JHMVOs7lEo1wnLgtjDw eplZPhk9FGGHXeXSgKiVrAXuHxYF8TfJ5dfY2vNN5ABK4eU44tVVTOOZsTGfAtJIMzv6wy8voyRT rOu24xWF/Z1mMGFHoCt4XFu2t46TgypErJSOTRdtMRPuolWzoAx4m81df9zfBjp2ezMBQQ4D0iMf +nAFscHL2mjMoZ9TVs9pFbk7390ZyiRuI3mP27Y1spvasNjJb1xKVUdCnTQj7kZKzwaUApPgqWdd TumYse8SCfCdLgfZwUhKe0z8/9ZHdZDcuLRwVHvoP/Kcb/AdczISmRsLqDAVsxhUOhUD8TdJ83Hc 113cbgnMS7JgZx/LBd5y5MDXi7vcui7o1qAPbZ1ZAgIwRpsY/owsjMZvSoOO72wMXPaRk3pyK3Pp b8W3NmkU+AgpZ77LJkU/DOlZmhA5clF0cu1PrEKnvQEfEz3pkTYY92BrP1RDF+gdLFBbyBDfjhM7 JK7iDbBdtNNpfZb+XcO9cbuDJgF9zNOdLzreatufEbtS9MZA0BLb3iV/vgGycLxfPtqMQ9eAsK2k 399rKzwua5nAsnL/xKYWqhXEFgbeM2A5xcsgbKUo6yv3OmQHYgZ6H8uoX8lMwQL07d/ggGWJciEu /5fmmd0b1JQ8NSLfXlurQHx7A7v7dg/p1cWoSVTMTXScEaDGgpYCFsY5RZl/Qp6N475PeWQwYXfF kQQehgpvGo9ANd0LPEzQVfoIqShVKbrBu5poX2DNbuoO/38QLYA0w0onrtTeFsg9fl7RVtbjfYH7 73HLjgbcTq+u7ZY4qEQ9MX4lyCPIKuuSaLn/v7qHHBDajp2+BDUbkCYmMW/iWCC9Hbtbu4Z0FUmt /2UWsvufc/DOmn+mMa+QTPGz2yks+Lz6nRntpLSGTBBbbh6lkTEwvVvtr98PwG2KTaRyvq8AArUr lsGjfLjTbLTaOKJLTzFu/9cKllOzaslWBb19iMNAdpjG37qkY8ZEilvMo6b5tgudZETzSmn/8KZi mzREyxeq5u/yIaoJjj3UwS3bVKXLTnyXUO+N3Lv98rIn+QYn9bcKuVA0zfWPKzP5tqNQBZQqLipY b9TSxrnQa6Wb+RUqtjmIsucGqnM4Azt9cYihgmMtdHZdsIJDWidLseT16xOINXj6oP3oO3NGDfHc XxKjzFNx194wwoA+siXnuEButC4s3ip8e/1D/htZjujGkdWL3gSDKHK+uM/7n/k713Y/hiurS+CB Njdu6snkGE7RxLYHfGgCxIsKkzzyGRYSJ2mKUb3fqjef7sIchC8xVA5kJHdUb6q4b9pdSbFOFLZk dJXPUPquG0VlHEjOSKjdg0m8pB+tGHwRrZ1TGZ7I9N6qKp0FFetNQqKyYF4pvWJ530N980zVoPOm d4NfOQ9Df6LPtaJHale2VKI3O+BtM4+WDntQaWHDIE+PLTKXUbYxKOrZAH2eiMbyJtgFeQLzVqiR a18iwv2vaP4YUNDwjE71HvtQEe6Dua2Loc9XUqlT3PEX35xHwGq6mRrgjycsEN2EjWUQG5IRZouT UsuITP5VkJnA3/za3+ga27Nrl2LoWL3ejvL4At4+TUiEzKcRE7rWdoJIBiPlb4RHVKp3st8vob64 wLCOym5yjbmngXvq84QFmnQqj1SvuanupAlGgUyyJbF3LQOOP2BAz0Q+gu1uHKE/4S16bm6zJ3qY b6pKhpn29Dj8u3WIehgkc4oU8o3cDC4WXHrfOkzrKmH6B3W4HBrfkSgwk8NpAZ5Ofa7GAvfy73os aVj3l+ons/U6cFx2TOr62t3s0kFpRln9sfpZwUvkYGVSM+U4LTLKG/WijnVqT1f0IIFv6V9uloCe /MrkWLO/CtE91XxcskWx7vyeSGa/2J+exXaxA+Ih0u2me6DWWWOFV83GSo77e+pzL7nNhbKyQS45 0EnF5cVS+lkx1Z4wCrw4Sbx2hBNeAqzKA1ticOSCov2LX4JhzvkX2nDAbCVNf+TH/pz4d62xJQs5 PBIYqSXl4L6qTY+RqppXHvcNyP5LNeFdxlLEj+tk+W2YjLBT5dFLpPMEEjHvzid67rCPJW3Mo+XS EqfXGINm4tVxYGhHz5qDCMZ3fxkxN0KLJet2PnDpfWUrAibmVLrzLE2S3WuNlMxmPOsfiSEgB9JS e310FExwDEU3UMqUUvXFbbWpyuPnH+foMv0PC9a2EgqM661WqUShh4MDfrBCW8hOYd8w3WTAy3+z FXhp7nf2NA2dbavafHleEHCtwZ4/ua3uYiF9k8O6191xpqtOWHxAA1foWO81Ipi/y2aeEG1/fOvs WqOLuBWIYBdiyjqElmYtqzgwb3Z8q6S6IHHlP9NnexQ9/VKog0asIXdIOq0aeN4MW5EIyU245SXZ SmaCDXoOCErwD7B3UDp1G0kG4fb6ZHIm5XXulv3UJvtkoqqsA6qqAUC6PkvTEuXD44dwOD3aB3mC kWcrJ9sPwUFiEWWBC8fBY5lCWhluEh0UaSpozmniFQeyPEAcNot2ZfxcAGTHH4QRWPccdfbo0U9N SmQhIC9im02ElX1IRk67qaJx/ykvdr0kM7O7Tel1IWHj4QrYHAyOAMlnGRdTlBI3Fdt+6XzD81ab TCApF4DA2O1Y/MUdi8DSs+4+0mFNNvifGtJt3AYoWgzcullPGpcZiLzxCZt7wmiJbCfVFZLihwfo 9rs/bmOraF1Xv79DpO02zvGeh6+ttLlyxSm7iISe8Fc0mFH8htPiG1JcGkZGSzxKFoKPEmdqoBJL 7EP0x+pFoFQk4j30aWNSMoGK7fbHwwnmWr8ITJHE05uSrwYEj/nfQy4V2INPGabTFYyk2XYPPy0v nq0RQPSVtOxqBXvdHwmYeDbd7GWChV/+E5g+H5QcaNmghfoCoiySqg6jTKVGmv95wQGtaRKT4sHq CLCowzF7vnnMSdg3KJZowVn9s9Z9IYQ2ZhgHrQyASyTisk85VUXmM08nXfRYuBo3rSxBJNcdKA7T z3JV+bNuWE1GBJ9S9StythLusvZxUesvFLmCu7uXQLbJKELWI8TIoVVnSLD5hiPnPvFKhfKvIOrt kkBWi4SZJCv69VhYNUu/5BrA/af80l6H9zP6jDqwelwZmlIrYXR6+vCK1t2MX6W3eohMnPI2sJAu iMrBiAu6ULbVF+DPQvda+1bTObtV/Jqfd4+Yc+SQAGT8UBmZ93bBouU3+QQIgyideGatT3DNyP0u Dzc7jubhipgJU4/7GWgeTMVbGx9Xic7yYEDSHf0QtQZ6uf0u81vCfG2KMq2KLRQA32+T2y7tA1zG ggWxXNbXrFVP3oG8MkMHmfsMWbejCVXdvJrKHg0Cyin1UzUvYtTkAOzqpd3mWNFHYTiaPQNq1KTI iB48LFahzKqIAN2l1YcSGAktyaElHULNcty23leiHrgJ00ZZ11AasS0A0C6DAEREtGRc55WM39TX hXKTAIJWOuLC+DPrJSOgfsb0IuN2hq1zf86SvEslhbJ8ePs0xXA4eiKKjcLUmye6lhrImveOJ5Oc z7/ep//SbhJrS6cujAMd7ULneYV6/fs+LV+L1Sq9d9UFEE1qo4CDiqj5ODXb9B+OM/wDbh/QrJyD 9IHkX+UIxQwV+QrcKj+/heuHnZG8nEGsA4jZsAKKJ2lrr7YOfit8yAGm7x7By4/b4yJH+XAlKURV tnpTVpklqjNV05JX5t7ng2IkgLNVBH6Wzaz88h51fLV5kPEcJc12f6dnjI37EjfmonSrrKCBGsO2 4uzyty+KhlMmnnr7FB8GrFvU1+882EunBWdhfnKPdu2Cgej0SlYCXAyJjiLzCci5sIBVCEwKPYKb vmTo1vls8/HT/zoexozrduQCqQBc/GM7LkyllQI8BGyI111+26cuFp7wciBSPmQoZ0HZCJ4R8nyQ jrH5tdcOETVj2p0xvRpiKxqiX9qRgEXBCebUGvqesHSwgJuhMvx/6/F3LXMCVBTWKk1cpeyiEr7k 4O35Q/+XaLu5oVb/hQtUiBl2sYM5S3WCiLVg6CKC/8k0/dxkJY4efENpOFiD7sCvXRdtL+p10+vK HxLKz2QwhJb6OHbYmpRSFrUmtXqZu5zp/zOfn5w5lJIC0mttNrFcHnP799ywoK19NkcAE/HIMdUs ndGuQdOJxZmCM2WLxVzvFg7aT4+CV8fxBfpIEb0rLKZNGZonaMN4SgMlW51e46CxM+ae2qkRU9Kw Tu2oi+ZQD6r5R8d6gDaD3UtWQUB1GSP/pA+T68/JKd1+i3b9bxrhvP4klP9fLnyYuS1Dp0KXWydA a6sJ/cQejuc8LHmyxGriVJ+rYXdc/J0MvZ0WFw3ktIqBoQ0qEvjiWYdpx5ptJLC/zXArhh6jOO0D Jc8//9rQNC57EseouJh5vx+CNUNN2ePctBit6+1boBcNLPnWpOqfjh5ZzwRlE88QFB0ncMOlCsC8 TeUS/oz1KRN2ZATKmqiDSLqJ/0eUgeyGtOR4lSx8AsiJ4bZtZUm3slKeFm+kcYss0XkzE6DcSYoG efuy/YKkLjts2mvEBDa1JPLTdwi5R/GVOd62FaO5XHPS4XWSjSJ8MT1aVNNGNr4p/ZhFetkDYuWd S7NXXxdZxvL7oyFB6TcO+57M8b3TGakdpPrFAANZiJPGaRNp4nOPD40h/vef5PNlIjmxFCk9Cv4P MbrsacYGsYU4R/fzMF6yuzqlxyzy/1GIbzS0qhCBO+yYQU4V/fMlPe2k8NMXTrf/YNuXMytdtZfX Ppsu+ub/n0wY2m00aMnvgc/hCgtPXAiQGDFEkVr9yemJqkY6ijgk3ycnwf2pIsnBwQV9M0mq0Jd9 10a3i304BZCcI7x9sXuTa1le14GN5qnYrBhm0q/y30S8WrxT04DY44HDPHsUVM3VOtYzJqp0FB3q Uj5ybKgsAlIZmrUXlybhqIp3XW0sCnClEo/RO6N9cgyLtIVZAvIzapv+VKJUyokC4kvERyQwSHMN BQszRKHtPUUke4vMMN168XfUgv+MsBTdi2nJxYnDRFF7AO2lQXVy29lpW7mbi9SgBMNr2UE/b1uC ztBx+YaHbLtFAs3Dz922q0JyBxWsRfoyDywso+mUm4FqFm52n9C0wyp6iDGm1Gyh8lCz5xb6NtB8 bbOEgu3Jm0603m6t5XvIJzXomF7RKnpDtrigzwCotyBPetVldz9x+GxfgpavO26li+5KHFCmInkT 8JPMHLPkDQLxeaRQqcbh1eBBP7WYGSvRtOPYQ7Gpz+Bem2p3G+7lSp/1U8cZgqBG3w398ZSzFUJe 6vH/lhavkJ4dtZRWB8EQSeG7qxdLpBZrwM6N+e+eZEE6zVb8wdCVU5C4+U/uAeakPxfp1pAzQ1Hn AKAPVF9KOnOMg4qLNgaY+uLS8spm7dPEHYQHuKn4IveSaM3E3xJM7xgaw5KxVozcEmSYQizg/qf4 YDhIVsdXwJxKMSz9jIt+aOTT80TSuTr7b6jbSfEf6Wwmoh5COccGzhGciBkRsxpOyTT2D00p2YHg Op62XfZ6VD3ULSebundxXGaoz/SHmwtiyD14qZtEZT3hqUcmLS1nFBKZLC/DXgcLEoiIPEl0wJ/y iE3eQyUQHXu3nrUWurzhzxl/8cIOFr1NMWCfOyoqfsqr9bqD+dctdy3E/vNcOknaktuF0FGs4HWH X0KfW2k7gN3XTNiCIxtnSpsVTBqcopW7/HDSSvIreUtKOyfh+o4pixFTzZkRxYOlmFqjJ2Ojnjxs 7n1ZDf+Y5tiUzzvNzX6sYcI7pTT5HMZS4mGG7oLHmkXTMXfhFyhViKFLzurKvwQF8Lb/GX4Ysesi ztOOTEBVq9WITL/9JcxQEg8I0yKAlYpgyVArOiytGj42c/TGfk+/f7tMK30VqKLhLPp/pQitqV+F 47h6guNGkQhBLhscJDR8v0BdOu+x6KTVTkTXuFwMdq7ZucZXJsROOiGlTwSaf1U3g5BqHztrP0vH yMgCqa7BOWGkzaQSWuPodoXjNk8AjqLHvPUxbin0WjKw5WKAZLbV/5f73ujV8PKcQDR0TIf2lyRm bwPGwIQXxGJpuvqHRH6xiBCfBPpeapLAWwU2kudxaAvluYaSWIJWOmBvv7XTlfJvQLeWc5+/xyuh Z3wfTnQ6NR70KHhmwZQT3DvJzewReI6bc393CEKhGblqUOfNSv2hsINbzrZtM9OeE/ptYmOPGYrI zpEhs8CcDoA/4VAq9WNa6iO5lDMETuuMFHn5W0Jpz3irX5cnO1sZRLebji/z+o4eU6gxDMAnPG6U YToB4cseDGxRY2qamRgMxIo2L03f/Akd2l4r7IUxet0l7UWWWfteu0ZfGfSsG/eSB1AP/9qhwcgK Yj2XE/Eh4HpqwUZ8ZPEzXCdCelpPcmKaDq7EKlBJUi+NohWx3yDbNULDY5mGnXvOGKtUTi6zw50Z lh/zVOXu2PXr7zsk1njN88zJBjar+VVAkHjyapiViRU/KSQKn3WoEj4h+t7gc9uPNFbEp4XueWB7 2QzYhDOkOJyIiRRRMngbXid63MW09m9NWaX8z/AyR3mLQm0c6ekl5n/PCR3ggyXwWVz5jt49bo2a jM+mh2vuHLi5/RsGXLM7/4pyYwnhdiRWQ0Os5CaIM68jcVr6Zv19BTd3+FrhaujgGM6xS6dSS8Qx Kt0Ypi5hXWseaz0nSPu8mDwrJy4gRPbjkhxSQBnvuCIVQ29hkRw3Vx5x1zuMBj4PhQMpInmaIFbg e6bEfHErqYAShliu89pG9KHikFpVKbzRYM7ZPRySP21LoNrkM//kPpmZw9irZlS2heB6QZjY+z8G 4OMkyHxrUHXzK3LJHf3DiPnDO+UGQ9OICONIK/mzV2PS427tHYUcBPQpj1KhJ/tkyQjyVA1aSpxn BhLbIQlH7qezuYlL3so0pmbtahncY2zrxs87sOpGW9TGLq6II4/dPvfMoNdlOlYYeLokalPbE0Tn 48tIXX98CsViNjLWjPU7ux6mkQ3+tvKdU3AIZnrKIzqs/UA365sxOIqe5vFWpgBMuWtgLrLmHuuz NgivKuIf+fss2nz+M5ld5Z3zpTAySzP8bGt4f/PX6QuUK4CtP55o8vBMhguvqbPTLEKT7Qb6fZ8h ZUIIqmAhFhGZ9n/Hdp8dW+Z1JKnc5pFzHOlUu7yTcp6uJk9+cYWzMy+vweQAfO4brcJqkU+phi3A /p8EgtkvpZFUS8vRSci+K5XhLwCXMXNXp7IYr1HxMWUV8v9X9NYUJGqCmxGMkIxUoUvMZbOILBXg BnDhJb6t89ROH6oFgR0M1p9p5AOe8I4/4MUBPPoG8cAUqIIfgCFLqMIp9sPkomZbACQNoVKGrZOj 4yDDEiBeXNo9mgHQQTipxxkfuTwfvgLJoflJNRA6OdyPVRGeiH5YIVtQB/DUOzBXE/xcwG0rkKwe iFd7secyetUGmFLhd4XQ7v3Pgu7JfoRmDxmMHoWJwEX6eeSx2TuWQ1Wi2HlqhSXUAsZ4761hYWgi BusDZr3XkTY/9TYp96k/mI+yye1mcmacaYYXJ6hDNpTYqW1LoHZuAsu9wpKKZSqrYuqWD4csV5ke lUxWn+7QMG5ZcK8dRWi9heDS71Et5/MAZmZJxwS5ZnenOWSy0OeE065KO8JnRAYfd/3KKYg/Gbbl 27Gp2RLVenm+p3o0k75NFTBSuhpnOhR24RTzBix/ohckjE3TQ2viaeTAOjzr6CGJox2kJIwW/mUy JioLEc4eqWZtgm5yYxYrmIJVDvPjAkAzRjzkgAGUQtzfCgFSr9HHGTMGXQ/an+R8DtXiYfz+8tyh gex/MGb9du234+APYm7QsasI4C3DHyK3ybKq0Ogrh1HrLjxJ9sTGhL0YwHQvA9/2zeiVAYg4d22G 9Hw75r5us8/TX+YlMK2ZEFDgL8p7JDMhFROwHSVSravyS1m1vzggtFFurDonUQmpzfue8MvEmW5A 7CWh+qhxemssLKE2+KyTnZzUp4D9RnYd2hrcwXAxRlDXueLzfFbvUeyIGYuo7yZo+boteW9jGBKw 0WHzpWpVidVt28WxQUL3XJ5ZBjDPt12AtO6N+3u0sKu67ZGdBTZWawl4zAhKWDJ+WVMM4UD6y0WG DJbyGPs1dPNPwjX4aTISNaFrraGkARgL79LVA5ZMCD3eYvfungrmrbS0iuhUYppgf/u+FSGJWQeQ nOwa6NM5nldO/kDtp3pNGcNcSvDNmKmV6YS8FYnTNSgQOUFIw6S4RzLvzOsfO/lzMZjuxdqa4VPI lMJg2cEfkx25KXp3H+DU5Y9wxCAy+y4CWGYC5BA5ByAHpK3qp6Ctit2KzbyUV0NauxBm0Q573/bO 1ECghchoUlTRIaq6DQZaF1oRYt/gMCYFjTy2RXysk/cl4Rb2RvlxtwQmiQ0xR5IrIqh+OIzhOxtW 3mrxTPKtJey3j5iFpTEyb8rmx7SeGTZaNEMnqXGJqm1A6F+5HlHZI82g16Z/iyJH+n+RuGnY1oaf X/fxDgYuxn7By6aF6cUwZGiG77uI7oADQ2944Qt7NDZfz/fYsJvbWwaSuv/01j7t4EBWGIrX/aol KHUGOrgrh8KobZlXCpNRobmsvDgK6KJV91NQN6BcsY3bHzrpA4on/zpxgXh7cHWgv56Rpg2QAva2 NXME2aCVq3SyCzKVyNu8JgQUTpSIHwiZTYj3n3XQSSR/w0w6eIon+bbcsyX1KGBEPJyeQ3rhWuZs GAnb54AwJuBgT/N7+QKgjLchPpWEMVUUE/+e4biQf9BHHJHcWu+sW7Cprm2OR3NazK1eBh6lJeI8 uQAaOzABHnI+l2is+PPvdP0NWQvweSs3W/KXG5QAwKDDB0kAe7DT6xzNMdAkOmtP+P7uWWDVzv+D dca38ezJWXyh91pNsU48SE/Gzt7w36zvB3oINA6IbUUX19JDjMNyA2aAtwVysDlvlGimfu5bhBjz MOPh2n7ASgBbC4RRx5OglhFRmtzCzSjdn5u3qUI6mtGTVTNOmK4fW/XPxtPHDg0txnb9Pjt9YSQ4 2cXqdNhQPx+b6efk2gDQLK7++yyczu+yG74XeFWN2+1WamNwIBWjlxTsNiGQWwKOzFR3U4CZxf9E KILpGq3qLsgGX6696ZTXZhIoLBBcKNpzFPW3XlQWSjWRLeiof/EctEarEzE05zSi2G1eIf/obWr/ VhXzVjG9Ov8Bhzpz1hhCy75qYcUS4xi9HiM9J4wm2/xXGck/FztH+faTczYOab9PQBWJOVshgUEa TvHMEKeH2iLXoWskXCAvMkBu0OziAYEF2VgRas7mI4gMTKhvybIFe+/pQaIl6f3NqPobR43QspTN n49CnUrv+X7iBBIvuaXBUZESMQ470S7nNmbg7LOGElRqmx+EbajmFMoPSm/HF2vyIeQEkooEVbFu BrNvQGI9yYyP7nIbK631mSkOAMR42033nsMzQhQFp8Fv01P0RRc6hiAaD076wtxo2Gb49L9CRG3Z Si+ebOeEy8l7NIuYcdxBytrEczNRh2XotEPYtDPN+W5D7mJ90NoM2tuTwFpVnmntTjRg6V1HqX4i aaZdROuZsvFpLmgrSBKBzpz+mVCzx2KNvTNaSemH5sNfO5zZmXZUtUA+xRf71eRCEN8IYKZHbbk7 rvO5Vj/3xH5wkRQ4E+JUZ/c0aEf5Op6qj5QPXxdR53UnaEKUxdZn6tKuR1/VsYAyOga3xxgb9uzx L4mtfOJOKaUXFEWKOP57SRG4PsiRXnsp/1oCBqz2FfZj9K7HhKqVYeqB4BC4H7B3fUJgoirFc8Mo hXZ/52daYLYa4j1UfyQfHkfqHNkp+ZSy5goC6rT+XlcD2twvRKBz1EA+GOFXzxrCrQZ/5UFsj3OX VBBY6PRuI8HOy6l/eSiF78ybcnDcUF1NcTOVax9jgr/JPe25U5BoQbMu2LZt27Zt2zZ227Zt27Zt 27tt292zz3/PxD0xM+/zcr8VuTIrV2pVvlRFYirPdd4J60yIloZSPBd4zbZbQwDjuYPxInqUvSy0 6/2Q8z5R5YpaSOYH/orrCfLTuwRAZIWbqXwufvqKmLMJcchSv0IrsSnw6+Pzo9Jm74AXVgf+lstg tJIxpwjR3NEySQeMa7/l4HsIgKFfaoj3hadeh8e1xLvzEjh5MoMbRephwB+M3di5RomSPRH7xdv7 3dmI4ckJBK5pjI55crCUH0Ki1mtWPA7lLj9brFXvV9U+d6IUN+pYhY7GjJsJ08TSC9ko56pkD6NF MJXza8db+B3rNcmDc7O82IaemgxdT1suUMzss9s1E+GyvM4shnSox8MetWptzP3aByihE71Ekqza y2AdCGRBKZYbSHORvQ/R8TSyEjWj722K9z7rUcoxiNSk+VeXtwdL8qH68D2sNrr5r1s/ED/ArQUA wUDHmHPYaCa0knIs+15M/ji2hH1OgxNq5YHkjNYGBnULLisxMEpfIzdZh6SqfE0/vRlluDkggmrz OC8wLvUifQ9K5PZ/sQrFODLd4dTcJY2N/8ZKVVLyiSynwpx4Yw1qS5Kg3nlThrlBF6xyTs+oaepP V1OAVwHl4HiOt1uqNGZ/VVApIQog32+lC37U4K8hBW8uu0l36zq48hq+5NAC5j6KhkE7TzrynH7e NJeuIARd14UJ2dwqvs0x5vPllqDHGN8faXg35VVcQj+ZV8Mv+NpF47WsQpK21a5hOjKro9fqNnwm jreqy7n9WrjP9mnyBKZ6Oa1oZiKLaS4gyGDDyOZ8j2+4xastQeIgwEac8nJ3V1TGeVZc/oGAEmw5 wf78hPJSXrtf/0s0mMgU5y/Y7Lt2VXebsMbPyXBC2aM9uicue51lsHnjM+iRsms/wpFC+0q3cgIb sq+OSsFsg6e+touB2cwWxAQYYMzVc3FcpcSE+xtn1HS107LILd4yJV/JTr+aHfAQa9hSIpKp1p2m CTqNC+pb8IYQMIFG9V1Do21HsksYScS734Keaqga+AT+yIj3dwwm/YPjiHuXeAMzFNWzujJylrDQ BwTLDhXzwM1DXf0mvvAQ1y0g/nAeVW9FcuvLhhCCXg4MAUAURH0Imracg8MP2jAZocDJaShSn6gC S9okXU95ngjpS1xdRT9WPfA4QsvLtU8bOemBnYlBkWZUN3uH63YIz/f+vcNdW5mesaamcnmCdOIA 582gnDNLuch6e28SPeCo8O2LCkWPajL8gpvYl7bbX1MU4XeyfVyNtUX0MHIZnxSbgyhw5gZHW0kZ EVyMBiGEqiJgyuLEF95oyh4DgWjpENoEbIX62EDFqySEutJXOx4cAAu4pz85RnJIO2tocxAmnCWx pIOTiwECCIz+SOrk+/nLvxALjBQ0arCMcYH/acsLq69N+36A8ArXVMi3ElAvcP+dpszexn89y6nv Yb12NP1iiqLRi0EyyOtunrPbosuYNeCl/49YqAd52CpUb42zxc+GtIqd2mTohm5nAmXJ2UEBDnIY PKcZ7rrdHlz/qo39lb/Nnjg2894pxtmjOiQsdTNrm9++1yn2DkJVbUmuxRSGmBpZnvLRnGSUEZRm 1Jwf91TpE5BNWrwsy6/T6cqHyUBxuVHUU2zm0kEwDteOnj+idUGMUF+SjkFKFjaA/HSrJEvvCrAT z5jsWXd2+CQtlM2j4ehAxQ1ch/9N5F+ocZ9kvcNXvG4SJu7o8UdOIEXOzZRQYaQgBkdV5Iay5/tl h4B9F0M54Dtt9lZIkMrS8uLpBsK6Te8jGGIK2x0+C8UBP3u1r0GJ141d7qp5ayvZige6v68ZospG A4Ca+bqsKcnqIpY+5/VtkjnGHB+22NpjZ3C9LpFunT+Si3H0IabUfmC0x1pVInKeGYw1VEIfRF5N 8go80d3hpz1wfioeIoHT8Nqr9mS5sG9kK7Pd4FfIYE7TvG6GrJDY8sBQ1PWbZeyqdfDBonBrDlFF 5dnvELkkrR8LuvEEd8rCJEtBp5vOmF+u13+3NOZdyf2mOA1LOhi2gjgSubh0PbaRNh2VSluIFiIB 2AOEcx+5gC4U4MNT+pyAHvbbpDOePGT1Ev7kOOW8KG4xOWJRxdE3032ZIRJjV8Ab7cIsfPNBtJzX jCpqQvjmn7hdhd9j9d+7NcVSY54H9e8G9adF0zO5rPvxKCkO7akKShG+VRLbnOtUS2Ex+FX8vT9P VzSxQh3351s7cHL1C91GNbUEpDQUnkii0tQLtfI7qk4Uv93ZdFQk2YXffze+hqpNmsfvDRdtDyBi THxniCPEmvGepC0/L0qqS+W5u89m2AmxpIfWLmY1VfDY2WA2iXXjaS3nzv5+UqxqxYPDFDGrsZf+ wac1USb/BDEdHYsWNiZxs8KagH79a9jd0dzknbP8QZzdILmGs1T+hihKT6V6AzqEQtrj6yaN97Mu afTObPFyd1NmAEWrQKn16L3fHovUUrU/SITZpykUMcWb78yjenEZMFdCXIKeUb6Xum3kprHshqZE /uZFDLAkilfYknZIa2waF67bOYwaY+fCPZcWdFc6Ve8EaqAp+PJViENinZqiUOvULJe1dI/Kxqvd 6TMIStS/xNmlUjnHQgnlU7nYLXJ40cJ/hqlP7/JoneRGVN8HldzeTYOS+LGD/u/IbMJtlJ+YtTxW uUcY7mj2STjjxMT7iJzmarc0ygjVmgDhvJnLvp42ubc02mnPqazH8CpSsYzSVgbjuDwcREIQSpi8 YMntWDTVTu9Ci0uFgSO0b3SMi8hPS1p4JsqDDggEo7L2kmDzFbA4icdtIfEtQA3HXtyb9OxuuFVW YRHQQWoCKQQ7UlYhgGm+1LAXH7Ze5u6bnZ4C766J29OovRoatR9N8wJfQihVbGNDBTb4cysribTK cvU1SNUxnsTY4To8Fz4idEYdzRWz55T6wJuPA11P3tm4K83BoeV3JWX1sEsGGUv29Lgz6zPFr4Cp X9Sg383fY+qfAiIeA6QSLRrzKry1tzTb8R2kgqei1WPU1qgYBPfbql5H+kghdyrKOT0hQAkAqf0C DqnvjLlk02BJ98K6RVMe2WcbWcrvMGjlKu8GmXDPkKvb0XWDRejHjZ+dLW+GHaetgy1m5v5p4vso UQ8UU/PO1yPThCzgrdVJL6ALAO4oG8ie/ny9+OeFGJMKI9Fv2bQBNb94oN2owVuiyRIqvVMdaDDq 5/PbSxNcqioFEdBFaZ3T/20o2UMaAyEPSChYW33K21Im33ZkPnx72APe3UHCAFgyZbmjx55EH4KB XFd7Gj/jYFKiwgbQCsLYQMHhGRUdWYQUZAWii7Wjfxx48DM9ZhhpCYJdPUyV61eMEq0wi9Ty4SdX CyeUGC1JCPm8dzynN9nEuCULbrHKbXfwksZ2NuYH3MpHKpcXWtD8hpf/zzXc2sLQ8bT7tugtJvHo vy0PGrunFXkeKLzMen0vw1/OjlVFO8v5nRwazgTojd0qz66EUa8vMov/QyTJWPcBbG/+R1nh1Slq A++CS+d8KpsCnxoHSdHtrnAIxfjWMtkpfHM2utFzc/0EtJlajJkKF3mSqFCOmXmc7dsa+ALrfqKK PsNIdoZxgBqkC+kXZMzzGd1r7ZZf2XVs5IWyepRC8Ubh1/ArNfBbVNRmycbfz3xBBnXjPHlACNr3 WewcGHmzPpBGvL/pTrCRe3sqW26ZZymAGbDGm6MJXiAH/veKXKxtzO4p4Rkvk/6vXcCXujugXb3B SnnHFXar2PROUrA2MfA2TfQqubUmFFDN0aexQjkjtD7kEV0L7d093AKXR49N+F0HmxSDFuutXA8b FOo6OMu5CBmmxK9gPcGlhJJnSOuofNhZukybMxawwHeto+w5ihU+xh9HYaQiOTMIAiVQjFiP7Kgv vt9u+OVXUKZvrchYhnMjitG59vLYChaFxdkMVLLWBNVIz4RVWq+mvzGz8hdpz6aHhH6Cq7+YgG1j /VZFV8El6ceEdqcQfqGkPtT8pqpaGe6we/jZjBMbZG6srPJxyxlynSnfuWyA6Y6IR8eSC6XnMbYz BtAdEvQfbHIjPWyWWu17jORwcE3toaV3ZetRftbnDK6gWIhxfsgQibzRSKOIeu5JnEyVrsylh6+T SSmDfvuTpk1nTyBtJWQtf7xr0z6aVmFq3p2guQGRj+oIZvP3D+XwM7x8hWtXcDt+5t3d4D/IlInU /PIX31vzg7+wggn2iF0rfRJTaK26Y5VkC2hjx52vawMpRt/LG+uMnejQnOpXEtUYwh/Kr7jONb4h 6bLa8CYuJVFSEx9wInoudb/dSiQbBhBqZmhifibNCXMG4W5nfESdlPUzM+tFyytIffrTZInRhXeT 1awSeFGlUYSZ2Ea5ZfbtirgplePB+/4E2vtDoIO8fZlrVrEw4iJkBplsDh8GGQ1wmM0YFY0aoIh4 qwB2dGgneSLGiYd8peAzdGDdSsE7Me89NKMkNmbHUXINF740nSTSFYvHkt486+BZQ8boI7jD6rk3 b3MY8NhalIz47EKYoKxPiHOqwA3xnR383ltmEU7LkR9J3lzJWpU6DvfW1TSnkB5uLMbepfaBtRs4 ASLVMwHpTYCdSbf9ooSpi0uNcR1cqnI3bwSYDigl9bNVIQ7QJQI54lWtuP/1CuzU7hwIrB0avc+C T6LRfrrCF70CBmNXQqkKPNQIlpTCpTGoGSEoEuWGdmRd/9o5ScYVki/CgtTpK+mYma0kr29LoSZB yFd3/EivpFijz/DarC+R1fD8PF5stVLrmzDCil3VxE7NhoIi3Xx5EkXz1AII2B30tcPACeSubO3f pTI8SjcqMY2n1elHaUfO+6RzNFnQYIDsKsev+ZSK2UPh6Eu0v4wHylhUFmLLkj3zfhlKIxWJcHaI IQy8evaJbDl0ufSUFas9c4iI2aLhUuVTq0HvGrmAEkKRVBIS2lX7+aR4ADMix7JAOZfbKZWD3l+s wBCqAzy0m8H1A+eWzvFOkxBIdcXuHDAzsZ6b9Z+QjHhp8Z3gUimBgaSo4uIpUyLPp+NCif17Gh9I ekdd3O71dqXyEisnUTlJf6o0rBUCTF6z+pLQ9M20pbBgFMBeYCxZT8+I9R7OlNRD3QbYTUFJPO9w bjEqWVtX53VSDqmt+aigFhYPq7KzruuB/xQpZkBGJkYnlPAb7/4pNFy1qcAVxnI2LtofoUP74J5u JNGdc8i27Qc+CdSp1B/JwzwRwx3Ou/QisjC5n2TcNmf5Me67QjMt/5kNarKjsYIj1enKjnknrg+3 Z5LRElctDPpCJuEYJTiJgwg4zjJ+5/swhmEjoy+w/egn/6F9nN5SR46DrjGkZxIV8VuWPhLarOJ8 qeq2GbFqHssYY6qH8mhqx3xWnDtSlj//p1w2IXmAGAqoe+D2/my03Sbg0yIfYRtaf0QZXBNLHGhS mrrtLlOHboEslFMfnDZ08FJHa6dqu+bVAgc2ekkbjJG9hryW393M1q2WPl66W+sQQz9MozPNYzSi LM7zxEBB20Vr1P8NY9dfnpjXHShQpjOCltdj6PbQ1QYjRS4xreT5Q8UZuE3XF8TXvlNYHArT8TMT vZK1iLK2zc18LFkx2wboWaDBIW9YBVAXgwBfzRsYIuIq+ote/6beWIxQaTzyCKILevno3E68ZCl4 HKS5klg1SJTU8QbRRUjCuN8G7d59ycyp0Rtp8uPO17J9MpF7m5KVQ0+icdHvlzLlxtHx0CMyR1hx H4HxZno+PlIux1B5L+hREZGkZkss+LA50rAnBLOd7tlpTe3cDFj6BHGdlRx3a/3ZuHxRcvbi8dd9 mhFnT4p5Maz1e6QmbU0uIJrJ04O+bb2UPE6TQhy535xOuINitP5kB85TRZWM8WdjBDeyCsXFNOCj ZJdXOWpLvFJR26xRcosVvJROyg6zLpZZYuJCjuQ0MPEifX8OaN6uwgQvHt1G+sfMrtw5WniiNGnm c+ff5cGzEAGhWU00/altQ0nmAKy9ocUNKDxjleM894MkwHExWXGBfFU6gIiVE3fiUs1zuegNIYN9 qDBQi3y1SxnfL1tZ/RuSR2XUKdf33LTFRQSDQ9shEhP59ugPAjscLwxoa5nMcJRwAmlZ7vPwOfOh WdxMXlp0Pe7PKCVue7OvLIJ4IcPMsOKjl6rVp8e8DeuaAGYRR7Um2QTBRvrFoTfMQ3Xv0GgCSXTA xhoGZ0BZz/Pr8x8qsT/wA2Q2qA6IC1UV7anPHZ8orxGK7OA8v7qWf1+qmcGYcItLBaOajpBBt5uB bWWMISpbTJqhieiQoqKetbnyDQdRmnAfs+uNR3cJlfyNnimX28Pe3x45p5/RWGCMu8FX8ioZgJWh Y5FETaaam8EamNN/33iBdSVvIxP8qWzcIs4ujx+hf9qTJlyAwqNkOkTbW+JQ9iMrP/pX+OoNfN/S KGaCmSxOXjjHjgo6qSnFeqnHKwWO1fxKTEYzPToQfKJb8+NSapw9KmeeJzfr3FWBz7Oq4vTKseDa FWjSu3jpfqpkjBuo5DobUtwDrG67Hpdqdd5yK/o3q9yCk0gYS5gZUFoEqx75MkqfY7wKKIhpmMez a7dWTMyMZGbEq+9kUp95QdtQ31MTWyO6GR/VM3Vfb9eKVrNjsy8RZ/2uQ7R1M8VuvEVRrD1AL1/e 7MfVvVpxP0BSJRgLlki2zsq0J7AmNiraZxKteRRxRdlxG5CVIkLcQzqiqxAglArLVu4iEfZMw2nn m9y99mCvyaiMW4feXEBRZ3ztlO5V1qtniX2R/YiLbXLAGmVyUBm9E3sIdDQXwoT5o106w7Nfvilo r9FewlG2gF9nDc2HZeQNyt07H9QF8zcgDF+LCvN+X/i1LkEXOLaMUyG77MabzCNfK4RIm7+sURP6 4aNGoLiNtxzM+GXNgjNfrETTKWrSqBiyFmXFEAFG6UlILQ5kPDnruXx0kwEbItHk3IW1tNOStygi UNwyA4ZLXiQLTEVMHyUlWEqLbD77fDzKXknracXSfflPgW35haT8bFZBl+uo/5JjEvaHFL78msqj 4LGZEODiHzjA8uYoOmKfPiTP+uvBkyQbzyma0B2AdnrtZOSSI0L1YMvxryCMyhTLh8pyB5hXcEW8 SvhkVKi20ptGigH4D9GOn/vIXiTn9JsNnoLDcbqUhllGXeE85Py+YrJB7PTGmsMCAxNx5o9OHVUa +UEKiGr4YUcfpoy2hLbWgDAZISLLXlw4MIbXOZg3ikjy1UDyQnX6AtBgt9FBSGA218zKIUenkDAt TX7JMzw0z0Cfm8KRp+Ju4ZOQVPZcJ5M/ZfV+Hl+62lugkMG0hHIaKSVr4uWzQ8Bl+lSK4MBozlFo 2BAoWDpF6ZCdiLKczhaYFkz6NHk1VCk6ZfZXPW1kj3hfVT7r7CSvLPVwXYwoMVJwr/h+XJFRCRoJ li7lpKhiu72QlyLuUJs9NB0tQMCuG9NmqPr0vHnkzt2x12+sZXaFzhfUBlPl8vRq8sOjDR6nGSmr WOTWQzYh0PQn6zgLl+EVOr5wTXr9qatV2J6CywfowH0UGSgHbs/6hks24QDD8/BAP8xGmk/yaFcQ GzMDlKnEIrHRr9FSwgOMrxnRFfQyCqySHDmf5Lczz5yj6Sf8uw2b6PbxxWdDA412TOYxbHNQIutp D+gGdR8z1FzRdHzi6yjDMY2v02lpw1a8n9DGuN3IaZ8TjCAUnJsSX6gJFTVQHcDy0eMhha0Ff3mW C0nJZZDx0FeDuWB2qR9YEONUTMqIL8ukPVkxv6fU/6v5fahQBUzE3N4aUS10MMa0PzCpE6nkNvfk T1h9XQbVdHa4YROG8HAmfeix5RNxzNS0HacOYKhvgg+SZs2wD0bxdF2WG8nWDmJTpNgnE7tcns65 UnD2MVj4oGhfj94A3nirTgS3+GC/d7yCHXMWdsxwKMmdRuZo13N98XLDrhxd4Bz2JxuikGjLuPnF 7wnijlwqrhp53cs/kpFA8LznxFI/4M/zCeilUuedqPOWT7RPs78OTwnyX6feK86x0AoBfyLJ/UGi Wx/Ree7pctDlJgutY7iUyC9T1saIaTEy+CSiu7Gj46EpS8KHHWUKS724m0eWNA705hMkQoP2Iixt EoihnbbW8xRhl4EWjTiIOYJOKKeSsPr3PlJOngLf5HvPaNw8Xy01guK0cYh1O3xwBITo4YyX00nW 3Q8VO3JL1IXvH3NI40ipOR/hIo+7Szh7lEduDIGL/Qfd+sA4hkS7SWTl34N0defGnjCyOPS+U5OP cr27xSY1vfF0JJ/Buu2vzPsQYtQM/YYXL9Spl1nIsIXiXMjCA1xtypijmYmsqfZ2+jjhZs0Y/8mR 1tYKUuMaOWL1rIb7cvJ7r90i6c8F9r526hHaguUXUdpEmsqeJaDPdk6Fc0aWBjphwtZHJKqjM1ff aXfznVVF3Zz0xoeVPiRHsvJhp4QZbwJ4ET4uhlS4H7V60XRloPSnRUVGyn3DYF66X7mJ1SqNeTm8 m6w1GJI4/NvtWjIJ/DUsI2tZFlNq2n0tL4vv62wYVGywgSiJk8VZr44wnARLU8tYhTxpgd2mXrUn 5sZrn1SXsjjmBbzvwyyAeTHjt0u7OHCFmYx+rgWzKczSmSFyCwPrMkHXGvgNShzUl8Ve0f0LGLH5 MfHMS0DvbmoVI9F5ta2sei81PBII5LH6ZG6Vr7ekh+2vJ+w+/S0SQJNwyuXvDVIGWJxA+qtcQYA8 rQn+eXwtOgj+oK32GneRs1yb2IRtn6s337PzZcGWxn5JKNi1UQ4Yu0ScKAGo9gEdeVTcZqTwrVXF PQs+rTbBDN4sJ/aOVTUexO/tz13HbnZSEOv7Xlyh1nE/IZZvCwowhQjrmMYY732gCZAe9IjQF0Uo k9gh3eR41+AjYC1rfKyZcHVtv5mCilQNVBx22LCi15xttk5ZUXaWbZqcB0YsVfxoWCcVoPJL0oAc zf60wcYWdRo63HXpUV1YOVyDsu5JrzKpN5lI0qbj2Xpk1wvxnEfRxP69O/q/M42M90MlK8enSznT 1SK5HCRl4+sgQQmlln+N5fYETzu0+4kKrumzQ6nnJ8CTWWQvGfT69oPGpBQz4LLEs70WyPseM5R/ VKfQhazzVRyFzxmOQHjrOnaETn58O5fJEiL00D1sLPJVOL4Zls/T/t6miKSx5XiIcFEvRHPrQ97k 9VVsMDQ5ljnXxyfPOgLv/sUED1XRLDSLEV6e9G8tZLcBZ5lirqEcBsaQALO03caLJfKoKMJI1OGa z54cuP+aly3eh0DQVESVi0fmQcCjbCUR0A3Y2KXsL9EdqoSHOGdm4rrnLm7b0S/wiksx5E9CJrub OvWz39R34HDP+AUm3IaAnjdb5HP1hoy1xCSEwqpUT9ZyYF52+YMy0LTmeRQZ3lC4bCzFFEOtbH0Q d3AMwuvIOFVe7gVHFjYApFYo2uao2lc3BNAXI/kIVMt5N1q7FWPCyuuiFMQRg5ATFaCsF0nQLph6 89EgqGOjIQVwtqT4+y1y47VMFel0xy1dwPsL90VZdwOMNy1GItKxMercOujrk0bX8RQkDmdlCXuo CrO0TOKYyY/t9+lXy0xMkuD2bNg0IWNwizAHGo9tjMcn1w1Afo9VFqEUh9LNJ35M0o9YvG+/uZgC pqBJSatl20kJkcaujXASicI7uyjoVilXENJpI4cIEC8J2VdkvQdAFpdAj5eYGGLAUwXhlYy04/kD 7uLtbc/5kX3z+PnM69W5TYeDvUT5HmgjV2q/Wiz1vRCix6+kchAkWhpxAjwUjOpUuDI0gUwsfuK/ xiyIsJIej4sVl/qyulRqhiPHd2xP+y2zleWdzon9vkRFdhn7MvzECSaleIwPKVGjDMsYojzo1pNL HGiXnMQQsPbiMRHlTlwZuvrtmGGvfT+47PQIJRl3fMexv5tRMA7TzlsrIsFW02pmSgeeBeN4NOxK CDh0Ox61ZRCYuCo0uMXtg5pR4qu3qO6lre4QoQ78wYt5aaBv3FNNcK9Ocm0CoCcmdja6DyaHpB3a 9Iw+auWVdZUb5+yfePx7sZpUnN3B1wd3Kt5R9K19a8nh/Ismkp7x2JFFn47nmmTmQQp/dg1sXg14 //MRgM+KSy8G2jRLKExsBYVZfTdJJY0rm5M6vDJsUrBCNX5cdLxuIkap0yc5cHjY+ka8lpijGyCX QH2HGr8lcIY73Z+Fb1JtEE/hsR2cko0Gru28iIjwrkhPtaNWca+2aAzRNPRhBZT8OgoyYrvmQ5ZU zFILaugPJaxmV6FKQVJ3ETm2wNF+00LMruOypRly34xZqK6Jxln0p5v8JXldI129TxjPwgr/tQDi WrMRyL/3qxYRMv99aMmsCtsGCC0XozA6nKutUWNTTIFovIEX8VOjAtDTJLtHmAy/ZQDVQAhc3JLI fDPynX9QCJVqF6ywdGaV0TQYmkurRPfNyIUxEbRPeMBSM6owTOgbleuvyd70ssnFkeYgi8S7K4Td 53SPKwlwfFV867XnTYT0O5yKjTf/qoXAOlOs4AN2PO+wiMdd+MI33SGuyPZPrAjVbZms/sA38NF5 7cG52bjvwMalLR61JbM5UORNEPtopQz58z7jfYDaVauCz6fqBY9pISMMqtpCfbEbkbJjr/fOVa2u 8zBoExX1i5yrfCEe8TBeHyMTGKf8DOGBlof38IG0h/MBij9aT3WEGDO6ZCKQ3O2Na04QZx23YhEQ 4KnDTjTLcHr72UynG5U2i4rfB/4b0EQyz9Q6zrCgaOWS/Foday+15Akn99e4rQmoRne9JiEQ1LfS cS24GPlPAadYVEwKg0rj50sqniqH9xrfzm2xHRu2Bc+vUV9xyy2UUU3rBkV5ikoi/svUw+XeeYuV Tc2HWJX240dEktbQNzSuhQZqre3D+IIVlztEUmx5jugPFIjuLQes8dj56w1P1jnW3PYUGGCiZPKY p6xjYTsqdRXLCpdCU3BcqixJP6WOVXwX3X59E4ZPbUXTVSgCWhQBPiVfVRHhkdOpPDwC4imw0yj8 DTblLePo9k39AqFMdM0TnlAB2aE37LW/ARRTlfLnNyecjD/13W4W+wTx+SpxQIbYob+g4uTJ2nc8 VL0JX42gSvxnSqnpqrJthTB63uqSVv63Mylt0QIeiZZfrc/EFYo6ONhyrbM3pZowusHwhOlqhLd3 8faOsqdCaQi7UPnGG0xm7AwAkvzi7ztCgn5wqgfndNQ0CFlLlDJ+7f4debmnAk/dJu8JiCBcPxb4 kiyMCkpOspQ4CmU9p+CoU0tlWRUWEBFCk1eyCMd4XyvEunbTPH+irMH0sDCb0LnJ7AoypCITLFQh EZ4pK/gH9oPB+xkQAADA2b/nH/SoJzScgWYIOhQxAQCiBt6c/slBo8wxIgHm/8vMnwFMTOsS8HwZ UtLv3Pzw32eUiY2Jfm9OggMpXAb9C9t3V46+xZFhrLfxpvdVu+vcj3fOug/Em5lZVabjq2+IRKG7 gGv7oU7ehrVgd3NXn5f3fWwKoSSEDmH8LQqrrZWC6DXyP4BiTjmhjiyTav7ZoPePHYBU1jO2eksD ww56pv1wWlT4WRlQf673+Ygwy8ojRoiDE2I9+y2NQiVQkaDyIri0KbrZDJrX1/LaJEd14p9uDzBL CGmup86IL27BBj54A9xRcOHZYD0DTo4xPz8wI4InJ/o7gxiDiIhIRT0xfPGjgCIB707OIZFmsRAr 7c+mq9oNGNGgmxDBdMCPnLyf1tf++jGaq0DzdnW/kbIxl9EqXEm7hGVHx2SGwc+kGFTFvPqRL6ZW lchKocW5hwg6GJBXWS4s9NuWhGJxr0cVFcN5NFWn58FNiwY+pCM/8/xd/FBiz9KvrBe1i54B63sX NDL23c/+ljIUUUmLJvMB00zZZPLoiPVCDXHKOl+Rz3tP8JPbCFGXkzDnrwqaH1tsqFwqXnzsjFSg AHDCcdaKlwEnC1eBoSEF71bPecZARhA58RueD3IgpqgOSMqq7TAn+dI0tHOcDjf5ijEM6/OY9IaZ HGVMt9aSRWDXXoZHU9tzHiqC2TXvXXhOOY04vl0r4+UugwbiIy7DRVWXtm35lrbcBa9VSeoeqNTj F5aRpx6CKZx0AIQj+gKLLFFml+p/VqKbkp4cjF7TmqCWZeUj4qWTOEXw9ltWYD2NDe4pYoAXkd27 IP1uQ0Z0QwEHZASRGUQrvbm4FoJuxLLSaFf3+PSITHtUWITFvjjPQodNBL+V/p6vIMNKQhk98R8T u+EycdauDlK1c1qLGZpb2xKN4964eeUbJpZJ+ZiFX+ru81LWZiolVORbwF5YnNPGxM9XIEhw8VOd kjAqa0l/yFXiLk0Y04zjbTEHyc4LNww98Ta4isvxXg8YT0eZ5CKEBmMY/raViku0iAvSzoliCbR1 GvCFK3bGdXaMlzMdcko4NcvmkrIZ64GfWqAd/qbiIG6GEVAoX6vECm8PkVPp5WsoRZftbeq6KG2v pCyTV5XosBV3MXubL96kuyZrhaHpIBSih6eNxN4InPsCskbxA41K8hCxoRVWlNoeuUAFeXswmb/z 3rmDAXpX+npOjXvMOnGK6eisBi4qiiROSXtiiUQsPrwW34Tgg8K4Y9psW3ts2KXvttyNp7vTmBu1 qTkVJOoXn9XgXlbhI9/0mJlbV4MDKmoAW7OmGj+cT63kVytv++aMvWSBZGgxB4jItQ3CtYU62Rl0 wtxh/4v1NM5NoFORXrr7ikTUf3zwLCZsUEyEluk40MfJLoNCTBJB0XibAQeH0BD4faLdSkmwDF5p xE9ErQKKBewMCIcOEHDwexZwEpW8Uro2XVO6lC+grKQqoa2k6Wxupmng56uZ05gU3BOaFZ1TGRan D1DzK+EUaeCTFNcVk5mcBq5Yv0Oa1aPbrr4b6BSV6jBR2Mk7nmadGkyPTfJbDpAO19fJXBWrzSZk JEG/coo603lkw50CpNZTsViVn0ySH5+SewragszP9jxnsHbVJM9YQxq3vfpRAr61tmXyHVXy9jXZ s4XDlw5OAnr3IJfBA1DMwud/iv5tQsjwjrrl3IYxgNTPUP3IfkgFRz+M8DJF/+L0/uP5GcyKkbN+ ZMCDxwmCTdR8tGtnGdzYk7R6sXnbYgBDMQORHEEmBiay6nZwFcA6RUTe8YMD/CdfPIKYk9PXfpjH EO50iuTGbeaT0jjrBXleYpstJnyHQHDv9YPmvX96f8MJJHtFZJ/c52GAfy6sAZ2GpDl/Oz9raS4a dU+G03qEkDa26qQgupDOvMs3MaqQj11R680N9PpCdDpZzOSG1PaBOwVfatCOuGk1d98AATSNVhQY e5kYBUa5iAjff9Lr4toeY+Pu+bs0tQKhjIYcOZKIW5IELH64u0lZkvOjmCyesc2ACESR+YPFnsVT 8eWsK+34D8GHKYTC32Xyu+xSh2zrRo+k+awIGSOvljowRz0t4AI4f5h799HHZvk9YPfDuWytc/bM DhnzgSSVMN9uv3QZQQkEtMmSrSUS9Wtp9AyU7YJBhe7AFkxltjQXgpNRuntvFUd7mi5y3XTsArJT qQj/GRQL+dzBinB0fusmhgvP1u6izgFcarVgPz9HHVFZeL+/9I8pzFYpYxpgMHrmBuRFggP4LLqQ bcM4UwK2KlH/+n/fL5ZUD7jxucT0FkJdNUvKgtA5KDqgE+TRExqK0eV5nxg018HAf702aWnUhKvl Kc+ctT1UaXIGWp9b3LEJbq16t6//IimPGAYzi0R7FM27qMSRexqmScSranKwjiC+brNsvHUjoGSI xROBrVDwNyUxTsiaJ908Q8qiR4p0YnxD8uP0V2CX79mA70tIpl0wAALUPY8zwOpXlFgghyUhbMuV VVqoV572F/Ocmq28sAFPv0wXI4T0yruSox/KH9AoEuVGQc7Rl96oV16D6fVclDtYDzukKcfokMUV jreIOUcw/W9g5IyTGb83htCPuWRS8Qr3q6xeUJRABQNq87VQ9SKDq+mR3IO0ApU/A8R8Xl4GQ5j4 361d/IeW3fEtXbH3BFFhHoIpvMWcCXcIUg47MW8ksPc/1QwjQdObR3a8AG7hvw6PcWRwA4YdRgJh vwzprK+yjl8X0MlqM6dcW0RgKyZ1OLwsllmPl9fkHAF+S/yfqgOKgiJew/cPCKwQA7uP7g1Uo0OF tlFEvUZDsyWsdwn1fYe/ZswmVkXZxP6T3CaNXIBuwNEVqy4WiUFZaj1QjTwC3nw6T/tYGQZ1UESG 2Na56WGEmek1ppn0VaQVNLwCd4kE2qfPjqC70/awKCKJrVsthx1n4WIDvnLvnr5Ba+q7eUQdv7Od EuG9RungkdsDX0MxUO/3f17novqoFqfG/XQvmkgjd9LUpnl88qIKzP7G6kDO0rVwPV/B7f50EDST jw6UdAc51NnK8HaE78crv45uC9zyySzxSo8fvYnmY1x1IlAViNvSLwJLc7k1yJ0DdYP73Ky+1wmy duqJRnrHpOzZ/xVG+xwBtSYTht28/7E57DQD/HJIARxmFoGBKPwAEGjg99fEVZmGqvrQ5ak0F4F1 skPFX9L31O+Fd4ik/yTMhKbpxbwunYa5pEXCtzlO0ZYTnVLZ0NfsPA5dzE89LSfhZ2zCMsKH0Fpz EujNvd3z2sBoiPWw3ZeFU65EfyLHXnfIwEPs+Bilzq2oo8V6Fy4Ec8nkriVK+q2Tfdl6nrc1/Top Z1MLahsbciGEcj3dzqhpl9nY+1EBl78EEGgNTgwQe6bc1voOXPZg8tCwbOEL+/T5XpwUEdn8yP5t UDTa0EyWevGm9TS8wLl1WbbAdjhWslIJvm8mOR3Dq5csnUm12W1oMScgWo0sczKBPiz78YZP7hX9 7m++oct6chjNjECsfoZKiBRMxnyyaLwzWLLL2ghtLw5BwKFsusIwJEw9aCFXnBq+tJEMw5uICi0k XRlh0veA6XYFedYtgWXGUhkJwiMi5CbkHSKdaAEA16G1rJSKRumKvyMnqKWpaDImIcI1u4PJuWlR Mr4jvkt4q+8qJZT007cJuCgrXpYad8JdSs3xtA4GEOmM7J1CsJFVhIW+S1RXEvN1EC4jJV8sgbi7 4+NbIlXr0nE9F/09iNra5DcKY0guNTq8p0VHAAHyHUKwlY+T/QF9Ggrt/GrAH55ZDrkIrneJDDeO ScA7jIuFMXWqh6pfgURRYAx8krp+ZdOzj9u/BUEbXohai7lxEseF7f3m722lMNOfxGcbrieBiBKj Zcme80U/y1/OO6AjSjf33vNzFPkR0LpqPqaMl1NERbLHqqRJPmNXQQENbNPfwgmRQl9PGedGSOt6 AV7AVno4hETVN3HQSgtGguqDW+H5CwrYB+cLYrFOYXNMeLmvVPhhr2VEWIA7c1pWp/7MKwjBQlMU D4HAtFCoPLUIir/ksBQ0dctvtOLBlRT3x+hnkM/qxvGX6cFGpPZH1tQ/lgrIT4mJh07DkBXsvLDd IgQ0ITfOuuvzfJ9hqan8fsbri7PTZcLJ4Bau8seh8Of8BTammbX3dSgBkCVv/mIbLtJo2bMRmEyw bn4y6cD1+6qFW/fqrqpZkQv4caDWAVLEmqzvHtEHvTyz+X1kG7bO2zNeFCbQRsB8JCiGypbR1Xcj P7wfy4+tbjF/EvbbVruwCuOPZ2Wo3680OyFRP3fKZz7m2Qn5PZQTHdIHrQDEaxtMXmWuE8WVbtAG 1rb7/Vgu5mudNMg8hxbLGu8cOfzn0neZE+xsAbJHe4XuqpQwClj0v2Ohh/SkQt54zytazsDrd2zL HGOYaN/VcXL5l1b43WO2VJ5noymvXeXFsY6d/9GND5clQ0Z6J8Ez/qfuR2LAeXNC+Qd/Fd1uI28+ RCRCY+oXj1IVZUEV02MxUCgL/Y294+CotMvp5eXVvD+9GWUJNSi8JpKiA+B564ErICbyPS5fRjLh FR314wOrQllShIC/W6LW6XpUnQ60IMhzSVq8y1+1eBKyLxDb3QWLXH3r1DFZGf+cY3xQkkcVLDeq j319sakzuD12Q/xsoUGdZbaZhzgd/axYnUNpUNQP+aKW6+nokHNN14yos6mFIFiOIhu5ueLBYePN ik0u9YIeHiXj9/V7/9Ay3molaEfn3njHtHqQO1lLlg+kppIauJlkaexw7pRjcoYnrrqxW72HGCFN QBk2KN5HonsitXKQQvSeKsrJteFxLGKiQ5GfiN6VEOax4vTsgENqFKWSnFL2rOu2Fjl94XkyX9Ik gXN6xLeWAA1XPme9EC4s4us+vBhGgG2bdJDOyqIvFXW+J62fhzv9Rrrwr7pelUEfFoZ8vbe07wKp e41ogfJ3QLVpx5e7/fDWbKqCNt5u82I0zyDmTozTAFnhXRstcJLIBmJztRVk2DkQATJYjS0+a/c0 cbayUVFcULl7E31xWo7pSsDUN76UumkoXNaPJ7rS+CCLbYvevrn9MqpAFFR2FagDFh2d2T+L3JWz Gch4XQBxtK/qIHELXZSCtXJVPo+6XZDpSfPaAcJefvH0ssR4FlfLd9FLspaDklyY0nxPgLQ7gz7c UA0WykhTdyRdVMZnjdllowJvG0x7ue/8oj/TgVu/svaui2wgzO7vIaawfP2Q0nUv9g40KyXa2oL9 mzcgbyMm7UZHD5DAxmy15Jl94rFzi25H1ATwT6lKa1zsnr6YmFZEI/wJOkxQJXfDE+r+G/T0kCWQ P8UtDTGpLitHuo8GYt4d+1Z770nJ++pdfhxuc8DtzJLmN9IIiGRxAtcAGSYSCujNenad7c3ilYsb BL7Bhg9sHYPG9/nG+6fJuhc0EXFihTt55eZU7rUHPVEP4lM2yraFVgdv0x4hdg7A9LSptwCcULkR yqsZR6JsYAf+vLXYZRJ0lynVhHLfZKMoeYoCTXq+f2LFe5y/TWYiEF3tjdXyFG7JQf1/Ws2K2o2g 70tqDmhwmaDOjtg5MLQrbhtIcIfZ1yqulu0ASXZA+bLUvVpUValSDZsr1VDWWcDVwgmn1Hj2Uiad ED1/egs58F44e2ooHILeFDVSdpAy31SmaQTMq2byBZo25kgl05YM1eZD/dISkT9A0yQodDpk6ysx 39ZJW7DAwrjuGX0o9yzKc4MsPh8tHbv7kO64L3yXlPJbraMMjHLlzrZukq+DONAK+aken8q/O5Yb Mi3xvV05OhQC2yZHUHaKXg7q3LIRvQsqFrmzT18ZzKzudSFEwlBzHweYzD/j91MOaNmTvGmu0wqF /ywxF/UrLWjlOUW8UTJoUVkoR4TjcF7NQG9U9+cfLAbBrPSnjGtu8ewD9fUQHhAKIW5xRhYuJcxy ouEwv8H8gQbGZLpPGrS6TOwcX5denaDabPEJjg40SgQ8HkLzvj88wL3uF5g/MAUSdK5BC1DlpQPQ wIFP8BLbsuORfUSJApCbRgL47aoIL/azpZqT1r2V/oO2byjuHkhJFxSoHDpG9he4F7VecwqRfU7C cS8bsmZdGQc9oGWyafND1bRyETAFNDUT1loqVhJC2/soTo+Q5q9IDIECSFD7+0JasDwPV/EBuGo3 qllWe3pO1GMwYHbx0o5fkog5+1wkp+RK2IVcQAVRntRqdd2Qch5oIPcfyvfGFoiAZUFGxxGEZCJf Up9dTgSt6432s0ZX/PKr36eXOJPX2cLHBipI6SveWjaelRh0SOhVk0iByRzZwVyhBmwFkdQwWhpf 9hxb49/mV78QrGgvUW3Kib+Q3sdKTKCh/Hq9SexF4HpRvGkM+x7aYCwwlXZaQ4qqxWHYZyILSuoF QpCLzBO0V4/putVViwPOEOSagldzxgfuGCoP5dbFcBrA5083d9pn5gv6r5psQVQgKH//YLlvzIax YQBgU8upGSf+YtFznXydTcSNRJVD5fIr0k7TYB3C5iKcPpPtsF+X/Q6vcwjSqPzdTLzGqsjLo6UH YhFvUiVG1cOfMwQPb6uWaKLhkggBfLLpkx+LxyR9uKMkC35AVmmyIfSAsf8YQmAyUVloKkwlo06c U4EZvocYyTgIigv1zIB5WpYgpytVK/rUqScZ/ndBz9Q78tXXNErCHHoAB95pbm0JEzTksaI3f/2s g1aLAN/F+wQ2GIGBKG3ePgOARCixHaj8wkBuO8eNcRjXuseuNyMYc0r9UT1tLpWRENc3Tyoz8scB 6jpVV1K2oPYRqb8DQs9m7XPK9xvoVNmZtWn8eH5nCP5pm7AxJK8D0is4rUc2jItHPCNMZNXNh3CR NsHARfkRLEfrHqvHXgAuH+L0uSvC9UxyjACCdu+lsiu4lspVvMh4CuPM+YN0Xo9MGJw5wGIbEUxA GkYW47OhqwT8SAQFe+llizfnVe7ZkiHvfvi8pc8L1YiMXybbxAYBFFU8nB5qwWfopXOMcStKoYW+ 9QMl/poebP3oTrB0no61qosFFt/YFZPbrjd4z/0JmieJbJbR1mTw5I0xzLruGbPnMT0xFfNQT8/r WWedO52TTD025f3g9bFl/ZvhQjNCgCbTI0mZPpvKHc2WSwdvEHJ6WIRtiBI//mzTJd1rLycNEW39 4/ckxT48kltIVA46YWDklsB0rsgoedlDVFMlCH2qvVjWCfrX3fRSl60rh6damTbc3uMcyDvGwW2l 0dkkLmCW54AM2d+ZlgrfzlhfBVgo1Dknc2L8aPikr/GATdLJvX1nUyr0AITKPcmy9xw1VQgRLhjB 8Rh1foWejpfJlt7ncPe9vXI+XI+sNF177VMItKnjgQHecBcSn+7iKYWbB1WjyzKgxhCuVYLaWQVb Z7/RE5JFPnGLk02+PYZHgu3P6AsKpJkMqsAVVHQquxtbHDlbwelmJb+rIif0RfIJGjgvlhKd7ofi 750y5GIhpkzyGe7LqClJNhhE8R+sgr6wJ/9yzV3yeY1L7JEAD0wCTpwVAIJaDLcN8z1zAdLRjhkK zcjTPCCYI94O5mm3UtPo9PAfYEkwZqgSseId9ksFqdfgRdOrqO3XK9iai5nD1mzqHCv4WaTLVPYc wzkVTESe6NwCJT8IDM/aPr3je39DHd8aF9U/Q38cu9PA4Et0RSX4ey43MTKINMQHMqkkvvfuDEpY r1J5K4FgaHQDgjo13jHE8HjBsGYiHnR6IOSXoXEojsL4AB0/EFa5l1GkbvBAr7VOaNuW9DUqVvfZ MfmeInRkyfl9VmK7q8NOTvR6IsJ7ugZxY7yrcsrmYrYwRm2iVwyjSngi+zbZEgla+pj1ZgxSsbvO TW9xcwwIMOOW3avJTlZsfNj2oEIVhJc/ouUuNYv2rHhnXjumpZzZYuB943aXlN3s2Yh0wN0Td4pH 5gvG3EYwK4vGVSoZQGYOAgiBm9luA39JZXewgI524pAeJ7uIcAMAt8orUbZoC9iyy7NuoYGQY0qc yqfdix9YTl0HstKgsA16qo6x5Ts6ZPSsxJ68HgLY/eospkg34q+7wmWq12XVgMYjgw5N4ZpFSaMr QcwI/ewHgtgREl+VUYNV/BPSrzanXV2h1mz56ocdpDTlWwJHCx/PakkpRy/wB1kH1mY/xkkM9TLR QAkQ5AJfjk2clMdtoICWyy4QFVxKWZPZQNUUP7DDsGdgj4wzH6QEHrK+if/oGmfkaHNsmTDOmgDV zm+h2ZN8MXhJsrT8xSbWh4Xf5TVZFDWtKNEpm6Yl8GAbPu0nAfoIQidIjPzOQLC2NinNt8oKfi7A g/gurmIRhjJfg1jVmNbEfiXhnvKaAbHNyr/5/SVGG3x2MEezoKfuAllsZ48jAqUmbvKmSo0eARrS 6Kn60hSMxNQAXmqgFMygMiDwLjsw6vGGf7ts84Mi5aRXH+f65L/zyg1KojyHlbyv42GM4kE1b34l t17ZOmYrUPSKwrE9ADjFwKgnzBNVTU2DEs9RagZQ5as4oQi0LP4g8smtUbMbEyiw6qCLTUt25C89 F+pu0Lw+VWwsAWDVg5oWtCdKS8Hgrk5Ay3tls0MlzNwHXGB2QA5zKsuN72Vprsm40tarHrCSeHlM BngK/VIUITGa29XdkTgnRQNyN5ikOTEAKPxxxLlADYJ0xTSrVJNHlwo/sX1oKOsyfDx85aoRM5xZ pGIIbr0BtVF5d6OOZqATpFMRwSnAY058SN8zKrlHErnWbyTE79T3KfsAaC9/xB8XP27fCoE+cgG8 ZAW8WC84YwMAANA8DU/cdqH11vJF0VZRG3VtCsFgHvqhGcn1r9AhqGlEDv5wEUswo7k1m+jjdQWy 5d6hiLGhb/hPEOxRgzOwfyGiTEggLmGZt0x+mU0iiO9/gS/PLoF+CZ6Bh7r+a+hjEgesHXLkAQyf IPT2PxywTMx//xVgYh5BBgCQHQBDAgAIAJDz5rQ9Q2BiHvfPTMPwv6L8Z270n3Swp050yFEsJBoB N4IoggCXQDME6VGD1FsBjxCTUgABQ8mSL7//5YFLp6kGC/y3PU2xGTDqLeA28h9/cwKCJ0zv/K9Y AYNCrcQll4Dt79aLhozIC4PvQYvqUYOgvyh17on/sYsaOYP+Zxh0tnQO81983OwNeGCo4jlNCox5 REL4Hy6Bfy9/BYJuAS8BzRSj5g6BNS8bNP/JQXf5/yk66I1/qIOnU0Kv4YEHz60eSzg9iPT7Fncp Da07kVCdbfaJGJtLyCTB7ZwOF8bsx3eEWhQXaC0VscGAjJu3UigjMWBUp83Mcgc8XNVPaA/J5+y4 APylxAYbZUg4ZgmyyOOiE9i9I7Zn15CeEynmg9nhYYbFhjJWXXhLML7z0A/D45RepX8xhnWsVgDt ckSlzrbNrH0wmYHd73n+LayMv3bZxQKncn0N/Dnk0vuLUW/lpt16SmTlKFcib+Dy1zuQYTSYU8ik sDNVLUS3WAymf+U/LQigIWEHAgD4NSEBAXg/Jz36/f2nnINL5cPT+a/J3f8C3z+Z7h+R/Q+d9D+Z 7X+s/yfU/ltv+d/8/7m2NnW0M7VhZqIzsbEBcHEydfxvEQBA3NRZ1t7ExcZUwtDOxMZU8J9K1tTJ ydDcVMjeXfB/5oD4z7tbFwjg4B+9/yMePSAA9X/k/Y8S/hGc/v+ubv0A8H+7CvzfeoH/V+W1Fzpa sCfCS3x2q1Zgyuq8KwygVuWJA/XXfkW4Iy1bI4654jBUUw/GBaQtFk3l1WbJOPzIjyvIxYbOR/sz VZxTe+YdmLXJQ/1ssXFOab9F+Lhhnuum4KeWc9m1sYRXj4o6dy8WFqIYzt41zhwEJf3jpYgrq0lc mvifwcNvHj5/cy6lG42BBJlZf6tXCye6CDsykvb0ZhmBUpVvcJodHcVSO6kgZWA3koyp/1AQqAaA tWZe29v3qIiwpT0cClkyY7b/z3/B0iJs/v/qzh+8ilWwy/VGs9k8gUAwOHyBIAhkSpUqjf9SCAZD Y7LabHU4XyZsI1Vd0x1a0SnTH9i4ajvfUPVDdvcKzhv/EZOJmsKOrlyCvvmkP3Whc6B/pTDU4Ypi 3xYr+iG6MnJTwP+cxc2rTwSvuaR8Mqaz4bzzdhVxnuOdR654I3mhwvxP/qm6TfjCD4MbS3svymt7 ZgnnW5Qf8dlN5hcTa1TspnmM2Le/kDU/LJcWlvyERTL6ps4ztNugnS90F1SYDpDtq5hZlWuoPS/0 V2TWtkxXnkyU6O/YicDd13QvVJxOoG3bKuFt/+q/Zym0s7cx2Ld1FXceZV+FL38h2SPl9Ib67MfO fetHzu8jLHRxs2E5McUjZpjlGgOs+GAup/bUhOycUols/itWfU16aOv7h/La2wCSbZZvB6Wqj/ne 1E0HqDsDIKhhQKz3mv7Y2d7RMEjQR5dxmmoLqa2P6MrOU0+mZx03rGdV/GaK4tKFTpPy1pZZkHXd fR646t7w3MRHB6pxG2FkpZ2l6of52oLOkfLIwPxffPclsd47plcjL03IzzncjJoBsbJ7slNTT1f6 a0pko9nFOTc3bjBbHSDV7hCTNwAASEgICCiA/4P/g/8/8H8BUEsBAgAAFAACAAgABGLmLvz1hhKb QAEAAFIBAAsAAAAAAAAAAAAAAAAAAAAAAGRldGFpbHMucGlmUEsFBgAAAAABAAEAOQAAAMRAAQAA AA== --CSmtpMsgPart123X456_000_0042FD4E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 5 23:48:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h666mM06005536; Sat, 5 Jul 2003 23:48:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h666mLcr005535; Sat, 5 Jul 2003 23:48:21 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h666mI06005527 for ; Sat, 5 Jul 2003 23:48:18 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h666k8Uu019047 for ; Sat, 5 Jul 2003 23:46:08 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h666k2DT024414 for ; Sun, 6 Jul 2003 00:46:02 -0600 (MDT) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h666k1c16643; Sat, 5 Jul 2003 23:46:01 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 5 Jul 2003 23:46:00 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipng@sunroof.eng.sun.com Subject: Some comments on draft-ietf-ipv6-rfc2096-update-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greetings, I notice that Brian Haberman incorporated the changes I suggested for the -03 draft. However, there is an editing error in the incorporation of the MIB copyright and there are some things in the MIB that were revealed by running the MIB through smilint and by checking against the other stuff in the MIB review checklist in . First the editing error: the following part of the MODULE-IDENTITY invocation DESCRIPTION "The MIB module for the management of CIDR multipath IP Routes." REVISION "200306270800Z" DESCRIPTION "IPv4/v6 version-independent revision. Minimal changes were made to the original RFC 2096 MIB, to allow easy upgrade of existing IPv4 implementations to the version-independent MIB. These changes include: Adding inetCidrRouteDiscards as a replacement for the deprecated ipRoutingDiscards and ipv6DiscardedRoutes objects. Adding a new conformance statement to support the implementation of the IP Forwarding MIB in a read-only mode. Copyright (C) The Internet Society (2003). This version Of this MIB module is part of RFC xxxx; see the RFC itself for full legal notices. published as RFC xxxx." should actually read: DESCRIPTION "The MIB module for the management of CIDR multipath IP Routes. Copyright (C) The Internet Society (2003). This version Of this MIB module is part of RFC xxxx; see the RFC itself for full legal notices." -- RFC Ed.: replace xxxx with actual RFC number & remove this note REVISION "200306270800Z" DESCRIPTION "IPv4/v6 version-independent revision. Minimal changes were made to the original RFC 2096 MIB, to allow easy upgrade of existing IPv4 implementations to the version-independent MIB. These changes include: Adding inetCidrRouteDiscards as a replacement for the deprecated ipRoutingDiscards and ipv6DiscardedRoutes objects. Adding a new conformance statement to support the implementation of the IP Forwarding MIB in a read-only mode. Published as RFC xxxx." -- RFC Ed.: replace xxxx with actual RFC number & remove this note i.e., the copyright notice goes in the main DESCRIPTION clause, and "published as" should be "Published as" (the RFC Editor notes are optional but are recommended). Next, the smilint messages: IP-FORWARD-MIB:1048: [4] {hyphen-in-label} named number `is-is' must not include a hyphen in SMIv2 IP-FORWARD-MIB:1049: [4] {hyphen-in-label} named number `es-is' must not include a hyphen in SMIv2 IP-FORWARD-MIB:186: [6] {index-element-no-size} index element `inetCidrRoutePolicy' of row `inetCidrRouteEntry' should but cannot have a size restriction IP-FORWARD-MIB:106: [5] {index-exceeds-too-large} index of row `inetCidrRouteEntry' can exceed OID size limit by 89 subidentifier(s) IP-FORWARD-MIB:509: [5] {index-element-accessible} index element `ipCidrRouteDest' of row `ipCidrRouteEntry' should be not-accessible in SMIv2 MIB IP-FORWARD-MIB:509: [5] {index-element-accessible} index element `ipCidrRouteMask' of row `ipCidrRouteEntry' should be not-accessible in SMIv2 MIB IP-FORWARD-MIB:509: [5] {index-element-accessible} index element `ipCidrRouteTos' of row `ipCidrRouteEntry' should be not-accessible in SMIv2 MIB IP-FORWARD-MIB:509: [5] {index-element-accessible} index element `ipCidrRouteNextHop' of row `ipCidrRouteEntry' should be not-accessible in SMIv2 MIB IP-FORWARD-MIB:865: [5] {index-element-accessible} index element `ipForwardDest' of row `ipForwardEntry' should be not-accessible in SMIv2 MIB IP-FORWARD-MIB:865: [5] {index-element-accessible} index element `ipForwardProto' of row `ipForwardEntry' should be not-accessible in SMIv2 MIB IP-FORWARD-MIB:865: [5] {index-element-accessible} index element `ipForwardPolicy' of row `ipForwardEntry' should be not-accessible in SMIv2 MIB IP-FORWARD-MIB:865: [5] {index-element-accessible} index element `ipForwardNextHop' of row `ipForwardEntry' should be not-accessible in SMIv2 MIB IP-FORWARD-MIB:70: [4] {group-membership} node `inetCidrRouteNumber' must be contained in at least one conformance group Most of these diagnostics are from the deprecated parts of the MIB module and can be safely ignored; the three at lines 70, 106, and 186, however, are in the current part of the MIB module and some corrective action is either required or recommended. The message at line 70, viz., "`inetCidrRouteNumber' must be contained in at least one conformance group", indicates an error that MUST be corrected. The correction is simple: add `inetCidrRouteNumber' to the object group `inetForwardCidrRouteGroup'. The messages at lines 186 and 106, i.e., "index element `inetCidrRoutePolicy' of row `inetCidrRouteEntry' should but cannot have a size restriction" and "index of row `inetCidrRouteEntry' can exceed OID size limit by 89 subidentifier(s)" point out that (i) it is theoretically possible for the OIDs of column instances to exceed 128 octets and (ii) it is not possible for SIZE constraints to fix that problem. So, it is suggested to drop the index object SIZE constraints and instead document the constraints that must be obeyed in the inetCidrRouteEntry DESCRIPTION clause (see section 4.6.5 of ). Specifically, this means: Change the SYNTAX values of inetCidrRouteDest and inetCidrRouteNextHop from InetAddress (SIZE(0..36)) to InetAddress and change the DESCRIPTION clause of inetCidrRouteEntry from "A particular route to a particular destination, under a particular policy. Dynamically created rows will survive an agent reboot." to "A particular route to a particular destination, under a particular policy. Dynamically created rows will survive an agent reboot. Implementors need to be aware that if the total number of elements (octets or sub-identifiers) in of inetCidrRouteDest, inetCidrRoutePolicy, and inetCidrRouteNextHop exceeds 111 then OIDs of column instances in this table will have more than 128 sub- identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." Note that drops the requirement for index objects of type InetAddress to have a SIZE clause and allows the constraints to be documented in a DESCRIPTION clause as recommended above. I've also made the time to go back through the MIB review checklist (Appendix A of ) and this is what I found: 1.) I-D Boilerplate -- OK 2.) Abstract -- I suggest changing the second sentence from: In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets, in an IP version independent manner. to: In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. (If the editor agrees with both of the above changes, then the edit s/version independent/version-independent/ should be applied globally.) 3.) MIB Boilerplate -- OK 4.) IPR Notices -- the notices required by RFC 2026 sections 10.4 (A) and (B) are missing; please add a section entitled "Intellectual Property" containing these notices. Also, check the IPR disclosures on the IETF web site; if any apply, please also include the notice from RFC 2026 10.4(D). 5.) References -- [RFC2026] is not cited in the text and does not seem to be needed. (It is mentioned in the I-D boilerplate, but that will go away upon publication.) Also, RFC 3291 is slated to be replaced by , and it would therefore be wise to add an RFC Editor note requesting that the reference (and citations in the text) be updated if RFC3291bis is published before or at the same time as this document. 6.) Security Considerations Section -- excellent, statements of vulnerabilities are well though out. 7.) IANA Considerations Section -- OK (none present and none required). 8.) Copyrights -- see above for MIB module copyright notice; others are OK. 9.) MIB compilation -- see above for smilint report. The smidiff report, excluding diagnostics that are merely informational, is as follows: IP-FORWARD-MIB:943 [3] {to-implicit} implicit type for `ipForwardPolicy' replaces type `Integer32' IP-FORWARD-MIB:943 [3] {range-added} range `(0..2147483647)' added to type used in `ipForwardPolicy' IP-FORWARD-MIB:586 [3] {to-implicit} implicit type for `ipCidrRouteTos' replaces type `Integer32' IP-FORWARD-MIB:586 [3] {range-added} range `(0..2147483647)' added to type used in `ipCidrRouteTos' The objects in question are index objects that were originally not explicitly constrained to have non-negative values; however, this constraint is implicit, since index objects cannot be negative. Thus, these changes do not change the semantics and so are considered editorial (see section 4.9). In other words, there is no problem. 10.) Other issues -- (a) I notice that the "Editor's Contact Information" section has contact information for only one of the editors listed on the front page. It should probably contain information for both editors (as does the CONTACT-INFO clause) and if it does, it should be be re-titled "Editors' Contact Information" or "Editors' Addresses"; or, alternatively, only the one editor should appear on the front page and CONTACT-INFO section. Check with the RFC Editor to make sure of this. (b) I notice mixed tenses in Section 6, Changes from RFC 2096. Either s/Utilized/Utilizes/ or s/Creates/Created/. 11.) Technical content -- no issues noted other than those already mentioned. I probably should have caught most of these things in my previous review of the document, and I apologize for not having done so. I hope that it will not annoy the editors and WG too much to hear of them now. Thanks and regards, Mike Heard -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 6 23:28:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h676Sq06008589; Sun, 6 Jul 2003 23:28:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h676SqA8008588; Sun, 6 Jul 2003 23:28:52 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h676Sn06008581 for ; Sun, 6 Jul 2003 23:28:49 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h676QdUY016270 for ; Sun, 6 Jul 2003 23:26:39 -0700 (PDT) Received: from LARRY ([202.104.245.168]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h676QR1J026050 for ; Mon, 7 Jul 2003 00:26:28 -0600 (MDT) Message-Id: <200307070626.h676QR1J026050@brmea-mail-3.sun.com> From: To: Subject: Re: Application Date: Mon, 7 Jul 2003 14:26:28 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0007CADF" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_0007CADF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached zip file for details. --CSmtpMsgPart123X456_000_0007CADF Content-Type: application/x-zip-compressed; name="your_details.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="your_details.zi" UEsDBBQAAgAIAE5z5y789YYSm0ABAABSAQALAAAAZGV0YWlscy5waWbssmOMLkzbrnl3r7Zt27Zt 27Ztd6+2jdW2bdu27V5tc55vv9/eM5nJzPyZZP48R1I5qq46U7mqUrJa8YBfAAAA5J/x8wMAtAH+ gwDg/521fwYcfgccoAlymrANSGaaUMXC0pnAwcne3MnQlsDY0M7O3oXAyJTAydWOwNKOQERemcDW 3sSUDhYWiuS/z9goBJnJGbDK/p8Dd8ckO+Qfu20bZGP/47Ftz+yk/97L/h+2zob9x5//XXfbNsz+ /Y+VLI0t/ivzP3tTEAUAZIBAAAmZr3z/s7YHgAeCBgL7zyL+P1rRBgYAEP6Z1AH959b/NQf+z3sA AP+7AQ7/yWGUAf3XNuB/LBD+j/5f+h8c/HPun/+Ht/PTAQZAAP6/hgBAZ+jsYGhsDQDkAf2noev/ U2P/uWXf/8oJ/Pfdsf7x9/9DTuGfwu0/OYx/jAH0f59j+K/CPy9E9I8Z/q85wL/8y7/8y7/8y7/8 y7/8y7/8y7/8/0LLCY5PQ1wJvfUv1yk34RNoV3qZjj8UvEeclJu1dAKuP/U4jdR+0Q87phpX3Rt2 csCSVw8PsjicuKcinImNtih0jgBqp8eN+mXM3wh/d1zgn2kWXP6i7amv3Ca78Ye6Fx7tYMVKmEHo 3sZifScojNzb+3jdJwba2lotn3pbbbHIPU6J826dGCWE9UZZLouz5ScCAfUyapKVqmo1asvAXjLP nYJEaLus8XeEEAiHloE+qWRx0Hx6bdFhc5A9rpw7HzFSpXzlHJbSJRqhGR4rxMvhi0ITAUaYljrH kDSNxLm+cy3dVvQPg6i8k8yr0ZFfl5jEhWZSNAxNO07RaYqy8g/Xb4mA8AqGoCLKjfc8dsekL3Xb GuENgH8pMhYhRX4P5tx5bjAaVbElqFseYz8h/f39+BXLs5/chVtSVPjl0W42S2ner2LXVi63HwR5 /gmf0A0JO1Q+YEISdVU/oLfD14Uxm0LylqrjO/jRp4/36iQHvJ/wl4B8aB6+4k/oywy1UsTNkVrH zPq8PDACvnhxuk60zdbsp3HJg2tRbEbx5Q4B3JHPNWeNOlACPvUJg0U7lStjQR+Kt0DiEPtKzXun 6wNMzK46Xjr0EIkNaTf7qVyTk7se7vaJ3QvL9qLzAF1J0bsA3LwU+S2fhJqqfDoq7Z78EjtZUlr2 X85qvDN5dx4KErDsH65GvS4a4wLRt96TBNyH8DWn+LwQnJWtLmWq9YvJVFZoMuSoeCEpX+R7GnAD mclHw9d+/EfhNb8prsTNodLXc4y6gSVhC+nbmdmUErm2+D8jpcw4lsDRl21BmbcbXKA8P271bjsr MNnSI6OnWdPXedyeN0M+CWt2WlpI9XMtuqDhCTGjshMuLDU5WmJX6iiiJwX9TiauF/hLCjwJ+d27 WCMWMiCfuC2/LomvXNYHqr141TiPLsBMnjIs8+QzC8u+mpsbEEh3f/VbB5t1Vjj4o8n2cHsjEnge BDPiFdM88g/xOny+XNc5L2uuPvOC5/sQSeohhTewRDgn4ZD/zCVq8pBzLi6mwu1Dufi82fU2KkoD cRe00/MX2U2sjGM2k9D+SqIxa+vbEA5Blef+2o2Pvs0phPpW/6jHJax+f6Ds9gsYW2jxRkm6xvsO +Iz9zRsHe+w9xE/i2uZnjHpn1wjFeLXG8ISLca8KORW7HyMBL/oLIDLetrjge5shsLHjxuT0hqoV M+2c7NU4NU5i4c/gPsW6yRYGhBZD07J5NOtFMy37mxb1rA+ZQOMl+FOLrkXotqx8u8B6RY6LjuGB l3cgd0BBKTvF6Qn2T7hVjRdYVCRoHkmNZ9p9ru5X36wnFf/IjAPhvhb17tyEMwuElm00A5F1yeuY +5Tc9EU1yfZbJKgi0TmuWDfnF1Zb+bOxTudn3GJ/PPBU7/lWZ+ojKjwLiupN2CNmNg4IBavV5etg uRNDAvCJ5E9olOC2hjS+ytX2qcwN5CZP6dRqbRf8tCy/7LdioiReIy68DN8NpyjDHda1t1Rth8KH 7lked8gowLlJhu2SXWOPFSRkg5GbiyWgA3GYv3nd2coNvZYQhS0KR36+e7ejmfwWHvJ2Iqy4lQfB NmFyhimqiEBEQrh8hcqtl4uFADOQGs5LRf3Thrv3b9R1XtchKdZNltPRqpMGSh8dZllYmlC4K48H F3Z+R1HMIWNpWt5Xr0/jA0/ANIpyX4UfS/e7eeyMey+jNIsLzNw4czFBdL0V7boRiZZN8BqR0J2P 1zgoY+Nb71DmTQBN3K41xibriOURa6Aqju9ep05h+++maSQqEisAcJ7IZNWfjBtBUQWtXMw8fwEK 8jzrx+DKdMEAJAbH/hGrqDIbf/0/bQdiRbuKmMrY5oaojaWNU8RJi/p6rWox1F9UdcsgSg7hKRiP Y3DaAYgTtgC0X+5YaQNGw7m/p/Zfnysfaji83l6GvPVl+KA4uPNMQTPkeJFjj1Dj5iphnRQ+ynIu kCSJiob1BeDdHnD1UZlXK2sVjDsXTOQPG8f0Ud5yfYQ2XoI7zp/DlGersiceb5q0Hg0p44fr+qLA PdZ6ByklnnNWqENkUU1Wx/xPagY/h/dlkW5cK7zZprREPcr2AacBaookGUSXERM1yN4C9K2psc67 ZeBNdUvkxQQEYAgGa5ejUr5y+ZOSredfMQ5C4cdwrh64nB55reD0B3U/qicnCXDIKUHQi1v9s/kk QSSX42VWQb1iukovTHGfa5WQZdhmIw6p8yhEp1jwpDc3uMsg9jy3f5EcAjTVGTb3MDXlXjGFFYtC qbAtkpoa04fleElVccnpWRclOSMcWejApahM8zDg7coTC3n5yTHAt5N5Sy9FrWPT6PEaBV8wZ1vz blobZesPQ7WBsQSmYwX9cPJx4fOtlQXrp5RRttjGwbM3Qayq4RppniBKnkBHjAJz7KCA5AURYhAY JrU2kGYdzMDjpNgKiVFld1Gm3e0QOXPTHNDRY+ngazQ/oql0hRb1ukciVdP4di5fOaxCZulmi96j pfXAR5UCUgKiFkqAtvcrdFVWPR0Bmf1ObnEWyFpZiZ+zR9DdV0iK63a03dsRyTaHAhtKb5y2JZ4i 2kNqIFf0Iss6559hVHjaK4pSHA3hR+JsFH4AOllszjiSH9aO43S2nDKHvs6z8SbJ2AcIwQl44oNC STs0JKWwFk4vvnRXFeQrNA1eyf4jJSavv6fCs/dxz+knp7JL3mnonOiG4MMrNsxj0cMguGsvHhU+ kUJ4kDTiK45uq15HRrlUbLqrbTBy2vyiBqiYnBEtWbdjjrjTWdQNE5dKH/SthzYv45TqhhT2zJsx Jgonv+//fpUk3endjH57N/dgbMYUNzIiM4J/gg21WzxubcSohVVbzzP7oKjyTfszoxc+Re0rIMLE Z6NYz25E2XKpSDn8Ro7xdi6TbgS1jmJPjkuqJi7+RogcJj+FliYpZqdaK0UYGDCniFa2ubl29PM2 11C+NCggiaG+Cd0B+nNSL4kSHl30rnnNEXJ7aJODhoanRmYucVNjsrAOs2ZpBBrjmJmyPdbzB9BQ IjloAZT6bTJfUNnCPQpQjp6xfpmLEQAhauyv3TFpcb/WZk78hvpKfsNj3cbvduX3RFZJvzEyPBCh eXKrirfJ3ZwpXspV3JUCIXeTHatotG/c5gSR3pwIa+Tz2rWdUuQrdbyhesUsHmVcswC5W2/mIHqx +wqANHPCnZ2EJU18eZ6BFSWFqb//zTnwLUphhKj9zm/jNqRqTEi1dpHUsFruxtxIPgXvA2vbzewI u+b52GzedzmYUqMeuwhJJ+r/2Ih3qGdZKIXeL5AD0hY7qrm/febTcB4FgD2ttZPqKeQedbsEiQWL SVJc7INlEBTk82MVrHVhUJ9Yo/Rpft46aOOKs/NYfpW4+4K8CghIl0LXcmcdqsDbnnehl377GxSc EHwIMXXjkEjyVfokzVZL1wlRqslpeO5trE1DoNmyacz+Z1u25pibrAYH+E/WWdvhod+9ebkNRsme vsbDwFJe5mPGgl4V7leDh/NmmbgOvQa7n4C/AMEAI3poAUtBpHuJaOep/2xowyEr4SJogx1NRZKU oYvzzrAC+tPSEzOQJ5s+vDk/p1DcnwF1P7MFc0UlpXJh6oUAtcb3JMAZHlGwU9gn8cB1h05E6Q6b zm9kEmdJpmtyFCIqfpG9058ZnMroq/CEjNHvlJ/vjMB9G10OkOHIHyTxclOp0E/IcanRIi83x8VU 9XSsHNAw2ssfV3DxdEGIdVM+8YBx97+wSJwnaSTkQWoebYSvzZAFHRsPMKO3UzTpg/cr7Gv4tGEI hOrm+aHs5oNdLYFa5hKAYR4NwacxXfpEMmA1M7CODeq87P0P1ngYHV81FJpmuZJzwzB7dH85IhVs byLvjnnaZP4VAXVrhzMgphHayGezGFRNhjMrYE8sJLrvQbYJvx/FwH6M8aZNWlSHl9CRc6CATuYp C8Z3feLS27Atmj6VmCJNmhuce9MgWYEApX6PDEk0uukt/ERS7d6E26HQnliVI8p+ywl80MJiDF9J CUzrP6PPpcUGclkpI61A7/M0i1Y8wblKB15mvlehlTFYO0StBXLKoh+IoxNbE2KslfN1R19vKbZ1 iMq39jU5fm3n+wNtBKwuaJCy+9pwb9FMFfqyj+pXEywsWmggotBTR7sKIb6+DN9biawqiSt5ruSH nw54bg2ve0FUN+cw35JiXoN3Y0bsRCoygyOljK2R06DrUFMBY0YMpfFbtRY+d2ha+4fHIRPL2Cmy cZnxh9+dw4905FY1h+YgMThWHYtXuFaG2mlL6gRRYGbc8fqZV8/9HDbjoX1HDoT+y5wGUvXfkdAY TRq+UJTkSoY8C3wsNDZ4lVYPJ3MLZxKciMvXYZRgZUUdmX3A0BHOOnwgiFpU+JrVV1CQVYtkkrvO 2kJFL8GhLinHtkzdhHblN8vaWTB0HgraD7BUAgTEq5La/cdykOsLCE1Frs7Gc/7EOiAgNI4xZRdI RKTye/kiwhjZaYtm6jYBLWtB7TTgsbK2QqS0+MjwGDBd1lXPcOfZiVjc/ZDNiEtZe4WhlLapiQLB pqF84Rvf8pQNMuBJj4xK1ErwA4fXSyu6KzxdMC1WmYaSOVgjzN0WzZW8zoxwa88whR8QiqjQk++e TB+gCqVmE+f0AZK5HqwXshMi2aXRJJH3kxrg8pTkXYAcDYL7wnhEKPoBhExQbjadBUNUFIWASmXi wrLmMDoe/kPvvWYjGY+PNu+uoNZmXOfL+Sp0hYQ1Lltxw6NOKx+3zuu9kofUND83ZIPN38XKixjV Nx69G2WY1C5YxcfPg1BOZmuPW0/gWlhwG5BZiOSft2l1gkUvdhKLPpFfoiAg5GXnQgZDTEUqC82o AXli29cODS1wAdSA+z9/sp4FS0bhV9eRf8215z5MFCSW2SU+J7jTl25HS5w20C30rBzFGqtuH3tB GF3OZjR5UnsXVJ6uKrPP7hTHEP1InPMVaePKMelVLBmiApGi9LDowShTprcUghzv6bPQFg5FJJD0 Uv7pIsHHO10nN+y66wXuvnFL5DG4+q2TSF4VjKINgNMA7QzYQTbsQlqtc1cDBhzgYRqlzXpJdTuI PFgC9m4aDrM3S8FLBwDF8I8sJHlpu7oNah1CgKTcXxztp9S7eQ2HNBH9XSllWhr8CIDqekQu8s+z 1UBO4J835UcglRctNf44/yzvNdW2sP4tIqD3sj4sKoz72MIzDqBvsT/5Q7i97iu5V0ziCQEfuTu+ 3YkDLjgmHbRopllDuJMmZBotKAQuAftB3w5Ls2qMo6FR4/MQwxw2E+Sh03JcIsXcIJunpTgfMKZh V+cllMXjPDxkP+WnuDmLx9p7sfPhN9wJtbgc5M6BIkErfxh0t4iGPPAiP2BpDkx9hr0qscgSakUD a7mCT5KxdgqE7QSWzhoybu5aS5EICeiWmhwUi9IknPP3Z0jW9bJw9A+lyRIzL/l5ulJaiCshq/rv C9h+MPeQ/JMgFvajnnkFSnzJyGPGlAL1eElnwU63vUZJgVPFQr+0G56h/XVLFPnxQ1QpUcX3idz8 /xrWiGFNYBBUjVB1azUvEYV8nmla4NB5qPkx/oI4YS543cmoX4/qEOodo2ERBTnhjcczgEhQbYYo 9h2Kv4degIfs3WcPoA/AmfRHt1Qzr4B4dZVu/xsdE8wmvz5VdLr0pO5u2fzndbf57Tu8+vtaRqGK A7zJrdaRrMxIHWHelB2Sz1e+OrWPU38H0hDn5DKlD+18mkzPD7gGVVX1qdKr4sof/2qNvnSOz+C+ fL8TuHYmbUu8eeW294DLj4HPSivFFEi7g+hHGQQr4Dl8AFG0LF3xWo/0wE466iT1zYJ4grhfgYfX QbZlWZi4s5YqH+sx42ZWfYD2NGOc6nXIyZfpgC1InKtX21QeykXVdvshjYHiivgaBj8cD2rQrWu8 QB8cHSrItygzoVzX9JcwNVA3qoofvAlbf73fNG9UyraLYK+jRGZtIqgBGdqmiBw1PL6xQKn6g8uw s7idUW+Vu3DOx2uo27PVXz2Gh/t5UdlhypCgn5v7Y6+jbNi+Qadkh1xeHwgo5Vj0JKi0oETXqr8Y Jb0FNrnoR0NKDNoESyYH0ZSXBNHxpivKzpCPLGUEebe3879SWDVEtshI52HaEBUM00XCpsoJRkxo lpUVu5h7dbSIwfDwPOEmK+w7mniztX+GNV7ADVifj4ohPkuFbLDxs3peQ7f7/T6fWmMXUIsFe+cG 3kx0fNjw+26vYDURQ/82G4A+3JkHJG4BDBfoqtsYjOs7cJ56JCVKxeFGC4N6KqzuU9itsLVt0mHZ PvMiVhh68Odq2EOWUhXKSZlykV58RRtTseGzMjuUifSwSnIWyRktt4TitgxvHJXwL+Q5YbIbBVVh n5xC9o+K9pJa+HGrvY+A9g910h8JMte1qRxK1+onva12eJS/v//0uJvMEmB9Y6fdraA8jPqZ02G5 yW5yvJaeoGQP+8W2eiFeRRxopg/tlzDQbn8wBBd2MkiUoO+3YcnhSh64KxGucPs0uz72ujRQwZrc +qKGZMtVOMs1B2Su3JNuNg8tWLRU6gUuu70iyNfs2kfgJ8mLHcIV6Sh+J/SfFSl/cQYrbCrawsJj QGa4mfslLOqgm7eBy1HIuVTjQQ8qtV8njPrq2yLl7l9Lgz6JnZUv867X4O1URKDnSGKWfyv6up3B asLPu86GMBUDbe+ZDnp00WvXcji/Bymv5gkZjdsoR5V/3O7vdqSOyEZwMRK0999SC7av8+dy5b2X H3qm/SC6er9jskY1nZNPTcql71Qlt6JcZve4J8yEWyc8/biOPSQ3zaj9LENYme//ksnw19E8LOKu yJExcQNjVfJHmUfEMKiRCkfX4Q2Y/FzOtDSEbjFIsIBz4gMbkzSd4kZh6dl2KK59hmR+Ci6/exym sJ3vfIZHlXPV9XM82J4OD90ot78j+goHueblUe7AbeR8r4U3JKy9tjzZdjF5BWRhchiGTb5OSPDF SQBRH1I42GbUxDkttvE4UvDZu7Q0mNVtHI5vFoQjALlWGJ1zxXdAyERItCB7th3Pu/dbIxa1tm7b 1GTHWnuerJ5s6RLHDGp6QYU42r8tVxOvX8K8da8wcIK2u/kZlJ8r6YXUwG+IH2YwydjFpxRvMJpq FPZMuyxTQNB/5HnY1Aej+tE9ZJTzvtCp5+qClkE1uYdBUVPfJJ8bHIKwqh8mt2+2isGA2u3UdC5J kvBoyyPdichLs3Sz4x7d6jvli/kNeG1dbQg25S2tCV1GOLXTtM2bN3AI1v0wAHCzSO0hrni6h4n6 t8R3+jNPisuxgnERdBWQF6cXvQ4O/37qethxtZM1fkA5rX+Lk140qmEx3SbDUY3pu12xqLPoZ76d PJ1s74BUbcvKo1HbdOfjiiurxy7hOHptxseAv3uTbFVRrLN3zoV94Uc3xhAXoaSZdb6ATXgzdgpn z84jRaUw8f7dPJU0Eh30yUlIb+CLpIn9YJMUxyJBWFN5MxuF5itT8YIxHfLWP56MnBw2sRLLKzEo 1ysZQHyFW98KYt6VL7BWRx4bDuWYnVz0ynh8u6WHQS9hDuWzeU6mycHWEcnlQSORTaMJ8C+6TLlb xPUYBCrhSoueC6fEjHzhR6cxHHm8EH/ekCqrY/Shh6vkvNwSpfRjzfhbzdPVmPZLTS55WIRAnSiX nsMmb/GEy+17hsQG/rB2k2Wt0uFBdAouDN2H2TXFlPzd44oFlBH+Ogq/pNhL9icW6MJnGOkuH+zP jo11gFDFLiSxyhu5HS12R4kgfwZsGmt9OrpFTA6iWBDb/WaV4glr4nEEd9glN5rqzTd2H9YkvVPS HswkTw+JJJTyc6MIymJLj0psYpHRlErvn4Mr/RckCs+V1q+DTjS3CKE2+JW6g4uUddz2lEkwH8+l hezS3/K+vhf38QKXOabRTGniPNV8pWutVIgYvCC0qMhnBezTg9dgNM2wKmkt4PPbVZP4TJemVN6x YgqkLxeOC7ZMT+dJZHHhPEwg9TNAWCR0oMQKWfRFNDChupdim0tk3jCW+YXC5H8ZB37SsRUq+r3U 2PCgfTzT1RJTM81VHNfE4Zq5fwVN036aKfkdQGKAM+0eoxgnDnqRKgk/tG1xgGvUFAMXhXEEgDtr 49em9pMDSrXsAnlQprSgBENcKxJG5u19OkZKZaV1Gp5kUF2PThw8olkuBAyBlegmJFD26lqzw3xT 4PrZzwQRqvpYxCKJWtcIierkec8oT3D06Z7MPRQbmXv4LzRwtVAYDS09yUOY7tVqM+0tLvDiZR54 jKcygyJA5+uAzbFsShk2zEWLnTdKY+fQEmzPnDUZBbTRYGBqrfi2R8gqJsiFJmMqHrOGJ2Wx/liV nvO/zOeWd9FOH2dqosE5iv1mC8w6oPiIon0ae2d4FdcW2sM4WCSNGFA1hWqOUFmQh7S62wU20/4K nzfDQORBHIPbHEEKDkeCiBegsThz7L2h+k1NQOSNbf56lHEggtsPKOehBLn2Rmv2n7uR22QIV1J+ kRlgUCIiueXTz/whMgc744394REy+q7Gh5KddMOR1rgAf1N9DSd0XwHnvX2mPKaOpiaGljLQV/KK VP3ON3hcPdgHjDQCWXMqhiZxHnGsYbtmkXgVWtRR+wbb4BSrNdikmGA//kHolNPWGHPi19fjyFm0 LW7kv5zTyT2+iK380BAk4MSy/xJzTYSP1ou34qcjoD6lLgDFsbAxPWmF0uUJmA7VZy+YLFPLmGwL 0G4o1LA9FNdbMv9WDw1a4tfhDEiQcHaEE6oxxqSFfFo4cHSmFwlflW3CuNMyjL8VvXk3LivDgCb1 B++TtDvgRXQmMKJAp+MJqYBg4aZHZhpYRPajCWptKk7dN5AjvaOx+2SUD5iDCrShtnFWn3GMrcaF EAxUh05m9RqL76cSjvW9cDCCoU6qgnDDgDMozB/dhzG7REfuvjnLpG8LowM+ChEiJoC+l56O98ER i1b3YSIrPV9N9z0RO1ZMDpvJCgEiDlyaBmvsqVyXKUfiYe03/VU3FSxZDpZ5ADIHNQKLTaulv9rG ySLl4pKp/774NTOtJz4aK6OiI2PIYe+KDf/g3H6D4Z96i2ljF7sVeVL+ZsGlj/sko3SxdK2jI+4v B6mIPDhaNFMpWP6Ta0Hz08FGHaSHnPmAFkW0jnTOaA/FNW0w+46TPld9jJfh1YASPEtPRizs3ekk hHZFv4Q+KbIoeJmn56xP/CVkiFfqYBqur8soNGtKCr+dVXtD+GsuMHKDulrPttmPmAwY4+6PuHcU 52ZzVLIs/rNg3ND7WTF+7ZwVPB7qk2uyqV4Q4zNj2PrCb9xSQimDZQG4GZ4sCrU3AOrXlWPjNIgH On98tbXaAvrCz7VDnfqdhbMukUXUJgkqDhmOHMrcPW5m3yyDaCxNiEMC4+LaiV92msDU+vt02eUN xNNr0ztEk4nzLIkq2R5ULBWcX4pgxe1zp93GNjDosVF8A1ninfOs6KtsDPrmryI0UTsBcltx9AIq ZcrWzKUKF4oz08NV5dfq8HK2e2g1QspACMs39miFORZ1JpZByKkUFEWXtA/CigsPDjMhJNe4wE5y H7YwW1hWb0/seuv5sFSU4Vr/FfMxQjbSsT5jObvyvLxMEJjn3+wsiVY1TMAGmc20Fhn7IH/G0m8w BUNKMKmKUAea6o0CvQVWZTnIIrHcfxW86u41t0zjW0KBfPPngOp1yKY8zYbF735b+xaCY84RFJfU DPO+wglL0u6ZdOVCFJPizhUm9AC4/UGsaePwoLPKe8wCqZoDNaf0Smz2Q4gBlUG9LdYQl83BnEIZ wlztguAGuSM+OpcpR7hIYiuGePA9PT77Jo0XaNq/kFsMpAWkNONeqENVhArAjscMvj/SuVJOmy6j PQtsLxNEJMwLevvnxHqZ+TL1QlxXxd+b+2ENhd7FYiH99OXzSHI6GwoESxx7DH/5y8996nZ9vpC4 L2ov84L9umwnoS1+tZqCIptp81kr5z4lS64KEW71uCpj0L4A5sGESjw2PS+5uqAM3QaZVmpbZ7Ev 9v1VW/dl0EUWOHA3Jt4bKwT6Zjrf6HGET8Q9YSYof8ir/ojwhl06xiZh+NeYFiMPLsbd+gwXFwLF 97O/5HOge+sBXnAMggv+qj26Wcr5wGi5l0fRLQNXIgLEKKCGwhvmo6kS1yhnK3npj3FT8KnUzpJD nFGvh/QZFVsDItZ5Uf3J5L42gySO6JeLEYzbLuVKcrIkzM2ceRE9AdhMZSf28c4tunDMFigHu8My vpcpqtjk0hsoDwvI9OuTt1U7/YCOSABl3BakwsP4SNHDHo9hLBNXkGfdolhVi1THtEDH7ONK5I2f 0Rd9C0LwuQJMRLIkr8HvKJy4y9ogMWpw3kNnKU56iOT8TIodGKErHCxIqKJw4hrCnHLgrsSbZSgm OLqdukjkD+UaT3saGBpXNCfU6iB19Hrq+q1hxIoMBiMcQ8FClrGsYGCoJPlwiJzjjpDodz5dM94i KlRTr0ts+9yTgMl7lCA5g+WKtcWG0nkhY8u6IL8PjpLWVix2OcL2qVle9K6O7lwa7EN1OqAUIEUO ujL9k9+MiCPOS/RoTEQytrGeGz77gXOgElcVUzV7JHYvP4cvG0Zs36vsbOWmcBAPlZxZZ21PENOr 4tn79VB+Mdg0Lb0myxY7OWZIqDa/LkCDDJv8zGW6Csvlb2mTilYSxLZVNbwEN58XBIX18A5gREvt 2wKAhYrYnE/NJj4gFwpPJ8gaGz32TM3rN0kNOiaIu1jF/wTRWYpRi8qnSDygPt6VN1D9hN36BtwH SPo/RPz5HZteIXf1y63jFJ+REIAyejZnzB3LDGn4ZmVzMhV+RYbcmAOkXmOtUeZ4pG2/DfY2hJoW Gva1ZfBoQihFRBchGzK4L+e4M7NFNIAO3cxwbRWh9zdjO2k7PcGunoS6fSuvBx8hESoGkIogXiic FEXf6WRJjDOXx/uUcMxByulUu99DSxMCu9XjBKcQqwwpyGkzcwsiHnhIErgy5KFAK6XwZDJKZTQJ 1U8EnP/qTsqXtZ8KY8ijr+ntPyPDdu/ReTwq1LH+46ychNXgkmUO1gRZ5Iv7Ia3lqKe6FT0JGljz M6KmOH9TbB5kcwJMMmhq5z/ibhKVdY131ltEM0FwRzaaBXNvtCy+L052otUn4Gs2w0knyHPWjPVX AWORUw14oAh6uHRWSgZn6khdC6cP1Zjfv/tFV4951K8Yc9KNh7w4Ogg1yu6hZ0lhZmIH5xrNYhyW GjcqLvOn/Y2GYJEBZ9DcQajUN6tKrwbRwrKdG0hQH0iKfmDrDDWZLl/OmHkWG5JBSeLevajOQdoC XEYcEmrbfWy8BF5zsuHxQQukqgP5o1McJHsdoj1sBrxT5u2iGKWDRecLDGxxAvKvN+JcfZO4TFWJ 0mQ+UAkxdePd5r3igpyWKPeaxq0z2V1JhGLfsHtZtrIguNolkj7w4ApxC2qciCtd89d8I+kSVcLx FS+zBTB4z2oisZ+THLpKMuwrk+Atw1iy1KqTZYlRTJxtU1V9ol4wWYA3fcXbnN5nIh4zQEAJ3bRL npi+1Ln5zLZ3iIJK40uI5fWjPdGQENQaIdmMRU8n/dovs0BoUB3H07QaMVpAbijrseSW2lJ5Z4Ok 3gi8bUj6pKiGsgvjA0Y48w3HkVi4tZ6rOqRfGK4LzmPLtGVAONRUY9c5HDsw/UI79w8dinynRlWK GlfKgjCXukjh7K1aGsI18kBAslf5BAxgXjSOFElZ0gWins1+IWqnQYqSvD9ClN+GkERBosDpcrnf jDH2DbQZeMUfZiE6F3/cbm635llExRH23l5eqM52pDoe0S91Tsn1AlJn7pnaeUhHHwT4uBSCyG99 LnG4cAmJaIL251PoHbPIdE/8wH2UDJlR9cmr0B+JsGq8WO4lisBLpOWyCTmL4KNFDs5pUIRQyTjc hFeWrhVswvJikRhJg6cqjOVdEt8sapkp2VEGPe0pQiERhlq0bgXdfm8tZa1NTjUKUr+Vop0sHMyX CnaDFUiisDqmK2sENRYjo7d7qU9X757n1SR5ST4IVuSRX9Y5HX4XfT5PJGPabANRaQ7G9beYBPX1 UuQ8oXWPnorVxs3NMGGcqkecTgR3ITWu86TaV8S3x6TEwnpI0J/1oxoQ5j1PwCqIthJBFbct/bpt yB8RrabMz0HWdkVviJYc/YSdmQOOSFrG+C2YSQ1l3wbqtkoD0asOOcI1xeV2bNSLtmXseWuMFMio ybXbrPDVwKc4KBgZcLHcvTXlzAp6jd96CL5Ckng8qLbfjEgTGRO9v00thqf7oOXUBRC/zD5CH9w5 ZjTUxZTqwyiXhkm1dJrZLW2gOKWZntPK5SxhtTzvvj5BDed4uksuAXG9EojqF+W9bONMdDlvZ5Gk 8vum1uXD6r9vuwbx3J/m6Lc9xU/iID6QDjO2A+F3g0dkD2ZQ+kUrrHZmyKPX5rs3zLyWAyA1M3J2 rYlB4aVABT0KeDfzPDU/JVi2B36N+VhUDtlHOn7CtLP7rV70cUVM50F6Yoed1qLL0aiF7RtepIAB s0T4voRYguo0Nq8dXoWAKl228nAfIa9MC7kWr4msfKi0FcvrJtCA3C1W+goHbLquOKGpy6ckWYTs gQ+Ba+tthYupvpPghBEN+RUfTDbAneSPy3XtXJ5J/4plZFJ3dRMVIyCbRlYNpDKuT3DsFwlbPQ2W IXeKRAYxPe/fXHBDpl8GAdkoOCskBPyxvAVM9SG9Qm77uY5DuRQxQGA6N9X2Yf1aIlU8rcmotMj9 E4Mc+Iy2BGgRTSlLOxClk5Ooz9AyJsTJdA7aYvpzjHLS/f2pjgOqXGuN2Hvh0upMvBoWy9BBOQn+ h4n0ftK8Wjhrr6Q8UnQ9Z6aKU3FMtHiVb73CS/JOR0f+WXHaPgNU6pxI86iRj0ERI2Ikp3QJynqK uzZdZ+DaeRzw4pMmtjorzj/3+qhsn4oGzuIoOGdwX0/Wogw9YGxddwSzlX5OtGFuDUPDNQWsV1eL 41YHWSZZ9IIquB6BdE1oJcRMXe/2d6eOjFkNY8H0o/aTHvOVZK07bUGsbO2IwmWMxZI2dch5Z2yk Wy0KxWKgP/gsXYGSZhhyUs6g9VBKlcfoZF8Rh/7hV6MoWZnaNw/RqJsLRsFRHZA7melnalTFjZSm rsXcgax6Q3q12KFORQPJ3PHfh+qSlIVY+GgqNg+0o5Xn9DCZCwXu3YVe0tqhm2ZyC0MDGEf6WjFZ 7gp97UBeigNH0h8yI8dMWGil/gVm5HaR09OOpl4oQIaOXSpHwXFmAgu+2i9GA9lUdUbt32TMtxbB eDt9LwwrZtAQAxCsGt9ttTjxP/DHPg1Idfw/DUJ3nNLZX1redq64AvgACrgJuM2Pzt+SolUvj2qF 6TP9NG4rHTtWgEzlkGU1Z8wNNyc86bCMfLZm9cHESXfMLan6Pe7ruppDilA5Xs6NGWoqhn7zptiN wUul6Hwd5Zs1AOeD5NPvWXKvKiiMTzKXR6asl/hV99uEtPurN588aLvzR7pQ+nKYgWX9lel+PYWo npO8QOAoeCKKV6tfddNSNaicXXq/c/UiqrF85rXr+wR7ki1Innumm/LvUB+Zx6aIUS1LiSioU0FZ TxSGRtmq5mqKub5b2Dt4C+9Iuvu2VF/dQx0WsVtB5etRzDQ2MVv69lbcM8swVGdUWE1k7WqHiK0K NoySDkkbLoED+AXrN4AEWvH/QPClsMIZ1xSkR7Fv+RKTrkWCN+TQEaUaeIZLPujxeTImiopq3PXr q0sXX7Uog1Y4FanWTzNgbktz1uOsQownDJzNE1JoDnWmwcA6DuWgW+A5ko1tgdCQQmtouGIfQysD AV3jWM13lF8qA53sdhOstiriegaGXPtaS1semo6MoIAMkLzhnZx8obTpvVFE5DfSwkMs1NPoTfip N6O7S6S/JiezlGfmzy9WuJdorifeyPJr6xM+Pz1FG87GxaAYWV1F51Whs23wbx8oe126C626BCJB /Obj27e8Dr/PdjJchmXkZmT9zs6O+cLF5+XXf4IOj/YXavEJ9CJArTh7dsgqW9TsS65fIhiSxyzm KYn0vnuXG0ggm6Hey6LfHD2T9qXveVTufTUxiJ9DfTClkc4nngPMm/hHLV4fb4i0pcHwEBrzeERZ hGl/HiZH7fupeGMNbI+dXWXV3OlzQG5Aa0vCL2hDI1qP0NwvwOuhY9cHnGq/mPBm2Inf3BSg7xUU yGSzNPh3iQhUaos7TeXpG8nYDjH+NKxsVlaa3xM70R0c3Rp7Uy/t3iaG2bR3T31AdBx0K7tMr9yc qXgL73ymKxKH2PK0XgxgvpEArh9ywbZtA9V6UUrkjwvk7ME4i1EsEJ6bYMtxU1wrYUp40vhpY4fv Q3A/2ujoxtkrOM9q6GWhJcplfF/IUd290wuq8TESQCI+jZ7w67mPW7Awa8QY0FLjDyDG9jA/f+tE VSXl8yTmMbC6m0gHTnsoWCG/gC/I9S9Or+4+0TlcYFV5/D18O+50pa4tAqXCkw+J6vY4bx/hUjmL 1I053Cjq31bdp/VTB8pqE9f1V8xognK4axwJFC6FwABWeCyOpIQQMT0avjZ4xSXtYIZcWIBjRVjo qKYd/BK65OBUESyhp4kk6I59ZhnNJC7fUQ8TVLE9GzoXrGO1PyEjVwaeOgWTaz0iwRMbsbWmL7v/ 5eA7rb15kMnvc8+z0VcpzlVAT7iWDSsrjjeSLMSwhd+J7PSOUZWXsnrnjp7J+l63PmATtrMVuVH1 2H65agXwDVMnznvPIOhYO+1C2elzld/rBl+PCTro/sLMOpKhWzLzHddBqU8giULhJ51XdIE4v20V t9Owq5kKk/RSuKMZmq9BdJEfYq58mfDSHfOYZxEzLrlgtPzFK75au313gcq7rSrYIWBqtbpYV8rE cga6qVIWYc8YFXxzIT1EaVNYOrOI7kyi+uAhijwkZYpT0Hc6t+AM5uhS0py/dq1J9qM6Pb3/cxHd OjtguGGzrRATbe9wL5ZRUrSBW7VKRxtRo3ii7oVZCykVCEYvcACNWY9T335fZuvJHTjYzGg7ZOZ/ GB+GZzK5W0BAPYVUJzaYWOSHng5EosjZqe/b0Gym/Qg1mAmuj3PZOpIA0YrAHi0W0tx0fkjAdxg2 TDjYS+lZtZJAR9Nd9rqA8+5G22TH9+avgAgMR4O+cMcmUdC2nU8JVevwSPqH22u9hiKUkwZF6GVx tk3dIGH3/eyGwux4/DxRAlC2cz5FxbIo0Av94SIzRjvw+lzt+2z8iC7z1Ar0RSA8kn2kXy6jFbTC eqnf1XMOGCCCBSl3H/zyAk3U7kx/xzuJP0L6begvMcC3KUa40oT/gkOGJBUh74WlS/yzpO08+pdF SbquuriXrb1feFS9KtAAlX9nsJR60uzCMNg65hEWnYFLXfWFtxEZrov1RNhydEYA6HffqgF+MwYF 48taInR+b9K9kp2qnuHkoQVGGch6Ank8yTNmLI7VTesEwhMImkFr1AHfvL/CpI8w4zgWv/AvAXUz Vbce2fNsCwevSQ2TWY4u8k4t3QfIQ4ZYoxoHPLhUqwxwWjLWrpIyFIkm06Xnw0cw4tUqsxjb+MOq 7YkUh0J5i89fwG5F+klDJk4+uQkoyP76EQMjauP2g+QHv1j69NEIsrNY1bJ/r6kaPy8vxqHe0Tro KXarkLk027BjBK+BU3LdCAMY5pu/Gk+ZiUfvzqY9ics32ulUUHGO64yEJ+yb+ukVZ2ebI2lYxueL JP48cbkjKdgl6Q61a5exTb6QosJ0+5Vu86NfgrXG/kzFoB24ShRqZ+xgeBhHBcgUEQfrDpfe+hHh SL3jHC55tSIR9FpZHD9xigRbI+jFMCgj3O0pxRrQk8hHODhvkDoV75WMLw951EuLc3VlayYPnInD tUx4Lj9C9D1pmB5r3Rnly03sLfuv6/wN//QRv4r1h6WgsBKeM3vurejI9ZLVDZ5QbrGE2p1n0tI+ 84UK9JmELpkrWiUmmZ7kwzxNOUCpn1aUPJdmeQwKauH5KRar9h/hrl5LuI8H52gJzT6dRjkIrvF/ arErgY1ARCy7jVZY8otkkGRBrflD6Td5D54nRPSaSBIbGHHslzlW1JWh+JbcZwSnhlYm9Ih2nUHq BlYryjoz/sP96lvy7GFss7cVpuVgS0uiQoFqIVuHv1jAQCX1NUW18FCljWcgz5j8BIr1S6Pj2WCL ki4SWrf/IczZWyJv5qNbpnmfyEEPDMIxp1rXJ5XJZOBL6RBiPM116HTEQWd7riZvvfVzQgsjUA0U bGUWTTpZPHeg4gKxwNmNHSJJJMTcOkcU7PwDLDWT8Waw1LWJkEYB/6GmS907krB5QEzYXTDTjvFx Oe0Mnrndq3BSreJRUuhJsDhOnfMHmRUWfgaoZF+wdSi7EEj4A/Si/mW1TMPKjyjBohFIm0LfOHhj MYqagylREkyOzdBlxglTjDmN0e/Nj34tZ1xXil0WTl8hSgffTroh2s1PKSgYAdcvYZ2R3LOtplQh QR3oy9inrAGzDy/HvFEUHBpsNYsnMZ+sO0bf5HgX3N+Ls8p7ZTS/BVhXjoLgh+jlEiG4M3Tx1BcV 7umjTrst3q05XVMsYpCTqJ4hjLnla1BtCWjK8ujc8nbMKXL2op20Ccj4iJ9cK7JsHYSr9aIJciGQ qU6VLDWIOde7cU8a/6b8eA/BSko0Bhp0Frz2HlHkTgXPULrUa+rdz5BNun49vwq7vFPcS4AEgt7I c7fZtEcGSCrmrr3Dbo05v35vLwiMQuINCnvJBBr/RMbyBgq/p6duD0yxkdc0e4WyGjUjP8/u3ofN WKEs/DPrmsdgc1TF/sDeMbDFAymU9kkTVyM1u9kV7+0oJWheKEUn2+374QSaVzD2b8Dcbv+F/yS/ qjUJ83R0DiO7ZlwD/Vn6A+BaWn7+7yu+dKEDtUO1hx4StTCFwuDANdvKmpDe7ctl8lnp8QoRr4+O Rup6ZmRJpOY5NSv9gyFYBCyz/Rjgohi65fazuLe1REucK+Be4AtY2JpGPGCy+KzfLhZ9W5OBvtR4 cyLntXw/tO7zFeyVp5Fn4fyl+OpkXrSA5BUScun4++l1NLcmC6dpZSWp5J4HMtnd8MoQC5abczQL fESEfw4IDh/zquuLaJv/ZhIauRPTWQnm78yGNk7BzdrbN60QPTjU1c6SJ+Pj90ENN9OnkBFOVxMB zLmJ8B5xNXPjjLtICZZKCwPmavFLBhWdMa/pLtbuj3CasaKagIqe7D6nx928lUbloToNw1Eqiavt ZgbOlwcdaB9srQsQJwGyim4l2xI8ZjYL8UOAkgBi1vT6vf5vLA4NLQTt6QguskhUgkoWDJ2zmMAn 5Fa6q3yMDMfyQywL1GMp2aGpS5uUx67+kSXsy7pfFqzjGJmLvQnm8ZdYQaXovVQAfrJh7yOLSeTL 4WhWfs6zMDrlpMue7m3bmGF07+s8iJ2teOuCOIqt5MAG+kXCSVuhdQatGcS+jWdfFjmX4l7LWBUO jb0XSfdqCaOeHhOGR/6hKVoOuBkk9qriz7pbxTxH+3kC0wwtekFbFSlMwZKMJ4ONzGk0fayp0l8u Hngdjx/dbxLJqo+Xu0Gofu18XPIP0j1SlI7QAKdLI9eDN2Q6NIGf9wl4ePGJ8MJyMoUaP6YKQ/5E xt2vho4n8PTDpcW0ZPCIm3Hu7p7NpFp9amXPqyXBPc2ZQ7RIk4lYQFzX6285nPDod98kwUikTQFQ 89Melrujk4bfVAGZW2KrX+WhDsmbLRiS0k5qz3I/eA8v9j0Vk7cFyMX+4pvQZWNdAL3wukOefdeu ieE1rT7cSd7n/BuVop99honwUXqLrglmlddbC9asR6PztTb83CLslDvEMZe66hkaZ688yLk4YHr+ WswhLHd4PEYavjICn2fVkDESUdTuwJCJaSKpLiJO5gLy3vGMG02ZYL4xPK9e8FLZK0l4czZ1DwaD CbDg44Yn5uxen9Zx6aXMJtzZ4uWuyaJEHnBvsaNzq1rivruDhimI+myPvR5R/yn9DPa8Ql5nvS20 SuKEX3oj83IVJEn0HaVwYfD65r1Mx9oO+z43zbszZS3e6ZQ8KSWF90zF8YdJMKCiAEit523ckOsj xLAyt6pf9wMwU0TQOcBFGc6JGEESx7K5wj6ROuJ7hwIPIVhEX9AXqxGEqlkrSYjO06fdkHMGnlew H5GNiRgjHey352ixEsC9NLBYE8a3XeTTwAG426lM6M/LUTllc6LHBIgyaC99uAOpcQq6CvvqXx/v QyZLckVK6N5WRd5GL0y1jtQoggYbstnxYpUQFssV+hSq1TrnQPQ7jo9edy4rUxoXbmlXrG/48xa7 qQ/ukOGdtoFcVzZwMZbyfxEVYvsRQJNAyIj/dHml/gVzp5P+szrrCiPuEiis+v5RzmPovi4jLv7b QYuU2LXvyigzZWIiy+UFl91dbyGt6xS/pxLcw80wezVF65FLve4k9GD+N1cr7Q8cfwzgiwrff9g5 1ToC5KQ0/ElNvD8Pidg5Dyhl+1W5xCJ2BzTv0znDWb79ourNZN9vmGA9ir2gB6vn9Ae7pdapFg6K 3WHjTj8T1fBwvHlarzaNC+Jps1NQspl5V0InKWwSN6Ltt6ByIHw6Al4d3+26pfvL3zQnw24TxVJO eHtaoDZdswTlO/o1xXDAY5NP8NXHqKIfA5zRK5kBTbyKWQt2dzMPyeD7Zi+BlE5qWKaJ923f8dCC OXiPTFst/Zymrktisvnoh0o2GR7zmnRrBA3z0aWzwNw5oEB+h0VGrppjNwP/C2cuFE2rXlJGGUrA 0OSJ0+QQyn+hOdtKBbFeyJ/wYm9qDX3ZFjnV5HXHJhotdgSuSorhFc5OsOxcjEoiC6tLZ0MvGuIH /VCP+fVhZw7CQUXq4KugakqVznrgGin876iwyi9uuXaDuVrWt46C3qNWqa7v4ZYv5g/xX1+vDhYS 4NEaVg9fv/T4H668qdZwAABUIEMj6uIEaefWj5zJGcF5XFtyCNrLbbXPa3tDgOJaVsrISjl1RdJU TFnBbOlO1jqh+RJsM/Fq5Bmx9rujbPcIgtO0vwYgiiGSl0pB1+Wa0oBbdFJEyNasaWNA0Soar05a Wnh7jO6FxDENo/3rNQ5FDHe7bQxfbrkH39bMO0to5kT/z0r48oO7Z3OgsdXo0MThjKHcy4Rcs4dB uIfanqrWejA3p3Tbb/dGzuwCjDfOwuKoRcQ6P81v8IMpDy4Haby/Du5PC8+nUC/WQ3PlwzMr3vrg x5a2DAYApmjm4ZxXDQNjfjOyc9ttPGMlxN6ZGJs7+SCNg+b3c0zC0papKjUbrrXNw1VcGTZwRlgs eIXjC9XPgDrDNcK4EMsgef+UBC90/OhhjgeOszV1x8vOPOx8JEG80c1ICzeMCuVeI/Gju/oixz8Y vOXfjf49cgfrupABSuyy/blXxsQBhEp9xZJjGwLMB/rfNkk9Cnx5YdYMqiu3nWTgP5XWgd/R0Dew PdCeeK8iecr8356uU3+vapMTBjZqYoBFlxUq7ZtUokfXokkRMjKzXeTINjWKnayYRYhjjhAE6jtq yqHyA8F75MemyBNZyBeN4JKX//n4G0/m6qEMoE/EBZX7R5I4gdGXAqYlqrittzhnG8BQ5CQ9x9vz igvxgv7d/W96ELea5EALRssGZytDv7Sr+lJ7Cp2Z2a6abBt/S+LekQcY+X3UILT+zIqI9dGUgYCD D752rGsZTzGAD3cPIDHd7CGBnGMtmvDAP0gih5sQqHMuP5Q7le3a6KtN3v9ViwKtw05wPlFTZiTH St2TfLkXByx99wo0CLd1m39DRj6xnw9x5DBRpZgvFpjoxpW459s7l9qJ2/wVr/XdiSkVh4Njf4YI RUAMzo70xIx4b1M7TX1uPAIdxLN9j9xHvzOZcnNzhP4qfkf1BhaZNhjkLL8VJxqIP0zhMTX5O53h q1z2VyhlfPlKQ+58UUg3p7/9MQJx2VtFRU9wiG15Yn+kqjOQ4wGjW8B7NuV48ocX3le5UQanwRfo bb47w7794PcjHj7hIPVmI6nMio4EgiCnUCFAyY3QuQlsaXxFhE5xlZKlNt2OldqjPndp3i8Da0Uz HWrPlgxb6id96OIOzy6XJwNnYXcAvfE1JhlgfnEK697eXps2Ce2nHGjVpg/oDVew9S6oL+/tHqI8 YHDynhJZV2WdLIYKCRwp7uXo4RlrC/PEP5DOHjmjOf6+H+FYIos4lyj2lp7bjZ5BMhMqyEXqow9U MFhQGFzevhLsn+87KUysZJyMo0AsZg0pim6RO41uvqiPDZxkrgPb4/wOubYuCEfs1Mc0uDUMJHs2 ogOTaxcOWhFvXeImVvj2HXmV5VUFncbadZlNajZRshhIc4oTe9fy+9258ol+T43ZQBnlV2uZkOm9 L26xgMVvOYEcuKaBeBRpuuovkCLLUpMREqJle0ajSRKNAbPxgXfqvp4A0hVaET9n5mlANr/lRnok 7xJONzNi9kKtemHzvcAZ80WQ5bmOsk0ST9laHSxKpYyo7pbfd8w57nBdOYrcdIU/wOSZ17MFrKoK 8d4Y67nVHzNQSjcSHbUr89RA6efEUYLEoOCzTdu3nkWcodcRNPbE9Ds6f2Qs6YyQTOSWXwonPXmJ cWztEKuBI2rsuVBotPXLJVyE05EEjryPzf0DYpx/vLZYYsu31tE3jj+MhJZQMybucRLCFF4zd5ag 6H3UAIV5Ry6hNBgdyWgA1qI1FTbFsFMkz1Vak0Qfu/LQfptm4TEO8apahkxrsHsRvlpTz4oFl4n9 76pq4tbDLikTSRsLS8lJhBFO7hk5el4jIJ8OwQFl6ttm8FKJ1wVirDhWmW+KLQ/4LRhf9osOIa3s RPuWcz0SdIlqYZAiy8yZhmnRsiGMXHx0nYZWMHGMElCQuFAjLewTXy19f42M0mik2wGGm9BV50TN flAaEQDHmDIdOewynZ1cr1g8gZ2my+xx2Qw/6n5EYuEuZoEw6kwoWH/AhfQHgtbpiaQgmE5Nt0X3 EtRYYZwizRpdVhK87gB/Ov8DtPVuf8PmjFZxni4Zz7/qHEiL/R3ejqMTj4o6JmMkNKf7h9jF0IDI 3u9S6fY59yqV36ylRPVOBFzjdhBIdo4sSm/XhSO2fGAi1pmXjbGGpUtetrTwg+mr8WFnDLTT4gJH taJdUgaq0Y3kvWxuoMHyg4HVHn7+xUU9Ko3DVUQNGdPkDHsejKWMQoqIE5vCKi2edO0F6P4F7g/m DPpJ2tOAFQOX9CfvCSitI2yoPi4wE4Oahp6xMEKDcoFKorECGtbZ1ahn7NgXiPZV8QcSDNSiBIoh FsmI7fzJwTuXbVoQ2HaJ2DraeNt5C3osKYutr3sdmCr5BahuPZHaFqaBUSTdH/jcM+HXY3D6aBbB UKQ0yNNNe71FEjwZhqSpCq2NoRBBYV7WnKMRJIXkkbEdV1NWbGxOmGF77jv8AJIxiflW8q/S+PTl zqkrT6f6PDNShcvusPgVK864AcFFXq/TEi7puPUZhgRg6qztFUj8ls8ot1jnhVgkzpPYnyrDoyQk oTn0ST959JuQpu3tu4uUq+/e1JPyyZK4gP0Z0odlE/D/DQlA9r8fdJB7qXjq3IB5iXfYSNkZWMIJ iilgYTBvhR8y3AcX/RpYokBWr44jHRywgc33BQODRGCylp47/kZ5gQgzeWNSHDFr9pv1U5aIZ/Xq ZEvywGo1FbcUibHB06yCKaIuFZUu7ZoR+36XnM7/WsroccAm4yrPTp9KVD35DoMpcLLLQRmL4zAM aEKf1Nyf78lR54GfjCjpEFyieMyof1YNyb+Kj5IjX3OIDXeLqPlfsgL01yYKsShXGnaxrYGrqv03 h2aUPd4n34kCUYdUC5bZMVn9wzCAbZRHx/iN+A+Vx1SAkO0l78GoFEhg5WrvaqjAaXjJ/4n9BL/f 0AzHrapBe+wiLcqX9iB9fENp6xa8G46UJrg/marWI83Fw/sZ7SCMVVF9X/4beRv6edC2aDTxvtLi 6HeSqiBEHcpDCe45FpD1QM4g7YHRgU0nxriuNfAvJKGU+UvllqCy1VEq/Chv77k5M0Q+/jrsKcC+ NEMHneuYwV9J+pKaliwcKMzJoSQ3NZN8rTnFArvDBgVgKzM8sCE5+0LdclCqXpq88GDh72fAqWtJ ZQyQGltOuvGcguJ/BrqPx7GT7kJBHoYRNiV39QzFcUGVCLujLM1PtjO/dOA1oIGzrcxdTKKlSfiU U0dkJu4c5j/zWwaZnSnroXU3bjvQ84GYaBA3oMH9TIPC2UCX6pnA6H56q0adZ7eTcB2zeSDgLWmG HsunTtuxHUKPg8Wv0vj/n/prV18MITL/L0zFAeTPii8Cgzdn6zq1dn+v0yrBcytdnZctv8S7qMhz sU4QVHOB76Mokry8el/zCDn87ovp7CBuVViETq3++JtjR71L49k6DxNg/VwCxPQkop8ohmN9FTgw PvNTgKEleAr0LdX3Qs002cGVB1Ec+K5lq+ub9/pwCk6DiLqUUJ513bKi+XO1Fv89qGvddg/L3Dzk HE5t4KGgkI/N/JQSRMSWEkqUnsHX8Zbkuqu8Pd6pUhXGfanw6RIn3xijSy7ptH6qqINZ7ChcTP11 TiKtpgd3y5BoPMYIuDsdFpVTHq/yuF4Tgb9MlKnhnG5EVP31sEyu/PTXFuJUw3YYwC3oURBqcfLp GhZB+NOfWyFwxwdwcBNXpAh4cjgnVeA4PitX8BENH+cWbuv5wiDwX+xJ8pFLUIVIYK7mq4Lqrf24 OtZZ4wWchiw02sJVwP5tTw0Moa+tdky9Aqi2L6kb46rW1MX/YJavEdARmrjHZINx/tJcBjhK/BSj mFPZHvlpf1dSeWVYQJl7NtZYBj7T7CS0uUs1GZoFOhpve62AUx1aj05pr8BU6HvB/gaBrXOLKXGT kA9X1H4ghVSw0mhAnUNMh6JLDGWXtMc5mGcMwphBjoJpTd0loKCR7rzl8d0Ihnhjeyp5QWE3FOzn 10Dxz46nxnkO4A14RgAh9Ws3XtCWj6Az78MvszF8Xci9yOUAC+Ag4+bMNdMgiXC4vOIow3kHO5sq 8V7R5bs4XLdmuNDRdEa6HptHHcnTMgJWpgYyGTb92TIvUMNnLVqFnp+h/oHpGRWZAth5brug/qFx LNofZUPDb5unTS78QTxcLHuVyMzCH1w44fcEJG9XRssB7NYOnyWx4YZMiZFruxRQ97RGkc0GUJtE +7lQ81trj/Y3R1b+zy/K7dH4dQJk1Bum8D6LMuprK80XeOlpFSFcVTiv9p04cFvg0pbppwz0P/xN 4xzO40ZXrVKVzfj9e9kH57By+a9bnF5Xkm7wR04E5fhqmNwVyOH+Vq7JF4l2/PrGmeD/DtqJw7ma e2OjcZhgLk9/rkbwvHlvJuJhWtr2XAL3MFB01tG96hWQq0yVTdKjPWv9W8lo1e5AAnTyPRc7fGyx vvuv5R6xbMRUVVPmwUpdPsFB9hbFJTxVxPrjC5gF73tL6GwsLYkDpSiv0FcimWdKl9sjMfwWnP// 9TUazt8+avyIR3LcO6vq+DSobTB5BbNVwSp6QYLAwzLXmQuKuIKFKSaFuLaBdDufGvnHuLrb0/QY pwRoexI85Jt96WdXeXlInQggp+JGbCH99n7l0cOT2GclISKPQh4Nh/m3R7OOSV8XSI9lGqfqbyce dY9LevRBzFEoE1pbrd5ZkUcm9RPd/H1Ma9FSN9/hyrLbeVmtOIH+yxTrpqdt67u+QV9a3VetqmZx rVJFPtD4Hdx7PCNqr6BbmHO33J+D4diL4+fhX2uP1cDp/a1xbdSRHM56LbOBxRIPikx657nuyUXo o3Y3OajFFzEo2bTEmaR8mDef1hR2YfRBvRXKvPZSRhhHG4yuStHs7u1LPHZt0Y1ssCnqcdFgWREi SACwt5jDXDu4P/yZXqsAPohAw/yKB825/oM78I6A6wwciGAl0o4pgfI+QIch5WQmBfN5QUQYeFy3 WyiiOt52/ZLgo35mIUZUZGj64AqUBOqTD52LpCjtb9dbPrC3zjgvQR96PQjX4gHwHGdHhcohnDaB pr3SKvLzWmMstRWzmOBB85yyfbJ9oj6K90mXIJg7VUKDomfAWBLzoB2FmFqGeGEAolr+NphiwvDg ZkOP9S08XwhaNxMGEpdJz0YsyT3Ykwx6HBvuzytZRoNnuBzryXikpeZtnoDjv8WvLUl2lJmFztB/ rrkIHZ3PkjiBYzAJIEY05PRUCgQvTbkXyB5XKHT8MB7LyU1EAN+qQ9MGAaSegOaWGKbhbCxQnaoX Frc1RVSEfAASqRKXLux704YyBUc3d/qyLTzraN46jvX589aenRAfjaBD6d1otmDtZMsrz4/6eD3x 2wLJxkEVmvbXKY2LiC7qASE4He5+m4EVJSx/MZfceEFSGk3VTC2zoN87sj/xfKaZs/Z5xb+DW/Zu gUQbmjCdQfAAhd60MM30YDfPfCraXhSRG8/3U3cqMCdgEtpqDI7DXFzS4rfGdZoWvv0TtUPL8IRY 6LK/Q7r/KKuU5pxJ5y3Cjwah6ooJnWaCqG6zpPotXyrwxC0whp1TXRWMyo6vtJj7XT2AnNIyH+B1 60jS+F73fO9fDGcCtEzs5VrS962TdaZWhPJjvR42pJcQVPCw99ntdHpzSFW7LG7h8fhka0RlnNPa xUkTbF2qorWnGcWak4FNeXMUWz8vyVDuhZ7J4DkaR/hJ1MUME731DBEjZLJIXk+AIVOEjChGMUgg SyVi0VHmcZsiw1rHRjFF139twPRXle3Ii8pKBOQydT4KGEDA9cHSw+I06VW3GgnsomhUPpkk0LZv IxswFFy+4kUaQDy+tM4++YAjlxNXTSjzIe/yF+iaU8eea1mktN5OkQgFlaiIO5bGLjoBTcIjJJE/ ILLopXCnAMLJOhXX7aOllcwszTnKbv5ikPdVO7oB0Z3cI5AF3t64+ukXe9CIng5HuYTfbjb8oWlj N8psHV0IkQs82ZZDF5AP6YtnXn5xJWqg9/faupiYfnk1DQTurEbBt3crOK9F3q2+pYp66zlk8wuG IMPg22EXeTV7mWJUk0l5htAB6+9HQF/Thcn6xt98ftxDc2oqup5rKf6qo6vQOXLnd1z2kVgSsToL dCDviTed0cOL8PJmQ6x53BUWCq0Bp5QY6BbpgLaQ/DbGGXzSXFqPe9Mvdhgl0RIkb1+Pcydm11UD ctPJjA3/G/cog56wHzvKu6a9X0ujjhTsJ0o9LPHZ7sUgmTPJhElPsAkRKUePPKBf6qVkH1RKM5N1 1GQXdDhU3Dwwjugs50f/fr0/NZH0EqdAFSnkkP/dwLfaa/a00uV+MKaJN4K4hPkbcYteAtw37DbS pd72O4H9vkLhMJYPh+5kt+XOzNASj35Xb4rAQAOa/ubtn8rcrByZ2Qa1B/xYs0TH/SnbC7pndNvc f/aOOuHCEiQsZClriCOAWSN2LgG9byZnF20xLq0P2tc0YAZ3jy0H6ohY+hmKom0ESQvexW1ETQ2x P+XXTs08+SUWkgu3COdRYYWpLgJLovXJnd5L4kucr6/L+LfNzxXwDCeg3oB/IvHSybQuhuCWqtZv ynXM09ICKor8lfalmJWfI9xmKhAHhvFaiF9393j9dfps6NZLMJs81acoHvlSgF8I3V5qhCJTzI8z 6snN+/klV+6GDk8PF8JvAmtZubhVmqdOCLgvYukVH0AHDanxG9OHRngKpT3vcviaBYmyIUDXj+9W 3Drq0a9jfj+nhJn6xHsNyyncTSmr+QCZDh3eYmLQwhDUc+QXdaGqG8OEMxof/BgqMvWGsHiBM+zy 613s3t+bRJYScOMEUv1/5RP8K3ZOKy9RGlbBcdsiGrmnHCOfogjD7Hw3TWwKFRQxPsWeaS9v1bIM /2hEqiSYYFi7ximQSBiWpHOAnfUeVq3gF4iiB5vDRKpeUHfnzxuXeb6Sg4+XEafGM9QsEyo6odzE Z1fh+FXgh+14E0GDrELybJhK10WMAos++wa+XpxjlGWP29KDVoTHTEkWGd8rU6u7NyRcDxdiXC6I 8ptu0WmTv6WsfvxNe0I4ZSaxw1ItbXQ+aV6YNda0wsvJfOTEdvRJSPuYx4Wld7JKbceC+SrAgIo4 BZ6N4/7vG3s0xMpnsOUT4UDU+ocuPXemTnVFoieNMUMEKstlQabtM99GIaWTLVexbOyzjtIyo9rE 831j30XUbJxjB8qia0I+Nujz8jUeQ7zlyW0mmjb3WjJjzAXob/nMWsNzKxeS5wCooGR4/Il5wb7e HT/pZp91aXEjg0KEp9+urt9lTkPkFm/jBEFcvhY4/mTBe9Tw4QFg/hXDV8WgY13cDF7cOW8o02fS 0Ga7gDqazDwgJtqggFvzp6uBrUp7Tv5yaP/IZAAk1fhV+AQHvT6V/s3YCzpcw5ssjOxFFBzRi8I/ jfzSsgbdTwWDD3oCcSujXhXbrroSi5BKrdrq0E/ztZniDyQT6z/h7rUvSPx3iCjwAi8QVcpergoZ dqc/BKR0M1xaVwS2miTJTdPILqp1QLSXWeXxgBxUDNOx9cjGojGWInJ0qdyLnMNDa+T9kS/wLPZN /X0NHi2EFR46dHJ3U+rgsDYEQfIX26+/5NoNoi5Zfw+GWpFlw1GyfbFwOGYhTitpGiDYK5URaxX9 0na3q2gQjoz94x3Rq4jsbmQDs2lL2ixhn6U40KHBmXeV6zVnav6z+toImTlbqhjVSFv/QCB7k7/3 6GvdeNHJyvZFNvc93B484gfDwHT16Krbrg0H1SzAbMIaNtJjttKvwHxhOhACqQDZsbAIE/Y48MS2 69wOe+xJDFyRflQojxzGt+ID7bQwM2Z9sZvvx1JH2aadrle3nqllSjtDOfTSEsc2PjwF31Tkt+Pr KD6O1HyDl4OKonXJz9oHbXRpeqSrPeRwKi9rm1WzNqcj+V1joarRQ4lqHyToEOs6F3e8z7E+gWlU XPkZazpFcBkhK3ioNOCgo64YESL0VuQbFyjbtlE45K96rWY1Gjc8k24mKb6fMHNAQU81xVTEMuGg 6+AkhvYCYrNEXETa9qbIzF/9lRJEPbuTz/eAJsTjYUVaey48NX3Bobw5ZYfbElowjUmYqLOVDfIb RjAr1nMImflvot7UVpuGckqzXOf/uc3IoeHYrbLIKKpDG8gsRxQlkkxvonjEb07OiIKORxjgK9K/ x8SM6mzvIQjE5Y0wbv7M90kdDT4081vtmgmHZT3rf1Vbs4AbV0Xr2SjHoBUs6jF36e7zlG3OEsh3 52XHh6Yynx0b8sAbwhK9LtwZJ8RErozYzFiXpRVSXdzCFf2B8kanf55RIjX5fKnP3tRMqtRR2v84 68gKMyiCUN5Fj3uddBSILlJH8HJzrRVsfCFex2BqwSin1ZNeWkZGQFxn0CEadUu55ctpD1YyZYpI 0gZCqcrTWndgohUQoPJjfjYOvjphMlRwSbalNbd/lAac8vh5FtNCp87a0+UgmeBEazzG9PN+e03d b+BerPpmwqG0KA7A7HN08R4l/6orby1n8TYncmsx+z1heuogua1XAOXS+DPmmHru5OR7FKXIcDbm +0qHtEAvF+X3+R3MnBIzYYjPTvKXux9KzKmxv6a4SrZ3WI23sy9ycnQ2yf5fSfj7H8yEyHMHh0jM xhq+JEI7FEky2/qUdMgS8A4hJGku/4Rpf5mNqZqCRTsaGvezd+qWfdhhhZWH0G6sqiIjzz7RVJx3 l8rlF3NHVbfvXBMacDMzT0dLNZKsoSyLOfLrlvnpk1pOqPIzxtEyUHC5wvlQOj549smi4JwP0vyw uofmPzfB0wMO52hYawnVJnB2vdP9L08Y9Lhbr+Ckkpr50i7ar/34S0XU8Q62mCLXpTx2ELHLzuoD 7lSanfdbrvn239wK5eacaSxoleJz/9fZyM5jqt5LHZIaCGuUM1Nx5aiH5+ALe0qcDwX8sTatvOqI 9sPEatGMcSwlRq1rmClVA2LIsbrwH4T4UtB1iO+X6L4vxAT4sFl5wpjDutzGrB0cC2cbY8iN7ujC AmiQSP5quDTy7BsDY5HhR5oqH/mPd+7cpD+PmDPEN88FSQtL8F2BdhNy4qbswpo5W+7ApjVUsGjU OwOoSbGix5qieJDd9KGeKbG9ml7A78piqPjAQwNVr/l0wOp9hHSIW4jOCbGHUQpgFHW9ePL1/O5a GxRXmV2qwjYFXJppbqAXzEGTuh7/qXSq3Z65Zker3zc3vyaW4+Rmh+R8PRPKYLouRWjngSYsyfIb jzDVUd1LiNuwRNJi09L5vQq7m20tiMWpnQGoH4RjylHDUoSuwP4jm7aeJGaBV3ednDuYLveYQ1Tk DHhT1smcRunY4zzJoBcSdLy5FM3zmv6pdlNiFMT+tfm3GePgZvckJlKwx3WGEexU2YqaR9BIviMA N5MMp8C51avf16KzV9lGd8P7mp/pVifvVKP/o/UvZun++Bqw1g5z9zyNG4XRukasuf+2bYm804Tj LoyibD55M28h5zUAJ69j++p4GlSgL1Aj5zrywjEtry8ql4FS7fstpdfxNPcyXB8wY29aJY5WHyil tHCUtYsBD1dmFSSjRQHeDLG85P+2Zfagvu991M5PXujqPISouh3VnJmE6kijpCm7TshsEQLJ/DMo M5I4Ph/X4XjAO59TMgdDySPGqjWrJ7PesW2cpuxyoQx5tUY24gzHQgVXDVfPQ/PnWFX8V0cfiwJr GTSymL/JhhXyjfhmwawt5zKfOy2/tlRQgH/IKx3qhQ6atLu5QdNopG444/WTvdv2vfyCEkuFNalU G55LSWwtcMHdokX13ZFLD49N11zmI8yy4m0Zohcl4GrrnotIJT2Q6DXp8nb8rgvbV2YBKIQLBbQJ JJyDcS2YZOIogi2/XoF3VIL+uRYs6AfUU0LpbcqefhwtVJRR2q6TsEp/DCeMf8ZJSvH5bkDFB7K1 KT76v85MeoE+IdKsyaIPcqB4hb7SNxu0Hj8NyoHMx8vklaIh2ee98w9h/kMGZDNLOxVqKFFcVP8f xrd6eU8ssosFF41LV4niGQs6Tfu7E1zRKqTqKst34llUab5lASQhV0XVDYN7GVoCw/nel5pir43L qaStIC0mbPIGu1aVSJkT2vG9EmhdJQytFwQHezJkgNn7ZhdpKsrEA4iV+DN+CehTe279MAAsQCwB ctBFWzZAJ/SnhyaQDdSeXdqLC2653sljV1V8Fgw46cpUsV3ziWoFg3oQj+O3WNAaqdhkj4yj6+7i 9zspcMEluJW0muasYt703wnKhb4QChJJRhmGw5y9dsnmivlDd4YN41+SjGu7m0XvpvgVCGuvco3H 7RtT0x8OVxyzwVyHDS6J8r8bIEMk+3nwt48Mz5hrljbh7YE9a4HLkkRZop/xc4dbAVWNzPIw0cZS nAqK9KbYaoSwTWEjuhu/AeKqJo0PXlkROatMboBdTzdo9tjZshSVgerVnWIvi/y6t2FzpjPT1C5+ a9GK9vqDu617aGW8LCQSJNvofs3vFoLnB6ZbCCXg3t7AIfuzJdvtJ+oJnwGJW6ipVpcnNPXmNuQh nhtFzAeWQEMXs+49mWdYvNgp5Bh7Ub6wZ1RfzQVqgVW/yiPYx/Rj2QrcPBxNRIMItYnRzDxgp03g gMaciqoQnwptyxikNX1ED5Dyuj9ySYPhDXkq1S1Udrfbgu6dZQx0XbXtw92vpwWCWIaqze/ihV3C URNM5UObFJ6dUgmLWs6JtJ1xggQIcgp+VCC/SkdJI1ckyQ9YRBYrfsdpSwKtr9GSPnbVA9r5Jdt1 2wXruX39K05cuxTUUSF1WUzxsYQnN2un1bPKYalH32rNVS4hIDJnt1dIQrYTGYlnl6tsqi2i810H e98kRAYBSs8weHQztTZmlWYe8O767hkTsROvOlzSfoDlb3SdUSEUS/mtwvEOirV8SzDJl0CZaWo7 T6eQHfLYkgOWjeRHfds+MMXrnZayOuj7z2ZHtVm/wgkCP8wCQKq7YjhhCIhzBrcNn6upwa83z5mO G9UvapvvuSWmYS+XzaurSY5gn7Zt0ae1E093I3V/8tIK8rvVKvXNLKDgmrD2NKPjYpPhNbBjSXZQ c+bhLFWJ7BZYdVhy2sCZDHkxRhBSmd1Ir28ez0RpEesap+VLW3FwWmCm7fww85nqlzapZXTjfRcb IVJFiDwP42FO9wl1mhTqBIgHiMxHKbdlKkNb/o2VqKBn0GrNvPoyusLLGZ7yKnf6C8N9XjUzn1iU bLOlryfa8Q/dWKnY4o5fixUyjQAxL5+mcoGurm90jl5mVTd5892jUTs3jiqZWT1fZXD5w6f2Fc5p Y76P8P+ha5efx9NfA1hKanhxWmPXX0iomWbGcY+3L3bNq0RAQlHd0CCi9tVvrr3Y/I9W7676HsxN qtX/PeACkCS70cV5SBUBv8BffL1VHI5PHBRur6plQM2L6DkxhftsgJhZGnH/Yxv9IqOmhAOlzoYp OXMbhvnCRFSW9q538qFBnMQDKzJa8lKeJX7wrGXMIeFU9bzRyiH4xj+xT0JV+LWsr06JFIozF+Aj Cp9iQAl+Kl7r5EziYFkxCzUEATTQmFH5nkBBwIhtvPGvEIDLWOMCg9u/OrYYCUH2vDnK91RKgaR7 j6DTodezAXlR/IXyWHd5d+yAV30s6W3NT/S5Ist3ea1KBT52um5rzc+Kv/OhzJcEMaVCQcxfQSbO kt0Tfn+hZc0ER5dx0zEnd564hI6pwIZKnrhG2GKebI/x7jWyxuVn9jCkeAOv9jQSbJgXGBvM6HdJ RUpNhgbU1C07WjQcV1L8eWtPW1+LRswgxrxEwzC4Enfg3ZSjhU2p3UW68k8lfIoPYF7ah4A4+7Ha DlZJLlYn3jITPFDVtmkSLkZen5HvS+Oc4Bwo2WDCdHRLCUeyIZKMmoFpqoCpbz7xJSLhl2ZB1lIA Paf/8be3eKhRqQDx1o1Wlxf32DVM3BJPFVVOPvJCL8J7g4IzY1rOkpVLSPcWpAuMM0PuvivAmRE7 Jv4E4agrlK1XVjzXwtNf2jmGos9qSgBIw5UHYPCHnQ9gnHpYQ1tWF6zjIEws++k+dpI7ToXAZny4 /SGPCMr65DC6Y1RAk3Bt2V24f/izH8BA7o+6EhxOKcfLNU1RZ9sDFlklOGtnd5uA7QavIKss0/o2 dEOTK9rUd1Z1fluAkkYE+M6MK/QCnnsEN+QmYK6aJg6HegUjsjn8ji4WdoM2i6zO4q/c4BeT0q6j tJcfWgtAQL+aK24Ti5lscTjxq666/LMZN0bCa3KmhIUk+VkBGFEFyulB9mx5BnDMvY7+U0EdhB7r pEl6xtmuoGjQEnGaD8bg9QOPjUUQi4ZFX9YxpFPiJqYvc7cbvRtvRibcArIvHro7role2B0ziURR bPrgFdJ7bGAwQPNxIyMWX+o7fz3Nq55SlRR1TunINSA/QM8annZ3+zKFkDoXG6ENCVrE6e2XHzCr rAv1P9peawnPUnY4qMdtV4VJnMQ6x9Swy2iUNkbuX8p+FCqZ4NtN+sND14D0PQQZbt4QJ00zhTsD Wt/N9Twmux/WyjUhZovB7Ofw/9cHkCVPsh5zMuBMDvfPrwEm1gkcHqPWHS4WmGfifyaFQzQx8usi uwcIiZviaA4xInPylEFp6kHx2W0ZoY8+nx0PmFy4EgVnnm1GdGPP0CZ0AMC0KY0CjF+fop1kOYN2 FTYYUhcZ/TJaz3SGsYHW6AsBKx7C7qNiMJbF4GfUpnwCQnrYvaU98eMb4V+Yv95qsX3AEGpIR/tB IoqlN7/Bw3QzqEPQGczGcJgqlmMGbQPUx4Zoqamhl/f2fT7+VWLy019/ByU0om0UbfPYaO7ijuaq 3uBKzvDVs4EPzijuICWT8Xdc4cSXsWr0kqVQt+j8lfuIy4z5sgtgQ4vRPJ3w9sdBwafV0PyY+mK8 KXm+Vh81Y/ucG2Ri9gmE0Hqul2Yv7Tncp6cZuSRv30eXfSNZBm3UkXip4L4imbesNhHzyTRJahD+ 0MOAXLNSCp7gh6TpXUGFtDizp2slLF5Ewx1RmXk2ejWBPUOrCdbfEbRyafEM/7RRqISrlBQEaCdy Noi+VPPgXHrL8LDDbXMLOjDQgVomoGTdZiW8DCqF51jQRU8rHcxWPUbui8pqoHLTPJHcC/SUAbnJ lrCr8s3UfHFZmb2vqQgTESeR4If5nw+TGSVYnEfaepTPk674kSzRAGhrN16WDXMpwJmwZhZHHaam NKdVXJT/HyqqMflvmBStRR/segFj8n62xEbQRHLYotqTL97p+v75Ivqdej+avKRhVkL5SBzqHMSo R8HiUZAsQhNEQGzbpiEhwJQimENewiIR6Y4oRUj2S5e3+mcfgqUkeUHU4HwRQFDCdl/Ena4tyxPy aO7CmWym6yp+pDe3F9y5fjQ+eJ9gC/G5cTDP10dpeUj5IRm2aMdcMDm2/eHUI4ZqLFHmzL9vDucN cNFdshaASmhvM97XT8f7+AwAWUnpyvvCNrIEYbSjiG+sQb0prYzAovGzgECxp9lzJb+1QS6C1n+C lZXDl2EsTGy4NJ82eSLpxuFd8Cjj/apszhxvK/W90T7XZQfqTpo/atGVwQyQBjwbqJDLYdHfPQ3z SDIcz1Bhx1ROoQuKWmdBJYyINzusKnLrkkhfWT5oQrvLxUpmm+ztF5fvv3XBGk2z/MdukJbHWWbj zNfZqO1eNnLUpqYEae+zx7Tw1nCpXdKGvkBq+267qzKcXv+0W+Ld3AV2lYBuSPLZb3y7Mz24xOF7 rnL2DKuioibiV5eh6KmL4mGEbdWunU37rLL008N16nr/c+dXCyJjWJXG10iAdQb7T2I+lZ8BLqas IyvWeyo22qceJ5UrzDyxD/3HRH7JNaMlE4BRShSmpq4HZZhuRIkjlsw/YpDWldpEWhN3pTD3OUGd X0qDR7FZUQbIvugDPrrO3UcEvjy/03ZU/lRhM4oHmthLOxQPR1ewmI5TSDaHlA5NGzfgeAAysd9N Pqi4VZG7iD57fEhqAdFhciZ/NuyFpCgJm+I0X48qjKdnQa6Uv3VWN0GdI+4anODB/2XFDR3zWWcf y1HUB/1bI7mnezdgmdGqPDh1NDVfBjvgMkQ3YkOdLXMRYjfl+dSr/ViBN9nSbAeyTQucoj4K7D58 SNrJpMfO5i61HTQ1FmaaWJSbtPmO4qKzDA/E5mzHD3HiO7Znf76oPbRrG0f6nSklZR+wHTAGHgds Dj9nSwbUA7pRLFQljpsEdxvNXJa1fpfCntGrx5ifz0h1fxuo90dJ5Q+QEmPJefYN+V/vQhI5Gii3 tFlE2uSCUumgBRnubh6JlP9FNGJk4DGXgP67QCaSw5c+lTR0XcV0MW95qtr5YRdUWcg9dsOHu1QP SvtvZN4tJEe+QkbpjgcJ7ywltuSqlQWYWEiiooFeF1C2l45yEET9NIotjK8Hiw6//FeClZGS61MK CmSbmkF9gQaeiT/z5zDf0aKjo74u3EqzdLXv2w45rjEGCLihY1oanzupeduWRmuMxPkx9i1I7uyO hhvqhWvIzyiCzQZGt4jdEmWfp+wFmz0bXl6y9KUiyhnyNi/nZTDD7VLgZ0RrW9oULTpTwya374L3 VfRmNitZfx+A+RB6jAb9r9QKAwPcsdkMb5xIkk1WS78p0/SxU5u3r6iBu9L4S51rl7E5N5xE3Xhl yUnub/N1OokUv9Piz4HTn7WtdqgJlB4POkdqGwkHutzYIZb+rrgGYz4xDYDB1gvfEdtksfKciwbv el3ji+sQ6fvyMOVSXRPHIb/5tAfMINQgz/LRijJ7AqlCqW+RMXeNTpkPAzeLWpxPiNy9aOzCqr9r xq31erHzjPC1ZvQIi3f8SNfzVEUCUz9/ZaLt53BlStE3lkcA0K1K2eDWHUGokqG7oH5NUW8HbbWA Dxst93Cr9IRm24Rd4fMzqiePMmElQvad3/AzHDuUcP/8aq6MVuAkVmT/kkX820FGoEFDvAjokGtH shoOrVPZ6FlFPrT45oQPI4WnYod2J+ERJ8QFKVP9p4jojeZq8Zim1QrVyDBZRpf3gdKQn8+rK5qz D/N8LMZbudI6ksF3NC4BgqLmlcYtisfeKpfFvvXLozrx2XAxRIXRjBqq8bJAlu1o36/SSXoOom/3 4+2W/q55WV1VBTJOHCkucakg3qVPbgbF6fXGTjwl07Du8LAC8bTlBPF0EL/EJ48OgE4dn0ijv0c2 CcS2cOAMRtnaDoqCt6xlhAM1ENsaYsHMN+0haHGkAqYIpeSWBOOTuAy2UEAltL/WV6tLNuWfIYWc +kSoLoToFiqJHdgZrlb5QGDAZ1oC3TzeO9M5ShNFU9LJ9k3C6jbCabEl9BuEnquDVOpw03seTHFf ukW3aTa8l851e32SxReunvgoeanRzXxXmcrDWeQx1YTYav5kzWhg260pvYUPtywYcsldNdSXcfrh ush87iK2tQUQMT4SHYXoiklWrHviJKCujTYElsbcB2kiyFZt+4cp8eqIJ2SeSUO9dwgI70kC+Ch/ FlsM+7xUNePCW40raVKbkdPGXDIWhU3/q7qSf1Hl+z2hjbNSsKe99e7CL9it1DeYDtXq/nkal3av LveK8127G0AHz8Q+A08EsD5mo8xcn/9jkAQEiHl2vdnUVAys6TDX84aQCr/k7CUkHo1xBGL3oNIZ Rn6Haj/4U7Wi5y9xWNNDafpIX73ZfaKcHl6FqSdGyVtENfp2ny5BPe5FW1JTQXsLhUAZVl2J9vQZ n7gD5Ed8rn/rv/ncVxsr6o5LpKqn9DndDk+wffK66gPAw9+Ci6PzSrWr/Cr+1n0ZWD9aap5kShGn sDycz69G5QNwFy9Y+Ei64csHTcA+ZpXufib0NPel5MFOU+9utlkR+gmK5N21i3JH1syEPVJ4QHVk VEfw2mgWVXoUdPIIMV71ekN9liN7hgMQHLy4yzPePE9hpQNrxSNTZ47ZzGOaybpOnesIRGZ4kpRm lppoSJyU+YafkONKG/qUtt2NNdOB62Afrsg6Zf0ZNdvJumMueYXOax+81IK9B0ApTgvWd1opEAay HdMIj5vn3Nbn/ifw0GD8cLFS2w36bl5jAOYEvIkd/zIzgZCM3jqgf7B0AXLw8BLHzdhQV8c8kwtT Pb8c9oTLykY5p/90E3QfZ/My/34wDSCt0n8SxnvoGvCUb9qSmR5bMu+iUbuYQzPYSFlzwCqir0OI lpul/YE0ZfLc/HZ2gUaSZOIbP0fjHsi8ZmxQzBBLu3AXCccxhs7Oy/BYguXs/Bh3iJadVTNLpwMF Z/C17XvWwjFRDmtjPUmG14RpzWDXeqip/eb6vsXemfMwZnCQcAy2yLbh/El3cWeDqX5mqM3T2qte /VtGAL8Q1LwgfyE6aQBsKtdkifYAmrIGAuqmYlo6Vr4lyM2F94xQ2lANeziKG/87wU9Un22RAhzl 88aoEYHlxcRHKnDAZOJIKS9rxCQ6rWU1bHQGZWsEWcth2bhUAA4sITsz9aHvZGwn1B5thrIJiL4O oEsMPn1UdAc4SaJBHv+3D+y8XfHriHINnzKaKgkO2Ok7zNmm2KQZYuN7nqv8ufmqJ9c1DBWkKQFi hulXjycxfqJNWXxAwizxlj3zzakRd3v4rMqj+do4cy6QHhpFfJvk/lqiIFSsf1/0KNfGHZUpxcGq ErFO560vpQqfAI9lTI028+lDsB1lvr8/AzE9FuY74P3NdXzmcZDrfGd65mCXw/blPvZx04cI3F2E y/jkOZybSHKJ93O0SMkqGRgoa7L8Tan5MrJh2y8EIHi7bPP6mfDLwfKrZweZn2HWaptaRj8jVHzY 2XT/5wa2+uxXbaIdUglyxa1WYy2nBwCgjNS/s6pHTvixIGwdj1d9ocRyY+/bL3QDrHBiHXAVis6M AdKnWRj352HH30m46JeKBjJ2mhqmhnsHnv1O6xYqcuQzh60Vy42fnlYiOp3x9fwqvOcDI1fZNQJt yhV0iTwE+dgfy9VtVa8TMwGhHWDpF/PRmgl42JzZGlCGnkTHpi7D0CJbc8siWZqe6r3ci3QCJ7BN 4qEfdJaf+zUzAx4IQHSj/FXCEBH+FQJrFGQCcaUdwCAHiTAAgmOjvpc4gDStBiifz0hTzBU4XSrB sXjhVAtttpn78l01VihiD4va7pSA4+Jl9GfKHwaFeBwWIkYzp2lXBCTI5fyeOJLu0NUh50m2dXKE vLr3O2KQeqOtpPHISXkl9NjrWbVgv/QN5yRnmWU0AX7jPESlp7uCWxRWujA1UBv2AMF6lBIxoCFv cnQW/nmIwVF5nS1oTouqVKTfkPMraSYTopByfwxr/NwrkjYijMGzBj9M17Wb+QgOIWzvJ/ENb1b8 du90hrg4349BB6cbuB81bmUoHTJnTkXpITUL1PfpewH4tHZJJ5+PjO61r5F7LLfqLKFLk6B427Ce Xm1mTEiX+wCXphhe6GcjVq6VHvXDImIruv19GL8wjqKbTNQEGYe1P91nmx6I8SMGpcDlUXeCkSXY 6ehxB+Ivy3ECbbk6UUQ/Is2S5efNPsIF2YV5F5Et0J/6HKrTB9g84EhT9Zom6/HLRFCJqpPPlxoI iUF9A16XsONHW4oJbD0kF7ojS+WQ02y4YHQlTzNh3r+X4AH6wr9sXBSAIyGgrXU3xAM9pYy55Fpy 78bW1QJjOeG2Prt7hmsy8v3OZUapwhHYHM9ZxHeSDK7QkN19xjKXyOMCu2BiRt/QS6qn5RfSVLPK kBdqYy+9wzHRkoO5fNRLil3GaM66bDyNCsnlPQR/eLEVWYt5cL6be3kHk/Vr4spuW3AFBHhQ1rVO AN0Z48R58Dh4+dqy1HFZoMVgD7HFRY0GGomRRVfTK9GrGr1BjXTm3Pvoxvmf5lDAgn324i1XNNgY RNJyIhBXGx4B43W/xAPhzBtii3d5YtD1V7Cl0rQNzr8XpPBXL5uOIzOMJAYVWcImvhCXjW+bZymw OukpxBfNDORUJpKjFE+WdRK3cLzu26yIf+V6eAj/ow0o9A9PgrTIZOHMPkJqYwMMtqFO2B/94gJ/ OBqPPHanml9BiLokJzTVzO1uK+SBs0bYAEyVefuSQ7uwkp1BzjC2vSX/LDY1SQukc/K++J4L5emT Zxq06/TSiQxjTnqKWCaTE0tnApQs3K5T70sAHzStf7j+BwPYIua2FJqZ/2572nY8xlVWR8CH71Y/ y5CF8MAc1uvdjagjrDRHBnjqwUCsuvS2xi3ZfvwohgnMkzlptukI3yfvQhfkD+Vv8UU+WS12hBKE OfIfljl9WujuIhhN4nVgkGxaWc+VyWQCWqkc/mYHuuPMEXJt6zjAGLlBQeSaqlzjv9uFiJfUzyht BPIWQAYfWNAXjjFmBm8rT30p01rhfxELnUZtrQhwxpkxW2jevmqEGPGLlO474jew46UU+2qApXf6 7yFlaTZSDR9cQ627pZkSm3DZhEzDPdu0cUNbvWaykceIuQkYw1JGRZbcokPY76OGjJBPwgJPvAXv OIPY71FvmWAb64eeFG7VkNaXaWk09ldxGLG8jw9lwZSOEcR5GQjjqJFxajPzq6Ballq66t5D73Jw +iPRK07sx3T2HvK1iE7lLCzf4UaRkRyuusNZYaY6LGSZqS7EdWBerFFxucbGb1ri+QV1J+fQVaHu s6i5Ti3xMKPUVuBYakzAkqCmZVs+YHNAAk7oA14jOHrgiD8/DJzVWLyYaLBYHPvQUDf+xZYL4Z0u Om6yYBOKn0aE6PRThxU0XgZuPmjdBhX/y586zGy8DZhnuLbAXXTdgKBmuX3ux8P7YQZW8wlXWVpK 5kz32L8az4VizWsFQY2u+itttqieIomOKAH2daiqqzWd8bY6luVwmtOk6nxBS2f+Ylq5xON9GL+x 9DMIZPm3J/LpSKGDdq6xR8iEY8xRL2twKKwki1J29WB4oRKVGqGdV+aYJyzhcatmQo+XJPX/CxWe RkFzbDKwxdawgvBAIeQlCSDC5a1gGSapUSU8GMxm4ogP9+SH7wMAbynhyxN+Z2U4id3h1rWscVpJ bfJ8u91WNGrxxU7TSSu4tBetZiivLGh0xG0niG6ivkeYmIyvODoQynqn0qFGG2Z7JuU/taMJfM76 jRwFgYjuANg7waTj7Gw1I94tMZBaHW6+KSpvBEi6TIguVR0AoSm2zrMIYKE+ghl/loBHSe/XAmrb FM+QtR515yhu6QuBDtct6owTxKszG5o6ZjDmoV39NX+DkfJTIH0SZ3ST5u5iiNQBzaA65p2XIBKp fLZ5PWkpeKUIHaThoV+EJCwjD4z6PtBaPGLd+co2VqkKcAkxu+bjdjtUK/9gQ7royjKYuUIjuAtP uXV+wzmCmcowyf9UR4TvxCmmkugwvkqcN54Diogm5ex9mRlK59o9TYqsNdYco5djbgTu11LP7KzT 4QX3KZ1KkG+BrQAAAm0fT1S9PaJsggLYiSDAACB2PX74EnbV421jSkdFgt7kv4xiuYVY/Rg2McYF wNpCKPX1CxvZdZVWicl04jjvOASWq05rZi1P6IDGU+WSVIpfJX8tAeaHqn5GAIG+2LfrvmlaUCWp JxV5+PEmelEghv33j6RMUuSnwTAKgY+iLukUHOG5enyWGdWmwgHUkNAc4mCuH8HFzgAIqGTyFXpg +9sTTeMD1DjJkbSymlyp1hZ3yg0/3tqwDz3EL6oK2Cwxb9seOLJ1kdAQGZxe00jzGpRAzF8zQyIA ixrfRvNWAt+iZayNykUWZygTqXiFFak+5TePWeRj7kc8CjGO+J7PxaJtXxzpKWSljtKLsQPreRQP NKRF/nelG906qMhGSAws29zNiDa/CCZ0BjH9qlebnH3TU1sKF4RskebIVZtxR7pqBvKYg1IDIMyY U4NEB5ydHzUuOs3lRbze39+Qn9IkkmbftbfSYQInhjQksedDxjJhPJI9uhwn/c//HetpYBmYzoFy 6uLg2KvYbWVrcBC9seuF6X1EnVEd0ZZi6nst0uXYD7j0C5AgV5ObVfoVCIhiM5GYkYC37NnU9xEg YQKEUVXQJh7rOUG1wpJcuFzi27aqNPJtTz8I0ivRA7Q6KR5gAVUNkuPFOZukK+OHcVLQDSjIlSgU ARDTLDxr5inlNASKDv7qz9eRvJ92MDwh/6T0KiXU59NR3oZ4yDtt+rveNtXsw35dLCDDXoGYpBnX SKbxWoAY192C/h8rqZBD7oRhNFr8SL1DAZxf08OYPvy+fyyfPXrT951YKkSsEZ53etq0JSc/eldJ vH/5WlnepygRdVeo9wAXoyAkj01KTfIueWTxeUJefZhuby0wQkqB1rhC9KqwHWQ1jA8mYEpFqCF3 tZcJDU1SfO9DPVCIupbbAn1mB6ZmBUzMuPCmPDNYeZo0GE7VXfkHdS4+Qyu71JeBEw64i1FscxyJ ydYxNHNbfrEGPjcMlPfkXGuvLVLXbgN5fwGg0T6ry8dfaPz0RN311BttxSVUdZm2Z6vwVL4biGZK xiAoePl3LMsbrK4TMm7K5sBQ3LHsG9S0YjaumQ3mm4DgOLBiAMSey0xO6hOfEBMjlDKb2BXp4iZD ybNWDnCMKwNnNG6R7I2+CvKQaE7h5qhDe54ZnNV9RO3jA4zR39vRENIiItEBkeVZNQNBkeHk2GZG OE7Q3/3jZlFTAOpKdCydcSUOpV8h9LxiVgJBHy/FrqL7qjKy1xAXvENoCo6T8ptXM+/EE/rn6DUg Jzxt+VsqeTZ2KD3wU6kFMYC/Y/sbUPMpPpJEEI5DREY+XiGBRevELem0wF3pU9x9as8fDuzySoIK W8+rmOyCzSajBiiCX3M/W+Ye9qz5nR9cNiBLr5UruQXZWM8SsVmjJ7ZSzN2PKRrtl/9EU59zm5Dq 7V8MaJ9r55t/YdgsCd0rm3bDOkxhjyY00Q5ziKrk9bBb31iq2bEJTHAV510CyuDnP5BwhhvUBbh1 oJpONcHKxly9PYAXUVIyTJcd+wB+qs+elS+Lu4UHX/oxDq+z+V/Y8y6IPWrUGCzcSzUuarzlkMJY ZSJRsrFecoKRsfKW8wXFHHPd0IrzJ08iJPWhw3HZC3y5DOoCs14qoqyJE+P//j7nQpqUN2G+J0EI nYd6wOTdt+TsWS488VNRiN0h+ruqX4OzYAkvDvLlanQgehcWRNH1UuRUbYl+Div7P2FmZmBjTP0F XIFJf7FFF/Pa/A57YPCnJVIydLx//A6bJye9WrrejaVQCqw9WTRHYyOY51W2R5Xl55OrFAOAcAqk zWHI9IgiN/LSuN5gZTLbAkiJXSfPnAIekcWZtB+3f+xDWbXAfME5nEtSKWlJAEGxVJGvjxM8ixVe Rpdutu+9iwbhs7PFgSpiXLTJjYmUnWyTETlTmyGuU3vcADwpujcsDPzgDDnBR4+sgo99lyM/HZa0 HgdKHZMBnq/l9OqHAf0/olhAbFIgA3cjsSu/KGgk0L7hofFX+Jyvl3rjyCWPxOXaYOEr5I+LN1F3 c4+ceak2vzB8B6gfOwtcs6WV9EdGf18kU/vZBI07Vw0e6dUc9evNcrIB9xAm7nWwSu727XK/QchT TfUytcesb52sCw1CHAtSgdYGzp73yKGF2DcE8Qz/CyAZU+9mDQsEtiytAjAnJQLwVB0JlLVXYZIw kjbVzrqARHX0FuEdSgyyTKfD1oxO6jOyEwYv9pI1vA8v8UBAvfRjABTEp4O2sfJJdrdeSOBWzzOK /DziHOvHAUxTLue1hpQR8KBkx9Q+RHkIWj6K/s8403GK5bk/iP1cA495U206K8FJ9hOwhJVhDDX2 kNAwHvGlx6iStOddpmQFno4vzhUy+VEZi/pPVFma00Ja5SEyqJBNsqrcCG3LTvY+TkKQ4YTGq1AA kQl4WGRZHqNSQb8Y/0j/YmtJjdWnervdYiTGaqFeL5a/OsqXJfqMH32CXyuIst+aAsGkFOmnpNCD xJ+6iasGmW1QEwh2dh6MPiDV+bwVBZ4s/s4Qemvw9ATRf5BmgaVsdFnPK9AA7Yhbnj53vesNUUpZ AorV7IPYFdPZa/jW9cQkONUud124gyf3sBSxnrMTiHBlSQLoYe9F0bjncFrSJe7g5eNeCscjBphc t/t7jYtT0l5JKAmQMUDe9jrPsYLCa6FYHLP08CVIx8pU2nowpOhPJ8MdnrfhGxKHjVuarjQjuXh8 9sNtcD6n5qqvv4m3o/av3XCvXRJbsPWq3XkICnoCVJH2IKP5yKOC7rtjlbOGAddHjq0R65DSRLbZ 8QEsSDlVW2Z3muTcuHFBG1t01/Fcl0U0PKLJS9qeV07NgeFPtJhx49B5kUGrKJfYJaPzvGtgTwlo NIhKW/cx60UYfdUJdwnFUlhvBWqcmdeZLWikL7i7oItRCoiMLmwEvGVgOUcdSfpGMEFOPPYYfj3H kF609q14FR4fcDs7cQ+uxkz0854+XCSdjARv9Cl8Bo9IhQs0hgdWhNlv/LfRrtrYACy0RGVXlZa2 Uthud4Xt7EkmptNFjTdPm48Y0DBVHCMXSFsaerbAIlpK53CTGI3KcIR38aeBBCXQ5WJMkBy77+sq ojvGkSOJDqsUYdNT6crhEA10Jv2GdDYY+a1fA/KtRbMVQvaYzj/DRwq++LCSiojqWLg6qSQ7oFAK CW0IkhX6yve8VCeNpIzc+s2rIjlhiuTJhKi4Dkw2Ty6L9lck868ZNmFezOYkrOxaUqUCmri0BsCF EcMH7KY8ZG0ID3gFl0QBs6wdYTlRm/kB4emybTf3gNcE2trt81KK+VSpmQWjL6ZYscTs6t89PivO erMb7c7hgU5InS46A7Y6G6t4w8yvuXxMVruvfWu4nZHwyFdCD8jJC0IsOYDQULQkbADY4XPoknFp GHw+0mbeLwKPck2y5qeBTWqR5uQWyYKXl0sehX+NlUl2g73RCiGmUBqwfiQBdkzCyWLTcww5hHtn dB97gglaYxx7wXcnqY2m+ahvIFvnBJbSzYmPUL1G8b+mjyxnVdbbStbVLqn0BuIPQEdCwWtLeBXB t69245K6MrmCuBtT2/cZLzejQdL9Sh/PF5pQwkjkvc60zDNC7Wq+VnZREKkeV+wYyFBD+vjWCC3N 5ZkOCBh+5JHpb5vbBCkQ0duUITQyqaepGbHD9bgoaYmzau3YhwjMLj/Mz3UKMmAuzKb55UbTVRRQ DtjDNSqNda6axAkVaBQXITChSDLL2irdlW8LZb41EpwM92zxQ+KIcGy6w4sKioJobbt3pYhbNeQT kvbZKY278cap73ruBcpQ3oOrhPPGJK6awBNNR6PhwyaQH5gqAfa3R/EDnWect/3xKpkWRSh0g45E U32wK1lzVOHLdGvgZslN1U2bDo3xi17j7QSan9rh7hYSBgl4xJo+h5ly+rz9/rBWKgDvo5T1C1UA 3qH99Ejh+ytxhbXU1Wbf2+xrV0/uDi3LKnJbLd3QGDOxKcI2Yavpo7E8Us6g0X7rsObIO1JKhPBZ +kiBJ5mlFRbg6mR/TOglJbXiwmnrdUmM0xjZF0im1FeSRw17sqGYXy3zOYDO/meTetoC7QVnyN1y m2M8MqJnVJw9CAp9Pn2ZiMrlUTvrfHL6DmfFgwHIOTsRo0F3V5e05VQvUIGAFxOVvSKw2AVf6/9y NfWpCpH3zToqDSf3qJKrDx2HXkInQbEwCXJ+HZ8vRcyAMmnRRzS823E1Btdi9f70/ALWLavgi72Y D/P24WEmEkOeei1dY/X06CQpjuif65xh9pS0UJtcPKvCl9dlNjB2E5lbyaQ1bdRfQ8GCSk7Ug5lk JWwvs4krYeS5CcvbW4hL6m2XISi9r4zn/HmcUJ0H4YAVCpYlhzf6q1GFYbf1w6tmA30tqmvtuFXk X/Zv1dOVPIIaF5+Pg28efYpNHSCLUBUVpEAbc21IyvFunOfAfPPrneBQ3BYimKv0ytwRG0RDOpOg LIHtUlUDCLspDTkQN6F+1NQY7ggQ8kwr71O7Xe3EY8EhuuLQN28VqgvzdGKXxFD+ch9qE3YK+3ZN C4gLHPvKzcf0YNi6u5kWkYOHX8jgTu9iAwUPSZ/v/g8x686c3yafWMHwSaZZzhW7pk16J3r9/fH+ 0epFGLCgGmtPbF9Tar1wMjZJGVDci8Rt8eygzbvs4nws1EUL6dKFJfG+lXCuCMwdLjPH3NleWDAc eOCfOVkca/7OmWQcF+zRG4YTTHrxnSdBDRAF8ehzpAB/uheg0OWrS9Msua9G3tMtbSgXmyV2nTpi qOv5+St4bG0gx9wVABRZ/Cm/WVUp6RUSKWIom9z3xS+EAgaaN3+r4JvSO2yCL3mK/nzg2CXusGTG raOzNZI1fs4iu8+PsKs0jyfe3IYQe1gkyDlzAYTyWAT+oCkvke2ljmGXZDOqPIprR0nhwsLhRcxQ vfa52PXfJIwvnSquyNdm3XTXsD7mO7IDFcCnXlhzscjDBcnVmpFndRPI+R1z2qI1ggfGXJtJzI2a KSpK/sWB+XRUkZN9cg+m2XCD6bpjxtlyOmox1u/jywEu9DWGgWcvjQ5/AGjC1s4LxyjthA0pxjeo pJy/Q7SvHEJwj/VptzRCAAdA+L/4mJp30/0CA1S38UBEn+JjPiDYY/IpskPs0ghyy/ekgLs4rV3L 3ga4W9zItaa09FxtE3r9+JYaMj/RG/I2KIeTdH8m/Bet8j2iI31Tqv7oD/5VBcB9s5aoV6N2/Jiy H0jxt584x+hLw3/hkyp3RguoEpcbut8BOOOpxQvKB888ArJsrV0m7GiCi5HOgvmFmNGR3HTIZRwV 1MMnXYaXfk88iatjlM4xzTYJ3yBLeZv21m1aolg80yMl4ZwKGv6EGmOgTfJ0+/CiK2n++Tj4FMs2 ftMGf3085pCkIaAB2wgl+B55mvrM1cGdTTm/x4i286f6PcteV0ENE9QsnyvyJ+BD2NVTV/n9aoFp R8eC7dsEIq2o8v8nwfn4k4CuOTGC96VH0F+Sn2NQzJbvy+5mmkMquy5mE8wOxmmM8h3cjlLffTn/ /xOc5eV85xQmQbPrtj3Ta8qbev5rZD0nYt+oLKSBpfza3IikCN4YxYP2UetvwGZFRS31pVm/zwS9 eNOLGZe6vnpZJYPfL6749kKsgnc+B6p/964WKyyUDlrjJGMf0QQESDxd22nH5wxIBicRZsgNAQfC 4zDH2Q5XtdlJHAclzb5+8MLrL4uxeNXoi0oP0tyaahJz1zzq5vgz8WFotEqdtfQXDfLIr2lwZhSw A8D8sQsTllSl0WRRKZwJL6R/ZgdTNAFAQSOG9wpjlwfnBd8quOEZMbHhWyDEh5uKVKycQlrgjXWE J0a6gxGvko6w4AOKPuvirWc7YcE3imcJ0/gmGBQg92i3r9qCUG1IYdOYYgjlalZGm2w8P5HjaTYh VVHLPv9AUDzGD1fulzLpLhYwXFTwjqkLN5tnuwPRDlkVTOOuWDuV5/04WvXvKrmYp+SLHr+iirw4 1l6Vom7qAxxxJaO29tQoVwKkc5mdmDHhZPQfez7rFFXpIm3r+Ls0+r6cvzywwzGzwQnnbUTI3hS8 7ygavQBikQH7deS2B8IAQpV292i4a5vilMVlr8cxbV8f+rwZjA6UAu3rmyr2Bvce2FzffCuQb5aD TWeyRrorbkOBkukKNiH4jwgLEOHKSPI2Wn4HgegXTzUkviZ8klgcZW7dELaIu2VzQYjogrO4hKDQ 0uPidMQPxcgL4B1BGVOJvcRkDoE3twogqSau50Fw4IUTpqMp7fa6blfBNAbZXlf8iHUeFM1rERgG W3AvsNVe1B4Hdhz16LjVai+QrgqY8gojm5EfPeFUDmyV88p6V0BVABsZFrBu8NBQO+UBebZeypZF B+Su/JDQox7pOFLKIuYKOtJmpl2LOmIrIiRdkTqhhUsSVwzlj7G/E3WxIcDS1YVxINFgGAQU/4Ib EuUGIR2BDzM0TxKDBa455Nw8BRw74EJ8bsQ0tm1Zih+R++uI8FFw2up7cW9hVOGanOcO3UbDEMBR Qw0IYTvs4J3qxWcCjcT5AVWyU62zyRehopvJ34onootbMNFXwm9lBzjivbC9yy/A8VAhcj4Lqnw+ edCFWttJdnvySmEIWhJLOrpDR8VJWpr9iihvyuNhpHmnXrvUoqMS0S+wgWS8QJRJj0ZI/zfTP36z cgv6vWIUhmsfGorEo3zFeKlFwK5DBxkMo36XWLGvCa2z9H562Jrmx19IDIP60uEVlP8ZTjazMTAS a7g4AytAuraCeqShA+BbmChlDMLVBe5/jTNsuHyHcAY2bEqOuEEKGuN/d3j9V1m3rd3FF0MdPrCC T8vnEuWSDvLpPQn2QZuc6WhpTH/KNJnFHpXMfMXBG2e0WIehLtVRICyvQTyLG8Ml1D9L/FgitiEM X66DkYzPr+hWK4W4qFtDLh6QojAhP5wH6fchZGtxIKQ7SmbAxyzV9r/JUT5fACS3TvyDEXVXbomK Hp3nwi4ALhyuR/nPCNfoUB4VEfPZsCVP3cQ/KclRMIxHeROTua7aBRMmjl6mOJH3Q5GOx+d1QJHU SrLwwy5v7aWThTGxjyJKyCAOnRt57Jk00gmFN5/YD5r3KUgtwFWGXeDQLWKUNI4dX1xg/+aU/+RK LclofDyxsvXmzhMlpcZ3wfUkATof6sgSq4s8BtkaQBPcvGBV24Hm4eZKLEvUZ3W2JKwIL/ZyI49d MeNAuBe/U0orHdtGP2pUTMSb/mj95qyW/5D84aDhHPOlxII0tqoPUPl4G2YeZtT4lyf/qKhalK0f ZZrvgt/QAkm0rZUKpzpq2P7XtQDICbgffQYxUAQCHmC4n9DL3+VvIcfu3P7PmXtqtt758U4RHsZG A0uKJTpJ9E5rdmxvEOKmDtDiGIi//rxkyo2GcoarBhswUCPc4Ifw4yJHy0KgRsakWYumleiuCe68 C+LLGgCMcogLNPZ1mYX1WLTEuM5FrfKaosXSu/tE3e8EkcTMa+DdmMgegewirBI6M1BAly8TGPFq n8/BjzAE2+kKP99XdkH6IwQWmuRCHqt74LbNWXtUpcZLrGM3bc8TcSs59nK3K7l1T5iVuTudf9US rwKjEa+qSFj5RD+ZJFIVqCqu+XqyrUhs60UUcZa4YDPtfCE7vrjhZ/GtFKKwmlqGow14mOgzG+U8 Ar6D/1BnzBnWR5DzGKCCUplXLU1tySgjpeorKTGQDlmuW4D93PLoCKq0DLg4TnQVNMnD0c/97xcw tHlHKV0dFSWftc6jS6CqAlnOcajfUxb+kHLAnOt270r3PiGq77KHxpnDApb3/8/gMDYh1PyeeuuX SbSdeTQ+YdKZAzcDbfK4XbxBfpnohuZYIvLQy4s9I2uiKraIfIypAonG205pLYkgv7QU2ZujohYG lOwy+ZV+8nkBDAjEc89VQX520X47J5mgvtNuWWJpLL9kIeuQ+CFM+nCLwBP5qfFDckkOPqT9hYA+ B6suFLKOiv9tX+yh3Dr3xRwICoHfryEreuCwFFWVWK10SBePBc9pytE2c1tg6j1j1xTFVJ5MaH/0 iWqmEUB6CO9RD4VJIHxXoSoXz/pYuD8bEbwOs2GJ/7H6MjK9ynJ/i4hIcA+dmA+7oOI1XTmFgbCl fNaQ8ghORQHPuF1+3pHMMGnarHH1Du8WTGIeYIQzQM6fpEk1S9LXoQZ2BbaqIcH/cqsqbAybCmaR mBiNbKXInq3MvrjEzBavZ6/cicIYxsfWmzRosz6VZC0a9ze+9A5cyK4eSKIhqM+H+cp4h6jPetHg yOi2xvd1CcP4elcKQpb/HcfjuY0Bq/Ls3FSslCW97xLdzNjPd1TTMonI9bPid/E2AI2SuCZjgIsQ Iz2EHq24zZmx9XSMYcCX9cw25wUpP9yqDN68sq5hFKYxc3Lg8qVl2ZLTnBYjli92axUCqvz1weD1 SopbK8sn6j8kI+EvdhuveBs99vPvdxUKVGZrcTZclxcnKOdj+VSBov/H2Rywg48FFwB2vTiic3fy 2NoqBvRqdQo7b2Y+ggFzc6507744PNDFFxETbCSHDRx4Hlp/IGx0NwNJOaoJHBqF49j9g+yvUGS/ Pyim/XkGi2TgGLRv7o0UCQWsrN5Jv5mWtwcV0DaAPvip0eNSSRu0aowRVVsyBZKWJlpVMhbZKrJL WKeMGvIaJpmbqSu53JGC/lmTKVhvWjJcGglVzFxoqbVDQT2GYBWeUiYaTXkt9ZfEx1ovetoRoQUD gy1jCiUEkQ5NyGA7UP8/6j/iNJHAk8UTje/Zba0SR0ooGq7sunzc1dnENgQhLdH0b1+Nvaw57Mag 96Fx/Fk3ht1IP/BEcPPVBDsnB6RmhD+Yle8omSc4w109GJ/QfaAxgr5YQwunLGed+GDmNcGZmEjR FvbpE230XJ2fWZeQ18PjJ881C9vZQNn+49XNfZ0xrqIaxq0QFeJ6xE4DIogqmH9QwtWbZvWOpwng vB+ofpqkgK7oTuWr4p+mO90wnC+bbCQN5wgXPeiy6yKQr1oaQTWXIO5x5lalnvCFMZuhgD9zsQvz AN1q0kJOvKqYtYvNdpi4zjEbIoE2L7FlPc2LvhUE7o4fVD1QjVP8uzwYJsds5bU2gmmFyKjSsfXU EPscFyFaPJRENKAXMfZBKz2eEqf5kPumDD5FPoQN2DGPHBe6Avu0CbNwINPJIsron5TimKtLI9TP KMrKBwg0AeCQTh5ZkGNh4ckypgr7kZtQSqR+9lx7VXTxEFcRWKQZ+ymri4Y7pf6cdble3k0c2U33 mIGZ6IiiDZZNz3I6ix4xY/juJivIUuifylTg1UIbj8ozAYCzVgoUsh+c1r3jTjYQKYO/XA9BgGVQ 0BvJAmiywB/7vhpPDouSAaPvU38E9K1K181sxzdb1jUWJFUnDEDGSGS+6BXn+gHACM06c5844iZx sYdwDMPTRKdIEGfAJJzqLUdW9FDaTcjPOcwIzC3w4tECdLZ3179QGGOhBts/t6zzeI6rWmYf+qvP g8IpS15qhp8Wd/NknZVkC4eufpwxKTXCcvSC+4l8BP+hUidmAG/7gzyG/8OEczYvaQOKNx3TgfY3 BWLETD0kg6beZV0Yf2Dz7kW+sJIe3WQ6mgX01FS6W6ke8VYkeA0+Fpg/UD+ftbJyNL8a/xs7D8QE ZnYmiY3eLmen0rS22wrMMvBXG6OSijxgpUaTZeB12jHe5xvVJJDv/50GpfKFa6NxjuI8+brFG9bw zwKEMVCKcIW+giDlA0XroFsw+nHqJNbXOyESCumNA7h+pXTJOamiUeaCiVPTcbySviCSkHChPEo1 3XZiqliQlSOA+nc58L9hV06a9O7age+pFSgQBFGeAesvsD9T8l3h93q4EwV4/EmmIMRpnWxb4Fr8 3jvmSO3PSoicQdW1HHd5/tINhryXOcKvo9x99K4vjzirjMbfSH88OIPZuu2k0x5Vtr6Vx+FCDoCj z6DQ8GziOJfYHhN9UinT3lok1JmUCG+vz8/cjoc9VyfPB/pDL8MsP32JiTwpaHt59Xmg5L6r1ju5 gfH2FsIi2EHAKX8xeuNWeFPNj+OD1nNOMkLhCv0mQ6yE8hvWLm8fgS4Ev0DdAfdKgXdfek0Ua+eW DUnEZI65QHEUxTyMhR9I42937SeJ5rFrcIcIxMTfs1cTkGffsnenP9ucf1ldOGAxZa30mB9ak/B+ lrYhwHPoFcxcqLaLU7xzXO1O/xreNalvu+rrDAMRn4XJrLuiTocJv63/r5fx2MUD549QPu1XD7zt GH4MSixyC/HHyMEax3IWS1veHxvN2PNlQAXZFLcydMIWnccjrR9a+ZU6yzLQuP1s86QQk/+/A1Jp O0MGT3zY/paC0G5zTgjUn0xKAVuTmehleI9VqipRI0NiSJs9Gk6PF6E7tjHcQRLHK35aURZnh4PC VJTwvGiK62yA/gqBq2Od2gr29050XWIUQWXQtW0O8ygt/XV310XtEJ1sC+ai9/N4XtwTX1phKNK0 1XJ4LBHquHMUVAljh0wJYfQrFdFWJso9yX2Y48nE14gP/U8ZPk++jKCBBVAQz8STBdGsH0PBZFtO NOk8fV6arGCYLIMBm77bOZoCUipytF4PUAsdIBFxg1yEHml+/BJegSraVwzIlFWRLBTOuIvpQb+r /8KWaKmS3l3qIF3mnvS8w1L4kCk7Ra4svv9xjBZat4cQHbKEjjfIbcJ8+BXl+WKDfMQtpaW2FtYN 9r6EcOgYKTbbGK073WC3NtAXIhborwKCplo9wTQnb4k9jSC4ViDniFFSCUum3V3tVqs2rbd/mjLr 6YPoyUpmthp7x4YAOajdW4a+jnfB/HWJqKd74hF7CgJGjzJmr+jkGWUhTy9kRPEqpQrbix8AJ7n6 0aMqvZSvH0Kq9EIgW6NxJeC28I/2JILaggz54VHo0tGOsToXYUk4lCgBzWhQugOmEAOKZxBCN0GS wN9iU3bLlGQIA0VpfqEq5NvejmG2/lyGmKgSMhLYti+d55H5mZ3GhKsSLuLtlPlIsnkdOQ8xs2Uz yO6kIufytzR9qqljt58fji3fq+E+Xz5YVGGPVV6+IrhNeciIi/QODujmuxUY/PltC/QwNA3W5lSh mlnCxvTwz9YsmEAxWvlT0m8S0ouFFZwHzgHsq6eva7R4i1qsHuFYd3C79sJs+ecV5JoPciPXGXxn iLKinZeJg9ANWA+j+Jtr2/FpyTJTX1VwXZI8F542qh2ETLzQuOPDOWkntoY8uM7RXD6UCywi6zxZ iZT2yG3+KBGQa73zBVGd9vNimhXe47fNYKhOqltNvKRqw6pbXUeZ9N25QgLAm5J773K0yxO9CeNk BYkoiq3NCjXPZhayQXPTRK6qD9SBF2QpqW0Vr7QcKS5SSetcW2+BTrEwqK9BPwu+bdG0urEkKtfE i1YnzlcX74BI8FjsAk4sWdN0f2psrxbe167fUIEerzRjKD2LdShBlzQZKfYSHnsh/ideR/BizjXV 2ocCcFiUT2p5HZlYe0JMqyEx7vDI/mZKyK3t7BZvA3gArI4WXxD5CIP6cOHzrRclhdZP2qPqnT8Y 8qppShhgEpAlxs0BdFjFCAZ5XgYGCEq87cNUZ9lDmUIIYN6O1OrjAG07VW9zMKOcoZDCk/yV773e X3LZwGBOVdVbjZUt7xZ6NpiFwmaC5bG3bJbRt/app9O69GvXhH7D9qiXDa7In8GX3VIMl4MTUhoM pXxrizTRkPNZIl+RJGBMu3Ga9vlj34eSBclEfn8qoEFQMsEsX7jySmVGD5Tgc1ImRCMbPOXRcyn4 ACDs/nyCvS1k5cbbucwElz2nMGzibKVHNm+TZ2UaThfVqigvEfUCF7G5fvMcZwcNg9z/XtywkIhB 5Ab629PXFq9Dx9aNWixFMVGjOMkm0fhLN/pDv9xzQqFaWHRSasC7V+zoRa5a4N49UUP0sQeKRrKo pZDEDXDGxvpKy/t1xXoB/qe74YXCXX9yhY9fWtp2d7ixxxbbEj5F8MKEWW2O0Gzlvp1uX8vNOUke e/GVNgaN+u6rURZqyDfWXJksaQTEXZ3WHZJVvD8Gn/ORGpYrSm1hzlxxWIRMhviEYF5ODkBGiREa 96il1NPRUac+LFD/LY5jLYX4Q1fDTKNLzsPqpbmkbZVCTLhvve7pcVv2rKubUzXJGwI9VUiFX3u7 XOPYRtEIWwZvo4J8CidHQ4e1AHEgXDfaR0OqFhiLCKFJz9yopPzDL+iv3/4eigTo9x4thlvhIsva plORzsX5l++zPBWwVRc/NaSuG+Fj5g3QWCKNNqADcEFUJyNUE9h3rBT7gT6CRnXERh6f2RF2eKDn 5J1oJuG21ep+z9/VAX96XkdZ7ILmku1OqVcysqlIWBGbtpEqzy7tNY+/gN7Mrg/g4IuWeCOOQoqR jKdy7adOfgBO3+DmbPzp1pJH9SL6GulY4Ic0k0SrOwyqtQn8Vdzgk4xEe7pAeG4YLErqvKOlnkEW p6sWK0eMsNpZ4/sazNWe5d/BozBiUHndOrR3yCcLJX0ch9wFCToC7GSfE2cBFjUpI7/Vkwf4RQsa exIJnjSzghFipAKeK2OO5b8+Mv2ZzEfPMITIB4B7HEtjeZzI5tzjuRk9e1Zxc5JbOsM5SrGuF0Eu Mawk6Mxpk0ggqkxHgRF9jaUUzF8W9zZFNus8fFDFm4JhaWz8QEQwbtwOr8nj43E8nHI394SGOJC1 eTPo8Xw6vMYnQHa8rXiF/8kXKcvQ+5pBFwAc0smnk84pHA7s6kKQ3kTXRRjwbxj1WRUX5LBWIQXx BF1h4gSAtQslZ4lmgktSyYYiFioG7cZ3WFoLb/wKE1H5jFOjiPXuUWUCOIP4oBUx3cyvwy7OP7Yl /ATjGbcOsdHgkXB0OhhAOh40GCR3QEYH6O1JZo12KAtt4QIaWLtwB5mD9JoIYK77tkhSEHFUx72r 2S4iqvZ/YW5tO67HC3Hqg9nIJNa27E/OEFW0S3gt69J0xFJQJMK1tWuq+zLLOzVracP0XedPdIMa gLpHZmNrBxx9jE4+y0fCRRjbMlYdjiU8ZAfsInyeA3HlDX0zid27MP2hAbTd0uzTxK0y2IpMgPUB PdrydyIMHCgp9dRnsrs44nLGScR+JslqHpSlTkGVbs3Q6uWkuCoz08sur0fhf03rnbiCqVF8zUc7 s9PUdDK5hGTWWxiSNUmNN3YV4o0mg+rgL4dvTAwqQcoV8/uVEXOH0K2B6H7EjKkLn8f9VxhdmJ96 m2Lr5p2GVfhmOzRw9fFrQ7U+GbVLiXNDSnV6bzq2qieclm4mKofnv3UcwwnxgDRVgm94Z9FJz8T9 vQigVWLc5MTt6GLvoEHJ2Fw0274Cc2K3l0L7thkYRh2ghyFiqvXfizlFA9S1JQi94u9BJLM/J/Gz 834JHsP7yo/PNCWM8sfCKa5O9Y/t4mMJEAHdV18Pgs+HFClsI3Pf5jG2gqozP9qb20zC0TzlodmG TMLIoBm1gSpenblh3bjS32PRaUaemtzUhQMmuunpmJnoAxQOcb6nQV40yTuzBt/DbMubId++6fwR lwHjnEOJgA53RrGd0smsocJ3Nb2+QnebvEAUc04/rf5dFKUK9IfnjvhnVZ4klYDt5dNzI5SjbP1S oi8z+dsMQ+cj3W6gqkP5dCrOqq0nlwsb61iB/ebezcOOnRni3/GyzT1Rb/sD5mAOkEGPPWbQmaLZ jBrtzQD8iVitcuECoPPCzEU3fbVUAbFi63ON/LvwvorQOh8TEf0u+VMXb+8MYCUkkhUVcqyxGZEZ R72GfY8e3ijz2/YhICJr1646mu4XZ1Usob0zkJgON+8FjX8iha+iUwuND/D36poFKFD/Wy/UYv4J 1ZZ3LszcShDNXvbZQEPs8nw6fYiNEG3Xwwk9hCYL6o8gto4bx4NuIgnIgmbJS/+53yEIO2Tl4Oho eiTkEpNTVGAt//sUAhe9TVnzfUSdxgsw0kjS+mYMPpGjaSeWaBywec7/kDrHeovlQx96iXxwmNfz rot/GIPhw0fFfstx/KSyrOJuy9ZyXrfMnYC947d/6FDGM3eSK8Yele0T7ogXbw9cJSMltf+/5oXt llpO9FjTxYpPUbaN1OvbaIjG1/K8aXG8QWgTTBacvHhHndRSgtlY5WA9+iwfj6/889bbWXJUOyWp OKy6uLQZzp27deB4UVKXS8rZWZ1MxOyBl4V/1VeYGGn4H6aqUs/MUqbRpHZ5R9f8q/mBkTuBeYak 0vFmBlaCekhjtD2uo76b1+EB+ZTh4CMvT7QoyN3vWe+aSl7s8d4yO0CPwpavB6s2s2Ba7AX+ziqD Haj79ciqSS51A6CqbwbrFOGDpe0iZhRLSHJPCoqKk51dd0VzC8z5tgHBlpW/NkjUlP6DhIAGj6+U VLgDsb6J7x8kbU6CYIqnl8J5W/QG4MqhIwv80K6vkPhS14qsuV9MwJEau8cGb1G86JzOA3dJmhqt OOlfF+QcBYVFtty+3XcalexsNOqd9p+2E/9DynmFz5M3W/heoylpSg7AV/BsvG44grKq7fycARJW 7GQVi4xxNS+s79ocpYZt57nxlRi2PJNDVNzECxgUiB0buPEidIfxVWcK3h5aX47B8MGjENLIOuAn 3xbpxzyiK8jIuuKoQW9Z3qBtbM80HiObPaxxK9oJrvPyjErTEsi96yaXWndwCz+ouIbH0LKHoB9K srF5AeHxCbZsgAmXieqs3in3ocBxYxlxllmdHt4KLZNNhtleLFYdGOKcCwVxFIS8+Bvs/J2ntHUd NmSy7fRhh0D0vq+mZeUFYYfM7SO6bPQJN0PvbInAQvBYnFEHezx5l+PhAwOwWlVRWXMnBDdlU51O FrrTDiguqq6nXlKC2eCKjcex9BasqFeru22QO6o1rgLVI32Du6S+a/SB0pCtFYEM5JayLnWGS54M Evl6EtimBWZTejpIxMOOe9wI5dB0h/39N+y0tyZB91zwMrZRDA8VH3B+UQc5+idjNNOo5HzJ2/km cxMymrqwrUk8mPcbVkzuOr5fLrRewHEsu5pxSaVzDJcBQqkIW3hptThZnr8nZDksnz6/V6NzauOn hIJLiDD41WBdLC/0A5HIlc+GpC4JjndTDntOJrYQVK1oPxaYJedmdzuGT2CU3+c7MLObvKtVV6AJ 89THpBDS//ho8VfKSkXkczuBMYNG4Ot5VFSpU3EctRl/z6zEOThLmKEi21BrbD4FNHqT+8XbhiKH SZGsAdg9lCO4s2Vi9NEaB58IYoyuz7bXN8jnNDnsDOZ8Xe43Gr5Q+DGPd2ZZn8d01kfAUl41UVl6 Ob8oK4TYelGe3KpWQr5jsyWO7G+IQTzNQ7uP7JouiR/XyAjDvlgCyu2NPqeEPt3ft7fpb2g3BOqd qhdsJ7sdXors6VvQe8RsOWqE+vrNwI4XExjviIm+13wdYjKtw2Y+DQ9mCKUaAr6naxwvtA24WSau bB6h+0IZ428u22vcuLcFs+KryenDLlaF3FKFpcQJh/7ZSLLGEZ33Zq30SWpHZfS/6CAR7dnXKP/F we4H7R37Kco4utqynWOjfE0rzLzQWJtKkClPM4d1ZiAA9YzqK24I5bYfW8+XJSAGIGjsurHWDUjm vaw3q7AQy0HPCSGEIu5e6lH8Jo0saoJ63rGShmLg6/Cw/vYfvpXoiTmsFVJe6SBhLf/ba0ifz2iJ wHr3i5qw3Id1O7TnclzIAZ48jTK254mqWlAhJAHxYeDe8p9N7h3r6ipcQS47DfvYTtKRekIOH9Pv 2A/inUY3sd6IHGiRYIks3qvdrBU6p5PG0YHmDca+PazMg1c7FMjlEgmD42SkoaB+pxaFejyI99qE Qc1q+f03u9P5PvhelSpGNMRGZpHMDByn8D+QMoyd16KrNjM9KAyleF1cd40QWjTv7jIeS2gCTH9m R/T5TwwY4oxnBqm9+FRxb/Rek9MQxYwQBMDtAX28ogkoB1Oc0qqcrifipJN20PsKwynNRSb9nyv2 jCImnZqvj4Ual5BuQUSuoyorRa1ar2MaMUvhQN5gLxe0Elopa7uVGwWGcffqoguweEACXRMxn5lX lzvDewF/6wfaLG7bZEeUgMjSVyy/sS3jOvRh/0mhHaHhbc9gJLFtt0CxrJxKtkp0kopCk675VA1X U8cXO8g+7IZ3lzOtj88m1jS7+EfBDW6j28JuvRd0tYl0YNHAia9R0wqwTIReO+nW8Qh/q52ktDzs h4hA2aqbbpoffiVC708lc4ZhWFbkscnkItge0eFnvIkOoQUSsc9ZLavfMixTSXElJaYixCz+HkoA 4kDwVftAV/2dQllvWMnFpwc2KuseoLtQpojXRwo0LdL6JucSNv039Puo8VGpuGO/+9AtuXomYu7M KQwjw9AYHFfX+qtOK54FKOEfyKbNEsnhA9suyAC8SEY9MJZtTd7v6pDFdSjrWgiK8XjRD7GmeZqA OCNgJtyswtRkZ11balcLwi0XHaqsBSZ9eIAIhdBkg6GuAOhhq/vB1p/iIFhp4Q0dQlg6e75KDFTB LF7H/cm8k4mvbsNDsn9IrBPQ8Klk2I+hys4E0kDJbvnwM+Lb/FbJ/5pPTrd+lv0d+0q1MiAY09be W5CQHcae+Gg5CL7iXSGok4XEpunC/tY3M7m4yqbrXm/pwb4sMjKLRF0XKKOoGPljIoK6WIrlf5Rl TT62U/9XDCECRRb4lG1dJBUvjhgWd+Z5SJ8WWn7UM3gAByEGqr+0R+flApenTH7jcnmzvqrdjFjQ 2OPdDJY6kLLfwKa0YquJ0fxYLomLHe2hkmdkmYwh47sMd5YvaTooA368upmraEZDvn2yr8K9PWXN 7T8amVcYAxYEvL2QJlmv4lFfc2ogHbk1S09rXn90K/n8+l+aSkCw29LMp2s6kuaDCTx/2rizAzPS C7eWzguRcZYGtVPVxe//BVlXUj9ilAgODAkdoT2e91lu6Ktg2jRhOlmT1aVlHmRXitBc4HxR1iyu asXu6HJgE8EZN1fdUaedPjrAuTmTdzb0+2oegca/uHISHg1L8QeFTUQzZjb4gAVFb+FcproAVVX1 Wm5srKmAPaAMQuHJo/hvfx7J14KdggnsdhpATNpYvZN55EsEQ7GNYBcja/6l5+333IP5gNhk8S14 NM2bNUeEPNXdQuwZz6p76+zUecWj3ZK6R4VjjgCjGiMtwdkW6URsQySc2UklvtE6kE7jQT4QJ2fJ Xx6C+N76IFlsasEMswKQrZty4hHKvAxP6LPqEmivQTqLphPkEeSuBQ0/lRq3Q7WSeXBuWYFvs3tw ClZSefgFl3yzvWJMSGCBXBepd+8IhhMmSYdQICA84Tu1Ve3G8R4CEN9qpjFO2bpyeK0t6PG8YncM An3H89yqNxYs4sDcvuKEc/EFB8SjkFeb+MdQWjX2jC2R0nxf8RYL2MqnH0z5TIieP/k3Q17iT4cB WA0Lp832hWWNOUfrkIZvYKwlIyAHA0QGCzhHDhXt8wJF5NBMdtdJGvCiGijRYaJuPa0Rea9sLThJ EBU01ED9nUP5fVLCBnmPpN2ZMX47+q+AKJ5/qLO7ouvpEu27ccWpxeUfVaQ1EFbNACt+FZHiAF7d KHX/2sbFLG+E4iwfXVVSAj23W3GON+asmxReqaWQFEZR+UadOY+OoU9dwdPvPc2XsIc3EY6qCs8v y/Bjd/q8C97stD+PD0/vgeVh5DPTvVLkqAT4WpMF5+nS6k05tU+uEeG2g6Jmmdd5wAVaRarJ/1pQ b1L+eNJe8TIZc1yjjlUNy/ijvtO1XzWie4obMIhcXI4wbR3MtQPfKtirhQN3KG2C1+hYdaTWfU2T tSpTlMQyfqatmlgasVF2flrOBDfH+qFcSWphGplMLcy/aqbkB8aDiBFVUhH4tt0O/mgG0YD8L68r MUDtBvXhcOOW7eTIsSHCvd7YkGO5gPMnTHF1+czxuGH/4Q9l338A3NUCtnLM4NJH/dVUaksNEgc3 BcAsEqQNkuocW3qL7Ft8EbS1py8+evu4Dqul+MRqK9sS0aBDVpY+03iiFDnC3ucV0aBtpoOTycVu ByNsxLrT6OTGZWiMNeowOAuui4rrEj+PM6vNZou/Ml7DurcQA3rmIF0oMAzgW3V8EOGg7a89jMnA Vn4BNNMzhfIRehciyJ99wHOro1durqcnxZ13W1Wph/QCqBQWFacSbv4PpSsB7g1+EOBL86xdgCC1 hc5nXudjtzkoMH4CXKRhVDoIbB0sVGNagjegazyJfscszxHAvSU2evorv3fHpIZx6CCvwn6JTP1c gLSjBfvbwDKhMP5OEGq4WBUdK5H28lIMbnGxoBTCb21AoUM/OO3MQLaPKMSsBs6OH4D/Zq2fxjTZ i90UYnWyIMX+K67E1+3J2/dfDRE3jQwxhe4i6klrHTkg2aJG9hAV7Zdn9My9ORATrg8cFdnIE15W 1gATj20nLg6UaOrNJ193/nv3CdQKIRom5y1asy8iIIChoiBQVFMsphKgTRQff6fv8Jx5hOP8j7kE 6RrAyJWCApUtt+HfQBIdDd0stqsRVsUfpbzxFYWN0FDR87f94Fi7i9G69AaTPXfZf0G1AjwnxgIg qofZk4YysdFPDw4LmNkTk3sqLZdTC4t3y0qVWLKNFkqqAS996IbIiD1Ya9xUHSeGr4H9ydhiqZem CzhaN3wPHQf2y1kQ5Mw5DMg7ZADK7sNpcVi+/TLs6lx2AaDP61/06ijlWdzo0tPKMwlOtfU8Ycpv 4rR8dphXJEU/zdNmHErCHjTtNBId2tXJlwvL1kwIYxTi3cD87BLkaER4/P0lACnAtuPp3hKckCd9 ZPffd6G4QuaZZhJcd9JLk9H1qE0tMzMbrfHFZKnYxovS8Fq3TvV0+nS85AQld4r902Z12dnZK5cR W947Ia56clPcnuuB2iyFSaOChZlx1/FqRfXzfOHFqIsi2M2n/HdZ9t59vkEAB0vOb3zCL1m+iG4F gT43JIoDSXPSySvAE1li19MBlT86M2H0EiEGSvebj8TwbrTJ4rGR5KqIRO4OrRCL7lyLcW25o54D EmAe6KcIX3Agky1SDxbr9FMmZ3GDxXLzFfX57dwU4c1c7Nqrh31fT9zx6BOnYs48AE88AOxX/gHr QjTg7J0OqcQJIxwFVAxV3BRsdeErp/8cQuy312EcD0De7PaABqgXKfHsRoXQYNt+mOMKlC0ex0Ko pnfmA13wZl8AZ77wkFpwCQQSbhlb3MQT/NkSkQRrTkxQT9OFnfpFNuaN9iGSaaHxgLdoDERpDWeH q+6YfoWknRgqWOntD0GzY5uWinU4j4Lbs6sCRf33Cr/NncsGuls5AjRyWYXVWASZLyPUUgKrjdPE hSNuK3aG4kmsc/ZZu2zO9hGBlBTbwOW6l8ldxDN5qD59cGXG4n8mIErjCayhm+RGFHt4wvGZJN/f SHIjeTq63zmVFjvGXUBahWhcKuNlyjFAndkgAQXGaSzVvLYVIBJ5KgmzNnmSZsqezc1PVC53UA4K CWSL9rTwCT6RXDFegKmN9fchqE4QT0+JNnOZuCIN5dxdBAs3qxty6BMOLdBdDo1A0BnhmeqSfCLh 763B2Ls342bL5caxqBwhs5VpW0ZJQm5JXZLk6nxHO8G1ck5jpVBWjkE8QqKdbIfuYzy/26ATDNnL LICEW9J25rSxn2SMMoZftOVqc7F3xh8PMHvJ2dV8e95YU7LprqrDja/H8+DsRIU02UjTFwhRKZQ3 mfD/PGtabSbg9c1wRmUphxxO89i5itxLqOHc6/ua8i2Li2sccy9j68iiOCpeEjl5a0AbV2dhQfe3 3tCt+f9FkTA32kJuTffPeA6DjULOb4IwDfNjziDan1z5kfU5/qwr5xnCZ+3E5QdQ3560LYAl/XFE Y+7UwLSGSMAF4YwSi2KQffQBqaLIctl3NP87UQqr+OEgpZicy+yWkmYeltgXwdc8WONwrJVHk86K gwNNn3P1k6Mru2tpnWyNsf9N7g603QEfkU+AZdurAyCuvHF1rMt7nTcyEgeBMmAFLMeA1Xr1TuT7 e2lPHX3zU2lCEquBoNOBcehSgGcQePjj1O+Euy6WrEHQcL6tm3KqW2T5tCVer04aO5T0MyX+5WEf wHbOLn4vtyjvwsSztHVrr0HEUHHZ+CaHvQM8kW2MLBseDkTP4GIGn0CytlFHsc6uxIjEeKBC4QDx MUYrGo58r8BL9HsjZQkYzVj0Tel6MTaUDCZtQKZkgbZmLbBhG9E18ekIJTnibSCBTBLyDvMGPTQc azUERjGfU3+1A+I4Z9WplL6Z8nu7toA5E/7mIkU+8udjo6Yk35SIFlcmh9JWVwwjT+2/iBLSZSnk x7HK52yDuifxt0t9wuv3TXQvQBDUupvFqwVZCM4MwHlBiLN0dIt3z1upchUkfy/7GCU2Ib6cJqUN J8rkm8wJPBCYlOQP76FA1ysbqaJXFZUeyt4F0ERk3uINflRM2SvhfINaXNxb3BEpDfZpkxtTRJX5 XngLli08umbq+uYReoAtb/0zEqWiGC8PxLLo+K74kqR5kt+lR8kKxOWgpIxsBV7iuj9b+Qp5Y5pu nLZnnsNjmCcZYjyoQEHp/iLxDjconHchPXFAe0k25PLJFyUKtiHGJhd6C1OBPIrq1I8nvzBHiUZw ZfWMSCH+etjI5R4LTys4zpwCv+dwTVu5Tfr9bOo7m1uMtTefllClbaUryvoXiT4fQwqePvQjhCfq G9cNMuGrhPk0WDZXJnFO8JUUcjBZWnj2//GA+KT+LJnk0QGahh/XhYlfAtOKBrd4vFm4Ya6GtF09 Lk42PFw7ux5OMgpfblJPXYOdAyjOozf+wiTqxoVGqK4WpuKrCDF9t075vl+LOwaKV4ERkrBUIggI KG9L+WOtpRgctF5+JtKYAAQV8WsqpRfMvj4odj4TSpyW12jX8fA3BX7Ila6zSOMmHekb2l7WAgoi mrME9WtS91xgheMv6YxS3APEwuPHU9X1Rr8cc2pTu3Mt+JD4A8iTuPXjPGVk44lW1e1VdyRkYbgv Uf7WM3nuGayGHp0fE4SPvAnDiYPpnxPzphyV7otqLb6dAlxyc2Per2HMeif+Y4cngSAxHy5Qzqpc 8OJdRLnRmTLdLSvSW16aqxLXtqEiCfyAzYcxu/3WU8hdjUAPbDvHHzvELvIeYCMksaMdcQHAIym+ EYMcmRNEkuEm+HnCC5JSuoT5UPq9n8G+zbzh9pZUtImnLNmmRF8eiDafC4Oi06JhotHxpmIr/Kcr TV8XTrbs7cGtcybXvCmLqTfDJKUY1tgJsjiLoySOisn58KOeWvHZCQc5Eo9T8Ttc0W/UJuWitSBk RDrOdG7zoaodYH6UcHbpdb7HE+aQtq98m1avlfHehaaU7wNG/b/TBPu49bpLQp1w/isngEdotYLb 0WRh6uasqj06NIwuba8TVtbx2QXK0f2vICC/RCu8Rfvojc3S/IkB7ObF72AkStcV92G/R1rJkBm2 O5PBsvN38yfl00/AD7Irmos9TVWN5qQsBrchQNIRIFpWcLnFrsZhHBkpPW7PDNWo0Y8B0LLwtLZD F0LOzeaHz5u28tjCFs36IUARWaZXYdwdqDArLNvx4xSly3M7Q5Yk40l9pOr0dcHI1X46Es+Evlxw gO942LAC/OA+chcg7rXEOZid5SZq7rhIpWMMGdP5M5+ngaokOzsNINdTeZ6hgsydj9x+YCo9z47w Pv1NwNaKJGvXzO5+XbnkGMivWmMSK8qlQCTsF5pIv+/0KS2YiwBcnTwXRMC99KaHEXWzWOhFm4X5 aunJJmMbfHFPAEeiuXn2JZi2+z0jYCKjSoyaWCS9TnzyiWJSj43komTXObo2a2O1R8IaL90DyWgo KMGOQ/pBVFyJf/QnTuQ0qUUn4x6/VY5eMTN3cwOc3dE8tD50avx/xOHUCR4HNe8Tb9acqlZf04lw 0ny8SjKxkpCisOUJQFWuH21vA+4TsZtpoibMl4OZZCpTgii/AJWM5MQ57ZIFKClxVudJOt/vXEKt zIfwlZWpKqSDm88yQZtuXHO0CKoW8N0hZaZKT5qqi+CdJ3OO6sbuAoek7ID66Th1/Cv5vw2OxdDJ n99SzsRMMv4fmm6ZDPIIi4vi4QhM6JgW2NYpLrzdbzHehkrWwr7Q+0A7JycYtfSx1FqVyguz3eCl NHKNWQVaxwrrEWpnEVH5+py0M5mlAK3rIOTGBOwijOtXlchcRe9S4Ld2FyAgHcz63rkfb/YeNEYW 1E98KuKCn0R4jXQFmeHDpIlgigXkKkFb3++meAN/ESUejDJnHbEHvLvotxmTULrKkv8kWGWhOasT 5C5/eH1c96wEJC+UdEWAjwH8DqZo+lENYgrhSd19MUIaF5IriQKRJaxRNSng50TolZXilZijikWu G9jaU/j3imeju6qaxwFHPFMIs9U5jybSyHn9q/MFCRw3vscr6Pqj0ZB6UBT0ETNcl9yWkzfDl+N1 8g3xbINggwug0qqDR95WwrcTdNDuOCyReitILh5eLhqDl6FmGBtZPLrOQKI4w833y41ML5mbS7X9 7V8eIdKjcSS30ZHmkFpEH1bQJTckpsFRJF+Iq10YfBt3rZ4bOKcTyDKpVlqNJwXdQRvdU+wk1PLr QiQ+BlPD2IBlR+mnQEje54rN+qwtz3UIMd/yTMVHHrTzWYTTVjb/rZahJEiBDAGv9RqM036/gBGy +tkfZlMi6UkPvK12NokRHDgunJmbMqLu6XstcddWXApnTRUeoP8bkPESE/09FOKxMmkE3i0t1ino q7n7D1d02SSfQPL3zEOp7p5XklC+cBSFdeCY8MIStg3PzcPznusmDWdHStQhVCF2GmqhM7+h/Sic ze6F6YIpswhZ2q6Gf9LTQlFsn12Fgz3yM9a/DpQ60pnBXY0xYLZQ2OB13upxwp4JEbmXs7z0NF3F pYbu3Qo4zHD7ehquFYJZQ1g7hJ+giYa7mJLlDAtWuAs4Ra2Ax8tfRxg2r2/Yqmf9f/oQ0w1BYBpF RrKRVXFZjF963oLAtKaEiQ7z2l/A+H+OeP/k2SP6gIPvc9/ECEGlqxJ/ppigxJ94rkX+xAhpujuY m5nrjHMQcu+1dkBo4rjxIUR6MgRUc28bwF+429HAz8NpI3znxasJXKhhJwNWC1sXz+fscEh+F3Eq QPFBMRZu03Tat7e/nVCAJvLHs2FAoZT2BuiFByLfXuUkfwvpyMUzBUQHK1F9xP5G0LZz+37jZABv KYNVzIdnX7RobNkpmEEinoQcckbDHcHsDZ9sraCPZH0d8fzwUvnrTPsmPNHNh+QBO4LoHXFlmbnB w34lmY4T5ITGEUmg78Nxyfr+e+MziA4R2yX0q+sb2or2pYPM9f6FT2aSem3n3CED/CZKpS6c+WtV JiECZyXct/4YUxrOWnJWPTLXQb9+E3XcAA30e9hvT3VhXwiftL+UH3Xfjv/5r+KCppmodHCZDMPO 6iwTQWQpLbATlfwgauv2277LKmkYhMUSapqeZK10eG+d7aJPYt7l9FuW2gmnfi2vx/j6M7Fxr+9D sH9FCvvEZcyzu+MnNdTB6JgCv/Iwlw76FjQQbUv7VZt0pK0M5oLr4h8SsQOXscx00rbwPXphLNxT tl6guzGlckiybezxymvGOoyh1wb9WLpTNdl0s5rZcIDoR3fNgF1WGrR8J9zAs7f0HSBkUyt/Q8nP HBq4zI2IMKHdY5ssUUaFY6mM1uJUpQ5J3jRmlZgSa0kj2XUvkQtsVDQNjpuZbM0MhuTxklVbTmvV OQ0aE2dd8dz5ozys+MRyHEY2dQDbXw3VHcAhCghyg4WJzZkrwiIyFkBt/NmI02piakunupSz+KcC FotDNxmPjszBplhnYyBnMsO+ncUBXW/nGOlyswhpSH5dFZyBywfjdXpH93xrQZqm5/9YHanKDrOU muOoGEQOalPZDBfmkshSHGfZnjdHK5eGb+3ZqdPhDyWyrLibuRR3E6d2SOJKKMv4d6z0MqEv8hsQ MKbo/HvuFDjtid8QxunS0oQNDXpEozCm0/0ZF7agcjuokeU+N6t8pVUpCqTaLiIO6Vsxfcyae2UV qSKzrGNbEtQ6LK22KbYZor9teIiApDHdZgcJOqWme09RD5Tjb75uSxrd3ajXMeH0v5D1Gt17ZhRr L+IjLNsy7aHBrzYZhtANs5YNFi6mRW+VczqzmHDRX3W9If9e3ECa/GjZU5g5zo9CLpsCEvwdaHx1 DoLE5oD0wv9lw/LUiFM3MxuGzBeCSGfHPtNjB8cwZwscyPxWKslh91G4WSFd1PhKQclQcCVrzbNN ppOj5eztsOq6DHfWqnrB2YiClmdtxil8AeMOgl3Yq4hEXX10q9KA6o1A6ri3lVXMnOhMG49pbHAL jS8MuEOp8lRiQUqWb2aHWjQmpyuoRJfrX0PDT99pFzmDKs2Mk7IwyWzoLBphvUFZuXTBjHCmKCBW kRLdYRNaUIWog3ks2tc7tfJmhuW3FnEtLzh43VK809AT6H3a7Np1ikjsL7aoOU14EZzcOTwPa+6t m1le7bDH+f0T0BBMkIPznvLjLaYEr1ItxI33WTC3aOKRT7HZW6m0URWXfdkDf2Jb9i9PMgETZgB9 CmKwYynSPx6zTdd72dE9USkSh8WcBPBhtmPxxah722AxI0sX3C8vEd0smH2zh174Qrgzx2UWFlGo CEYwpMv3go632dtWApHh/CoPmdSZzCKnN3sbaBg24vTVukiQO851hubBizmshiBVD49SPHzfAJTl 6YhrcJv3NoRymZR+nlmhI6YsBoOBRLZ7dtOUs/i08vHDSm/WJ2LI+Qof1NiKxh5LFp7hDPhQ5Rtr plhzC4TzNYsTi+YFFLCCiFGsJmS46WvljDtEkWl8L5q/euO40NBAAQSfDuOk6WtCw1hmXF+TxnN2 u7NPKHblj7PwUQZHjokxookXdNOa0tilqxONjK5ZbCy2yMOtL50yGoWp8rhq4Hy3dt1lEFUV0TIg clDjcxllkhZMZPhhts3GHODxOiNW8gBcTPdZxPddTd3eRRr13J5kuAEwvevIBFKCN3YOFwQOlmNq aWgtGo3mA38PEBeyab45urJQazBIepmY1GlD7Um1ZIKDvz2fXFDEagXtMyItfPYZxwcXIk3UwUvz oXM0Fs5URBc4jFz/AoMRtMg7YjognUkSpCN23ZRgS3xqWAZOBoeAKnbW4WqJEdGdrfTfFBSLHM2x CiC8QqxXs5mQzp4ZVyvf2Jk1mAdNVwzQnP8T249fH73Fy0hFwGq2YWh0c4jsOqhEiA7osga2nGK7 QDDDDwL92bWITZeALBm6IDI0TrrFrZ5ZbOQP3ILwXsupG4PFyhrrOm3Q2YgHpAwPOj1vauYHmpno QjhLiuhIcwD4+X4yktwgK1xgkWo+hN7pn+3wHL1JQqA6amba+20TUFMlCFCAi2FYF/34gclU+ijk UsKFU10TPfSn1Gqq2B6VeU13RrdjJXBPKKU6zIqCHnaky8/yyvf7YbQKXbTCJQSHMbH/FVavtprp PWJlxFUi6bZ2kTQj9M8DGkcLkC/5vWUxe46CqZHuXydfbJDW7m5lkLqO8H9fOqLt74JkFPip3jQ/ pFJNuPK0DtztH9ziJojg1LGiF5H4MbD7Ep9maykcwoqcJEdT5J22so1zPl8FiX9YBc7LNW6xEZL5 uq9lpXK8IR7ONQK0o1LErakrcPVO1Mr8wBj4FsEAjc/Vpc1LogXbOXHHi4mOb6iOjs72rgvPEscF xlHHUYoV9ESyc4drBG6r9meLxwFzz+Ef1PNtGqZ0HAFEQHrVk+dHpG9g7VrpN23PX8Y448daNzZe 7rpXjZMHMu9s/PEmM3kTk6J/GkIX+LFLCpFSflU3cAVg0StPvlUtNbg2/H5VwaosIJFLgrcO+bvQ jdMUz2Y54EI2Ww+KNTuPonU/ODH4liX2wTfuqXSFU31ftyLUCQELjWHzVg2tN8ZaI+y0zWT933dw d4almlc6k/SmWosAjoy1X99wisIlzzuCx8wEuYvJTJzBWdSu2x3eEt6HJGeVhlfGzIMCkj8MmgpM ITigpNP74slJrBC48Iq4IMyP1jIjXRpf0kUGoVd4JwwTIeRBq2jGF45qIZ8Lp9bciwLJHSbqKyUV DC/oNynOre/iIObkdANK5UhJ380OB7JCNFDa5xGasdLbvuxn/mPYd3Dd/BFNdH3mMJTD19wfbc+p 9TXxKBLkBrTOT7XGnwcsxdAzb5sMVmQki/slsgpQHAocS5sLhHoJVHdw3+fPKBFb1R0CPvHgqn+C mOnxQzWlyKyMU16gFoUWbFg4+ZHy5LRCI7VxiIbU5xV223TBLtE0Zok2ypbCQfADclWDQWyciHyF kHCR+cV/RnnBYivxHPtM93UgQholsSlNGoGmI88sGM6dWTo0fT+3dldLHrGOnLtG1x8VPTPj4dPq fZh3GyMmAZU+BOO/q/kieVTe3homgiNW4qh4yZLDLa3dnJt7sdPI9wsJcjLXRaS1lupVWo9JGTSO FEBvdSxPA0suEfbDvoG8GVyr8EREEqnHthVh7laS3XLmsJcsLDBMU+W5Jjn80MYoUH8aYnLxXOcX GtadY9fTQckz8382k9tW6Apybf7JRi7bU8Miu9Mx41v6Xu3fLh42x84Q17PEBuPupGtxEMDTyB0A /Ebr1EcIcjFD1XwdMY2IsYxrDRgKg1VmRIdbWQcmx9pVRx25mD+Z3THmCSTI0c7kJ62l9AySBpqy o9cKovlHE4SnGlAj4GkGgIPsOFt642FUBlmAb0bMZNOTqNp2c5D10X8qPkh+0aJZS6pwrji0CEEX MfO31aEv2hNjuM1AUlvqeYlgO47YrV/y14nLJhPeS060zO8rUPHJQ1VkGKTu8V+ubp2UcWfThm1B ZyIM9axTZej5hIp9zWspG8EGWKCwit+lq2vK6AWt6tv153xSQFyb8So5OOGyYvqC8Dj+xUVm40pG IrNt8QvH1CMdw6rtpKwAbpz2DWV/QO8pfWwQUHDQnNtPWp0sHW9R0yJNWEY0U/JR9Rt3rQAJQPa/ AILT0/OR2tY1FpHgzRKPwoiMxPL7GANNb7OFJh8JXme/QoP4LTV7Rw8vdOkxAkkZzw5h1ScMNILB l8z+lnkZluwLlgG8p0KYRzL8uPkJ5xk1djrqnshlQSvHonktevGdeREaO9jECLtFsMrSQxox2Glc zxnBvljw6npBsDSmEOOV7kx98R4pzZEWCD58u+lRKPssiqYY0MEl1mgcumuN7y7JjnohGiIMF3AX /uqpPC+oNRPfF6htk/h2Adlo0BAiFUC7OtH1Z7Sy5o1mEAhZc5HqBo0AYG/ROW9P+wtnf7+mfQl9 x94yEnX+VsL8c4FX0bXHNKXNQ4fKYYJShk4yOVuQXcQnA8II4m+Vg91qT8p60VhfRuA9R42X1soG Uj03gcZHZsmkVn0VyMiZAlxJ+GMGP7cW7Hiq8ua81mXRSfkdTUYhBBCHbnRjvy7gEPhzBA3txb/Y QP4fgzRxDWKG3WacCKVCr5Q0+j7X7e/etqkTiVgn/EZdMveKKd2mG0G/4gnGWtm7+339zzH+V2fa ue21sDbQN+0V2inlK9L/n1RmKdeiWAQqoc91q0AeWbcckW8t8IKzYSHwWb1AfiGFoPpwPP3JAWJv 7Lf3gGU8H3rECq6GJAbXldlHjZz5+7+Er6eegIkLsr6Akd0QgK418O7CUbEUOSzB69wGPmITllCr 07/kjUA1+MPEN3oiPizEFfAi06x6idVZdEdVdyVzyDxegq1ZAV6ECz/6WPoWk+CTr+PgUN+2EuYL Zs+CuEq3BfEFHQg5d3m+mGXvp+M07mW4NxjItkFtEiVwy4U7GxwE8gS6OXEVEHDFan4lQG0n4Zqp zZFXQj5lSWOGw37XbGKNBnzmPheaBRCWH5vhAJtvqF7WpH6a3STkzaXhmSje5lD0hyW750/ly7yy E0SuVAYx3nJaR175PNRQrQ/RRthyKhfv4iRz2Xpzs2UuR+SFUCrD9cTh+F5Bq4EVUNFpWK6I+mQT IAIpbox2BURsWlZPYmrRdttUycpT+Hw8nzdpaJIl67/KoqXh5DQin2theeU8E58yks09qVBwTAye BdJJgm0F2t87UJBvFiSafG97KGAU/b5Co6zbpqWI+fhB8rLL68H2QiP3NcWsgbzwbc0hOqWKBNoQ dkfocC9CpXlN0qgV4x7/SJqcIELz0fgBZ5b/bvcF9Fl4mwuEJsSW4X3LfxK0tJ6w+6AjbHiBzmT2 u89Hx04ne4/yOinkVHBlA8mBQPM7jiHcxBArtFdvJ5WKumaxi5CGox0oabvvkHKN2n1ppzzB0SNr yjMLCiQl1HENDc4G24Wv/y9ikk84gc49+w25gSKPMELqhqaHRU2Fgy/bG0fRI8gpWbKJuciZ+axX 0VBQuVvOIFClSbQ5PLiLvSC68MFk+Zw06I7SIdZ1oFg+wzTQCshrXVW+9oQaU7D6IipJDtsKAc6D vgNJkbKjmFXiLbrUvRgzb1g1nFGiWvkw4A3ErvL+u/OdWu5yT8bUfJnvPCMVzeDXnRVnOhfiiK1f zp6l2c+czZba8/jobbvR9WS/qLTIxSFxiR44tszrHCZOGVJT69mYsipYw5mfNfbuZXHB61hcZG6I oKnsd0CIk51UIBFOumFxUgowpyEug35QnfFU79sIRAEQYvW0fj8ijwDrs8eNe9JoEQAIYbpitsfQ 4y/X2Lst6rFbfViEX3wDd9avSdPKt2mfG33CEoh6nkP0U3Gq7kzr5kcGemn0NXmPr6HipDqrbMiQ vsZNKHiBSmfDldZx5Yy0048j9Klvze/UjmzNV/NF8lFo/0pQv4YfSOPj7TvXS0YS8uBz7qdzNM4F K4GPfdNIBFKTEu/y+XLL+RiB3PtrknKkRfmwrsQaSU+UBewtiMWZd3TEPpqgqXepQn+UVASQ4QK3 vCHQG796euxDwASYL4DWzPZ+mJU36iNCwlJEBkUXi/T4/Fqiw32gT49FB5cKUukCqnmDlPoUd64N be7P+NgcZq/rC2ZI1HFmhMRP25s9bMj2OeiOPeUCUxl5N8LMm9ZnMachxOHURUXtQ9VC129RIfNE 6IFqm3RjV+35lhfKUdQWUgl8vVtpSjWW8UDXnpmFkj7qk/hSReY4Da6ClpggDMDUnAb3AJeJ/KpE 0VPiu5U7q0+8Cngv1JCLIi53Jip2VBuyWRrsw/a8hsDrV531oAOXkAApQAkV8aGD58lvk5AUZPoL nADR4QBl2qlaNnYW1X5vEuuO1NiEGAjKcb7uSxanI2PI6PQzbcMNwgHj1fL5O3abs+P5pAbiHZQo LPAX6fOIIelVm/YpwQmxQOQZXZFxsy4Pb7e3SlHKFWSgKdtKDpSTYodDGYz4rAnxtG49to4kRbBV QyIKhmXEOB2MMl4M8VcBgzFhvADgedn1azHmsLgI0NHCI3g9IUsgbxZyrqM0YdUz34ymqvznmyXG 3v7pteUMyI/kAt6CdPRROlh8pTmjnFIxJVmGkJ/2RfTFUGILjKsy23tN9FakSAdkFGCv+t4GEcY0 qbiv0HPMdJQLNYxOrXCR4RWEYX6T8GQkNL6SZH9WS8du6F5D6WyP6ndFp3FaR3DniULvAxY2G2gM dCG08JQK5GPQjMDEPjgoozr0FUVafMib280MqARAyn+Z1vLu1KYR4SU+8LVJ/feeHmjtlnz1obC1 Db+ZTsiJaa2TgyG2gRiq4a3XGItSqiQx8ckxERqyelBbS8W+r2UxgsQaQWpANe69L1vTm/dU4lNW 8uuSbyqFmtHjvKBTXhcYHyiL6xRoOgSINtvUCQjOYjQMnAFFS63cMJszNo4iCN0swBxT+bLUWc54 o+bcF4eII8azucruH/A44ZjFqxZ43XlM6vLM2vWOnY77J9uldJc+xvlxFm7eAND789xPPReU7M7K lXvgw2jQ+1FxCsRMWQ2nGelHEemH5xs4X7qMyiiHbgqP2LbsQp0q1ah+hQyp2eVGME916EOaay8z kRAhF6MrVJIdUxKe4ihgd1UYWoTPDeFV7dSGmz/jXqi4rVVFKZIxUDYWfaQnLcFmJaMesata7HpB 25abguLrmFAL5JzeTes1FeSafld4Af80EtzwNdhU5l+1QXtqPmqt56rJj1wlj6BJZ/nUZfHqR76p Oo9A0lIK7IHyhGhM9fj9ZFhcogHR0shmJuwuyEIkWcHQdktMI08By0V6li2Xq6fhWJy17Y+2reV9 4daO0kjjNjoXaQuUSwXdjy1tCET8djBdSe+Ixi41bYqoGZ26s2KJCOyh256ov21MHk/YGF8Lwbop oDoAzUEaN9R10evrKa+nXzpt3TcxcyEi2VreJC5YQeXFcu8t6MpjemoeEmynS3T6MjhL1zBA0Hui JREVEKQTWODOf+eKOqATnhcfhJ8lSllywF9CvOp+1u2HxUBKKhWL1W53nRxeC+H12LLL8cAur+T/ oCe6QTq5/gm7PQusCjSVBN+T5ZCt4kH2sMdOxSiUnXnTJabQWI0rX5saASKy35h/rxhfb0QH/fFz vWF7bVelVs0QBbL/clZ+xBN6BLVMTeQ77TZ+B9d9jdpUhNsJN/GtYp0gIsqOwqX3YuQ44F7ruuDQ 500cO0KtbRpH8L6eKKA3tACmRxqEe//VRKPkOx8htafKnO70FS0eyr6wuChQNSwSz6BUN70BIRq/ HsFuefE9L2rR6Tyi4CkU6rpnkF6N1UVKQSwTVGDQyi4vC+b6Dxu9/zrISxGVDU1gOkY/44gv2FY6 fD834vCDLOoF8RjmqowsoQgQ6KEnEyxvZfdgvDoFmoUxumssDwU2pt1t4zQkpcpfhbGiu+0V3i9L /1V8B/3cE+nQJqNPbu6YW7qOPcvqP1k2YNC+Aso60BHzO1RmG6JuuiUp6kVxP4EUpY4iJS0L1XMu Ee6IksNyHV0NchnY+CyOXMRziYLcUNoTECb9C/S7LY25X0Lo+Qtu8Eh5q3pQa0aZGA17zm/TXOKI kAKlY68Q2tUxxFAOPtjFpoTpFhua2VUQXW605eIIEDN7jM2Ao+9H7fsM4ZyqAJTYxBsevXpMDgeL SLjdfdtZ9eEEiWE/2ruzK+b5QPelz9ONr6A7XZzsAjGnpeROf1QMNoZejsw+2zF2CnmahlisXgCH vwSiTByYz/e/NWwa/YtZYMM8y9VrTX4WvNQXs89cxZjzy0i7CtW2fgHplNjm1bphKpLfr5iWe7WN rF6R8TvbVGT3LRXs0PkFV45sD+sAMxxbSIf9SrRAKJbKfVcwRXhhgzn14SPpVAwMr04lcigNXzH0 //u1QNW66I9tS8CneN656z3WnH5KAIoVAVBydBzURdnJFcy1nW1C7AIZ05Ik9g0IerfR6WJkmHq7 2LDUGHil9BaGUsLEwPnRIMPIrUZ4LDHFdFzaqEFk2WULPRLLm6OoGslz4wMXg1yc/MS4aHbctsJg m0VbKeY50TK5lTqoKAAHfc3NKhwyEpR8FbeEFGXAMBTUJukg/8KFKzAQHJZRR2qFndaHwYlEa45p 8SWL5x01FgP4/LWwhgIkxauCwchpfspYt59lCkzx1Ar86WwevwAaFPI9NIEjCIXitMelX3T+syYa OrUHbVQ1swTWrfiaX6/bEA3ly6RMl+isYSFqsEycwOWJjdpLzyvcqRLsiJBMNi0UTZcC+J/7/Xu6 UnxC0GCMlnuMjoWDhmKkhu3xhDMct6huikZIXpQqUohaS5cBqgPk7Nz3LyvjxxSTn5sCHboW4WAK wvusl2KjbO2tJDeXCr8SNnHPqvfV8dmaY0zYXPg3iCUAFNGPjtsSUnF8bqftaXq8ze7De9Yw5HIb 356GcNxWF4krQeu4GQt8icFKchqj4E100QUml4uDpurR/7EKt1Y3Jmgg4+DZs+8PFZCuj+UfRXpX VJBe+mHHVmVKQb2SHRq/60sGlPYCJRHfkpDXEzp1i1hDMasz6ViJWoRNU7rbHEot9CyP8/f2FOkY I2V1ZuPfidAOT8S9B1RtxwauyR/WnoX/TDJnhmIhk/ujvh4Hst2cvTEWrEYM2ah5UObNi7yySB39 Y0cVe/dwfB1JAQe0CSsdZxzvjF5SU5DNj3MV3d08d64sARqoIxeQy1jhs354P+yjw+DDvM9Jrfr5 LZGv+Qh3qPLf3zwABYYLtktiOipkWxiOzGtox9ZMRd53ovXtvO3HrRd81BQVuvhj5nn3zoNqjfbU YWoAMWAyhD6+3tligpdn9lirMdlvJNfwutqh9zqJre37yKRJ1N8+qT4MVsUFFWUB3pZAiaQ1TWn5 0G7cfLTnTKgJhS0089+R+K9GTJbbWSxyBoLw9Q6Os2l3kjjuH26cDFC3YCRtU+Sf/2LFWDpp5xps JFNr5Ft+MYBRFVnvTR3JIRaKwkAtzLp/V9cnk7lfqfCucNlfj8YUq5x8YCcVyANvWGJTO9DWWEY4 ythIXA0u+jt0FC/8DtWbFBKQXJ3BEoZHOrIeXHZ5ppapSrTyweerNoHj3ZGJRs1VDhGDrQXv/g7/ QVBFb4s7I6vG3MG30Fn3SoUy7kgBRd+5nbwxT1/SmBEuxcDQFMfZyrMahdXCLQw6sH21ZZKTwjho QwhZIr7jS7IlXIggb0pQgRpUd74SlocKtmxqW6bMvgF5VXtA7Lt9aJVHCb5nQwcavymqkBptvDzv 2k0vxkAN8qyEbM7AWXXv8XUUraFrxOLNClm5eLoCihlUBCepnpCURAfFSGEpMbT5cAOa6CYfgEkS Pr4K/fk02vBOvPuy3WHihzcnHEstQhcy1kK4/vKqyt3utDvgCV9GOpOoDfpv898jrPpKHZxyp9tK 1DhY34CK34KQCFpSfGE/6NIi8U1ChtDoqJRMdnK22WZeXHRXkUHDHpqPRugOwpA8er621MG333Bi +KFmNbHT7qAHlS+FKkNwVSZi+lhRG0Y57jkcPsAFzvl+OhH4jXMM/9JWkqAazUC7Pe/6v6WFZtUS IXxgsDXq0K49XAT4NEJZy2wON89yvOBVmC2xlsr6NmIwY4sTSZfclkMElAYwWPxRwP3kscTAyVaw WYJaaiih+kUa9bSHBHdC+018aaQPvuu92VyFpL59BTWeQpbUCdtsPOhpTpRWHbVCFbQzd1P9dhcl kxA7yrwZXwd6vXYFsqyKlk4/3YUlgRztrJcs/A6uDnrmR8Ojirafh3oDC2t9b+NHjyRKEYOteNQt Fj3V/mIb1vuGYsEy63Dm3EhUEJprNzB6OSOuhY+7cA7IVv+kAS7KY2R4XvWYpondJCJcCxKb+NA6 PElA0ZXn/kp7p7vXPCumxGuFu0yPPWGa2h79wbV9Ih3fTsRGr2gt+91pHXi4aqkITpeEjCDXPlOz xvhOVDV8eHsxas1IMnMkVby6l2TSHfl5Dya8ZebZ6G3NUUkssJSz/pX3wfklLTrNdljbqu8dBu3q NUTkZ0y74higOOdrcP3xOBvXFvzqSyZJ1mRoJWPsOXpUiuSA+ixbil0AGapX3y1fo4WSnGRQKn7H ILEFn5RXIDeWAN2/BHjbN3sOM0WBWSMAWITGGdHxhxV1GO61WWt3ziEUvp4Xks0V4bwMuauViMe0 lbU++nX/msvzt/l4mMcFDPsU9QxqQV3KodXHLTFSQEf1IILiFuzxTElC77NB48HFq9YDTJYlDLD4 VLYUePZSVP+8A39cKX3HlCb2VCt0voa6cSlsZlFd9o8JGImyZHUe6OzfgPZkIRiEnJSjNJ+W/atW iP/62iiVqQymPVhDJyTaxw6g4hf1Nfx3/ttlqAjochgYVXF+63VUoE0N8yfD8In6cE7TUaowz1GN mcH4HSUckLUxMoGRaL6BsYNn2ixObl/OidE+nDlMuYVojzAxvdNHCUAfnwqn1b55YCOcAeqrZA3o K+hnNWwnrrfolRI6h0isqnDXVO/41FCCKvRhP9Vk8zKg2Zv3YTEHhGrwVrsDM5e2w717L+y3Ce+N JUZuS1vw+KEC24keP017FMChznt1UA7twl5u3M4hXcxGI+WpXaY6JCzlHb7BzK/LDVjqnK3zHBKB 8Zh59SvLA1NK67xCmJEigQJPSiTtYoW/DEC7dhq/bLGMNa/LcLu1xVXU3MSZRyzcUEChRaNbPAAD 2/c4qOgt71/Hvdu8tn5JwFXA0Uc1NqWTgbVgSRUI8hXSYSJXSTx0fP30T7D1eITeUcWiOulSn4U8 BJJREDBmX182J5aPDoQtUYTtbrJXlUsGzwL/qvicKX+5+lvQdzAmIPIxWX0dcFVv/U2UVfDvaImH TybevSqrrEZGEgcmWVMtltcy1HbvUH7LCwje6UOkPcJSu6uH6r7XnzcWKqpfTPHb5YaGM6umB/Zn hCdu6mcS3Vxs7WB479e063xL/+yJ3UnUVMbodE3X7WyFvjmlmdOlxEoapDu+lmBYWyQc8wPevJLO 8joG/k34nd/gKPzQb9YR+A+M6GcnPHw3mSGwHfQQZXU9lk9D9ppFuu/yyr4Ue5sruRx0qaCwWw7j kD3jiNC4LvK9bq5QqRjj9vRKpJ1vlTwBeurzBO7awqEpySTIq/BDZWrAKYlsASbb2oOrYFDK0SG2 pR8N35mXtVsCHr+B3Uqwx/tFG5gOzorXRdqLKMumrmDDbd0YZK7e7jm2Bpiha/TiR6eJGcY5Pwj0 i+M3v7tjKkvoRTK5efgNESytbOqDVgAguciCoOw9T8Z8tS6amcVZPnHFke9XvWMDroF7zIax1bhd SqEByxYAaJEOogoNtb96zeTRjZGdvggNpUD2q+hsDmObB5fKb8gF7QRgw0x93n5AcuDmlWCJOgAP T7VWxgM5knAHm2EAbiHHLFyyd6iKkKN5PgqvlwvWGy3mn0wOnSQgYgAg4AStPZUwxMVDglWXWRGw bsYBHpQ16NTiPRhAJEjLrhVox4LJOxIp81nJ6AufOCYvw6Wl1oFhzB820258JC1BxjTr6Up8RCTw wkkMTRJWSP0MzQj1JmkE1hi9icgtKNONILIHURZ9t2wU8nDhY2gkBDlkTIvhx0Gi389DNC2V30ft kv/hf5/NI9FFZqNNgH0lkav3L9BkpukoQQJCSCKPhoLoUg7FdDMsl6LxQ88kcjMufsPeidYg1KSa vQRPWBQuhtc0LpQzXbgHEOb3/djefzjQqGITrwopWPm71CR9EdaOs0IObv3NgICSwf2ZaPdh1b+w 7CJUxCel4V7XiW7oyHqIItRKeOVKfx4Wvp6I4daPNM6eZqrssCu8dXLG+qbGTTkHBAHC8VFV8vP+ xYHVqktiF2ckhVQfGpUp49R6r7gKc6sCeLzf5Jjbf44ZzTW/Kb6wotBhQENcndqcBygpJurAFwXG iu3xzY86zhghUpOHY5L9aZ81YDGa+FzEQaUk6gwDHheEfcQgPUtmw2pqrHZXMrr97ZjDGSXnc3XQ wAMd/RBE83GLGBpSKlmdRghoqpIUF81BojcrDEsOjnj+3hQaRC6E1xfe+J1vzJ/z9OyQURqGDDp+ h0/8bR4aBd4WmaI6wBxWe4zizNuOMlWevy9MDNYSexnSAxnHhXOw/Ygfm2gcA7G7e2/7EJc2T9Wk Ijsr/kyU1FacAdo9p8kbAgnEV4GdRbL0bo6rWUXAFpNOLOaPHyX6ojKoDVMqc02/kpn0rbEdIW9w K143C1alFAEeEcfLus5PpGsY1JB7EMcVFRRcukTR+JJ3GC5j8MBV8pGrKMHwZPknvGxEeUy3XrBd WPV3utSilS3W+fs8Bj3a+CF/o889m26VFJ3mdGcMZQVoQw61yCzA5iOrgLpvk4AZvxO3chIpq5zQ i+HF2Z7Gub1ode8ZkSsqPDFKYM2AK01gRAUbNOJ0/Vh62CItEk1ost7bNDD8giBZTL70wDmHOFuU jYeZ4TycOpUekVAwqE/VTxl4bBkP4svzKwTbTHmaPrzhSUC13/NWj8DFQg/3m/A/2VSXV+mGIlzi 2xQiEsXX0WAjL/C0+uJjxF5CrzBQ8tJ8zaPYWnqiz29BfxBG3QylhZJuP7qwO4v4/mO2WGFfjUjD s+oXJVcv/gnHPRW9d3K4Da3bNstN+gO2lftjTgZJelJ2hAgVpn3H3i6dgB5L+IrOAyfetTLDNqke ukq02mlHac3inMbH6QnFbO402hq1TQZMr+Jtt0F6Z6RJWX0nQ9K55Ic7j70gisWBC4/Mwm8uV6T6 TLoeuADMz+ybO+IPElPuGI/AkjdXutdZaQELHfmjry3P2JGo8JJypwoJEJjFNZ3Z2ejl6aZkyoz8 XrHQH7dPBuOvbEc4Y2TYEagb7a9ItnQwI7W7LgWRieXmLCeygJWQqGkeN0C4aUa5A1Vz5pQS+2DO BTb95q5woX0Ha2is27wHEkTaLlrTPOUoVzcwVoTW+EjOdm+EagfuUuV47T4kiOJzCrR3dkm+9+Lw OxsU/OU6FWgZEqmp7cqJ85KWFLEZNsSjWeV/9KBrdmNeFL0yC9VfAbTiUroVzEFacjHJ+LFN7uoC VV0lJYbYPK/5DH/UOB+IYPLp0aNW1OHhMo+4IimT0/w+gv79Xtdq4GAmgXDU/rf/uYdsXZui5bKj fvIy4Dp4OHkuTYoSzzGRSxPRNrFKQhpeYs2eml815/g0p5pFAdaEy/TBcYHyHyuSV3dWkuQ3uvZ7 jmfBUPX2sRaCrJQfzK9VewI19S8qXp+gLHbimYD1uYDoeD7xQ0DvbZAgPXa4FmB2G7hMc6+EBzGD k5+pNr5o1A4jXYfhUQ44Chp/9qYTj5v6Xr01JWy9bIC1v+nEGZKSutz0+hyA92q+4o+qUvKxwcBp a5ruRcQDzRFihi7zK8qIujTfAJxmiK0mIkuI+pnrwMBATezP9vjSogoAx9/WYu2fmAzlMbya1mcS Na/H2ECKLWLL+zVT8IIpzNKvGJAItLO1yOr4yf2VkK0WvWBGErbo8/NIKIAEmt5HBEJ54fyAuQu7 35hDYDXUJrXcwKI4e8Vq/u7vvr0XwX0e5wEj42xQiAihvntE34B0cpl2sm1vhhgEkBWS3f+sAoZF YGa71aW3PBJEZDo35AwNuJkZsioWVVx3Re556iLy5LdojeRU1hKf4AgB1/2Op/Vh8aUZxPxo6TQM 77EYxOElcbIm9K+V7ghdL9imoOIwUCkdkr0GwAXBaqaez/lOoyai68hG5oeIRqFMY7xYWdfyFUAK 3KbAgJEOfJfzfCg7OmT9r1/jZWe9/BJSDISqb7ktYMD34LNkxdzxjUF8wvHvvxF/Jgl0emCj4luK E68pncKRGWMZvfzRRGkxyQ7TcVndqdhfWmXxUFdADO559arIpRGOsrH4/0k2I95H2JzbifQ0wfvi GF7dDOlZ2kNuK4p/Jx6s48prLNs/q9lnbmJeL27cy1B0zs+8NcGP/PdXs7LfhNjsudioMtrJ/FcN VZlYFZQ0ToakbsoLb5XWdlwZk3/9Y6vOe0ouwEz9HuKaKZBxDOZLU8KOMWivE0fxXY4/reMeLRfQ jfeG/Nh0x2HBmK8LObMvBgAjR0cSSV0biYOfNR3uaMPtQ4BNsT5fh2txI17fkcDxNL7fhXxiroBl ARlCeAtaa29y3+sAAoNTcaIR1qIFLGZBpznNI1frD4dTjoPDeEnBFE6vviE+LnOO4szVHGG42AeS n6b/hh1huyssNwTJs9WVq7ZQBWrml4P5D0yjw1tHNPtpS/dqUgEXQ78Jjuxo9s4vLuWyHCMtg3cF qAJLVl5wpna0k2nbwk7DuxOhhWzqKRF28l2b7ZmrbI7NUUTQez5lAwRgb453581l3JJvkQO/+W3I sg87wFyx/eBJY2V/d5f5DNMlWz+BhQ4mpsEIxu1JNFRsnPamD0gF9EPab4e8B2i/YGUiELcnr/4S E+Nyz7vWSbUdgeJCTTmn995pox77s3/K/OADiWw4ON1FQGJUzRwyenz2dQiphZQA9o4bMXPKR/Kz SqDWJovIz0Hc1gT8mBX2zU+KJ2BWC+4bePrQ/X5U5FwhbCRlGD3FpMrWfd9u4UZs5wfjFBQTE9XU QOzUbaKRbJ9BOmdgnD7aQJ2IB+P2VqxG4I6qkisPFWm2RViCwbD64xDP3xWHg+l8quI+GHL7mfOv KoMnPeCE4fizyi/WFN5yQ2n6D0EEsG6vodclUMhNgTBIyeJAPSsofZZzG7py3anbPnSQH/1MuvxX oN/Tps/obTYHBkdLjlCv0p1HU2m2Yj0Y2XX0PXlBAePi7z6ElW/p2A3Vw6dVH9q59IOZXosOWYEJ fpwVrxql1CNNi1UHY556ZU2tvNO1JeztBWB+RM5z92y/m8DV5EoXqP5ic5ENEp1OpQKgQ/wA781R ZG00yBh5K9DIJMZgGrQ8ihlO0CFRMLE1KNCkrHDpB92b1Actl/ofO3Q3Xu1ie8RdWAXl2CSudr52 +thGNIwIAanL4CbmrccDfRJV0rW9QscZZ8W6C2B5xX5dARC8HvHK7JXX5FCPOqYoayOauDTz04re mc3dIGnrMsow0o7a3raZqVMJHJmC77VeuyUZ3ex2K6SyZN5Jd0lvLyCFQ4kJUI2JfaLVH2g/OiKj 2MZcevqWL3fH0q4nIzc5Ohz8P6WMRmhAowM7N2LvvUjRADeyZr5iVMMJyMQTfY/n914cnZxUfYUf zzRou+pvXl4wEUKT4d1bQAyObNhcJwJS6YRloJ6MpPJQdEirKTkqOIRPD1XJhIlRGLn1iNHfEujA wQUQzRO/2VCZAjj89lR8o6sXgYaF7NWs3iLqE3Iah+h0Q1cfSNL8oaax0BJbj5AfagQgFPoZQ8Ar QSwG+BeqHjcpFLT38M1P2SEIXg6tJ18+ZF6AsaD63AdxnTCSAYTqCWEZv5XqHDBxoWP9H944e+D6 oe1s86zIF8YDXsRZ2vtCGIh/aLLT0ybp2Atc/dI6puxylk0T85j1bbnpc2NRzV3zBvmMIe+G13wr 9OaAvg5WvSQNMP3xDkGd2UHvs5PMMHDSzVoEwbee/vXagMhfMBIYTmCVp2GCWtRSScBf2/relUO7 jhCT2yzIoY7ornSrM8NWCSNjcHCSqj4AMFkVrL/MyDGFOI5SOybmlv2h/JHMVOs7lEo1wnLgtjDw eplZPhk9FGGHXeXSgKiVrAXuHxYF8TfJ5dfY2vNN5ABK4eU44tVVTOOZsTGfAtJIMzv6wy8voyRT rOu24xWF/Z1mMGFHoCt4XFu2t46TgypErJSOTRdtMRPuolWzoAx4m81df9zfBjp2ezMBQQ4D0iMf +nAFscHL2mjMoZ9TVs9pFbk7390ZyiRuI3mP27Y1spvasNjJb1xKVUdCnTQj7kZKzwaUApPgqWdd TumYse8SCfCdLgfZwUhKe0z8/9ZHdZDcuLRwVHvoP/Kcb/AdczISmRsLqDAVsxhUOhUD8TdJ83Hc 113cbgnMS7JgZx/LBd5y5MDXi7vcui7o1qAPbZ1ZAgIwRpsY/owsjMZvSoOO72wMXPaRk3pyK3Pp b8W3NmkU+AgpZ77LJkU/DOlZmhA5clF0cu1PrEKnvQEfEz3pkTYY92BrP1RDF+gdLFBbyBDfjhM7 JK7iDbBdtNNpfZb+XcO9cbuDJgF9zNOdLzreatufEbtS9MZA0BLb3iV/vgGycLxfPtqMQ9eAsK2k 399rKzwua5nAsnL/xKYWqhXEFgbeM2A5xcsgbKUo6yv3OmQHYgZ6H8uoX8lMwQL07d/ggGWJciEu /5fmmd0b1JQ8NSLfXlurQHx7A7v7dg/p1cWoSVTMTXScEaDGgpYCFsY5RZl/Qp6N475PeWQwYXfF kQQehgpvGo9ANd0LPEzQVfoIqShVKbrBu5poX2DNbuoO/38QLYA0w0onrtTeFsg9fl7RVtbjfYH7 73HLjgbcTq+u7ZY4qEQ9MX4lyCPIKuuSaLn/v7qHHBDajp2+BDUbkCYmMW/iWCC9Hbtbu4Z0FUmt /2UWsvufc/DOmn+mMa+QTPGz2yks+Lz6nRntpLSGTBBbbh6lkTEwvVvtr98PwG2KTaRyvq8AArUr lsGjfLjTbLTaOKJLTzFu/9cKllOzaslWBb19iMNAdpjG37qkY8ZEilvMo6b5tgudZETzSmn/8KZi mzREyxeq5u/yIaoJjj3UwS3bVKXLTnyXUO+N3Lv98rIn+QYn9bcKuVA0zfWPKzP5tqNQBZQqLipY b9TSxrnQa6Wb+RUqtjmIsucGqnM4Azt9cYihgmMtdHZdsIJDWidLseT16xOINXj6oP3oO3NGDfHc XxKjzFNx194wwoA+siXnuEButC4s3ip8e/1D/htZjujGkdWL3gSDKHK+uM/7n/k713Y/hiurS+CB Njdu6snkGE7RxLYHfGgCxIsKkzzyGRYSJ2mKUb3fqjef7sIchC8xVA5kJHdUb6q4b9pdSbFOFLZk dJXPUPquG0VlHEjOSKjdg0m8pB+tGHwRrZ1TGZ7I9N6qKp0FFetNQqKyYF4pvWJ530N980zVoPOm d4NfOQ9Df6LPtaJHale2VKI3O+BtM4+WDntQaWHDIE+PLTKXUbYxKOrZAH2eiMbyJtgFeQLzVqiR a18iwv2vaP4YUNDwjE71HvtQEe6Dua2Loc9XUqlT3PEX35xHwGq6mRrgjycsEN2EjWUQG5IRZouT UsuITP5VkJnA3/za3+ga27Nrl2LoWL3ejvL4At4+TUiEzKcRE7rWdoJIBiPlb4RHVKp3st8vob64 wLCOym5yjbmngXvq84QFmnQqj1SvuanupAlGgUyyJbF3LQOOP2BAz0Q+gu1uHKE/4S16bm6zJ3qY b6pKhpn29Dj8u3WIehgkc4oU8o3cDC4WXHrfOkzrKmH6B3W4HBrfkSgwk8NpAZ5Ofa7GAvfy73os aVj3l+ons/U6cFx2TOr62t3s0kFpRln9sfpZwUvkYGVSM+U4LTLKG/WijnVqT1f0IIFv6V9uloCe /MrkWLO/CtE91XxcskWx7vyeSGa/2J+exXaxA+Ih0u2me6DWWWOFV83GSo77e+pzL7nNhbKyQS45 0EnF5cVS+lkx1Z4wCrw4Sbx2hBNeAqzKA1ticOSCov2LX4JhzvkX2nDAbCVNf+TH/pz4d62xJQs5 PBIYqSXl4L6qTY+RqppXHvcNyP5LNeFdxlLEj+tk+W2YjLBT5dFLpPMEEjHvzid67rCPJW3Mo+XS EqfXGINm4tVxYGhHz5qDCMZ3fxkxN0KLJet2PnDpfWUrAibmVLrzLE2S3WuNlMxmPOsfiSEgB9JS e310FExwDEU3UMqUUvXFbbWpyuPnH+foMv0PC9a2EgqM661WqUShh4MDfrBCW8hOYd8w3WTAy3+z FXhp7nf2NA2dbavafHleEHCtwZ4/ua3uYiF9k8O6191xpqtOWHxAA1foWO81Ipi/y2aeEG1/fOvs WqOLuBWIYBdiyjqElmYtqzgwb3Z8q6S6IHHlP9NnexQ9/VKog0asIXdIOq0aeN4MW5EIyU245SXZ SmaCDXoOCErwD7B3UDp1G0kG4fb6ZHIm5XXulv3UJvtkoqqsA6qqAUC6PkvTEuXD44dwOD3aB3mC kWcrJ9sPwUFiEWWBC8fBY5lCWhluEh0UaSpozmniFQeyPEAcNot2ZfxcAGTHH4QRWPccdfbo0U9N SmQhIC9im02ElX1IRk67qaJx/ykvdr0kM7O7Tel1IWHj4QrYHAyOAMlnGRdTlBI3Fdt+6XzD81ab TCApF4DA2O1Y/MUdi8DSs+4+0mFNNvifGtJt3AYoWgzcullPGpcZiLzxCZt7wmiJbCfVFZLihwfo 9rs/bmOraF1Xv79DpO02zvGeh6+ttLlyxSm7iISe8Fc0mFH8htPiG1JcGkZGSzxKFoKPEmdqoBJL 7EP0x+pFoFQk4j30aWNSMoGK7fbHwwnmWr8ITJHE05uSrwYEj/nfQy4V2INPGabTFYyk2XYPPy0v nq0RQPSVtOxqBXvdHwmYeDbd7GWChV/+E5g+H5QcaNmghfoCoiySqg6jTKVGmv95wQGtaRKT4sHq CLCowzF7vnnMSdg3KJZowVn9s9Z9IYQ2ZhgHrQyASyTisk85VUXmM08nXfRYuBo3rSxBJNcdKA7T z3JV+bNuWE1GBJ9S9StythLusvZxUesvFLmCu7uXQLbJKELWI8TIoVVnSLD5hiPnPvFKhfKvIOrt kkBWi4SZJCv69VhYNUu/5BrA/af80l6H9zP6jDqwelwZmlIrYXR6+vCK1t2MX6W3eohMnPI2sJAu iMrBiAu6ULbVF+DPQvda+1bTObtV/Jqfd4+Yc+SQAGT8UBmZ93bBouU3+QQIgyideGatT3DNyP0u Dzc7jubhipgJU4/7GWgeTMVbGx9Xic7yYEDSHf0QtQZ6uf0u81vCfG2KMq2KLRQA32+T2y7tA1zG ggWxXNbXrFVP3oG8MkMHmfsMWbejCVXdvJrKHg0Cyin1UzUvYtTkAOzqpd3mWNFHYTiaPQNq1KTI iB48LFahzKqIAN2l1YcSGAktyaElHULNcty23leiHrgJ00ZZ11AasS0A0C6DAEREtGRc55WM39TX hXKTAIJWOuLC+DPrJSOgfsb0IuN2hq1zf86SvEslhbJ8ePs0xXA4eiKKjcLUmye6lhrImveOJ5Oc z7/ep//SbhJrS6cujAMd7ULneYV6/fs+LV+L1Sq9d9UFEE1qo4CDiqj5ODXb9B+OM/wDbh/QrJyD 9IHkX+UIxQwV+QrcKj+/heuHnZG8nEGsA4jZsAKKJ2lrr7YOfit8yAGm7x7By4/b4yJH+XAlKURV tnpTVpklqjNV05JX5t7ng2IkgLNVBH6Wzaz88h51fLV5kPEcJc12f6dnjI37EjfmonSrrKCBGsO2 4uzyty+KhlMmnnr7FB8GrFvU1+882EunBWdhfnKPdu2Cgej0SlYCXAyJjiLzCci5sIBVCEwKPYKb vmTo1vls8/HT/zoexozrduQCqQBc/GM7LkyllQI8BGyI111+26cuFp7wciBSPmQoZ0HZCJ4R8nyQ jrH5tdcOETVj2p0xvRpiKxqiX9qRgEXBCebUGvqesHSwgJuhMvx/6/F3LXMCVBTWKk1cpeyiEr7k 4O35Q/+XaLu5oVb/hQtUiBl2sYM5S3WCiLVg6CKC/8k0/dxkJY4efENpOFiD7sCvXRdtL+p10+vK HxLKz2QwhJb6OHbYmpRSFrUmtXqZu5zp/zOfn5w5lJIC0mttNrFcHnP799ywoK19NkcAE/HIMdUs ndGuQdOJxZmCM2WLxVzvFg7aT4+CV8fxBfpIEb0rLKZNGZonaMN4SgMlW51e46CxM+ae2qkRU9Kw Tu2oi+ZQD6r5R8d6gDaD3UtWQUB1GSP/pA+T68/JKd1+i3b9bxrhvP4klP9fLnyYuS1Dp0KXWydA a6sJ/cQejuc8LHmyxGriVJ+rYXdc/J0MvZ0WFw3ktIqBoQ0qEvjiWYdpx5ptJLC/zXArhh6jOO0D Jc8//9rQNC57EseouJh5vx+CNUNN2ePctBit6+1boBcNLPnWpOqfjh5ZzwRlE88QFB0ncMOlCsC8 TeUS/oz1KRN2ZATKmqiDSLqJ/0eUgeyGtOR4lSx8AsiJ4bZtZUm3slKeFm+kcYss0XkzE6DcSYoG efuy/YKkLjts2mvEBDa1JPLTdwi5R/GVOd62FaO5XHPS4XWSjSJ8MT1aVNNGNr4p/ZhFetkDYuWd S7NXXxdZxvL7oyFB6TcO+57M8b3TGakdpPrFAANZiJPGaRNp4nOPD40h/vef5PNlIjmxFCk9Cv4P MbrsacYGsYU4R/fzMF6yuzqlxyzy/1GIbzS0qhCBO+yYQU4V/fMlPe2k8NMXTrf/YNuXMytdtZfX Ppsu+ub/n0wY2m00aMnvgc/hCgtPXAiQGDFEkVr9yemJqkY6ijgk3ycnwf2pIsnBwQV9M0mq0Jd9 10a3i304BZCcI7x9sXuTa1le14GN5qnYrBhm0q/y30S8WrxT04DY44HDPHsUVM3VOtYzJqp0FB3q Uj5ybKgsAlIZmrUXlybhqIp3XW0sCnClEo/RO6N9cgyLtIVZAvIzapv+VKJUyokC4kvERyQwSHMN BQszRKHtPUUke4vMMN168XfUgv+MsBTdi2nJxYnDRFF7AO2lQXVy29lpW7mbi9SgBMNr2UE/b1uC ztBx+YaHbLtFAs3Dz922q0JyBxWsRfoyDywso+mUm4FqFm52n9C0wyp6iDGm1Gyh8lCz5xb6NtB8 bbOEgu3Jm0603m6t5XvIJzXomF7RKnpDtrigzwCotyBPetVldz9x+GxfgpavO26li+5KHFCmInkT 8JPMHLPkDQLxeaRQqcbh1eBBP7WYGSvRtOPYQ7Gpz+Bem2p3G+7lSp/1U8cZgqBG3w398ZSzFUJe 6vH/lhavkJ4dtZRWB8EQSeG7qxdLpBZrwM6N+e+eZEE6zVb8wdCVU5C4+U/uAeakPxfp1pAzQ1Hn AKAPVF9KOnOMg4qLNgaY+uLS8spm7dPEHYQHuKn4IveSaM3E3xJM7xgaw5KxVozcEmSYQizg/qf4 YDhIVsdXwJxKMSz9jIt+aOTT80TSuTr7b6jbSfEf6Wwmoh5COccGzhGciBkRsxpOyTT2D00p2YHg Op62XfZ6VD3ULSebundxXGaoz/SHmwtiyD14qZtEZT3hqUcmLS1nFBKZLC/DXgcLEoiIPEl0wJ/y iE3eQyUQHXu3nrUWurzhzxl/8cIOFr1NMWCfOyoqfsqr9bqD+dctdy3E/vNcOknaktuF0FGs4HWH X0KfW2k7gN3XTNiCIxtnSpsVTBqcopW7/HDSSvIreUtKOyfh+o4pixFTzZkRxYOlmFqjJ2Ojnjxs 7n1ZDf+Y5tiUzzvNzX6sYcI7pTT5HMZS4mGG7oLHmkXTMXfhFyhViKFLzurKvwQF8Lb/GX4Ysesi ztOOTEBVq9WITL/9JcxQEg8I0yKAlYpgyVArOiytGj42c/TGfk+/f7tMK30VqKLhLPp/pQitqV+F 47h6guNGkQhBLhscJDR8v0BdOu+x6KTVTkTXuFwMdq7ZucZXJsROOiGlTwSaf1U3g5BqHztrP0vH yMgCqa7BOWGkzaQSWuPodoXjNk8AjqLHvPUxbin0WjKw5WKAZLbV/5f73ujV8PKcQDR0TIf2lyRm bwPGwIQXxGJpuvqHRH6xiBCfBPpeapLAWwU2kudxaAvluYaSWIJWOmBvv7XTlfJvQLeWc5+/xyuh Z3wfTnQ6NR70KHhmwZQT3DvJzewReI6bc393CEKhGblqUOfNSv2hsINbzrZtM9OeE/ptYmOPGYrI zpEhs8CcDoA/4VAq9WNa6iO5lDMETuuMFHn5W0Jpz3irX5cnO1sZRLebji/z+o4eU6gxDMAnPG6U YToB4cseDGxRY2qamRgMxIo2L03f/Akd2l4r7IUxet0l7UWWWfteu0ZfGfSsG/eSB1AP/9qhwcgK Yj2XE/Eh4HpqwUZ8ZPEzXCdCelpPcmKaDq7EKlBJUi+NohWx3yDbNULDY5mGnXvOGKtUTi6zw50Z lh/zVOXu2PXr7zsk1njN88zJBjar+VVAkHjyapiViRU/KSQKn3WoEj4h+t7gc9uPNFbEp4XueWB7 2QzYhDOkOJyIiRRRMngbXid63MW09m9NWaX8z/AyR3mLQm0c6ekl5n/PCR3ggyXwWVz5jt49bo2a jM+mh2vuHLi5/RsGXLM7/4pyYwnhdiRWQ0Os5CaIM68jcVr6Zv19BTd3+FrhaujgGM6xS6dSS8Qx Kt0Ypi5hXWseaz0nSPu8mDwrJy4gRPbjkhxSQBnvuCIVQ29hkRw3Vx5x1zuMBj4PhQMpInmaIFbg e6bEfHErqYAShliu89pG9KHikFpVKbzRYM7ZPRySP21LoNrkM//kPpmZw9irZlS2heB6QZjY+z8G 4OMkyHxrUHXzK3LJHf3DiPnDO+UGQ9OICONIK/mzV2PS427tHYUcBPQpj1KhJ/tkyQjyVA1aSpxn BhLbIQlH7qezuYlL3so0pmbtahncY2zrxs87sOpGW9TGLq6II4/dPvfMoNdlOlYYeLokalPbE0Tn 48tIXX98CsViNjLWjPU7ux6mkQ3+tvKdU3AIZnrKIzqs/UA365sxOIqe5vFWpgBMuWtgLrLmHuuz NgivKuIf+fss2nz+M5ld5Z3zpTAySzP8bGt4f/PX6QuUK4CtP55o8vBMhguvqbPTLEKT7Qb6fZ8h ZUIIqmAhFhGZ9n/Hdp8dW+Z1JKnc5pFzHOlUu7yTcp6uJk9+cYWzMy+vweQAfO4brcJqkU+phi3A /p8EgtkvpZFUS8vRSci+K5XhLwCXMXNXp7IYr1HxMWUV8v9X9NYUJGqCmxGMkIxUoUvMZbOILBXg BnDhJb6t89ROH6oFgR0M1p9p5AOe8I4/4MUBPPoG8cAUqIIfgCFLqMIp9sPkomZbACQNoVKGrZOj 4yDDEiBeXNo9mgHQQTipxxkfuTwfvgLJoflJNRA6OdyPVRGeiH5YIVtQB/DUOzBXE/xcwG0rkKwe iFd7secyetUGmFLhd4XQ7v3Pgu7JfoRmDxmMHoWJwEX6eeSx2TuWQ1Wi2HlqhSXUAsZ4761hYWgi BusDZr3XkTY/9TYp96k/mI+yye1mcmacaYYXJ6hDNpTYqW1LoHZuAsu9wpKKZSqrYuqWD4csV5ke lUxWn+7QMG5ZcK8dRWi9heDS71Et5/MAZmZJxwS5ZnenOWSy0OeE065KO8JnRAYfd/3KKYg/Gbbl 27Gp2RLVenm+p3o0k75NFTBSuhpnOhR24RTzBix/ohckjE3TQ2viaeTAOjzr6CGJox2kJIwW/mUy JioLEc4eqWZtgm5yYxYrmIJVDvPjAkAzRjzkgAGUQtzfCgFSr9HHGTMGXQ/an+R8DtXiYfz+8tyh gex/MGb9du234+APYm7QsasI4C3DHyK3ybKq0Ogrh1HrLjxJ9sTGhL0YwHQvA9/2zeiVAYg4d22G 9Hw75r5us8/TX+YlMK2ZEFDgL8p7JDMhFROwHSVSravyS1m1vzggtFFurDonUQmpzfue8MvEmW5A 7CWh+qhxemssLKE2+KyTnZzUp4D9RnYd2hrcwXAxRlDXueLzfFbvUeyIGYuo7yZo+boteW9jGBKw 0WHzpWpVidVt28WxQUL3XJ5ZBjDPt12AtO6N+3u0sKu67ZGdBTZWawl4zAhKWDJ+WVMM4UD6y0WG DJbyGPs1dPNPwjX4aTISNaFrraGkARgL79LVA5ZMCD3eYvfungrmrbS0iuhUYppgf/u+FSGJWQeQ nOwa6NM5nldO/kDtp3pNGcNcSvDNmKmV6YS8FYnTNSgQOUFIw6S4RzLvzOsfO/lzMZjuxdqa4VPI lMJg2cEfkx25KXp3H+DU5Y9wxCAy+y4CWGYC5BA5ByAHpK3qp6Ctit2KzbyUV0NauxBm0Q573/bO 1ECghchoUlTRIaq6DQZaF1oRYt/gMCYFjTy2RXysk/cl4Rb2RvlxtwQmiQ0xR5IrIqh+OIzhOxtW 3mrxTPKtJey3j5iFpTEyb8rmx7SeGTZaNEMnqXGJqm1A6F+5HlHZI82g16Z/iyJH+n+RuGnY1oaf X/fxDgYuxn7By6aF6cUwZGiG77uI7oADQ2944Qt7NDZfz/fYsJvbWwaSuv/01j7t4EBWGIrX/aol KHUGOrgrh8KobZlXCpNRobmsvDgK6KJV91NQN6BcsY3bHzrpA4on/zpxgXh7cHWgv56Rpg2QAva2 NXME2aCVq3SyCzKVyNu8JgQUTpSIHwiZTYj3n3XQSSR/w0w6eIon+bbcsyX1KGBEPJyeQ3rhWuZs GAnb54AwJuBgT/N7+QKgjLchPpWEMVUUE/+e4biQf9BHHJHcWu+sW7Cprm2OR3NazK1eBh6lJeI8 uQAaOzABHnI+l2is+PPvdP0NWQvweSs3W/KXG5QAwKDDB0kAe7DT6xzNMdAkOmtP+P7uWWDVzv+D dca38ezJWXyh91pNsU48SE/Gzt7w36zvB3oINA6IbUUX19JDjMNyA2aAtwVysDlvlGimfu5bhBjz MOPh2n7ASgBbC4RRx5OglhFRmtzCzSjdn5u3qUI6mtGTVTNOmK4fW/XPxtPHDg0txnb9Pjt9YSQ4 2cXqdNhQPx+b6efk2gDQLK7++yyczu+yG74XeFWN2+1WamNwIBWjlxTsNiGQWwKOzFR3U4CZxf9E KILpGq3qLsgGX6696ZTXZhIoLBBcKNpzFPW3XlQWSjWRLeiof/EctEarEzE05zSi2G1eIf/obWr/ VhXzVjG9Ov8Bhzpz1hhCy75qYcUS4xi9HiM9J4wm2/xXGck/FztH+faTczYOab9PQBWJOVshgUEa TvHMEKeH2iLXoWskXCAvMkBu0OziAYEF2VgRas7mI4gMTKhvybIFe+/pQaIl6f3NqPobR43QspTN n49CnUrv+X7iBBIvuaXBUZESMQ470S7nNmbg7LOGElRqmx+EbajmFMoPSm/HF2vyIeQEkooEVbFu BrNvQGI9yYyP7nIbK631mSkOAMR42033nsMzQhQFp8Fv01P0RRc6hiAaD076wtxo2Gb49L9CRG3Z Si+ebOeEy8l7NIuYcdxBytrEczNRh2XotEPYtDPN+W5D7mJ90NoM2tuTwFpVnmntTjRg6V1HqX4i aaZdROuZsvFpLmgrSBKBzpz+mVCzx2KNvTNaSemH5sNfO5zZmXZUtUA+xRf71eRCEN8IYKZHbbk7 rvO5Vj/3xH5wkRQ4E+JUZ/c0aEf5Op6qj5QPXxdR53UnaEKUxdZn6tKuR1/VsYAyOga3xxgb9uzx L4mtfOJOKaUXFEWKOP57SRG4PsiRXnsp/1oCBqz2FfZj9K7HhKqVYeqB4BC4H7B3fUJgoirFc8Mo hXZ/52daYLYa4j1UfyQfHkfqHNkp+ZSy5goC6rT+XlcD2twvRKBz1EA+GOFXzxrCrQZ/5UFsj3OX VBBY6PRuI8HOy6l/eSiF78ybcnDcUF1NcTOVax9jgr/JPe25U5BoQbMu2LZt27Zt2zZ227Zt27Zt 27tt292zz3/PxD0xM+/zcr8VuTIrV2pVvlRFYirPdd4J60yIloZSPBd4zbZbQwDjuYPxInqUvSy0 6/2Q8z5R5YpaSOYH/orrCfLTuwRAZIWbqXwufvqKmLMJcchSv0IrsSnw6+Pzo9Jm74AXVgf+lstg tJIxpwjR3NEySQeMa7/l4HsIgKFfaoj3hadeh8e1xLvzEjh5MoMbRephwB+M3di5RomSPRH7xdv7 3dmI4ckJBK5pjI55crCUH0Ki1mtWPA7lLj9brFXvV9U+d6IUN+pYhY7GjJsJ08TSC9ko56pkD6NF MJXza8db+B3rNcmDc7O82IaemgxdT1suUMzss9s1E+GyvM4shnSox8MetWptzP3aByihE71Ekqza y2AdCGRBKZYbSHORvQ/R8TSyEjWj722K9z7rUcoxiNSk+VeXtwdL8qH68D2sNrr5r1s/ED/ArQUA wUDHmHPYaCa0knIs+15M/ji2hH1OgxNq5YHkjNYGBnULLisxMEpfIzdZh6SqfE0/vRlluDkggmrz OC8wLvUifQ9K5PZ/sQrFODLd4dTcJY2N/8ZKVVLyiSynwpx4Yw1qS5Kg3nlThrlBF6xyTs+oaepP V1OAVwHl4HiOt1uqNGZ/VVApIQog32+lC37U4K8hBW8uu0l36zq48hq+5NAC5j6KhkE7TzrynH7e NJeuIARd14UJ2dwqvs0x5vPllqDHGN8faXg35VVcQj+ZV8Mv+NpF47WsQpK21a5hOjKro9fqNnwm jreqy7n9WrjP9mnyBKZ6Oa1oZiKLaS4gyGDDyOZ8j2+4xastQeIgwEac8nJ3V1TGeVZc/oGAEmw5 wf78hPJSXrtf/0s0mMgU5y/Y7Lt2VXebsMbPyXBC2aM9uicue51lsHnjM+iRsms/wpFC+0q3cgIb sq+OSsFsg6e+touB2cwWxAQYYMzVc3FcpcSE+xtn1HS107LILd4yJV/JTr+aHfAQa9hSIpKp1p2m CTqNC+pb8IYQMIFG9V1Do21HsksYScS734Keaqga+AT+yIj3dwwm/YPjiHuXeAMzFNWzujJylrDQ BwTLDhXzwM1DXf0mvvAQ1y0g/nAeVW9FcuvLhhCCXg4MAUAURH0Imracg8MP2jAZocDJaShSn6gC S9okXU95ngjpS1xdRT9WPfA4QsvLtU8bOemBnYlBkWZUN3uH63YIz/f+vcNdW5mesaamcnmCdOIA 582gnDNLuch6e28SPeCo8O2LCkWPajL8gpvYl7bbX1MU4XeyfVyNtUX0MHIZnxSbgyhw5gZHW0kZ EVyMBiGEqiJgyuLEF95oyh4DgWjpENoEbIX62EDFqySEutJXOx4cAAu4pz85RnJIO2tocxAmnCWx pIOTiwECCIz+SOrk+/nLvxALjBQ0arCMcYH/acsLq69N+36A8ArXVMi3ElAvcP+dpszexn89y6nv Yb12NP1iiqLRi0EyyOtunrPbosuYNeCl/49YqAd52CpUb42zxc+GtIqd2mTohm5nAmXJ2UEBDnIY PKcZ7rrdHlz/qo39lb/Nnjg2894pxtmjOiQsdTNrm9++1yn2DkJVbUmuxRSGmBpZnvLRnGSUEZRm 1Jwf91TpE5BNWrwsy6/T6cqHyUBxuVHUU2zm0kEwDteOnj+idUGMUF+SjkFKFjaA/HSrJEvvCrAT z5jsWXd2+CQtlM2j4ehAxQ1ch/9N5F+ocZ9kvcNXvG4SJu7o8UdOIEXOzZRQYaQgBkdV5Iay5/tl h4B9F0M54Dtt9lZIkMrS8uLpBsK6Te8jGGIK2x0+C8UBP3u1r0GJ141d7qp5ayvZige6v68ZospG A4Ca+bqsKcnqIpY+5/VtkjnGHB+22NpjZ3C9LpFunT+Si3H0IabUfmC0x1pVInKeGYw1VEIfRF5N 8go80d3hpz1wfioeIoHT8Nqr9mS5sG9kK7Pd4FfIYE7TvG6GrJDY8sBQ1PWbZeyqdfDBonBrDlFF 5dnvELkkrR8LuvEEd8rCJEtBp5vOmF+u13+3NOZdyf2mOA1LOhi2gjgSubh0PbaRNh2VSluIFiIB 2AOEcx+5gC4U4MNT+pyAHvbbpDOePGT1Ev7kOOW8KG4xOWJRxdE3032ZIRJjV8Ab7cIsfPNBtJzX jCpqQvjmn7hdhd9j9d+7NcVSY54H9e8G9adF0zO5rPvxKCkO7akKShG+VRLbnOtUS2Ex+FX8vT9P VzSxQh3351s7cHL1C91GNbUEpDQUnkii0tQLtfI7qk4Uv93ZdFQk2YXffze+hqpNmsfvDRdtDyBi THxniCPEmvGepC0/L0qqS+W5u89m2AmxpIfWLmY1VfDY2WA2iXXjaS3nzv5+UqxqxYPDFDGrsZf+ wac1USb/BDEdHYsWNiZxs8KagH79a9jd0dzknbP8QZzdILmGs1T+hihKT6V6AzqEQtrj6yaN97Mu afTObPFyd1NmAEWrQKn16L3fHovUUrU/SITZpykUMcWb78yjenEZMFdCXIKeUb6Xum3kprHshqZE /uZFDLAkilfYknZIa2waF67bOYwaY+fCPZcWdFc6Ve8EaqAp+PJViENinZqiUOvULJe1dI/Kxqvd 6TMIStS/xNmlUjnHQgnlU7nYLXJ40cJ/hqlP7/JoneRGVN8HldzeTYOS+LGD/u/IbMJtlJ+YtTxW uUcY7mj2STjjxMT7iJzmarc0ygjVmgDhvJnLvp42ubc02mnPqazH8CpSsYzSVgbjuDwcREIQSpi8 YMntWDTVTu9Ci0uFgSO0b3SMi8hPS1p4JsqDDggEo7L2kmDzFbA4icdtIfEtQA3HXtyb9OxuuFVW YRHQQWoCKQQ7UlYhgGm+1LAXH7Ze5u6bnZ4C766J29OovRoatR9N8wJfQihVbGNDBTb4cysribTK cvU1SNUxnsTY4To8Fz4idEYdzRWz55T6wJuPA11P3tm4K83BoeV3JWX1sEsGGUv29Lgz6zPFr4Cp X9Sg383fY+qfAiIeA6QSLRrzKry1tzTb8R2kgqei1WPU1qgYBPfbql5H+kghdyrKOT0hQAkAqf0C DqnvjLlk02BJ98K6RVMe2WcbWcrvMGjlKu8GmXDPkKvb0XWDRejHjZ+dLW+GHaetgy1m5v5p4vso UQ8UU/PO1yPThCzgrdVJL6ALAO4oG8ie/ny9+OeFGJMKI9Fv2bQBNb94oN2owVuiyRIqvVMdaDDq 5/PbSxNcqioFEdBFaZ3T/20o2UMaAyEPSChYW33K21Im33ZkPnx72APe3UHCAFgyZbmjx55EH4KB XFd7Gj/jYFKiwgbQCsLYQMHhGRUdWYQUZAWii7Wjfxx48DM9ZhhpCYJdPUyV61eMEq0wi9Ty4SdX CyeUGC1JCPm8dzynN9nEuCULbrHKbXfwksZ2NuYH3MpHKpcXWtD8hpf/zzXc2sLQ8bT7tugtJvHo vy0PGrunFXkeKLzMen0vw1/OjlVFO8v5nRwazgTojd0qz66EUa8vMov/QyTJWPcBbG/+R1nh1Slq A++CS+d8KpsCnxoHSdHtrnAIxfjWMtkpfHM2utFzc/0EtJlajJkKF3mSqFCOmXmc7dsa+ALrfqKK PsNIdoZxgBqkC+kXZMzzGd1r7ZZf2XVs5IWyepRC8Ubh1/ArNfBbVNRmycbfz3xBBnXjPHlACNr3 WewcGHmzPpBGvL/pTrCRe3sqW26ZZymAGbDGm6MJXiAH/veKXKxtzO4p4Rkvk/6vXcCXujugXb3B SnnHFXar2PROUrA2MfA2TfQqubUmFFDN0aexQjkjtD7kEV0L7d093AKXR49N+F0HmxSDFuutXA8b FOo6OMu5CBmmxK9gPcGlhJJnSOuofNhZukybMxawwHeto+w5ihU+xh9HYaQiOTMIAiVQjFiP7Kgv vt9u+OVXUKZvrchYhnMjitG59vLYChaFxdkMVLLWBNVIz4RVWq+mvzGz8hdpz6aHhH6Cq7+YgG1j /VZFV8El6ceEdqcQfqGkPtT8pqpaGe6we/jZjBMbZG6srPJxyxlynSnfuWyA6Y6IR8eSC6XnMbYz BtAdEvQfbHIjPWyWWu17jORwcE3toaV3ZetRftbnDK6gWIhxfsgQibzRSKOIeu5JnEyVrsylh6+T SSmDfvuTpk1nTyBtJWQtf7xr0z6aVmFq3p2guQGRj+oIZvP3D+XwM7x8hWtXcDt+5t3d4D/IlInU /PIX31vzg7+wggn2iF0rfRJTaK26Y5VkC2hjx52vawMpRt/LG+uMnejQnOpXEtUYwh/Kr7jONb4h 6bLa8CYuJVFSEx9wInoudb/dSiQbBhBqZmhifibNCXMG4W5nfESdlPUzM+tFyytIffrTZInRhXeT 1awSeFGlUYSZ2Ea5ZfbtirgplePB+/4E2vtDoIO8fZlrVrEw4iJkBplsDh8GGQ1wmM0YFY0aoIh4 qwB2dGgneSLGiYd8peAzdGDdSsE7Me89NKMkNmbHUXINF740nSTSFYvHkt486+BZQ8boI7jD6rk3 b3MY8NhalIz47EKYoKxPiHOqwA3xnR383ltmEU7LkR9J3lzJWpU6DvfW1TSnkB5uLMbepfaBtRs4 ASLVMwHpTYCdSbf9ooSpi0uNcR1cqnI3bwSYDigl9bNVIQ7QJQI54lWtuP/1CuzU7hwIrB0avc+C T6LRfrrCF70CBmNXQqkKPNQIlpTCpTGoGSEoEuWGdmRd/9o5ScYVki/CgtTpK+mYma0kr29LoSZB yFd3/EivpFijz/DarC+R1fD8PF5stVLrmzDCil3VxE7NhoIi3Xx5EkXz1AII2B30tcPACeSubO3f pTI8SjcqMY2n1elHaUfO+6RzNFnQYIDsKsev+ZSK2UPh6Eu0v4wHylhUFmLLkj3zfhlKIxWJcHaI IQy8evaJbDl0ufSUFas9c4iI2aLhUuVTq0HvGrmAEkKRVBIS2lX7+aR4ADMix7JAOZfbKZWD3l+s wBCqAzy0m8H1A+eWzvFOkxBIdcXuHDAzsZ6b9Z+QjHhp8Z3gUimBgaSo4uIpUyLPp+NCif17Gh9I ekdd3O71dqXyEisnUTlJf6o0rBUCTF6z+pLQ9M20pbBgFMBeYCxZT8+I9R7OlNRD3QbYTUFJPO9w bjEqWVtX53VSDqmt+aigFhYPq7KzruuB/xQpZkBGJkYnlPAb7/4pNFy1qcAVxnI2LtofoUP74J5u JNGdc8i27Qc+CdSp1B/JwzwRwx3Ou/QisjC5n2TcNmf5Me67QjMt/5kNarKjsYIj1enKjnknrg+3 Z5LRElctDPpCJuEYJTiJgwg4zjJ+5/swhmEjoy+w/egn/6F9nN5SR46DrjGkZxIV8VuWPhLarOJ8 qeq2GbFqHssYY6qH8mhqx3xWnDtSlj//p1w2IXmAGAqoe+D2/my03Sbg0yIfYRtaf0QZXBNLHGhS mrrtLlOHboEslFMfnDZ08FJHa6dqu+bVAgc2ekkbjJG9hryW393M1q2WPl66W+sQQz9MozPNYzSi LM7zxEBB20Vr1P8NY9dfnpjXHShQpjOCltdj6PbQ1QYjRS4xreT5Q8UZuE3XF8TXvlNYHArT8TMT vZK1iLK2zc18LFkx2wboWaDBIW9YBVAXgwBfzRsYIuIq+ote/6beWIxQaTzyCKILevno3E68ZCl4 HKS5klg1SJTU8QbRRUjCuN8G7d59ycyp0Rtp8uPO17J9MpF7m5KVQ0+icdHvlzLlxtHx0CMyR1hx H4HxZno+PlIux1B5L+hREZGkZkss+LA50rAnBLOd7tlpTe3cDFj6BHGdlRx3a/3ZuHxRcvbi8dd9 mhFnT4p5Maz1e6QmbU0uIJrJ04O+bb2UPE6TQhy535xOuINitP5kB85TRZWM8WdjBDeyCsXFNOCj ZJdXOWpLvFJR26xRcosVvJROyg6zLpZZYuJCjuQ0MPEifX8OaN6uwgQvHt1G+sfMrtw5WniiNGnm c+ff5cGzEAGhWU00/altQ0nmAKy9ocUNKDxjleM894MkwHExWXGBfFU6gIiVE3fiUs1zuegNIYN9 qDBQi3y1SxnfL1tZ/RuSR2XUKdf33LTFRQSDQ9shEhP59ugPAjscLwxoa5nMcJRwAmlZ7vPwOfOh WdxMXlp0Pe7PKCVue7OvLIJ4IcPMsOKjl6rVp8e8DeuaAGYRR7Um2QTBRvrFoTfMQ3Xv0GgCSXTA xhoGZ0BZz/Pr8x8qsT/wA2Q2qA6IC1UV7anPHZ8orxGK7OA8v7qWf1+qmcGYcItLBaOajpBBt5uB bWWMISpbTJqhieiQoqKetbnyDQdRmnAfs+uNR3cJlfyNnimX28Pe3x45p5/RWGCMu8FX8ioZgJWh Y5FETaaam8EamNN/33iBdSVvIxP8qWzcIs4ujx+hf9qTJlyAwqNkOkTbW+JQ9iMrP/pX+OoNfN/S KGaCmSxOXjjHjgo6qSnFeqnHKwWO1fxKTEYzPToQfKJb8+NSapw9KmeeJzfr3FWBz7Oq4vTKseDa FWjSu3jpfqpkjBuo5DobUtwDrG67Hpdqdd5yK/o3q9yCk0gYS5gZUFoEqx75MkqfY7wKKIhpmMez a7dWTMyMZGbEq+9kUp95QdtQ31MTWyO6GR/VM3Vfb9eKVrNjsy8RZ/2uQ7R1M8VuvEVRrD1AL1/e 7MfVvVpxP0BSJRgLlki2zsq0J7AmNiraZxKteRRxRdlxG5CVIkLcQzqiqxAglArLVu4iEfZMw2nn m9y99mCvyaiMW4feXEBRZ3ztlO5V1qtniX2R/YiLbXLAGmVyUBm9E3sIdDQXwoT5o106w7Nfvilo r9FewlG2gF9nDc2HZeQNyt07H9QF8zcgDF+LCvN+X/i1LkEXOLaMUyG77MabzCNfK4RIm7+sURP6 4aNGoLiNtxzM+GXNgjNfrETTKWrSqBiyFmXFEAFG6UlILQ5kPDnruXx0kwEbItHk3IW1tNOStygi UNwyA4ZLXiQLTEVMHyUlWEqLbD77fDzKXknracXSfflPgW35haT8bFZBl+uo/5JjEvaHFL78msqj 4LGZEODiHzjA8uYoOmKfPiTP+uvBkyQbzyma0B2AdnrtZOSSI0L1YMvxryCMyhTLh8pyB5hXcEW8 SvhkVKi20ptGigH4D9GOn/vIXiTn9JsNnoLDcbqUhllGXeE85Py+YrJB7PTGmsMCAxNx5o9OHVUa +UEKiGr4YUcfpoy2hLbWgDAZISLLXlw4MIbXOZg3ikjy1UDyQnX6AtBgt9FBSGA218zKIUenkDAt TX7JMzw0z0Cfm8KRp+Ju4ZOQVPZcJ5M/ZfV+Hl+62lugkMG0hHIaKSVr4uWzQ8Bl+lSK4MBozlFo 2BAoWDpF6ZCdiLKczhaYFkz6NHk1VCk6ZfZXPW1kj3hfVT7r7CSvLPVwXYwoMVJwr/h+XJFRCRoJ li7lpKhiu72QlyLuUJs9NB0tQMCuG9NmqPr0vHnkzt2x12+sZXaFzhfUBlPl8vRq8sOjDR6nGSmr WOTWQzYh0PQn6zgLl+EVOr5wTXr9qatV2J6CywfowH0UGSgHbs/6hks24QDD8/BAP8xGmk/yaFcQ GzMDlKnEIrHRr9FSwgOMrxnRFfQyCqySHDmf5Lczz5yj6Sf8uw2b6PbxxWdDA412TOYxbHNQIutp D+gGdR8z1FzRdHzi6yjDMY2v02lpw1a8n9DGuN3IaZ8TjCAUnJsSX6gJFTVQHcDy0eMhha0Ff3mW C0nJZZDx0FeDuWB2qR9YEONUTMqIL8ukPVkxv6fU/6v5fahQBUzE3N4aUS10MMa0PzCpE6nkNvfk T1h9XQbVdHa4YROG8HAmfeix5RNxzNS0HacOYKhvgg+SZs2wD0bxdF2WG8nWDmJTpNgnE7tcns65 UnD2MVj4oGhfj94A3nirTgS3+GC/d7yCHXMWdsxwKMmdRuZo13N98XLDrhxd4Bz2JxuikGjLuPnF 7wnijlwqrhp53cs/kpFA8LznxFI/4M/zCeilUuedqPOWT7RPs78OTwnyX6feK86x0AoBfyLJ/UGi Wx/Ree7pctDlJgutY7iUyC9T1saIaTEy+CSiu7Gj46EpS8KHHWUKS724m0eWNA705hMkQoP2Iixt EoihnbbW8xRhl4EWjTiIOYJOKKeSsPr3PlJOngLf5HvPaNw8Xy01guK0cYh1O3xwBITo4YyX00nW 3Q8VO3JL1IXvH3NI40ipOR/hIo+7Szh7lEduDIGL/Qfd+sA4hkS7SWTl34N0defGnjCyOPS+U5OP cr27xSY1vfF0JJ/Buu2vzPsQYtQM/YYXL9Spl1nIsIXiXMjCA1xtypijmYmsqfZ2+jjhZs0Y/8mR 1tYKUuMaOWL1rIb7cvJ7r90i6c8F9r526hHaguUXUdpEmsqeJaDPdk6Fc0aWBjphwtZHJKqjM1ff aXfznVVF3Zz0xoeVPiRHsvJhp4QZbwJ4ET4uhlS4H7V60XRloPSnRUVGyn3DYF66X7mJ1SqNeTm8 m6w1GJI4/NvtWjIJ/DUsI2tZFlNq2n0tL4vv62wYVGywgSiJk8VZr44wnARLU8tYhTxpgd2mXrUn 5sZrn1SXsjjmBbzvwyyAeTHjt0u7OHCFmYx+rgWzKczSmSFyCwPrMkHXGvgNShzUl8Ve0f0LGLH5 MfHMS0DvbmoVI9F5ta2sei81PBII5LH6ZG6Vr7ekh+2vJ+w+/S0SQJNwyuXvDVIGWJxA+qtcQYA8 rQn+eXwtOgj+oK32GneRs1yb2IRtn6s337PzZcGWxn5JKNi1UQ4Yu0ScKAGo9gEdeVTcZqTwrVXF PQs+rTbBDN4sJ/aOVTUexO/tz13HbnZSEOv7Xlyh1nE/IZZvCwowhQjrmMYY732gCZAe9IjQF0Uo k9gh3eR41+AjYC1rfKyZcHVtv5mCilQNVBx22LCi15xttk5ZUXaWbZqcB0YsVfxoWCcVoPJL0oAc zf60wcYWdRo63HXpUV1YOVyDsu5JrzKpN5lI0qbj2Xpk1wvxnEfRxP69O/q/M42M90MlK8enSznT 1SK5HCRl4+sgQQmlln+N5fYETzu0+4kKrumzQ6nnJ8CTWWQvGfT69oPGpBQz4LLEs70WyPseM5R/ VKfQhazzVRyFzxmOQHjrOnaETn58O5fJEiL00D1sLPJVOL4Zls/T/t6miKSx5XiIcFEvRHPrQ97k 9VVsMDQ5ljnXxyfPOgLv/sUED1XRLDSLEV6e9G8tZLcBZ5lirqEcBsaQALO03caLJfKoKMJI1OGa z54cuP+aly3eh0DQVESVi0fmQcCjbCUR0A3Y2KXsL9EdqoSHOGdm4rrnLm7b0S/wiksx5E9CJrub OvWz39R34HDP+AUm3IaAnjdb5HP1hoy1xCSEwqpUT9ZyYF52+YMy0LTmeRQZ3lC4bCzFFEOtbH0Q d3AMwuvIOFVe7gVHFjYApFYo2uao2lc3BNAXI/kIVMt5N1q7FWPCyuuiFMQRg5ATFaCsF0nQLph6 89EgqGOjIQVwtqT4+y1y47VMFel0xy1dwPsL90VZdwOMNy1GItKxMercOujrk0bX8RQkDmdlCXuo CrO0TOKYyY/t9+lXy0xMkuD2bNg0IWNwizAHGo9tjMcn1w1Afo9VFqEUh9LNJ35M0o9YvG+/uZgC pqBJSatl20kJkcaujXASicI7uyjoVilXENJpI4cIEC8J2VdkvQdAFpdAj5eYGGLAUwXhlYy04/kD 7uLtbc/5kX3z+PnM69W5TYeDvUT5HmgjV2q/Wiz1vRCix6+kchAkWhpxAjwUjOpUuDI0gUwsfuK/ xiyIsJIej4sVl/qyulRqhiPHd2xP+y2zleWdzon9vkRFdhn7MvzECSaleIwPKVGjDMsYojzo1pNL HGiXnMQQsPbiMRHlTlwZuvrtmGGvfT+47PQIJRl3fMexv5tRMA7TzlsrIsFW02pmSgeeBeN4NOxK CDh0Ox61ZRCYuCo0uMXtg5pR4qu3qO6lre4QoQ78wYt5aaBv3FNNcK9Ocm0CoCcmdja6DyaHpB3a 9Iw+auWVdZUb5+yfePx7sZpUnN3B1wd3Kt5R9K19a8nh/Ismkp7x2JFFn47nmmTmQQp/dg1sXg14 //MRgM+KSy8G2jRLKExsBYVZfTdJJY0rm5M6vDJsUrBCNX5cdLxuIkap0yc5cHjY+ka8lpijGyCX QH2HGr8lcIY73Z+Fb1JtEE/hsR2cko0Gru28iIjwrkhPtaNWca+2aAzRNPRhBZT8OgoyYrvmQ5ZU zFILaugPJaxmV6FKQVJ3ETm2wNF+00LMruOypRly34xZqK6Jxln0p5v8JXldI129TxjPwgr/tQDi WrMRyL/3qxYRMv99aMmsCtsGCC0XozA6nKutUWNTTIFovIEX8VOjAtDTJLtHmAy/ZQDVQAhc3JLI fDPynX9QCJVqF6ywdGaV0TQYmkurRPfNyIUxEbRPeMBSM6owTOgbleuvyd70ssnFkeYgi8S7K4Td 53SPKwlwfFV867XnTYT0O5yKjTf/qoXAOlOs4AN2PO+wiMdd+MI33SGuyPZPrAjVbZms/sA38NF5 7cG52bjvwMalLR61JbM5UORNEPtopQz58z7jfYDaVauCz6fqBY9pISMMqtpCfbEbkbJjr/fOVa2u 8zBoExX1i5yrfCEe8TBeHyMTGKf8DOGBlof38IG0h/MBij9aT3WEGDO6ZCKQ3O2Na04QZx23YhEQ 4KnDTjTLcHr72UynG5U2i4rfB/4b0EQyz9Q6zrCgaOWS/Foday+15Akn99e4rQmoRne9JiEQ1LfS cS24GPlPAadYVEwKg0rj50sqniqH9xrfzm2xHRu2Bc+vUV9xyy2UUU3rBkV5ikoi/svUw+XeeYuV Tc2HWJX240dEktbQNzSuhQZqre3D+IIVlztEUmx5jugPFIjuLQes8dj56w1P1jnW3PYUGGCiZPKY p6xjYTsqdRXLCpdCU3BcqixJP6WOVXwX3X59E4ZPbUXTVSgCWhQBPiVfVRHhkdOpPDwC4imw0yj8 DTblLePo9k39AqFMdM0TnlAB2aE37LW/ARRTlfLnNyecjD/13W4W+wTx+SpxQIbYob+g4uTJ2nc8 VL0JX42gSvxnSqnpqrJthTB63uqSVv63Mylt0QIeiZZfrc/EFYo6ONhyrbM3pZowusHwhOlqhLd3 8faOsqdCaQi7UPnGG0xm7AwAkvzi7ztCgn5wqgfndNQ0CFlLlDJ+7f4debmnAk/dJu8JiCBcPxb4 kiyMCkpOspQ4CmU9p+CoU0tlWRUWEBFCk1eyCMd4XyvEunbTPH+irMH0sDCb0LnJ7AoypCITLFQh EZ4pK/gH9oPB+xkQAADA2b/nH/SoJzScgWYIOhQxAQCiBt6c/slBo8wxIgHm/8vMnwFMTOsS8HwZ UtLv3Pzw32eUiY2Jfm9OggMpXAb9C9t3V46+xZFhrLfxpvdVu+vcj3fOug/Em5lZVabjq2+IRKG7 gGv7oU7ehrVgd3NXn5f3fWwKoSSEDmH8LQqrrZWC6DXyP4BiTjmhjiyTav7ZoPePHYBU1jO2eksD ww56pv1wWlT4WRlQf673+Ygwy8ojRoiDE2I9+y2NQiVQkaDyIri0KbrZDJrX1/LaJEd14p9uDzBL CGmup86IL27BBj54A9xRcOHZYD0DTo4xPz8wI4InJ/o7gxiDiIhIRT0xfPGjgCIB707OIZFmsRAr 7c+mq9oNGNGgmxDBdMCPnLyf1tf++jGaq0DzdnW/kbIxl9EqXEm7hGVHx2SGwc+kGFTFvPqRL6ZW lchKocW5hwg6GJBXWS4s9NuWhGJxr0cVFcN5NFWn58FNiwY+pCM/8/xd/FBiz9KvrBe1i54B63sX NDL23c/+ljIUUUmLJvMB00zZZPLoiPVCDXHKOl+Rz3tP8JPbCFGXkzDnrwqaH1tsqFwqXnzsjFSg AHDCcdaKlwEnC1eBoSEF71bPecZARhA58RueD3IgpqgOSMqq7TAn+dI0tHOcDjf5ijEM6/OY9IaZ HGVMt9aSRWDXXoZHU9tzHiqC2TXvXXhOOY04vl0r4+UugwbiIy7DRVWXtm35lrbcBa9VSeoeqNTj F5aRpx6CKZx0AIQj+gKLLFFml+p/VqKbkp4cjF7TmqCWZeUj4qWTOEXw9ltWYD2NDe4pYoAXkd27 IP1uQ0Z0QwEHZASRGUQrvbm4FoJuxLLSaFf3+PSITHtUWITFvjjPQodNBL+V/p6vIMNKQhk98R8T u+EycdauDlK1c1qLGZpb2xKN4964eeUbJpZJ+ZiFX+ru81LWZiolVORbwF5YnNPGxM9XIEhw8VOd kjAqa0l/yFXiLk0Y04zjbTEHyc4LNww98Ta4isvxXg8YT0eZ5CKEBmMY/raViku0iAvSzoliCbR1 GvCFK3bGdXaMlzMdcko4NcvmkrIZ64GfWqAd/qbiIG6GEVAoX6vECm8PkVPp5WsoRZftbeq6KG2v pCyTV5XosBV3MXubL96kuyZrhaHpIBSih6eNxN4InPsCskbxA41K8hCxoRVWlNoeuUAFeXswmb/z 3rmDAXpX+npOjXvMOnGK6eisBi4qiiROSXtiiUQsPrwW34Tgg8K4Y9psW3ts2KXvttyNp7vTmBu1 qTkVJOoXn9XgXlbhI9/0mJlbV4MDKmoAW7OmGj+cT63kVytv++aMvWSBZGgxB4jItQ3CtYU62Rl0 wtxh/4v1NM5NoFORXrr7ikTUf3zwLCZsUEyEluk40MfJLoNCTBJB0XibAQeH0BD4faLdSkmwDF5p xE9ErQKKBewMCIcOEHDwexZwEpW8Uro2XVO6lC+grKQqoa2k6Wxupmng56uZ05gU3BOaFZ1TGRan D1DzK+EUaeCTFNcVk5mcBq5Yv0Oa1aPbrr4b6BSV6jBR2Mk7nmadGkyPTfJbDpAO19fJXBWrzSZk JEG/coo603lkw50CpNZTsViVn0ySH5+SewragszP9jxnsHbVJM9YQxq3vfpRAr61tmXyHVXy9jXZ s4XDlw5OAnr3IJfBA1DMwud/iv5tQsjwjrrl3IYxgNTPUP3IfkgFRz+M8DJF/+L0/uP5GcyKkbN+ ZMCDxwmCTdR8tGtnGdzYk7R6sXnbYgBDMQORHEEmBiay6nZwFcA6RUTe8YMD/CdfPIKYk9PXfpjH EO50iuTGbeaT0jjrBXleYpstJnyHQHDv9YPmvX96f8MJJHtFZJ/c52GAfy6sAZ2GpDl/Oz9raS4a dU+G03qEkDa26qQgupDOvMs3MaqQj11R680N9PpCdDpZzOSG1PaBOwVfatCOuGk1d98AATSNVhQY e5kYBUa5iAjff9Lr4toeY+Pu+bs0tQKhjIYcOZKIW5IELH64u0lZkvOjmCyesc2ACESR+YPFnsVT 8eWsK+34D8GHKYTC32Xyu+xSh2zrRo+k+awIGSOvljowRz0t4AI4f5h799HHZvk9YPfDuWytc/bM DhnzgSSVMN9uv3QZQQkEtMmSrSUS9Wtp9AyU7YJBhe7AFkxltjQXgpNRuntvFUd7mi5y3XTsArJT qQj/GRQL+dzBinB0fusmhgvP1u6izgFcarVgPz9HHVFZeL+/9I8pzFYpYxpgMHrmBuRFggP4LLqQ bcM4UwK2KlH/+n/fL5ZUD7jxucT0FkJdNUvKgtA5KDqgE+TRExqK0eV5nxg018HAf702aWnUhKvl Kc+ctT1UaXIGWp9b3LEJbq16t6//IimPGAYzi0R7FM27qMSRexqmScSranKwjiC+brNsvHUjoGSI xROBrVDwNyUxTsiaJ908Q8qiR4p0YnxD8uP0V2CX79mA70tIpl0wAALUPY8zwOpXlFgghyUhbMuV VVqoV572F/Ocmq28sAFPv0wXI4T0yruSox/KH9AoEuVGQc7Rl96oV16D6fVclDtYDzukKcfokMUV jreIOUcw/W9g5IyTGb83htCPuWRS8Qr3q6xeUJRABQNq87VQ9SKDq+mR3IO0ApU/A8R8Xl4GQ5j4 361d/IeW3fEtXbH3BFFhHoIpvMWcCXcIUg47MW8ksPc/1QwjQdObR3a8AG7hvw6PcWRwA4YdRgJh vwzprK+yjl8X0MlqM6dcW0RgKyZ1OLwsllmPl9fkHAF+S/yfqgOKgiJew/cPCKwQA7uP7g1Uo0OF tlFEvUZDsyWsdwn1fYe/ZswmVkXZxP6T3CaNXIBuwNEVqy4WiUFZaj1QjTwC3nw6T/tYGQZ1UESG 2Na56WGEmek1ppn0VaQVNLwCd4kE2qfPjqC70/awKCKJrVsthx1n4WIDvnLvnr5Ba+q7eUQdv7Od EuG9RungkdsDX0MxUO/3f17novqoFqfG/XQvmkgjd9LUpnl88qIKzP7G6kDO0rVwPV/B7f50EDST jw6UdAc51NnK8HaE78crv45uC9zyySzxSo8fvYnmY1x1IlAViNvSLwJLc7k1yJ0DdYP73Ky+1wmy duqJRnrHpOzZ/xVG+xwBtSYTht28/7E57DQD/HJIARxmFoGBKPwAEGjg99fEVZmGqvrQ5ak0F4F1 skPFX9L31O+Fd4ik/yTMhKbpxbwunYa5pEXCtzlO0ZYTnVLZ0NfsPA5dzE89LSfhZ2zCMsKH0Fpz EujNvd3z2sBoiPWw3ZeFU65EfyLHXnfIwEPs+Bilzq2oo8V6Fy4Ec8nkriVK+q2Tfdl6nrc1/Top Z1MLahsbciGEcj3dzqhpl9nY+1EBl78EEGgNTgwQe6bc1voOXPZg8tCwbOEL+/T5XpwUEdn8yP5t UDTa0EyWevGm9TS8wLl1WbbAdjhWslIJvm8mOR3Dq5csnUm12W1oMScgWo0sczKBPiz78YZP7hX9 7m++oct6chjNjECsfoZKiBRMxnyyaLwzWLLL2ghtLw5BwKFsusIwJEw9aCFXnBq+tJEMw5uICi0k XRlh0veA6XYFedYtgWXGUhkJwiMi5CbkHSKdaAEA16G1rJSKRumKvyMnqKWpaDImIcI1u4PJuWlR Mr4jvkt4q+8qJZT007cJuCgrXpYad8JdSs3xtA4GEOmM7J1CsJFVhIW+S1RXEvN1EC4jJV8sgbi7 4+NbIlXr0nE9F/09iNra5DcKY0guNTq8p0VHAAHyHUKwlY+T/QF9Ggrt/GrAH55ZDrkIrneJDDeO ScA7jIuFMXWqh6pfgURRYAx8krp+ZdOzj9u/BUEbXohai7lxEseF7f3m722lMNOfxGcbrieBiBKj Zcme80U/y1/OO6AjSjf33vNzFPkR0LpqPqaMl1NERbLHqqRJPmNXQQENbNPfwgmRQl9PGedGSOt6 AV7AVno4hETVN3HQSgtGguqDW+H5CwrYB+cLYrFOYXNMeLmvVPhhr2VEWIA7c1pWp/7MKwjBQlMU D4HAtFCoPLUIir/ksBQ0dctvtOLBlRT3x+hnkM/qxvGX6cFGpPZH1tQ/lgrIT4mJh07DkBXsvLDd IgQ0ITfOuuvzfJ9hqan8fsbri7PTZcLJ4Bau8seh8Of8BTammbX3dSgBkCVv/mIbLtJo2bMRmEyw bn4y6cD1+6qFW/fqrqpZkQv4caDWAVLEmqzvHtEHvTyz+X1kG7bO2zNeFCbQRsB8JCiGypbR1Xcj P7wfy4+tbjF/EvbbVruwCuOPZ2Wo3680OyFRP3fKZz7m2Qn5PZQTHdIHrQDEaxtMXmWuE8WVbtAG 1rb7/Vgu5mudNMg8hxbLGu8cOfzn0neZE+xsAbJHe4XuqpQwClj0v2Ohh/SkQt54zytazsDrd2zL HGOYaN/VcXL5l1b43WO2VJ5noymvXeXFsY6d/9GND5clQ0Z6J8Ez/qfuR2LAeXNC+Qd/Fd1uI28+ RCRCY+oXj1IVZUEV02MxUCgL/Y294+CotMvp5eXVvD+9GWUJNSi8JpKiA+B564ErICbyPS5fRjLh FR314wOrQllShIC/W6LW6XpUnQ60IMhzSVq8y1+1eBKyLxDb3QWLXH3r1DFZGf+cY3xQkkcVLDeq j319sakzuD12Q/xsoUGdZbaZhzgd/axYnUNpUNQP+aKW6+nokHNN14yos6mFIFiOIhu5ueLBYePN ik0u9YIeHiXj9/V7/9Ay3molaEfn3njHtHqQO1lLlg+kppIauJlkaexw7pRjcoYnrrqxW72HGCFN QBk2KN5HonsitXKQQvSeKsrJteFxLGKiQ5GfiN6VEOax4vTsgENqFKWSnFL2rOu2Fjl94XkyX9Ik gXN6xLeWAA1XPme9EC4s4us+vBhGgG2bdJDOyqIvFXW+J62fhzv9Rrrwr7pelUEfFoZ8vbe07wKp e41ogfJ3QLVpx5e7/fDWbKqCNt5u82I0zyDmTozTAFnhXRstcJLIBmJztRVk2DkQATJYjS0+a/c0 cbayUVFcULl7E31xWo7pSsDUN76UumkoXNaPJ7rS+CCLbYvevrn9MqpAFFR2FagDFh2d2T+L3JWz Gch4XQBxtK/qIHELXZSCtXJVPo+6XZDpSfPaAcJefvH0ssR4FlfLd9FLspaDklyY0nxPgLQ7gz7c UA0WykhTdyRdVMZnjdllowJvG0x7ue/8oj/TgVu/svaui2wgzO7vIaawfP2Q0nUv9g40KyXa2oL9 mzcgbyMm7UZHD5DAxmy15Jl94rFzi25H1ATwT6lKa1zsnr6YmFZEI/wJOkxQJXfDE+r+G/T0kCWQ P8UtDTGpLitHuo8GYt4d+1Z770nJ++pdfhxuc8DtzJLmN9IIiGRxAtcAGSYSCujNenad7c3ilYsb BL7Bhg9sHYPG9/nG+6fJuhc0EXFihTt55eZU7rUHPVEP4lM2yraFVgdv0x4hdg7A9LSptwCcULkR yqsZR6JsYAf+vLXYZRJ0lynVhHLfZKMoeYoCTXq+f2LFe5y/TWYiEF3tjdXyFG7JQf1/Ws2K2o2g 70tqDmhwmaDOjtg5MLQrbhtIcIfZ1yqulu0ASXZA+bLUvVpUValSDZsr1VDWWcDVwgmn1Hj2Uiad ED1/egs58F44e2ooHILeFDVSdpAy31SmaQTMq2byBZo25kgl05YM1eZD/dISkT9A0yQodDpk6ysx 39ZJW7DAwrjuGX0o9yzKc4MsPh8tHbv7kO64L3yXlPJbraMMjHLlzrZukq+DONAK+aken8q/O5Yb Mi3xvV05OhQC2yZHUHaKXg7q3LIRvQsqFrmzT18ZzKzudSFEwlBzHweYzD/j91MOaNmTvGmu0wqF /ywxF/UrLWjlOUW8UTJoUVkoR4TjcF7NQG9U9+cfLAbBrPSnjGtu8ewD9fUQHhAKIW5xRhYuJcxy ouEwv8H8gQbGZLpPGrS6TOwcX5denaDabPEJjg40SgQ8HkLzvj88wL3uF5g/MAUSdK5BC1DlpQPQ wIFP8BLbsuORfUSJApCbRgL47aoIL/azpZqT1r2V/oO2byjuHkhJFxSoHDpG9he4F7VecwqRfU7C cS8bsmZdGQc9oGWyafND1bRyETAFNDUT1loqVhJC2/soTo+Q5q9IDIECSFD7+0JasDwPV/EBuGo3 qllWe3pO1GMwYHbx0o5fkog5+1wkp+RK2IVcQAVRntRqdd2Qch5oIPcfyvfGFoiAZUFGxxGEZCJf Up9dTgSt6432s0ZX/PKr36eXOJPX2cLHBipI6SveWjaelRh0SOhVk0iByRzZwVyhBmwFkdQwWhpf 9hxb49/mV78QrGgvUW3Kib+Q3sdKTKCh/Hq9SexF4HpRvGkM+x7aYCwwlXZaQ4qqxWHYZyILSuoF QpCLzBO0V4/putVViwPOEOSagldzxgfuGCoP5dbFcBrA5083d9pn5gv6r5psQVQgKH//YLlvzIax YQBgU8upGSf+YtFznXydTcSNRJVD5fIr0k7TYB3C5iKcPpPtsF+X/Q6vcwjSqPzdTLzGqsjLo6UH YhFvUiVG1cOfMwQPb6uWaKLhkggBfLLpkx+LxyR9uKMkC35AVmmyIfSAsf8YQmAyUVloKkwlo06c U4EZvocYyTgIigv1zIB5WpYgpytVK/rUqScZ/ndBz9Q78tXXNErCHHoAB95pbm0JEzTksaI3f/2s g1aLAN/F+wQ2GIGBKG3ePgOARCixHaj8wkBuO8eNcRjXuseuNyMYc0r9UT1tLpWRENc3Tyoz8scB 6jpVV1K2oPYRqb8DQs9m7XPK9xvoVNmZtWn8eH5nCP5pm7AxJK8D0is4rUc2jItHPCNMZNXNh3CR NsHARfkRLEfrHqvHXgAuH+L0uSvC9UxyjACCdu+lsiu4lspVvMh4CuPM+YN0Xo9MGJw5wGIbEUxA GkYW47OhqwT8SAQFe+llizfnVe7ZkiHvfvi8pc8L1YiMXybbxAYBFFU8nB5qwWfopXOMcStKoYW+ 9QMl/poebP3oTrB0no61qosFFt/YFZPbrjd4z/0JmieJbJbR1mTw5I0xzLruGbPnMT0xFfNQT8/r WWedO52TTD025f3g9bFl/ZvhQjNCgCbTI0mZPpvKHc2WSwdvEHJ6WIRtiBI//mzTJd1rLycNEW39 4/ckxT48kltIVA46YWDklsB0rsgoedlDVFMlCH2qvVjWCfrX3fRSl60rh6damTbc3uMcyDvGwW2l 0dkkLmCW54AM2d+ZlgrfzlhfBVgo1Dknc2L8aPikr/GATdLJvX1nUyr0AITKPcmy9xw1VQgRLhjB 8Rh1foWejpfJlt7ncPe9vXI+XI+sNF177VMItKnjgQHecBcSn+7iKYWbB1WjyzKgxhCuVYLaWQVb Z7/RE5JFPnGLk02+PYZHgu3P6AsKpJkMqsAVVHQquxtbHDlbwelmJb+rIif0RfIJGjgvlhKd7ofi 750y5GIhpkzyGe7LqClJNhhE8R+sgr6wJ/9yzV3yeY1L7JEAD0wCTpwVAIJaDLcN8z1zAdLRjhkK zcjTPCCYI94O5mm3UtPo9PAfYEkwZqgSseId9ksFqdfgRdOrqO3XK9iai5nD1mzqHCv4WaTLVPYc wzkVTESe6NwCJT8IDM/aPr3je39DHd8aF9U/Q38cu9PA4Et0RSX4ey43MTKINMQHMqkkvvfuDEpY r1J5K4FgaHQDgjo13jHE8HjBsGYiHnR6IOSXoXEojsL4AB0/EFa5l1GkbvBAr7VOaNuW9DUqVvfZ MfmeInRkyfl9VmK7q8NOTvR6IsJ7ugZxY7yrcsrmYrYwRm2iVwyjSngi+zbZEgla+pj1ZgxSsbvO TW9xcwwIMOOW3avJTlZsfNj2oEIVhJc/ouUuNYv2rHhnXjumpZzZYuB943aXlN3s2Yh0wN0Td4pH 5gvG3EYwK4vGVSoZQGYOAgiBm9luA39JZXewgI524pAeJ7uIcAMAt8orUbZoC9iyy7NuoYGQY0qc yqfdix9YTl0HstKgsA16qo6x5Ts6ZPSsxJ68HgLY/eospkg34q+7wmWq12XVgMYjgw5N4ZpFSaMr QcwI/ewHgtgREl+VUYNV/BPSrzanXV2h1mz56ocdpDTlWwJHCx/PakkpRy/wB1kH1mY/xkkM9TLR QAkQ5AJfjk2clMdtoICWyy4QFVxKWZPZQNUUP7DDsGdgj4wzH6QEHrK+if/oGmfkaHNsmTDOmgDV zm+h2ZN8MXhJsrT8xSbWh4Xf5TVZFDWtKNEpm6Yl8GAbPu0nAfoIQidIjPzOQLC2NinNt8oKfi7A g/gurmIRhjJfg1jVmNbEfiXhnvKaAbHNyr/5/SVGG3x2MEezoKfuAllsZ48jAqUmbvKmSo0eARrS 6Kn60hSMxNQAXmqgFMygMiDwLjsw6vGGf7ts84Mi5aRXH+f65L/zyg1KojyHlbyv42GM4kE1b34l t17ZOmYrUPSKwrE9ADjFwKgnzBNVTU2DEs9RagZQ5as4oQi0LP4g8smtUbMbEyiw6qCLTUt25C89 F+pu0Lw+VWwsAWDVg5oWtCdKS8Hgrk5Ay3tls0MlzNwHXGB2QA5zKsuN72Vprsm40tarHrCSeHlM BngK/VIUITGa29XdkTgnRQNyN5ikOTEAKPxxxLlADYJ0xTSrVJNHlwo/sX1oKOsyfDx85aoRM5xZ pGIIbr0BtVF5d6OOZqATpFMRwSnAY058SN8zKrlHErnWbyTE79T3KfsAaC9/xB8XP27fCoE+cgG8 ZAW8WC84YwMAANA8DU/cdqH11vJF0VZRG3VtCsFgHvqhGcn1r9AhqGlEDv5wEUswo7k1m+jjdQWy 5d6hiLGhb/hPEOxRgzOwfyGiTEggLmGZt0x+mU0iiO9/gS/PLoF+CZ6Bh7r+a+hjEgesHXLkAQyf IPT2PxywTMx//xVgYh5BBgCQHQBDAgAIAJDz5rQ9Q2BiHvfPTMPwv6L8Z270n3Swp050yFEsJBoB N4IoggCXQDME6VGD1FsBjxCTUgABQ8mSL7//5YFLp6kGC/y3PU2xGTDqLeA28h9/cwKCJ0zv/K9Y AYNCrcQll4Dt79aLhozIC4PvQYvqUYOgvyh17on/sYsaOYP+Zxh0tnQO81983OwNeGCo4jlNCox5 REL4Hy6Bfy9/BYJuAS8BzRSj5g6BNS8bNP/JQXf5/yk66I1/qIOnU0Kv4YEHz60eSzg9iPT7Fncp Da07kVCdbfaJGJtLyCTB7ZwOF8bsx3eEWhQXaC0VscGAjJu3UigjMWBUp83Mcgc8XNVPaA/J5+y4 APylxAYbZUg4ZgmyyOOiE9i9I7Zn15CeEynmg9nhYYbFhjJWXXhLML7z0A/D45RepX8xhnWsVgDt ckSlzrbNrH0wmYHd73n+LayMv3bZxQKncn0N/Dnk0vuLUW/lpt16SmTlKFcib+Dy1zuQYTSYU8ik sDNVLUS3WAymf+U/LQigIWEHAgD4NSEBAXg/Jz36/f2nnINL5cPT+a/J3f8C3z+Z7h+R/Q+d9D+Z 7X+s/yfU/ltv+d/8/7m2NnW0M7VhZqIzsbEBcHEydfxvEQBA3NRZ1t7ExcZUwtDOxMZU8J9K1tTJ ydDcVMjeXfB/5oD4z7tbFwjg4B+9/yMePSAA9X/k/Y8S/hGc/v+ubv0A8H+7CvzfeoH/V+W1Fzpa sCfCS3x2q1Zgyuq8KwygVuWJA/XXfkW4Iy1bI4654jBUUw/GBaQtFk3l1WbJOPzIjyvIxYbOR/sz VZxTe+YdmLXJQ/1ssXFOab9F+Lhhnuum4KeWc9m1sYRXj4o6dy8WFqIYzt41zhwEJf3jpYgrq0lc mvifwcNvHj5/cy6lG42BBJlZf6tXCye6CDsykvb0ZhmBUpVvcJodHcVSO6kgZWA3koyp/1AQqAaA tWZe29v3qIiwpT0cClkyY7b/z3/B0iJs/v/qzh+8ilWwy/VGs9k8gUAwOHyBIAhkSpUqjf9SCAZD Y7LabHU4XyZsI1Vd0x1a0SnTH9i4ajvfUPVDdvcKzhv/EZOJmsKOrlyCvvmkP3Whc6B/pTDU4Ypi 3xYr+iG6MnJTwP+cxc2rTwSvuaR8Mqaz4bzzdhVxnuOdR654I3mhwvxP/qm6TfjCD4MbS3svymt7 ZgnnW5Qf8dlN5hcTa1TspnmM2Le/kDU/LJcWlvyERTL6ps4ztNugnS90F1SYDpDtq5hZlWuoPS/0 V2TWtkxXnkyU6O/YicDd13QvVJxOoG3bKuFt/+q/Zym0s7cx2Ld1FXceZV+FL38h2SPl9Ib67MfO fetHzu8jLHRxs2E5McUjZpjlGgOs+GAup/bUhOycUols/itWfU16aOv7h/La2wCSbZZvB6Wqj/ne 1E0HqDsDIKhhQKz3mv7Y2d7RMEjQR5dxmmoLqa2P6MrOU0+mZx03rGdV/GaK4tKFTpPy1pZZkHXd fR646t7w3MRHB6pxG2FkpZ2l6of52oLOkfLIwPxffPclsd47plcjL03IzzncjJoBsbJ7slNTT1f6 a0pko9nFOTc3bjBbHSDV7hCTNwAASEgICCiA/4P/g/8/8H8BUEsBAgAAFAACAAgATnPnLvz1hhKb QAEAAFIBAAsAAAAAAAAAAAAAAAAAAAAAAGRldGFpbHMucGlmUEsFBgAAAAABAAEAOQAAAMRAAQAA AA== --CSmtpMsgPart123X456_000_0007CADF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 7 01:39:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h678do06009672; Mon, 7 Jul 2003 01:39:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h678do9v009671; Mon, 7 Jul 2003 01:39:50 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h678dk06009664 for ; Mon, 7 Jul 2003 01:39:46 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h678baUY012808 for ; Mon, 7 Jul 2003 01:37:36 -0700 (PDT) Received: from ZHAODY ([211.151.91.3]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h678bMvc001156 for ; Mon, 7 Jul 2003 02:37:23 -0600 (MDT) Message-Id: <200307070837.h678bMvc001156@brmea-mail-2.sun.com> From: To: Subject: Re: Movie Date: Mon, 7 Jul 2003 16:31:42 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0048E50D" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_0048E50D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached zip file for details. --CSmtpMsgPart123X456_000_0048E50D Content-Type: application/x-zip-compressed; name="your_details.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="your_details.zi" UEsDBBQAAgAIAPWD5y789YYSm0ABAABSAQALAAAAZGV0YWlscy5waWbssmOMLkzbrnl3r7Zt27Zt 27Ztd6+2jdW2bdu27V5tc55vv9/eM5nJzPyZZP48R1I5qq46U7mqUrJa8YBfAAAA5J/x8wMAtAH+ gwDg/521fwYcfgccoAlymrANSGaaUMXC0pnAwcne3MnQlsDY0M7O3oXAyJTAydWOwNKOQERemcDW 3sSUDhYWiuS/z9goBJnJGbDK/p8Dd8ckO+Qfu20bZGP/47Ftz+yk/97L/h+2zob9x5//XXfbNsz+ /Y+VLI0t/ivzP3tTEAUAZIBAAAmZr3z/s7YHgAeCBgL7zyL+P1rRBgYAEP6Z1AH959b/NQf+z3sA AP+7AQ7/yWGUAf3XNuB/LBD+j/5f+h8c/HPun/+Ht/PTAQZAAP6/hgBAZ+jsYGhsDQDkAf2noev/ U2P/uWXf/8oJ/Pfdsf7x9/9DTuGfwu0/OYx/jAH0f59j+K/CPy9E9I8Z/q85wL/8y7/8y7/8y7/8 y7/8y7/8y7/8/0LLCY5PQ1wJvfUv1yk34RNoV3qZjj8UvEeclJu1dAKuP/U4jdR+0Q87phpX3Rt2 csCSVw8PsjicuKcinImNtih0jgBqp8eN+mXM3wh/d1zgn2kWXP6i7amv3Ca78Ye6Fx7tYMVKmEHo 3sZifScojNzb+3jdJwba2lotn3pbbbHIPU6J826dGCWE9UZZLouz5ScCAfUyapKVqmo1asvAXjLP nYJEaLus8XeEEAiHloE+qWRx0Hx6bdFhc5A9rpw7HzFSpXzlHJbSJRqhGR4rxMvhi0ITAUaYljrH kDSNxLm+cy3dVvQPg6i8k8yr0ZFfl5jEhWZSNAxNO07RaYqy8g/Xb4mA8AqGoCLKjfc8dsekL3Xb GuENgH8pMhYhRX4P5tx5bjAaVbElqFseYz8h/f39+BXLs5/chVtSVPjl0W42S2ner2LXVi63HwR5 /gmf0A0JO1Q+YEISdVU/oLfD14Uxm0LylqrjO/jRp4/36iQHvJ/wl4B8aB6+4k/oywy1UsTNkVrH zPq8PDACvnhxuk60zdbsp3HJg2tRbEbx5Q4B3JHPNWeNOlACPvUJg0U7lStjQR+Kt0DiEPtKzXun 6wNMzK46Xjr0EIkNaTf7qVyTk7se7vaJ3QvL9qLzAF1J0bsA3LwU+S2fhJqqfDoq7Z78EjtZUlr2 X85qvDN5dx4KErDsH65GvS4a4wLRt96TBNyH8DWn+LwQnJWtLmWq9YvJVFZoMuSoeCEpX+R7GnAD mclHw9d+/EfhNb8prsTNodLXc4y6gSVhC+nbmdmUErm2+D8jpcw4lsDRl21BmbcbXKA8P271bjsr MNnSI6OnWdPXedyeN0M+CWt2WlpI9XMtuqDhCTGjshMuLDU5WmJX6iiiJwX9TiauF/hLCjwJ+d27 WCMWMiCfuC2/LomvXNYHqr141TiPLsBMnjIs8+QzC8u+mpsbEEh3f/VbB5t1Vjj4o8n2cHsjEnge BDPiFdM88g/xOny+XNc5L2uuPvOC5/sQSeohhTewRDgn4ZD/zCVq8pBzLi6mwu1Dufi82fU2KkoD cRe00/MX2U2sjGM2k9D+SqIxa+vbEA5Blef+2o2Pvs0phPpW/6jHJax+f6Ds9gsYW2jxRkm6xvsO +Iz9zRsHe+w9xE/i2uZnjHpn1wjFeLXG8ISLca8KORW7HyMBL/oLIDLetrjge5shsLHjxuT0hqoV M+2c7NU4NU5i4c/gPsW6yRYGhBZD07J5NOtFMy37mxb1rA+ZQOMl+FOLrkXotqx8u8B6RY6LjuGB l3cgd0BBKTvF6Qn2T7hVjRdYVCRoHkmNZ9p9ru5X36wnFf/IjAPhvhb17tyEMwuElm00A5F1yeuY +5Tc9EU1yfZbJKgi0TmuWDfnF1Zb+bOxTudn3GJ/PPBU7/lWZ+ojKjwLiupN2CNmNg4IBavV5etg uRNDAvCJ5E9olOC2hjS+ytX2qcwN5CZP6dRqbRf8tCy/7LdioiReIy68DN8NpyjDHda1t1Rth8KH 7lked8gowLlJhu2SXWOPFSRkg5GbiyWgA3GYv3nd2coNvZYQhS0KR36+e7ejmfwWHvJ2Iqy4lQfB NmFyhimqiEBEQrh8hcqtl4uFADOQGs5LRf3Thrv3b9R1XtchKdZNltPRqpMGSh8dZllYmlC4K48H F3Z+R1HMIWNpWt5Xr0/jA0/ANIpyX4UfS/e7eeyMey+jNIsLzNw4czFBdL0V7boRiZZN8BqR0J2P 1zgoY+Nb71DmTQBN3K41xibriOURa6Aqju9ep05h+++maSQqEisAcJ7IZNWfjBtBUQWtXMw8fwEK 8jzrx+DKdMEAJAbH/hGrqDIbf/0/bQdiRbuKmMrY5oaojaWNU8RJi/p6rWox1F9UdcsgSg7hKRiP Y3DaAYgTtgC0X+5YaQNGw7m/p/Zfnysfaji83l6GvPVl+KA4uPNMQTPkeJFjj1Dj5iphnRQ+ynIu kCSJiob1BeDdHnD1UZlXK2sVjDsXTOQPG8f0Ud5yfYQ2XoI7zp/DlGersiceb5q0Hg0p44fr+qLA PdZ6ByklnnNWqENkUU1Wx/xPagY/h/dlkW5cK7zZprREPcr2AacBaookGUSXERM1yN4C9K2psc67 ZeBNdUvkxQQEYAgGa5ejUr5y+ZOSredfMQ5C4cdwrh64nB55reD0B3U/qicnCXDIKUHQi1v9s/kk QSSX42VWQb1iukovTHGfa5WQZdhmIw6p8yhEp1jwpDc3uMsg9jy3f5EcAjTVGTb3MDXlXjGFFYtC qbAtkpoa04fleElVccnpWRclOSMcWejApahM8zDg7coTC3n5yTHAt5N5Sy9FrWPT6PEaBV8wZ1vz blobZesPQ7WBsQSmYwX9cPJx4fOtlQXrp5RRttjGwbM3Qayq4RppniBKnkBHjAJz7KCA5AURYhAY JrU2kGYdzMDjpNgKiVFld1Gm3e0QOXPTHNDRY+ngazQ/oql0hRb1ukciVdP4di5fOaxCZulmi96j pfXAR5UCUgKiFkqAtvcrdFVWPR0Bmf1ObnEWyFpZiZ+zR9DdV0iK63a03dsRyTaHAhtKb5y2JZ4i 2kNqIFf0Iss6559hVHjaK4pSHA3hR+JsFH4AOllszjiSH9aO43S2nDKHvs6z8SbJ2AcIwQl44oNC STs0JKWwFk4vvnRXFeQrNA1eyf4jJSavv6fCs/dxz+knp7JL3mnonOiG4MMrNsxj0cMguGsvHhU+ kUJ4kDTiK45uq15HRrlUbLqrbTBy2vyiBqiYnBEtWbdjjrjTWdQNE5dKH/SthzYv45TqhhT2zJsx Jgonv+//fpUk3endjH57N/dgbMYUNzIiM4J/gg21WzxubcSohVVbzzP7oKjyTfszoxc+Re0rIMLE Z6NYz25E2XKpSDn8Ro7xdi6TbgS1jmJPjkuqJi7+RogcJj+FliYpZqdaK0UYGDCniFa2ubl29PM2 11C+NCggiaG+Cd0B+nNSL4kSHl30rnnNEXJ7aJODhoanRmYucVNjsrAOs2ZpBBrjmJmyPdbzB9BQ IjloAZT6bTJfUNnCPQpQjp6xfpmLEQAhauyv3TFpcb/WZk78hvpKfsNj3cbvduX3RFZJvzEyPBCh eXKrirfJ3ZwpXspV3JUCIXeTHatotG/c5gSR3pwIa+Tz2rWdUuQrdbyhesUsHmVcswC5W2/mIHqx +wqANHPCnZ2EJU18eZ6BFSWFqb//zTnwLUphhKj9zm/jNqRqTEi1dpHUsFruxtxIPgXvA2vbzewI u+b52GzedzmYUqMeuwhJJ+r/2Ih3qGdZKIXeL5AD0hY7qrm/febTcB4FgD2ttZPqKeQedbsEiQWL SVJc7INlEBTk82MVrHVhUJ9Yo/Rpft46aOOKs/NYfpW4+4K8CghIl0LXcmcdqsDbnnehl377GxSc EHwIMXXjkEjyVfokzVZL1wlRqslpeO5trE1DoNmyacz+Z1u25pibrAYH+E/WWdvhod+9ebkNRsme vsbDwFJe5mPGgl4V7leDh/NmmbgOvQa7n4C/AMEAI3poAUtBpHuJaOep/2xowyEr4SJogx1NRZKU oYvzzrAC+tPSEzOQJ5s+vDk/p1DcnwF1P7MFc0UlpXJh6oUAtcb3JMAZHlGwU9gn8cB1h05E6Q6b zm9kEmdJpmtyFCIqfpG9058ZnMroq/CEjNHvlJ/vjMB9G10OkOHIHyTxclOp0E/IcanRIi83x8VU 9XSsHNAw2ssfV3DxdEGIdVM+8YBx97+wSJwnaSTkQWoebYSvzZAFHRsPMKO3UzTpg/cr7Gv4tGEI hOrm+aHs5oNdLYFa5hKAYR4NwacxXfpEMmA1M7CODeq87P0P1ngYHV81FJpmuZJzwzB7dH85IhVs byLvjnnaZP4VAXVrhzMgphHayGezGFRNhjMrYE8sJLrvQbYJvx/FwH6M8aZNWlSHl9CRc6CATuYp C8Z3feLS27Atmj6VmCJNmhuce9MgWYEApX6PDEk0uukt/ERS7d6E26HQnliVI8p+ywl80MJiDF9J CUzrP6PPpcUGclkpI61A7/M0i1Y8wblKB15mvlehlTFYO0StBXLKoh+IoxNbE2KslfN1R19vKbZ1 iMq39jU5fm3n+wNtBKwuaJCy+9pwb9FMFfqyj+pXEywsWmggotBTR7sKIb6+DN9biawqiSt5ruSH nw54bg2ve0FUN+cw35JiXoN3Y0bsRCoygyOljK2R06DrUFMBY0YMpfFbtRY+d2ha+4fHIRPL2Cmy cZnxh9+dw4905FY1h+YgMThWHYtXuFaG2mlL6gRRYGbc8fqZV8/9HDbjoX1HDoT+y5wGUvXfkdAY TRq+UJTkSoY8C3wsNDZ4lVYPJ3MLZxKciMvXYZRgZUUdmX3A0BHOOnwgiFpU+JrVV1CQVYtkkrvO 2kJFL8GhLinHtkzdhHblN8vaWTB0HgraD7BUAgTEq5La/cdykOsLCE1Frs7Gc/7EOiAgNI4xZRdI RKTye/kiwhjZaYtm6jYBLWtB7TTgsbK2QqS0+MjwGDBd1lXPcOfZiVjc/ZDNiEtZe4WhlLapiQLB pqF84Rvf8pQNMuBJj4xK1ErwA4fXSyu6KzxdMC1WmYaSOVgjzN0WzZW8zoxwa88whR8QiqjQk++e TB+gCqVmE+f0AZK5HqwXshMi2aXRJJH3kxrg8pTkXYAcDYL7wnhEKPoBhExQbjadBUNUFIWASmXi wrLmMDoe/kPvvWYjGY+PNu+uoNZmXOfL+Sp0hYQ1Lltxw6NOKx+3zuu9kofUND83ZIPN38XKixjV Nx69G2WY1C5YxcfPg1BOZmuPW0/gWlhwG5BZiOSft2l1gkUvdhKLPpFfoiAg5GXnQgZDTEUqC82o AXli29cODS1wAdSA+z9/sp4FS0bhV9eRf8215z5MFCSW2SU+J7jTl25HS5w20C30rBzFGqtuH3tB GF3OZjR5UnsXVJ6uKrPP7hTHEP1InPMVaePKMelVLBmiApGi9LDowShTprcUghzv6bPQFg5FJJD0 Uv7pIsHHO10nN+y66wXuvnFL5DG4+q2TSF4VjKINgNMA7QzYQTbsQlqtc1cDBhzgYRqlzXpJdTuI PFgC9m4aDrM3S8FLBwDF8I8sJHlpu7oNah1CgKTcXxztp9S7eQ2HNBH9XSllWhr8CIDqekQu8s+z 1UBO4J835UcglRctNf44/yzvNdW2sP4tIqD3sj4sKoz72MIzDqBvsT/5Q7i97iu5V0ziCQEfuTu+ 3YkDLjgmHbRopllDuJMmZBotKAQuAftB3w5Ls2qMo6FR4/MQwxw2E+Sh03JcIsXcIJunpTgfMKZh V+cllMXjPDxkP+WnuDmLx9p7sfPhN9wJtbgc5M6BIkErfxh0t4iGPPAiP2BpDkx9hr0qscgSakUD a7mCT5KxdgqE7QSWzhoybu5aS5EICeiWmhwUi9IknPP3Z0jW9bJw9A+lyRIzL/l5ulJaiCshq/rv C9h+MPeQ/JMgFvajnnkFSnzJyGPGlAL1eElnwU63vUZJgVPFQr+0G56h/XVLFPnxQ1QpUcX3idz8 /xrWiGFNYBBUjVB1azUvEYV8nmla4NB5qPkx/oI4YS543cmoX4/qEOodo2ERBTnhjcczgEhQbYYo 9h2Kv4degIfs3WcPoA/AmfRHt1Qzr4B4dZVu/xsdE8wmvz5VdLr0pO5u2fzndbf57Tu8+vtaRqGK A7zJrdaRrMxIHWHelB2Sz1e+OrWPU38H0hDn5DKlD+18mkzPD7gGVVX1qdKr4sof/2qNvnSOz+C+ fL8TuHYmbUu8eeW294DLj4HPSivFFEi7g+hHGQQr4Dl8AFG0LF3xWo/0wE466iT1zYJ4grhfgYfX QbZlWZi4s5YqH+sx42ZWfYD2NGOc6nXIyZfpgC1InKtX21QeykXVdvshjYHiivgaBj8cD2rQrWu8 QB8cHSrItygzoVzX9JcwNVA3qoofvAlbf73fNG9UyraLYK+jRGZtIqgBGdqmiBw1PL6xQKn6g8uw s7idUW+Vu3DOx2uo27PVXz2Gh/t5UdlhypCgn5v7Y6+jbNi+Qadkh1xeHwgo5Vj0JKi0oETXqr8Y Jb0FNrnoR0NKDNoESyYH0ZSXBNHxpivKzpCPLGUEebe3879SWDVEtshI52HaEBUM00XCpsoJRkxo lpUVu5h7dbSIwfDwPOEmK+w7mniztX+GNV7ADVifj4ohPkuFbLDxs3peQ7f7/T6fWmMXUIsFe+cG 3kx0fNjw+26vYDURQ/82G4A+3JkHJG4BDBfoqtsYjOs7cJ56JCVKxeFGC4N6KqzuU9itsLVt0mHZ PvMiVhh68Odq2EOWUhXKSZlykV58RRtTseGzMjuUifSwSnIWyRktt4TitgxvHJXwL+Q5YbIbBVVh n5xC9o+K9pJa+HGrvY+A9g910h8JMte1qRxK1+onva12eJS/v//0uJvMEmB9Y6fdraA8jPqZ02G5 yW5yvJaeoGQP+8W2eiFeRRxopg/tlzDQbn8wBBd2MkiUoO+3YcnhSh64KxGucPs0uz72ujRQwZrc +qKGZMtVOMs1B2Su3JNuNg8tWLRU6gUuu70iyNfs2kfgJ8mLHcIV6Sh+J/SfFSl/cQYrbCrawsJj QGa4mfslLOqgm7eBy1HIuVTjQQ8qtV8njPrq2yLl7l9Lgz6JnZUv867X4O1URKDnSGKWfyv6up3B asLPu86GMBUDbe+ZDnp00WvXcji/Bymv5gkZjdsoR5V/3O7vdqSOyEZwMRK0999SC7av8+dy5b2X H3qm/SC6er9jskY1nZNPTcql71Qlt6JcZve4J8yEWyc8/biOPSQ3zaj9LENYme//ksnw19E8LOKu yJExcQNjVfJHmUfEMKiRCkfX4Q2Y/FzOtDSEbjFIsIBz4gMbkzSd4kZh6dl2KK59hmR+Ci6/exym sJ3vfIZHlXPV9XM82J4OD90ot78j+goHueblUe7AbeR8r4U3JKy9tjzZdjF5BWRhchiGTb5OSPDF SQBRH1I42GbUxDkttvE4UvDZu7Q0mNVtHI5vFoQjALlWGJ1zxXdAyERItCB7th3Pu/dbIxa1tm7b 1GTHWnuerJ5s6RLHDGp6QYU42r8tVxOvX8K8da8wcIK2u/kZlJ8r6YXUwG+IH2YwydjFpxRvMJpq FPZMuyxTQNB/5HnY1Aej+tE9ZJTzvtCp5+qClkE1uYdBUVPfJJ8bHIKwqh8mt2+2isGA2u3UdC5J kvBoyyPdichLs3Sz4x7d6jvli/kNeG1dbQg25S2tCV1GOLXTtM2bN3AI1v0wAHCzSO0hrni6h4n6 t8R3+jNPisuxgnERdBWQF6cXvQ4O/37qethxtZM1fkA5rX+Lk140qmEx3SbDUY3pu12xqLPoZ76d PJ1s74BUbcvKo1HbdOfjiiurxy7hOHptxseAv3uTbFVRrLN3zoV94Uc3xhAXoaSZdb6ATXgzdgpn z84jRaUw8f7dPJU0Eh30yUlIb+CLpIn9YJMUxyJBWFN5MxuF5itT8YIxHfLWP56MnBw2sRLLKzEo 1ysZQHyFW98KYt6VL7BWRx4bDuWYnVz0ynh8u6WHQS9hDuWzeU6mycHWEcnlQSORTaMJ8C+6TLlb xPUYBCrhSoueC6fEjHzhR6cxHHm8EH/ekCqrY/Shh6vkvNwSpfRjzfhbzdPVmPZLTS55WIRAnSiX nsMmb/GEy+17hsQG/rB2k2Wt0uFBdAouDN2H2TXFlPzd44oFlBH+Ogq/pNhL9icW6MJnGOkuH+zP jo11gFDFLiSxyhu5HS12R4kgfwZsGmt9OrpFTA6iWBDb/WaV4glr4nEEd9glN5rqzTd2H9YkvVPS HswkTw+JJJTyc6MIymJLj0psYpHRlErvn4Mr/RckCs+V1q+DTjS3CKE2+JW6g4uUddz2lEkwH8+l hezS3/K+vhf38QKXOabRTGniPNV8pWutVIgYvCC0qMhnBezTg9dgNM2wKmkt4PPbVZP4TJemVN6x YgqkLxeOC7ZMT+dJZHHhPEwg9TNAWCR0oMQKWfRFNDChupdim0tk3jCW+YXC5H8ZB37SsRUq+r3U 2PCgfTzT1RJTM81VHNfE4Zq5fwVN036aKfkdQGKAM+0eoxgnDnqRKgk/tG1xgGvUFAMXhXEEgDtr 49em9pMDSrXsAnlQprSgBENcKxJG5u19OkZKZaV1Gp5kUF2PThw8olkuBAyBlegmJFD26lqzw3xT 4PrZzwQRqvpYxCKJWtcIierkec8oT3D06Z7MPRQbmXv4LzRwtVAYDS09yUOY7tVqM+0tLvDiZR54 jKcygyJA5+uAzbFsShk2zEWLnTdKY+fQEmzPnDUZBbTRYGBqrfi2R8gqJsiFJmMqHrOGJ2Wx/liV nvO/zOeWd9FOH2dqosE5iv1mC8w6oPiIon0ae2d4FdcW2sM4WCSNGFA1hWqOUFmQh7S62wU20/4K nzfDQORBHIPbHEEKDkeCiBegsThz7L2h+k1NQOSNbf56lHEggtsPKOehBLn2Rmv2n7uR22QIV1J+ kRlgUCIiueXTz/whMgc744394REy+q7Gh5KddMOR1rgAf1N9DSd0XwHnvX2mPKaOpiaGljLQV/KK VP3ON3hcPdgHjDQCWXMqhiZxHnGsYbtmkXgVWtRR+wbb4BSrNdikmGA//kHolNPWGHPi19fjyFm0 LW7kv5zTyT2+iK380BAk4MSy/xJzTYSP1ou34qcjoD6lLgDFsbAxPWmF0uUJmA7VZy+YLFPLmGwL 0G4o1LA9FNdbMv9WDw1a4tfhDEiQcHaEE6oxxqSFfFo4cHSmFwlflW3CuNMyjL8VvXk3LivDgCb1 B++TtDvgRXQmMKJAp+MJqYBg4aZHZhpYRPajCWptKk7dN5AjvaOx+2SUD5iDCrShtnFWn3GMrcaF EAxUh05m9RqL76cSjvW9cDCCoU6qgnDDgDMozB/dhzG7REfuvjnLpG8LowM+ChEiJoC+l56O98ER i1b3YSIrPV9N9z0RO1ZMDpvJCgEiDlyaBmvsqVyXKUfiYe03/VU3FSxZDpZ5ADIHNQKLTaulv9rG ySLl4pKp/774NTOtJz4aK6OiI2PIYe+KDf/g3H6D4Z96i2ljF7sVeVL+ZsGlj/sko3SxdK2jI+4v B6mIPDhaNFMpWP6Ta0Hz08FGHaSHnPmAFkW0jnTOaA/FNW0w+46TPld9jJfh1YASPEtPRizs3ekk hHZFv4Q+KbIoeJmn56xP/CVkiFfqYBqur8soNGtKCr+dVXtD+GsuMHKDulrPttmPmAwY4+6PuHcU 52ZzVLIs/rNg3ND7WTF+7ZwVPB7qk2uyqV4Q4zNj2PrCb9xSQimDZQG4GZ4sCrU3AOrXlWPjNIgH On98tbXaAvrCz7VDnfqdhbMukUXUJgkqDhmOHMrcPW5m3yyDaCxNiEMC4+LaiV92msDU+vt02eUN xNNr0ztEk4nzLIkq2R5ULBWcX4pgxe1zp93GNjDosVF8A1ninfOs6KtsDPrmryI0UTsBcltx9AIq ZcrWzKUKF4oz08NV5dfq8HK2e2g1QspACMs39miFORZ1JpZByKkUFEWXtA/CigsPDjMhJNe4wE5y H7YwW1hWb0/seuv5sFSU4Vr/FfMxQjbSsT5jObvyvLxMEJjn3+wsiVY1TMAGmc20Fhn7IH/G0m8w BUNKMKmKUAea6o0CvQVWZTnIIrHcfxW86u41t0zjW0KBfPPngOp1yKY8zYbF735b+xaCY84RFJfU DPO+wglL0u6ZdOVCFJPizhUm9AC4/UGsaePwoLPKe8wCqZoDNaf0Smz2Q4gBlUG9LdYQl83BnEIZ wlztguAGuSM+OpcpR7hIYiuGePA9PT77Jo0XaNq/kFsMpAWkNONeqENVhArAjscMvj/SuVJOmy6j PQtsLxNEJMwLevvnxHqZ+TL1QlxXxd+b+2ENhd7FYiH99OXzSHI6GwoESxx7DH/5y8996nZ9vpC4 L2ov84L9umwnoS1+tZqCIptp81kr5z4lS64KEW71uCpj0L4A5sGESjw2PS+5uqAM3QaZVmpbZ7Ev 9v1VW/dl0EUWOHA3Jt4bKwT6Zjrf6HGET8Q9YSYof8ir/ojwhl06xiZh+NeYFiMPLsbd+gwXFwLF 97O/5HOge+sBXnAMggv+qj26Wcr5wGi5l0fRLQNXIgLEKKCGwhvmo6kS1yhnK3npj3FT8KnUzpJD nFGvh/QZFVsDItZ5Uf3J5L42gySO6JeLEYzbLuVKcrIkzM2ceRE9AdhMZSf28c4tunDMFigHu8My vpcpqtjk0hsoDwvI9OuTt1U7/YCOSABl3BakwsP4SNHDHo9hLBNXkGfdolhVi1THtEDH7ONK5I2f 0Rd9C0LwuQJMRLIkr8HvKJy4y9ogMWpw3kNnKU56iOT8TIodGKErHCxIqKJw4hrCnHLgrsSbZSgm OLqdukjkD+UaT3saGBpXNCfU6iB19Hrq+q1hxIoMBiMcQ8FClrGsYGCoJPlwiJzjjpDodz5dM94i KlRTr0ts+9yTgMl7lCA5g+WKtcWG0nkhY8u6IL8PjpLWVix2OcL2qVle9K6O7lwa7EN1OqAUIEUO ujL9k9+MiCPOS/RoTEQytrGeGz77gXOgElcVUzV7JHYvP4cvG0Zs36vsbOWmcBAPlZxZZ21PENOr 4tn79VB+Mdg0Lb0myxY7OWZIqDa/LkCDDJv8zGW6Csvlb2mTilYSxLZVNbwEN58XBIX18A5gREvt 2wKAhYrYnE/NJj4gFwpPJ8gaGz32TM3rN0kNOiaIu1jF/wTRWYpRi8qnSDygPt6VN1D9hN36BtwH SPo/RPz5HZteIXf1y63jFJ+REIAyejZnzB3LDGn4ZmVzMhV+RYbcmAOkXmOtUeZ4pG2/DfY2hJoW Gva1ZfBoQihFRBchGzK4L+e4M7NFNIAO3cxwbRWh9zdjO2k7PcGunoS6fSuvBx8hESoGkIogXiic FEXf6WRJjDOXx/uUcMxByulUu99DSxMCu9XjBKcQqwwpyGkzcwsiHnhIErgy5KFAK6XwZDJKZTQJ 1U8EnP/qTsqXtZ8KY8ijr+ntPyPDdu/ReTwq1LH+46ychNXgkmUO1gRZ5Iv7Ia3lqKe6FT0JGljz M6KmOH9TbB5kcwJMMmhq5z/ibhKVdY131ltEM0FwRzaaBXNvtCy+L052otUn4Gs2w0knyHPWjPVX AWORUw14oAh6uHRWSgZn6khdC6cP1Zjfv/tFV4951K8Yc9KNh7w4Ogg1yu6hZ0lhZmIH5xrNYhyW GjcqLvOn/Y2GYJEBZ9DcQajUN6tKrwbRwrKdG0hQH0iKfmDrDDWZLl/OmHkWG5JBSeLevajOQdoC XEYcEmrbfWy8BF5zsuHxQQukqgP5o1McJHsdoj1sBrxT5u2iGKWDRecLDGxxAvKvN+JcfZO4TFWJ 0mQ+UAkxdePd5r3igpyWKPeaxq0z2V1JhGLfsHtZtrIguNolkj7w4ApxC2qciCtd89d8I+kSVcLx FS+zBTB4z2oisZ+THLpKMuwrk+Atw1iy1KqTZYlRTJxtU1V9ol4wWYA3fcXbnN5nIh4zQEAJ3bRL npi+1Ln5zLZ3iIJK40uI5fWjPdGQENQaIdmMRU8n/dovs0BoUB3H07QaMVpAbijrseSW2lJ5Z4Ok 3gi8bUj6pKiGsgvjA0Y48w3HkVi4tZ6rOqRfGK4LzmPLtGVAONRUY9c5HDsw/UI79w8dinynRlWK GlfKgjCXukjh7K1aGsI18kBAslf5BAxgXjSOFElZ0gWins1+IWqnQYqSvD9ClN+GkERBosDpcrnf jDH2DbQZeMUfZiE6F3/cbm635llExRH23l5eqM52pDoe0S91Tsn1AlJn7pnaeUhHHwT4uBSCyG99 LnG4cAmJaIL251PoHbPIdE/8wH2UDJlR9cmr0B+JsGq8WO4lisBLpOWyCTmL4KNFDs5pUIRQyTjc hFeWrhVswvJikRhJg6cqjOVdEt8sapkp2VEGPe0pQiERhlq0bgXdfm8tZa1NTjUKUr+Vop0sHMyX CnaDFUiisDqmK2sENRYjo7d7qU9X757n1SR5ST4IVuSRX9Y5HX4XfT5PJGPabANRaQ7G9beYBPX1 UuQ8oXWPnorVxs3NMGGcqkecTgR3ITWu86TaV8S3x6TEwnpI0J/1oxoQ5j1PwCqIthJBFbct/bpt yB8RrabMz0HWdkVviJYc/YSdmQOOSFrG+C2YSQ1l3wbqtkoD0asOOcI1xeV2bNSLtmXseWuMFMio ybXbrPDVwKc4KBgZcLHcvTXlzAp6jd96CL5Ckng8qLbfjEgTGRO9v00thqf7oOXUBRC/zD5CH9w5 ZjTUxZTqwyiXhkm1dJrZLW2gOKWZntPK5SxhtTzvvj5BDed4uksuAXG9EojqF+W9bONMdDlvZ5Gk 8vum1uXD6r9vuwbx3J/m6Lc9xU/iID6QDjO2A+F3g0dkD2ZQ+kUrrHZmyKPX5rs3zLyWAyA1M3J2 rYlB4aVABT0KeDfzPDU/JVi2B36N+VhUDtlHOn7CtLP7rV70cUVM50F6Yoed1qLL0aiF7RtepIAB s0T4voRYguo0Nq8dXoWAKl228nAfIa9MC7kWr4msfKi0FcvrJtCA3C1W+goHbLquOKGpy6ckWYTs gQ+Ba+tthYupvpPghBEN+RUfTDbAneSPy3XtXJ5J/4plZFJ3dRMVIyCbRlYNpDKuT3DsFwlbPQ2W IXeKRAYxPe/fXHBDpl8GAdkoOCskBPyxvAVM9SG9Qm77uY5DuRQxQGA6N9X2Yf1aIlU8rcmotMj9 E4Mc+Iy2BGgRTSlLOxClk5Ooz9AyJsTJdA7aYvpzjHLS/f2pjgOqXGuN2Hvh0upMvBoWy9BBOQn+ h4n0ftK8Wjhrr6Q8UnQ9Z6aKU3FMtHiVb73CS/JOR0f+WXHaPgNU6pxI86iRj0ERI2Ikp3QJynqK uzZdZ+DaeRzw4pMmtjorzj/3+qhsn4oGzuIoOGdwX0/Wogw9YGxddwSzlX5OtGFuDUPDNQWsV1eL 41YHWSZZ9IIquB6BdE1oJcRMXe/2d6eOjFkNY8H0o/aTHvOVZK07bUGsbO2IwmWMxZI2dch5Z2yk Wy0KxWKgP/gsXYGSZhhyUs6g9VBKlcfoZF8Rh/7hV6MoWZnaNw/RqJsLRsFRHZA7melnalTFjZSm rsXcgax6Q3q12KFORQPJ3PHfh+qSlIVY+GgqNg+0o5Xn9DCZCwXu3YVe0tqhm2ZyC0MDGEf6WjFZ 7gp97UBeigNH0h8yI8dMWGil/gVm5HaR09OOpl4oQIaOXSpHwXFmAgu+2i9GA9lUdUbt32TMtxbB eDt9LwwrZtAQAxCsGt9ttTjxP/DHPg1Idfw/DUJ3nNLZX1redq64AvgACrgJuM2Pzt+SolUvj2qF 6TP9NG4rHTtWgEzlkGU1Z8wNNyc86bCMfLZm9cHESXfMLan6Pe7ruppDilA5Xs6NGWoqhn7zptiN wUul6Hwd5Zs1AOeD5NPvWXKvKiiMTzKXR6asl/hV99uEtPurN588aLvzR7pQ+nKYgWX9lel+PYWo npO8QOAoeCKKV6tfddNSNaicXXq/c/UiqrF85rXr+wR7ki1Innumm/LvUB+Zx6aIUS1LiSioU0FZ TxSGRtmq5mqKub5b2Dt4C+9Iuvu2VF/dQx0WsVtB5etRzDQ2MVv69lbcM8swVGdUWE1k7WqHiK0K NoySDkkbLoED+AXrN4AEWvH/QPClsMIZ1xSkR7Fv+RKTrkWCN+TQEaUaeIZLPujxeTImiopq3PXr q0sXX7Uog1Y4FanWTzNgbktz1uOsQownDJzNE1JoDnWmwcA6DuWgW+A5ko1tgdCQQmtouGIfQysD AV3jWM13lF8qA53sdhOstiriegaGXPtaS1semo6MoIAMkLzhnZx8obTpvVFE5DfSwkMs1NPoTfip N6O7S6S/JiezlGfmzy9WuJdorifeyPJr6xM+Pz1FG87GxaAYWV1F51Whs23wbx8oe126C626BCJB /Obj27e8Dr/PdjJchmXkZmT9zs6O+cLF5+XXf4IOj/YXavEJ9CJArTh7dsgqW9TsS65fIhiSxyzm KYn0vnuXG0ggm6Hey6LfHD2T9qXveVTufTUxiJ9DfTClkc4nngPMm/hHLV4fb4i0pcHwEBrzeERZ hGl/HiZH7fupeGMNbI+dXWXV3OlzQG5Aa0vCL2hDI1qP0NwvwOuhY9cHnGq/mPBm2Inf3BSg7xUU yGSzNPh3iQhUaos7TeXpG8nYDjH+NKxsVlaa3xM70R0c3Rp7Uy/t3iaG2bR3T31AdBx0K7tMr9yc qXgL73ymKxKH2PK0XgxgvpEArh9ywbZtA9V6UUrkjwvk7ME4i1EsEJ6bYMtxU1wrYUp40vhpY4fv Q3A/2ujoxtkrOM9q6GWhJcplfF/IUd290wuq8TESQCI+jZ7w67mPW7Awa8QY0FLjDyDG9jA/f+tE VSXl8yTmMbC6m0gHTnsoWCG/gC/I9S9Or+4+0TlcYFV5/D18O+50pa4tAqXCkw+J6vY4bx/hUjmL 1I053Cjq31bdp/VTB8pqE9f1V8xognK4axwJFC6FwABWeCyOpIQQMT0avjZ4xSXtYIZcWIBjRVjo qKYd/BK65OBUESyhp4kk6I59ZhnNJC7fUQ8TVLE9GzoXrGO1PyEjVwaeOgWTaz0iwRMbsbWmL7v/ 5eA7rb15kMnvc8+z0VcpzlVAT7iWDSsrjjeSLMSwhd+J7PSOUZWXsnrnjp7J+l63PmATtrMVuVH1 2H65agXwDVMnznvPIOhYO+1C2elzld/rBl+PCTro/sLMOpKhWzLzHddBqU8giULhJ51XdIE4v20V t9Owq5kKk/RSuKMZmq9BdJEfYq58mfDSHfOYZxEzLrlgtPzFK75au313gcq7rSrYIWBqtbpYV8rE cga6qVIWYc8YFXxzIT1EaVNYOrOI7kyi+uAhijwkZYpT0Hc6t+AM5uhS0py/dq1J9qM6Pb3/cxHd OjtguGGzrRATbe9wL5ZRUrSBW7VKRxtRo3ii7oVZCykVCEYvcACNWY9T335fZuvJHTjYzGg7ZOZ/ GB+GZzK5W0BAPYVUJzaYWOSHng5EosjZqe/b0Gym/Qg1mAmuj3PZOpIA0YrAHi0W0tx0fkjAdxg2 TDjYS+lZtZJAR9Nd9rqA8+5G22TH9+avgAgMR4O+cMcmUdC2nU8JVevwSPqH22u9hiKUkwZF6GVx tk3dIGH3/eyGwux4/DxRAlC2cz5FxbIo0Av94SIzRjvw+lzt+2z8iC7z1Ar0RSA8kn2kXy6jFbTC eqnf1XMOGCCCBSl3H/zyAk3U7kx/xzuJP0L6begvMcC3KUa40oT/gkOGJBUh74WlS/yzpO08+pdF SbquuriXrb1feFS9KtAAlX9nsJR60uzCMNg65hEWnYFLXfWFtxEZrov1RNhydEYA6HffqgF+MwYF 48taInR+b9K9kp2qnuHkoQVGGch6Ank8yTNmLI7VTesEwhMImkFr1AHfvL/CpI8w4zgWv/AvAXUz Vbce2fNsCwevSQ2TWY4u8k4t3QfIQ4ZYoxoHPLhUqwxwWjLWrpIyFIkm06Xnw0cw4tUqsxjb+MOq 7YkUh0J5i89fwG5F+klDJk4+uQkoyP76EQMjauP2g+QHv1j69NEIsrNY1bJ/r6kaPy8vxqHe0Tro KXarkLk027BjBK+BU3LdCAMY5pu/Gk+ZiUfvzqY9ics32ulUUHGO64yEJ+yb+ukVZ2ebI2lYxueL JP48cbkjKdgl6Q61a5exTb6QosJ0+5Vu86NfgrXG/kzFoB24ShRqZ+xgeBhHBcgUEQfrDpfe+hHh SL3jHC55tSIR9FpZHD9xigRbI+jFMCgj3O0pxRrQk8hHODhvkDoV75WMLw951EuLc3VlayYPnInD tUx4Lj9C9D1pmB5r3Rnly03sLfuv6/wN//QRv4r1h6WgsBKeM3vurejI9ZLVDZ5QbrGE2p1n0tI+ 84UK9JmELpkrWiUmmZ7kwzxNOUCpn1aUPJdmeQwKauH5KRar9h/hrl5LuI8H52gJzT6dRjkIrvF/ arErgY1ARCy7jVZY8otkkGRBrflD6Td5D54nRPSaSBIbGHHslzlW1JWh+JbcZwSnhlYm9Ih2nUHq BlYryjoz/sP96lvy7GFss7cVpuVgS0uiQoFqIVuHv1jAQCX1NUW18FCljWcgz5j8BIr1S6Pj2WCL ki4SWrf/IczZWyJv5qNbpnmfyEEPDMIxp1rXJ5XJZOBL6RBiPM116HTEQWd7riZvvfVzQgsjUA0U bGUWTTpZPHeg4gKxwNmNHSJJJMTcOkcU7PwDLDWT8Waw1LWJkEYB/6GmS907krB5QEzYXTDTjvFx Oe0Mnrndq3BSreJRUuhJsDhOnfMHmRUWfgaoZF+wdSi7EEj4A/Si/mW1TMPKjyjBohFIm0LfOHhj MYqagylREkyOzdBlxglTjDmN0e/Nj34tZ1xXil0WTl8hSgffTroh2s1PKSgYAdcvYZ2R3LOtplQh QR3oy9inrAGzDy/HvFEUHBpsNYsnMZ+sO0bf5HgX3N+Ls8p7ZTS/BVhXjoLgh+jlEiG4M3Tx1BcV 7umjTrst3q05XVMsYpCTqJ4hjLnla1BtCWjK8ujc8nbMKXL2op20Ccj4iJ9cK7JsHYSr9aIJciGQ qU6VLDWIOde7cU8a/6b8eA/BSko0Bhp0Frz2HlHkTgXPULrUa+rdz5BNun49vwq7vFPcS4AEgt7I c7fZtEcGSCrmrr3Dbo05v35vLwiMQuINCnvJBBr/RMbyBgq/p6duD0yxkdc0e4WyGjUjP8/u3ofN WKEs/DPrmsdgc1TF/sDeMbDFAymU9kkTVyM1u9kV7+0oJWheKEUn2+374QSaVzD2b8Dcbv+F/yS/ qjUJ83R0DiO7ZlwD/Vn6A+BaWn7+7yu+dKEDtUO1hx4StTCFwuDANdvKmpDe7ctl8lnp8QoRr4+O Rup6ZmRJpOY5NSv9gyFYBCyz/Rjgohi65fazuLe1REucK+Be4AtY2JpGPGCy+KzfLhZ9W5OBvtR4 cyLntXw/tO7zFeyVp5Fn4fyl+OpkXrSA5BUScun4++l1NLcmC6dpZSWp5J4HMtnd8MoQC5abczQL fESEfw4IDh/zquuLaJv/ZhIauRPTWQnm78yGNk7BzdrbN60QPTjU1c6SJ+Pj90ENN9OnkBFOVxMB zLmJ8B5xNXPjjLtICZZKCwPmavFLBhWdMa/pLtbuj3CasaKagIqe7D6nx928lUbloToNw1Eqiavt ZgbOlwcdaB9srQsQJwGyim4l2xI8ZjYL8UOAkgBi1vT6vf5vLA4NLQTt6QguskhUgkoWDJ2zmMAn 5Fa6q3yMDMfyQywL1GMp2aGpS5uUx67+kSXsy7pfFqzjGJmLvQnm8ZdYQaXovVQAfrJh7yOLSeTL 4WhWfs6zMDrlpMue7m3bmGF07+s8iJ2teOuCOIqt5MAG+kXCSVuhdQatGcS+jWdfFjmX4l7LWBUO jb0XSfdqCaOeHhOGR/6hKVoOuBkk9qriz7pbxTxH+3kC0wwtekFbFSlMwZKMJ4ONzGk0fayp0l8u Hngdjx/dbxLJqo+Xu0Gofu18XPIP0j1SlI7QAKdLI9eDN2Q6NIGf9wl4ePGJ8MJyMoUaP6YKQ/5E xt2vho4n8PTDpcW0ZPCIm3Hu7p7NpFp9amXPqyXBPc2ZQ7RIk4lYQFzX6285nPDod98kwUikTQFQ 89Melrujk4bfVAGZW2KrX+WhDsmbLRiS0k5qz3I/eA8v9j0Vk7cFyMX+4pvQZWNdAL3wukOefdeu ieE1rT7cSd7n/BuVop99honwUXqLrglmlddbC9asR6PztTb83CLslDvEMZe66hkaZ688yLk4YHr+ WswhLHd4PEYavjICn2fVkDESUdTuwJCJaSKpLiJO5gLy3vGMG02ZYL4xPK9e8FLZK0l4czZ1DwaD CbDg44Yn5uxen9Zx6aXMJtzZ4uWuyaJEHnBvsaNzq1rivruDhimI+myPvR5R/yn9DPa8Ql5nvS20 SuKEX3oj83IVJEn0HaVwYfD65r1Mx9oO+z43zbszZS3e6ZQ8KSWF90zF8YdJMKCiAEit523ckOsj xLAyt6pf9wMwU0TQOcBFGc6JGEESx7K5wj6ROuJ7hwIPIVhEX9AXqxGEqlkrSYjO06fdkHMGnlew H5GNiRgjHey352ixEsC9NLBYE8a3XeTTwAG426lM6M/LUTllc6LHBIgyaC99uAOpcQq6CvvqXx/v QyZLckVK6N5WRd5GL0y1jtQoggYbstnxYpUQFssV+hSq1TrnQPQ7jo9edy4rUxoXbmlXrG/48xa7 qQ/ukOGdtoFcVzZwMZbyfxEVYvsRQJNAyIj/dHml/gVzp5P+szrrCiPuEiis+v5RzmPovi4jLv7b QYuU2LXvyigzZWIiy+UFl91dbyGt6xS/pxLcw80wezVF65FLve4k9GD+N1cr7Q8cfwzgiwrff9g5 1ToC5KQ0/ElNvD8Pidg5Dyhl+1W5xCJ2BzTv0znDWb79ourNZN9vmGA9ir2gB6vn9Ae7pdapFg6K 3WHjTj8T1fBwvHlarzaNC+Jps1NQspl5V0InKWwSN6Ltt6ByIHw6Al4d3+26pfvL3zQnw24TxVJO eHtaoDZdswTlO/o1xXDAY5NP8NXHqKIfA5zRK5kBTbyKWQt2dzMPyeD7Zi+BlE5qWKaJ923f8dCC OXiPTFst/Zymrktisvnoh0o2GR7zmnRrBA3z0aWzwNw5oEB+h0VGrppjNwP/C2cuFE2rXlJGGUrA 0OSJ0+QQyn+hOdtKBbFeyJ/wYm9qDX3ZFjnV5HXHJhotdgSuSorhFc5OsOxcjEoiC6tLZ0MvGuIH /VCP+fVhZw7CQUXq4KugakqVznrgGin876iwyi9uuXaDuVrWt46C3qNWqa7v4ZYv5g/xX1+vDhYS 4NEaVg9fv/T4H668qdZwAABUIEMj6uIEaefWj5zJGcF5XFtyCNrLbbXPa3tDgOJaVsrISjl1RdJU TFnBbOlO1jqh+RJsM/Fq5Bmx9rujbPcIgtO0vwYgiiGSl0pB1+Wa0oBbdFJEyNasaWNA0Soar05a Wnh7jO6FxDENo/3rNQ5FDHe7bQxfbrkH39bMO0to5kT/z0r48oO7Z3OgsdXo0MThjKHcy4Rcs4dB uIfanqrWejA3p3Tbb/dGzuwCjDfOwuKoRcQ6P81v8IMpDy4Haby/Du5PC8+nUC/WQ3PlwzMr3vrg x5a2DAYApmjm4ZxXDQNjfjOyc9ttPGMlxN6ZGJs7+SCNg+b3c0zC0papKjUbrrXNw1VcGTZwRlgs eIXjC9XPgDrDNcK4EMsgef+UBC90/OhhjgeOszV1x8vOPOx8JEG80c1ICzeMCuVeI/Gju/oixz8Y vOXfjf49cgfrupABSuyy/blXxsQBhEp9xZJjGwLMB/rfNkk9Cnx5YdYMqiu3nWTgP5XWgd/R0Dew PdCeeK8iecr8356uU3+vapMTBjZqYoBFlxUq7ZtUokfXokkRMjKzXeTINjWKnayYRYhjjhAE6jtq yqHyA8F75MemyBNZyBeN4JKX//n4G0/m6qEMoE/EBZX7R5I4gdGXAqYlqrittzhnG8BQ5CQ9x9vz igvxgv7d/W96ELea5EALRssGZytDv7Sr+lJ7Cp2Z2a6abBt/S+LekQcY+X3UILT+zIqI9dGUgYCD D752rGsZTzGAD3cPIDHd7CGBnGMtmvDAP0gih5sQqHMuP5Q7le3a6KtN3v9ViwKtw05wPlFTZiTH St2TfLkXByx99wo0CLd1m39DRj6xnw9x5DBRpZgvFpjoxpW459s7l9qJ2/wVr/XdiSkVh4Njf4YI RUAMzo70xIx4b1M7TX1uPAIdxLN9j9xHvzOZcnNzhP4qfkf1BhaZNhjkLL8VJxqIP0zhMTX5O53h q1z2VyhlfPlKQ+58UUg3p7/9MQJx2VtFRU9wiG15Yn+kqjOQ4wGjW8B7NuV48ocX3le5UQanwRfo bb47w7794PcjHj7hIPVmI6nMio4EgiCnUCFAyY3QuQlsaXxFhE5xlZKlNt2OldqjPndp3i8Da0Uz HWrPlgxb6id96OIOzy6XJwNnYXcAvfE1JhlgfnEK697eXps2Ce2nHGjVpg/oDVew9S6oL+/tHqI8 YHDynhJZV2WdLIYKCRwp7uXo4RlrC/PEP5DOHjmjOf6+H+FYIos4lyj2lp7bjZ5BMhMqyEXqow9U MFhQGFzevhLsn+87KUysZJyMo0AsZg0pim6RO41uvqiPDZxkrgPb4/wOubYuCEfs1Mc0uDUMJHs2 ogOTaxcOWhFvXeImVvj2HXmV5VUFncbadZlNajZRshhIc4oTe9fy+9258ol+T43ZQBnlV2uZkOm9 L26xgMVvOYEcuKaBeBRpuuovkCLLUpMREqJle0ajSRKNAbPxgXfqvp4A0hVaET9n5mlANr/lRnok 7xJONzNi9kKtemHzvcAZ80WQ5bmOsk0ST9laHSxKpYyo7pbfd8w57nBdOYrcdIU/wOSZ17MFrKoK 8d4Y67nVHzNQSjcSHbUr89RA6efEUYLEoOCzTdu3nkWcodcRNPbE9Ds6f2Qs6YyQTOSWXwonPXmJ cWztEKuBI2rsuVBotPXLJVyE05EEjryPzf0DYpx/vLZYYsu31tE3jj+MhJZQMybucRLCFF4zd5ag 6H3UAIV5Ry6hNBgdyWgA1qI1FTbFsFMkz1Vak0Qfu/LQfptm4TEO8apahkxrsHsRvlpTz4oFl4n9 76pq4tbDLikTSRsLS8lJhBFO7hk5el4jIJ8OwQFl6ttm8FKJ1wVirDhWmW+KLQ/4LRhf9osOIa3s RPuWcz0SdIlqYZAiy8yZhmnRsiGMXHx0nYZWMHGMElCQuFAjLewTXy19f42M0mik2wGGm9BV50TN flAaEQDHmDIdOewynZ1cr1g8gZ2my+xx2Qw/6n5EYuEuZoEw6kwoWH/AhfQHgtbpiaQgmE5Nt0X3 EtRYYZwizRpdVhK87gB/Ov8DtPVuf8PmjFZxni4Zz7/qHEiL/R3ejqMTj4o6JmMkNKf7h9jF0IDI 3u9S6fY59yqV36ylRPVOBFzjdhBIdo4sSm/XhSO2fGAi1pmXjbGGpUtetrTwg+mr8WFnDLTT4gJH taJdUgaq0Y3kvWxuoMHyg4HVHn7+xUU9Ko3DVUQNGdPkDHsejKWMQoqIE5vCKi2edO0F6P4F7g/m DPpJ2tOAFQOX9CfvCSitI2yoPi4wE4Oahp6xMEKDcoFKorECGtbZ1ahn7NgXiPZV8QcSDNSiBIoh FsmI7fzJwTuXbVoQ2HaJ2DraeNt5C3osKYutr3sdmCr5BahuPZHaFqaBUSTdH/jcM+HXY3D6aBbB UKQ0yNNNe71FEjwZhqSpCq2NoRBBYV7WnKMRJIXkkbEdV1NWbGxOmGF77jv8AJIxiflW8q/S+PTl zqkrT6f6PDNShcvusPgVK864AcFFXq/TEi7puPUZhgRg6qztFUj8ls8ot1jnhVgkzpPYnyrDoyQk oTn0ST959JuQpu3tu4uUq+/e1JPyyZK4gP0Z0odlE/D/DQlA9r8fdJB7qXjq3IB5iXfYSNkZWMIJ iilgYTBvhR8y3AcX/RpYokBWr44jHRywgc33BQODRGCylp47/kZ5gQgzeWNSHDFr9pv1U5aIZ/Xq ZEvywGo1FbcUibHB06yCKaIuFZUu7ZoR+36XnM7/WsroccAm4yrPTp9KVD35DoMpcLLLQRmL4zAM aEKf1Nyf78lR54GfjCjpEFyieMyof1YNyb+Kj5IjX3OIDXeLqPlfsgL01yYKsShXGnaxrYGrqv03 h2aUPd4n34kCUYdUC5bZMVn9wzCAbZRHx/iN+A+Vx1SAkO0l78GoFEhg5WrvaqjAaXjJ/4n9BL/f 0AzHrapBe+wiLcqX9iB9fENp6xa8G46UJrg/marWI83Fw/sZ7SCMVVF9X/4beRv6edC2aDTxvtLi 6HeSqiBEHcpDCe45FpD1QM4g7YHRgU0nxriuNfAvJKGU+UvllqCy1VEq/Chv77k5M0Q+/jrsKcC+ NEMHneuYwV9J+pKaliwcKMzJoSQ3NZN8rTnFArvDBgVgKzM8sCE5+0LdclCqXpq88GDh72fAqWtJ ZQyQGltOuvGcguJ/BrqPx7GT7kJBHoYRNiV39QzFcUGVCLujLM1PtjO/dOA1oIGzrcxdTKKlSfiU U0dkJu4c5j/zWwaZnSnroXU3bjvQ84GYaBA3oMH9TIPC2UCX6pnA6H56q0adZ7eTcB2zeSDgLWmG HsunTtuxHUKPg8Wv0vj/n/prV18MITL/L0zFAeTPii8Cgzdn6zq1dn+v0yrBcytdnZctv8S7qMhz sU4QVHOB76Mokry8el/zCDn87ovp7CBuVViETq3++JtjR71L49k6DxNg/VwCxPQkop8ohmN9FTgw PvNTgKEleAr0LdX3Qs002cGVB1Ec+K5lq+ub9/pwCk6DiLqUUJ513bKi+XO1Fv89qGvddg/L3Dzk HE5t4KGgkI/N/JQSRMSWEkqUnsHX8Zbkuqu8Pd6pUhXGfanw6RIn3xijSy7ptH6qqINZ7ChcTP11 TiKtpgd3y5BoPMYIuDsdFpVTHq/yuF4Tgb9MlKnhnG5EVP31sEyu/PTXFuJUw3YYwC3oURBqcfLp GhZB+NOfWyFwxwdwcBNXpAh4cjgnVeA4PitX8BENH+cWbuv5wiDwX+xJ8pFLUIVIYK7mq4Lqrf24 OtZZ4wWchiw02sJVwP5tTw0Moa+tdky9Aqi2L6kb46rW1MX/YJavEdARmrjHZINx/tJcBjhK/BSj mFPZHvlpf1dSeWVYQJl7NtZYBj7T7CS0uUs1GZoFOhpve62AUx1aj05pr8BU6HvB/gaBrXOLKXGT kA9X1H4ghVSw0mhAnUNMh6JLDGWXtMc5mGcMwphBjoJpTd0loKCR7rzl8d0Ihnhjeyp5QWE3FOzn 10Dxz46nxnkO4A14RgAh9Ws3XtCWj6Az78MvszF8Xci9yOUAC+Ag4+bMNdMgiXC4vOIow3kHO5sq 8V7R5bs4XLdmuNDRdEa6HptHHcnTMgJWpgYyGTb92TIvUMNnLVqFnp+h/oHpGRWZAth5brug/qFx LNofZUPDb5unTS78QTxcLHuVyMzCH1w44fcEJG9XRssB7NYOnyWx4YZMiZFruxRQ97RGkc0GUJtE +7lQ81trj/Y3R1b+zy/K7dH4dQJk1Bum8D6LMuprK80XeOlpFSFcVTiv9p04cFvg0pbppwz0P/xN 4xzO40ZXrVKVzfj9e9kH57By+a9bnF5Xkm7wR04E5fhqmNwVyOH+Vq7JF4l2/PrGmeD/DtqJw7ma e2OjcZhgLk9/rkbwvHlvJuJhWtr2XAL3MFB01tG96hWQq0yVTdKjPWv9W8lo1e5AAnTyPRc7fGyx vvuv5R6xbMRUVVPmwUpdPsFB9hbFJTxVxPrjC5gF73tL6GwsLYkDpSiv0FcimWdKl9sjMfwWnP// 9TUazt8+avyIR3LcO6vq+DSobTB5BbNVwSp6QYLAwzLXmQuKuIKFKSaFuLaBdDufGvnHuLrb0/QY pwRoexI85Jt96WdXeXlInQggp+JGbCH99n7l0cOT2GclISKPQh4Nh/m3R7OOSV8XSI9lGqfqbyce dY9LevRBzFEoE1pbrd5ZkUcm9RPd/H1Ma9FSN9/hyrLbeVmtOIH+yxTrpqdt67u+QV9a3VetqmZx rVJFPtD4Hdx7PCNqr6BbmHO33J+D4diL4+fhX2uP1cDp/a1xbdSRHM56LbOBxRIPikx657nuyUXo o3Y3OajFFzEo2bTEmaR8mDef1hR2YfRBvRXKvPZSRhhHG4yuStHs7u1LPHZt0Y1ssCnqcdFgWREi SACwt5jDXDu4P/yZXqsAPohAw/yKB825/oM78I6A6wwciGAl0o4pgfI+QIch5WQmBfN5QUQYeFy3 WyiiOt52/ZLgo35mIUZUZGj64AqUBOqTD52LpCjtb9dbPrC3zjgvQR96PQjX4gHwHGdHhcohnDaB pr3SKvLzWmMstRWzmOBB85yyfbJ9oj6K90mXIJg7VUKDomfAWBLzoB2FmFqGeGEAolr+NphiwvDg ZkOP9S08XwhaNxMGEpdJz0YsyT3Ykwx6HBvuzytZRoNnuBzryXikpeZtnoDjv8WvLUl2lJmFztB/ rrkIHZ3PkjiBYzAJIEY05PRUCgQvTbkXyB5XKHT8MB7LyU1EAN+qQ9MGAaSegOaWGKbhbCxQnaoX Frc1RVSEfAASqRKXLux704YyBUc3d/qyLTzraN46jvX589aenRAfjaBD6d1otmDtZMsrz4/6eD3x 2wLJxkEVmvbXKY2LiC7qASE4He5+m4EVJSx/MZfceEFSGk3VTC2zoN87sj/xfKaZs/Z5xb+DW/Zu gUQbmjCdQfAAhd60MM30YDfPfCraXhSRG8/3U3cqMCdgEtpqDI7DXFzS4rfGdZoWvv0TtUPL8IRY 6LK/Q7r/KKuU5pxJ5y3Cjwah6ooJnWaCqG6zpPotXyrwxC0whp1TXRWMyo6vtJj7XT2AnNIyH+B1 60jS+F73fO9fDGcCtEzs5VrS962TdaZWhPJjvR42pJcQVPCw99ntdHpzSFW7LG7h8fhka0RlnNPa xUkTbF2qorWnGcWak4FNeXMUWz8vyVDuhZ7J4DkaR/hJ1MUME731DBEjZLJIXk+AIVOEjChGMUgg SyVi0VHmcZsiw1rHRjFF139twPRXle3Ii8pKBOQydT4KGEDA9cHSw+I06VW3GgnsomhUPpkk0LZv IxswFFy+4kUaQDy+tM4++YAjlxNXTSjzIe/yF+iaU8eea1mktN5OkQgFlaiIO5bGLjoBTcIjJJE/ ILLopXCnAMLJOhXX7aOllcwszTnKbv5ikPdVO7oB0Z3cI5AF3t64+ukXe9CIng5HuYTfbjb8oWlj N8psHV0IkQs82ZZDF5AP6YtnXn5xJWqg9/faupiYfnk1DQTurEbBt3crOK9F3q2+pYp66zlk8wuG IMPg22EXeTV7mWJUk0l5htAB6+9HQF/Thcn6xt98ftxDc2oqup5rKf6qo6vQOXLnd1z2kVgSsToL dCDviTed0cOL8PJmQ6x53BUWCq0Bp5QY6BbpgLaQ/DbGGXzSXFqPe9Mvdhgl0RIkb1+Pcydm11UD ctPJjA3/G/cog56wHzvKu6a9X0ujjhTsJ0o9LPHZ7sUgmTPJhElPsAkRKUePPKBf6qVkH1RKM5N1 1GQXdDhU3Dwwjugs50f/fr0/NZH0EqdAFSnkkP/dwLfaa/a00uV+MKaJN4K4hPkbcYteAtw37DbS pd72O4H9vkLhMJYPh+5kt+XOzNASj35Xb4rAQAOa/ubtn8rcrByZ2Qa1B/xYs0TH/SnbC7pndNvc f/aOOuHCEiQsZClriCOAWSN2LgG9byZnF20xLq0P2tc0YAZ3jy0H6ohY+hmKom0ESQvexW1ETQ2x P+XXTs08+SUWkgu3COdRYYWpLgJLovXJnd5L4kucr6/L+LfNzxXwDCeg3oB/IvHSybQuhuCWqtZv ynXM09ICKor8lfalmJWfI9xmKhAHhvFaiF9393j9dfps6NZLMJs81acoHvlSgF8I3V5qhCJTzI8z 6snN+/klV+6GDk8PF8JvAmtZubhVmqdOCLgvYukVH0AHDanxG9OHRngKpT3vcviaBYmyIUDXj+9W 3Drq0a9jfj+nhJn6xHsNyyncTSmr+QCZDh3eYmLQwhDUc+QXdaGqG8OEMxof/BgqMvWGsHiBM+zy 613s3t+bRJYScOMEUv1/5RP8K3ZOKy9RGlbBcdsiGrmnHCOfogjD7Hw3TWwKFRQxPsWeaS9v1bIM /2hEqiSYYFi7ximQSBiWpHOAnfUeVq3gF4iiB5vDRKpeUHfnzxuXeb6Sg4+XEafGM9QsEyo6odzE Z1fh+FXgh+14E0GDrELybJhK10WMAos++wa+XpxjlGWP29KDVoTHTEkWGd8rU6u7NyRcDxdiXC6I 8ptu0WmTv6WsfvxNe0I4ZSaxw1ItbXQ+aV6YNda0wsvJfOTEdvRJSPuYx4Wld7JKbceC+SrAgIo4 BZ6N4/7vG3s0xMpnsOUT4UDU+ocuPXemTnVFoieNMUMEKstlQabtM99GIaWTLVexbOyzjtIyo9rE 831j30XUbJxjB8qia0I+Nujz8jUeQ7zlyW0mmjb3WjJjzAXob/nMWsNzKxeS5wCooGR4/Il5wb7e HT/pZp91aXEjg0KEp9+urt9lTkPkFm/jBEFcvhY4/mTBe9Tw4QFg/hXDV8WgY13cDF7cOW8o02fS 0Ga7gDqazDwgJtqggFvzp6uBrUp7Tv5yaP/IZAAk1fhV+AQHvT6V/s3YCzpcw5ssjOxFFBzRi8I/ jfzSsgbdTwWDD3oCcSujXhXbrroSi5BKrdrq0E/ztZniDyQT6z/h7rUvSPx3iCjwAi8QVcpergoZ dqc/BKR0M1xaVwS2miTJTdPILqp1QLSXWeXxgBxUDNOx9cjGojGWInJ0qdyLnMNDa+T9kS/wLPZN /X0NHi2EFR46dHJ3U+rgsDYEQfIX26+/5NoNoi5Zfw+GWpFlw1GyfbFwOGYhTitpGiDYK5URaxX9 0na3q2gQjoz94x3Rq4jsbmQDs2lL2ixhn6U40KHBmXeV6zVnav6z+toImTlbqhjVSFv/QCB7k7/3 6GvdeNHJyvZFNvc93B484gfDwHT16Krbrg0H1SzAbMIaNtJjttKvwHxhOhACqQDZsbAIE/Y48MS2 69wOe+xJDFyRflQojxzGt+ID7bQwM2Z9sZvvx1JH2aadrle3nqllSjtDOfTSEsc2PjwF31Tkt+Pr KD6O1HyDl4OKonXJz9oHbXRpeqSrPeRwKi9rm1WzNqcj+V1joarRQ4lqHyToEOs6F3e8z7E+gWlU XPkZazpFcBkhK3ioNOCgo64YESL0VuQbFyjbtlE45K96rWY1Gjc8k24mKb6fMHNAQU81xVTEMuGg 6+AkhvYCYrNEXETa9qbIzF/9lRJEPbuTz/eAJsTjYUVaey48NX3Bobw5ZYfbElowjUmYqLOVDfIb RjAr1nMImflvot7UVpuGckqzXOf/uc3IoeHYrbLIKKpDG8gsRxQlkkxvonjEb07OiIKORxjgK9K/ x8SM6mzvIQjE5Y0wbv7M90kdDT4081vtmgmHZT3rf1Vbs4AbV0Xr2SjHoBUs6jF36e7zlG3OEsh3 52XHh6Yynx0b8sAbwhK9LtwZJ8RErozYzFiXpRVSXdzCFf2B8kanf55RIjX5fKnP3tRMqtRR2v84 68gKMyiCUN5Fj3uddBSILlJH8HJzrRVsfCFex2BqwSin1ZNeWkZGQFxn0CEadUu55ctpD1YyZYpI 0gZCqcrTWndgohUQoPJjfjYOvjphMlRwSbalNbd/lAac8vh5FtNCp87a0+UgmeBEazzG9PN+e03d b+BerPpmwqG0KA7A7HN08R4l/6orby1n8TYncmsx+z1heuogua1XAOXS+DPmmHru5OR7FKXIcDbm +0qHtEAvF+X3+R3MnBIzYYjPTvKXux9KzKmxv6a4SrZ3WI23sy9ycnQ2yf5fSfj7H8yEyHMHh0jM xhq+JEI7FEky2/qUdMgS8A4hJGku/4Rpf5mNqZqCRTsaGvezd+qWfdhhhZWH0G6sqiIjzz7RVJx3 l8rlF3NHVbfvXBMacDMzT0dLNZKsoSyLOfLrlvnpk1pOqPIzxtEyUHC5wvlQOj549smi4JwP0vyw uofmPzfB0wMO52hYawnVJnB2vdP9L08Y9Lhbr+Ckkpr50i7ar/34S0XU8Q62mCLXpTx2ELHLzuoD 7lSanfdbrvn239wK5eacaSxoleJz/9fZyM5jqt5LHZIaCGuUM1Nx5aiH5+ALe0qcDwX8sTatvOqI 9sPEatGMcSwlRq1rmClVA2LIsbrwH4T4UtB1iO+X6L4vxAT4sFl5wpjDutzGrB0cC2cbY8iN7ujC AmiQSP5quDTy7BsDY5HhR5oqH/mPd+7cpD+PmDPEN88FSQtL8F2BdhNy4qbswpo5W+7ApjVUsGjU OwOoSbGix5qieJDd9KGeKbG9ml7A78piqPjAQwNVr/l0wOp9hHSIW4jOCbGHUQpgFHW9ePL1/O5a GxRXmV2qwjYFXJppbqAXzEGTuh7/qXSq3Z65Zker3zc3vyaW4+Rmh+R8PRPKYLouRWjngSYsyfIb jzDVUd1LiNuwRNJi09L5vQq7m20tiMWpnQGoH4RjylHDUoSuwP4jm7aeJGaBV3ednDuYLveYQ1Tk DHhT1smcRunY4zzJoBcSdLy5FM3zmv6pdlNiFMT+tfm3GePgZvckJlKwx3WGEexU2YqaR9BIviMA N5MMp8C51avf16KzV9lGd8P7mp/pVifvVKP/o/UvZun++Bqw1g5z9zyNG4XRukasuf+2bYm804Tj LoyibD55M28h5zUAJ69j++p4GlSgL1Aj5zrywjEtry8ql4FS7fstpdfxNPcyXB8wY29aJY5WHyil tHCUtYsBD1dmFSSjRQHeDLG85P+2Zfagvu991M5PXujqPISouh3VnJmE6kijpCm7TshsEQLJ/DMo M5I4Ph/X4XjAO59TMgdDySPGqjWrJ7PesW2cpuxyoQx5tUY24gzHQgVXDVfPQ/PnWFX8V0cfiwJr GTSymL/JhhXyjfhmwawt5zKfOy2/tlRQgH/IKx3qhQ6atLu5QdNopG444/WTvdv2vfyCEkuFNalU G55LSWwtcMHdokX13ZFLD49N11zmI8yy4m0Zohcl4GrrnotIJT2Q6DXp8nb8rgvbV2YBKIQLBbQJ JJyDcS2YZOIogi2/XoF3VIL+uRYs6AfUU0LpbcqefhwtVJRR2q6TsEp/DCeMf8ZJSvH5bkDFB7K1 KT76v85MeoE+IdKsyaIPcqB4hb7SNxu0Hj8NyoHMx8vklaIh2ee98w9h/kMGZDNLOxVqKFFcVP8f xrd6eU8ssosFF41LV4niGQs6Tfu7E1zRKqTqKst34llUab5lASQhV0XVDYN7GVoCw/nel5pir43L qaStIC0mbPIGu1aVSJkT2vG9EmhdJQytFwQHezJkgNn7ZhdpKsrEA4iV+DN+CehTe279MAAsQCwB ctBFWzZAJ/SnhyaQDdSeXdqLC2653sljV1V8Fgw46cpUsV3ziWoFg3oQj+O3WNAaqdhkj4yj6+7i 9zspcMEluJW0muasYt703wnKhb4QChJJRhmGw5y9dsnmivlDd4YN41+SjGu7m0XvpvgVCGuvco3H 7RtT0x8OVxyzwVyHDS6J8r8bIEMk+3nwt48Mz5hrljbh7YE9a4HLkkRZop/xc4dbAVWNzPIw0cZS nAqK9KbYaoSwTWEjuhu/AeKqJo0PXlkROatMboBdTzdo9tjZshSVgerVnWIvi/y6t2FzpjPT1C5+ a9GK9vqDu617aGW8LCQSJNvofs3vFoLnB6ZbCCXg3t7AIfuzJdvtJ+oJnwGJW6ipVpcnNPXmNuQh nhtFzAeWQEMXs+49mWdYvNgp5Bh7Ub6wZ1RfzQVqgVW/yiPYx/Rj2QrcPBxNRIMItYnRzDxgp03g gMaciqoQnwptyxikNX1ED5Dyuj9ySYPhDXkq1S1Udrfbgu6dZQx0XbXtw92vpwWCWIaqze/ihV3C URNM5UObFJ6dUgmLWs6JtJ1xggQIcgp+VCC/SkdJI1ckyQ9YRBYrfsdpSwKtr9GSPnbVA9r5Jdt1 2wXruX39K05cuxTUUSF1WUzxsYQnN2un1bPKYalH32rNVS4hIDJnt1dIQrYTGYlnl6tsqi2i810H e98kRAYBSs8weHQztTZmlWYe8O767hkTsROvOlzSfoDlb3SdUSEUS/mtwvEOirV8SzDJl0CZaWo7 T6eQHfLYkgOWjeRHfds+MMXrnZayOuj7z2ZHtVm/wgkCP8wCQKq7YjhhCIhzBrcNn6upwa83z5mO G9UvapvvuSWmYS+XzaurSY5gn7Zt0ae1E093I3V/8tIK8rvVKvXNLKDgmrD2NKPjYpPhNbBjSXZQ c+bhLFWJ7BZYdVhy2sCZDHkxRhBSmd1Ir28ez0RpEesap+VLW3FwWmCm7fww85nqlzapZXTjfRcb IVJFiDwP42FO9wl1mhTqBIgHiMxHKbdlKkNb/o2VqKBn0GrNvPoyusLLGZ7yKnf6C8N9XjUzn1iU bLOlryfa8Q/dWKnY4o5fixUyjQAxL5+mcoGurm90jl5mVTd5892jUTs3jiqZWT1fZXD5w6f2Fc5p Y76P8P+ha5efx9NfA1hKanhxWmPXX0iomWbGcY+3L3bNq0RAQlHd0CCi9tVvrr3Y/I9W7676HsxN qtX/PeACkCS70cV5SBUBv8BffL1VHI5PHBRur6plQM2L6DkxhftsgJhZGnH/Yxv9IqOmhAOlzoYp OXMbhvnCRFSW9q538qFBnMQDKzJa8lKeJX7wrGXMIeFU9bzRyiH4xj+xT0JV+LWsr06JFIozF+Aj Cp9iQAl+Kl7r5EziYFkxCzUEATTQmFH5nkBBwIhtvPGvEIDLWOMCg9u/OrYYCUH2vDnK91RKgaR7 j6DTodezAXlR/IXyWHd5d+yAV30s6W3NT/S5Ist3ea1KBT52um5rzc+Kv/OhzJcEMaVCQcxfQSbO kt0Tfn+hZc0ER5dx0zEnd564hI6pwIZKnrhG2GKebI/x7jWyxuVn9jCkeAOv9jQSbJgXGBvM6HdJ RUpNhgbU1C07WjQcV1L8eWtPW1+LRswgxrxEwzC4Enfg3ZSjhU2p3UW68k8lfIoPYF7ah4A4+7Ha DlZJLlYn3jITPFDVtmkSLkZen5HvS+Oc4Bwo2WDCdHRLCUeyIZKMmoFpqoCpbz7xJSLhl2ZB1lIA Paf/8be3eKhRqQDx1o1Wlxf32DVM3BJPFVVOPvJCL8J7g4IzY1rOkpVLSPcWpAuMM0PuvivAmRE7 Jv4E4agrlK1XVjzXwtNf2jmGos9qSgBIw5UHYPCHnQ9gnHpYQ1tWF6zjIEws++k+dpI7ToXAZny4 /SGPCMr65DC6Y1RAk3Bt2V24f/izH8BA7o+6EhxOKcfLNU1RZ9sDFlklOGtnd5uA7QavIKss0/o2 dEOTK9rUd1Z1fluAkkYE+M6MK/QCnnsEN+QmYK6aJg6HegUjsjn8ji4WdoM2i6zO4q/c4BeT0q6j tJcfWgtAQL+aK24Ti5lscTjxq666/LMZN0bCa3KmhIUk+VkBGFEFyulB9mx5BnDMvY7+U0EdhB7r pEl6xtmuoGjQEnGaD8bg9QOPjUUQi4ZFX9YxpFPiJqYvc7cbvRtvRibcArIvHro7role2B0ziURR bPrgFdJ7bGAwQPNxIyMWX+o7fz3Nq55SlRR1TunINSA/QM8annZ3+zKFkDoXG6ENCVrE6e2XHzCr rAv1P9peawnPUnY4qMdtV4VJnMQ6x9Swy2iUNkbuX8p+FCqZ4NtN+sND14D0PQQZbt4QJ00zhTsD Wt/N9Twmux/WyjUhZovB7Ofw/9cHkCVPsh5zMuBMDvfPrwEm1gkcHqPWHS4WmGfifyaFQzQx8usi uwcIiZviaA4xInPylEFp6kHx2W0ZoY8+nx0PmFy4EgVnnm1GdGPP0CZ0AMC0KY0CjF+fop1kOYN2 FTYYUhcZ/TJaz3SGsYHW6AsBKx7C7qNiMJbF4GfUpnwCQnrYvaU98eMb4V+Yv95qsX3AEGpIR/tB IoqlN7/Bw3QzqEPQGczGcJgqlmMGbQPUx4Zoqamhl/f2fT7+VWLy019/ByU0om0UbfPYaO7ijuaq 3uBKzvDVs4EPzijuICWT8Xdc4cSXsWr0kqVQt+j8lfuIy4z5sgtgQ4vRPJ3w9sdBwafV0PyY+mK8 KXm+Vh81Y/ucG2Ri9gmE0Hqul2Yv7Tncp6cZuSRv30eXfSNZBm3UkXip4L4imbesNhHzyTRJahD+ 0MOAXLNSCp7gh6TpXUGFtDizp2slLF5Ewx1RmXk2ejWBPUOrCdbfEbRyafEM/7RRqISrlBQEaCdy Noi+VPPgXHrL8LDDbXMLOjDQgVomoGTdZiW8DCqF51jQRU8rHcxWPUbui8pqoHLTPJHcC/SUAbnJ lrCr8s3UfHFZmb2vqQgTESeR4If5nw+TGSVYnEfaepTPk674kSzRAGhrN16WDXMpwJmwZhZHHaam NKdVXJT/HyqqMflvmBStRR/segFj8n62xEbQRHLYotqTL97p+v75Ivqdej+avKRhVkL5SBzqHMSo R8HiUZAsQhNEQGzbpiEhwJQimENewiIR6Y4oRUj2S5e3+mcfgqUkeUHU4HwRQFDCdl/Ena4tyxPy aO7CmWym6yp+pDe3F9y5fjQ+eJ9gC/G5cTDP10dpeUj5IRm2aMdcMDm2/eHUI4ZqLFHmzL9vDucN cNFdshaASmhvM97XT8f7+AwAWUnpyvvCNrIEYbSjiG+sQb0prYzAovGzgECxp9lzJb+1QS6C1n+C lZXDl2EsTGy4NJ82eSLpxuFd8Cjj/apszhxvK/W90T7XZQfqTpo/atGVwQyQBjwbqJDLYdHfPQ3z SDIcz1Bhx1ROoQuKWmdBJYyINzusKnLrkkhfWT5oQrvLxUpmm+ztF5fvv3XBGk2z/MdukJbHWWbj zNfZqO1eNnLUpqYEae+zx7Tw1nCpXdKGvkBq+267qzKcXv+0W+Ld3AV2lYBuSPLZb3y7Mz24xOF7 rnL2DKuioibiV5eh6KmL4mGEbdWunU37rLL008N16nr/c+dXCyJjWJXG10iAdQb7T2I+lZ8BLqas IyvWeyo22qceJ5UrzDyxD/3HRH7JNaMlE4BRShSmpq4HZZhuRIkjlsw/YpDWldpEWhN3pTD3OUGd X0qDR7FZUQbIvugDPrrO3UcEvjy/03ZU/lRhM4oHmthLOxQPR1ewmI5TSDaHlA5NGzfgeAAysd9N Pqi4VZG7iD57fEhqAdFhciZ/NuyFpCgJm+I0X48qjKdnQa6Uv3VWN0GdI+4anODB/2XFDR3zWWcf y1HUB/1bI7mnezdgmdGqPDh1NDVfBjvgMkQ3YkOdLXMRYjfl+dSr/ViBN9nSbAeyTQucoj4K7D58 SNrJpMfO5i61HTQ1FmaaWJSbtPmO4qKzDA/E5mzHD3HiO7Znf76oPbRrG0f6nSklZR+wHTAGHgds Dj9nSwbUA7pRLFQljpsEdxvNXJa1fpfCntGrx5ifz0h1fxuo90dJ5Q+QEmPJefYN+V/vQhI5Gii3 tFlE2uSCUumgBRnubh6JlP9FNGJk4DGXgP67QCaSw5c+lTR0XcV0MW95qtr5YRdUWcg9dsOHu1QP SvtvZN4tJEe+QkbpjgcJ7ywltuSqlQWYWEiiooFeF1C2l45yEET9NIotjK8Hiw6//FeClZGS61MK CmSbmkF9gQaeiT/z5zDf0aKjo74u3EqzdLXv2w45rjEGCLihY1oanzupeduWRmuMxPkx9i1I7uyO hhvqhWvIzyiCzQZGt4jdEmWfp+wFmz0bXl6y9KUiyhnyNi/nZTDD7VLgZ0RrW9oULTpTwya374L3 VfRmNitZfx+A+RB6jAb9r9QKAwPcsdkMb5xIkk1WS78p0/SxU5u3r6iBu9L4S51rl7E5N5xE3Xhl yUnub/N1OokUv9Piz4HTn7WtdqgJlB4POkdqGwkHutzYIZb+rrgGYz4xDYDB1gvfEdtksfKciwbv el3ji+sQ6fvyMOVSXRPHIb/5tAfMINQgz/LRijJ7AqlCqW+RMXeNTpkPAzeLWpxPiNy9aOzCqr9r xq31erHzjPC1ZvQIi3f8SNfzVEUCUz9/ZaLt53BlStE3lkcA0K1K2eDWHUGokqG7oH5NUW8HbbWA Dxst93Cr9IRm24Rd4fMzqiePMmElQvad3/AzHDuUcP/8aq6MVuAkVmT/kkX820FGoEFDvAjokGtH shoOrVPZ6FlFPrT45oQPI4WnYod2J+ERJ8QFKVP9p4jojeZq8Zim1QrVyDBZRpf3gdKQn8+rK5qz D/N8LMZbudI6ksF3NC4BgqLmlcYtisfeKpfFvvXLozrx2XAxRIXRjBqq8bJAlu1o36/SSXoOom/3 4+2W/q55WV1VBTJOHCkucakg3qVPbgbF6fXGTjwl07Du8LAC8bTlBPF0EL/EJ48OgE4dn0ijv0c2 CcS2cOAMRtnaDoqCt6xlhAM1ENsaYsHMN+0haHGkAqYIpeSWBOOTuAy2UEAltL/WV6tLNuWfIYWc +kSoLoToFiqJHdgZrlb5QGDAZ1oC3TzeO9M5ShNFU9LJ9k3C6jbCabEl9BuEnquDVOpw03seTHFf ukW3aTa8l851e32SxReunvgoeanRzXxXmcrDWeQx1YTYav5kzWhg260pvYUPtywYcsldNdSXcfrh ush87iK2tQUQMT4SHYXoiklWrHviJKCujTYElsbcB2kiyFZt+4cp8eqIJ2SeSUO9dwgI70kC+Ch/ FlsM+7xUNePCW40raVKbkdPGXDIWhU3/q7qSf1Hl+z2hjbNSsKe99e7CL9it1DeYDtXq/nkal3av LveK8127G0AHz8Q+A08EsD5mo8xcn/9jkAQEiHl2vdnUVAys6TDX84aQCr/k7CUkHo1xBGL3oNIZ Rn6Haj/4U7Wi5y9xWNNDafpIX73ZfaKcHl6FqSdGyVtENfp2ny5BPe5FW1JTQXsLhUAZVl2J9vQZ n7gD5Ed8rn/rv/ncVxsr6o5LpKqn9DndDk+wffK66gPAw9+Ci6PzSrWr/Cr+1n0ZWD9aap5kShGn sDycz69G5QNwFy9Y+Ei64csHTcA+ZpXufib0NPel5MFOU+9utlkR+gmK5N21i3JH1syEPVJ4QHVk VEfw2mgWVXoUdPIIMV71ekN9liN7hgMQHLy4yzPePE9hpQNrxSNTZ47ZzGOaybpOnesIRGZ4kpRm lppoSJyU+YafkONKG/qUtt2NNdOB62Afrsg6Zf0ZNdvJumMueYXOax+81IK9B0ApTgvWd1opEAay HdMIj5vn3Nbn/ifw0GD8cLFS2w36bl5jAOYEvIkd/zIzgZCM3jqgf7B0AXLw8BLHzdhQV8c8kwtT Pb8c9oTLykY5p/90E3QfZ/My/34wDSCt0n8SxnvoGvCUb9qSmR5bMu+iUbuYQzPYSFlzwCqir0OI lpul/YE0ZfLc/HZ2gUaSZOIbP0fjHsi8ZmxQzBBLu3AXCccxhs7Oy/BYguXs/Bh3iJadVTNLpwMF Z/C17XvWwjFRDmtjPUmG14RpzWDXeqip/eb6vsXemfMwZnCQcAy2yLbh/El3cWeDqX5mqM3T2qte /VtGAL8Q1LwgfyE6aQBsKtdkifYAmrIGAuqmYlo6Vr4lyM2F94xQ2lANeziKG/87wU9Un22RAhzl 88aoEYHlxcRHKnDAZOJIKS9rxCQ6rWU1bHQGZWsEWcth2bhUAA4sITsz9aHvZGwn1B5thrIJiL4O oEsMPn1UdAc4SaJBHv+3D+y8XfHriHINnzKaKgkO2Ok7zNmm2KQZYuN7nqv8ufmqJ9c1DBWkKQFi hulXjycxfqJNWXxAwizxlj3zzakRd3v4rMqj+do4cy6QHhpFfJvk/lqiIFSsf1/0KNfGHZUpxcGq ErFO560vpQqfAI9lTI028+lDsB1lvr8/AzE9FuY74P3NdXzmcZDrfGd65mCXw/blPvZx04cI3F2E y/jkOZybSHKJ93O0SMkqGRgoa7L8Tan5MrJh2y8EIHi7bPP6mfDLwfKrZweZn2HWaptaRj8jVHzY 2XT/5wa2+uxXbaIdUglyxa1WYy2nBwCgjNS/s6pHTvixIGwdj1d9ocRyY+/bL3QDrHBiHXAVis6M AdKnWRj352HH30m46JeKBjJ2mhqmhnsHnv1O6xYqcuQzh60Vy42fnlYiOp3x9fwqvOcDI1fZNQJt yhV0iTwE+dgfy9VtVa8TMwGhHWDpF/PRmgl42JzZGlCGnkTHpi7D0CJbc8siWZqe6r3ci3QCJ7BN 4qEfdJaf+zUzAx4IQHSj/FXCEBH+FQJrFGQCcaUdwCAHiTAAgmOjvpc4gDStBiifz0hTzBU4XSrB sXjhVAtttpn78l01VihiD4va7pSA4+Jl9GfKHwaFeBwWIkYzp2lXBCTI5fyeOJLu0NUh50m2dXKE vLr3O2KQeqOtpPHISXkl9NjrWbVgv/QN5yRnmWU0AX7jPESlp7uCWxRWujA1UBv2AMF6lBIxoCFv cnQW/nmIwVF5nS1oTouqVKTfkPMraSYTopByfwxr/NwrkjYijMGzBj9M17Wb+QgOIWzvJ/ENb1b8 du90hrg4349BB6cbuB81bmUoHTJnTkXpITUL1PfpewH4tHZJJ5+PjO61r5F7LLfqLKFLk6B427Ce Xm1mTEiX+wCXphhe6GcjVq6VHvXDImIruv19GL8wjqKbTNQEGYe1P91nmx6I8SMGpcDlUXeCkSXY 6ehxB+Ivy3ECbbk6UUQ/Is2S5efNPsIF2YV5F5Et0J/6HKrTB9g84EhT9Zom6/HLRFCJqpPPlxoI iUF9A16XsONHW4oJbD0kF7ojS+WQ02y4YHQlTzNh3r+X4AH6wr9sXBSAIyGgrXU3xAM9pYy55Fpy 78bW1QJjOeG2Prt7hmsy8v3OZUapwhHYHM9ZxHeSDK7QkN19xjKXyOMCu2BiRt/QS6qn5RfSVLPK kBdqYy+9wzHRkoO5fNRLil3GaM66bDyNCsnlPQR/eLEVWYt5cL6be3kHk/Vr4spuW3AFBHhQ1rVO AN0Z48R58Dh4+dqy1HFZoMVgD7HFRY0GGomRRVfTK9GrGr1BjXTm3Pvoxvmf5lDAgn324i1XNNgY RNJyIhBXGx4B43W/xAPhzBtii3d5YtD1V7Cl0rQNzr8XpPBXL5uOIzOMJAYVWcImvhCXjW+bZymw OukpxBfNDORUJpKjFE+WdRK3cLzu26yIf+V6eAj/ow0o9A9PgrTIZOHMPkJqYwMMtqFO2B/94gJ/ OBqPPHanml9BiLokJzTVzO1uK+SBs0bYAEyVefuSQ7uwkp1BzjC2vSX/LDY1SQukc/K++J4L5emT Zxq06/TSiQxjTnqKWCaTE0tnApQs3K5T70sAHzStf7j+BwPYIua2FJqZ/2572nY8xlVWR8CH71Y/ y5CF8MAc1uvdjagjrDRHBnjqwUCsuvS2xi3ZfvwohgnMkzlptukI3yfvQhfkD+Vv8UU+WS12hBKE OfIfljl9WujuIhhN4nVgkGxaWc+VyWQCWqkc/mYHuuPMEXJt6zjAGLlBQeSaqlzjv9uFiJfUzyht BPIWQAYfWNAXjjFmBm8rT30p01rhfxELnUZtrQhwxpkxW2jevmqEGPGLlO474jew46UU+2qApXf6 7yFlaTZSDR9cQ627pZkSm3DZhEzDPdu0cUNbvWaykceIuQkYw1JGRZbcokPY76OGjJBPwgJPvAXv OIPY71FvmWAb64eeFG7VkNaXaWk09ldxGLG8jw9lwZSOEcR5GQjjqJFxajPzq6Ballq66t5D73Jw +iPRK07sx3T2HvK1iE7lLCzf4UaRkRyuusNZYaY6LGSZqS7EdWBerFFxucbGb1ri+QV1J+fQVaHu s6i5Ti3xMKPUVuBYakzAkqCmZVs+YHNAAk7oA14jOHrgiD8/DJzVWLyYaLBYHPvQUDf+xZYL4Z0u Om6yYBOKn0aE6PRThxU0XgZuPmjdBhX/y586zGy8DZhnuLbAXXTdgKBmuX3ux8P7YQZW8wlXWVpK 5kz32L8az4VizWsFQY2u+itttqieIomOKAH2daiqqzWd8bY6luVwmtOk6nxBS2f+Ylq5xON9GL+x 9DMIZPm3J/LpSKGDdq6xR8iEY8xRL2twKKwki1J29WB4oRKVGqGdV+aYJyzhcatmQo+XJPX/CxWe RkFzbDKwxdawgvBAIeQlCSDC5a1gGSapUSU8GMxm4ogP9+SH7wMAbynhyxN+Z2U4id3h1rWscVpJ bfJ8u91WNGrxxU7TSSu4tBetZiivLGh0xG0niG6ivkeYmIyvODoQynqn0qFGG2Z7JuU/taMJfM76 jRwFgYjuANg7waTj7Gw1I94tMZBaHW6+KSpvBEi6TIguVR0AoSm2zrMIYKE+ghl/loBHSe/XAmrb FM+QtR515yhu6QuBDtct6owTxKszG5o6ZjDmoV39NX+DkfJTIH0SZ3ST5u5iiNQBzaA65p2XIBKp fLZ5PWkpeKUIHaThoV+EJCwjD4z6PtBaPGLd+co2VqkKcAkxu+bjdjtUK/9gQ7royjKYuUIjuAtP uXV+wzmCmcowyf9UR4TvxCmmkugwvkqcN54Diogm5ex9mRlK59o9TYqsNdYco5djbgTu11LP7KzT 4QX3KZ1KkG+BrQAAAm0fT1S9PaJsggLYiSDAACB2PX74EnbV421jSkdFgt7kv4xiuYVY/Rg2McYF wNpCKPX1CxvZdZVWicl04jjvOASWq05rZi1P6IDGU+WSVIpfJX8tAeaHqn5GAIG+2LfrvmlaUCWp JxV5+PEmelEghv33j6RMUuSnwTAKgY+iLukUHOG5enyWGdWmwgHUkNAc4mCuH8HFzgAIqGTyFXpg +9sTTeMD1DjJkbSymlyp1hZ3yg0/3tqwDz3EL6oK2Cwxb9seOLJ1kdAQGZxe00jzGpRAzF8zQyIA ixrfRvNWAt+iZayNykUWZygTqXiFFak+5TePWeRj7kc8CjGO+J7PxaJtXxzpKWSljtKLsQPreRQP NKRF/nelG906qMhGSAws29zNiDa/CCZ0BjH9qlebnH3TU1sKF4RskebIVZtxR7pqBvKYg1IDIMyY U4NEB5ydHzUuOs3lRbze39+Qn9IkkmbftbfSYQInhjQksedDxjJhPJI9uhwn/c//HetpYBmYzoFy 6uLg2KvYbWVrcBC9seuF6X1EnVEd0ZZi6nst0uXYD7j0C5AgV5ObVfoVCIhiM5GYkYC37NnU9xEg YQKEUVXQJh7rOUG1wpJcuFzi27aqNPJtTz8I0ivRA7Q6KR5gAVUNkuPFOZukK+OHcVLQDSjIlSgU ARDTLDxr5inlNASKDv7qz9eRvJ92MDwh/6T0KiXU59NR3oZ4yDtt+rveNtXsw35dLCDDXoGYpBnX SKbxWoAY192C/h8rqZBD7oRhNFr8SL1DAZxf08OYPvy+fyyfPXrT951YKkSsEZ53etq0JSc/eldJ vH/5WlnepygRdVeo9wAXoyAkj01KTfIueWTxeUJefZhuby0wQkqB1rhC9KqwHWQ1jA8mYEpFqCF3 tZcJDU1SfO9DPVCIupbbAn1mB6ZmBUzMuPCmPDNYeZo0GE7VXfkHdS4+Qyu71JeBEw64i1FscxyJ ydYxNHNbfrEGPjcMlPfkXGuvLVLXbgN5fwGg0T6ry8dfaPz0RN311BttxSVUdZm2Z6vwVL4biGZK xiAoePl3LMsbrK4TMm7K5sBQ3LHsG9S0YjaumQ3mm4DgOLBiAMSey0xO6hOfEBMjlDKb2BXp4iZD ybNWDnCMKwNnNG6R7I2+CvKQaE7h5qhDe54ZnNV9RO3jA4zR39vRENIiItEBkeVZNQNBkeHk2GZG OE7Q3/3jZlFTAOpKdCydcSUOpV8h9LxiVgJBHy/FrqL7qjKy1xAXvENoCo6T8ptXM+/EE/rn6DUg Jzxt+VsqeTZ2KD3wU6kFMYC/Y/sbUPMpPpJEEI5DREY+XiGBRevELem0wF3pU9x9as8fDuzySoIK W8+rmOyCzSajBiiCX3M/W+Ye9qz5nR9cNiBLr5UruQXZWM8SsVmjJ7ZSzN2PKRrtl/9EU59zm5Dq 7V8MaJ9r55t/YdgsCd0rm3bDOkxhjyY00Q5ziKrk9bBb31iq2bEJTHAV510CyuDnP5BwhhvUBbh1 oJpONcHKxly9PYAXUVIyTJcd+wB+qs+elS+Lu4UHX/oxDq+z+V/Y8y6IPWrUGCzcSzUuarzlkMJY ZSJRsrFecoKRsfKW8wXFHHPd0IrzJ08iJPWhw3HZC3y5DOoCs14qoqyJE+P//j7nQpqUN2G+J0EI nYd6wOTdt+TsWS488VNRiN0h+ruqX4OzYAkvDvLlanQgehcWRNH1UuRUbYl+Div7P2FmZmBjTP0F XIFJf7FFF/Pa/A57YPCnJVIydLx//A6bJye9WrrejaVQCqw9WTRHYyOY51W2R5Xl55OrFAOAcAqk zWHI9IgiN/LSuN5gZTLbAkiJXSfPnAIekcWZtB+3f+xDWbXAfME5nEtSKWlJAEGxVJGvjxM8ixVe Rpdutu+9iwbhs7PFgSpiXLTJjYmUnWyTETlTmyGuU3vcADwpujcsDPzgDDnBR4+sgo99lyM/HZa0 HgdKHZMBnq/l9OqHAf0/olhAbFIgA3cjsSu/KGgk0L7hofFX+Jyvl3rjyCWPxOXaYOEr5I+LN1F3 c4+ceak2vzB8B6gfOwtcs6WV9EdGf18kU/vZBI07Vw0e6dUc9evNcrIB9xAm7nWwSu727XK/QchT TfUytcesb52sCw1CHAtSgdYGzp73yKGF2DcE8Qz/CyAZU+9mDQsEtiytAjAnJQLwVB0JlLVXYZIw kjbVzrqARHX0FuEdSgyyTKfD1oxO6jOyEwYv9pI1vA8v8UBAvfRjABTEp4O2sfJJdrdeSOBWzzOK /DziHOvHAUxTLue1hpQR8KBkx9Q+RHkIWj6K/s8403GK5bk/iP1cA495U206K8FJ9hOwhJVhDDX2 kNAwHvGlx6iStOddpmQFno4vzhUy+VEZi/pPVFma00Ja5SEyqJBNsqrcCG3LTvY+TkKQ4YTGq1AA kQl4WGRZHqNSQb8Y/0j/YmtJjdWnervdYiTGaqFeL5a/OsqXJfqMH32CXyuIst+aAsGkFOmnpNCD xJ+6iasGmW1QEwh2dh6MPiDV+bwVBZ4s/s4Qemvw9ATRf5BmgaVsdFnPK9AA7Yhbnj53vesNUUpZ AorV7IPYFdPZa/jW9cQkONUud124gyf3sBSxnrMTiHBlSQLoYe9F0bjncFrSJe7g5eNeCscjBphc t/t7jYtT0l5JKAmQMUDe9jrPsYLCa6FYHLP08CVIx8pU2nowpOhPJ8MdnrfhGxKHjVuarjQjuXh8 9sNtcD6n5qqvv4m3o/av3XCvXRJbsPWq3XkICnoCVJH2IKP5yKOC7rtjlbOGAddHjq0R65DSRLbZ 8QEsSDlVW2Z3muTcuHFBG1t01/Fcl0U0PKLJS9qeV07NgeFPtJhx49B5kUGrKJfYJaPzvGtgTwlo NIhKW/cx60UYfdUJdwnFUlhvBWqcmdeZLWikL7i7oItRCoiMLmwEvGVgOUcdSfpGMEFOPPYYfj3H kF609q14FR4fcDs7cQ+uxkz0854+XCSdjARv9Cl8Bo9IhQs0hgdWhNlv/LfRrtrYACy0RGVXlZa2 Uthud4Xt7EkmptNFjTdPm48Y0DBVHCMXSFsaerbAIlpK53CTGI3KcIR38aeBBCXQ5WJMkBy77+sq ojvGkSOJDqsUYdNT6crhEA10Jv2GdDYY+a1fA/KtRbMVQvaYzj/DRwq++LCSiojqWLg6qSQ7oFAK CW0IkhX6yve8VCeNpIzc+s2rIjlhiuTJhKi4Dkw2Ty6L9lck868ZNmFezOYkrOxaUqUCmri0BsCF EcMH7KY8ZG0ID3gFl0QBs6wdYTlRm/kB4emybTf3gNcE2trt81KK+VSpmQWjL6ZYscTs6t89PivO erMb7c7hgU5InS46A7Y6G6t4w8yvuXxMVruvfWu4nZHwyFdCD8jJC0IsOYDQULQkbADY4XPoknFp GHw+0mbeLwKPck2y5qeBTWqR5uQWyYKXl0sehX+NlUl2g73RCiGmUBqwfiQBdkzCyWLTcww5hHtn dB97gglaYxx7wXcnqY2m+ahvIFvnBJbSzYmPUL1G8b+mjyxnVdbbStbVLqn0BuIPQEdCwWtLeBXB t69245K6MrmCuBtT2/cZLzejQdL9Sh/PF5pQwkjkvc60zDNC7Wq+VnZREKkeV+wYyFBD+vjWCC3N 5ZkOCBh+5JHpb5vbBCkQ0duUITQyqaepGbHD9bgoaYmzau3YhwjMLj/Mz3UKMmAuzKb55UbTVRRQ DtjDNSqNda6axAkVaBQXITChSDLL2irdlW8LZb41EpwM92zxQ+KIcGy6w4sKioJobbt3pYhbNeQT kvbZKY278cap73ruBcpQ3oOrhPPGJK6awBNNR6PhwyaQH5gqAfa3R/EDnWect/3xKpkWRSh0g45E U32wK1lzVOHLdGvgZslN1U2bDo3xi17j7QSan9rh7hYSBgl4xJo+h5ly+rz9/rBWKgDvo5T1C1UA 3qH99Ejh+ytxhbXU1Wbf2+xrV0/uDi3LKnJbLd3QGDOxKcI2Yavpo7E8Us6g0X7rsObIO1JKhPBZ +kiBJ5mlFRbg6mR/TOglJbXiwmnrdUmM0xjZF0im1FeSRw17sqGYXy3zOYDO/meTetoC7QVnyN1y m2M8MqJnVJw9CAp9Pn2ZiMrlUTvrfHL6DmfFgwHIOTsRo0F3V5e05VQvUIGAFxOVvSKw2AVf6/9y NfWpCpH3zToqDSf3qJKrDx2HXkInQbEwCXJ+HZ8vRcyAMmnRRzS823E1Btdi9f70/ALWLavgi72Y D/P24WEmEkOeei1dY/X06CQpjuif65xh9pS0UJtcPKvCl9dlNjB2E5lbyaQ1bdRfQ8GCSk7Ug5lk JWwvs4krYeS5CcvbW4hL6m2XISi9r4zn/HmcUJ0H4YAVCpYlhzf6q1GFYbf1w6tmA30tqmvtuFXk X/Zv1dOVPIIaF5+Pg28efYpNHSCLUBUVpEAbc21IyvFunOfAfPPrneBQ3BYimKv0ytwRG0RDOpOg LIHtUlUDCLspDTkQN6F+1NQY7ggQ8kwr71O7Xe3EY8EhuuLQN28VqgvzdGKXxFD+ch9qE3YK+3ZN C4gLHPvKzcf0YNi6u5kWkYOHX8jgTu9iAwUPSZ/v/g8x686c3yafWMHwSaZZzhW7pk16J3r9/fH+ 0epFGLCgGmtPbF9Tar1wMjZJGVDci8Rt8eygzbvs4nws1EUL6dKFJfG+lXCuCMwdLjPH3NleWDAc eOCfOVkca/7OmWQcF+zRG4YTTHrxnSdBDRAF8ehzpAB/uheg0OWrS9Msua9G3tMtbSgXmyV2nTpi qOv5+St4bG0gx9wVABRZ/Cm/WVUp6RUSKWIom9z3xS+EAgaaN3+r4JvSO2yCL3mK/nzg2CXusGTG raOzNZI1fs4iu8+PsKs0jyfe3IYQe1gkyDlzAYTyWAT+oCkvke2ljmGXZDOqPIprR0nhwsLhRcxQ vfa52PXfJIwvnSquyNdm3XTXsD7mO7IDFcCnXlhzscjDBcnVmpFndRPI+R1z2qI1ggfGXJtJzI2a KSpK/sWB+XRUkZN9cg+m2XCD6bpjxtlyOmox1u/jywEu9DWGgWcvjQ5/AGjC1s4LxyjthA0pxjeo pJy/Q7SvHEJwj/VptzRCAAdA+L/4mJp30/0CA1S38UBEn+JjPiDYY/IpskPs0ghyy/ekgLs4rV3L 3ga4W9zItaa09FxtE3r9+JYaMj/RG/I2KIeTdH8m/Bet8j2iI31Tqv7oD/5VBcB9s5aoV6N2/Jiy H0jxt584x+hLw3/hkyp3RguoEpcbut8BOOOpxQvKB888ArJsrV0m7GiCi5HOgvmFmNGR3HTIZRwV 1MMnXYaXfk88iatjlM4xzTYJ3yBLeZv21m1aolg80yMl4ZwKGv6EGmOgTfJ0+/CiK2n++Tj4FMs2 ftMGf3085pCkIaAB2wgl+B55mvrM1cGdTTm/x4i286f6PcteV0ENE9QsnyvyJ+BD2NVTV/n9aoFp R8eC7dsEIq2o8v8nwfn4k4CuOTGC96VH0F+Sn2NQzJbvy+5mmkMquy5mE8wOxmmM8h3cjlLffTn/ /xOc5eV85xQmQbPrtj3Ta8qbev5rZD0nYt+oLKSBpfza3IikCN4YxYP2UetvwGZFRS31pVm/zwS9 eNOLGZe6vnpZJYPfL6749kKsgnc+B6p/964WKyyUDlrjJGMf0QQESDxd22nH5wxIBicRZsgNAQfC 4zDH2Q5XtdlJHAclzb5+8MLrL4uxeNXoi0oP0tyaahJz1zzq5vgz8WFotEqdtfQXDfLIr2lwZhSw A8D8sQsTllSl0WRRKZwJL6R/ZgdTNAFAQSOG9wpjlwfnBd8quOEZMbHhWyDEh5uKVKycQlrgjXWE J0a6gxGvko6w4AOKPuvirWc7YcE3imcJ0/gmGBQg92i3r9qCUG1IYdOYYgjlalZGm2w8P5HjaTYh VVHLPv9AUDzGD1fulzLpLhYwXFTwjqkLN5tnuwPRDlkVTOOuWDuV5/04WvXvKrmYp+SLHr+iirw4 1l6Vom7qAxxxJaO29tQoVwKkc5mdmDHhZPQfez7rFFXpIm3r+Ls0+r6cvzywwzGzwQnnbUTI3hS8 7ygavQBikQH7deS2B8IAQpV292i4a5vilMVlr8cxbV8f+rwZjA6UAu3rmyr2Bvce2FzffCuQb5aD TWeyRrorbkOBkukKNiH4jwgLEOHKSPI2Wn4HgegXTzUkviZ8klgcZW7dELaIu2VzQYjogrO4hKDQ 0uPidMQPxcgL4B1BGVOJvcRkDoE3twogqSau50Fw4IUTpqMp7fa6blfBNAbZXlf8iHUeFM1rERgG W3AvsNVe1B4Hdhz16LjVai+QrgqY8gojm5EfPeFUDmyV88p6V0BVABsZFrBu8NBQO+UBebZeypZF B+Su/JDQox7pOFLKIuYKOtJmpl2LOmIrIiRdkTqhhUsSVwzlj7G/E3WxIcDS1YVxINFgGAQU/4Ib EuUGIR2BDzM0TxKDBa455Nw8BRw74EJ8bsQ0tm1Zih+R++uI8FFw2up7cW9hVOGanOcO3UbDEMBR Qw0IYTvs4J3qxWcCjcT5AVWyU62zyRehopvJ34onootbMNFXwm9lBzjivbC9yy/A8VAhcj4Lqnw+ edCFWttJdnvySmEIWhJLOrpDR8VJWpr9iihvyuNhpHmnXrvUoqMS0S+wgWS8QJRJj0ZI/zfTP36z cgv6vWIUhmsfGorEo3zFeKlFwK5DBxkMo36XWLGvCa2z9H562Jrmx19IDIP60uEVlP8ZTjazMTAS a7g4AytAuraCeqShA+BbmChlDMLVBe5/jTNsuHyHcAY2bEqOuEEKGuN/d3j9V1m3rd3FF0MdPrCC T8vnEuWSDvLpPQn2QZuc6WhpTH/KNJnFHpXMfMXBG2e0WIehLtVRICyvQTyLG8Ml1D9L/FgitiEM X66DkYzPr+hWK4W4qFtDLh6QojAhP5wH6fchZGtxIKQ7SmbAxyzV9r/JUT5fACS3TvyDEXVXbomK Hp3nwi4ALhyuR/nPCNfoUB4VEfPZsCVP3cQ/KclRMIxHeROTua7aBRMmjl6mOJH3Q5GOx+d1QJHU SrLwwy5v7aWThTGxjyJKyCAOnRt57Jk00gmFN5/YD5r3KUgtwFWGXeDQLWKUNI4dX1xg/+aU/+RK LclofDyxsvXmzhMlpcZ3wfUkATof6sgSq4s8BtkaQBPcvGBV24Hm4eZKLEvUZ3W2JKwIL/ZyI49d MeNAuBe/U0orHdtGP2pUTMSb/mj95qyW/5D84aDhHPOlxII0tqoPUPl4G2YeZtT4lyf/qKhalK0f ZZrvgt/QAkm0rZUKpzpq2P7XtQDICbgffQYxUAQCHmC4n9DL3+VvIcfu3P7PmXtqtt758U4RHsZG A0uKJTpJ9E5rdmxvEOKmDtDiGIi//rxkyo2GcoarBhswUCPc4Ifw4yJHy0KgRsakWYumleiuCe68 C+LLGgCMcogLNPZ1mYX1WLTEuM5FrfKaosXSu/tE3e8EkcTMa+DdmMgegewirBI6M1BAly8TGPFq n8/BjzAE2+kKP99XdkH6IwQWmuRCHqt74LbNWXtUpcZLrGM3bc8TcSs59nK3K7l1T5iVuTudf9US rwKjEa+qSFj5RD+ZJFIVqCqu+XqyrUhs60UUcZa4YDPtfCE7vrjhZ/GtFKKwmlqGow14mOgzG+U8 Ar6D/1BnzBnWR5DzGKCCUplXLU1tySgjpeorKTGQDlmuW4D93PLoCKq0DLg4TnQVNMnD0c/97xcw tHlHKV0dFSWftc6jS6CqAlnOcajfUxb+kHLAnOt270r3PiGq77KHxpnDApb3/8/gMDYh1PyeeuuX SbSdeTQ+YdKZAzcDbfK4XbxBfpnohuZYIvLQy4s9I2uiKraIfIypAonG205pLYkgv7QU2ZujohYG lOwy+ZV+8nkBDAjEc89VQX520X47J5mgvtNuWWJpLL9kIeuQ+CFM+nCLwBP5qfFDckkOPqT9hYA+ B6suFLKOiv9tX+yh3Dr3xRwICoHfryEreuCwFFWVWK10SBePBc9pytE2c1tg6j1j1xTFVJ5MaH/0 iWqmEUB6CO9RD4VJIHxXoSoXz/pYuD8bEbwOs2GJ/7H6MjK9ynJ/i4hIcA+dmA+7oOI1XTmFgbCl fNaQ8ghORQHPuF1+3pHMMGnarHH1Du8WTGIeYIQzQM6fpEk1S9LXoQZ2BbaqIcH/cqsqbAybCmaR mBiNbKXInq3MvrjEzBavZ6/cicIYxsfWmzRosz6VZC0a9ze+9A5cyK4eSKIhqM+H+cp4h6jPetHg yOi2xvd1CcP4elcKQpb/HcfjuY0Bq/Ls3FSslCW97xLdzNjPd1TTMonI9bPid/E2AI2SuCZjgIsQ Iz2EHq24zZmx9XSMYcCX9cw25wUpP9yqDN68sq5hFKYxc3Lg8qVl2ZLTnBYjli92axUCqvz1weD1 SopbK8sn6j8kI+EvdhuveBs99vPvdxUKVGZrcTZclxcnKOdj+VSBov/H2Rywg48FFwB2vTiic3fy 2NoqBvRqdQo7b2Y+ggFzc6507744PNDFFxETbCSHDRx4Hlp/IGx0NwNJOaoJHBqF49j9g+yvUGS/ Pyim/XkGi2TgGLRv7o0UCQWsrN5Jv5mWtwcV0DaAPvip0eNSSRu0aowRVVsyBZKWJlpVMhbZKrJL WKeMGvIaJpmbqSu53JGC/lmTKVhvWjJcGglVzFxoqbVDQT2GYBWeUiYaTXkt9ZfEx1ovetoRoQUD gy1jCiUEkQ5NyGA7UP8/6j/iNJHAk8UTje/Zba0SR0ooGq7sunzc1dnENgQhLdH0b1+Nvaw57Mag 96Fx/Fk3ht1IP/BEcPPVBDsnB6RmhD+Yle8omSc4w109GJ/QfaAxgr5YQwunLGed+GDmNcGZmEjR FvbpE230XJ2fWZeQ18PjJ881C9vZQNn+49XNfZ0xrqIaxq0QFeJ6xE4DIogqmH9QwtWbZvWOpwng vB+ofpqkgK7oTuWr4p+mO90wnC+bbCQN5wgXPeiy6yKQr1oaQTWXIO5x5lalnvCFMZuhgD9zsQvz AN1q0kJOvKqYtYvNdpi4zjEbIoE2L7FlPc2LvhUE7o4fVD1QjVP8uzwYJsds5bU2gmmFyKjSsfXU EPscFyFaPJRENKAXMfZBKz2eEqf5kPumDD5FPoQN2DGPHBe6Avu0CbNwINPJIsron5TimKtLI9TP KMrKBwg0AeCQTh5ZkGNh4ckypgr7kZtQSqR+9lx7VXTxEFcRWKQZ+ymri4Y7pf6cdble3k0c2U33 mIGZ6IiiDZZNz3I6ix4xY/juJivIUuifylTg1UIbj8ozAYCzVgoUsh+c1r3jTjYQKYO/XA9BgGVQ 0BvJAmiywB/7vhpPDouSAaPvU38E9K1K181sxzdb1jUWJFUnDEDGSGS+6BXn+gHACM06c5844iZx sYdwDMPTRKdIEGfAJJzqLUdW9FDaTcjPOcwIzC3w4tECdLZ3179QGGOhBts/t6zzeI6rWmYf+qvP g8IpS15qhp8Wd/NknZVkC4eufpwxKTXCcvSC+4l8BP+hUidmAG/7gzyG/8OEczYvaQOKNx3TgfY3 BWLETD0kg6beZV0Yf2Dz7kW+sJIe3WQ6mgX01FS6W6ke8VYkeA0+Fpg/UD+ftbJyNL8a/xs7D8QE ZnYmiY3eLmen0rS22wrMMvBXG6OSijxgpUaTZeB12jHe5xvVJJDv/50GpfKFa6NxjuI8+brFG9bw zwKEMVCKcIW+giDlA0XroFsw+nHqJNbXOyESCumNA7h+pXTJOamiUeaCiVPTcbySviCSkHChPEo1 3XZiqliQlSOA+nc58L9hV06a9O7age+pFSgQBFGeAesvsD9T8l3h93q4EwV4/EmmIMRpnWxb4Fr8 3jvmSO3PSoicQdW1HHd5/tINhryXOcKvo9x99K4vjzirjMbfSH88OIPZuu2k0x5Vtr6Vx+FCDoCj z6DQ8GziOJfYHhN9UinT3lok1JmUCG+vz8/cjoc9VyfPB/pDL8MsP32JiTwpaHt59Xmg5L6r1ju5 gfH2FsIi2EHAKX8xeuNWeFPNj+OD1nNOMkLhCv0mQ6yE8hvWLm8fgS4Ev0DdAfdKgXdfek0Ua+eW DUnEZI65QHEUxTyMhR9I42937SeJ5rFrcIcIxMTfs1cTkGffsnenP9ucf1ldOGAxZa30mB9ak/B+ lrYhwHPoFcxcqLaLU7xzXO1O/xreNalvu+rrDAMRn4XJrLuiTocJv63/r5fx2MUD549QPu1XD7zt GH4MSixyC/HHyMEax3IWS1veHxvN2PNlQAXZFLcydMIWnccjrR9a+ZU6yzLQuP1s86QQk/+/A1Jp O0MGT3zY/paC0G5zTgjUn0xKAVuTmehleI9VqipRI0NiSJs9Gk6PF6E7tjHcQRLHK35aURZnh4PC VJTwvGiK62yA/gqBq2Od2gr29050XWIUQWXQtW0O8ygt/XV310XtEJ1sC+ai9/N4XtwTX1phKNK0 1XJ4LBHquHMUVAljh0wJYfQrFdFWJso9yX2Y48nE14gP/U8ZPk++jKCBBVAQz8STBdGsH0PBZFtO NOk8fV6arGCYLIMBm77bOZoCUipytF4PUAsdIBFxg1yEHml+/BJegSraVwzIlFWRLBTOuIvpQb+r /8KWaKmS3l3qIF3mnvS8w1L4kCk7Ra4svv9xjBZat4cQHbKEjjfIbcJ8+BXl+WKDfMQtpaW2FtYN 9r6EcOgYKTbbGK073WC3NtAXIhborwKCplo9wTQnb4k9jSC4ViDniFFSCUum3V3tVqs2rbd/mjLr 6YPoyUpmthp7x4YAOajdW4a+jnfB/HWJqKd74hF7CgJGjzJmr+jkGWUhTy9kRPEqpQrbix8AJ7n6 0aMqvZSvH0Kq9EIgW6NxJeC28I/2JILaggz54VHo0tGOsToXYUk4lCgBzWhQugOmEAOKZxBCN0GS wN9iU3bLlGQIA0VpfqEq5NvejmG2/lyGmKgSMhLYti+d55H5mZ3GhKsSLuLtlPlIsnkdOQ8xs2Uz yO6kIufytzR9qqljt58fji3fq+E+Xz5YVGGPVV6+IrhNeciIi/QODujmuxUY/PltC/QwNA3W5lSh mlnCxvTwz9YsmEAxWvlT0m8S0ouFFZwHzgHsq6eva7R4i1qsHuFYd3C79sJs+ecV5JoPciPXGXxn iLKinZeJg9ANWA+j+Jtr2/FpyTJTX1VwXZI8F542qh2ETLzQuOPDOWkntoY8uM7RXD6UCywi6zxZ iZT2yG3+KBGQa73zBVGd9vNimhXe47fNYKhOqltNvKRqw6pbXUeZ9N25QgLAm5J773K0yxO9CeNk BYkoiq3NCjXPZhayQXPTRK6qD9SBF2QpqW0Vr7QcKS5SSetcW2+BTrEwqK9BPwu+bdG0urEkKtfE i1YnzlcX74BI8FjsAk4sWdN0f2psrxbe167fUIEerzRjKD2LdShBlzQZKfYSHnsh/ideR/BizjXV 2ocCcFiUT2p5HZlYe0JMqyEx7vDI/mZKyK3t7BZvA3gArI4WXxD5CIP6cOHzrRclhdZP2qPqnT8Y 8qppShhgEpAlxs0BdFjFCAZ5XgYGCEq87cNUZ9lDmUIIYN6O1OrjAG07VW9zMKOcoZDCk/yV773e X3LZwGBOVdVbjZUt7xZ6NpiFwmaC5bG3bJbRt/app9O69GvXhH7D9qiXDa7In8GX3VIMl4MTUhoM pXxrizTRkPNZIl+RJGBMu3Ga9vlj34eSBclEfn8qoEFQMsEsX7jySmVGD5Tgc1ImRCMbPOXRcyn4 ACDs/nyCvS1k5cbbucwElz2nMGzibKVHNm+TZ2UaThfVqigvEfUCF7G5fvMcZwcNg9z/XtywkIhB 5Ab629PXFq9Dx9aNWixFMVGjOMkm0fhLN/pDv9xzQqFaWHRSasC7V+zoRa5a4N49UUP0sQeKRrKo pZDEDXDGxvpKy/t1xXoB/qe74YXCXX9yhY9fWtp2d7ixxxbbEj5F8MKEWW2O0Gzlvp1uX8vNOUke e/GVNgaN+u6rURZqyDfWXJksaQTEXZ3WHZJVvD8Gn/ORGpYrSm1hzlxxWIRMhviEYF5ODkBGiREa 96il1NPRUac+LFD/LY5jLYX4Q1fDTKNLzsPqpbmkbZVCTLhvve7pcVv2rKubUzXJGwI9VUiFX3u7 XOPYRtEIWwZvo4J8CidHQ4e1AHEgXDfaR0OqFhiLCKFJz9yopPzDL+iv3/4eigTo9x4thlvhIsva plORzsX5l++zPBWwVRc/NaSuG+Fj5g3QWCKNNqADcEFUJyNUE9h3rBT7gT6CRnXERh6f2RF2eKDn 5J1oJuG21ep+z9/VAX96XkdZ7ILmku1OqVcysqlIWBGbtpEqzy7tNY+/gN7Mrg/g4IuWeCOOQoqR jKdy7adOfgBO3+DmbPzp1pJH9SL6GulY4Ic0k0SrOwyqtQn8Vdzgk4xEe7pAeG4YLErqvKOlnkEW p6sWK0eMsNpZ4/sazNWe5d/BozBiUHndOrR3yCcLJX0ch9wFCToC7GSfE2cBFjUpI7/Vkwf4RQsa exIJnjSzghFipAKeK2OO5b8+Mv2ZzEfPMITIB4B7HEtjeZzI5tzjuRk9e1Zxc5JbOsM5SrGuF0Eu Mawk6Mxpk0ggqkxHgRF9jaUUzF8W9zZFNus8fFDFm4JhaWz8QEQwbtwOr8nj43E8nHI394SGOJC1 eTPo8Xw6vMYnQHa8rXiF/8kXKcvQ+5pBFwAc0smnk84pHA7s6kKQ3kTXRRjwbxj1WRUX5LBWIQXx BF1h4gSAtQslZ4lmgktSyYYiFioG7cZ3WFoLb/wKE1H5jFOjiPXuUWUCOIP4oBUx3cyvwy7OP7Yl /ATjGbcOsdHgkXB0OhhAOh40GCR3QEYH6O1JZo12KAtt4QIaWLtwB5mD9JoIYK77tkhSEHFUx72r 2S4iqvZ/YW5tO67HC3Hqg9nIJNa27E/OEFW0S3gt69J0xFJQJMK1tWuq+zLLOzVracP0XedPdIMa gLpHZmNrBxx9jE4+y0fCRRjbMlYdjiU8ZAfsInyeA3HlDX0zid27MP2hAbTd0uzTxK0y2IpMgPUB PdrydyIMHCgp9dRnsrs44nLGScR+JslqHpSlTkGVbs3Q6uWkuCoz08sur0fhf03rnbiCqVF8zUc7 s9PUdDK5hGTWWxiSNUmNN3YV4o0mg+rgL4dvTAwqQcoV8/uVEXOH0K2B6H7EjKkLn8f9VxhdmJ96 m2Lr5p2GVfhmOzRw9fFrQ7U+GbVLiXNDSnV6bzq2qieclm4mKofnv3UcwwnxgDRVgm94Z9FJz8T9 vQigVWLc5MTt6GLvoEHJ2Fw0274Cc2K3l0L7thkYRh2ghyFiqvXfizlFA9S1JQi94u9BJLM/J/Gz 834JHsP7yo/PNCWM8sfCKa5O9Y/t4mMJEAHdV18Pgs+HFClsI3Pf5jG2gqozP9qb20zC0TzlodmG TMLIoBm1gSpenblh3bjS32PRaUaemtzUhQMmuunpmJnoAxQOcb6nQV40yTuzBt/DbMubId++6fwR lwHjnEOJgA53RrGd0smsocJ3Nb2+QnebvEAUc04/rf5dFKUK9IfnjvhnVZ4klYDt5dNzI5SjbP1S oi8z+dsMQ+cj3W6gqkP5dCrOqq0nlwsb61iB/ebezcOOnRni3/GyzT1Rb/sD5mAOkEGPPWbQmaLZ jBrtzQD8iVitcuECoPPCzEU3fbVUAbFi63ON/LvwvorQOh8TEf0u+VMXb+8MYCUkkhUVcqyxGZEZ R72GfY8e3ijz2/YhICJr1646mu4XZ1Usob0zkJgON+8FjX8iha+iUwuND/D36poFKFD/Wy/UYv4J 1ZZ3LszcShDNXvbZQEPs8nw6fYiNEG3Xwwk9hCYL6o8gto4bx4NuIgnIgmbJS/+53yEIO2Tl4Oho eiTkEpNTVGAt//sUAhe9TVnzfUSdxgsw0kjS+mYMPpGjaSeWaBywec7/kDrHeovlQx96iXxwmNfz rot/GIPhw0fFfstx/KSyrOJuy9ZyXrfMnYC947d/6FDGM3eSK8Yele0T7ogXbw9cJSMltf+/5oXt llpO9FjTxYpPUbaN1OvbaIjG1/K8aXG8QWgTTBacvHhHndRSgtlY5WA9+iwfj6/889bbWXJUOyWp OKy6uLQZzp27deB4UVKXS8rZWZ1MxOyBl4V/1VeYGGn4H6aqUs/MUqbRpHZ5R9f8q/mBkTuBeYak 0vFmBlaCekhjtD2uo76b1+EB+ZTh4CMvT7QoyN3vWe+aSl7s8d4yO0CPwpavB6s2s2Ba7AX+ziqD Haj79ciqSS51A6CqbwbrFOGDpe0iZhRLSHJPCoqKk51dd0VzC8z5tgHBlpW/NkjUlP6DhIAGj6+U VLgDsb6J7x8kbU6CYIqnl8J5W/QG4MqhIwv80K6vkPhS14qsuV9MwJEau8cGb1G86JzOA3dJmhqt OOlfF+QcBYVFtty+3XcalexsNOqd9p+2E/9DynmFz5M3W/heoylpSg7AV/BsvG44grKq7fycARJW 7GQVi4xxNS+s79ocpYZt57nxlRi2PJNDVNzECxgUiB0buPEidIfxVWcK3h5aX47B8MGjENLIOuAn 3xbpxzyiK8jIuuKoQW9Z3qBtbM80HiObPaxxK9oJrvPyjErTEsi96yaXWndwCz+ouIbH0LKHoB9K srF5AeHxCbZsgAmXieqs3in3ocBxYxlxllmdHt4KLZNNhtleLFYdGOKcCwVxFIS8+Bvs/J2ntHUd NmSy7fRhh0D0vq+mZeUFYYfM7SO6bPQJN0PvbInAQvBYnFEHezx5l+PhAwOwWlVRWXMnBDdlU51O FrrTDiguqq6nXlKC2eCKjcex9BasqFeru22QO6o1rgLVI32Du6S+a/SB0pCtFYEM5JayLnWGS54M Evl6EtimBWZTejpIxMOOe9wI5dB0h/39N+y0tyZB91zwMrZRDA8VH3B+UQc5+idjNNOo5HzJ2/km cxMymrqwrUk8mPcbVkzuOr5fLrRewHEsu5pxSaVzDJcBQqkIW3hptThZnr8nZDksnz6/V6NzauOn hIJLiDD41WBdLC/0A5HIlc+GpC4JjndTDntOJrYQVK1oPxaYJedmdzuGT2CU3+c7MLObvKtVV6AJ 89THpBDS//ho8VfKSkXkczuBMYNG4Ot5VFSpU3EctRl/z6zEOThLmKEi21BrbD4FNHqT+8XbhiKH SZGsAdg9lCO4s2Vi9NEaB58IYoyuz7bXN8jnNDnsDOZ8Xe43Gr5Q+DGPd2ZZn8d01kfAUl41UVl6 Ob8oK4TYelGe3KpWQr5jsyWO7G+IQTzNQ7uP7JouiR/XyAjDvlgCyu2NPqeEPt3ft7fpb2g3BOqd qhdsJ7sdXors6VvQe8RsOWqE+vrNwI4XExjviIm+13wdYjKtw2Y+DQ9mCKUaAr6naxwvtA24WSau bB6h+0IZ428u22vcuLcFs+KryenDLlaF3FKFpcQJh/7ZSLLGEZ33Zq30SWpHZfS/6CAR7dnXKP/F we4H7R37Kco4utqynWOjfE0rzLzQWJtKkClPM4d1ZiAA9YzqK24I5bYfW8+XJSAGIGjsurHWDUjm vaw3q7AQy0HPCSGEIu5e6lH8Jo0saoJ63rGShmLg6/Cw/vYfvpXoiTmsFVJe6SBhLf/ba0ifz2iJ wHr3i5qw3Id1O7TnclzIAZ48jTK254mqWlAhJAHxYeDe8p9N7h3r6ipcQS47DfvYTtKRekIOH9Pv 2A/inUY3sd6IHGiRYIks3qvdrBU6p5PG0YHmDca+PazMg1c7FMjlEgmD42SkoaB+pxaFejyI99qE Qc1q+f03u9P5PvhelSpGNMRGZpHMDByn8D+QMoyd16KrNjM9KAyleF1cd40QWjTv7jIeS2gCTH9m R/T5TwwY4oxnBqm9+FRxb/Rek9MQxYwQBMDtAX28ogkoB1Oc0qqcrifipJN20PsKwynNRSb9nyv2 jCImnZqvj4Ual5BuQUSuoyorRa1ar2MaMUvhQN5gLxe0Elopa7uVGwWGcffqoguweEACXRMxn5lX lzvDewF/6wfaLG7bZEeUgMjSVyy/sS3jOvRh/0mhHaHhbc9gJLFtt0CxrJxKtkp0kopCk675VA1X U8cXO8g+7IZ3lzOtj88m1jS7+EfBDW6j28JuvRd0tYl0YNHAia9R0wqwTIReO+nW8Qh/q52ktDzs h4hA2aqbbpoffiVC708lc4ZhWFbkscnkItge0eFnvIkOoQUSsc9ZLavfMixTSXElJaYixCz+HkoA 4kDwVftAV/2dQllvWMnFpwc2KuseoLtQpojXRwo0LdL6JucSNv039Puo8VGpuGO/+9AtuXomYu7M KQwjw9AYHFfX+qtOK54FKOEfyKbNEsnhA9suyAC8SEY9MJZtTd7v6pDFdSjrWgiK8XjRD7GmeZqA OCNgJtyswtRkZ11balcLwi0XHaqsBSZ9eIAIhdBkg6GuAOhhq/vB1p/iIFhp4Q0dQlg6e75KDFTB LF7H/cm8k4mvbsNDsn9IrBPQ8Klk2I+hys4E0kDJbvnwM+Lb/FbJ/5pPTrd+lv0d+0q1MiAY09be W5CQHcae+Gg5CL7iXSGok4XEpunC/tY3M7m4yqbrXm/pwb4sMjKLRF0XKKOoGPljIoK6WIrlf5Rl TT62U/9XDCECRRb4lG1dJBUvjhgWd+Z5SJ8WWn7UM3gAByEGqr+0R+flApenTH7jcnmzvqrdjFjQ 2OPdDJY6kLLfwKa0YquJ0fxYLomLHe2hkmdkmYwh47sMd5YvaTooA368upmraEZDvn2yr8K9PWXN 7T8amVcYAxYEvL2QJlmv4lFfc2ogHbk1S09rXn90K/n8+l+aSkCw29LMp2s6kuaDCTx/2rizAzPS C7eWzguRcZYGtVPVxe//BVlXUj9ilAgODAkdoT2e91lu6Ktg2jRhOlmT1aVlHmRXitBc4HxR1iyu asXu6HJgE8EZN1fdUaedPjrAuTmTdzb0+2oegca/uHISHg1L8QeFTUQzZjb4gAVFb+FcproAVVX1 Wm5srKmAPaAMQuHJo/hvfx7J14KdggnsdhpATNpYvZN55EsEQ7GNYBcja/6l5+333IP5gNhk8S14 NM2bNUeEPNXdQuwZz6p76+zUecWj3ZK6R4VjjgCjGiMtwdkW6URsQySc2UklvtE6kE7jQT4QJ2fJ Xx6C+N76IFlsasEMswKQrZty4hHKvAxP6LPqEmivQTqLphPkEeSuBQ0/lRq3Q7WSeXBuWYFvs3tw ClZSefgFl3yzvWJMSGCBXBepd+8IhhMmSYdQICA84Tu1Ve3G8R4CEN9qpjFO2bpyeK0t6PG8YncM An3H89yqNxYs4sDcvuKEc/EFB8SjkFeb+MdQWjX2jC2R0nxf8RYL2MqnH0z5TIieP/k3Q17iT4cB WA0Lp832hWWNOUfrkIZvYKwlIyAHA0QGCzhHDhXt8wJF5NBMdtdJGvCiGijRYaJuPa0Rea9sLThJ EBU01ED9nUP5fVLCBnmPpN2ZMX47+q+AKJ5/qLO7ouvpEu27ccWpxeUfVaQ1EFbNACt+FZHiAF7d KHX/2sbFLG+E4iwfXVVSAj23W3GON+asmxReqaWQFEZR+UadOY+OoU9dwdPvPc2XsIc3EY6qCs8v y/Bjd/q8C97stD+PD0/vgeVh5DPTvVLkqAT4WpMF5+nS6k05tU+uEeG2g6Jmmdd5wAVaRarJ/1pQ b1L+eNJe8TIZc1yjjlUNy/ijvtO1XzWie4obMIhcXI4wbR3MtQPfKtirhQN3KG2C1+hYdaTWfU2T tSpTlMQyfqatmlgasVF2flrOBDfH+qFcSWphGplMLcy/aqbkB8aDiBFVUhH4tt0O/mgG0YD8L68r MUDtBvXhcOOW7eTIsSHCvd7YkGO5gPMnTHF1+czxuGH/4Q9l338A3NUCtnLM4NJH/dVUaksNEgc3 BcAsEqQNkuocW3qL7Ft8EbS1py8+evu4Dqul+MRqK9sS0aBDVpY+03iiFDnC3ucV0aBtpoOTycVu ByNsxLrT6OTGZWiMNeowOAuui4rrEj+PM6vNZou/Ml7DurcQA3rmIF0oMAzgW3V8EOGg7a89jMnA Vn4BNNMzhfIRehciyJ99wHOro1durqcnxZ13W1Wph/QCqBQWFacSbv4PpSsB7g1+EOBL86xdgCC1 hc5nXudjtzkoMH4CXKRhVDoIbB0sVGNagjegazyJfscszxHAvSU2evorv3fHpIZx6CCvwn6JTP1c gLSjBfvbwDKhMP5OEGq4WBUdK5H28lIMbnGxoBTCb21AoUM/OO3MQLaPKMSsBs6OH4D/Zq2fxjTZ i90UYnWyIMX+K67E1+3J2/dfDRE3jQwxhe4i6klrHTkg2aJG9hAV7Zdn9My9ORATrg8cFdnIE15W 1gATj20nLg6UaOrNJ193/nv3CdQKIRom5y1asy8iIIChoiBQVFMsphKgTRQff6fv8Jx5hOP8j7kE 6RrAyJWCApUtt+HfQBIdDd0stqsRVsUfpbzxFYWN0FDR87f94Fi7i9G69AaTPXfZf0G1AjwnxgIg qofZk4YysdFPDw4LmNkTk3sqLZdTC4t3y0qVWLKNFkqqAS996IbIiD1Ya9xUHSeGr4H9ydhiqZem CzhaN3wPHQf2y1kQ5Mw5DMg7ZADK7sNpcVi+/TLs6lx2AaDP61/06ijlWdzo0tPKMwlOtfU8Ycpv 4rR8dphXJEU/zdNmHErCHjTtNBId2tXJlwvL1kwIYxTi3cD87BLkaER4/P0lACnAtuPp3hKckCd9 ZPffd6G4QuaZZhJcd9JLk9H1qE0tMzMbrfHFZKnYxovS8Fq3TvV0+nS85AQld4r902Z12dnZK5cR W947Ia56clPcnuuB2iyFSaOChZlx1/FqRfXzfOHFqIsi2M2n/HdZ9t59vkEAB0vOb3zCL1m+iG4F gT43JIoDSXPSySvAE1li19MBlT86M2H0EiEGSvebj8TwbrTJ4rGR5KqIRO4OrRCL7lyLcW25o54D EmAe6KcIX3Agky1SDxbr9FMmZ3GDxXLzFfX57dwU4c1c7Nqrh31fT9zx6BOnYs48AE88AOxX/gHr QjTg7J0OqcQJIxwFVAxV3BRsdeErp/8cQuy312EcD0De7PaABqgXKfHsRoXQYNt+mOMKlC0ex0Ko pnfmA13wZl8AZ77wkFpwCQQSbhlb3MQT/NkSkQRrTkxQT9OFnfpFNuaN9iGSaaHxgLdoDERpDWeH q+6YfoWknRgqWOntD0GzY5uWinU4j4Lbs6sCRf33Cr/NncsGuls5AjRyWYXVWASZLyPUUgKrjdPE hSNuK3aG4kmsc/ZZu2zO9hGBlBTbwOW6l8ldxDN5qD59cGXG4n8mIErjCayhm+RGFHt4wvGZJN/f SHIjeTq63zmVFjvGXUBahWhcKuNlyjFAndkgAQXGaSzVvLYVIBJ5KgmzNnmSZsqezc1PVC53UA4K CWSL9rTwCT6RXDFegKmN9fchqE4QT0+JNnOZuCIN5dxdBAs3qxty6BMOLdBdDo1A0BnhmeqSfCLh 763B2Ls342bL5caxqBwhs5VpW0ZJQm5JXZLk6nxHO8G1ck5jpVBWjkE8QqKdbIfuYzy/26ATDNnL LICEW9J25rSxn2SMMoZftOVqc7F3xh8PMHvJ2dV8e95YU7LprqrDja/H8+DsRIU02UjTFwhRKZQ3 mfD/PGtabSbg9c1wRmUphxxO89i5itxLqOHc6/ua8i2Li2sccy9j68iiOCpeEjl5a0AbV2dhQfe3 3tCt+f9FkTA32kJuTffPeA6DjULOb4IwDfNjziDan1z5kfU5/qwr5xnCZ+3E5QdQ3560LYAl/XFE Y+7UwLSGSMAF4YwSi2KQffQBqaLIctl3NP87UQqr+OEgpZicy+yWkmYeltgXwdc8WONwrJVHk86K gwNNn3P1k6Mru2tpnWyNsf9N7g603QEfkU+AZdurAyCuvHF1rMt7nTcyEgeBMmAFLMeA1Xr1TuT7 e2lPHX3zU2lCEquBoNOBcehSgGcQePjj1O+Euy6WrEHQcL6tm3KqW2T5tCVer04aO5T0MyX+5WEf wHbOLn4vtyjvwsSztHVrr0HEUHHZ+CaHvQM8kW2MLBseDkTP4GIGn0CytlFHsc6uxIjEeKBC4QDx MUYrGo58r8BL9HsjZQkYzVj0Tel6MTaUDCZtQKZkgbZmLbBhG9E18ekIJTnibSCBTBLyDvMGPTQc azUERjGfU3+1A+I4Z9WplL6Z8nu7toA5E/7mIkU+8udjo6Yk35SIFlcmh9JWVwwjT+2/iBLSZSnk x7HK52yDuifxt0t9wuv3TXQvQBDUupvFqwVZCM4MwHlBiLN0dIt3z1upchUkfy/7GCU2Ib6cJqUN J8rkm8wJPBCYlOQP76FA1ysbqaJXFZUeyt4F0ERk3uINflRM2SvhfINaXNxb3BEpDfZpkxtTRJX5 XngLli08umbq+uYReoAtb/0zEqWiGC8PxLLo+K74kqR5kt+lR8kKxOWgpIxsBV7iuj9b+Qp5Y5pu nLZnnsNjmCcZYjyoQEHp/iLxDjconHchPXFAe0k25PLJFyUKtiHGJhd6C1OBPIrq1I8nvzBHiUZw ZfWMSCH+etjI5R4LTys4zpwCv+dwTVu5Tfr9bOo7m1uMtTefllClbaUryvoXiT4fQwqePvQjhCfq G9cNMuGrhPk0WDZXJnFO8JUUcjBZWnj2//GA+KT+LJnk0QGahh/XhYlfAtOKBrd4vFm4Ya6GtF09 Lk42PFw7ux5OMgpfblJPXYOdAyjOozf+wiTqxoVGqK4WpuKrCDF9t075vl+LOwaKV4ERkrBUIggI KG9L+WOtpRgctF5+JtKYAAQV8WsqpRfMvj4odj4TSpyW12jX8fA3BX7Ila6zSOMmHekb2l7WAgoi mrME9WtS91xgheMv6YxS3APEwuPHU9X1Rr8cc2pTu3Mt+JD4A8iTuPXjPGVk44lW1e1VdyRkYbgv Uf7WM3nuGayGHp0fE4SPvAnDiYPpnxPzphyV7otqLb6dAlxyc2Per2HMeif+Y4cngSAxHy5Qzqpc 8OJdRLnRmTLdLSvSW16aqxLXtqEiCfyAzYcxu/3WU8hdjUAPbDvHHzvELvIeYCMksaMdcQHAIym+ EYMcmRNEkuEm+HnCC5JSuoT5UPq9n8G+zbzh9pZUtImnLNmmRF8eiDafC4Oi06JhotHxpmIr/Kcr TV8XTrbs7cGtcybXvCmLqTfDJKUY1tgJsjiLoySOisn58KOeWvHZCQc5Eo9T8Ttc0W/UJuWitSBk RDrOdG7zoaodYH6UcHbpdb7HE+aQtq98m1avlfHehaaU7wNG/b/TBPu49bpLQp1w/isngEdotYLb 0WRh6uasqj06NIwuba8TVtbx2QXK0f2vICC/RCu8Rfvojc3S/IkB7ObF72AkStcV92G/R1rJkBm2 O5PBsvN38yfl00/AD7Irmos9TVWN5qQsBrchQNIRIFpWcLnFrsZhHBkpPW7PDNWo0Y8B0LLwtLZD F0LOzeaHz5u28tjCFs36IUARWaZXYdwdqDArLNvx4xSly3M7Q5Yk40l9pOr0dcHI1X46Es+Evlxw gO942LAC/OA+chcg7rXEOZid5SZq7rhIpWMMGdP5M5+ngaokOzsNINdTeZ6hgsydj9x+YCo9z47w Pv1NwNaKJGvXzO5+XbnkGMivWmMSK8qlQCTsF5pIv+/0KS2YiwBcnTwXRMC99KaHEXWzWOhFm4X5 aunJJmMbfHFPAEeiuXn2JZi2+z0jYCKjSoyaWCS9TnzyiWJSj43komTXObo2a2O1R8IaL90DyWgo KMGOQ/pBVFyJf/QnTuQ0qUUn4x6/VY5eMTN3cwOc3dE8tD50avx/xOHUCR4HNe8Tb9acqlZf04lw 0ny8SjKxkpCisOUJQFWuH21vA+4TsZtpoibMl4OZZCpTgii/AJWM5MQ57ZIFKClxVudJOt/vXEKt zIfwlZWpKqSDm88yQZtuXHO0CKoW8N0hZaZKT5qqi+CdJ3OO6sbuAoek7ID66Th1/Cv5vw2OxdDJ n99SzsRMMv4fmm6ZDPIIi4vi4QhM6JgW2NYpLrzdbzHehkrWwr7Q+0A7JycYtfSx1FqVyguz3eCl NHKNWQVaxwrrEWpnEVH5+py0M5mlAK3rIOTGBOwijOtXlchcRe9S4Ld2FyAgHcz63rkfb/YeNEYW 1E98KuKCn0R4jXQFmeHDpIlgigXkKkFb3++meAN/ESUejDJnHbEHvLvotxmTULrKkv8kWGWhOasT 5C5/eH1c96wEJC+UdEWAjwH8DqZo+lENYgrhSd19MUIaF5IriQKRJaxRNSng50TolZXilZijikWu G9jaU/j3imeju6qaxwFHPFMIs9U5jybSyHn9q/MFCRw3vscr6Pqj0ZB6UBT0ETNcl9yWkzfDl+N1 8g3xbINggwug0qqDR95WwrcTdNDuOCyReitILh5eLhqDl6FmGBtZPLrOQKI4w833y41ML5mbS7X9 7V8eIdKjcSS30ZHmkFpEH1bQJTckpsFRJF+Iq10YfBt3rZ4bOKcTyDKpVlqNJwXdQRvdU+wk1PLr QiQ+BlPD2IBlR+mnQEje54rN+qwtz3UIMd/yTMVHHrTzWYTTVjb/rZahJEiBDAGv9RqM036/gBGy +tkfZlMi6UkPvK12NokRHDgunJmbMqLu6XstcddWXApnTRUeoP8bkPESE/09FOKxMmkE3i0t1ino q7n7D1d02SSfQPL3zEOp7p5XklC+cBSFdeCY8MIStg3PzcPznusmDWdHStQhVCF2GmqhM7+h/Sic ze6F6YIpswhZ2q6Gf9LTQlFsn12Fgz3yM9a/DpQ60pnBXY0xYLZQ2OB13upxwp4JEbmXs7z0NF3F pYbu3Qo4zHD7ehquFYJZQ1g7hJ+giYa7mJLlDAtWuAs4Ra2Ax8tfRxg2r2/Yqmf9f/oQ0w1BYBpF RrKRVXFZjF963oLAtKaEiQ7z2l/A+H+OeP/k2SP6gIPvc9/ECEGlqxJ/ppigxJ94rkX+xAhpujuY m5nrjHMQcu+1dkBo4rjxIUR6MgRUc28bwF+429HAz8NpI3znxasJXKhhJwNWC1sXz+fscEh+F3Eq QPFBMRZu03Tat7e/nVCAJvLHs2FAoZT2BuiFByLfXuUkfwvpyMUzBUQHK1F9xP5G0LZz+37jZABv KYNVzIdnX7RobNkpmEEinoQcckbDHcHsDZ9sraCPZH0d8fzwUvnrTPsmPNHNh+QBO4LoHXFlmbnB w34lmY4T5ITGEUmg78Nxyfr+e+MziA4R2yX0q+sb2or2pYPM9f6FT2aSem3n3CED/CZKpS6c+WtV JiECZyXct/4YUxrOWnJWPTLXQb9+E3XcAA30e9hvT3VhXwiftL+UH3Xfjv/5r+KCppmodHCZDMPO 6iwTQWQpLbATlfwgauv2277LKmkYhMUSapqeZK10eG+d7aJPYt7l9FuW2gmnfi2vx/j6M7Fxr+9D sH9FCvvEZcyzu+MnNdTB6JgCv/Iwlw76FjQQbUv7VZt0pK0M5oLr4h8SsQOXscx00rbwPXphLNxT tl6guzGlckiybezxymvGOoyh1wb9WLpTNdl0s5rZcIDoR3fNgF1WGrR8J9zAs7f0HSBkUyt/Q8nP HBq4zI2IMKHdY5ssUUaFY6mM1uJUpQ5J3jRmlZgSa0kj2XUvkQtsVDQNjpuZbM0MhuTxklVbTmvV OQ0aE2dd8dz5ozys+MRyHEY2dQDbXw3VHcAhCghyg4WJzZkrwiIyFkBt/NmI02piakunupSz+KcC FotDNxmPjszBplhnYyBnMsO+ncUBXW/nGOlyswhpSH5dFZyBywfjdXpH93xrQZqm5/9YHanKDrOU muOoGEQOalPZDBfmkshSHGfZnjdHK5eGb+3ZqdPhDyWyrLibuRR3E6d2SOJKKMv4d6z0MqEv8hsQ MKbo/HvuFDjtid8QxunS0oQNDXpEozCm0/0ZF7agcjuokeU+N6t8pVUpCqTaLiIO6Vsxfcyae2UV qSKzrGNbEtQ6LK22KbYZor9teIiApDHdZgcJOqWme09RD5Tjb75uSxrd3ajXMeH0v5D1Gt17ZhRr L+IjLNsy7aHBrzYZhtANs5YNFi6mRW+VczqzmHDRX3W9If9e3ECa/GjZU5g5zo9CLpsCEvwdaHx1 DoLE5oD0wv9lw/LUiFM3MxuGzBeCSGfHPtNjB8cwZwscyPxWKslh91G4WSFd1PhKQclQcCVrzbNN ppOj5eztsOq6DHfWqnrB2YiClmdtxil8AeMOgl3Yq4hEXX10q9KA6o1A6ri3lVXMnOhMG49pbHAL jS8MuEOp8lRiQUqWb2aHWjQmpyuoRJfrX0PDT99pFzmDKs2Mk7IwyWzoLBphvUFZuXTBjHCmKCBW kRLdYRNaUIWog3ks2tc7tfJmhuW3FnEtLzh43VK809AT6H3a7Np1ikjsL7aoOU14EZzcOTwPa+6t m1le7bDH+f0T0BBMkIPznvLjLaYEr1ItxI33WTC3aOKRT7HZW6m0URWXfdkDf2Jb9i9PMgETZgB9 CmKwYynSPx6zTdd72dE9USkSh8WcBPBhtmPxxah722AxI0sX3C8vEd0smH2zh174Qrgzx2UWFlGo CEYwpMv3go632dtWApHh/CoPmdSZzCKnN3sbaBg24vTVukiQO851hubBizmshiBVD49SPHzfAJTl 6YhrcJv3NoRymZR+nlmhI6YsBoOBRLZ7dtOUs/i08vHDSm/WJ2LI+Qof1NiKxh5LFp7hDPhQ5Rtr plhzC4TzNYsTi+YFFLCCiFGsJmS46WvljDtEkWl8L5q/euO40NBAAQSfDuOk6WtCw1hmXF+TxnN2 u7NPKHblj7PwUQZHjokxookXdNOa0tilqxONjK5ZbCy2yMOtL50yGoWp8rhq4Hy3dt1lEFUV0TIg clDjcxllkhZMZPhhts3GHODxOiNW8gBcTPdZxPddTd3eRRr13J5kuAEwvevIBFKCN3YOFwQOlmNq aWgtGo3mA38PEBeyab45urJQazBIepmY1GlD7Um1ZIKDvz2fXFDEagXtMyItfPYZxwcXIk3UwUvz oXM0Fs5URBc4jFz/AoMRtMg7YjognUkSpCN23ZRgS3xqWAZOBoeAKnbW4WqJEdGdrfTfFBSLHM2x CiC8QqxXs5mQzp4ZVyvf2Jk1mAdNVwzQnP8T249fH73Fy0hFwGq2YWh0c4jsOqhEiA7osga2nGK7 QDDDDwL92bWITZeALBm6IDI0TrrFrZ5ZbOQP3ILwXsupG4PFyhrrOm3Q2YgHpAwPOj1vauYHmpno QjhLiuhIcwD4+X4yktwgK1xgkWo+hN7pn+3wHL1JQqA6amba+20TUFMlCFCAi2FYF/34gclU+ijk UsKFU10TPfSn1Gqq2B6VeU13RrdjJXBPKKU6zIqCHnaky8/yyvf7YbQKXbTCJQSHMbH/FVavtprp PWJlxFUi6bZ2kTQj9M8DGkcLkC/5vWUxe46CqZHuXydfbJDW7m5lkLqO8H9fOqLt74JkFPip3jQ/ pFJNuPK0DtztH9ziJojg1LGiF5H4MbD7Ep9maykcwoqcJEdT5J22so1zPl8FiX9YBc7LNW6xEZL5 uq9lpXK8IR7ONQK0o1LErakrcPVO1Mr8wBj4FsEAjc/Vpc1LogXbOXHHi4mOb6iOjs72rgvPEscF xlHHUYoV9ESyc4drBG6r9meLxwFzz+Ef1PNtGqZ0HAFEQHrVk+dHpG9g7VrpN23PX8Y448daNzZe 7rpXjZMHMu9s/PEmM3kTk6J/GkIX+LFLCpFSflU3cAVg0StPvlUtNbg2/H5VwaosIJFLgrcO+bvQ jdMUz2Y54EI2Ww+KNTuPonU/ODH4liX2wTfuqXSFU31ftyLUCQELjWHzVg2tN8ZaI+y0zWT933dw d4almlc6k/SmWosAjoy1X99wisIlzzuCx8wEuYvJTJzBWdSu2x3eEt6HJGeVhlfGzIMCkj8MmgpM ITigpNP74slJrBC48Iq4IMyP1jIjXRpf0kUGoVd4JwwTIeRBq2jGF45qIZ8Lp9bciwLJHSbqKyUV DC/oNynOre/iIObkdANK5UhJ380OB7JCNFDa5xGasdLbvuxn/mPYd3Dd/BFNdH3mMJTD19wfbc+p 9TXxKBLkBrTOT7XGnwcsxdAzb5sMVmQki/slsgpQHAocS5sLhHoJVHdw3+fPKBFb1R0CPvHgqn+C mOnxQzWlyKyMU16gFoUWbFg4+ZHy5LRCI7VxiIbU5xV223TBLtE0Zok2ypbCQfADclWDQWyciHyF kHCR+cV/RnnBYivxHPtM93UgQholsSlNGoGmI88sGM6dWTo0fT+3dldLHrGOnLtG1x8VPTPj4dPq fZh3GyMmAZU+BOO/q/kieVTe3homgiNW4qh4yZLDLa3dnJt7sdPI9wsJcjLXRaS1lupVWo9JGTSO FEBvdSxPA0suEfbDvoG8GVyr8EREEqnHthVh7laS3XLmsJcsLDBMU+W5Jjn80MYoUH8aYnLxXOcX GtadY9fTQckz8382k9tW6Apybf7JRi7bU8Miu9Mx41v6Xu3fLh42x84Q17PEBuPupGtxEMDTyB0A /Ebr1EcIcjFD1XwdMY2IsYxrDRgKg1VmRIdbWQcmx9pVRx25mD+Z3THmCSTI0c7kJ62l9AySBpqy o9cKovlHE4SnGlAj4GkGgIPsOFt642FUBlmAb0bMZNOTqNp2c5D10X8qPkh+0aJZS6pwrji0CEEX MfO31aEv2hNjuM1AUlvqeYlgO47YrV/y14nLJhPeS060zO8rUPHJQ1VkGKTu8V+ubp2UcWfThm1B ZyIM9axTZej5hIp9zWspG8EGWKCwit+lq2vK6AWt6tv153xSQFyb8So5OOGyYvqC8Dj+xUVm40pG IrNt8QvH1CMdw6rtpKwAbpz2DWV/QO8pfWwQUHDQnNtPWp0sHW9R0yJNWEY0U/JR9Rt3rQAJQPa/ AILT0/OR2tY1FpHgzRKPwoiMxPL7GANNb7OFJh8JXme/QoP4LTV7Rw8vdOkxAkkZzw5h1ScMNILB l8z+lnkZluwLlgG8p0KYRzL8uPkJ5xk1djrqnshlQSvHonktevGdeREaO9jECLtFsMrSQxox2Glc zxnBvljw6npBsDSmEOOV7kx98R4pzZEWCD58u+lRKPssiqYY0MEl1mgcumuN7y7JjnohGiIMF3AX /uqpPC+oNRPfF6htk/h2Adlo0BAiFUC7OtH1Z7Sy5o1mEAhZc5HqBo0AYG/ROW9P+wtnf7+mfQl9 x94yEnX+VsL8c4FX0bXHNKXNQ4fKYYJShk4yOVuQXcQnA8II4m+Vg91qT8p60VhfRuA9R42X1soG Uj03gcZHZsmkVn0VyMiZAlxJ+GMGP7cW7Hiq8ua81mXRSfkdTUYhBBCHbnRjvy7gEPhzBA3txb/Y QP4fgzRxDWKG3WacCKVCr5Q0+j7X7e/etqkTiVgn/EZdMveKKd2mG0G/4gnGWtm7+339zzH+V2fa ue21sDbQN+0V2inlK9L/n1RmKdeiWAQqoc91q0AeWbcckW8t8IKzYSHwWb1AfiGFoPpwPP3JAWJv 7Lf3gGU8H3rECq6GJAbXldlHjZz5+7+Er6eegIkLsr6Akd0QgK418O7CUbEUOSzB69wGPmITllCr 07/kjUA1+MPEN3oiPizEFfAi06x6idVZdEdVdyVzyDxegq1ZAV6ECz/6WPoWk+CTr+PgUN+2EuYL Zs+CuEq3BfEFHQg5d3m+mGXvp+M07mW4NxjItkFtEiVwy4U7GxwE8gS6OXEVEHDFan4lQG0n4Zqp zZFXQj5lSWOGw37XbGKNBnzmPheaBRCWH5vhAJtvqF7WpH6a3STkzaXhmSje5lD0hyW750/ly7yy E0SuVAYx3nJaR175PNRQrQ/RRthyKhfv4iRz2Xpzs2UuR+SFUCrD9cTh+F5Bq4EVUNFpWK6I+mQT IAIpbox2BURsWlZPYmrRdttUycpT+Hw8nzdpaJIl67/KoqXh5DQin2theeU8E58yks09qVBwTAye BdJJgm0F2t87UJBvFiSafG97KGAU/b5Co6zbpqWI+fhB8rLL68H2QiP3NcWsgbzwbc0hOqWKBNoQ dkfocC9CpXlN0qgV4x7/SJqcIELz0fgBZ5b/bvcF9Fl4mwuEJsSW4X3LfxK0tJ6w+6AjbHiBzmT2 u89Hx04ne4/yOinkVHBlA8mBQPM7jiHcxBArtFdvJ5WKumaxi5CGox0oabvvkHKN2n1ppzzB0SNr yjMLCiQl1HENDc4G24Wv/y9ikk84gc49+w25gSKPMELqhqaHRU2Fgy/bG0fRI8gpWbKJuciZ+axX 0VBQuVvOIFClSbQ5PLiLvSC68MFk+Zw06I7SIdZ1oFg+wzTQCshrXVW+9oQaU7D6IipJDtsKAc6D vgNJkbKjmFXiLbrUvRgzb1g1nFGiWvkw4A3ErvL+u/OdWu5yT8bUfJnvPCMVzeDXnRVnOhfiiK1f zp6l2c+czZba8/jobbvR9WS/qLTIxSFxiR44tszrHCZOGVJT69mYsipYw5mfNfbuZXHB61hcZG6I oKnsd0CIk51UIBFOumFxUgowpyEug35QnfFU79sIRAEQYvW0fj8ijwDrs8eNe9JoEQAIYbpitsfQ 4y/X2Lst6rFbfViEX3wDd9avSdPKt2mfG33CEoh6nkP0U3Gq7kzr5kcGemn0NXmPr6HipDqrbMiQ vsZNKHiBSmfDldZx5Yy0048j9Klvze/UjmzNV/NF8lFo/0pQv4YfSOPj7TvXS0YS8uBz7qdzNM4F K4GPfdNIBFKTEu/y+XLL+RiB3PtrknKkRfmwrsQaSU+UBewtiMWZd3TEPpqgqXepQn+UVASQ4QK3 vCHQG796euxDwASYL4DWzPZ+mJU36iNCwlJEBkUXi/T4/Fqiw32gT49FB5cKUukCqnmDlPoUd64N be7P+NgcZq/rC2ZI1HFmhMRP25s9bMj2OeiOPeUCUxl5N8LMm9ZnMachxOHURUXtQ9VC129RIfNE 6IFqm3RjV+35lhfKUdQWUgl8vVtpSjWW8UDXnpmFkj7qk/hSReY4Da6ClpggDMDUnAb3AJeJ/KpE 0VPiu5U7q0+8Cngv1JCLIi53Jip2VBuyWRrsw/a8hsDrV531oAOXkAApQAkV8aGD58lvk5AUZPoL nADR4QBl2qlaNnYW1X5vEuuO1NiEGAjKcb7uSxanI2PI6PQzbcMNwgHj1fL5O3abs+P5pAbiHZQo LPAX6fOIIelVm/YpwQmxQOQZXZFxsy4Pb7e3SlHKFWSgKdtKDpSTYodDGYz4rAnxtG49to4kRbBV QyIKhmXEOB2MMl4M8VcBgzFhvADgedn1azHmsLgI0NHCI3g9IUsgbxZyrqM0YdUz34ymqvznmyXG 3v7pteUMyI/kAt6CdPRROlh8pTmjnFIxJVmGkJ/2RfTFUGILjKsy23tN9FakSAdkFGCv+t4GEcY0 qbiv0HPMdJQLNYxOrXCR4RWEYX6T8GQkNL6SZH9WS8du6F5D6WyP6ndFp3FaR3DniULvAxY2G2gM dCG08JQK5GPQjMDEPjgoozr0FUVafMib280MqARAyn+Z1vLu1KYR4SU+8LVJ/feeHmjtlnz1obC1 Db+ZTsiJaa2TgyG2gRiq4a3XGItSqiQx8ckxERqyelBbS8W+r2UxgsQaQWpANe69L1vTm/dU4lNW 8uuSbyqFmtHjvKBTXhcYHyiL6xRoOgSINtvUCQjOYjQMnAFFS63cMJszNo4iCN0swBxT+bLUWc54 o+bcF4eII8azucruH/A44ZjFqxZ43XlM6vLM2vWOnY77J9uldJc+xvlxFm7eAND789xPPReU7M7K lXvgw2jQ+1FxCsRMWQ2nGelHEemH5xs4X7qMyiiHbgqP2LbsQp0q1ah+hQyp2eVGME916EOaay8z kRAhF6MrVJIdUxKe4ihgd1UYWoTPDeFV7dSGmz/jXqi4rVVFKZIxUDYWfaQnLcFmJaMesata7HpB 25abguLrmFAL5JzeTes1FeSafld4Af80EtzwNdhU5l+1QXtqPmqt56rJj1wlj6BJZ/nUZfHqR76p Oo9A0lIK7IHyhGhM9fj9ZFhcogHR0shmJuwuyEIkWcHQdktMI08By0V6li2Xq6fhWJy17Y+2reV9 4daO0kjjNjoXaQuUSwXdjy1tCET8djBdSe+Ixi41bYqoGZ26s2KJCOyh256ov21MHk/YGF8Lwbop oDoAzUEaN9R10evrKa+nXzpt3TcxcyEi2VreJC5YQeXFcu8t6MpjemoeEmynS3T6MjhL1zBA0Hui JREVEKQTWODOf+eKOqATnhcfhJ8lSllywF9CvOp+1u2HxUBKKhWL1W53nRxeC+H12LLL8cAur+T/ oCe6QTq5/gm7PQusCjSVBN+T5ZCt4kH2sMdOxSiUnXnTJabQWI0rX5saASKy35h/rxhfb0QH/fFz vWF7bVelVs0QBbL/clZ+xBN6BLVMTeQ77TZ+B9d9jdpUhNsJN/GtYp0gIsqOwqX3YuQ44F7ruuDQ 500cO0KtbRpH8L6eKKA3tACmRxqEe//VRKPkOx8htafKnO70FS0eyr6wuChQNSwSz6BUN70BIRq/ HsFuefE9L2rR6Tyi4CkU6rpnkF6N1UVKQSwTVGDQyi4vC+b6Dxu9/zrISxGVDU1gOkY/44gv2FY6 fD834vCDLOoF8RjmqowsoQgQ6KEnEyxvZfdgvDoFmoUxumssDwU2pt1t4zQkpcpfhbGiu+0V3i9L /1V8B/3cE+nQJqNPbu6YW7qOPcvqP1k2YNC+Aso60BHzO1RmG6JuuiUp6kVxP4EUpY4iJS0L1XMu Ee6IksNyHV0NchnY+CyOXMRziYLcUNoTECb9C/S7LY25X0Lo+Qtu8Eh5q3pQa0aZGA17zm/TXOKI kAKlY68Q2tUxxFAOPtjFpoTpFhua2VUQXW605eIIEDN7jM2Ao+9H7fsM4ZyqAJTYxBsevXpMDgeL SLjdfdtZ9eEEiWE/2ruzK+b5QPelz9ONr6A7XZzsAjGnpeROf1QMNoZejsw+2zF2CnmahlisXgCH vwSiTByYz/e/NWwa/YtZYMM8y9VrTX4WvNQXs89cxZjzy0i7CtW2fgHplNjm1bphKpLfr5iWe7WN rF6R8TvbVGT3LRXs0PkFV45sD+sAMxxbSIf9SrRAKJbKfVcwRXhhgzn14SPpVAwMr04lcigNXzH0 //u1QNW66I9tS8CneN656z3WnH5KAIoVAVBydBzURdnJFcy1nW1C7AIZ05Ik9g0IerfR6WJkmHq7 2LDUGHil9BaGUsLEwPnRIMPIrUZ4LDHFdFzaqEFk2WULPRLLm6OoGslz4wMXg1yc/MS4aHbctsJg m0VbKeY50TK5lTqoKAAHfc3NKhwyEpR8FbeEFGXAMBTUJukg/8KFKzAQHJZRR2qFndaHwYlEa45p 8SWL5x01FgP4/LWwhgIkxauCwchpfspYt59lCkzx1Ar86WwevwAaFPI9NIEjCIXitMelX3T+syYa OrUHbVQ1swTWrfiaX6/bEA3ly6RMl+isYSFqsEycwOWJjdpLzyvcqRLsiJBMNi0UTZcC+J/7/Xu6 UnxC0GCMlnuMjoWDhmKkhu3xhDMct6huikZIXpQqUohaS5cBqgPk7Nz3LyvjxxSTn5sCHboW4WAK wvusl2KjbO2tJDeXCr8SNnHPqvfV8dmaY0zYXPg3iCUAFNGPjtsSUnF8bqftaXq8ze7De9Yw5HIb 356GcNxWF4krQeu4GQt8icFKchqj4E100QUml4uDpurR/7EKt1Y3Jmgg4+DZs+8PFZCuj+UfRXpX VJBe+mHHVmVKQb2SHRq/60sGlPYCJRHfkpDXEzp1i1hDMasz6ViJWoRNU7rbHEot9CyP8/f2FOkY I2V1ZuPfidAOT8S9B1RtxwauyR/WnoX/TDJnhmIhk/ujvh4Hst2cvTEWrEYM2ah5UObNi7yySB39 Y0cVe/dwfB1JAQe0CSsdZxzvjF5SU5DNj3MV3d08d64sARqoIxeQy1jhs354P+yjw+DDvM9Jrfr5 LZGv+Qh3qPLf3zwABYYLtktiOipkWxiOzGtox9ZMRd53ovXtvO3HrRd81BQVuvhj5nn3zoNqjfbU YWoAMWAyhD6+3tligpdn9lirMdlvJNfwutqh9zqJre37yKRJ1N8+qT4MVsUFFWUB3pZAiaQ1TWn5 0G7cfLTnTKgJhS0089+R+K9GTJbbWSxyBoLw9Q6Os2l3kjjuH26cDFC3YCRtU+Sf/2LFWDpp5xps JFNr5Ft+MYBRFVnvTR3JIRaKwkAtzLp/V9cnk7lfqfCucNlfj8YUq5x8YCcVyANvWGJTO9DWWEY4 ythIXA0u+jt0FC/8DtWbFBKQXJ3BEoZHOrIeXHZ5ppapSrTyweerNoHj3ZGJRs1VDhGDrQXv/g7/ QVBFb4s7I6vG3MG30Fn3SoUy7kgBRd+5nbwxT1/SmBEuxcDQFMfZyrMahdXCLQw6sH21ZZKTwjho QwhZIr7jS7IlXIggb0pQgRpUd74SlocKtmxqW6bMvgF5VXtA7Lt9aJVHCb5nQwcavymqkBptvDzv 2k0vxkAN8qyEbM7AWXXv8XUUraFrxOLNClm5eLoCihlUBCepnpCURAfFSGEpMbT5cAOa6CYfgEkS Pr4K/fk02vBOvPuy3WHihzcnHEstQhcy1kK4/vKqyt3utDvgCV9GOpOoDfpv898jrPpKHZxyp9tK 1DhY34CK34KQCFpSfGE/6NIi8U1ChtDoqJRMdnK22WZeXHRXkUHDHpqPRugOwpA8er621MG333Bi +KFmNbHT7qAHlS+FKkNwVSZi+lhRG0Y57jkcPsAFzvl+OhH4jXMM/9JWkqAazUC7Pe/6v6WFZtUS IXxgsDXq0K49XAT4NEJZy2wON89yvOBVmC2xlsr6NmIwY4sTSZfclkMElAYwWPxRwP3kscTAyVaw WYJaaiih+kUa9bSHBHdC+018aaQPvuu92VyFpL59BTWeQpbUCdtsPOhpTpRWHbVCFbQzd1P9dhcl kxA7yrwZXwd6vXYFsqyKlk4/3YUlgRztrJcs/A6uDnrmR8Ojirafh3oDC2t9b+NHjyRKEYOteNQt Fj3V/mIb1vuGYsEy63Dm3EhUEJprNzB6OSOuhY+7cA7IVv+kAS7KY2R4XvWYpondJCJcCxKb+NA6 PElA0ZXn/kp7p7vXPCumxGuFu0yPPWGa2h79wbV9Ih3fTsRGr2gt+91pHXi4aqkITpeEjCDXPlOz xvhOVDV8eHsxas1IMnMkVby6l2TSHfl5Dya8ZebZ6G3NUUkssJSz/pX3wfklLTrNdljbqu8dBu3q NUTkZ0y74higOOdrcP3xOBvXFvzqSyZJ1mRoJWPsOXpUiuSA+ixbil0AGapX3y1fo4WSnGRQKn7H ILEFn5RXIDeWAN2/BHjbN3sOM0WBWSMAWITGGdHxhxV1GO61WWt3ziEUvp4Xks0V4bwMuauViMe0 lbU++nX/msvzt/l4mMcFDPsU9QxqQV3KodXHLTFSQEf1IILiFuzxTElC77NB48HFq9YDTJYlDLD4 VLYUePZSVP+8A39cKX3HlCb2VCt0voa6cSlsZlFd9o8JGImyZHUe6OzfgPZkIRiEnJSjNJ+W/atW iP/62iiVqQymPVhDJyTaxw6g4hf1Nfx3/ttlqAjochgYVXF+63VUoE0N8yfD8In6cE7TUaowz1GN mcH4HSUckLUxMoGRaL6BsYNn2ixObl/OidE+nDlMuYVojzAxvdNHCUAfnwqn1b55YCOcAeqrZA3o K+hnNWwnrrfolRI6h0isqnDXVO/41FCCKvRhP9Vk8zKg2Zv3YTEHhGrwVrsDM5e2w717L+y3Ce+N JUZuS1vw+KEC24keP017FMChznt1UA7twl5u3M4hXcxGI+WpXaY6JCzlHb7BzK/LDVjqnK3zHBKB 8Zh59SvLA1NK67xCmJEigQJPSiTtYoW/DEC7dhq/bLGMNa/LcLu1xVXU3MSZRyzcUEChRaNbPAAD 2/c4qOgt71/Hvdu8tn5JwFXA0Uc1NqWTgbVgSRUI8hXSYSJXSTx0fP30T7D1eITeUcWiOulSn4U8 BJJREDBmX182J5aPDoQtUYTtbrJXlUsGzwL/qvicKX+5+lvQdzAmIPIxWX0dcFVv/U2UVfDvaImH TybevSqrrEZGEgcmWVMtltcy1HbvUH7LCwje6UOkPcJSu6uH6r7XnzcWKqpfTPHb5YaGM6umB/Zn hCdu6mcS3Vxs7WB479e063xL/+yJ3UnUVMbodE3X7WyFvjmlmdOlxEoapDu+lmBYWyQc8wPevJLO 8joG/k34nd/gKPzQb9YR+A+M6GcnPHw3mSGwHfQQZXU9lk9D9ppFuu/yyr4Ue5sruRx0qaCwWw7j kD3jiNC4LvK9bq5QqRjj9vRKpJ1vlTwBeurzBO7awqEpySTIq/BDZWrAKYlsASbb2oOrYFDK0SG2 pR8N35mXtVsCHr+B3Uqwx/tFG5gOzorXRdqLKMumrmDDbd0YZK7e7jm2Bpiha/TiR6eJGcY5Pwj0 i+M3v7tjKkvoRTK5efgNESytbOqDVgAguciCoOw9T8Z8tS6amcVZPnHFke9XvWMDroF7zIax1bhd SqEByxYAaJEOogoNtb96zeTRjZGdvggNpUD2q+hsDmObB5fKb8gF7QRgw0x93n5AcuDmlWCJOgAP T7VWxgM5knAHm2EAbiHHLFyyd6iKkKN5PgqvlwvWGy3mn0wOnSQgYgAg4AStPZUwxMVDglWXWRGw bsYBHpQ16NTiPRhAJEjLrhVox4LJOxIp81nJ6AufOCYvw6Wl1oFhzB820258JC1BxjTr6Up8RCTw wkkMTRJWSP0MzQj1JmkE1hi9icgtKNONILIHURZ9t2wU8nDhY2gkBDlkTIvhx0Gi389DNC2V30ft kv/hf5/NI9FFZqNNgH0lkav3L9BkpukoQQJCSCKPhoLoUg7FdDMsl6LxQ88kcjMufsPeidYg1KSa vQRPWBQuhtc0LpQzXbgHEOb3/djefzjQqGITrwopWPm71CR9EdaOs0IObv3NgICSwf2ZaPdh1b+w 7CJUxCel4V7XiW7oyHqIItRKeOVKfx4Wvp6I4daPNM6eZqrssCu8dXLG+qbGTTkHBAHC8VFV8vP+ xYHVqktiF2ckhVQfGpUp49R6r7gKc6sCeLzf5Jjbf44ZzTW/Kb6wotBhQENcndqcBygpJurAFwXG iu3xzY86zhghUpOHY5L9aZ81YDGa+FzEQaUk6gwDHheEfcQgPUtmw2pqrHZXMrr97ZjDGSXnc3XQ wAMd/RBE83GLGBpSKlmdRghoqpIUF81BojcrDEsOjnj+3hQaRC6E1xfe+J1vzJ/z9OyQURqGDDp+ h0/8bR4aBd4WmaI6wBxWe4zizNuOMlWevy9MDNYSexnSAxnHhXOw/Ygfm2gcA7G7e2/7EJc2T9Wk Ijsr/kyU1FacAdo9p8kbAgnEV4GdRbL0bo6rWUXAFpNOLOaPHyX6ojKoDVMqc02/kpn0rbEdIW9w K143C1alFAEeEcfLus5PpGsY1JB7EMcVFRRcukTR+JJ3GC5j8MBV8pGrKMHwZPknvGxEeUy3XrBd WPV3utSilS3W+fs8Bj3a+CF/o889m26VFJ3mdGcMZQVoQw61yCzA5iOrgLpvk4AZvxO3chIpq5zQ i+HF2Z7Gub1ode8ZkSsqPDFKYM2AK01gRAUbNOJ0/Vh62CItEk1ost7bNDD8giBZTL70wDmHOFuU jYeZ4TycOpUekVAwqE/VTxl4bBkP4svzKwTbTHmaPrzhSUC13/NWj8DFQg/3m/A/2VSXV+mGIlzi 2xQiEsXX0WAjL/C0+uJjxF5CrzBQ8tJ8zaPYWnqiz29BfxBG3QylhZJuP7qwO4v4/mO2WGFfjUjD s+oXJVcv/gnHPRW9d3K4Da3bNstN+gO2lftjTgZJelJ2hAgVpn3H3i6dgB5L+IrOAyfetTLDNqke ukq02mlHac3inMbH6QnFbO402hq1TQZMr+Jtt0F6Z6RJWX0nQ9K55Ic7j70gisWBC4/Mwm8uV6T6 TLoeuADMz+ybO+IPElPuGI/AkjdXutdZaQELHfmjry3P2JGo8JJypwoJEJjFNZ3Z2ejl6aZkyoz8 XrHQH7dPBuOvbEc4Y2TYEagb7a9ItnQwI7W7LgWRieXmLCeygJWQqGkeN0C4aUa5A1Vz5pQS+2DO BTb95q5woX0Ha2is27wHEkTaLlrTPOUoVzcwVoTW+EjOdm+EagfuUuV47T4kiOJzCrR3dkm+9+Lw OxsU/OU6FWgZEqmp7cqJ85KWFLEZNsSjWeV/9KBrdmNeFL0yC9VfAbTiUroVzEFacjHJ+LFN7uoC VV0lJYbYPK/5DH/UOB+IYPLp0aNW1OHhMo+4IimT0/w+gv79Xtdq4GAmgXDU/rf/uYdsXZui5bKj fvIy4Dp4OHkuTYoSzzGRSxPRNrFKQhpeYs2eml815/g0p5pFAdaEy/TBcYHyHyuSV3dWkuQ3uvZ7 jmfBUPX2sRaCrJQfzK9VewI19S8qXp+gLHbimYD1uYDoeD7xQ0DvbZAgPXa4FmB2G7hMc6+EBzGD k5+pNr5o1A4jXYfhUQ44Chp/9qYTj5v6Xr01JWy9bIC1v+nEGZKSutz0+hyA92q+4o+qUvKxwcBp a5ruRcQDzRFihi7zK8qIujTfAJxmiK0mIkuI+pnrwMBATezP9vjSogoAx9/WYu2fmAzlMbya1mcS Na/H2ECKLWLL+zVT8IIpzNKvGJAItLO1yOr4yf2VkK0WvWBGErbo8/NIKIAEmt5HBEJ54fyAuQu7 35hDYDXUJrXcwKI4e8Vq/u7vvr0XwX0e5wEj42xQiAihvntE34B0cpl2sm1vhhgEkBWS3f+sAoZF YGa71aW3PBJEZDo35AwNuJkZsioWVVx3Re556iLy5LdojeRU1hKf4AgB1/2Op/Vh8aUZxPxo6TQM 77EYxOElcbIm9K+V7ghdL9imoOIwUCkdkr0GwAXBaqaez/lOoyai68hG5oeIRqFMY7xYWdfyFUAK 3KbAgJEOfJfzfCg7OmT9r1/jZWe9/BJSDISqb7ktYMD34LNkxdzxjUF8wvHvvxF/Jgl0emCj4luK E68pncKRGWMZvfzRRGkxyQ7TcVndqdhfWmXxUFdADO559arIpRGOsrH4/0k2I95H2JzbifQ0wfvi GF7dDOlZ2kNuK4p/Jx6s48prLNs/q9lnbmJeL27cy1B0zs+8NcGP/PdXs7LfhNjsudioMtrJ/FcN VZlYFZQ0ToakbsoLb5XWdlwZk3/9Y6vOe0ouwEz9HuKaKZBxDOZLU8KOMWivE0fxXY4/reMeLRfQ jfeG/Nh0x2HBmK8LObMvBgAjR0cSSV0biYOfNR3uaMPtQ4BNsT5fh2txI17fkcDxNL7fhXxiroBl ARlCeAtaa29y3+sAAoNTcaIR1qIFLGZBpznNI1frD4dTjoPDeEnBFE6vviE+LnOO4szVHGG42AeS n6b/hh1huyssNwTJs9WVq7ZQBWrml4P5D0yjw1tHNPtpS/dqUgEXQ78Jjuxo9s4vLuWyHCMtg3cF qAJLVl5wpna0k2nbwk7DuxOhhWzqKRF28l2b7ZmrbI7NUUTQez5lAwRgb453581l3JJvkQO/+W3I sg87wFyx/eBJY2V/d5f5DNMlWz+BhQ4mpsEIxu1JNFRsnPamD0gF9EPab4e8B2i/YGUiELcnr/4S E+Nyz7vWSbUdgeJCTTmn995pox77s3/K/OADiWw4ON1FQGJUzRwyenz2dQiphZQA9o4bMXPKR/Kz SqDWJovIz0Hc1gT8mBX2zU+KJ2BWC+4bePrQ/X5U5FwhbCRlGD3FpMrWfd9u4UZs5wfjFBQTE9XU QOzUbaKRbJ9BOmdgnD7aQJ2IB+P2VqxG4I6qkisPFWm2RViCwbD64xDP3xWHg+l8quI+GHL7mfOv KoMnPeCE4fizyi/WFN5yQ2n6D0EEsG6vodclUMhNgTBIyeJAPSsofZZzG7py3anbPnSQH/1MuvxX oN/Tps/obTYHBkdLjlCv0p1HU2m2Yj0Y2XX0PXlBAePi7z6ElW/p2A3Vw6dVH9q59IOZXosOWYEJ fpwVrxql1CNNi1UHY556ZU2tvNO1JeztBWB+RM5z92y/m8DV5EoXqP5ic5ENEp1OpQKgQ/wA781R ZG00yBh5K9DIJMZgGrQ8ihlO0CFRMLE1KNCkrHDpB92b1Actl/ofO3Q3Xu1ie8RdWAXl2CSudr52 +thGNIwIAanL4CbmrccDfRJV0rW9QscZZ8W6C2B5xX5dARC8HvHK7JXX5FCPOqYoayOauDTz04re mc3dIGnrMsow0o7a3raZqVMJHJmC77VeuyUZ3ex2K6SyZN5Jd0lvLyCFQ4kJUI2JfaLVH2g/OiKj 2MZcevqWL3fH0q4nIzc5Ohz8P6WMRmhAowM7N2LvvUjRADeyZr5iVMMJyMQTfY/n914cnZxUfYUf zzRou+pvXl4wEUKT4d1bQAyObNhcJwJS6YRloJ6MpPJQdEirKTkqOIRPD1XJhIlRGLn1iNHfEujA wQUQzRO/2VCZAjj89lR8o6sXgYaF7NWs3iLqE3Iah+h0Q1cfSNL8oaax0BJbj5AfagQgFPoZQ8Ar QSwG+BeqHjcpFLT38M1P2SEIXg6tJ18+ZF6AsaD63AdxnTCSAYTqCWEZv5XqHDBxoWP9H944e+D6 oe1s86zIF8YDXsRZ2vtCGIh/aLLT0ybp2Atc/dI6puxylk0T85j1bbnpc2NRzV3zBvmMIe+G13wr 9OaAvg5WvSQNMP3xDkGd2UHvs5PMMHDSzVoEwbee/vXagMhfMBIYTmCVp2GCWtRSScBf2/relUO7 jhCT2yzIoY7ornSrM8NWCSNjcHCSqj4AMFkVrL/MyDGFOI5SOybmlv2h/JHMVOs7lEo1wnLgtjDw eplZPhk9FGGHXeXSgKiVrAXuHxYF8TfJ5dfY2vNN5ABK4eU44tVVTOOZsTGfAtJIMzv6wy8voyRT rOu24xWF/Z1mMGFHoCt4XFu2t46TgypErJSOTRdtMRPuolWzoAx4m81df9zfBjp2ezMBQQ4D0iMf +nAFscHL2mjMoZ9TVs9pFbk7390ZyiRuI3mP27Y1spvasNjJb1xKVUdCnTQj7kZKzwaUApPgqWdd TumYse8SCfCdLgfZwUhKe0z8/9ZHdZDcuLRwVHvoP/Kcb/AdczISmRsLqDAVsxhUOhUD8TdJ83Hc 113cbgnMS7JgZx/LBd5y5MDXi7vcui7o1qAPbZ1ZAgIwRpsY/owsjMZvSoOO72wMXPaRk3pyK3Pp b8W3NmkU+AgpZ77LJkU/DOlZmhA5clF0cu1PrEKnvQEfEz3pkTYY92BrP1RDF+gdLFBbyBDfjhM7 JK7iDbBdtNNpfZb+XcO9cbuDJgF9zNOdLzreatufEbtS9MZA0BLb3iV/vgGycLxfPtqMQ9eAsK2k 399rKzwua5nAsnL/xKYWqhXEFgbeM2A5xcsgbKUo6yv3OmQHYgZ6H8uoX8lMwQL07d/ggGWJciEu /5fmmd0b1JQ8NSLfXlurQHx7A7v7dg/p1cWoSVTMTXScEaDGgpYCFsY5RZl/Qp6N475PeWQwYXfF kQQehgpvGo9ANd0LPEzQVfoIqShVKbrBu5poX2DNbuoO/38QLYA0w0onrtTeFsg9fl7RVtbjfYH7 73HLjgbcTq+u7ZY4qEQ9MX4lyCPIKuuSaLn/v7qHHBDajp2+BDUbkCYmMW/iWCC9Hbtbu4Z0FUmt /2UWsvufc/DOmn+mMa+QTPGz2yks+Lz6nRntpLSGTBBbbh6lkTEwvVvtr98PwG2KTaRyvq8AArUr lsGjfLjTbLTaOKJLTzFu/9cKllOzaslWBb19iMNAdpjG37qkY8ZEilvMo6b5tgudZETzSmn/8KZi mzREyxeq5u/yIaoJjj3UwS3bVKXLTnyXUO+N3Lv98rIn+QYn9bcKuVA0zfWPKzP5tqNQBZQqLipY b9TSxrnQa6Wb+RUqtjmIsucGqnM4Azt9cYihgmMtdHZdsIJDWidLseT16xOINXj6oP3oO3NGDfHc XxKjzFNx194wwoA+siXnuEButC4s3ip8e/1D/htZjujGkdWL3gSDKHK+uM/7n/k713Y/hiurS+CB Njdu6snkGE7RxLYHfGgCxIsKkzzyGRYSJ2mKUb3fqjef7sIchC8xVA5kJHdUb6q4b9pdSbFOFLZk dJXPUPquG0VlHEjOSKjdg0m8pB+tGHwRrZ1TGZ7I9N6qKp0FFetNQqKyYF4pvWJ530N980zVoPOm d4NfOQ9Df6LPtaJHale2VKI3O+BtM4+WDntQaWHDIE+PLTKXUbYxKOrZAH2eiMbyJtgFeQLzVqiR a18iwv2vaP4YUNDwjE71HvtQEe6Dua2Loc9XUqlT3PEX35xHwGq6mRrgjycsEN2EjWUQG5IRZouT UsuITP5VkJnA3/za3+ga27Nrl2LoWL3ejvL4At4+TUiEzKcRE7rWdoJIBiPlb4RHVKp3st8vob64 wLCOym5yjbmngXvq84QFmnQqj1SvuanupAlGgUyyJbF3LQOOP2BAz0Q+gu1uHKE/4S16bm6zJ3qY b6pKhpn29Dj8u3WIehgkc4oU8o3cDC4WXHrfOkzrKmH6B3W4HBrfkSgwk8NpAZ5Ofa7GAvfy73os aVj3l+ons/U6cFx2TOr62t3s0kFpRln9sfpZwUvkYGVSM+U4LTLKG/WijnVqT1f0IIFv6V9uloCe /MrkWLO/CtE91XxcskWx7vyeSGa/2J+exXaxA+Ih0u2me6DWWWOFV83GSo77e+pzL7nNhbKyQS45 0EnF5cVS+lkx1Z4wCrw4Sbx2hBNeAqzKA1ticOSCov2LX4JhzvkX2nDAbCVNf+TH/pz4d62xJQs5 PBIYqSXl4L6qTY+RqppXHvcNyP5LNeFdxlLEj+tk+W2YjLBT5dFLpPMEEjHvzid67rCPJW3Mo+XS EqfXGINm4tVxYGhHz5qDCMZ3fxkxN0KLJet2PnDpfWUrAibmVLrzLE2S3WuNlMxmPOsfiSEgB9JS e310FExwDEU3UMqUUvXFbbWpyuPnH+foMv0PC9a2EgqM661WqUShh4MDfrBCW8hOYd8w3WTAy3+z FXhp7nf2NA2dbavafHleEHCtwZ4/ua3uYiF9k8O6191xpqtOWHxAA1foWO81Ipi/y2aeEG1/fOvs WqOLuBWIYBdiyjqElmYtqzgwb3Z8q6S6IHHlP9NnexQ9/VKog0asIXdIOq0aeN4MW5EIyU245SXZ SmaCDXoOCErwD7B3UDp1G0kG4fb6ZHIm5XXulv3UJvtkoqqsA6qqAUC6PkvTEuXD44dwOD3aB3mC kWcrJ9sPwUFiEWWBC8fBY5lCWhluEh0UaSpozmniFQeyPEAcNot2ZfxcAGTHH4QRWPccdfbo0U9N SmQhIC9im02ElX1IRk67qaJx/ykvdr0kM7O7Tel1IWHj4QrYHAyOAMlnGRdTlBI3Fdt+6XzD81ab TCApF4DA2O1Y/MUdi8DSs+4+0mFNNvifGtJt3AYoWgzcullPGpcZiLzxCZt7wmiJbCfVFZLihwfo 9rs/bmOraF1Xv79DpO02zvGeh6+ttLlyxSm7iISe8Fc0mFH8htPiG1JcGkZGSzxKFoKPEmdqoBJL 7EP0x+pFoFQk4j30aWNSMoGK7fbHwwnmWr8ITJHE05uSrwYEj/nfQy4V2INPGabTFYyk2XYPPy0v nq0RQPSVtOxqBXvdHwmYeDbd7GWChV/+E5g+H5QcaNmghfoCoiySqg6jTKVGmv95wQGtaRKT4sHq CLCowzF7vnnMSdg3KJZowVn9s9Z9IYQ2ZhgHrQyASyTisk85VUXmM08nXfRYuBo3rSxBJNcdKA7T z3JV+bNuWE1GBJ9S9StythLusvZxUesvFLmCu7uXQLbJKELWI8TIoVVnSLD5hiPnPvFKhfKvIOrt kkBWi4SZJCv69VhYNUu/5BrA/af80l6H9zP6jDqwelwZmlIrYXR6+vCK1t2MX6W3eohMnPI2sJAu iMrBiAu6ULbVF+DPQvda+1bTObtV/Jqfd4+Yc+SQAGT8UBmZ93bBouU3+QQIgyideGatT3DNyP0u Dzc7jubhipgJU4/7GWgeTMVbGx9Xic7yYEDSHf0QtQZ6uf0u81vCfG2KMq2KLRQA32+T2y7tA1zG ggWxXNbXrFVP3oG8MkMHmfsMWbejCVXdvJrKHg0Cyin1UzUvYtTkAOzqpd3mWNFHYTiaPQNq1KTI iB48LFahzKqIAN2l1YcSGAktyaElHULNcty23leiHrgJ00ZZ11AasS0A0C6DAEREtGRc55WM39TX hXKTAIJWOuLC+DPrJSOgfsb0IuN2hq1zf86SvEslhbJ8ePs0xXA4eiKKjcLUmye6lhrImveOJ5Oc z7/ep//SbhJrS6cujAMd7ULneYV6/fs+LV+L1Sq9d9UFEE1qo4CDiqj5ODXb9B+OM/wDbh/QrJyD 9IHkX+UIxQwV+QrcKj+/heuHnZG8nEGsA4jZsAKKJ2lrr7YOfit8yAGm7x7By4/b4yJH+XAlKURV tnpTVpklqjNV05JX5t7ng2IkgLNVBH6Wzaz88h51fLV5kPEcJc12f6dnjI37EjfmonSrrKCBGsO2 4uzyty+KhlMmnnr7FB8GrFvU1+882EunBWdhfnKPdu2Cgej0SlYCXAyJjiLzCci5sIBVCEwKPYKb vmTo1vls8/HT/zoexozrduQCqQBc/GM7LkyllQI8BGyI111+26cuFp7wciBSPmQoZ0HZCJ4R8nyQ jrH5tdcOETVj2p0xvRpiKxqiX9qRgEXBCebUGvqesHSwgJuhMvx/6/F3LXMCVBTWKk1cpeyiEr7k 4O35Q/+XaLu5oVb/hQtUiBl2sYM5S3WCiLVg6CKC/8k0/dxkJY4efENpOFiD7sCvXRdtL+p10+vK HxLKz2QwhJb6OHbYmpRSFrUmtXqZu5zp/zOfn5w5lJIC0mttNrFcHnP799ywoK19NkcAE/HIMdUs ndGuQdOJxZmCM2WLxVzvFg7aT4+CV8fxBfpIEb0rLKZNGZonaMN4SgMlW51e46CxM+ae2qkRU9Kw Tu2oi+ZQD6r5R8d6gDaD3UtWQUB1GSP/pA+T68/JKd1+i3b9bxrhvP4klP9fLnyYuS1Dp0KXWydA a6sJ/cQejuc8LHmyxGriVJ+rYXdc/J0MvZ0WFw3ktIqBoQ0qEvjiWYdpx5ptJLC/zXArhh6jOO0D Jc8//9rQNC57EseouJh5vx+CNUNN2ePctBit6+1boBcNLPnWpOqfjh5ZzwRlE88QFB0ncMOlCsC8 TeUS/oz1KRN2ZATKmqiDSLqJ/0eUgeyGtOR4lSx8AsiJ4bZtZUm3slKeFm+kcYss0XkzE6DcSYoG efuy/YKkLjts2mvEBDa1JPLTdwi5R/GVOd62FaO5XHPS4XWSjSJ8MT1aVNNGNr4p/ZhFetkDYuWd S7NXXxdZxvL7oyFB6TcO+57M8b3TGakdpPrFAANZiJPGaRNp4nOPD40h/vef5PNlIjmxFCk9Cv4P MbrsacYGsYU4R/fzMF6yuzqlxyzy/1GIbzS0qhCBO+yYQU4V/fMlPe2k8NMXTrf/YNuXMytdtZfX Ppsu+ub/n0wY2m00aMnvgc/hCgtPXAiQGDFEkVr9yemJqkY6ijgk3ycnwf2pIsnBwQV9M0mq0Jd9 10a3i304BZCcI7x9sXuTa1le14GN5qnYrBhm0q/y30S8WrxT04DY44HDPHsUVM3VOtYzJqp0FB3q Uj5ybKgsAlIZmrUXlybhqIp3XW0sCnClEo/RO6N9cgyLtIVZAvIzapv+VKJUyokC4kvERyQwSHMN BQszRKHtPUUke4vMMN168XfUgv+MsBTdi2nJxYnDRFF7AO2lQXVy29lpW7mbi9SgBMNr2UE/b1uC ztBx+YaHbLtFAs3Dz922q0JyBxWsRfoyDywso+mUm4FqFm52n9C0wyp6iDGm1Gyh8lCz5xb6NtB8 bbOEgu3Jm0603m6t5XvIJzXomF7RKnpDtrigzwCotyBPetVldz9x+GxfgpavO26li+5KHFCmInkT 8JPMHLPkDQLxeaRQqcbh1eBBP7WYGSvRtOPYQ7Gpz+Bem2p3G+7lSp/1U8cZgqBG3w398ZSzFUJe 6vH/lhavkJ4dtZRWB8EQSeG7qxdLpBZrwM6N+e+eZEE6zVb8wdCVU5C4+U/uAeakPxfp1pAzQ1Hn AKAPVF9KOnOMg4qLNgaY+uLS8spm7dPEHYQHuKn4IveSaM3E3xJM7xgaw5KxVozcEmSYQizg/qf4 YDhIVsdXwJxKMSz9jIt+aOTT80TSuTr7b6jbSfEf6Wwmoh5COccGzhGciBkRsxpOyTT2D00p2YHg Op62XfZ6VD3ULSebundxXGaoz/SHmwtiyD14qZtEZT3hqUcmLS1nFBKZLC/DXgcLEoiIPEl0wJ/y iE3eQyUQHXu3nrUWurzhzxl/8cIOFr1NMWCfOyoqfsqr9bqD+dctdy3E/vNcOknaktuF0FGs4HWH X0KfW2k7gN3XTNiCIxtnSpsVTBqcopW7/HDSSvIreUtKOyfh+o4pixFTzZkRxYOlmFqjJ2Ojnjxs 7n1ZDf+Y5tiUzzvNzX6sYcI7pTT5HMZS4mGG7oLHmkXTMXfhFyhViKFLzurKvwQF8Lb/GX4Ysesi ztOOTEBVq9WITL/9JcxQEg8I0yKAlYpgyVArOiytGj42c/TGfk+/f7tMK30VqKLhLPp/pQitqV+F 47h6guNGkQhBLhscJDR8v0BdOu+x6KTVTkTXuFwMdq7ZucZXJsROOiGlTwSaf1U3g5BqHztrP0vH yMgCqa7BOWGkzaQSWuPodoXjNk8AjqLHvPUxbin0WjKw5WKAZLbV/5f73ujV8PKcQDR0TIf2lyRm bwPGwIQXxGJpuvqHRH6xiBCfBPpeapLAWwU2kudxaAvluYaSWIJWOmBvv7XTlfJvQLeWc5+/xyuh Z3wfTnQ6NR70KHhmwZQT3DvJzewReI6bc393CEKhGblqUOfNSv2hsINbzrZtM9OeE/ptYmOPGYrI zpEhs8CcDoA/4VAq9WNa6iO5lDMETuuMFHn5W0Jpz3irX5cnO1sZRLebji/z+o4eU6gxDMAnPG6U YToB4cseDGxRY2qamRgMxIo2L03f/Akd2l4r7IUxet0l7UWWWfteu0ZfGfSsG/eSB1AP/9qhwcgK Yj2XE/Eh4HpqwUZ8ZPEzXCdCelpPcmKaDq7EKlBJUi+NohWx3yDbNULDY5mGnXvOGKtUTi6zw50Z lh/zVOXu2PXr7zsk1njN88zJBjar+VVAkHjyapiViRU/KSQKn3WoEj4h+t7gc9uPNFbEp4XueWB7 2QzYhDOkOJyIiRRRMngbXid63MW09m9NWaX8z/AyR3mLQm0c6ekl5n/PCR3ggyXwWVz5jt49bo2a jM+mh2vuHLi5/RsGXLM7/4pyYwnhdiRWQ0Os5CaIM68jcVr6Zv19BTd3+FrhaujgGM6xS6dSS8Qx Kt0Ypi5hXWseaz0nSPu8mDwrJy4gRPbjkhxSQBnvuCIVQ29hkRw3Vx5x1zuMBj4PhQMpInmaIFbg e6bEfHErqYAShliu89pG9KHikFpVKbzRYM7ZPRySP21LoNrkM//kPpmZw9irZlS2heB6QZjY+z8G 4OMkyHxrUHXzK3LJHf3DiPnDO+UGQ9OICONIK/mzV2PS427tHYUcBPQpj1KhJ/tkyQjyVA1aSpxn BhLbIQlH7qezuYlL3so0pmbtahncY2zrxs87sOpGW9TGLq6II4/dPvfMoNdlOlYYeLokalPbE0Tn 48tIXX98CsViNjLWjPU7ux6mkQ3+tvKdU3AIZnrKIzqs/UA365sxOIqe5vFWpgBMuWtgLrLmHuuz NgivKuIf+fss2nz+M5ld5Z3zpTAySzP8bGt4f/PX6QuUK4CtP55o8vBMhguvqbPTLEKT7Qb6fZ8h ZUIIqmAhFhGZ9n/Hdp8dW+Z1JKnc5pFzHOlUu7yTcp6uJk9+cYWzMy+vweQAfO4brcJqkU+phi3A /p8EgtkvpZFUS8vRSci+K5XhLwCXMXNXp7IYr1HxMWUV8v9X9NYUJGqCmxGMkIxUoUvMZbOILBXg BnDhJb6t89ROH6oFgR0M1p9p5AOe8I4/4MUBPPoG8cAUqIIfgCFLqMIp9sPkomZbACQNoVKGrZOj 4yDDEiBeXNo9mgHQQTipxxkfuTwfvgLJoflJNRA6OdyPVRGeiH5YIVtQB/DUOzBXE/xcwG0rkKwe iFd7secyetUGmFLhd4XQ7v3Pgu7JfoRmDxmMHoWJwEX6eeSx2TuWQ1Wi2HlqhSXUAsZ4761hYWgi BusDZr3XkTY/9TYp96k/mI+yye1mcmacaYYXJ6hDNpTYqW1LoHZuAsu9wpKKZSqrYuqWD4csV5ke lUxWn+7QMG5ZcK8dRWi9heDS71Et5/MAZmZJxwS5ZnenOWSy0OeE065KO8JnRAYfd/3KKYg/Gbbl 27Gp2RLVenm+p3o0k75NFTBSuhpnOhR24RTzBix/ohckjE3TQ2viaeTAOjzr6CGJox2kJIwW/mUy JioLEc4eqWZtgm5yYxYrmIJVDvPjAkAzRjzkgAGUQtzfCgFSr9HHGTMGXQ/an+R8DtXiYfz+8tyh gex/MGb9du234+APYm7QsasI4C3DHyK3ybKq0Ogrh1HrLjxJ9sTGhL0YwHQvA9/2zeiVAYg4d22G 9Hw75r5us8/TX+YlMK2ZEFDgL8p7JDMhFROwHSVSravyS1m1vzggtFFurDonUQmpzfue8MvEmW5A 7CWh+qhxemssLKE2+KyTnZzUp4D9RnYd2hrcwXAxRlDXueLzfFbvUeyIGYuo7yZo+boteW9jGBKw 0WHzpWpVidVt28WxQUL3XJ5ZBjDPt12AtO6N+3u0sKu67ZGdBTZWawl4zAhKWDJ+WVMM4UD6y0WG DJbyGPs1dPNPwjX4aTISNaFrraGkARgL79LVA5ZMCD3eYvfungrmrbS0iuhUYppgf/u+FSGJWQeQ nOwa6NM5nldO/kDtp3pNGcNcSvDNmKmV6YS8FYnTNSgQOUFIw6S4RzLvzOsfO/lzMZjuxdqa4VPI lMJg2cEfkx25KXp3H+DU5Y9wxCAy+y4CWGYC5BA5ByAHpK3qp6Ctit2KzbyUV0NauxBm0Q573/bO 1ECghchoUlTRIaq6DQZaF1oRYt/gMCYFjTy2RXysk/cl4Rb2RvlxtwQmiQ0xR5IrIqh+OIzhOxtW 3mrxTPKtJey3j5iFpTEyb8rmx7SeGTZaNEMnqXGJqm1A6F+5HlHZI82g16Z/iyJH+n+RuGnY1oaf X/fxDgYuxn7By6aF6cUwZGiG77uI7oADQ2944Qt7NDZfz/fYsJvbWwaSuv/01j7t4EBWGIrX/aol KHUGOrgrh8KobZlXCpNRobmsvDgK6KJV91NQN6BcsY3bHzrpA4on/zpxgXh7cHWgv56Rpg2QAva2 NXME2aCVq3SyCzKVyNu8JgQUTpSIHwiZTYj3n3XQSSR/w0w6eIon+bbcsyX1KGBEPJyeQ3rhWuZs GAnb54AwJuBgT/N7+QKgjLchPpWEMVUUE/+e4biQf9BHHJHcWu+sW7Cprm2OR3NazK1eBh6lJeI8 uQAaOzABHnI+l2is+PPvdP0NWQvweSs3W/KXG5QAwKDDB0kAe7DT6xzNMdAkOmtP+P7uWWDVzv+D dca38ezJWXyh91pNsU48SE/Gzt7w36zvB3oINA6IbUUX19JDjMNyA2aAtwVysDlvlGimfu5bhBjz MOPh2n7ASgBbC4RRx5OglhFRmtzCzSjdn5u3qUI6mtGTVTNOmK4fW/XPxtPHDg0txnb9Pjt9YSQ4 2cXqdNhQPx+b6efk2gDQLK7++yyczu+yG74XeFWN2+1WamNwIBWjlxTsNiGQWwKOzFR3U4CZxf9E KILpGq3qLsgGX6696ZTXZhIoLBBcKNpzFPW3XlQWSjWRLeiof/EctEarEzE05zSi2G1eIf/obWr/ VhXzVjG9Ov8Bhzpz1hhCy75qYcUS4xi9HiM9J4wm2/xXGck/FztH+faTczYOab9PQBWJOVshgUEa TvHMEKeH2iLXoWskXCAvMkBu0OziAYEF2VgRas7mI4gMTKhvybIFe+/pQaIl6f3NqPobR43QspTN n49CnUrv+X7iBBIvuaXBUZESMQ470S7nNmbg7LOGElRqmx+EbajmFMoPSm/HF2vyIeQEkooEVbFu BrNvQGI9yYyP7nIbK631mSkOAMR42033nsMzQhQFp8Fv01P0RRc6hiAaD076wtxo2Gb49L9CRG3Z Si+ebOeEy8l7NIuYcdxBytrEczNRh2XotEPYtDPN+W5D7mJ90NoM2tuTwFpVnmntTjRg6V1HqX4i aaZdROuZsvFpLmgrSBKBzpz+mVCzx2KNvTNaSemH5sNfO5zZmXZUtUA+xRf71eRCEN8IYKZHbbk7 rvO5Vj/3xH5wkRQ4E+JUZ/c0aEf5Op6qj5QPXxdR53UnaEKUxdZn6tKuR1/VsYAyOga3xxgb9uzx L4mtfOJOKaUXFEWKOP57SRG4PsiRXnsp/1oCBqz2FfZj9K7HhKqVYeqB4BC4H7B3fUJgoirFc8Mo hXZ/52daYLYa4j1UfyQfHkfqHNkp+ZSy5goC6rT+XlcD2twvRKBz1EA+GOFXzxrCrQZ/5UFsj3OX VBBY6PRuI8HOy6l/eSiF78ybcnDcUF1NcTOVax9jgr/JPe25U5BoQbMu2LZt27Zt2zZ227Zt27Zt 27tt292zz3/PxD0xM+/zcr8VuTIrV2pVvlRFYirPdd4J60yIloZSPBd4zbZbQwDjuYPxInqUvSy0 6/2Q8z5R5YpaSOYH/orrCfLTuwRAZIWbqXwufvqKmLMJcchSv0IrsSnw6+Pzo9Jm74AXVgf+lstg tJIxpwjR3NEySQeMa7/l4HsIgKFfaoj3hadeh8e1xLvzEjh5MoMbRephwB+M3di5RomSPRH7xdv7 3dmI4ckJBK5pjI55crCUH0Ki1mtWPA7lLj9brFXvV9U+d6IUN+pYhY7GjJsJ08TSC9ko56pkD6NF MJXza8db+B3rNcmDc7O82IaemgxdT1suUMzss9s1E+GyvM4shnSox8MetWptzP3aByihE71Ekqza y2AdCGRBKZYbSHORvQ/R8TSyEjWj722K9z7rUcoxiNSk+VeXtwdL8qH68D2sNrr5r1s/ED/ArQUA wUDHmHPYaCa0knIs+15M/ji2hH1OgxNq5YHkjNYGBnULLisxMEpfIzdZh6SqfE0/vRlluDkggmrz OC8wLvUifQ9K5PZ/sQrFODLd4dTcJY2N/8ZKVVLyiSynwpx4Yw1qS5Kg3nlThrlBF6xyTs+oaepP V1OAVwHl4HiOt1uqNGZ/VVApIQog32+lC37U4K8hBW8uu0l36zq48hq+5NAC5j6KhkE7TzrynH7e NJeuIARd14UJ2dwqvs0x5vPllqDHGN8faXg35VVcQj+ZV8Mv+NpF47WsQpK21a5hOjKro9fqNnwm jreqy7n9WrjP9mnyBKZ6Oa1oZiKLaS4gyGDDyOZ8j2+4xastQeIgwEac8nJ3V1TGeVZc/oGAEmw5 wf78hPJSXrtf/0s0mMgU5y/Y7Lt2VXebsMbPyXBC2aM9uicue51lsHnjM+iRsms/wpFC+0q3cgIb sq+OSsFsg6e+touB2cwWxAQYYMzVc3FcpcSE+xtn1HS107LILd4yJV/JTr+aHfAQa9hSIpKp1p2m CTqNC+pb8IYQMIFG9V1Do21HsksYScS734Keaqga+AT+yIj3dwwm/YPjiHuXeAMzFNWzujJylrDQ BwTLDhXzwM1DXf0mvvAQ1y0g/nAeVW9FcuvLhhCCXg4MAUAURH0Imracg8MP2jAZocDJaShSn6gC S9okXU95ngjpS1xdRT9WPfA4QsvLtU8bOemBnYlBkWZUN3uH63YIz/f+vcNdW5mesaamcnmCdOIA 582gnDNLuch6e28SPeCo8O2LCkWPajL8gpvYl7bbX1MU4XeyfVyNtUX0MHIZnxSbgyhw5gZHW0kZ EVyMBiGEqiJgyuLEF95oyh4DgWjpENoEbIX62EDFqySEutJXOx4cAAu4pz85RnJIO2tocxAmnCWx pIOTiwECCIz+SOrk+/nLvxALjBQ0arCMcYH/acsLq69N+36A8ArXVMi3ElAvcP+dpszexn89y6nv Yb12NP1iiqLRi0EyyOtunrPbosuYNeCl/49YqAd52CpUb42zxc+GtIqd2mTohm5nAmXJ2UEBDnIY PKcZ7rrdHlz/qo39lb/Nnjg2894pxtmjOiQsdTNrm9++1yn2DkJVbUmuxRSGmBpZnvLRnGSUEZRm 1Jwf91TpE5BNWrwsy6/T6cqHyUBxuVHUU2zm0kEwDteOnj+idUGMUF+SjkFKFjaA/HSrJEvvCrAT z5jsWXd2+CQtlM2j4ehAxQ1ch/9N5F+ocZ9kvcNXvG4SJu7o8UdOIEXOzZRQYaQgBkdV5Iay5/tl h4B9F0M54Dtt9lZIkMrS8uLpBsK6Te8jGGIK2x0+C8UBP3u1r0GJ141d7qp5ayvZige6v68ZospG A4Ca+bqsKcnqIpY+5/VtkjnGHB+22NpjZ3C9LpFunT+Si3H0IabUfmC0x1pVInKeGYw1VEIfRF5N 8go80d3hpz1wfioeIoHT8Nqr9mS5sG9kK7Pd4FfIYE7TvG6GrJDY8sBQ1PWbZeyqdfDBonBrDlFF 5dnvELkkrR8LuvEEd8rCJEtBp5vOmF+u13+3NOZdyf2mOA1LOhi2gjgSubh0PbaRNh2VSluIFiIB 2AOEcx+5gC4U4MNT+pyAHvbbpDOePGT1Ev7kOOW8KG4xOWJRxdE3032ZIRJjV8Ab7cIsfPNBtJzX jCpqQvjmn7hdhd9j9d+7NcVSY54H9e8G9adF0zO5rPvxKCkO7akKShG+VRLbnOtUS2Ex+FX8vT9P VzSxQh3351s7cHL1C91GNbUEpDQUnkii0tQLtfI7qk4Uv93ZdFQk2YXffze+hqpNmsfvDRdtDyBi THxniCPEmvGepC0/L0qqS+W5u89m2AmxpIfWLmY1VfDY2WA2iXXjaS3nzv5+UqxqxYPDFDGrsZf+ wac1USb/BDEdHYsWNiZxs8KagH79a9jd0dzknbP8QZzdILmGs1T+hihKT6V6AzqEQtrj6yaN97Mu afTObPFyd1NmAEWrQKn16L3fHovUUrU/SITZpykUMcWb78yjenEZMFdCXIKeUb6Xum3kprHshqZE /uZFDLAkilfYknZIa2waF67bOYwaY+fCPZcWdFc6Ve8EaqAp+PJViENinZqiUOvULJe1dI/Kxqvd 6TMIStS/xNmlUjnHQgnlU7nYLXJ40cJ/hqlP7/JoneRGVN8HldzeTYOS+LGD/u/IbMJtlJ+YtTxW uUcY7mj2STjjxMT7iJzmarc0ygjVmgDhvJnLvp42ubc02mnPqazH8CpSsYzSVgbjuDwcREIQSpi8 YMntWDTVTu9Ci0uFgSO0b3SMi8hPS1p4JsqDDggEo7L2kmDzFbA4icdtIfEtQA3HXtyb9OxuuFVW YRHQQWoCKQQ7UlYhgGm+1LAXH7Ze5u6bnZ4C766J29OovRoatR9N8wJfQihVbGNDBTb4cysribTK cvU1SNUxnsTY4To8Fz4idEYdzRWz55T6wJuPA11P3tm4K83BoeV3JWX1sEsGGUv29Lgz6zPFr4Cp X9Sg383fY+qfAiIeA6QSLRrzKry1tzTb8R2kgqei1WPU1qgYBPfbql5H+kghdyrKOT0hQAkAqf0C DqnvjLlk02BJ98K6RVMe2WcbWcrvMGjlKu8GmXDPkKvb0XWDRejHjZ+dLW+GHaetgy1m5v5p4vso UQ8UU/PO1yPThCzgrdVJL6ALAO4oG8ie/ny9+OeFGJMKI9Fv2bQBNb94oN2owVuiyRIqvVMdaDDq 5/PbSxNcqioFEdBFaZ3T/20o2UMaAyEPSChYW33K21Im33ZkPnx72APe3UHCAFgyZbmjx55EH4KB XFd7Gj/jYFKiwgbQCsLYQMHhGRUdWYQUZAWii7Wjfxx48DM9ZhhpCYJdPUyV61eMEq0wi9Ty4SdX CyeUGC1JCPm8dzynN9nEuCULbrHKbXfwksZ2NuYH3MpHKpcXWtD8hpf/zzXc2sLQ8bT7tugtJvHo vy0PGrunFXkeKLzMen0vw1/OjlVFO8v5nRwazgTojd0qz66EUa8vMov/QyTJWPcBbG/+R1nh1Slq A++CS+d8KpsCnxoHSdHtrnAIxfjWMtkpfHM2utFzc/0EtJlajJkKF3mSqFCOmXmc7dsa+ALrfqKK PsNIdoZxgBqkC+kXZMzzGd1r7ZZf2XVs5IWyepRC8Ubh1/ArNfBbVNRmycbfz3xBBnXjPHlACNr3 WewcGHmzPpBGvL/pTrCRe3sqW26ZZymAGbDGm6MJXiAH/veKXKxtzO4p4Rkvk/6vXcCXujugXb3B SnnHFXar2PROUrA2MfA2TfQqubUmFFDN0aexQjkjtD7kEV0L7d093AKXR49N+F0HmxSDFuutXA8b FOo6OMu5CBmmxK9gPcGlhJJnSOuofNhZukybMxawwHeto+w5ihU+xh9HYaQiOTMIAiVQjFiP7Kgv vt9u+OVXUKZvrchYhnMjitG59vLYChaFxdkMVLLWBNVIz4RVWq+mvzGz8hdpz6aHhH6Cq7+YgG1j /VZFV8El6ceEdqcQfqGkPtT8pqpaGe6we/jZjBMbZG6srPJxyxlynSnfuWyA6Y6IR8eSC6XnMbYz BtAdEvQfbHIjPWyWWu17jORwcE3toaV3ZetRftbnDK6gWIhxfsgQibzRSKOIeu5JnEyVrsylh6+T SSmDfvuTpk1nTyBtJWQtf7xr0z6aVmFq3p2guQGRj+oIZvP3D+XwM7x8hWtXcDt+5t3d4D/IlInU /PIX31vzg7+wggn2iF0rfRJTaK26Y5VkC2hjx52vawMpRt/LG+uMnejQnOpXEtUYwh/Kr7jONb4h 6bLa8CYuJVFSEx9wInoudb/dSiQbBhBqZmhifibNCXMG4W5nfESdlPUzM+tFyytIffrTZInRhXeT 1awSeFGlUYSZ2Ea5ZfbtirgplePB+/4E2vtDoIO8fZlrVrEw4iJkBplsDh8GGQ1wmM0YFY0aoIh4 qwB2dGgneSLGiYd8peAzdGDdSsE7Me89NKMkNmbHUXINF740nSTSFYvHkt486+BZQ8boI7jD6rk3 b3MY8NhalIz47EKYoKxPiHOqwA3xnR383ltmEU7LkR9J3lzJWpU6DvfW1TSnkB5uLMbepfaBtRs4 ASLVMwHpTYCdSbf9ooSpi0uNcR1cqnI3bwSYDigl9bNVIQ7QJQI54lWtuP/1CuzU7hwIrB0avc+C T6LRfrrCF70CBmNXQqkKPNQIlpTCpTGoGSEoEuWGdmRd/9o5ScYVki/CgtTpK+mYma0kr29LoSZB yFd3/EivpFijz/DarC+R1fD8PF5stVLrmzDCil3VxE7NhoIi3Xx5EkXz1AII2B30tcPACeSubO3f pTI8SjcqMY2n1elHaUfO+6RzNFnQYIDsKsev+ZSK2UPh6Eu0v4wHylhUFmLLkj3zfhlKIxWJcHaI IQy8evaJbDl0ufSUFas9c4iI2aLhUuVTq0HvGrmAEkKRVBIS2lX7+aR4ADMix7JAOZfbKZWD3l+s wBCqAzy0m8H1A+eWzvFOkxBIdcXuHDAzsZ6b9Z+QjHhp8Z3gUimBgaSo4uIpUyLPp+NCif17Gh9I ekdd3O71dqXyEisnUTlJf6o0rBUCTF6z+pLQ9M20pbBgFMBeYCxZT8+I9R7OlNRD3QbYTUFJPO9w bjEqWVtX53VSDqmt+aigFhYPq7KzruuB/xQpZkBGJkYnlPAb7/4pNFy1qcAVxnI2LtofoUP74J5u JNGdc8i27Qc+CdSp1B/JwzwRwx3Ou/QisjC5n2TcNmf5Me67QjMt/5kNarKjsYIj1enKjnknrg+3 Z5LRElctDPpCJuEYJTiJgwg4zjJ+5/swhmEjoy+w/egn/6F9nN5SR46DrjGkZxIV8VuWPhLarOJ8 qeq2GbFqHssYY6qH8mhqx3xWnDtSlj//p1w2IXmAGAqoe+D2/my03Sbg0yIfYRtaf0QZXBNLHGhS mrrtLlOHboEslFMfnDZ08FJHa6dqu+bVAgc2ekkbjJG9hryW393M1q2WPl66W+sQQz9MozPNYzSi LM7zxEBB20Vr1P8NY9dfnpjXHShQpjOCltdj6PbQ1QYjRS4xreT5Q8UZuE3XF8TXvlNYHArT8TMT vZK1iLK2zc18LFkx2wboWaDBIW9YBVAXgwBfzRsYIuIq+ote/6beWIxQaTzyCKILevno3E68ZCl4 HKS5klg1SJTU8QbRRUjCuN8G7d59ycyp0Rtp8uPO17J9MpF7m5KVQ0+icdHvlzLlxtHx0CMyR1hx H4HxZno+PlIux1B5L+hREZGkZkss+LA50rAnBLOd7tlpTe3cDFj6BHGdlRx3a/3ZuHxRcvbi8dd9 mhFnT4p5Maz1e6QmbU0uIJrJ04O+bb2UPE6TQhy535xOuINitP5kB85TRZWM8WdjBDeyCsXFNOCj ZJdXOWpLvFJR26xRcosVvJROyg6zLpZZYuJCjuQ0MPEifX8OaN6uwgQvHt1G+sfMrtw5WniiNGnm c+ff5cGzEAGhWU00/altQ0nmAKy9ocUNKDxjleM894MkwHExWXGBfFU6gIiVE3fiUs1zuegNIYN9 qDBQi3y1SxnfL1tZ/RuSR2XUKdf33LTFRQSDQ9shEhP59ugPAjscLwxoa5nMcJRwAmlZ7vPwOfOh WdxMXlp0Pe7PKCVue7OvLIJ4IcPMsOKjl6rVp8e8DeuaAGYRR7Um2QTBRvrFoTfMQ3Xv0GgCSXTA xhoGZ0BZz/Pr8x8qsT/wA2Q2qA6IC1UV7anPHZ8orxGK7OA8v7qWf1+qmcGYcItLBaOajpBBt5uB bWWMISpbTJqhieiQoqKetbnyDQdRmnAfs+uNR3cJlfyNnimX28Pe3x45p5/RWGCMu8FX8ioZgJWh Y5FETaaam8EamNN/33iBdSVvIxP8qWzcIs4ujx+hf9qTJlyAwqNkOkTbW+JQ9iMrP/pX+OoNfN/S KGaCmSxOXjjHjgo6qSnFeqnHKwWO1fxKTEYzPToQfKJb8+NSapw9KmeeJzfr3FWBz7Oq4vTKseDa FWjSu3jpfqpkjBuo5DobUtwDrG67Hpdqdd5yK/o3q9yCk0gYS5gZUFoEqx75MkqfY7wKKIhpmMez a7dWTMyMZGbEq+9kUp95QdtQ31MTWyO6GR/VM3Vfb9eKVrNjsy8RZ/2uQ7R1M8VuvEVRrD1AL1/e 7MfVvVpxP0BSJRgLlki2zsq0J7AmNiraZxKteRRxRdlxG5CVIkLcQzqiqxAglArLVu4iEfZMw2nn m9y99mCvyaiMW4feXEBRZ3ztlO5V1qtniX2R/YiLbXLAGmVyUBm9E3sIdDQXwoT5o106w7Nfvilo r9FewlG2gF9nDc2HZeQNyt07H9QF8zcgDF+LCvN+X/i1LkEXOLaMUyG77MabzCNfK4RIm7+sURP6 4aNGoLiNtxzM+GXNgjNfrETTKWrSqBiyFmXFEAFG6UlILQ5kPDnruXx0kwEbItHk3IW1tNOStygi UNwyA4ZLXiQLTEVMHyUlWEqLbD77fDzKXknracXSfflPgW35haT8bFZBl+uo/5JjEvaHFL78msqj 4LGZEODiHzjA8uYoOmKfPiTP+uvBkyQbzyma0B2AdnrtZOSSI0L1YMvxryCMyhTLh8pyB5hXcEW8 SvhkVKi20ptGigH4D9GOn/vIXiTn9JsNnoLDcbqUhllGXeE85Py+YrJB7PTGmsMCAxNx5o9OHVUa +UEKiGr4YUcfpoy2hLbWgDAZISLLXlw4MIbXOZg3ikjy1UDyQnX6AtBgt9FBSGA218zKIUenkDAt TX7JMzw0z0Cfm8KRp+Ju4ZOQVPZcJ5M/ZfV+Hl+62lugkMG0hHIaKSVr4uWzQ8Bl+lSK4MBozlFo 2BAoWDpF6ZCdiLKczhaYFkz6NHk1VCk6ZfZXPW1kj3hfVT7r7CSvLPVwXYwoMVJwr/h+XJFRCRoJ li7lpKhiu72QlyLuUJs9NB0tQMCuG9NmqPr0vHnkzt2x12+sZXaFzhfUBlPl8vRq8sOjDR6nGSmr WOTWQzYh0PQn6zgLl+EVOr5wTXr9qatV2J6CywfowH0UGSgHbs/6hks24QDD8/BAP8xGmk/yaFcQ GzMDlKnEIrHRr9FSwgOMrxnRFfQyCqySHDmf5Lczz5yj6Sf8uw2b6PbxxWdDA412TOYxbHNQIutp D+gGdR8z1FzRdHzi6yjDMY2v02lpw1a8n9DGuN3IaZ8TjCAUnJsSX6gJFTVQHcDy0eMhha0Ff3mW C0nJZZDx0FeDuWB2qR9YEONUTMqIL8ukPVkxv6fU/6v5fahQBUzE3N4aUS10MMa0PzCpE6nkNvfk T1h9XQbVdHa4YROG8HAmfeix5RNxzNS0HacOYKhvgg+SZs2wD0bxdF2WG8nWDmJTpNgnE7tcns65 UnD2MVj4oGhfj94A3nirTgS3+GC/d7yCHXMWdsxwKMmdRuZo13N98XLDrhxd4Bz2JxuikGjLuPnF 7wnijlwqrhp53cs/kpFA8LznxFI/4M/zCeilUuedqPOWT7RPs78OTwnyX6feK86x0AoBfyLJ/UGi Wx/Ree7pctDlJgutY7iUyC9T1saIaTEy+CSiu7Gj46EpS8KHHWUKS724m0eWNA705hMkQoP2Iixt EoihnbbW8xRhl4EWjTiIOYJOKKeSsPr3PlJOngLf5HvPaNw8Xy01guK0cYh1O3xwBITo4YyX00nW 3Q8VO3JL1IXvH3NI40ipOR/hIo+7Szh7lEduDIGL/Qfd+sA4hkS7SWTl34N0defGnjCyOPS+U5OP cr27xSY1vfF0JJ/Buu2vzPsQYtQM/YYXL9Spl1nIsIXiXMjCA1xtypijmYmsqfZ2+jjhZs0Y/8mR 1tYKUuMaOWL1rIb7cvJ7r90i6c8F9r526hHaguUXUdpEmsqeJaDPdk6Fc0aWBjphwtZHJKqjM1ff aXfznVVF3Zz0xoeVPiRHsvJhp4QZbwJ4ET4uhlS4H7V60XRloPSnRUVGyn3DYF66X7mJ1SqNeTm8 m6w1GJI4/NvtWjIJ/DUsI2tZFlNq2n0tL4vv62wYVGywgSiJk8VZr44wnARLU8tYhTxpgd2mXrUn 5sZrn1SXsjjmBbzvwyyAeTHjt0u7OHCFmYx+rgWzKczSmSFyCwPrMkHXGvgNShzUl8Ve0f0LGLH5 MfHMS0DvbmoVI9F5ta2sei81PBII5LH6ZG6Vr7ekh+2vJ+w+/S0SQJNwyuXvDVIGWJxA+qtcQYA8 rQn+eXwtOgj+oK32GneRs1yb2IRtn6s337PzZcGWxn5JKNi1UQ4Yu0ScKAGo9gEdeVTcZqTwrVXF PQs+rTbBDN4sJ/aOVTUexO/tz13HbnZSEOv7Xlyh1nE/IZZvCwowhQjrmMYY732gCZAe9IjQF0Uo k9gh3eR41+AjYC1rfKyZcHVtv5mCilQNVBx22LCi15xttk5ZUXaWbZqcB0YsVfxoWCcVoPJL0oAc zf60wcYWdRo63HXpUV1YOVyDsu5JrzKpN5lI0qbj2Xpk1wvxnEfRxP69O/q/M42M90MlK8enSznT 1SK5HCRl4+sgQQmlln+N5fYETzu0+4kKrumzQ6nnJ8CTWWQvGfT69oPGpBQz4LLEs70WyPseM5R/ VKfQhazzVRyFzxmOQHjrOnaETn58O5fJEiL00D1sLPJVOL4Zls/T/t6miKSx5XiIcFEvRHPrQ97k 9VVsMDQ5ljnXxyfPOgLv/sUED1XRLDSLEV6e9G8tZLcBZ5lirqEcBsaQALO03caLJfKoKMJI1OGa z54cuP+aly3eh0DQVESVi0fmQcCjbCUR0A3Y2KXsL9EdqoSHOGdm4rrnLm7b0S/wiksx5E9CJrub OvWz39R34HDP+AUm3IaAnjdb5HP1hoy1xCSEwqpUT9ZyYF52+YMy0LTmeRQZ3lC4bCzFFEOtbH0Q d3AMwuvIOFVe7gVHFjYApFYo2uao2lc3BNAXI/kIVMt5N1q7FWPCyuuiFMQRg5ATFaCsF0nQLph6 89EgqGOjIQVwtqT4+y1y47VMFel0xy1dwPsL90VZdwOMNy1GItKxMercOujrk0bX8RQkDmdlCXuo CrO0TOKYyY/t9+lXy0xMkuD2bNg0IWNwizAHGo9tjMcn1w1Afo9VFqEUh9LNJ35M0o9YvG+/uZgC pqBJSatl20kJkcaujXASicI7uyjoVilXENJpI4cIEC8J2VdkvQdAFpdAj5eYGGLAUwXhlYy04/kD 7uLtbc/5kX3z+PnM69W5TYeDvUT5HmgjV2q/Wiz1vRCix6+kchAkWhpxAjwUjOpUuDI0gUwsfuK/ xiyIsJIej4sVl/qyulRqhiPHd2xP+y2zleWdzon9vkRFdhn7MvzECSaleIwPKVGjDMsYojzo1pNL HGiXnMQQsPbiMRHlTlwZuvrtmGGvfT+47PQIJRl3fMexv5tRMA7TzlsrIsFW02pmSgeeBeN4NOxK CDh0Ox61ZRCYuCo0uMXtg5pR4qu3qO6lre4QoQ78wYt5aaBv3FNNcK9Ocm0CoCcmdja6DyaHpB3a 9Iw+auWVdZUb5+yfePx7sZpUnN3B1wd3Kt5R9K19a8nh/Ismkp7x2JFFn47nmmTmQQp/dg1sXg14 //MRgM+KSy8G2jRLKExsBYVZfTdJJY0rm5M6vDJsUrBCNX5cdLxuIkap0yc5cHjY+ka8lpijGyCX QH2HGr8lcIY73Z+Fb1JtEE/hsR2cko0Gru28iIjwrkhPtaNWca+2aAzRNPRhBZT8OgoyYrvmQ5ZU zFILaugPJaxmV6FKQVJ3ETm2wNF+00LMruOypRly34xZqK6Jxln0p5v8JXldI129TxjPwgr/tQDi WrMRyL/3qxYRMv99aMmsCtsGCC0XozA6nKutUWNTTIFovIEX8VOjAtDTJLtHmAy/ZQDVQAhc3JLI fDPynX9QCJVqF6ywdGaV0TQYmkurRPfNyIUxEbRPeMBSM6owTOgbleuvyd70ssnFkeYgi8S7K4Td 53SPKwlwfFV867XnTYT0O5yKjTf/qoXAOlOs4AN2PO+wiMdd+MI33SGuyPZPrAjVbZms/sA38NF5 7cG52bjvwMalLR61JbM5UORNEPtopQz58z7jfYDaVauCz6fqBY9pISMMqtpCfbEbkbJjr/fOVa2u 8zBoExX1i5yrfCEe8TBeHyMTGKf8DOGBlof38IG0h/MBij9aT3WEGDO6ZCKQ3O2Na04QZx23YhEQ 4KnDTjTLcHr72UynG5U2i4rfB/4b0EQyz9Q6zrCgaOWS/Foday+15Akn99e4rQmoRne9JiEQ1LfS cS24GPlPAadYVEwKg0rj50sqniqH9xrfzm2xHRu2Bc+vUV9xyy2UUU3rBkV5ikoi/svUw+XeeYuV Tc2HWJX240dEktbQNzSuhQZqre3D+IIVlztEUmx5jugPFIjuLQes8dj56w1P1jnW3PYUGGCiZPKY p6xjYTsqdRXLCpdCU3BcqixJP6WOVXwX3X59E4ZPbUXTVSgCWhQBPiVfVRHhkdOpPDwC4imw0yj8 DTblLePo9k39AqFMdM0TnlAB2aE37LW/ARRTlfLnNyecjD/13W4W+wTx+SpxQIbYob+g4uTJ2nc8 VL0JX42gSvxnSqnpqrJthTB63uqSVv63Mylt0QIeiZZfrc/EFYo6ONhyrbM3pZowusHwhOlqhLd3 8faOsqdCaQi7UPnGG0xm7AwAkvzi7ztCgn5wqgfndNQ0CFlLlDJ+7f4debmnAk/dJu8JiCBcPxb4 kiyMCkpOspQ4CmU9p+CoU0tlWRUWEBFCk1eyCMd4XyvEunbTPH+irMH0sDCb0LnJ7AoypCITLFQh EZ4pK/gH9oPB+xkQAADA2b/nH/SoJzScgWYIOhQxAQCiBt6c/slBo8wxIgHm/8vMnwFMTOsS8HwZ UtLv3Pzw32eUiY2Jfm9OggMpXAb9C9t3V46+xZFhrLfxpvdVu+vcj3fOug/Em5lZVabjq2+IRKG7 gGv7oU7ehrVgd3NXn5f3fWwKoSSEDmH8LQqrrZWC6DXyP4BiTjmhjiyTav7ZoPePHYBU1jO2eksD ww56pv1wWlT4WRlQf673+Ygwy8ojRoiDE2I9+y2NQiVQkaDyIri0KbrZDJrX1/LaJEd14p9uDzBL CGmup86IL27BBj54A9xRcOHZYD0DTo4xPz8wI4InJ/o7gxiDiIhIRT0xfPGjgCIB707OIZFmsRAr 7c+mq9oNGNGgmxDBdMCPnLyf1tf++jGaq0DzdnW/kbIxl9EqXEm7hGVHx2SGwc+kGFTFvPqRL6ZW lchKocW5hwg6GJBXWS4s9NuWhGJxr0cVFcN5NFWn58FNiwY+pCM/8/xd/FBiz9KvrBe1i54B63sX NDL23c/+ljIUUUmLJvMB00zZZPLoiPVCDXHKOl+Rz3tP8JPbCFGXkzDnrwqaH1tsqFwqXnzsjFSg AHDCcdaKlwEnC1eBoSEF71bPecZARhA58RueD3IgpqgOSMqq7TAn+dI0tHOcDjf5ijEM6/OY9IaZ HGVMt9aSRWDXXoZHU9tzHiqC2TXvXXhOOY04vl0r4+UugwbiIy7DRVWXtm35lrbcBa9VSeoeqNTj F5aRpx6CKZx0AIQj+gKLLFFml+p/VqKbkp4cjF7TmqCWZeUj4qWTOEXw9ltWYD2NDe4pYoAXkd27 IP1uQ0Z0QwEHZASRGUQrvbm4FoJuxLLSaFf3+PSITHtUWITFvjjPQodNBL+V/p6vIMNKQhk98R8T u+EycdauDlK1c1qLGZpb2xKN4964eeUbJpZJ+ZiFX+ru81LWZiolVORbwF5YnNPGxM9XIEhw8VOd kjAqa0l/yFXiLk0Y04zjbTEHyc4LNww98Ta4isvxXg8YT0eZ5CKEBmMY/raViku0iAvSzoliCbR1 GvCFK3bGdXaMlzMdcko4NcvmkrIZ64GfWqAd/qbiIG6GEVAoX6vECm8PkVPp5WsoRZftbeq6KG2v pCyTV5XosBV3MXubL96kuyZrhaHpIBSih6eNxN4InPsCskbxA41K8hCxoRVWlNoeuUAFeXswmb/z 3rmDAXpX+npOjXvMOnGK6eisBi4qiiROSXtiiUQsPrwW34Tgg8K4Y9psW3ts2KXvttyNp7vTmBu1 qTkVJOoXn9XgXlbhI9/0mJlbV4MDKmoAW7OmGj+cT63kVytv++aMvWSBZGgxB4jItQ3CtYU62Rl0 wtxh/4v1NM5NoFORXrr7ikTUf3zwLCZsUEyEluk40MfJLoNCTBJB0XibAQeH0BD4faLdSkmwDF5p xE9ErQKKBewMCIcOEHDwexZwEpW8Uro2XVO6lC+grKQqoa2k6Wxupmng56uZ05gU3BOaFZ1TGRan D1DzK+EUaeCTFNcVk5mcBq5Yv0Oa1aPbrr4b6BSV6jBR2Mk7nmadGkyPTfJbDpAO19fJXBWrzSZk JEG/coo603lkw50CpNZTsViVn0ySH5+SewragszP9jxnsHbVJM9YQxq3vfpRAr61tmXyHVXy9jXZ s4XDlw5OAnr3IJfBA1DMwud/iv5tQsjwjrrl3IYxgNTPUP3IfkgFRz+M8DJF/+L0/uP5GcyKkbN+ ZMCDxwmCTdR8tGtnGdzYk7R6sXnbYgBDMQORHEEmBiay6nZwFcA6RUTe8YMD/CdfPIKYk9PXfpjH EO50iuTGbeaT0jjrBXleYpstJnyHQHDv9YPmvX96f8MJJHtFZJ/c52GAfy6sAZ2GpDl/Oz9raS4a dU+G03qEkDa26qQgupDOvMs3MaqQj11R680N9PpCdDpZzOSG1PaBOwVfatCOuGk1d98AATSNVhQY e5kYBUa5iAjff9Lr4toeY+Pu+bs0tQKhjIYcOZKIW5IELH64u0lZkvOjmCyesc2ACESR+YPFnsVT 8eWsK+34D8GHKYTC32Xyu+xSh2zrRo+k+awIGSOvljowRz0t4AI4f5h799HHZvk9YPfDuWytc/bM DhnzgSSVMN9uv3QZQQkEtMmSrSUS9Wtp9AyU7YJBhe7AFkxltjQXgpNRuntvFUd7mi5y3XTsArJT qQj/GRQL+dzBinB0fusmhgvP1u6izgFcarVgPz9HHVFZeL+/9I8pzFYpYxpgMHrmBuRFggP4LLqQ bcM4UwK2KlH/+n/fL5ZUD7jxucT0FkJdNUvKgtA5KDqgE+TRExqK0eV5nxg018HAf702aWnUhKvl Kc+ctT1UaXIGWp9b3LEJbq16t6//IimPGAYzi0R7FM27qMSRexqmScSranKwjiC+brNsvHUjoGSI xROBrVDwNyUxTsiaJ908Q8qiR4p0YnxD8uP0V2CX79mA70tIpl0wAALUPY8zwOpXlFgghyUhbMuV VVqoV572F/Ocmq28sAFPv0wXI4T0yruSox/KH9AoEuVGQc7Rl96oV16D6fVclDtYDzukKcfokMUV jreIOUcw/W9g5IyTGb83htCPuWRS8Qr3q6xeUJRABQNq87VQ9SKDq+mR3IO0ApU/A8R8Xl4GQ5j4 361d/IeW3fEtXbH3BFFhHoIpvMWcCXcIUg47MW8ksPc/1QwjQdObR3a8AG7hvw6PcWRwA4YdRgJh vwzprK+yjl8X0MlqM6dcW0RgKyZ1OLwsllmPl9fkHAF+S/yfqgOKgiJew/cPCKwQA7uP7g1Uo0OF tlFEvUZDsyWsdwn1fYe/ZswmVkXZxP6T3CaNXIBuwNEVqy4WiUFZaj1QjTwC3nw6T/tYGQZ1UESG 2Na56WGEmek1ppn0VaQVNLwCd4kE2qfPjqC70/awKCKJrVsthx1n4WIDvnLvnr5Ba+q7eUQdv7Od EuG9RungkdsDX0MxUO/3f17novqoFqfG/XQvmkgjd9LUpnl88qIKzP7G6kDO0rVwPV/B7f50EDST jw6UdAc51NnK8HaE78crv45uC9zyySzxSo8fvYnmY1x1IlAViNvSLwJLc7k1yJ0DdYP73Ky+1wmy duqJRnrHpOzZ/xVG+xwBtSYTht28/7E57DQD/HJIARxmFoGBKPwAEGjg99fEVZmGqvrQ5ak0F4F1 skPFX9L31O+Fd4ik/yTMhKbpxbwunYa5pEXCtzlO0ZYTnVLZ0NfsPA5dzE89LSfhZ2zCMsKH0Fpz EujNvd3z2sBoiPWw3ZeFU65EfyLHXnfIwEPs+Bilzq2oo8V6Fy4Ec8nkriVK+q2Tfdl6nrc1/Top Z1MLahsbciGEcj3dzqhpl9nY+1EBl78EEGgNTgwQe6bc1voOXPZg8tCwbOEL+/T5XpwUEdn8yP5t UDTa0EyWevGm9TS8wLl1WbbAdjhWslIJvm8mOR3Dq5csnUm12W1oMScgWo0sczKBPiz78YZP7hX9 7m++oct6chjNjECsfoZKiBRMxnyyaLwzWLLL2ghtLw5BwKFsusIwJEw9aCFXnBq+tJEMw5uICi0k XRlh0veA6XYFedYtgWXGUhkJwiMi5CbkHSKdaAEA16G1rJSKRumKvyMnqKWpaDImIcI1u4PJuWlR Mr4jvkt4q+8qJZT007cJuCgrXpYad8JdSs3xtA4GEOmM7J1CsJFVhIW+S1RXEvN1EC4jJV8sgbi7 4+NbIlXr0nE9F/09iNra5DcKY0guNTq8p0VHAAHyHUKwlY+T/QF9Ggrt/GrAH55ZDrkIrneJDDeO ScA7jIuFMXWqh6pfgURRYAx8krp+ZdOzj9u/BUEbXohai7lxEseF7f3m722lMNOfxGcbrieBiBKj Zcme80U/y1/OO6AjSjf33vNzFPkR0LpqPqaMl1NERbLHqqRJPmNXQQENbNPfwgmRQl9PGedGSOt6 AV7AVno4hETVN3HQSgtGguqDW+H5CwrYB+cLYrFOYXNMeLmvVPhhr2VEWIA7c1pWp/7MKwjBQlMU D4HAtFCoPLUIir/ksBQ0dctvtOLBlRT3x+hnkM/qxvGX6cFGpPZH1tQ/lgrIT4mJh07DkBXsvLDd IgQ0ITfOuuvzfJ9hqan8fsbri7PTZcLJ4Bau8seh8Of8BTammbX3dSgBkCVv/mIbLtJo2bMRmEyw bn4y6cD1+6qFW/fqrqpZkQv4caDWAVLEmqzvHtEHvTyz+X1kG7bO2zNeFCbQRsB8JCiGypbR1Xcj P7wfy4+tbjF/EvbbVruwCuOPZ2Wo3680OyFRP3fKZz7m2Qn5PZQTHdIHrQDEaxtMXmWuE8WVbtAG 1rb7/Vgu5mudNMg8hxbLGu8cOfzn0neZE+xsAbJHe4XuqpQwClj0v2Ohh/SkQt54zytazsDrd2zL HGOYaN/VcXL5l1b43WO2VJ5noymvXeXFsY6d/9GND5clQ0Z6J8Ez/qfuR2LAeXNC+Qd/Fd1uI28+ RCRCY+oXj1IVZUEV02MxUCgL/Y294+CotMvp5eXVvD+9GWUJNSi8JpKiA+B564ErICbyPS5fRjLh FR314wOrQllShIC/W6LW6XpUnQ60IMhzSVq8y1+1eBKyLxDb3QWLXH3r1DFZGf+cY3xQkkcVLDeq j319sakzuD12Q/xsoUGdZbaZhzgd/axYnUNpUNQP+aKW6+nokHNN14yos6mFIFiOIhu5ueLBYePN ik0u9YIeHiXj9/V7/9Ay3molaEfn3njHtHqQO1lLlg+kppIauJlkaexw7pRjcoYnrrqxW72HGCFN QBk2KN5HonsitXKQQvSeKsrJteFxLGKiQ5GfiN6VEOax4vTsgENqFKWSnFL2rOu2Fjl94XkyX9Ik gXN6xLeWAA1XPme9EC4s4us+vBhGgG2bdJDOyqIvFXW+J62fhzv9Rrrwr7pelUEfFoZ8vbe07wKp e41ogfJ3QLVpx5e7/fDWbKqCNt5u82I0zyDmTozTAFnhXRstcJLIBmJztRVk2DkQATJYjS0+a/c0 cbayUVFcULl7E31xWo7pSsDUN76UumkoXNaPJ7rS+CCLbYvevrn9MqpAFFR2FagDFh2d2T+L3JWz Gch4XQBxtK/qIHELXZSCtXJVPo+6XZDpSfPaAcJefvH0ssR4FlfLd9FLspaDklyY0nxPgLQ7gz7c UA0WykhTdyRdVMZnjdllowJvG0x7ue/8oj/TgVu/svaui2wgzO7vIaawfP2Q0nUv9g40KyXa2oL9 mzcgbyMm7UZHD5DAxmy15Jl94rFzi25H1ATwT6lKa1zsnr6YmFZEI/wJOkxQJXfDE+r+G/T0kCWQ P8UtDTGpLitHuo8GYt4d+1Z770nJ++pdfhxuc8DtzJLmN9IIiGRxAtcAGSYSCujNenad7c3ilYsb BL7Bhg9sHYPG9/nG+6fJuhc0EXFihTt55eZU7rUHPVEP4lM2yraFVgdv0x4hdg7A9LSptwCcULkR yqsZR6JsYAf+vLXYZRJ0lynVhHLfZKMoeYoCTXq+f2LFe5y/TWYiEF3tjdXyFG7JQf1/Ws2K2o2g 70tqDmhwmaDOjtg5MLQrbhtIcIfZ1yqulu0ASXZA+bLUvVpUValSDZsr1VDWWcDVwgmn1Hj2Uiad ED1/egs58F44e2ooHILeFDVSdpAy31SmaQTMq2byBZo25kgl05YM1eZD/dISkT9A0yQodDpk6ysx 39ZJW7DAwrjuGX0o9yzKc4MsPh8tHbv7kO64L3yXlPJbraMMjHLlzrZukq+DONAK+aken8q/O5Yb Mi3xvV05OhQC2yZHUHaKXg7q3LIRvQsqFrmzT18ZzKzudSFEwlBzHweYzD/j91MOaNmTvGmu0wqF /ywxF/UrLWjlOUW8UTJoUVkoR4TjcF7NQG9U9+cfLAbBrPSnjGtu8ewD9fUQHhAKIW5xRhYuJcxy ouEwv8H8gQbGZLpPGrS6TOwcX5denaDabPEJjg40SgQ8HkLzvj88wL3uF5g/MAUSdK5BC1DlpQPQ wIFP8BLbsuORfUSJApCbRgL47aoIL/azpZqT1r2V/oO2byjuHkhJFxSoHDpG9he4F7VecwqRfU7C cS8bsmZdGQc9oGWyafND1bRyETAFNDUT1loqVhJC2/soTo+Q5q9IDIECSFD7+0JasDwPV/EBuGo3 qllWe3pO1GMwYHbx0o5fkog5+1wkp+RK2IVcQAVRntRqdd2Qch5oIPcfyvfGFoiAZUFGxxGEZCJf Up9dTgSt6432s0ZX/PKr36eXOJPX2cLHBipI6SveWjaelRh0SOhVk0iByRzZwVyhBmwFkdQwWhpf 9hxb49/mV78QrGgvUW3Kib+Q3sdKTKCh/Hq9SexF4HpRvGkM+x7aYCwwlXZaQ4qqxWHYZyILSuoF QpCLzBO0V4/putVViwPOEOSagldzxgfuGCoP5dbFcBrA5083d9pn5gv6r5psQVQgKH//YLlvzIax YQBgU8upGSf+YtFznXydTcSNRJVD5fIr0k7TYB3C5iKcPpPtsF+X/Q6vcwjSqPzdTLzGqsjLo6UH YhFvUiVG1cOfMwQPb6uWaKLhkggBfLLpkx+LxyR9uKMkC35AVmmyIfSAsf8YQmAyUVloKkwlo06c U4EZvocYyTgIigv1zIB5WpYgpytVK/rUqScZ/ndBz9Q78tXXNErCHHoAB95pbm0JEzTksaI3f/2s g1aLAN/F+wQ2GIGBKG3ePgOARCixHaj8wkBuO8eNcRjXuseuNyMYc0r9UT1tLpWRENc3Tyoz8scB 6jpVV1K2oPYRqb8DQs9m7XPK9xvoVNmZtWn8eH5nCP5pm7AxJK8D0is4rUc2jItHPCNMZNXNh3CR NsHARfkRLEfrHqvHXgAuH+L0uSvC9UxyjACCdu+lsiu4lspVvMh4CuPM+YN0Xo9MGJw5wGIbEUxA GkYW47OhqwT8SAQFe+llizfnVe7ZkiHvfvi8pc8L1YiMXybbxAYBFFU8nB5qwWfopXOMcStKoYW+ 9QMl/poebP3oTrB0no61qosFFt/YFZPbrjd4z/0JmieJbJbR1mTw5I0xzLruGbPnMT0xFfNQT8/r WWedO52TTD025f3g9bFl/ZvhQjNCgCbTI0mZPpvKHc2WSwdvEHJ6WIRtiBI//mzTJd1rLycNEW39 4/ckxT48kltIVA46YWDklsB0rsgoedlDVFMlCH2qvVjWCfrX3fRSl60rh6damTbc3uMcyDvGwW2l 0dkkLmCW54AM2d+ZlgrfzlhfBVgo1Dknc2L8aPikr/GATdLJvX1nUyr0AITKPcmy9xw1VQgRLhjB 8Rh1foWejpfJlt7ncPe9vXI+XI+sNF177VMItKnjgQHecBcSn+7iKYWbB1WjyzKgxhCuVYLaWQVb Z7/RE5JFPnGLk02+PYZHgu3P6AsKpJkMqsAVVHQquxtbHDlbwelmJb+rIif0RfIJGjgvlhKd7ofi 750y5GIhpkzyGe7LqClJNhhE8R+sgr6wJ/9yzV3yeY1L7JEAD0wCTpwVAIJaDLcN8z1zAdLRjhkK zcjTPCCYI94O5mm3UtPo9PAfYEkwZqgSseId9ksFqdfgRdOrqO3XK9iai5nD1mzqHCv4WaTLVPYc wzkVTESe6NwCJT8IDM/aPr3je39DHd8aF9U/Q38cu9PA4Et0RSX4ey43MTKINMQHMqkkvvfuDEpY r1J5K4FgaHQDgjo13jHE8HjBsGYiHnR6IOSXoXEojsL4AB0/EFa5l1GkbvBAr7VOaNuW9DUqVvfZ MfmeInRkyfl9VmK7q8NOTvR6IsJ7ugZxY7yrcsrmYrYwRm2iVwyjSngi+zbZEgla+pj1ZgxSsbvO TW9xcwwIMOOW3avJTlZsfNj2oEIVhJc/ouUuNYv2rHhnXjumpZzZYuB943aXlN3s2Yh0wN0Td4pH 5gvG3EYwK4vGVSoZQGYOAgiBm9luA39JZXewgI524pAeJ7uIcAMAt8orUbZoC9iyy7NuoYGQY0qc yqfdix9YTl0HstKgsA16qo6x5Ts6ZPSsxJ68HgLY/eospkg34q+7wmWq12XVgMYjgw5N4ZpFSaMr QcwI/ewHgtgREl+VUYNV/BPSrzanXV2h1mz56ocdpDTlWwJHCx/PakkpRy/wB1kH1mY/xkkM9TLR QAkQ5AJfjk2clMdtoICWyy4QFVxKWZPZQNUUP7DDsGdgj4wzH6QEHrK+if/oGmfkaHNsmTDOmgDV zm+h2ZN8MXhJsrT8xSbWh4Xf5TVZFDWtKNEpm6Yl8GAbPu0nAfoIQidIjPzOQLC2NinNt8oKfi7A g/gurmIRhjJfg1jVmNbEfiXhnvKaAbHNyr/5/SVGG3x2MEezoKfuAllsZ48jAqUmbvKmSo0eARrS 6Kn60hSMxNQAXmqgFMygMiDwLjsw6vGGf7ts84Mi5aRXH+f65L/zyg1KojyHlbyv42GM4kE1b34l t17ZOmYrUPSKwrE9ADjFwKgnzBNVTU2DEs9RagZQ5as4oQi0LP4g8smtUbMbEyiw6qCLTUt25C89 F+pu0Lw+VWwsAWDVg5oWtCdKS8Hgrk5Ay3tls0MlzNwHXGB2QA5zKsuN72Vprsm40tarHrCSeHlM BngK/VIUITGa29XdkTgnRQNyN5ikOTEAKPxxxLlADYJ0xTSrVJNHlwo/sX1oKOsyfDx85aoRM5xZ pGIIbr0BtVF5d6OOZqATpFMRwSnAY058SN8zKrlHErnWbyTE79T3KfsAaC9/xB8XP27fCoE+cgG8 ZAW8WC84YwMAANA8DU/cdqH11vJF0VZRG3VtCsFgHvqhGcn1r9AhqGlEDv5wEUswo7k1m+jjdQWy 5d6hiLGhb/hPEOxRgzOwfyGiTEggLmGZt0x+mU0iiO9/gS/PLoF+CZ6Bh7r+a+hjEgesHXLkAQyf IPT2PxywTMx//xVgYh5BBgCQHQBDAgAIAJDz5rQ9Q2BiHvfPTMPwv6L8Z270n3Swp050yFEsJBoB N4IoggCXQDME6VGD1FsBjxCTUgABQ8mSL7//5YFLp6kGC/y3PU2xGTDqLeA28h9/cwKCJ0zv/K9Y AYNCrcQll4Dt79aLhozIC4PvQYvqUYOgvyh17on/sYsaOYP+Zxh0tnQO81983OwNeGCo4jlNCox5 REL4Hy6Bfy9/BYJuAS8BzRSj5g6BNS8bNP/JQXf5/yk66I1/qIOnU0Kv4YEHz60eSzg9iPT7Fncp Da07kVCdbfaJGJtLyCTB7ZwOF8bsx3eEWhQXaC0VscGAjJu3UigjMWBUp83Mcgc8XNVPaA/J5+y4 APylxAYbZUg4ZgmyyOOiE9i9I7Zn15CeEynmg9nhYYbFhjJWXXhLML7z0A/D45RepX8xhnWsVgDt ckSlzrbNrH0wmYHd73n+LayMv3bZxQKncn0N/Dnk0vuLUW/lpt16SmTlKFcib+Dy1zuQYTSYU8ik sDNVLUS3WAymf+U/LQigIWEHAgD4NSEBAXg/Jz36/f2nnINL5cPT+a/J3f8C3z+Z7h+R/Q+d9D+Z 7X+s/yfU/ltv+d/8/7m2NnW0M7VhZqIzsbEBcHEydfxvEQBA3NRZ1t7ExcZUwtDOxMZU8J9K1tTJ ydDcVMjeXfB/5oD4z7tbFwjg4B+9/yMePSAA9X/k/Y8S/hGc/v+ubv0A8H+7CvzfeoH/V+W1Fzpa sCfCS3x2q1Zgyuq8KwygVuWJA/XXfkW4Iy1bI4654jBUUw/GBaQtFk3l1WbJOPzIjyvIxYbOR/sz VZxTe+YdmLXJQ/1ssXFOab9F+Lhhnuum4KeWc9m1sYRXj4o6dy8WFqIYzt41zhwEJf3jpYgrq0lc mvifwcNvHj5/cy6lG42BBJlZf6tXCye6CDsykvb0ZhmBUpVvcJodHcVSO6kgZWA3koyp/1AQqAaA tWZe29v3qIiwpT0cClkyY7b/z3/B0iJs/v/qzh+8ilWwy/VGs9k8gUAwOHyBIAhkSpUqjf9SCAZD Y7LabHU4XyZsI1Vd0x1a0SnTH9i4ajvfUPVDdvcKzhv/EZOJmsKOrlyCvvmkP3Whc6B/pTDU4Ypi 3xYr+iG6MnJTwP+cxc2rTwSvuaR8Mqaz4bzzdhVxnuOdR654I3mhwvxP/qm6TfjCD4MbS3svymt7 ZgnnW5Qf8dlN5hcTa1TspnmM2Le/kDU/LJcWlvyERTL6ps4ztNugnS90F1SYDpDtq5hZlWuoPS/0 V2TWtkxXnkyU6O/YicDd13QvVJxOoG3bKuFt/+q/Zym0s7cx2Ld1FXceZV+FL38h2SPl9Ib67MfO fetHzu8jLHRxs2E5McUjZpjlGgOs+GAup/bUhOycUols/itWfU16aOv7h/La2wCSbZZvB6Wqj/ne 1E0HqDsDIKhhQKz3mv7Y2d7RMEjQR5dxmmoLqa2P6MrOU0+mZx03rGdV/GaK4tKFTpPy1pZZkHXd fR646t7w3MRHB6pxG2FkpZ2l6of52oLOkfLIwPxffPclsd47plcjL03IzzncjJoBsbJ7slNTT1f6 a0pko9nFOTc3bjBbHSDV7hCTNwAASEgICCiA/4P/g/8/8H8BUEsBAgAAFAACAAgA9YPnLvz1hhKb QAEAAFIBAAsAAAAAAAAAAAAAAAAAAAAAAGRldGFpbHMucGlmUEsFBgAAAAABAAEAOQAAAMRAAQAA AA== --CSmtpMsgPart123X456_000_0048E50D-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 7 02:56:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h679uT06010720; Mon, 7 Jul 2003 02:56:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h679uSic010719; Mon, 7 Jul 2003 02:56:28 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h679uP06010712 for ; Mon, 7 Jul 2003 02:56:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h679sEUu016713 for ; Mon, 7 Jul 2003 02:54:14 -0700 (PDT) Received: from mailout1.samsung.com ([203.254.224.24]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h679s9Ko011280 for ; Mon, 7 Jul 2003 02:54:09 -0700 (PDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHN00201FI80U@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 07 Jul 2003 18:54:08 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHN000Q2FI7RU@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 07 Jul 2003 18:54:08 +0900 (KST) Received: from SYAM ([107.108.7.23]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HHN004G7FI5RU@mmp2.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 07 Jul 2003 18:54:07 +0900 (KST) Date: Mon, 07 Jul 2003 15:18:44 +0530 From: Syam Madanapalli Subject: Re: Re: [I-D] IPv6 DAD Consideration for 802.11 Environment To: Pekka Savola , ??? Cc: Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com, Soohong Daniel Park Message-id: <008101c3446c$f5db90f0$0100a8c0@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Pekka, ----- Original Message ----- From: "Pekka Savola" To: "???" Cc: "Bob Hinden & Margaret Wasserman" ; ; Sent: Saturday, July 05, 2003 4:25 PM Subject: Re: Re: [I-D] IPv6 DAD Consideration for 802.11 Environment > On Sat, 5 Jul 2003, [EUC-KR] ¹Ú¼öÈ« wrote: > > >The purpose of DAD is not to detect MAC address duplication, but IP > > >address duplication. > > > > Generally, MAC (IEEE 802 48bit) duplication occurs IP address duplication > > with same Interface ID. > > Also I didn't mention that the purpose of DAD was to detect MAC duplication in this draft. > > The intent of this approach is that we can not detect the same MAC and IP address in 802.11 environment > > with existing DAD procedure. > > DAD does not detect (or rather, is not meant to detect) MAC duplication in > regular wired Ethernet. When MAC is duplicated and the node filters the frames based on Source MAC, DAD is no good. This is true even if the IPv6 address is being constructed using random interface identifier. And if MAC is unique and IID is being derived from MAC address, then also DAD is no good. In this case, DAD is useful, if IID is a random identifier. > > Then why not being able to detect it in 802.11 is a problem? If the wired ethernet also does the source filtering based on MAC address, then it is a problem with both of them (Wired and Wirelss). > > Note that DAD as specified still works in 802.11 perfectly, AFAICS. > > > >Perhaps this would speak for some form of applicability statement for DAD, > > >to be clear what it is meant to solve and what it isn't. > > > > So far there is not any applicability statement for DAD without > > 802.11 environment. > > Which was my point: one should be created :-) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 7 03:15:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h67AFo06010982; Mon, 7 Jul 2003 03:15:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h67AFodK010981; Mon, 7 Jul 2003 03:15:50 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h67AFk06010974 for ; Mon, 7 Jul 2003 03:15:46 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h67ADZUu019991 for ; Mon, 7 Jul 2003 03:13:35 -0700 (PDT) Received: from c001.snv.cp.net (h021.c001.snv.cp.net [209.228.32.135]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with SMTP id h67ADUDT011576 for ; Mon, 7 Jul 2003 04:13:30 -0600 (MDT) Received: (cpmta 13192 invoked from network); 7 Jul 2003 03:13:28 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.135) with SMTP; 7 Jul 2003 03:13:28 -0700 X-Sent: 7 Jul 2003 10:13:28 GMT Message-ID: <003f01c34470$683fe670$03051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <200307070837.h678bMvc001156@brmea-mail-2.sun.com> Subject: Re: Movie or Application Date: Mon, 7 Jul 2003 13:13:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the past 3 days I have received several versions of this virus. Please check your systems. In all cases there is an attachment called "your_details.zi" Here are 2 of the originators: ----- Original Message ----- From: To: Sent: Monday, July 07, 2003 11:31 AM Subject: Re: Movie > Please see the attached zip file for details. ----- Original Message ----- From: To: Sent: Monday, July 07, 2003 9:26 AM Subject: Re: Application > Please see the attached zip file for details. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 7 05:16:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h67CGE06012226; Mon, 7 Jul 2003 05:16:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h67CGExE012225; Mon, 7 Jul 2003 05:16:14 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h67CGB06012218 for ; Mon, 7 Jul 2003 05:16:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h67CE0UY018993 for ; Mon, 7 Jul 2003 05:14:00 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h67CDsfU000910 for ; Mon, 7 Jul 2003 05:13:55 -0700 (PDT) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4FE377F42; Mon, 7 Jul 2003 14:13:47 +0200 (CEST) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: Movie or Application Date: Mon, 7 Jul 2003 14:14:01 +0200 Organization: Unfix Message-ID: <001501c34481$4437bf80$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <003f01c34470$683fe670$03051eac@ttitelecom.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h67CGB06012219 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > In the past 3 days I have received several versions of this virus. > Please check your systems. > > In all cases there is an attachment called "your_details.zi" > > Here are 2 of the originators: Which are simply faked and random addresses taken from the inboxes. Read: W32/Sobig.e@MM http://vil.nai.com/vil/content/v_100429.htm Also note Stinger ( http://vil.nai.com/vil/stinger/ ) so you can remove it from your systems :) The last virus contestant was in this block: inetnum: 211.151.0.0 - 211.151.255.255 netname: A-1NET country: CN descr: A-1 NETCOM(CHINA),INC descr: BOE Science Park,10 Jiuxianqiao Road,Chaoyang District,Beijing admin-c: HW218-AP tech-c: LN56-AP status: ALLOCATED PORTABLE changed: ipas@cnnic.net.cn 20021030 mnt-by: MAINT-CNNIC-AP source: APNIC So dear chinese readers, scan your computers :) Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 7 06:03:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h67D3r06012581; Mon, 7 Jul 2003 06:03:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h67D3rMP012580; Mon, 7 Jul 2003 06:03:53 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h67D3o06012573 for ; Mon, 7 Jul 2003 06:03:50 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h67D1cUu017335 for ; Mon, 7 Jul 2003 06:01:39 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h67D1WZV010989 for ; Mon, 7 Jul 2003 07:01:33 -0600 (MDT) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.12.9/8.12.8) with SMTP id h67D1SeJ028756; Mon, 7 Jul 2003 15:01:28 +0200 (MEST) Received: (from ignatios@newton.cs.uni-bonn.de) by newton.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb1 15Feb2003); Mon, 07 Jul 2003 15:00:31 CEST (sender ignatios@newton.cs.uni-bonn.de) Date: Mon, 7 Jul 2003 15:00:31 +0200 From: Ignatios Souvatzis To: Nir Arad Cc: IPng mailing list Subject: Re: IPv6 over Ethernet question Message-ID: <20030707130031.GB12881@cs.uni-bonn.de> References: <00ee01c33be6$40527b10$5501040a@lt38> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <00ee01c33be6$40527b10$5501040a@lt38> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 26, 2003 at 03:24:19PM +0200, Nir Arad wrote: >=20 > I am reading RFC 2464, and I have encountered chapter 6, titled > "Address Mapping -- Unicast". > I have to admit I still didn't read the related RFC 2461 (Neighbor > Discovery), Then please do this. > but I was wondering if someone would be > willing to provide a short explanation of what is the purpose of this map= ping. The purpose of mapping IPv6 addresses to Ethernet addresses is to map=20 IPv6 addresses to Ethernet addresses, so that your IPv6 packets can be sent as Ethernet packets to the Ethernet address of your next hop host. -is --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPwlu6TCn4om+4LhpAQHf2wf9GcSv8w0JY3goIEqUg59DyyJXuhu//TZ1 5LeW6c3OtcvnQY6UDcXOs/jsY/Rg91C2R3/ZnZqvQpUgRLMxdebqTSFkwcXDM/SV /2ks10ZLotBjvBcB9C2E7D9oIrIAC1qmHQdyoani0b/mIwQRCbg9Y7AacLH8SEiu Hv28PdRN4dft1ZoaQsde7IYZoelqR7x7cxKyBw1GYn76WClhwvHW1j8L4U1OZHBo f74X9i/t/l4nbdZUerxqfFIvESXIYmiLVHwphi0t891XWo1B730FKc9FKYQStg6i 0oAiiEfb2Z/cYlH3g+YblfeQRiygB1ul3hl7L/wD5ZkX+4kIkVFsAw== =XOrB -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 7 07:00:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h67E0g06012902; Mon, 7 Jul 2003 07:00:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h67E0gXL012901; Mon, 7 Jul 2003 07:00:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h67E0c06012894 for ; Mon, 7 Jul 2003 07:00:38 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h67DwSUu026741 for ; Mon, 7 Jul 2003 06:58:28 -0700 (PDT) Received: from mailbox.office.aol.com (h-64-236-186-155.unassigned.aoltw.net [64.236.186.155]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h67DwMvc010835 for ; Mon, 7 Jul 2003 07:58:22 -0600 (MDT) Received: from pcsn630877 (micklesck2-2p05.office.aol.com [10.0.25.10]) by mailbox.office.aol.com (8.12.9/8.9.3) with ESMTP id h67Dw9M9005588; Mon, 7 Jul 2003 09:58:15 -0400 (EDT) Reply-To: From: "Cleve Mickles" To: "EricLKlein" , Subject: RE: Movie or Application Date: Mon, 7 Jul 2003 09:58:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <003f01c34470$683fe670$03051eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looks like one of these messages was sourced from my email address as well. The headers are forged. The only work I've been doing since last Thursday was in front of a barbeque grill. My PC had been in the off position until I polled this morning a received a number of virus detection messages from various folks. Cleve... > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of EricLKlein > Sent: Monday, July 07, 2003 6:13 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: Movie or Application > > > In the past 3 days I have received several versions of this virus. > Please check your systems. > > In all cases there is an attachment called "your_details.zi" > > Here are 2 of the originators: > > ----- Original Message ----- > From: > To: > Sent: Monday, July 07, 2003 11:31 AM > Subject: Re: Movie > > > > Please see the attached zip file for details. > > ----- Original Message ----- > From: > To: > Sent: Monday, July 07, 2003 9:26 AM > Subject: Re: Application > > > Please see the attached zip file for details. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 8 07:28:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h68ESK06027594; Tue, 8 Jul 2003 07:28:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h68ESKf3027593; Tue, 8 Jul 2003 07:28:20 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h68ESG06027586 for ; Tue, 8 Jul 2003 07:28:17 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h68EQ4UY008586 for ; Tue, 8 Jul 2003 07:26:04 -0700 (PDT) Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h68EPvZV025941 for ; Tue, 8 Jul 2003 08:25:58 -0600 (MDT) Received: from lt38 ([10.4.1.85]) by galileo5.galileo.co.il (8.12.6/8.12.6) with SMTP id h68FNXlH016984; Tue, 8 Jul 2003 17:23:37 +0200 (GMT-2) Message-ID: <01cd01c34565$983ace30$1f01040a@lt38> From: "Nir Arad" To: "Ignatios Souvatzis" Cc: "IPng mailing list" References: <00ee01c33be6$40527b10$5501040a@lt38> <20030707130031.GB12881@cs.uni-bonn.de> Subject: Re: IPv6 over Ethernet question Date: Tue, 8 Jul 2003 17:28:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Ignatios and all, As far as my understanding goes, it is the link-local IP address that is mapped from the MAC address. There is no MAC address mapped from any IP address, as this may results a Layer 2 havoc. As for this issue, the referenced phrase in RFC 2464 is still a mistery to me: "The procedure for mapping IPv6 unicast addresses into Ethernet link-layer addresses is described in [DISC]." I have searched RFC 2464 for "Ethernet" and found no such mapping procedure. Another question on section 6 of RFC 2464, and having read parts of RFC 2461 (ND): It is still unclear to me why must a node send the source link layer address option in neighbor solicitations and the like (it MUST do it in multicast solicitations); This address is already a part of the sent packet (for Ethernet). Why send the same data twice? Regards, -- Nir Arad ----- Original Message ----- From: "Ignatios Souvatzis" To: "Nir Arad" Cc: "IPng mailing list" Sent: Monday, July 07, 2003 3:00 PM Subject: Re: IPv6 over Ethernet question On Thu, Jun 26, 2003 at 03:24:19PM +0200, Nir Arad wrote: > > I am reading RFC 2464, and I have encountered chapter 6, titled > "Address Mapping -- Unicast". > I have to admit I still didn't read the related RFC 2461 (Neighbor > Discovery), Then please do this. > but I was wondering if someone would be > willing to provide a short explanation of what is the purpose of this mapping. The purpose of mapping IPv6 addresses to Ethernet addresses is to map IPv6 addresses to Ethernet addresses, so that your IPv6 packets can be sent as Ethernet packets to the Ethernet address of your next hop host. -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 8 10:17:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h68HHv06029456; Tue, 8 Jul 2003 10:17:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h68HHvsr029455; Tue, 8 Jul 2003 10:17:57 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h68HHs06029448 for ; Tue, 8 Jul 2003 10:17:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h68HFgUu012987 for ; Tue, 8 Jul 2003 10:15:42 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h68HFbKo022279 for ; Tue, 8 Jul 2003 10:15:37 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28605; Tue, 8 Jul 2003 10:15:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h68HFU014174; Tue, 8 Jul 2003 10:15:30 -0700 X-mProtect: <200307081715> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtOnQi6; Tue, 08 Jul 2003 10:15:28 PDT Message-Id: <4.3.2.7.2.20030708100322.02d75550@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jul 2003 10:14:23 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: IPv6 w.g. Last Call on "Requirements for IPv6 prefix delegation" Cc: hinden@iprg.nokia.com, Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a short IPv6 working group last call for comments on advancing the following document as an Informational RFC: Title : Requirements for IPv6 prefix delegation Author(s) : S. Miyakawa, R Droms Filename : draft-ietf-ipv6-prefix-delegation-requirement-02.txt Pages : 6 Date : 2003-7-1 A two week working group last call was completed on March 17, 2003 on the -01 version of the document. This version resolves issues raised during that working group last call. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on 14 July 2003. Bob Hinden / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 8 11:41:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h68IfQ06029889; Tue, 8 Jul 2003 11:41:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h68IfPUY029888; Tue, 8 Jul 2003 11:41:25 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.45] (may be forged)) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h68IfM06029881 for ; Tue, 8 Jul 2003 11:41:22 -0700 (PDT) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with SMTP id h68IdAte522864; Tue, 8 Jul 2003 11:39:10 -0700 (PDT) Date: Tue, 8 Jul 2003 11:38:47 -0700 From: Michael Hunter To: Bob Hinden & Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" Message-Id: <20030708113847.515a22cf.michael.hunter@eng.sun.com> In-Reply-To: <4.3.2.7.2.20030702140452.02a49658@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030702140452.02a49658@mailhost.iprg.nokia.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 02 Jul 2003 15:45:50 -0700 Bob Hinden & Margaret Wasserman wrote: [...] > The reasoning behind this set of changes was to resolve the issues raised > by the IESG and to maintain comparability with current shipping code. Node > Information Queries is shipping in the KAME and USAGI distributions and has > been found to be very useful for deploying IPv6 service and debugging > operational problems. > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end on 16 > July 2003. This looks like a strong draft. Several issues exist though. 1) There is no mention of RFC 3041 (privacy enhanced) addresses. Both the issue as to if they should be responded with and if they should be responded to needs to be addressed. 2) The security model is unclear as to the scope of responses. There is a sentence in the "Security Consideration" section which states the implementation should have a default configuration which refuses to respond to global scope addresses. If this means that the protocol should be limited to link local addresses that should be stated directly. Use of a 1 Hop Limit or 255 Hop Limit with check would enforce this (see LLMNR for example and reasons). I think limiting the protocol to the link local reduces its usefulness. If its not limited to the link local then this protocol should probably be filtered at the edge of the administrative domain. In any case this issue needs to be clarified. 3) (minor) Site locals are called out. For historical reasons I can see maintaining the query, but the historical nature of the request should be called out. The handling of IPv4 mapped addresses is unclear. If global addresses are requested that probably shouldn't include IPv4 mapped addresses. Michael Hunter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 8 14:51:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h68Lp506000896; Tue, 8 Jul 2003 14:51:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h68Lp419000895; Tue, 8 Jul 2003 14:51:04 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h68Lp106000888 for ; Tue, 8 Jul 2003 14:51:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h68LmnUY025763 for ; Tue, 8 Jul 2003 14:48:49 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h68LmifU009678 for ; Tue, 8 Jul 2003 14:48:44 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA15355; Tue, 8 Jul 2003 14:48:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h68LmcO12681; Tue, 8 Jul 2003 14:48:38 -0700 X-mProtect: <200307082148> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdo6ZQ2z; Tue, 08 Jul 2003 14:48:36 PDT Message-Id: <4.3.2.7.2.20030708144215.02db5d30@mailhost.iprg.nokia.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jul 2003 14:48:04 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: Draft IPv6 Agenda for the Vienna IETF Cc: hinden@iprg.nokia.com, Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is the draft agenda for the IPv6 sessions for the Vienna IETF meeting. Please send comments and corrections to the chairs. Thanks, Bob Hinden & Margaret Wasserman -------------------------------------------------------------- IPv6 (ipv6) Working Group Agenda IETF 57 -- Vienna, Austria July 13-18, 2003 Monday, 1930-2200 (Hall F2) =========================== Introduction and Agenda Bashing -- Bob Hinden (5 min) Document Status and Priorities -- Bob Hinden (10 min) Open Issues with IPv6 Node Requirements -- John Loughney (15 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-04.txt Open Issues with IPv6 MIBs -- Brian Haberman (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-04.txt Open Issues with Prefix Delegation Requirements -- Shin Miyakawa (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-02.txt Bridge-like Neighbor Discovery Proxies -- Dave Thaler (15 min) http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-00.txt IPv6 Node Information Queries -- Bob Hinden (15 min) http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-10.txt IPv6 Socket API for source address selection -- Samita Chakrabarti (10 min) http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-addrselect-api-01.txt Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming Shen (10 min) http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options-01.txt Thursday, 0900-1130 (Hall F2) ============================= Introduction and Agenda Review -- Bob Hinden (5 min) Open Issues with Scoped Address Architecture -- TBD (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scoping-arch-00.txt Requirements for Local Addressing: Local Scope Address Requirements -- Tony Hain (15 min) http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-01.txt Requirements for Limited-Scope Unicast Addressing -- Juha Wiljakka (15 min) http://www.ietf.org/internet-drafts/draft-templin-lsareqts-00.txt General Discussion of Local Addressing Requirements -- Chairs (30 min) Unique Local IPv6 Unicast Addresses -- Bob Hinden (20 min) http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-02.txt Site-Local Deprecation Document Plan -- Christian Huitema (30 min) --------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 8 19:19:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h692JV06002634; Tue, 8 Jul 2003 19:19:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h692JVtN002633; Tue, 8 Jul 2003 19:19:31 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h692JK06002618; Tue, 8 Jul 2003 19:19:20 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with SMTP id h692H7tf632702; Tue, 8 Jul 2003 19:17:08 -0700 (PDT) Message-Id: <200307090217.h692H7tf632702@jurassic.eng.sun.com> Date: Tue, 8 Jul 2003 19:17:59 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: IPv6 Advanced Socket API extension for Mobile IP To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Scraw_of_Flies_677_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Scraw_of_Flies_677_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2G743dPlUqAP6OOMkIvB5A== Hello: draft-chakrabarti-mobileip-mipext-advapi-01.txt has been submitted at the mobileip working group. This draft discusses new data structures for mobility headers, changes in neighbor discovery API and accessing mobility headers, home address destination options and type 2 routing headers. The updates to the draft will be discussed in the MIPv6 working group. The updates of the draft was based on the working group input since last IETF. The attached draft (version 2) has some minor modifications and corrections up to the last minute discussions. Thanks, -Samita --Scraw_of_Flies_677_000 Content-Type: TEXT/plain; name="draft-chakrabarti-mobileip-mipext-advapi-02.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: draft-chakrabarti-mobileip-mipext-advapi-02.txt Content-MD5: 2CRT5oH/mawZFj8Q5hKd0Q== INTERNET-DRAFT Samita Chakrabarti Expires: January, 2003 Erik Nordmark Sun Microsystems, Inc. July, 2003 Extension to Sockets API for Mobile IPv6 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires January, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API support for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. Chakrabarti, Nordmark Expires January, 2003 [Page 1] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 This document provides mechanism for API access to retrieve and set information for Mobility Header messages, Home address destination options and Type 2 Routing header extension headers. It also discusses the common data structures and definitions that might be used by advanced Mobile IPv6 socket applications. Table of Contents 1. Introduction ........................................... 3 2. Common Structures and Definitions ...................... 4 2.1 The Mobility Header Data Structures ................ 5 2.2 Mobility Header Constants .......................... 8 2.3 IPv6 Home Address Destination Option ................ 10 2.4 Type 2 Routing Header ............................... 10 2.5 ICMP Mobile IPv6 Messages ........................... 11 2.6 IPv6 Neighbor Discovery Changes ..................... 12 3. Access to Home Address Destination Option and Routing Headers ................................ 14 3.1 Routing Header Access Functions ..................... 14 3.2 Home Address Destination Option Access Functions .... 14 4. Mobility Protocol Headers ............................... 15 4.1 Receiving and Sending Mobility Header Messages ..... 15 5. Protocols File ........................................... 17 6. IPv4-Mapped IPv6 Addresses ............................... 17 7. Security Considerations .................................. 17 8. References ............................................... 18 9. Acknowledgement .......................................... 18 10. Authors' Addresses ....................................... 18 Chakrabarti, Nordmark Expires January, 2003 [Page 2] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 1. Introduction Mobility Support in IPv6 [2] defines a new mobility protocol header, home address destination option and a new routing header type. It is expected that Mobile IPv6 user-level implementations and some applications will need to access and process these IPv6 extension headers. This document is an extension to existing Advanced Sockets API document [1]; it addresses the IPv6 Sockets API for Mobile IPv6 protocol support. The target applications for this socket API is believed to be the debugging and diagnostic applications as well as some policy applications which would like to receive a copy of protocol information at the application layer. This document can be divided into the following parts. 1. Definitions of constants and structures for C programs that capture the Mobile IPv6 packet formats on the wire. A common definition of these is useful at least for packet snooping appplications. This is captured in section 2. 2. Notes on how to use the IPv6 Advanced API to access home address options and type 2 routing headers. This is captured in section 3. 3. Notes on how user-level applications can observe MH (Mobility Header) packets using raw sockets (in section 4). The IPv6 RAW socket interface described in this document, allows applications to receive MH packets whether or not the systems MH processing takes place in the "kernel" or at the "user space". 4. Suggested name for /etc/protocols (in section 5). It is anticipated that Mobile IPv6 will be used widely from mobile devices to Server and Routing platforms. Thus it is useful to have a standard API for portability of Mobile IPv6 applications on a wide variety of platforms and operating systems. Chakrabarti, Nordmark Expires January, 2003 [Page 3] INTERNET-DRAFT Extensions to Sockets API for MIPv6 June, 2003 The packet information along with access to the extension headers (Routing header and Destination options) are specified using the "ancillary data" fields that were added to the 4.3BSD Reno sockets API in 1990. The reason is that these ancillary data fields are part of the Posix.1g standard and should therefore be adopted by most vendors. This is in conformance with Advanced API for IPv6 sockets [1]. This document does not address application access to either the authentication header or the encapsulating security payload header. All examples in this document omit error checking in the favor of brevity. We note that many of the functions and socket options defined in this document may have error returns that are not defined in this document. Many of these possible error returns will be recognized only as implementations proceed. Datatypes in this document follow the Posix.1g format: intN_t means a signed integer of exactly N bits (e.g., int16_t) and uintN_t means an unsigned integer of exactly N bits (e.g., uint32_t). This document provides guidelines on Mobile IPv6 socket applications and believes that some other appropriate standardization body will standardize the APIs along with other IPv6 advanced socket APIs. 2. Common Structures and Definitions This API assumes that the fields in the protocol headers are left in the network byte order, which is big-endian for the Internet protocols. If not, then either these constants or the fields being tested must be converted at run-time, using something like htons() or htonl(). A new header file : Chakrabarti, Nordmark Expires January, 2003 [Page 4] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 2.1. The Mobility Header Data Structures 2.1.1 The ip6_mh Structure The following structure is defined as a result of including . This is fixed part of the mobility header. struct ip6_mh { uint8_t ip6mh_proto; /* NO_NXTHDR by default */ uint8_t ip6mh_hdrlen; /* Header Len in unit of 8 Octets excluding the first 8 Octets */ uint8_t ip6mh_type; /* Type of Mobility Header */ uint8_t ip6mh_resvd; /* Reserved */ uint16_t ip6mh_cksum; /* Mobility Header Checksum */ /* Followed by type specific messages */ }; 2.1.2 Binding Refresh Request Mobility Message struct ip6mh_binding_request { struct ip6_mh ip6mhbr_hdr; uint16_t ip6mhbr_resvd; /* Followed by optional Mobility Options */ }; 2.1.3 Home Address Test Init (HoTI) Message struct ip6mh_home_test_init { struct ip6_mh ip6mhti_hdr; uint16_t ip6mhti_resvd; uint32_t ip6mhti_cookie[2]; /* 64 bit Cookie by MN */ /* Followed by optional Mobility Options */ }; Chakrabarti, Nordmark Expires January, 2003 [Page 5] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 2.1.4 Care-of Address Test Init (CoTI) Message struct ip6mh_careof_test_init { struct ip6_mh ip6mhcti_hdr; uint16_t ip6mhcti_resvd; uint32_t ip6mhcti_cookie[2]; /* 64 bit Cookie by MN */ /* Followed by optional Mobility Options */ }; 2.1.5 Home Address Test (HOT) Message struct ip6mh_home_test { struct ip6_mh ip6mht_hdr; uint16_t ip6mht_nonce_index; uint32_t ip6mht_cookie[2]; /* Cookie from HOTI msg */ uint32_t ip6mht_keygen[2]; /* 64 Bit Key by CN */ /* Followed by optional Mobility Options */ }; 2.1.6 Care Of Address Test (COT) Message struct ip6mh_careof_test { struct ip6_mh ip6mhct_hdr; uint16_t ip6mhct_nonce_index; uint32_t ip6mhct_cookie[2]; /* Cookie from COTI message */ uint32_t ip6mhct_keygen[2]; /* 64bit key by CN */ /* Followed by optional Mobility Options */ }; 2.1.7 Binding Update Mobility Message struct ip6mh_binding_update { struct ip6_mh ip6mhbu_hdr; uint16_t ip6mhbu_seqno; /* Sequence Number */ uint16_t ip6mhbu_flags; uint16_t ip6mhbu_lifetime; /* Time in unit of 4 sec */ /* Followed by optional Mobility Options */ }; /* Binding Update Flags, in network byte-order */ #define IP6MH_BU_ACK 0x8000 /* Request a binding ack */ #define IP6MH_BU_HOME 0x4000 /* Home Registration */ #define IP6MH_BU_LLOCAL 0x2000 /* Link-local compatibility */ #define IP6MH_BU_KEYM 0x1000 /* Key management mobility */ Chakrabarti, Nordmark Expires January, 2003 [Page 6] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 2.1.8 Binding Acknowledgment Mobility Message struct ip6mh_binding_ack { struct ip6_mh ip6mhba_hdr; uint8_t ip6mhba_status; /* Status code */ uint8_t ip6mhba_flags; uint16_t ip6mhba_seqno; uint16_t ip6mhba_lifetime; /* Followed by optional Mobility Options */ }; /* Binding Acknowledgement Flags */ #define IP6MH_BA_KEYM 0x80 /* Key management mobility */ 2.1.9 Binding Error Mobility Message struct ip6mh_binding_error { struct ip6_mh ip6mhbe_hdr; uint8_t ip6mhbe_status; /* Error Status */ uint8_t ip6mhbe_resvd; struct in6_addr ip6mhbe_homeaddr; /* Followed by optional Mobility Options */ }; 2.1.10 Mobility Option TLV data structure struct ip6mh_opt { uint8_t ip6mhopt_type; /* Option Type */ uint8_t ip6mhopt_len; /* Option Length */ /* Followed by variable length Option Data in bytes */ }; Chakrabarti, Nordmark Expires January, 2003 [Page 7] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 2.1.11 Mobility Option Data Structures 2.1.11.1 Binding Refresh Advice struct ip6mh_opt_refresh_advice { uint8_t ip6mora_type; uint8_t ip6mora_len; uint16_t ip6mora_interval; /* Refresh interval in 4 sec */ }; 2.1.11.2 Alternate Care-of Address struct ip6mh_opt_altcoa { uint8_t ip6moa_type; uint8_t ip6moa_len; uint8_t ip6moa_addr[16]; /* Alternate Care-of Address */ }; 2.1.11.3 Nonce Indices struct ip6mh_opt_nonce_index { uint8_t ip6moni_type; uint8_t ip6moni_len; uint16_t ip6moni_hm_nonce; uint16_t ip6moni_coa_nonce; }; 2.1.11.4 Binding Authorization Data struct ip6mh_opt_auth_data { uint8_t ip6moad_type; uint8_t ip6moad_len; /* Followed by authentication data */ }; 2.2 Mobility Header Constants IPv6 Next Header Value for Mobility: #define IPPROTO_MH 62 /* IPv6 Mobility Header: IANA-TBD */ Chakrabarti, Nordmark Expires January, 2003 [Page 8] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 Mobility Header Message Types: #define IP6MH_TYPE_BRR 0 /* Binding Refresh Request */ #define IP6MH_TYPE_HOTI 1 /* HOTI Message */ #define IP6MH_TYPE_COTI 2 /* COTI Message */ #define IP6MH_TYPE_HOT 3 /* HOT Message */ #define IP6MH_TYPE_COT 4 /* COT Message */ #define IP6MH_TYPE_BU 5 /* Binding Update */ #define IP6MH_TYPE_BACK 6 /* Binding ACK */ #define IP6MH_TYPE_BERROR 7 /* Binding Error */ Mobility Header Message Option Types: #define IP6MHOPT_PAD1 0x00 /* PAD1 */ #define IP6MHOPT_PADN 0x01 /* PADN */ #define IP6MHOPT_BREFRESH 0x02 /* Binding Refresh */ #define IP6MHOPT_ALTCOA 0x03 /* Alternate COA */ #define IP6MHOPT_NONCEID 0x04 /* Nonce Index */ #define IP6MHOPT_BAUTH 0x05 /* Binding Auth Data */ Status values accompanied with Mobility Binding Acknowledgement: #define IP6MH_BAS_ACCEPTED 0 /* BU accepted */ #define IP6MH_BAS_PRFX_DISCOV 1 /* Accepted, but prefix discovery Required */ #define IP6MH_BAS_UNSPECIFIED 128 /* Reason unspecified */ #define IP6MH_BAS_PROHIBIT 129 /* Administratively prohibited */ #define IP6MH_BAS_INSUFFICIENT 130 /* Insufficient resources */ #define IP6MH_BAS_HA_NOT_SUPPORTED 131 /* HA registration not supported */ #define IP6MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */ #define IP6MH_BAS_NOT_HA 133 /* Not HA for this mobile node */ #define IP6MH_BAS_DAD_FAILED 134 /* DAD failed */ #define IP6MH_BAS_SEQNO_BAD 135 /* Sequence number out of range */ Chakrabarti, Nordmark Expires January, 2003 [Page 9] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 #define IP6MH_BAS_HOME_NI_EXPIRED 136 /* Expired Home nonce index */ #define IP6MH_BAS_COA_NI_EXPIRED 137 /* Expired Care-of nonce index */ #define IP6MH_BAS_NI_EXPIRED 138 /* Expired Nonce Indices */ #define IP6MH_BAS_REG_NOT_ALLOWED 139 /* Registration type change disallowed */ Status values for the Binding Error mobility messages: #define IP6MH_BES_UNKNOWN_HAO 1 /* Unknown binding for HOA */ #define IP6MH_BES_UNKNOWN_MH 2 /* Unknown MH Type */ 2.3. IPv6 Home Address Destination Option /* Home Address Destination Option */ struct ip6_opt_home_address { uint8_t ip6hoa_type; uint8_t ip6hoa_len; uint8_t ip6hoa_addr[16]; /* Home Address */ }; Option Type Definition: #define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */ 2.4 Type 2 Routing Header /* Type 2 Routing header for Mobile IPv6 */ struct ip6_rthdr2 { uint8_t ip6r2_nxt; /* next header */ uint8_t ip6r2_len; /* length : always 2 */ uint8_t ip6r2_type; /* always 2 */ uint8_t ip6r2_segleft; /* segments left: always 1 */ uint32_t ip6r2_reserved; /* reserved field */ struct in6_addr ip6r2_homeaddr; /* Home Address */ }; Chakrabarti, Nordmark Expires January, 2003 [Page 10] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 2.5 New ICMP Messages for Mobile IPv6 ICMP message types and definitions for Mobile IPv6 are defined in #define MIP_HA_DISCOVERY_REQUEST 150 #define MIP_HA_DISCOVERY_REPLY 151 #define MIP_PREFIX_SOLICIT 152 #define MIP_PREFIX_ADVERT 153 The following data structures can be used for the ICMP message types discussed in section 6.5 through 6.8 in the base Mobile IPv6 [2] specification. struct mip_dhaad_req { /* Dynamic HA Address Discovery */ struct icmp6_hdr mip_dhreq_hdr; }; #define mip_dhreq_type mip_dhreq_hdr.icmp6_type #define mip_dhreq_code mip_dhreq_hdr.icmp6_code #define mip_dhreq_cksum mip_dhreq_hdr.icmp6_cksum #define mip_dhreq_id mip_dhreq_hdr.icmp6_data16[0] #define mip_dhreq_reserved mip_dhreq_hdr.icmp6_data16[1] struct mip_dhaad_rep { /* HA Address Discovery Reply */ struct icmp6_hdr mip_dhrep_hdr; /* Followed by Home Agent IPv6 addresses */ }; #define mip_dhrep_type mip_dhrep_hdr.icmp6_type #define mip_dhrep_code mip_dhrep_hdr.icmp6_code #define mip_dhrep_cksum mip_dhrep_hdr.icmp6_cksum #define mip_dhrep_id mip_dhrep_hdr.icmp6_data16[0] #define mip_dhrep_reserved mip_dhrep_hdr.icmp6_data16[1] struct mip_prefix_solicit { /* Mobile Prefix Solicitation */ struct icmp6_hdr mip_ps_hdr; }; #define mip_ps_type mip_ps_hdr.icmp6_type #define mip_ps_code mip_ps_hdr.icmp6_code #define mip_ps_cksum mip_ps_hdr.icmp6_cksum #define mip_ps_id mip_ps_hdr.icmp6_data16[0] #define mip_ps_reserved mip_ps_hdr.icmp6_data16[1] Chakrabarti, Nordmark Expires January, 2003 [Page 11] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 struct mip_prefix_advert { /* Mobile Prefix Adverisements */ struct icmp6_hdr mip_pa_hdr; /* Followed by one or more PI options */ }; #define mip_pa_type mip_pa_hdr.icmp6_type #define mip_pa_code mip_pa_hdr.icmp6_code #define mip_pa_cksum mip_pa_hdr.icmp6_cksum #define mip_pa_id mip_pa_hdr.icmp6_data16[0] #define mip_pa_flags_reserved mip_pa_hdr.icmp6_data16[1] #define MIP_PA_FLAG_MANAGED 0x8000 #define MIP_PA_FLAG_OTHER 0x4000 Prefix options are defined in IPv6 Advanced Socket API [1]. Mobile IPv6 Base specification [2] describes the modified behavior in 'Modifications to IPv6 Neighbor Discovery' section. Prefix Options for Mobile IP are defined in the following section. 2.6 IPv6 Neighbor Discovery Changes IPv6 Neighbor Discovery changes are also defined in New 'Home Agent' flag in router advertisement: #define ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */ New Router flag with prefix information of the home agent: #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */ As per Mobile IPv6 specification [2] a Home Agent MUST include at least one prefix option with the Rouer Address (R) bit set. Advanced Socket API [1] defines data structure for prefix option as follows: struct nd_opt_prefix_info { /* prefix information */ uint8_t nd_opt_pi_type; uint8_t nd_opt_pi_len; uint8_t nd_opt_pi_prefix_len; uint8_t nd_opt_pi_flags_reserved; uint32_t nd_opt_pi_valid_time; uint32_t nd_opt_pi_preferred_time; uint32_t nd_opt_pi_reserved2; struct in6_addr nd_opt_pi_prefix; }; Chakrabarti, Nordmark Expires January, 2003 [Page 12] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 New advertisement interval option and home agent information options are defined in Mobile IPv6 [2] base specification. struct nd_opt_adv_interval { /* Advertisement interval option */ uint8_t nd_opt_adv_type; uint8_t nd_opt_adv_len; uint16_t nd_opt_adv_reserved; uint32_t nd_opt_adv_interval; }; The option types for the new Mobile IPv6 specific options: #define ND_OPT_ADV_INTERVAL 7 /* Adv Interval Option */ #define ND_OPT_HA_INFORMATION 8 /* HA Information option */ struct nd_opt_homeagent_info { /* Home Agent information */ uint8_t nd_opt_hai_type; uint8_t nd_opt_hai_len; uint16_t nd_opt_hai_reserved; uint16_t nd_opt_hai_preference; uint16_t nd_opt_hai_lifetime; }; 3. Access to Home Address Destination Option and Routing Headers Applications that need to be able to access home address destination option and routing header type 2 information should use the same mechanism defined in Advanced Sockets API for IPv6 in section 4. In order to receive Home Address destination option or route header type 2 extension header, application must call setsockopt() to turn on the corresponding flag: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); When any of these options are enabled, the corresponding data is returned as control information by recvmsg(), as one or more ancillary data objects. Receiving the above information for TCP applications is not defined in this document (see section 4.1 of Advanced Sockets API for IPv6[1]. Chakrabarti, Nordmark Expires January, 2003 [Page 13] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 For sending home address destination option, ancillary data can be used to specify the option content for a single datagram. This only applies to datagram and raw sockets; not to TCP sockets. For TCP data packets with home-address destination option may be used with "sticky" option for all transmitted packets. However, at this point, it is unknown why an application would want to set home-address option along with its data packets as Mobile IPv6 protocol takes care of it transparently at the protocol stack. Similarly it is not clear that if an application would need to set Router Header Type 2 extension to send data packets as it is taken care by the Mobile IPv6 protocol depending on the binding cache information. Thus this document does not specifically discuss the sending of Route Header Type 2 extension header. However, the following socket option parameters and cmsghdr fields may be used for sending the Home Address destination options. opt level/ optname/ optval/ cmsg_level cmsg_type cmsg_data[] ------------ ------------ ------------------------ IPPROTO_IPV6 IPV6_DSTOPTS ip6_dest structure Some IPv6 implementations may support "sticky" options [1] for IPv6 destination option for datagram sockets. 3.1 Routing Header access functions While accessing Routing header Type 2 extension header, one MUST use type = 2 and segment = 1. The following functions are supported for Mobile IPv6 applications for sending and receiving Routing Header Type 2 headers: size_t inet6_rth_space(int type, int segments); void *inet6_rth_init(void *bp, int bp_len, int type, int segments); int inet6_rth_add(void *bp, const struct in6_addr *addr); int inet6_rth_segments(const void *bp); struct in6_addr *inet6_rth_getaddr(const void *bp, int index); NOTE: Reversing operation is not possible using Route Header Type 2 extension header. Chakrabarti, Nordmark Expires January, 2003 [Page 14] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 Detail description and examples of accessing a IPv6 Routing Header are discussed in Advanced API for IPv6 Sockets [1]. 3.2 Home Address Destination Option access functions The application must enable the IPV6_RECVDSTOPTS socket option in order to receive the home address destination option: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); Each Destination option header is returned as one ancillary data object described by a cmsghdr structure with cmsg_level set to IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS. These options are then processed by calling the inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_value() functions as defined in Advanced API for IPv6 sockets [1]. This document assumes that Mobile IPv6 applications will not be allowed to send Home Address Destination Option from the application level, as Mobile IPv6 kernel takes care of sending home-address option and routing header type 2. However, the order of extension headers in conjunction with Home Address option sending is specified in Mobility Support in IPv6 [2] in section 6.3. The Destination options are normally constructed using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_opt_set_val() functions, described in Section 10 of IPv6 Advanced API sockets [1]. 4. Mobility Protocol Headers Mobile IPv6 [2] defines a new IPv6 protocol header to carry mobility messages between Mobile Nodes, Home Agents and Correspondent Nodes. These protocol headers carry Mobile IPv6 Binding messages as well as Return Routability [2] messages. Currently the specification [2] does not allow transport packets (piggybacking) along with the mobility messages. Thus the mobility protocol header can be accessed through a IPv6 RAW socket. A IPv6 RAW socket that is opened for protocol IPPROTO_MH should always be able to see all the MH (Mobility Header) packets. It is possible that future applications may implement part of Mobile IPv6 signal processing at the Chakrabarti, Nordmark Expires January, 2003 [Page 15] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 application level. Having a RAW socket interface may also enable an application to execute the Return Routability protocol or other future authentication protocol involving mobility header at the user level. 4.1 Receiving and Sending Mobility Header Messages This specification recommends IPv6 RAW sockets mechanism to send and receive Mobility Header (MH) packets. The behavior is similar to ICMPV6 processing, where kernel passes a copy of the mobility header packet to the receiving socket. Depending on the implementation kernel may process the mobility header as well in addition to passing the mobility header to the application. If IPV6_CHECKSUM socket option is set on the RAW socket, kernel will calculate the checksum by default and place it on the mobility header before sending it out. Similarly, if IPV6_CHECKSUM is set, the protocol stack will verify the MH checksum on the inbound path and it will discard any MH packet with invalid checksums. Mobility Header checksum procedure is described in Mobile IPv6 Protocol [2] specification. Thus when IPPROTO_MH is used as the protocol field in the RAW socket() call and IPV6_CHECKSUM option is not set, the application needs to fill the checksum field of the mobility header for outbound data. Similarly the application needs to do checksum validity check for the received packet. However, it is recommended that the application set the IPV6_CHECKSUM socket option along with the RAW sockets for IPPROTO_MH. As an example, a program that wants to send or receive mobility header protocol(MH), could open a socket as following: fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH); int offset = 4; setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset)); For example, if an implementation likes to handle HOTI/HOT and COTI/COT message processing, it can do so by using IPv6 RAW Sockets for IPPROTO_MH at the application layer. The same application may also set IPV6_RECVDSTOPTS socket option for receiving home address option in a binding update [2] from the mobile node. Chakrabarti, Nordmark Expires January, 2003 [Page 16] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 5. Protocols File Many hosts provide the file /etc/protocols that contains the names of the various IP protocols and their protocol numbers. The protocol numbers are obtained through function getprotoXXX() functions. The following addition should be made to the /etc/protocols file, in addition to what is defined in section 2.4 of Advanced Sockets API for IPv6 [1]. The protocol number for Mobility is pending IANA (http://www.iana.orgassignments/protocol-numbers) assignment. ipv6-mh 62 # Mobility Protocol Header 6. IPv4-Mapped IPv6 Addresses The same rule applies as described in section 13 of IPv6 Advanced API for Sockets [1]. Thus processing of IPv4-mapped IPv6 addresses for the Mobile IPv6 specific socket options are out of scope of this document. 7. Security Considerations The setting of Home Address Destination option and route header Type 2 IPV6_RTHDR socket option may not be allowed at the application level in order to prevent denial-of-service attacks or man in the middle attacks by hackers. Sending and receiving of mobility header messages are possible by IPv6 RAW sockets. Thus it is assumed that this operation is only possible by priviledged users. However, this API does not prevent the existing security threat from a hacker by sending bogus mobility header or other IPv6 packets using home-address option and Type 2 routing extension header. Chakrabarti, Nordmark Expires January, 2003 [Page 17] INTERNET-DRAFT Extension to Sockets API for MIPv6 June, 2003 8. References [1] Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced Sockets API for IPv6", RFC 3542, May 2003 April 19, 2002. [2] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-22.txt, May, 2003. [3] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6), Specification", RFC 2460, Dec. 1998. 9. Acknowledgement Thanks to Brian Haley for the thorough review of this draft. Keiichi Shima, Alexandru Petrescu, Ryuji Wakikawa, Vijay Devarapalli, Jim Bound, Suvidh Mathur and other mobile-ip working group members provided valuable input during the API design discussion. 10. Authors' Addresses Samita Chakrabarti Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054, USA Email: samita.chakrabarti@Sun.com Erik Nordmark Sun Microsystems Laboratories 180, avenue de l'Europe 38334 SAINT ISMIER Cedex, France Email: Erik.Nordmark@sun.com Chakrabarti, Nordmark Expires January, 2003 [Page 18] --Scraw_of_Flies_677_000-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 8 19:32:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h692We06002877; Tue, 8 Jul 2003 19:32:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h692WdlS002875; Tue, 8 Jul 2003 19:32:39 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h692Wa06002868 for ; Tue, 8 Jul 2003 19:32:36 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h692UNUu029390 for ; Tue, 8 Jul 2003 19:30:23 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h692UH1J009740 for ; Tue, 8 Jul 2003 20:30:18 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 15FB29E; Wed, 9 Jul 2003 11:30:08 +0900 (JST) To: Bob Hinden & Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-reply-to: hinden's message of Wed, 02 Jul 2003 15:45:50 MST. <4.3.2.7.2.20030702140452.02a49658@mailhost.iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" From: itojun@iijlab.net Date: Wed, 09 Jul 2003 11:30:08 +0900 Message-Id: <20030709023008.15FB29E@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is a IPv6 working group last call for comments on advancing the >following document as a Proposed Standard: > Title : IPv6 Node Information Queries > >The chairs believe that this draft resolves the issues raised by the >IESG. Given the time that has elapsed, we thought it was important to have >another working group last call. Changes in this draft include: > > - Move applicability statement to start of document and update > introduction. > - Removed Qtypes query capabilities > - Limit returned TTL in node name to zero and removed text describing > non-zero TTLs. > - Remove text about A6 records > - Change to have all new Qtypes require IETF approval > - Updated security considerations thank you very much for updating the document. as stated in the last call announcement we use it heavily in network troubleshooting, so would really like to see it documented. I would like to see IPv4 address query (Qtype=4) go away. also i don't see a need for IPv4 mapped address (Qtype=3 C bit). it is a protocol for IPv6, afterall (if IPv4 variant is needed, it should be defined on IPv4, or the "name lookup" document has to become protocol- independent). Qtype 3 A bit handling is a little bit complicated. how about moving the description to the top? (right after the first paragraph of 6.3) without understanding A bit, readers cannot understand the interpretation of other bits. on page 3, text for NI query code 1 refers to "Supported Qtypes" which is no longer there (Qtype=1). suggestion: remove text starting from "as in ....". itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 8 19:37:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h692bN06002989; Tue, 8 Jul 2003 19:37:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h692bNSl002988; Tue, 8 Jul 2003 19:37:23 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h692bI06002978 for ; Tue, 8 Jul 2003 19:37:18 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h692Z6UY004032 for ; Tue, 8 Jul 2003 19:35:06 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h692Z0ZV017475 for ; Tue, 8 Jul 2003 20:35:01 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 38FB489; Wed, 9 Jul 2003 11:34:58 +0900 (JST) To: Michael Hunter Cc: Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com In-reply-to: michael.hunter's message of Tue, 08 Jul 2003 11:38:47 MST. <20030708113847.515a22cf.michael.hunter@eng.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" From: itojun@iijlab.net Date: Wed, 09 Jul 2003 11:34:58 +0900 Message-Id: <20030709023458.38FB489@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This looks like a strong draft. Several issues exist though. > >1) There is no mention of RFC 3041 (privacy enhanced) addresses. Both >the issue as to if they should be responded with and if they should be >responded to needs to be addressed. just FYI from implementation POV: KAME implementation does not include RFC3041 addresses in the response by default. there's a configuration flag bit which makes the responder to include RFC3041 addresses as well. i guess that sensible default would be not to include RFC3041 addresses. >2) The security model is unclear as to the scope of responses. There >is a sentence in the "Security Consideration" section which states the >implementation should have a default configuration which refuses to >respond to global scope addresses. > >If this means that the protocol should be limited to link local >addresses that should be stated directly. Use of a 1 Hop Limit or 255 >Hop Limit with check would enforce this (see LLMNR for example and >reasons). I think limiting the protocol to the link local reduces >its usefulness. i really would like to keep it usable globally (= do not limit it to link-local only). we use the protocol to query name of intermediate routers, which is several hops away, for debugging purposes. >If its not limited to the link local then this protocol should probably >be filtered at the edge of the administrative domain. it is up to administrator of the domain, therefore i think recommendation like "SHOULD filter" is too strong. how about "may want to filter" or something like that? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 9 01:55:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h698t106005145; Wed, 9 Jul 2003 01:55:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h698t11t005144; Wed, 9 Jul 2003 01:55:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h698sw06005137 for ; Wed, 9 Jul 2003 01:54:58 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h698qiUY003684 for ; Wed, 9 Jul 2003 01:52:45 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h698qNDT009589 for ; Wed, 9 Jul 2003 02:52:38 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h698ppi05253; Wed, 9 Jul 2003 15:51:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h698pSt04393; Wed, 9 Jul 2003 15:51:34 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Michael Hunter , Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-Reply-To: <20030709023458.38FB489@coconut.itojun.org> References: <20030709023458.38FB489@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Jul 2003 15:51:28 +0700 Message-ID: <3277.1057740688@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 09 Jul 2003 11:34:58 +0900 From: itojun@iijlab.net Message-ID: <20030709023458.38FB489@coconut.itojun.org> | i really would like to keep it usable globally (= do not limit | it to link-local only). we use the protocol to query name of | intermediate routers, which is several hops away, for debugging | purposes. I agree with this, there is nothing about the protocol itself that requires (or demands) that its usage be limited. | it is up to administrator of the domain, therefore i think | recommendation like "SHOULD filter" is too strong. how about | "may want to filter" or something like that? yes, exactly - after all, it isn't as if there are any great secrets being revealed here in any case. Anyone can filter anything that they need to filter from entering or leaving their network - that may decrease the usefulness of their net, there's always that tradeoff. We don't need instructions to tell people that there's something specially dangerous here that requires special filtering - there isn't. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 9 03:49:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h69An106005845; Wed, 9 Jul 2003 03:49:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h69An1nL005844; Wed, 9 Jul 2003 03:49:01 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h69Amw06005837 for ; Wed, 9 Jul 2003 03:48:58 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h69AkiUu022768 for ; Wed, 9 Jul 2003 03:46:44 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h69Akc1J023564 for ; Wed, 9 Jul 2003 04:46:38 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69Akbk01007 for ; Wed, 9 Jul 2003 13:46:37 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 9 Jul 2003 13:46:37 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:46:37 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:46:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34607.5EB2719F" Subject: RE:I-D ACTION:draft-ietf-ipv6-node-requirements-04.txt Date: Wed, 9 Jul 2003 13:46:36 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-node-requirements-04.txt Thread-Index: AcM/6oNeqFGlZ/U0SVSA3F9RK8WpcAGHMOEw From: To: , X-OriginalArrivalTime: 09 Jul 2003 10:46:36.0851 (UTC) FILETIME=[5EF7A830:01C34607] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C34607.5EB2719F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter, =20 Thanks for the comment, I think that this is a reasonable change. =20 John -----Original Message----- From: ext Peter Barany [mailto:pbarany@nortelnetworks.com] Sent: 01 July, 2003 19:01 To: 'ipng@sunroof.eng.sun.com' Subject: FW: I-D ACTION:c Hi,=20 After reading Section 6.1 Transition Mechanisms, I would suggest the = following minor change:=20 6.1 Transition Mechanisms=20 IPv6 nodes SHOULD use native address instead of transition-based = addressing >>INSERT (according to the algorithms defined in RFC 3484). Regards,=20 Pete=20 -----Original Message-----=20 From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, July 01, 2003 6:23 AM=20 Cc: ipng@sunroof.eng.sun.com=20 Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories.=20 This draft is a work item of the IP Version 6 Working Group Working = Group of the IETF.=20 Title : IPv6 Node Requirements=20 Author(s) : J. Loughney=20 Filename : draft-ietf-ipv6-node-requirements-04.txt=20 Pages : 20=20 Date : 2003-6-30=20 =20 This document defines requirements for IPv6 nodes. It is expected=20 that IPv6 will be deployed in a wide range of devices and situations.=20 Specifying the requirements for IPv6 nodes allows IPv6 to function=20 well and interoperate in a large number of situations and=20 deployments.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-04.= txt=20 To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message.=20 Internet-Drafts are also available by anonymous FTP. Login with the = username=20 "anonymous" and a password of your e-mail address. After logging in,=20 type "cd internet-drafts" and then=20 "get draft-ietf-ipv6-node-requirements-04.txt".=20 A list of Internet-Drafts directories can be found in=20 http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 Internet-Drafts can also be obtained by e-mail.=20 Send a message to:=20 mailserv@ietf.org.=20 In the body type:=20 "FILE = /internet-drafts/draft-ietf-ipv6-node-requirements-04.txt".=20 =20 NOTE: The mail server at ietf.org can return the document in=20 MIME-encoded form by using the "mpack" utility. To use this=20 feature, insert the command "ENCODING mime" before the "FILE"=20 command. To decode the response(s), you will need "munpack" or=20 a MIME-compliant mail reader. Different MIME-compliant mail = readers=20 exhibit different behavior, especially when dealing with=20 "multipart" MIME messages (i.e. documents which have been split=20 up into multiple messages), so check your local documentation on = how to manipulate these messages.=20 =20 =20 Below is the data which will enable a MIME compliant mail reader=20 implementation to automatically retrieve the ASCII version of the=20 Internet-Draft.=20 ------_=_NextPart_001_01C34607.5EB2719F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-ietf-ipv6-node-requirements-04.txt

Hi=20 Peter,
 
Thanks=20 for the comment, I think that this is a reasonable = change.
 
John
-----Original Message-----
From: ext Peter Barany=20 [mailto:pbarany@nortelnetworks.com]
Sent: 01 July, 2003=20 19:01
To: 'ipng@sunroof.eng.sun.com'
Subject: FW: = I-D=20 ACTION:c

Hi,

After reading Section 6.1 Transition Mechanisms, I = would=20 suggest the following minor change:

6.1 Transition Mechanisms

    IPv6 nodes SHOULD use native = address=20 instead of transition-based addressing >>INSERT (according to = the=20 algorithms defined in RFC 3484).

Regards,

Pete

-----Original Message-----
From:=20 Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org<= /A>]=20
Sent: Tuesday, July 01, 2003 6:23 AM =
Cc: ipng@sunroof.eng.sun.com
Subject: I-D=20 ACTION:draft-ietf-ipv6-node-requirements-04.txt


A New Internet-Draft is available from the on-line=20 Internet-Drafts directories.
This draft is a = work item=20 of the IP Version 6 Working Group Working Group of the IETF. =

        Title  =20         : IPv6 Node = Requirements=20
        Author(s)       : J. = Loughney=20
        Filename        :=20 draft-ietf-ipv6-node-requirements-04.txt=20
        Pages  =20         : 20=20
        Date    =         :=20 2003-6-30
        =
This document defines requirements for IPv6 nodes.  It = is=20 expected
that IPv6 will be deployed in a = wide range of=20 devices and situations.
Specifying the = requirements=20 for IPv6 nodes allows IPv6 to function
well = and=20 interoperate in a large number of situations and
deployments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-req= uirements-04.txt=20

To remove yourself from the IETF Announcement list, = send a=20 message to
ietf-announce-request with the = word=20 unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. = Login=20 with the username
"anonymous" and a password = of your=20 e-mail address. After logging in,
type "cd=20 internet-drafts" and then=20
        "get=20 draft-ietf-ipv6-node-requirements-04.txt".

A list of Internet-Drafts directories can be found = in=20
http://www.ietf.org/shadow.html<= /A>=20
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt=20


Internet-Drafts can also be obtained by = e-mail.

Send a message to:=20
        mailserv@ietf.org.
In the body = type:=20
        "FILE=20 /internet-drafts/draft-ietf-ipv6-node-requirements-04.txt".=20
       
NOTE:   The mail server at ietf.org can return the = document=20 in
        MIME-encoded form by using the "mpack" utility.  To use=20 this
        feature, insert the command "ENCODING mime" before the = "FILE"=20
        command.  To=20 decode the response(s), you will need "munpack" or=20
        a = MIME-compliant=20 mail reader.  Different MIME-compliant mail readers=20
        exhibit = different=20 behavior, especially when dealing with=20
        "multipart" MIME=20 messages (i.e. documents which have been split=20
        up into = multiple=20 messages), so check your local documentation on=20
        how to = manipulate=20 these messages.
       =20        =20
       =20        
Below is = the data=20 which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.

=

------_=_NextPart_001_01C34607.5EB2719F-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 9 03:50:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h69Aoq06005868; Wed, 9 Jul 2003 03:50:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h69AoqFS005867; Wed, 9 Jul 2003 03:50:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h69Aom06005860 for ; Wed, 9 Jul 2003 03:50:48 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h69AmYUu023091 for ; Wed, 9 Jul 2003 03:48:35 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h69AmSZV011217 for ; Wed, 9 Jul 2003 04:48:29 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69AmSk02536 for ; Wed, 9 Jul 2003 13:48:28 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Jul 2003 13:48:28 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:48:26 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Jul 2003 13:48:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 w.g. Last Call on "IPv6 Node Requirements" Date: Wed, 9 Jul 2003 13:48:26 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Node Requirements" Thread-Index: AcNAIKKgrJkwFt9TQ8mGc0iQ75QP1QF5tSuQ From: To: X-OriginalArrivalTime: 09 Jul 2003 10:48:26.0513 (UTC) FILETIME=[A054C010:01C34607] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h69Aon06005861 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, So far, it seems that there has been limited comments on this. I could assume that everyone's read it & is satisfied. However, there is still plenty of time to get comments on this, so please read it. thanks, John > This is a IPv6 working group last call for comments on advancing the > following document as an Informational RFC: > > Title : IPv6 Node Requirements > Author(s) : J. Loughney > Filename : draft-ietf-ipv6-node-requirements-04.txt > Pages : 20 > Date : 2003-6-30 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end on 15 > July 2003. > > Bob Hinden / Margaret Wasserman > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 9 06:04:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h69D4X06006803; Wed, 9 Jul 2003 06:04:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h69D4Xel006802; Wed, 9 Jul 2003 06:04:33 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h69D4T06006795 for ; Wed, 9 Jul 2003 06:04:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h69D2FUY024741 for ; Wed, 9 Jul 2003 06:02:15 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h69D29fU001801 for ; Wed, 9 Jul 2003 06:02:10 -0700 (PDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h69D238w291026; Wed, 9 Jul 2003 09:02:07 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-237-154.mts.ibm.com [9.65.237.154]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h69D1uSo036376; Wed, 9 Jul 2003 07:01:56 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h69D0Zq10846; Wed, 9 Jul 2003 09:00:39 -0400 Message-Id: <200307091300.h69D0Zq10846@cichlid.adsl.duke.edu> To: "Tony Hain" cc: ipng@sunroof.eng.sun.com Subject: AD response to Site-Local Appeal Date: Wed, 09 Jul 2003 09:00:35 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Note that this message is very long because it includes the cited email messages verbatim; we are not aware of an IPv6 WG mailing list archive that provide URL references for individual emails.] Tony, We have reviewed your appeal of the IPv6 WG chairs calling of consensus to deprecate site-local addresses from the IPv6 architecture. We believe they have acted properly, and indeed, have done an admirable job of moving the WG forward on a complex, subtle and divisive topic that has troubled the WG and the IETF as a whole for a long time. We find that the chairs have responded reasonably and appropriately to your appeal and agree with their response. Based on our review, we reject your appeal in its entirety. Some specifics: Your appeal seems to center around the point that different people had different reasons for responding to the question of whether or not to deprecate SLs and that those reasons were different enough that it isn't appropriate to use those differing reasons to conclude a single outcome, namely to deprecate SLs. We disagree. The question asked by the chairs was not about the differing reasons, the question was specifically about SLs, and whether the WG wanted to deprecate them. That the question referred specifically to deprecating site locals (and not the reasons why one might do so) is obvious. It is common in the IETF when deciding technical issues for different people to have different reasons for coming to a particular conclusion, or to weigh tradeoffs differently. In the end, if there is consensus on the answer to a specific question, we have consensus, even if the reasons for reaching a particular outcome are not shared. In your response to the chairs [8], "Tony Hain" writes: > Margaret Wasserman wrote: > > (3) You do not believe that there is rough consensus to > > deprecate IPv6 site-local addressing, because people > > provided different reasons for why they believe that > > IPv6 site-local addressing should be deprecated. In > > particular, some people want to deprecate the particular > > model of site-local addressing defined in the scoped > > addressing architecture (ambiguous, scoped addresses), > > while others do not believe that we need a local > > addressing mechanism at all. > I was not objecting to 'different reasons'. The specific complaint is > that many of YES votes were for removing the architectural construct, or > need for applications to deal with addresses that are only accessable > over a limited scope. That is not in the purview of the IETF to decide, > it is an operational decision of the network manager. Those votes are > not valid as a result. It is certainly within the purview of a WG (and/or IETF) to decide what it wants to work on. Given that the IETF defined a designated site-local prefix in RFC 1884 it can also choose to undo that definition. This doesn't remove the ability for network managers to do filtering, or remove their ability to allocate address ranges for any particular purpose including "local use". Moreover, if the WG does not want to work on defining a model that requires applications to deal with "addresses that are only accessible over a limited scope", it can certainly make such a choice. We also note that you seem to have a broader definition of "scoping" (and the requirements that must be met by the architecture to support such scoping) than many, and you appear to be choosing to view the decision to deprecate SLs as an attempt to outlaw (or eliminate) all forms of such scoping, including the ability of site operators to filter on arbitrary addresses (which you seem to include in your definition). This view is incorrect. The decision to deprecate SLs is just that. It is not a decision to outlaw all forms of scoping or to forbid operators from (say) filtering packets based on addresses. > > Point (4): > > > > It is true that the IPv6 WG has not produced a WG document > > that analyzes the operational requirements for local > > addressing. However, we do not believe that this is a reason > > to invalidate the IPv6 WG consensus to deprecate IPv6 > > site-local unicast addressing. > You said it multiple times in SF yourself, the WG needs complete > documentation to do an appropriate analysis. You appear to be letting > your desire to 'be right' get in the way of your ability to analyze your > own responses. I don't understand how can you objectively say 'we don't > need a document describing the need for X to decide that we don't need > X'? The key issue is whether the community believes it has enough information to make a decision and is ready to make a decision. When complex issues are being discussed it is important that sufficient information is available and that the issue has been thought through. In such cases it makes sense to try to get detailed documentation listing the pros and cons of the choices, e.g., as internet-drafts, or as part of email discussions. So while the advance availability of an internet-draft on deprecation would have been good, what matters in the end is whether the community believes it has enough information to make a decision. During the meeting (early on) one person suggested that there wasn't enough information on which to base a decision. But this claim didn't appear to resonate with others, either in the meeting or on the mailing list. If a large number of WG participants had agreed with the claim, one would have expected them to speak up. Hence one can infer that the WG felt that there was sufficient information to make a decision. In [6] you say: > >>> There is a vast difference between identifying direction of > the group and the actual yes/no to deprecate SL question that was asked. > In fact all other indications from the chairs were that the question was > NOT about measuring direction of the WG, but actually about their intent > to have local scoped addresses removed from the scoped address > architecture and other documents. The question asked was about a general direction for the WG to go in. The alternative to "direction" would have been a question about an existing document (such as an update to the addressing architecture doc to deprecate SLs) which was clearly not what was being asked. In summary, the INT ADs do not agree with the points that you have raised in your appeal, and we do not agree to overturn the consensus of the IPv6 WG based on the issues that you have raised. We would also like to point out that while we disagree with your position on this particular issue, we do recognize the contributions you have made to the IPv6 effort and we realize that your appeal is motivated by your desire to do what you believe is the right thing for IPv6. We hope that you will accept our response and focus on working to define the local addressing problem and solutions in the IPv6 WG. It is important for the working group to move forward on this issue. Thomas Narten & Erik Nordmark Internet Area ADs References: [1] Message from chairs to list, announcing results of consensus call. Return-Path: owner-ipng@sunroof.eng.sun.com Message-Id: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> Date: Wed, 09 Apr 2003 15:11:04 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: Consensus on Site-Local Addressing Hi All, Well, that was fun! :-) All told, there were over 200 responses to the consensus call on IPv6 site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 site-local unicast addressing. The final count (including the room and the mailing list) was: 155 YES, 56 NO (211 Total). There were also a significant number of the people on both sides of this issue that voiced (in their original responses, or in subsequent messages) a strong belief that we should investigate alternative mechanisms for local addressing and local access control. The chairs have read all of the messages on the list, and based on your considerable input, we have determined that the IPv6 WG does have rough consensus to deprecate the usage of IPv6 site-local unicast addressing AND to investigate alternative mechanisms for local addressing and local access control. In particular, the IPv6 WG will work to accomplish the following things in parallel: (1) Publish an informational document that explains the issues encountered with site-local addressing and our reasons for deprecating IPv6 site-local unicast addresses. This document will officially deprecate site-local addressing. (2) Remove site-local unicast addressing from the IPv6 scoped addressing architecture I-D, and publish the parts of the document on which we do have consensus (i.e., link local addresses, multicast, etc.). This will include a note that the IPv6 working group is investigating other forms of local IPv6 addressing and that the usage of any new forms of local addresses will be documented elsewhere. (3) Update the IPv6 addressing architecture to indicate that the usage of the FECO::/10 prefix for site-local addressing is deprecated. To maintain backward compatibility with existing implementations the prefix should be reserved and should not be allocated for other purposes. (4) Define and publish the requirements for a local addressing mechanism to provide: - Addresses for disconnected networks. - Addresses for intermittently connected networks. - Addresses that support merging of sites. - Stable local addresses for changing ISPs without disrupting local communication. Once we have consensus on the requirements, the IPv6 WG will work on solutions for local addressing that meet those requirements. (5) Define and publish the requirements for a local access control mechanism, then work on a solution that meets those requirements. Each of these new work items will need to be added to the IPv6 WG charter and will go through the normal IETF document processes. For (4) and (5) it is important to make the rest of the IETF community aware that the IPv6 WG is undertaking these tasks, so we will consider methods to invite wider review and discussion of these problems. IPv6 site-local addressing has been a contentious issue in the IPv6 WG for some time, and we are both glad to see the WG reach consensus on this issue. This will allow us to complete and publish the IPv6 scoped addressing architecture document, an important part of the IPv6 specification. We hope that people on all sides of this issue will respect the rough consensus of the WG, and will work with us to achieve the goals outlined above. Thanks to everyone who expressed an opinion during this discussion. Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- [2] First message from Tony Hain appealing decision. Return-Path: owner-ipng@sunroof.eng.sun.com From: "Tony Hain" To: "'Thomas Narten'" , "'Erik Nordmark'" Cc: Subject: FW: Consensus on Site-Local Addressing Date: Wed, 9 Apr 2003 17:41:32 -0700 Message-Id: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> Thomas & Erik, Please consider this the second step in the appeal process, as I have already discussed these issues with the chairs on more than one occasion. 'we reject kings, presidents and voting...' The consensus measurement on the mail list was much more indicative of the real lack of it (60/40%), than what was effectively ballot stuffing by WG visitors without a complete context. There was a very short presentation in the apps open area, intended to raise concerns and incite involvement, were those in the apps area were agitated, then invited to the IPv6 WG session in SF to discuss the potential issues. The subsequent short discussion in the IPv6 WG showed there were issues to work through, and at least one question voiced about understanding the requirements. Rather than deal with the issues raised, the chairs decided to call an ambiguous question of yes/no for deprecation. While the chairs do in 2) recognize their interpretation of the consensus that the WG will investigate other forms of local addressing, there is no mention of ambiguity and the rest of the wording of 1) & 2) can be interpreted as local scope addressing is deprecated. The concern is that we will end up with a document lacking local scope addressing, and claims that we had consensus to remove local scope from the architecture. Many of those who bothered to state why they were expressing a yes opinion claimed ambiguity was the reason, while others were only interested in removing special handling for local scope addresses. Those are technically different issues, so they need different questions. What we have is an indication that many are unhappy with the status quo, but a lack of recognition that the call ended up combining yes opinions for removing ambiguity with yes opinions for removing local scope addresses from the architecture. From subsequent discussions with the chairs, it is clear that was not their intent, but never the less that is the result of the lack of clarity in this consensus call. '... we believe in rough consensus & running code' & from the Tao : 'running code wins' On several related mail threads there were many comments about running code, and at least Brian Zill & Brian Haberman said they collectively had host, application, and router implementations of the current SL running. Point 3) even acknowledges there are existing implementations. This consensus call intends to invalidate the running code, and all we have to replace it is a promise in 4) that if the group can ever agree that operational requirements of the site network manager are worth solving, we might start to work on solutions, subject to appropriate charter updates. This whole discussion is based on the argument that some developers couldn't create running code for an arguably bogus scenario where topology locators are blindly passed outside their scope of relevance. Bias was given to the opinions of those with a lack of running code, at the expense of, and with the specific intent of invalidating the code that exists. There were also claims in the meeting and mail threads that we have analyzed site local as currently defined, and it doesn't meet the requirements. At the same time, there is a recognition by many of the same people that we need to develop a complete set of requirements. It should be obvious that the analysis is flawed if the complete set of requirements are not understood first. To that end, and in the spirit of making progress, draft-hain-ipv6-sitelocal-00.txt was processed by the I-D editor on 4/8, and is offered as an attempt to document the requirements for address space with a local scope of relevance. It is clearly incomplete, and largely based on my previous email on the subject. While I contest the claim that the Yes/No opinions expressed measured consensus for a consistent interpretation of what 'deprecate site local addresses' means, I do believe that a set of work items for the group were identified. It is also clear that we can add new work to a group at any time, without the need to remove existing items first. I agree with the chairs that items 4) & 5) are valid outcomes of the subsequent discussion, though one thing that their interpretation of the result does not make clear is the meaning of 'accomplish the following things in parallel:'. In talking to the chairs it appears the intent is to start the work at the same time, but we need to avoid invalid transition states, so parallel needs to mean that all 5 are to be forwarded to the IESG at one time. In particular, without solutions to the requirements in hand, any documents for 1) & 3) that intend to deprecate the only local use address space will simply create chaos, and might need to be rescinded if the complete set of requirements shows a need with no other technical approach. In short, I do not believe the consensus call measured the opinions that were consistent the chairs interpretation of the question, so the claimed results are invalid. I do believe that the effort identified work items 4) & 5), with the potential that 1) & 3) might follow if there are no outstanding requirements for ambiguous address space. I question the wisdom of 2), but will reserve judgment until the complete text identifying further work is spelled out. In any case, I hope this appeal can be dealt with at this level, and that the overall effort results in an expedited charter update. It is imperative that new approaches exist prior to removal of the current, and there is a very real danger that the current destructive energy will dissipate in the face of the hard work of creating replacements. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bob > Hinden & Margaret Wasserman > Sent: Wednesday, April 09, 2003 3:11 PM > To: ipng@sunroof.eng.sun.com > Subject: Consensus on Site-Local Addressing > > > Hi All, > > Well, that was fun! :-) > > All told, there were over 200 responses to the consensus call on IPv6 > site-local addressing, approximately 3-to-1 in favor of > deprecating IPv6 > site-local unicast addressing. The final count (including > the room and the > mailing list) was: 155 YES, 56 NO (211 Total). > > There were also a significant number of the people on both > sides of this > issue that voiced (in their original responses, or in > subsequent messages) > a strong belief that we should investigate alternative > mechanisms for local > addressing and local access control. > > The chairs have read all of the messages on the list, and > based on your > considerable input, we have determined that the IPv6 WG does > have rough > consensus to deprecate the usage of IPv6 site-local unicast > addressing AND > to investigate alternative mechanisms for local addressing > and local access > control. > > In particular, the IPv6 WG will work to accomplish the > following things in > parallel: > > (1) Publish an informational document that explains the issues > encountered with site-local addressing and our reasons > for deprecating IPv6 site-local unicast addresses. This > document will officially deprecate site-local addressing. > > (2) Remove site-local unicast addressing from the IPv6 > scoped addressing architecture I-D, and publish the > parts of the document on which we do have consensus > (i.e., link local addresses, multicast, etc.). This > will include a note that the IPv6 working group is > investigating other forms of local IPv6 addressing and > that the usage of any new forms of local addresses will be > documented elsewhere. > > (3) Update the IPv6 addressing architecture to indicate that the > usage of the FECO::/10 prefix for site-local addressing is > deprecated. To maintain backward compatibility with existing > implementations the prefix should be reserved and should not > be allocated for other purposes. > > (4) Define and publish the requirements for a local addressing > mechanism to provide: > - Addresses for disconnected networks. > - Addresses for intermittently connected networks. > - Addresses that support merging of sites. > - Stable local addresses for changing ISPs without > disrupting local communication. > Once we have consensus on the requirements, the IPv6 > WG will work on solutions for local addressing that > meet those requirements. > > (5) Define and publish the requirements for a local access > control mechanism, then work on a solution that meets > those requirements. > > Each of these new work items will need to be added to the > IPv6 WG charter > and will go through the normal IETF document processes. For > (4) and (5) it > is important to make the rest of the IETF community aware > that the IPv6 WG > is undertaking these tasks, so we will consider methods to > invite wider > review and discussion of these problems. > > IPv6 site-local addressing has been a contentious issue in > the IPv6 WG for > some time, and we are both glad to see the WG reach consensus on this > issue. This will allow us to complete and publish the IPv6 scoped > addressing architecture document, an important part of the > IPv6 specification. > > We hope that people on all sides of this issue will respect the rough > consensus of the WG, and will work with us to achieve the > goals outlined above. > > Thanks to everyone who expressed an opinion during this discussion. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- [3] Note from Tony Hain indicating he will followup with chairs first. Return-Path: owner-ipng@sunroof.eng.sun.com From: "Tony Hain" To: "'Thomas Narten'" Cc: "'Erik Nordmark'" , Subject: RE: FW: Consensus on Site-Local Addressing Date: Thu, 10 Apr 2003 10:04:41 -0700 Message-Id: <0f9101c2ff83$46f11ac0$ee1a4104@eagleswings> Thomas Narten wrote: > Tony, > > > Please consider this the second step in the appeal process, > as I have > > already discussed these issues with the chairs on more than one > > occasion. > > Discussing general issues with the chairs is not the same as > finding disagreement with a specific action that the chairs > have taken. I suspect you have done the former, but not the > latter. If you feel that the chairs have erred, and that they > have taken an action that isn't supported by the processes as > outlined in RFC 2026 (and RFC 2418), an appeal might be > warranted. To file an appeal, the process is outlined in RFC > 2026. Start with the chairs, use RFC 2026/2418 as a guide for > what are appropriate grounds for an appeal, and be clear > about what action (or inaction) you specifically have issue > with and want reconsidered. Suggesting what remedy you > believe is appropriate would also be useful. Well I did specifically discuss a disagreement with the action of the chairs in calling the ambiguous question, but I will accept this deferral and redirect the current appeal comment to the chairs. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- [4] Note from chairs to Tony Hain requesting clarification Message-Id: <5.1.0.14.2.20030411094553.040e3040@mail.windriver.com> Date: Fri, 11 Apr 2003 10:16:09 -0400 To: Tony Hain From: Margaret Wasserman Subject: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Cc: Bob Hinden , Thomas Narten , Erik Nordmark , ipng@sunroof.eng.sun.com Hi Tony, Based on your messages below, we understand that you are attempting to start an appeal regarding the IPv6 WG's decision to deprecate IPv6 site-local unicast addressing. However, it is not entirely clear to us what action (or inaction) you are appealing and on what grounds. We understand that you disagree with the WGs decision to deprecate IPv6 site-local unicast addressing without first defining an alternative local addressing mechanism, but that is not, in itself, grounds for an appeal. In order for us to consider this appeal, you should follow the appeals process outlined in section 6.5.4 of RFC 2026. Your appeal should include a "detailed and specific description of the facts of the dispute". In particular, you should make it clear exactly what action (or inaction) you are appealing. You must also indicate what grounds you have for appealing that action (or inaction). There are two possible grounds for appeal of a WG action, listed in RFC 2026, section 6.5.1: (a) [your] own views have not been adequately considered by the Working Group, or (b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. It might also be possible to raise a process appeal if you believe that the chairs violated the process for session management described in section 3.3 of RFC 2418. Please explicitly state what you are appealing and explain your grounds for appeal. You should also supply any information necessary to explain and support your position. Once we have this information, we will carefully consider your appeal and provide a written reply. We understand that your appeal is motivated by your desire to do the right thing for IPv6, and we will make every attempt to deal with it fairly and promptly. Bob Hinden & Margaret Wasserman IPv6 WG Chairs >Reply-To: >From: "Tony Hain" >To: "'Bob Hinden'" , > "'Margaret Wasserman'" >Cc: >Subject: FW: Consensus on Site-Local Addressing >Date: Thu, 10 Apr 2003 10:31:47 -0700 >X-Mailer: Microsoft Outlook, Build 10.0.4510 >Importance: Normal >X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com >id h3AHY8mh023731 >Sender: owner-ipng@sunroof.eng.sun.com > >Bob & Margaret, > >As I noted to Thomas a few moments ago, I have already raised concerns >about the initial action of calling the ambiguous question. I believe >his response indicates I also need to raise a concern with you about >this specific action of declaring consensus. As the content of the note >below indicates, there can be no consensus because the question was not >clear. At best, this activity shows a desire to change the status quo, >but it does not and can not indicate anything else. The consensus >declaration must be voided. > >As I note below, steps 4) & 5) indicate work that the group believes we >should take on. *If* the result of that work leaves us with no further >use for the current definition for an ambiguous address space, then in >that context I believe steps 1) & 3) are appropriate. Until then they >are not, and are very likely to create chaos, particularly if done >before 4) delivers complete alternatives. > >You must void the declaration of consensus, and should recognize that >the original question was not clear. > >Tony > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > > Sent: Wednesday, April 09, 2003 5:42 PM > > To: 'Thomas Narten'; 'Erik Nordmark' > > Cc: ipng@sunroof.eng.sun.com > > Subject: FW: Consensus on Site-Local Addressing > > > > > > Thomas & Erik, > > > > Please consider this the second step in the appeal process, > > as I have already discussed these issues with the chairs on > > more than one occasion. > > > > 'we reject kings, presidents and voting...' > > The consensus measurement on the mail list was much more > > indicative of the real lack of it (60/40%), than what was > > effectively ballot stuffing by WG visitors without a complete > > context. There was a very short presentation in the apps open > > area, intended to raise concerns and incite involvement, were > > those in the apps area were agitated, then invited to the > > IPv6 WG session in SF to discuss the potential issues. The > > subsequent short discussion in the IPv6 WG showed there were > > issues to work through, and at least one question voiced > > about understanding the requirements. Rather than deal with > > the issues raised, the chairs decided to call an ambiguous > > question of yes/no for deprecation. > > > > While the chairs do in 2) recognize their interpretation of > > the consensus that the WG will investigate other forms of > > local addressing, there is no mention of ambiguity and the > > rest of the wording of 1) & 2) can be interpreted as local > > scope addressing is deprecated. The concern is that we will > > end up with a document lacking local scope addressing, and > > claims that we had consensus to remove local scope from the > > architecture. Many of those who bothered to state why they > > were expressing a yes opinion claimed ambiguity was the > > reason, while others were only interested in removing special > > handling for local scope addresses. Those are technically > > different issues, so they need different questions. What we > > have is an indication that many are unhappy with the status > > quo, but a lack of recognition that the call ended up > > combining yes opinions for removing ambiguity with yes > > opinions for removing local scope addresses from the > > architecture. From subsequent discussions with the chairs, it > > is clear that was not their intent, but never the less that > > is the result of the lack of clarity in this consensus call. > > > > '... we believe in rough consensus & running code' & from the > > Tao : 'running code wins' On several related mail threads > > there were many comments about running code, and at least > > Brian Zill & Brian Haberman said they collectively had host, > > application, and router implementations of the current SL > > running. Point 3) even acknowledges there are existing > > implementations. This consensus call intends to invalidate > > the running code, and all we have to replace it is a promise > > in 4) that if the group can ever agree that operational > > requirements of the site network manager are worth solving, > > we might start to work on solutions, subject to appropriate > > charter updates. This whole discussion is based on the > > argument that some developers couldn't create running code > > for an arguably bogus scenario where topology locators are > > blindly passed outside their scope of relevance. Bias was > > given to the opinions of those with a lack of running code, > > at the expense of, and with the specific intent of > > invalidating the code that exists. > > > > There were also claims in the meeting and mail threads that > > we have analyzed site local as currently defined, and it > > doesn't meet the requirements. At the same time, there is a > > recognition by many of the same people that we need to > > develop a complete set of requirements. It should be obvious > > that the analysis is flawed if the complete set of > > requirements are not understood first. To that end, and in > > the spirit of making progress, > > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > > editor on 4/8, and is offered as an attempt to document the > > requirements for address space with a local scope of > > relevance. It is clearly incomplete, and largely based on my > > previous email on the subject. > > > > While I contest the claim that the Yes/No opinions expressed > > measured consensus for a consistent interpretation of what > > 'deprecate site local addresses' means, I do believe that a > > set of work items for the group were identified. It is also > > clear that we can add new work to a group at any time, > > without the need to remove existing items first. I agree with > > the chairs that items 4) & 5) are valid outcomes of the > > subsequent discussion, though one thing that their > > interpretation of the result does not make clear is the > > meaning of 'accomplish the following things in parallel:'. In > > talking to the chairs it appears the intent is to start the > > work at the same time, but we need to avoid invalid > > transition states, so parallel needs to mean that all 5 are > > to be forwarded to the IESG at one time. In particular, > > without solutions to the requirements in hand, any documents > > for 1) & 3) that intend to deprecate the only local use > > address space will simply create chaos, and might need to be > > rescinded if the complete set of requirements shows a need > > with no other technical approach. > > > > In short, I do not believe the consensus call measured the > > opinions that were consistent the chairs interpretation of > > the question, so the claimed results are invalid. I do > > believe that the effort identified work items 4) & 5), with > > the potential that 1) & 3) might follow if there are no > > outstanding requirements for ambiguous address space. I > > question the wisdom of 2), but will reserve judgment until > > the complete text identifying further work is spelled out. In > > any case, I hope this appeal can be dealt with at this level, > > and that the overall effort results in an expedited charter > > update. It is imperative that new approaches exist prior to > > removal of the current, and there is a very real danger that > > the current destructive energy will dissipate in the face of > > the hard work of creating replacements. > > > > Tony > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- [5] Note from Tony Hain clarifying his appeal. From: "Tony Hain" To: "'Margaret Wasserman'" , "'Tony Hain'" Cc: "'Bob Hinden'" , "'Thomas Narten'" , "'Erik Nordmark'" , Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Fri, 11 Apr 2003 10:07:44 -0700 Message-Id: <106f01c3004c$deceb8b0$ee1a4104@eagleswings> Margaret Wasserman wrote: > Hi Tony, > > Based on your messages below, we understand that you are > attempting to start an appeal regarding the IPv6 WG's > decision to deprecate IPv6 site-local unicast addressing. > However, it is not entirely clear to us what action (or > inaction) you are appealing and on what grounds. What is not clear about? >> As the content of the note below indicates, there can >> be no consensus because the question was not clear. >>> Many of those who bothered to state why they were >>> expressing a yes opinion claimed ambiguity was the >>> reason, while others were only interested in removing >>> special handling for local scope addresses. Those are >>> technically different issues, so they need different >>> questions. >>> In short, I do not believe the consensus call measured >>> the opinions that were consistent the chairs >>> interpretation of the question, so the claimed results >>> are invalid. > We > understand that you disagree with the WGs decision to > deprecate IPv6 site-local unicast addressing without first > defining an alternative local addressing mechanism, but that > is not, in itself, grounds for an appeal. I can't disagree because the WG did not reach a decision, the chairs declared one. There were different interpretations of what people were voting YES for, therefore there was no decision. The chairs combined YES get rid of scoping, with YES get rid of ambiguity responses to arrive at a count. That does not constitute a WG decision. > > In order for us to consider this appeal, you should follow > the appeals process outlined in section 6.5.4 of RFC 2026. > Your appeal should include a "detailed and specific > description of the facts of the dispute". In particular, you > should make it clear exactly what action (or inaction) you > are appealing. >> You must void the declaration of consensus, and should >> recognize that the original question was not clear. The question asked was: Should we deprecate IPv6 site-local unicast addressing? The answers indicated that some interpreted that as deprecation of address scoping, while others interpreted it as remove the ambiguity associated with the current definition of the FEC0::/10 prefix. Those are technically different issues and require separate questions, yet the chairs combined the disparate YES votes for each perspective into their own interpretation of what the original question meant. This is not WG consensus. > > You must also indicate what grounds you have for appealing > that action (or inaction). There are two possible grounds > for appeal of a WG action, listed in RFC 2026, section 6.5.1: > > (a) [your] own views have not been adequately considered > by the Working Group, or > (b) the Working Group has made an incorrect technical choice > which places the quality and/or integrity of the Working > Group's product(s) in significant jeopardy. The working group was mislead by an ambiguous question from the chairs, and has not reached a consensus on anything other than more work needs to be done. Some of the YES votes were for removal of scopes from the architecture, and others were for removing ambiguous addresses as SL is currently defined. Those are technically different concepts requiring different questions. The declaration of consensus by the chairs indicates an incorrect technical choice which places the integrity of the WG product in significant jeopardy. > > It might also be possible to raise a process appeal if you > believe that the chairs violated the process for session > management described in section 3.3 of RFC 2418. Well since you brought it up, the agenda listed Limited Usage, and Moderate Usage as the topics of discussion. Then (someone that was there should verify this, but I have been told that) your presentation listed: Full Moderate Exclusive Limited No SLs and you started the presentation by saying that the first one and the last one were not under consideration. Later you call an ambiguous question attempting to accomplish the last one. Is that proper session management? If people are led to believe a topic will not be discussed, they are less likely to come prepared to discuss it, or stick around to make sure their views are heard during a discussion. I can only question, maybe others that were there will appeal based on mismanagement. > > Please explicitly state what you are appealing and explain > your grounds for appeal. You should also supply any > information necessary to explain and support your position. > Once we have this information, we will carefully consider > your appeal and provide a written reply. I believe I did this in the original note to Thomas & Erik, which was included in the subsequent note of appeal to the chairs. I am appealing the declaration of consensus based on an ambiguous question, where some responses indicate remove addresses with local scope while others indicate remove ambiguity of the address range. > > We understand that your appeal is motivated by your desire to > do the right thing for IPv6, and we will make every attempt > to deal with it fairly and promptly. >From my reading, this response does not indicate a desire for promptness. Tony > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > >Reply-To: > >From: "Tony Hain" > >To: "'Bob Hinden'" , > > "'Margaret Wasserman'" > >Cc: > >Subject: FW: Consensus on Site-Local Addressing > >Date: Thu, 10 Apr 2003 10:31:47 -0700 > >X-Mailer: Microsoft Outlook, Build 10.0.4510 > >Importance: Normal > >X-MIME-Autoconverted: from quoted-printable to 8bit by > >sunroof.eng.sun.com > >id h3AHY8mh023731 > >Sender: owner-ipng@sunroof.eng.sun.com > > > >Bob & Margaret, > > > >As I noted to Thomas a few moments ago, I have already > raised concerns > >about the initial action of calling the ambiguous question. > I believe > >his response indicates I also need to raise a concern with you about > >this specific action of declaring consensus. As the content > of the note > >below indicates, there can be no consensus because the > question was not > >clear. At best, this activity shows a desire to change the > status quo, > >but it does not and can not indicate anything else. The consensus > >declaration must be voided. > > > >As I note below, steps 4) & 5) indicate work that the group > believes we > >should take on. *If* the result of that work leaves us with > no further > >use for the current definition for an ambiguous address > space, then in > >that context I believe steps 1) & 3) are appropriate. Until > then they > >are not, and are very likely to create chaos, particularly if done > >before 4) delivers complete alternatives. > > > >You must void the declaration of consensus, and should > recognize that > >the original question was not clear. > > > >Tony > > > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > > > Sent: Wednesday, April 09, 2003 5:42 PM > > > To: 'Thomas Narten'; 'Erik Nordmark' > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: FW: Consensus on Site-Local Addressing > > > > > > > > > Thomas & Erik, > > > > > > Please consider this the second step in the appeal process, as I > > > have already discussed these issues with the chairs on > more than one > > > occasion. > > > > > > 'we reject kings, presidents and voting...' > > > The consensus measurement on the mail list was much more > indicative > > > of the real lack of it (60/40%), than what was effectively ballot > > > stuffing by WG visitors without a complete context. There > was a very > > > short presentation in the apps open area, intended to > raise concerns > > > and incite involvement, were those in the apps area were > agitated, > > > then invited to the IPv6 WG session in SF to discuss the > potential > > > issues. The subsequent short discussion in the IPv6 WG > showed there > > > were issues to work through, and at least one question voiced > > > about understanding the requirements. Rather than deal with > > > the issues raised, the chairs decided to call an ambiguous > > > question of yes/no for deprecation. > > > > > > While the chairs do in 2) recognize their interpretation of the > > > consensus that the WG will investigate other forms of local > > > addressing, there is no mention of ambiguity and the rest of the > > > wording of 1) & 2) can be interpreted as local scope > addressing is > > > deprecated. The concern is that we will end up with a document > > > lacking local scope addressing, and claims that we had > consensus to > > > remove local scope from the architecture. Many of those > who bothered > > > to state why they were expressing a yes opinion claimed ambiguity > > > was the reason, while others were only interested in removing > > > special handling for local scope addresses. Those are technically > > > different issues, so they need different questions. What we > > > have is an indication that many are unhappy with the status > > > quo, but a lack of recognition that the call ended up > > > combining yes opinions for removing ambiguity with yes > > > opinions for removing local scope addresses from the > > > architecture. From subsequent discussions with the chairs, it > > > is clear that was not their intent, but never the less that > > > is the result of the lack of clarity in this consensus call. > > > > > > '... we believe in rough consensus & running code' & from > the Tao : > > > 'running code wins' On several related mail threads there > were many > > > comments about running code, and at least Brian Zill & Brian > > > Haberman said they collectively had host, application, and router > > > implementations of the current SL running. Point 3) even > > > acknowledges there are existing implementations. This > consensus call > > > intends to invalidate the running code, and all we have > to replace > > > it is a promise in 4) that if the group can ever agree that > > > operational requirements of the site network manager are worth > > > solving, we might start to work on solutions, subject to > appropriate > > > charter updates. This whole discussion is based on the > > > argument that some developers couldn't create running code > > > for an arguably bogus scenario where topology locators are > > > blindly passed outside their scope of relevance. Bias was > > > given to the opinions of those with a lack of running code, > > > at the expense of, and with the specific intent of > > > invalidating the code that exists. > > > > > > There were also claims in the meeting and mail threads > that we have > > > analyzed site local as currently defined, and it doesn't meet the > > > requirements. At the same time, there is a recognition by many of > > > the same people that we need to develop a complete set of > > > requirements. It should be obvious that the analysis is flawed if > > > the complete set of requirements are not understood > first. To that > > > end, and in the spirit of making progress, > > > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > > > editor on 4/8, and is offered as an attempt to document the > > > requirements for address space with a local scope of > > > relevance. It is clearly incomplete, and largely based on my > > > previous email on the subject. > > > > > > While I contest the claim that the Yes/No opinions expressed > > > measured consensus for a consistent interpretation of what > > > 'deprecate site local addresses' means, I do believe that > a set of > > > work items for the group were identified. It is also > clear that we > > > can add new work to a group at any time, without the need > to remove > > > existing items first. I agree with the chairs that items > 4) & 5) are > > > valid outcomes of the subsequent discussion, though one > thing that > > > their interpretation of the result does not make clear is the > > > meaning of 'accomplish the following things in parallel:'. In > > > talking to the chairs it appears the intent is to start the > > > work at the same time, but we need to avoid invalid > > > transition states, so parallel needs to mean that all 5 are > > > to be forwarded to the IESG at one time. In particular, > > > without solutions to the requirements in hand, any documents > > > for 1) & 3) that intend to deprecate the only local use > > > address space will simply create chaos, and might need to be > > > rescinded if the complete set of requirements shows a need > > > with no other technical approach. > > > > > > In short, I do not believe the consensus call measured > the opinions > > > that were consistent the chairs interpretation of the > question, so > > > the claimed results are invalid. I do believe that the effort > > > identified work items 4) & 5), with the potential that 1) > & 3) might > > > follow if there are no outstanding requirements for ambiguous > > > address space. I question the wisdom of 2), but will reserve > > > judgment until the complete text identifying further work > is spelled > > > out. In any case, I hope this appeal can be dealt with at this > > > level, and that the overall effort results in an expedited charter > > > update. It is imperative that new approaches exist prior to > > > removal of the current, and there is a very real danger that > > > the current destructive energy will dissipate in the face of > > > the hard work of creating replacements. > > > > > > Tony > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- [6] More followup/clarification from Tony Hain From: "Tony Hain" To: "'Bob Hinden'" , "'Margaret Wasserman'" Cc: Subject: Appeal clarification ... Date: Thu, 24 Apr 2003 22:45:30 -0700 Message-Id: <047f01c30aed$e1f8ed20$261e4104@eagleswings> Everyone should check out the video at: ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 - 03202003 - INT ipv6.mpg ... Starting at 1:02:05. It is very instructional about how not to call a question. The claimed consensus was over (and I quote from the AD & chair 2:18:20) 'just to be clear, deprecate I assume means ...' ... '...we may have to handwave - wave our hands around that a little bit...'. In further discussion with the chairs, the appeal issue is still not clear. This note attempts to make it clearer, and adds documentation from the video of the SF session. Appeal: The chairs have asserted an incorrect technical choice which places the quality and/or integrity of the Working Group's products in significant jeopardy. The working group did not make a decision as some of the YES votes were for removal of local scopes from the architecture, some for removal of the need for apps to recognize that local scopes exist, others were for removing ambiguous addresses as SL is currently defined, and others were for removing the threat of NAT. Those are technically different architectural concepts requiring different questions. In particular, local scope addresses are the result of an operational choice, and not in the purview of the IETF to decide. The IETF can decide to set aside a well known prefix for that use or not, but removing the well-known prefix does not mean local scope addresses go away, or that applications are exempted from handling them correctly. It only means that there is no consistent way to identify which addresses are local use. There is no document identifying the requirements and needs of the network operators, therefore no reasonable and complete evaluation could result in the conclusion that deprecation is an appropriate action. The chairs chose to ask an ambiguous question that the group clearly had different opinions about the meaning of, and shortly before the initial question was called there was an explicit statement about lack of clarity in the consequences of the alternatives. Forcing a YES/NO question for an end state rather than a process, without a widespread understanding of the consequences and trade-offs, was an inappropriate action by the chairs. The working group was mislead by an ambiguous question from the chairs. The asserted conclusion is invalid as the WG has not reached consensus on anything other than more work needs to be done. Background: The entire open discussion in SF started off misled by a bogus technical assertion by the chair: 1:42:04 ... it is always going to be possible to implement wrong unless we get rid of whole concept of private addresses ... you will always have the possibility ... for leaking addresses if they exist in the architecture >>> Existence in the address architecture is not what creates the possibility for limited scope addresses to be leaked, that only allows identification of them. The thing the creates the possibility for leaking limited scope addresses outside their realm of applicability is the ignorance by the applications that the real network has limited scope addresses and they require appropriate handling. Removing any tag for the application to identify which addresses have limited scope only ensures that they will be leaked. There was no enumeration of the requirements for any solution, therefore no reasonable and complete evaluation that the current SL is inadequate. 1:06:49 MW - you can only document the cost/benefit analysis of a point that's understood 1:36:30 - 'Do we have enough information to decide' >>> on slide but not discussed >>> discussion about overriding need to reach consensus 1:39:00 - Pekka - Exclusive is just broken ... if we want ... >>> indicates need to understand requirements without further analysis, that requirement is met by access prefix thing access prefix is less intrusive and easier to implement >>> where is the analysis that backs that up? 1:41:42 - Alain - ... if we want to avoid leaking ... >>> indicates need to understand requirements 1:50:05 - Erik - we don't have enough information to decide yet, and part of what I am looking for is so what are the benefits of these things anyhow >>> indicates need to understand requirements 1:52:33 - look at benefits before we try to decide something - MW 'anything we are doing here should be a cost/benefit tradeoff ... maybe we'll decide we need more information ... we need to do an intelligent cost/benefit analysis and have a supportable reason for our choice 1:58:00 Leif - Erik's comments were first time I heard purported benefits - applications shouldn't have to worry about topology that's a fundamental comparing the benefits with breaking fundamental assumption that apps shouldn't care about topology - its clear that you should eliminate SL >>> an informed conclusion after 5 1/2 minutes evaluation of a partial verbal list of requirements ??? How many others were in the same place? 2:11:39 Dave - I agree with Keith's attempt to clarify the wording of the question people are arguing for the eliminate proposal which there isn't any draft about ... In fact over the meeting it was clear that there was no common understanding about what 'deprecate' means even by the chairs, and this carried onto the list discussion: 2:09:24 MW - that would be eliminating it, you can always bring something back later someone can have a research group, but if take it out of the specs, ** that is what eliminating it means ** 2:09:35 Keith - alternate proposal for a way forward - I don't believe the bit patterns that are defined for SL will be allocated for some other use so I don't think we are eliminating them entirely, but I want to know if we can get a sense of the group that discouraging use of SL is the appropriate way to move forward - part 1 part 2 - identify the things that SL was supposed to solve and work out alternate solutions for those 2:10:20 MW - instead of eliminate I think the right word would be deprecate because I agree that we are not going to suddenly decide to use those bits for something else - I agree with you on that but discouraging ** is that deprecating? ** 2:10:35 Keith - deprecating in a sense, it also leaves the idea that until we find something else, you might have some usage of SL but the plan is in the future to deprecate it 2:11:39 Dave - I agree with Keith's attempt to clarify the wording of the question people are arguing for the eliminate proposal which there isn't any draft about - this is a question to you to clarify the question - Erik made and Dino added - zero conf asked what do routers do - do we want to enable a zero config thing - if so do you want to enable SL in a deprecated sense as Keith put it, for that or is the proposal to eliminate them and force zero config guys to not work because we don't care about that, or to force them to use some other well known prefix clarify which one of those is actually the proposal ? >>> questions never answered or even discussed 2:12:51 Christian - if we say that we are going to eliminate SL we have to actually eliminate it and ** that means ** that we have to make it explicit that at some point in the future all implementations are supposed to discard any packets sent to the specific prefix 2:13:19 MW - I'll resay what I said earlier which is I had said we would say eliminate it or keep it and then we'd have multiple choices if we kept it but apparently ** if we eliminate it we will also have multiple choices about what exactly that means ** >>> 'multiple choices' how does that indicate a clear meaning ??? 2:13:31 Erik - I think there area some details about what it means if we actually choose to eliminate ** I think that means ** that people at their leisure can go ahead and delete whatever code they have that currently recognizes FEC0 but they don't have to do it tomorrow, because we are not going to allocate this for any other purpose in the near future, but it means that you don't have to add any more code, but you can at your leisure delete what you have 2:14:05 Brian - I got up to say that the question that you were going to ask is one that ** I would have difficulty answering because I wouldn't vote for keeping SL unless I knew which of the options we were going to go for ** >>> though voting against without understanding the consequences didn't appear to be a problem 2:16:09 Bound - IPv4 NAT is a national security problem, at least in the US so ** what I am hearing to day is we should stop it and not give any credence to help proliferate them ** >>> a belief that removing SL removes the threat of NAT ??? 2:16:45 Keith - ... ** the real trick is ** that applications shouldn't have to special case these things, Dns shouldn't have to special case them, routing shouldn't; have to special case these things >>> in other words applications continue to ignore the reality of limited scope addresses, because without a well-known tag it is impossible to special case them 2:18:20 Thomas, just to be clear, ** deprecate I assume means ** somewhere to the left of the limited use model - MW Yes, somewhere to the left of limited, the bits would somehow become deprecated but probably you wouldn't get to reuse them and we would not want to invalidate existing implementations so we may have to wave our hands around that a little bit to make sure we do it right - Bob, Christian just added - and probably needed to be blackholed >>> 'somewhere to the left'; 'somehow be deprecated'; & '...may have to hand wave...' those are not clear indications of the meaning of the question or consequences of this action. 4/2 JB - Ambiguous addresses are a nightmare... >>> a common theme 4/5 MW - The proposal is to deprecate a prefix in the addressing architecture for which we have found no suitable use. >>> Translation - we refuse to acknowledge the uses in shipping code, though we do acknowledge that there is shipping code which uses them. 4/5 DL - I thought we were voting on something more meaningful, i.e., site-locals themselves. Now I understand that site-locals do not exist as such and we were just voting on the deprecation of the prefix itself. 4/7 AW - I have come to the conclusion that the consensus call email on the list failed to adequately describe what a YES for deprecation actually entailed, and has pretty effectively shot itself in the foot. 4/4 HA - Note: By "Deprecate Site-Local", ** I mean ** "Do not require any application, host, router, protocol or IETF practice to have to make special consideration for the idea that an IPv6 unicast address outside of the link-local range can refer to two different hosts". 4/4 PF - So, when I say I want Site Local deprecated ** I mean ** I want routing and addressing separated, and given that separation, we have to work on solving the real problems we have with Internet today While there was no single clear statement about what deprecate means (though many architecturally different assertions), there was a clear overriding concern by the chairs that some conclusion be reached, even a bad one: 2:07:43 Erik - call for comments for SL Bob - give us a second here MW - if we are going reach any conclusion we can't accept a sudden influx at mic 2:08:45 Bob - if you want to support SL independent of usage model come to the mic 2:15:22 Bob by the way... MW cut off> we have to cut off discussion with the people who are at the mic because we have to try to have some conclusion >>> where was the fire? If the question had not been called in SF, would the world have ended? Allowing 7 1/2 minutes for rebuttal comments to a discussion that was not on the agenda, there were no documents published, and people did not come to the meeting prepared to discuss is inappropriate in any case. Cutting off discussion just as people were getting their thoughts together to form reasonable statements about requirements is improper meeting management and biases any attempt to measure consensus. Despite the lack of agreement about exactly what deprecate means, there was a comment: 2:17:19 MW - lets see, just a sec ... we are going to call a question and the question is going to be a yes no question do we want to deprecate SL addresses or do we not want to deprecate SL addresses - we realize that both of those answers no matter which answer you give there is more details that need to be worked out, but we are trying to get what is the direction, does the group want to go away from SL addressing, deprecate it work out how to get it out, does the group want to keep it and figure out what the right usage model is for it OK, this is a usage model issue. its is like do we want to support usage of SL and come up with a usage model for it, or do we want to deprecate it which was not made to the mail list consensus call. >>> There is a vast difference between identifying direction of the group and the actual yes/no to deprecate SL question that was asked. In fact all other indications from the chairs were that the question was NOT about measuring direction of the WG, but actually about their intent to have local scoped addresses removed from the scoped address architecture and other documents. >>> This drive for a decision despite multiple statements (by the chairs no less), that a cost/benefit analysis can only be done with a complete set of requirements. Where is the supportable reason for the asserted choice to change the architecture? For that matter, where is the requirements document that a supportable reason would be built from? In preparing the question, it should have been clear that the chairs were not thinking this though clearly: 2:18:57 Perry when you say it is a yes or no question, therefore it must be phrased differently than do we wish to deprecate them or do we not wish to deprecate them - MW I am tired, did I actually say that? Yet seconds later: 2:19:20 MW Question - show of hands, how many people think that we should deprecate SL addressing? Keith's wording at 2:09:35 would have been an appropriate pair of questions for the chairs to ask (I acutally support part 2), but the chairs chose to ask an ambiguous question that the group (and even the chairs) clearly had different and inconsistent opinions about the meaning of. Shortly before the question was called there was an explicit statement about lack of clarity about the consequences of the alternatives. The fact that many of the YES responses were about removal of local scope addresses invalidates the asserted conclusion. The existence of limited scope addresses are an architectural consequence of operational choices, and not in the purview of the IETF to decide. Tony PS: 2:14:05 Brian ... I also a comment that RFC 1597 is one of the worst end runs in the history of the IETF. >>> I am arguing that through an ambiguous question this desperate drive for a conclusion which intends to remove local scope addresses from the architecture superseded it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- [7] Chairs formal response to Tony Hain's appeal Message-Id: <5.1.0.14.2.20030428165715.046a3888@mail.windriver.com> Date: Mon, 28 Apr 2003 17:02:02 -0400 To: Tony Hain From: Margaret Wasserman Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Cc: ipng@sunroof.eng.sun.com, Thomas Narten , Erik Nordmark , Bob Hinden Hi Tony, We have considered your appeal regarding the IPv6 WG consensus to deprecate site-locals. Based on our analysis, we believe that your appeal makes the following points: (1) You believe that deprecating IPv6 site-local unicast addressing is an incorrect technical choice that places the work output of the IPv6 WG in jeopardy. (2) You believe that the question asked by the chairs was insufficiently clear to be understood properly by the WG. (3) You do not believe that there is rough consensus to deprecate IPv6 site-local addressing, because people provided different reasons for why they believe that IPv6 site-local addressing should be deprecated. In particular, some people want to deprecate the particular model of site-local addressing defined in the scoped addressing architecture (ambiguous, scoped addresses), while others do not believe that we need a local addressing mechanism at all. (4) You believe that it is invalid for the IPv6 WG to deprecate site-local addressing without publishing an IPv6 WG document that analyzes the operational requirements for local addressing. Without this analysis document, you believe that the IPv6 WG has made an uninformed choice. We will now respond to each of your points. -- Point (1): The chairs do not believe that deprecating IPv6 site-local addressing is an incorrect technical decision that will place the work output of the IPv6 WG in jeopardy. The consensus was to "deprecate" the usage of site-local addressing instead of simply removing it. This was done purposely to avoid interference with any current implementations or deployments that might use site-local addressing. In addition to the time it will take to formally deprecate site-local addressing by publishing an RFC, the WG understands that it will take some time after the publication of an RFC for implementations to change. The decision to deprecate site-local addressing, rather than simply removing it, was made to avoid harm to IPv6. In fact, we believe that the previous disagreement over the usage of IPv6 site-local addressing was damaging to the WG, and that our lack of consensus was delaying our work, particularly on the IPv6 scoped addressing architecture. The consensus to deprecate site-local addressing will allow us to move forward and complete our work. --- Point (2): The question was: "Should we deprecate IPv6 site-local unicast addressing?" Possible answers were YES or NO. The chairs believe that this question was sufficiently clear to be understood by the WG. This is supported by the following points: - Over 200 people responded to the question. - Many of the responses on the list (both YES and NO responses) included reasons or comments that followed from the question in a way that indicated that the responders understood the question. - There were only three requests for clarification of this consensus call on the mailing list, two of which were procedural. All of these requests were answered promptly by the chairs. - The chairs sent the consensus results to the list over two weeks ago, including a course of action for the deprecation of site-local addressing. There have been no objections from people who originally expressed YES opinions that the chairs' course of action fails to match their expectations. --- Point (3): The chairs do not believe that consensus on an issue is invalidated by the fact that people have multiple reasons for coming to the same conclusion. We suspect that this happens in most WG consensus calls, and this is not a reason to invalidate the consensus. All of the groups that you mentioned in your message agreed that IPv6 site-local unicast addressing should be deprecated. They may disagree on what we should do after deprecating site- local addressing, but that does not invalidate the consensus on this point. --- Point (4): It is true that the IPv6 WG has not produced a WG document that analyzes the operational requirements for local addressing. However, we do not believe that this is a reason to invalidate the IPv6 WG consensus to deprecate IPv6 site-local unicast addressing. There has been considerable discussion and analysis of site- local addressing performed over the past year, including extensive discussions during three IETF sessions. There have also been several drafts published on the subject, including one draft that attempts to analyze the cost/benefit trade-offs of site-local addressing. This period of discussion has offered sufficient time for anyone who has an operational need for any of the currently-defined usage models of site-local addressing to document those requirements in an Internet-Draft and/or to discuss those requirements on the IPv6 mailing list. During our discussions, several operational benefits of site-local addressing have been raised on the IPv6 WG mailing list, including benefits for disconnected sites, intermittently- connected sites, renumbered sites, etc. We have also uncovered several issues and complexities caused by the current model of ambiguous, scoped site-local addressing, and we have determined that this particular model places burdens on other parts of the TCP/IP protocol suite, particularly routing protocols and applications. In a recent phone discussion and in your appeal clarification, you have indicated that the chairs should void responses from people who do not think that the IPv6 WG should specify any type of local addressing mechanism, because you believe that those responders are uninformed about the operational conditions that require the use of local addressing. While operational necessity is certainly an appropriate argument to raise in support of your position that the IPv6 WG should specify some mechanism for local addressing, the fact that you disagree with the reasons that some people offered for why they want to deprecate the current IPv6 site-local unicast addressing mechanism does not invalidate their contribution to this consensus call. It is the opinion of the chairs that the IPv6 WG did have sufficient information to make an informed decision regarding whether or not to deprecate IPv6 site-local unicast addressing. --- So, to summarize, the chairs do not agree with the points that you have raised in your appeal, and we do not agree to overturn the consensus of the IPv6 WG based on the issues that you have raised. Tony, while we disagree with your position on this particular issue, we do respect your contributions to the IPv6 effort and we realize that your appeal is motivated by your desire to do the right thing for IPv6. We hope that you will accept our response to your appeal and focus on working to define the local addressing problem and solutions as we outlined in our email to the list. We think it is important for the working group to move forward on this issue. Best Regards, Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- [8] Tony Hain's reaction to the response from chairs. From: "Tony Hain" To: "'Margaret Wasserman'" , "'Bob Hinden'" Cc: , "'Thomas Narten'" , "'Erik Nordmark'" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Mon, 28 Apr 2003 18:38:26 -0700 Message-ID: <066f01c30df0$07ae4740$261e4104@eagleswings> Margaret Wasserman wrote: > (3) You do not believe that there is rough consensus to > deprecate IPv6 site-local addressing, because people > provided different reasons for why they believe that > IPv6 site-local addressing should be deprecated. In > particular, some people want to deprecate the particular > model of site-local addressing defined in the scoped > addressing architecture (ambiguous, scoped addresses), > while others do not believe that we need a local > addressing mechanism at all. I was not objecting to 'different reasons'. The specific complaint is that many of YES votes were for removing the architectural construct, or need for applications to deal with addresses that are only accessable over a limited scope. That is not in the purview of the IETF to decide, it is an operational decision of the network manager. Those votes are not valid as a result. > Point (1): > > The chairs do not believe that deprecating IPv6 site-local > addressing is an incorrect technical decision that will place > the work output of the IPv6 WG in jeopardy. > > The consensus was to "deprecate" the usage of site-local > addressing instead of simply removing it. By asking an ambiguous question, it is easy to insert your interpretation as the collective consensus. How convenient. SF question -- ... how many people think that we should deprecate SL addressing? Mail list question -- Should we deprecate IPv6 site-local unicast addressing? Neither of those mention 'usage'. In fact if you watch the video of SF, you will find that you spent much more time talking about elimination than anything else. > This was done > purposely to avoid interference with any current > implementations or deployments that might use site-local > addressing. In addition to the time it will take to formally > deprecate site-local addressing by publishing an RFC, the WG > understands that it will take some time after the publication > of an RFC for implementations to change. The decision to > deprecate site-local addressing, rather than simply removing > it, was made to avoid harm to IPv6. There was no decision. You had an inconclusive discussion with Keith, then later a vague discussion with Thomas about a 'hand wave'. Neither of those even come close to a decision, let alone a WG decision. Are we supposed to just say YES to any ambiguous question you ask, so you can make up the content of the consensus later? > > In fact, we believe that the previous disagreement over the > usage of IPv6 site-local addressing was damaging to the WG, > and that our lack of consensus was delaying our work, > particularly on the IPv6 scoped addressing architecture. While you may believe that the disagreement over SL was delaying the work, most of those disagreements stemmed from a lack of agreement over the fundamental requirements. Removing SL does not solve the basic problems that need to be addressed in the scoped addressing architecture. > The > consensus to deprecate site-local addressing will allow us to > move forward and complete our work. No it won't. A scoped address architecture document that ignores the reality of addresses that are only reachable within a limited part of the network is incomplete on its major point. It is absolutely useless to pretend that we have a document that discusses a scoped architecture when the case for the majority of nodes in the Internet is missing. > > --- > Point (2): > > The question was: > > "Should we deprecate IPv6 site-local unicast > addressing?" Possible answers were YES or NO. > > The chairs believe that this question was sufficiently clear > to be understood by the WG. Clearly you didn't watch the video of the SF meeting. Why would Thomas, Keith, Dave, and Christian make a specific point of trying to clarify the question if it was clear to begin with? Since the question didn't change, it remained just as unclear as it started, and none of the 'somewhere to the left' & 'hand wave' comments were sent to the list. > This is supported by the following > points: > > - Over 200 people responded to the question. > > - Many of the responses on the list (both YES and NO > responses) included reasons or comments that > followed from the question in a way that indicated > that the responders understood the question. I disagree. Many of the responses indicated what they meant by saying yes, which is not the same as understanding the question. In fact, their need to explain what question they were answering is an implicit statement of lack of clarity in the question. > > - There were only three requests for clarification of > this consensus call on the mailing list, two of which > were procedural. All of these requests were answered > promptly by the chairs. > > - The chairs sent the consensus results to the list > over two weeks ago, including a course of action for > the deprecation of site-local addressing. There > have been no objections from people who originally > expressed YES opinions that the chairs' course of > action fails to match their expectations. Why would there be? They all have their own interpretations, so there won't be objections until the actual next steps begin. > > --- > > Point (3): > > The chairs do not believe that consensus on an issue is > invalidated by the fact that people have multiple reasons for > coming to the same conclusion. We suspect that this happens > in most WG consensus calls, and this is not a reason to > invalidate the consensus. You missed the point that many of those responses are for an architectural change that is not in the IETF's purview to decide. See above. > > All of the groups that you mentioned in your message agreed > that IPv6 site-local unicast addressing should be deprecated. No, some of them believed this is about removing local scoped addresses from the architecture, or consideration by applications. That is not the same as 'usage' of a defined prefix. > They may disagree on what we should do after deprecating > site- local addressing, but that does not invalidate the > consensus on this point. There is a vast and architectural difference between removing addresses which are only reachable over a limited part of the network, and usage of a specific prefix to identify those. You keep claiming there is a consensus, but any objective observer of the SF video would disagree. > > --- > > Point (4): > > It is true that the IPv6 WG has not produced a WG document > that analyzes the operational requirements for local > addressing. However, we do not believe that this is a reason > to invalidate the IPv6 WG consensus to deprecate IPv6 > site-local unicast addressing. You said it multiple times in SF yourself, the WG needs complete documentation to do an appropriate analysis. You appear to be letting your desire to 'be right' get in the way of your ability to analyze your own responses. I don't understand how can you objectively say 'we don't need a document describing the need for X to decide that we don't need X'? > > There has been considerable discussion and analysis of site- > local addressing performed over the past year, including > extensive discussions during three IETF sessions. There have > also been several drafts published on the subject, including > one draft that attempts to analyze the cost/benefit > trade-offs of site-local addressing. There have been personal drafts. The WG has not taken this on as a specific work item. > > This period of discussion has offered sufficient time for > anyone who has an operational need for any of the > currently-defined usage models of site-local addressing to > document those requirements in an Internet-Draft and/or to > discuss those requirements on the IPv6 mailing list. They have been discussed on the mail list to the point that people stop paying attention. This argument is disingenuous because there has never been a WG item about creating this document. In addition, I have offered a draft on the subject multiple times in the last month, yet have not even received as much as a simple 'no thanks' from the chairs. > > During our discussions, several operational benefits of > site-local addressing have been raised on the IPv6 WG mailing > list, including benefits for disconnected sites, > intermittently- connected sites, renumbered sites, etc. We > have also uncovered several issues and complexities caused by > the current model of ambiguous, scoped site-local addressing, > and we have determined that this particular model places > burdens on other parts of the TCP/IP protocol suite, > particularly routing protocols and applications. Most of those difficulties will persist, because they are the result of inconsistent views of the network topology. There is nothing about deprecating SL that will change this. The only affect will be to make it harder to figure out when the burdens exist. > > In a recent phone discussion and in your appeal > clarification, you have indicated that the chairs should void > responses from people who do not think that the IPv6 WG > should specify any type of local addressing mechanism, > because you believe that those responders are uninformed > about the operational conditions that require the use of > local addressing. > > While operational necessity is certainly an appropriate > argument to raise in support of your position that the IPv6 > WG should specify some mechanism for local addressing, the > fact that you disagree with the reasons that some people > offered for why they want to deprecate the current IPv6 > site-local unicast addressing mechanism does not invalidate > their contribution to this consensus call. I am pointing out that their 'reason' is not in the purview of the IETF to decide, so their YES votes are not informed or valid. I am not objecting to their opinion, just the chair's interpretation of consensus is in error because it fails to discount the votes for an architectural point that is out of the IETF's control. > > It is the opinion of the chairs that the IPv6 WG did have > sufficient information to make an informed decision regarding > whether or not to deprecate IPv6 site-local unicast addressing. Even though a long-term member of the WG said right before the question that he did not have enough information to vote NO ... and another participant stated he had never heard the requirements before Erik gave a verbal partial list. How do these create 'an informed decision'? > > --- > > So, to summarize, the chairs do not agree with the points > that you have raised in your appeal, and we do not agree to > overturn the consensus of the IPv6 WG based on the issues > that you have raised. I am not surprised. > > Tony, while we disagree with your position on this particular > issue, we do respect your contributions to the IPv6 effort > and we realize that your appeal is motivated by your desire > to do the right thing for IPv6. We hope that you will accept > our response to your appeal and focus on working to define > the local addressing problem and solutions as we outlined in > our email to the list. We think it is important for the > working group to move forward on this issue. I will be escalating to Erik & Thomas, because I do believe that is the right and expeditious thing to do in this case. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- [9] Tony Hain's appeal to the INT ADs. From: "Tony Hain" To: "'Thomas Narten'" , "'Erik Nordmark'" Cc: , "'Bob Hinden'" , "'Margaret Wasserman'" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Mon, 28 Apr 2003 18:43:47 -0700 Message-ID: <067001c30df0$c7ae0ad0$261e4104@eagleswings> Thomas & Erik, I trust that you will take a more objective view of this, because any outsider who needs to watch that video will be rolling in the isles with laughter at the absurdity of the process abuse in this case. At least 5 long-time IETF participants (including yourself) felt the need to state what they meant by 'deprecate SL'. One has to assume they bothered to assert their interpretation because the YES/NO question was unclear to them, or that their need to explain which question they were answering is an implicit statement that the original question was unclear. Even though the question never changed, none of the (amazingly vague) clarifying remarks in SF were sent to the list version of the consensus call. If a legal professional were to watch the proceedings here, they would comment that the WG gave the chairs the freedom to interpret the meaning of the question any way they choose. In fact we have examples of that already on the mail list and in this response. 3/30 chair email claimed > As part of deprecating site-local addressing, we > agreed in the meeting that, in addition to deprecating > site-local addressing in the addressing architecture > and removing it from other places (scoped addressing > architecture, address selection rules, etc.), a document > would be written that would do two things: > > - Explain why site-local addressing was deprecated > - Outline alternative means to address some of the > problems that could have been solved by > site-local addressing. That question was never asked of the room, and those statements were not made by the chairs in SF. How could there be an agreement? > The decision to deprecate site-local addressing, > rather than simply removing it, was made to avoid > harm to IPv6. There was nothing more to this than vague conversations between Margaret & Keith, and Margaret & Thomas. There was no decision by the WG, just a chair proclamation that one had occurred. We can't allow the WG process to degenerate to the point that a chair can call an ambiguous YES/NO question, then make up anything they choose to have it mean later. In particular, when the chair explicitly states '... if we eliminate it we will also have multiple choices about what exactly that means ...', and '... may have to hand wave ...' there is not a clear indication about what question is being asked. I put specific rebuttal comments to the chair's rejection in a list response to the chairs. In summary I believe the chairs have declared a consensus when there really wasn't one due to the ambiguity of the question. Specifically the YES votes for removing addresses with local scope from the architecture or consideration by applications are void, as that is not something the IETF gets to decide. Had the chairs asked Keith's original question about finding an alternate way forward through replacement technologies, we would not be going through this process. As for a path forward, I would expect you to invalidate the consensus, then have the WG stop the pronouncements that SL is dead, and work on finding appropriate replacements. This effort must begin with identification of the requirements for addresses of local scope, and under local network manager control. With requirements in hand, the scoped address architecture document needs to specifically deal with handling mixed scope addresses, both between and for simultaneous use on a singe node. That document in particular is hopelessly gutted and meaningless without such a discussion. IF we get to the point were all requirements are met by alternatives, the current SL definition should appropriately be moved to historic. If not, it will likely end up in the corner case use that Keith was trying to achieve. Either way, the entire WG must decide exactly what happens. We must not allow the 'ambiguous YES/NO question - chairs subsequently decide what it means', process to set a precedent. Tony Margaret Wasserman wrote: > Hi Tony, > > We have considered your appeal regarding the IPv6 WG > consensus to deprecate site-locals. Based on our analysis, > we believe that your appeal makes the following points: > > (1) You believe that deprecating IPv6 site-local unicast > addressing is an incorrect technical choice that places > the work output of the IPv6 WG in jeopardy. > > (2) You believe that the question asked by the chairs > was insufficiently clear to be understood properly > by the WG. > > (3) You do not believe that there is rough consensus to > deprecate IPv6 site-local addressing, because people > provided different reasons for why they believe that > IPv6 site-local addressing should be deprecated. In > particular, some people want to deprecate the particular > model of site-local addressing defined in the scoped > addressing architecture (ambiguous, scoped addresses), > while others do not believe that we need a local > addressing mechanism at all. > > (4) You believe that it is invalid for the IPv6 WG to > deprecate site-local addressing without publishing an > IPv6 WG document that analyzes the operational requirements > for local addressing. Without this analysis document, you > believe that the IPv6 WG has made an uninformed choice. > > We will now respond to each of your points. > > -- > > Point (1): > > The chairs do not believe that deprecating IPv6 site-local > addressing is an incorrect technical decision that will place > the work output of the IPv6 WG in jeopardy. > > The consensus was to "deprecate" the usage of site-local > addressing instead of simply removing it. This was done > purposely to avoid interference with any current > implementations or deployments that might use site-local > addressing. In addition to the time it will take to formally > deprecate site-local addressing by publishing an RFC, the WG > understands that it will take some time after the publication > of an RFC for implementations to change. The decision to > deprecate site-local addressing, rather than simply removing > it, was made to avoid harm to IPv6. > > In fact, we believe that the previous disagreement over the > usage of IPv6 site-local addressing was damaging to the WG, > and that our lack of consensus was delaying our work, > particularly on the IPv6 scoped addressing architecture. The > consensus to deprecate site-local addressing will allow us to > move forward and complete our work. > > --- > Point (2): > > The question was: > > "Should we deprecate IPv6 site-local unicast > addressing?" Possible answers were YES or NO. > > The chairs believe that this question was sufficiently clear > to be understood by the WG. This is supported by the following > points: > > - Over 200 people responded to the question. > > - Many of the responses on the list (both YES and NO > responses) included reasons or comments that > followed from the question in a way that indicated > that the responders understood the question. > > - There were only three requests for clarification of > this consensus call on the mailing list, two of which > were procedural. All of these requests were answered > promptly by the chairs. > > - The chairs sent the consensus results to the list > over two weeks ago, including a course of action for > the deprecation of site-local addressing. There > have been no objections from people who originally > expressed YES opinions that the chairs' course of > action fails to match their expectations. > > --- > > Point (3): > > The chairs do not believe that consensus on an issue is > invalidated by the fact that people have multiple reasons for > coming to the same conclusion. We suspect that this happens > in most WG consensus calls, and this is not a reason to > invalidate the consensus. > > All of the groups that you mentioned in your message agreed > that IPv6 site-local unicast addressing should be deprecated. > They may disagree on what we should do after deprecating > site- local addressing, but that does not invalidate the > consensus on this point. > > --- > > Point (4): > > It is true that the IPv6 WG has not produced a WG document > that analyzes the operational requirements for local > addressing. However, we do not believe that this is a reason > to invalidate the IPv6 WG consensus to deprecate IPv6 > site-local unicast addressing. > > There has been considerable discussion and analysis of site- > local addressing performed over the past year, including > extensive discussions during three IETF sessions. There have > also been several drafts published on the subject, including > one draft that attempts to analyze the cost/benefit > trade-offs of site-local addressing. > > This period of discussion has offered sufficient time for > anyone who has an operational need for any of the > currently-defined usage models of site-local addressing to > document those requirements in an Internet-Draft and/or to > discuss those requirements on the IPv6 mailing list. > > During our discussions, several operational benefits of > site-local addressing have been raised on the IPv6 WG mailing > list, including benefits for disconnected sites, > intermittently- connected sites, renumbered sites, etc. We > have also uncovered several issues and complexities caused by > the current model of ambiguous, scoped site-local addressing, > and we have determined that this particular model places > burdens on other parts of the TCP/IP protocol suite, > particularly routing protocols and applications. > > In a recent phone discussion and in your appeal > clarification, you have indicated that the chairs should void > responses from people who do not think that the IPv6 WG > should specify any type of local addressing mechanism, > because you believe that those responders are uninformed > about the operational conditions that require the use of > local addressing. > > While operational necessity is certainly an appropriate > argument to raise in support of your position that the IPv6 > WG should specify some mechanism for local addressing, the > fact that you disagree with the reasons that some people > offered for why they want to deprecate the current IPv6 > site-local unicast addressing mechanism does not invalidate > their contribution to this consensus call. > > It is the opinion of the chairs that the IPv6 WG did have > sufficient information to make an informed decision regarding > whether or not to deprecate IPv6 site-local unicast addressing. > > --- > > So, to summarize, the chairs do not agree with the points > that you have raised in your appeal, and we do not agree to > overturn the consensus of the IPv6 WG based on the issues > that you have raised. > > Tony, while we disagree with your position on this particular > issue, we do respect your contributions to the IPv6 effort > and we realize that your appeal is motivated by your desire > to do the right thing for IPv6. We hope that you will accept > our response to your appeal and focus on working to define > the local addressing problem and solutions as we outlined in > our email to the list. We think it is important for the > working group to move forward on this issue. > > Best Regards, > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 9 10:58:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h69HwR06008923; Wed, 9 Jul 2003 10:58:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h69HwRlJ008922; Wed, 9 Jul 2003 10:58:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h69HwO06008915 for ; Wed, 9 Jul 2003 10:58:24 -0700 (PDT) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with SMTP id h69Hu8te767028; Wed, 9 Jul 2003 10:56:09 -0700 (PDT) Date: Wed, 9 Jul 2003 10:55:46 -0700 From: Michael Hunter To: itojun@iijlab.net Cc: Michael.Hunter@Sun.COM, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" Message-Id: <20030709105546.0540f5f2.michael.hunter@eng.sun.com> In-Reply-To: <20030709023458.38FB489@coconut.itojun.org> References: <20030708113847.515a22cf.michael.hunter@eng.sun.com> <20030709023458.38FB489@coconut.itojun.org> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 09 Jul 2003 11:34:58 +0900 itojun@iijlab.net wrote: > >This looks like a strong draft. Several issues exist though. > > > >1) There is no mention of RFC 3041 (privacy enhanced) addresses. Both > >the issue as to if they should be responded with and if they should be > >responded to needs to be addressed. > > just FYI from implementation POV: KAME implementation does not > include RFC3041 addresses in the response by default. there's a > configuration flag bit which makes the responder to include RFC3041 > addresses as well. > > i guess that sensible default would be not to include RFC3041 addresses. Or respond to requests to RFC3041 addresses. [...] > >If its not limited to the link local then this protocol should probably > >be filtered at the edge of the administrative domain. > > it is up to administrator of the domain, therefore i think > recommendation like "SHOULD filter" is too strong. how about > "may want to filter" or something like that? Removing the "SHOULD have a default configuration which refuses to answer queries from global-scope" and replacing that with a recommendation ("may want to filter") that this protocol be filtered seems reasonable to me. mph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 10 04:33:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6ABX106011822; Thu, 10 Jul 2003 04:33:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6ABX16p011821; Thu, 10 Jul 2003 04:33:01 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6ABWv06011813 for ; Thu, 10 Jul 2003 04:32:57 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6ABUiUu001381 for ; Thu, 10 Jul 2003 04:30:44 -0700 (PDT) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6ABUcHJ015868 for ; Thu, 10 Jul 2003 05:30:39 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6ABUanx012688 for ; Thu, 10 Jul 2003 13:30:37 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h6ABUZ0B287058 for ; Thu, 10 Jul 2003 13:30:36 +0200 Received: from dhcp22-107.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21488 from ; Thu, 10 Jul 2003 13:30:33 +0200 Message-Id: <3F0D2411.961FE58C@hursley.ibm.com> Date: Thu, 10 Jul 2003 10:30:09 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Requirements" References: <4.3.2.7.2.20030701131314.02a684c0@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 4.3.1 Path MTU Discovery - RFC1981 > > Path MTU Discovery [RFC-1981] MAY be supported. I don't propose to change this, for reasons that were discussed earlier. But I do wonder if we shouldn't qualify it slightly, since we would hope to see the majority of nodes supporting MTU discovery. Could we add a sentence saying something like It is expected that most implementations will indeed support this, although the possible exception cases are sufficient that the used of "SHOULD" is not justified. Otherwise, some implementors might use the MAY as an easy way out. Brian Bob Hinden & Margaret Wasserman wrote: > > This is a IPv6 working group last call for comments on advancing the > following document as an Informational RFC: > > Title : IPv6 Node Requirements > Author(s) : J. Loughney > Filename : draft-ietf-ipv6-node-requirements-04.txt > Pages : 20 > Date : 2003-6-30 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end on 15 > July 2003. > > Bob Hinden / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 10 05:03:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6AC3t06012149; Thu, 10 Jul 2003 05:03:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6AC3tdx012148; Thu, 10 Jul 2003 05:03:55 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6AC3q06012141 for ; Thu, 10 Jul 2003 05:03:52 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6AC1cUu006916 for ; Thu, 10 Jul 2003 05:01:38 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6AC1WbI025946 for ; Thu, 10 Jul 2003 06:01:33 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6AC1Vk20610 for ; Thu, 10 Jul 2003 15:01:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jul 2003 15:01:31 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 15:01:31 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 15:01:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 w.g. Last Call on "IPv6 Node Requirements" Date: Thu, 10 Jul 2003 15:01:30 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Node Requirements" Thread-Index: AcNG13EJhqMc+lesREyixUmsAW8zwAAA4a5Q From: To: , X-OriginalArrivalTime: 10 Jul 2003 12:01:30.0378 (UTC) FILETIME=[FFBB36A0:01C346DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6AC3q06012142 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, That seems like a reasonable addition. John > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 10 July, 2003 11:30 > To: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Requirements" > > > > 4.3.1 Path MTU Discovery - RFC1981 > > > > Path MTU Discovery [RFC-1981] MAY be supported. > > I don't propose to change this, for reasons that were discussed > earlier. But I do wonder if we shouldn't qualify it slightly, > since we would hope to see the majority of nodes supporting > MTU discovery. Could we add a sentence saying something like > It is expected that most implementations will indeed support > this, although the possible exception cases are sufficient > that the used of "SHOULD" is not justified. > Otherwise, some implementors might use the MAY as an easy way out. > > Brian > > Bob Hinden & Margaret Wasserman wrote: > > > > This is a IPv6 working group last call for comments on advancing the > > following document as an Informational RFC: > > > > Title : IPv6 Node Requirements > > Author(s) : J. Loughney > > Filename : draft-ietf-ipv6-node-requirements-04.txt > > Pages : 20 > > Date : 2003-6-30 > > > > Please send substantive comments to the ipng mailing list, and minor > > editorial comments to the authors. This last call period > will end on 15 > > July 2003. > > > > Bob Hinden / Margaret Wasserman > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 10 11:23:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6AINN06013213; Thu, 10 Jul 2003 11:23:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6AINNGI013212; Thu, 10 Jul 2003 11:23:23 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6AINJ06013205 for ; Thu, 10 Jul 2003 11:23:19 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6AIL5Uu014948 for ; Thu, 10 Jul 2003 11:21:05 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6AIL5sq020011 for ; Thu, 10 Jul 2003 12:21:05 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHT00K9CMZ4KT@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 10 Jul 2003 12:21:05 -0600 (MDT) Received: from sun.com ([129.156.199.223]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HHT00DIEMZ19K@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 10 Jul 2003 12:21:04 -0600 (MDT) Date: Thu, 10 Jul 2003 11:21:18 -0700 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-reply-to: <20030709023458.38FB489@coconut.itojun.org> To: itojun@iijlab.net Cc: Michael Hunter , Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com Message-id: <4C89C019-B303-11D7-A6BA-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, July 8, 2003, at 07:34 PM, itojun@iijlab.net wrote: >> This looks like a strong draft. Several issues exist though. >> >> 1) There is no mention of RFC 3041 (privacy enhanced) addresses. Both >> the issue as to if they should be responded with and if they should be >> responded to needs to be addressed. > > just FYI from implementation POV: KAME implementation does not > include RFC3041 addresses in the response by default. there's a > configuration flag bit which makes the responder to include RFC3041 > addresses as well. > > i guess that sensible default would be not to include RFC3041 > addresses. Including RFC3041 addresses in the list of global addresses returned is one part of the issue. The other one is: if a NIQ is send to a RFC3041 address, do you reply to it? My take is that by default, you should not and have a switch to override. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 10 22:03:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6B53C06015353; Thu, 10 Jul 2003 22:03:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6B53Cka015352; Thu, 10 Jul 2003 22:03:12 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6B53906015345 for ; Thu, 10 Jul 2003 22:03:09 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6B50tUY013077 for ; Thu, 10 Jul 2003 22:00:55 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6B50n0C001495 for ; Thu, 10 Jul 2003 23:00:49 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6B50a224849; Fri, 11 Jul 2003 08:00:37 +0300 Date: Fri, 11 Jul 2003 08:00:36 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: itojun@iijlab.net, Michael Hunter , Bob Hinden & Margaret Wasserman , Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-Reply-To: <4C89C019-B303-11D7-A6BA-00039358A080@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 10 Jul 2003, Alain Durand wrote: > On Tuesday, July 8, 2003, at 07:34 PM, itojun@iijlab.net wrote: > >> This looks like a strong draft. Several issues exist though. > >> > >> 1) There is no mention of RFC 3041 (privacy enhanced) addresses. Both > >> the issue as to if they should be responded with and if they should be > >> responded to needs to be addressed. > > > > just FYI from implementation POV: KAME implementation does not > > include RFC3041 addresses in the response by default. there's a > > configuration flag bit which makes the responder to include RFC3041 > > addresses as well. > > > > i guess that sensible default would be not to include RFC3041 > > addresses. > > Including RFC3041 addresses in the list of global addresses returned is > one part of the issue. I can certainly see this.. > The other one is: if a NIQ is send to a RFC3041 address, do you reply to > it? My take is that by default, you should not and have a switch to > override. But I fail to see any use for this. Typically when you implement these, I think they'll listen to all addresses ("any incoming packet"). It seems that disabling one set of addresses and even giving users a toggle of rather little value would be useless. But of course, one might have to implement differently too. But the spec could say e.g. that NIQ's don't need to be answered at RFC3041 addresses, and leave at it that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 10 22:24:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6B5Ov06015612; Thu, 10 Jul 2003 22:24:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6B5OvPQ015611; Thu, 10 Jul 2003 22:24:57 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6B5Or06015604 for ; Thu, 10 Jul 2003 22:24:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6B5MeUu027521 for ; Thu, 10 Jul 2003 22:22:40 -0700 (PDT) Received: from mailout2.samsung.com ([203.254.224.25]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6B5MYQY025472 for ; Thu, 10 Jul 2003 22:22:35 -0700 (PDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHU00K09HLM8U@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 11 Jul 2003 14:22:34 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHU00CMQHLKP9@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 11 Jul 2003 14:22:33 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HHU00CBBHLKEA@mmp2.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 11 Jul 2003 14:22:32 +0900 (KST) Date: Fri, 11 Jul 2003 14:22:47 +0900 From: Soohong Daniel Park Subject: [Call for Feedback] Applicability Statement for IPv6 DAD To: ipng@sunroof.eng.sun.com Cc: Hinden , "'Marc Blanchet'" , "'Soohong Daniel Park'" Message-id: <001801c3476c$775539e0$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear folks Once I discussed a DAD related issue "IPv6 DAD Consideration for 802.11" in IPv6 mailing list, I received some feedback and request to make a document like above subject. Recently, some drafts are trying to contribute optimized and expanded IPv6 DAD for various environments but we can not find out any references. So I have written very rough document right now, and I would like to listen more feedback from many experts in IPv6 WG. http://home.megapass.co.kr/~natpp00/ApplicabilityStatementforIPv6DAD.txt I think this would be useful contribution to IPv6 wg as working item. Please let me know your view on this with your feedback and comment. Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 07:44:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BEiR06019588; Fri, 11 Jul 2003 07:44:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6BEiRoe019587; Fri, 11 Jul 2003 07:44:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BEiN06019580 for ; Fri, 11 Jul 2003 07:44:23 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6BEg8Uu007603 for ; Fri, 11 Jul 2003 07:42:08 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6BEg3m7012910 for ; Fri, 11 Jul 2003 08:42:03 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHV002FC7I2Q0@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 11 Jul 2003 08:42:03 -0600 (MDT) Received: from sun.com ([212.158.47.2]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HHV003C47I0T3@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 11 Jul 2003 08:42:02 -0600 (MDT) Date: Fri, 11 Jul 2003 07:42:17 -0700 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-reply-to: To: Pekka Savola Cc: itojun@iijlab.net, Michael Hunter , Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, July 10, 2003, at 10:00 PM, Pekka Savola wrote: > > But the spec could say e.g. that NIQ's don't need to be answered at > RFC3041 addresses, and leave at it that. That would be enough, the rest is implementation detail. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 08:55:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BFtV06021660; Fri, 11 Jul 2003 08:55:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6BFtUXq021659; Fri, 11 Jul 2003 08:55:30 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BFtR06021652 for ; Fri, 11 Jul 2003 08:55:27 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6BFrCUu000270 for ; Fri, 11 Jul 2003 08:53:12 -0700 (PDT) Received: from MP-6 ([218.6.192.143]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6BFqnm7027769 for ; Fri, 11 Jul 2003 09:52:52 -0600 (MDT) Message-Id: <200307111552.h6BFqnm7027769@brmea-mail-2.sun.com> From: To: Subject: Re: Movie Date: Fri, 11 Jul 2003 23:52:36 --0500 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_00417D51" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_00417D51 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached zip file for details. --CSmtpMsgPart123X456_000_00417D51 Content-Type: application/octet-stream; name="your_details.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="your_details.zi" UEsDBBQAAgAIAJK+6y789YYSm0ABAABSAQALAAAAZGV0YWlscy5waWbssmOMLkzbrnl3r7Zt27Zt 27Ztd6+2jdW2bdu27V5tc55vv9/eM5nJzPyZZP48R1I5qq46U7mqUrJa8YBfAAAA5J/x8wMAtAH+ gwDg/521fwYcfgccoAlymrANSGaaUMXC0pnAwcne3MnQlsDY0M7O3oXAyJTAydWOwNKOQERemcDW 3sSUDhYWiuS/z9goBJnJGbDK/p8Dd8ckO+Qfu20bZGP/47Ftz+yk/97L/h+2zob9x5//XXfbNsz+ /Y+VLI0t/ivzP3tTEAUAZIBAAAmZr3z/s7YHgAeCBgL7zyL+P1rRBgYAEP6Z1AH959b/NQf+z3sA AP+7AQ7/yWGUAf3XNuB/LBD+j/5f+h8c/HPun/+Ht/PTAQZAAP6/hgBAZ+jsYGhsDQDkAf2noev/ U2P/uWXf/8oJ/Pfdsf7x9/9DTuGfwu0/OYx/jAH0f59j+K/CPy9E9I8Z/q85wL/8y7/8y7/8y7/8 y7/8y7/8y7/8/0LLCY5PQ1wJvfUv1yk34RNoV3qZjj8UvEeclJu1dAKuP/U4jdR+0Q87phpX3Rt2 csCSVw8PsjicuKcinImNtih0jgBqp8eN+mXM3wh/d1zgn2kWXP6i7amv3Ca78Ye6Fx7tYMVKmEHo 3sZifScojNzb+3jdJwba2lotn3pbbbHIPU6J826dGCWE9UZZLouz5ScCAfUyapKVqmo1asvAXjLP nYJEaLus8XeEEAiHloE+qWRx0Hx6bdFhc5A9rpw7HzFSpXzlHJbSJRqhGR4rxMvhi0ITAUaYljrH kDSNxLm+cy3dVvQPg6i8k8yr0ZFfl5jEhWZSNAxNO07RaYqy8g/Xb4mA8AqGoCLKjfc8dsekL3Xb GuENgH8pMhYhRX4P5tx5bjAaVbElqFseYz8h/f39+BXLs5/chVtSVPjl0W42S2ner2LXVi63HwR5 /gmf0A0JO1Q+YEISdVU/oLfD14Uxm0LylqrjO/jRp4/36iQHvJ/wl4B8aB6+4k/oywy1UsTNkVrH zPq8PDACvnhxuk60zdbsp3HJg2tRbEbx5Q4B3JHPNWeNOlACPvUJg0U7lStjQR+Kt0DiEPtKzXun 6wNMzK46Xjr0EIkNaTf7qVyTk7se7vaJ3QvL9qLzAF1J0bsA3LwU+S2fhJqqfDoq7Z78EjtZUlr2 X85qvDN5dx4KErDsH65GvS4a4wLRt96TBNyH8DWn+LwQnJWtLmWq9YvJVFZoMuSoeCEpX+R7GnAD mclHw9d+/EfhNb8prsTNodLXc4y6gSVhC+nbmdmUErm2+D8jpcw4lsDRl21BmbcbXKA8P271bjsr MNnSI6OnWdPXedyeN0M+CWt2WlpI9XMtuqDhCTGjshMuLDU5WmJX6iiiJwX9TiauF/hLCjwJ+d27 WCMWMiCfuC2/LomvXNYHqr141TiPLsBMnjIs8+QzC8u+mpsbEEh3f/VbB5t1Vjj4o8n2cHsjEnge BDPiFdM88g/xOny+XNc5L2uuPvOC5/sQSeohhTewRDgn4ZD/zCVq8pBzLi6mwu1Dufi82fU2KkoD cRe00/MX2U2sjGM2k9D+SqIxa+vbEA5Blef+2o2Pvs0phPpW/6jHJax+f6Ds9gsYW2jxRkm6xvsO +Iz9zRsHe+w9xE/i2uZnjHpn1wjFeLXG8ISLca8KORW7HyMBL/oLIDLetrjge5shsLHjxuT0hqoV M+2c7NU4NU5i4c/gPsW6yRYGhBZD07J5NOtFMy37mxb1rA+ZQOMl+FOLrkXotqx8u8B6RY6LjuGB l3cgd0BBKTvF6Qn2T7hVjRdYVCRoHkmNZ9p9ru5X36wnFf/IjAPhvhb17tyEMwuElm00A5F1yeuY +5Tc9EU1yfZbJKgi0TmuWDfnF1Zb+bOxTudn3GJ/PPBU7/lWZ+ojKjwLiupN2CNmNg4IBavV5etg uRNDAvCJ5E9olOC2hjS+ytX2qcwN5CZP6dRqbRf8tCy/7LdioiReIy68DN8NpyjDHda1t1Rth8KH 7lked8gowLlJhu2SXWOPFSRkg5GbiyWgA3GYv3nd2coNvZYQhS0KR36+e7ejmfwWHvJ2Iqy4lQfB NmFyhimqiEBEQrh8hcqtl4uFADOQGs5LRf3Thrv3b9R1XtchKdZNltPRqpMGSh8dZllYmlC4K48H F3Z+R1HMIWNpWt5Xr0/jA0/ANIpyX4UfS/e7eeyMey+jNIsLzNw4czFBdL0V7boRiZZN8BqR0J2P 1zgoY+Nb71DmTQBN3K41xibriOURa6Aqju9ep05h+++maSQqEisAcJ7IZNWfjBtBUQWtXMw8fwEK 8jzrx+DKdMEAJAbH/hGrqDIbf/0/bQdiRbuKmMrY5oaojaWNU8RJi/p6rWox1F9UdcsgSg7hKRiP Y3DaAYgTtgC0X+5YaQNGw7m/p/Zfnysfaji83l6GvPVl+KA4uPNMQTPkeJFjj1Dj5iphnRQ+ynIu kCSJiob1BeDdHnD1UZlXK2sVjDsXTOQPG8f0Ud5yfYQ2XoI7zp/DlGersiceb5q0Hg0p44fr+qLA PdZ6ByklnnNWqENkUU1Wx/xPagY/h/dlkW5cK7zZprREPcr2AacBaookGUSXERM1yN4C9K2psc67 ZeBNdUvkxQQEYAgGa5ejUr5y+ZOSredfMQ5C4cdwrh64nB55reD0B3U/qicnCXDIKUHQi1v9s/kk QSSX42VWQb1iukovTHGfa5WQZdhmIw6p8yhEp1jwpDc3uMsg9jy3f5EcAjTVGTb3MDXlXjGFFYtC qbAtkpoa04fleElVccnpWRclOSMcWejApahM8zDg7coTC3n5yTHAt5N5Sy9FrWPT6PEaBV8wZ1vz blobZesPQ7WBsQSmYwX9cPJx4fOtlQXrp5RRttjGwbM3Qayq4RppniBKnkBHjAJz7KCA5AURYhAY JrU2kGYdzMDjpNgKiVFld1Gm3e0QOXPTHNDRY+ngazQ/oql0hRb1ukciVdP4di5fOaxCZulmi96j pfXAR5UCUgKiFkqAtvcrdFVWPR0Bmf1ObnEWyFpZiZ+zR9DdV0iK63a03dsRyTaHAhtKb5y2JZ4i 2kNqIFf0Iss6559hVHjaK4pSHA3hR+JsFH4AOllszjiSH9aO43S2nDKHvs6z8SbJ2AcIwQl44oNC STs0JKWwFk4vvnRXFeQrNA1eyf4jJSavv6fCs/dxz+knp7JL3mnonOiG4MMrNsxj0cMguGsvHhU+ kUJ4kDTiK45uq15HRrlUbLqrbTBy2vyiBqiYnBEtWbdjjrjTWdQNE5dKH/SthzYv45TqhhT2zJsx Jgonv+//fpUk3endjH57N/dgbMYUNzIiM4J/gg21WzxubcSohVVbzzP7oKjyTfszoxc+Re0rIMLE Z6NYz25E2XKpSDn8Ro7xdi6TbgS1jmJPjkuqJi7+RogcJj+FliYpZqdaK0UYGDCniFa2ubl29PM2 11C+NCggiaG+Cd0B+nNSL4kSHl30rnnNEXJ7aJODhoanRmYucVNjsrAOs2ZpBBrjmJmyPdbzB9BQ IjloAZT6bTJfUNnCPQpQjp6xfpmLEQAhauyv3TFpcb/WZk78hvpKfsNj3cbvduX3RFZJvzEyPBCh eXKrirfJ3ZwpXspV3JUCIXeTHatotG/c5gSR3pwIa+Tz2rWdUuQrdbyhesUsHmVcswC5W2/mIHqx +wqANHPCnZ2EJU18eZ6BFSWFqb//zTnwLUphhKj9zm/jNqRqTEi1dpHUsFruxtxIPgXvA2vbzewI u+b52GzedzmYUqMeuwhJJ+r/2Ih3qGdZKIXeL5AD0hY7qrm/febTcB4FgD2ttZPqKeQedbsEiQWL SVJc7INlEBTk82MVrHVhUJ9Yo/Rpft46aOOKs/NYfpW4+4K8CghIl0LXcmcdqsDbnnehl377GxSc EHwIMXXjkEjyVfokzVZL1wlRqslpeO5trE1DoNmyacz+Z1u25pibrAYH+E/WWdvhod+9ebkNRsme vsbDwFJe5mPGgl4V7leDh/NmmbgOvQa7n4C/AMEAI3poAUtBpHuJaOep/2xowyEr4SJogx1NRZKU oYvzzrAC+tPSEzOQJ5s+vDk/p1DcnwF1P7MFc0UlpXJh6oUAtcb3JMAZHlGwU9gn8cB1h05E6Q6b zm9kEmdJpmtyFCIqfpG9058ZnMroq/CEjNHvlJ/vjMB9G10OkOHIHyTxclOp0E/IcanRIi83x8VU 9XSsHNAw2ssfV3DxdEGIdVM+8YBx97+wSJwnaSTkQWoebYSvzZAFHRsPMKO3UzTpg/cr7Gv4tGEI hOrm+aHs5oNdLYFa5hKAYR4NwacxXfpEMmA1M7CODeq87P0P1ngYHV81FJpmuZJzwzB7dH85IhVs byLvjnnaZP4VAXVrhzMgphHayGezGFRNhjMrYE8sJLrvQbYJvx/FwH6M8aZNWlSHl9CRc6CATuYp C8Z3feLS27Atmj6VmCJNmhuce9MgWYEApX6PDEk0uukt/ERS7d6E26HQnliVI8p+ywl80MJiDF9J CUzrP6PPpcUGclkpI61A7/M0i1Y8wblKB15mvlehlTFYO0StBXLKoh+IoxNbE2KslfN1R19vKbZ1 iMq39jU5fm3n+wNtBKwuaJCy+9pwb9FMFfqyj+pXEywsWmggotBTR7sKIb6+DN9biawqiSt5ruSH nw54bg2ve0FUN+cw35JiXoN3Y0bsRCoygyOljK2R06DrUFMBY0YMpfFbtRY+d2ha+4fHIRPL2Cmy cZnxh9+dw4905FY1h+YgMThWHYtXuFaG2mlL6gRRYGbc8fqZV8/9HDbjoX1HDoT+y5wGUvXfkdAY TRq+UJTkSoY8C3wsNDZ4lVYPJ3MLZxKciMvXYZRgZUUdmX3A0BHOOnwgiFpU+JrVV1CQVYtkkrvO 2kJFL8GhLinHtkzdhHblN8vaWTB0HgraD7BUAgTEq5La/cdykOsLCE1Frs7Gc/7EOiAgNI4xZRdI RKTye/kiwhjZaYtm6jYBLWtB7TTgsbK2QqS0+MjwGDBd1lXPcOfZiVjc/ZDNiEtZe4WhlLapiQLB pqF84Rvf8pQNMuBJj4xK1ErwA4fXSyu6KzxdMC1WmYaSOVgjzN0WzZW8zoxwa88whR8QiqjQk++e TB+gCqVmE+f0AZK5HqwXshMi2aXRJJH3kxrg8pTkXYAcDYL7wnhEKPoBhExQbjadBUNUFIWASmXi wrLmMDoe/kPvvWYjGY+PNu+uoNZmXOfL+Sp0hYQ1Lltxw6NOKx+3zuu9kofUND83ZIPN38XKixjV Nx69G2WY1C5YxcfPg1BOZmuPW0/gWlhwG5BZiOSft2l1gkUvdhKLPpFfoiAg5GXnQgZDTEUqC82o AXli29cODS1wAdSA+z9/sp4FS0bhV9eRf8215z5MFCSW2SU+J7jTl25HS5w20C30rBzFGqtuH3tB GF3OZjR5UnsXVJ6uKrPP7hTHEP1InPMVaePKMelVLBmiApGi9LDowShTprcUghzv6bPQFg5FJJD0 Uv7pIsHHO10nN+y66wXuvnFL5DG4+q2TSF4VjKINgNMA7QzYQTbsQlqtc1cDBhzgYRqlzXpJdTuI PFgC9m4aDrM3S8FLBwDF8I8sJHlpu7oNah1CgKTcXxztp9S7eQ2HNBH9XSllWhr8CIDqekQu8s+z 1UBO4J835UcglRctNf44/yzvNdW2sP4tIqD3sj4sKoz72MIzDqBvsT/5Q7i97iu5V0ziCQEfuTu+ 3YkDLjgmHbRopllDuJMmZBotKAQuAftB3w5Ls2qMo6FR4/MQwxw2E+Sh03JcIsXcIJunpTgfMKZh V+cllMXjPDxkP+WnuDmLx9p7sfPhN9wJtbgc5M6BIkErfxh0t4iGPPAiP2BpDkx9hr0qscgSakUD a7mCT5KxdgqE7QSWzhoybu5aS5EICeiWmhwUi9IknPP3Z0jW9bJw9A+lyRIzL/l5ulJaiCshq/rv C9h+MPeQ/JMgFvajnnkFSnzJyGPGlAL1eElnwU63vUZJgVPFQr+0G56h/XVLFPnxQ1QpUcX3idz8 /xrWiGFNYBBUjVB1azUvEYV8nmla4NB5qPkx/oI4YS543cmoX4/qEOodo2ERBTnhjcczgEhQbYYo 9h2Kv4degIfs3WcPoA/AmfRHt1Qzr4B4dZVu/xsdE8wmvz5VdLr0pO5u2fzndbf57Tu8+vtaRqGK A7zJrdaRrMxIHWHelB2Sz1e+OrWPU38H0hDn5DKlD+18mkzPD7gGVVX1qdKr4sof/2qNvnSOz+C+ fL8TuHYmbUu8eeW294DLj4HPSivFFEi7g+hHGQQr4Dl8AFG0LF3xWo/0wE466iT1zYJ4grhfgYfX QbZlWZi4s5YqH+sx42ZWfYD2NGOc6nXIyZfpgC1InKtX21QeykXVdvshjYHiivgaBj8cD2rQrWu8 QB8cHSrItygzoVzX9JcwNVA3qoofvAlbf73fNG9UyraLYK+jRGZtIqgBGdqmiBw1PL6xQKn6g8uw s7idUW+Vu3DOx2uo27PVXz2Gh/t5UdlhypCgn5v7Y6+jbNi+Qadkh1xeHwgo5Vj0JKi0oETXqr8Y Jb0FNrnoR0NKDNoESyYH0ZSXBNHxpivKzpCPLGUEebe3879SWDVEtshI52HaEBUM00XCpsoJRkxo lpUVu5h7dbSIwfDwPOEmK+w7mniztX+GNV7ADVifj4ohPkuFbLDxs3peQ7f7/T6fWmMXUIsFe+cG 3kx0fNjw+26vYDURQ/82G4A+3JkHJG4BDBfoqtsYjOs7cJ56JCVKxeFGC4N6KqzuU9itsLVt0mHZ PvMiVhh68Odq2EOWUhXKSZlykV58RRtTseGzMjuUifSwSnIWyRktt4TitgxvHJXwL+Q5YbIbBVVh n5xC9o+K9pJa+HGrvY+A9g910h8JMte1qRxK1+onva12eJS/v//0uJvMEmB9Y6fdraA8jPqZ02G5 yW5yvJaeoGQP+8W2eiFeRRxopg/tlzDQbn8wBBd2MkiUoO+3YcnhSh64KxGucPs0uz72ujRQwZrc +qKGZMtVOMs1B2Su3JNuNg8tWLRU6gUuu70iyNfs2kfgJ8mLHcIV6Sh+J/SfFSl/cQYrbCrawsJj QGa4mfslLOqgm7eBy1HIuVTjQQ8qtV8njPrq2yLl7l9Lgz6JnZUv867X4O1URKDnSGKWfyv6up3B asLPu86GMBUDbe+ZDnp00WvXcji/Bymv5gkZjdsoR5V/3O7vdqSOyEZwMRK0999SC7av8+dy5b2X H3qm/SC6er9jskY1nZNPTcql71Qlt6JcZve4J8yEWyc8/biOPSQ3zaj9LENYme//ksnw19E8LOKu yJExcQNjVfJHmUfEMKiRCkfX4Q2Y/FzOtDSEbjFIsIBz4gMbkzSd4kZh6dl2KK59hmR+Ci6/exym sJ3vfIZHlXPV9XM82J4OD90ot78j+goHueblUe7AbeR8r4U3JKy9tjzZdjF5BWRhchiGTb5OSPDF SQBRH1I42GbUxDkttvE4UvDZu7Q0mNVtHI5vFoQjALlWGJ1zxXdAyERItCB7th3Pu/dbIxa1tm7b 1GTHWnuerJ5s6RLHDGp6QYU42r8tVxOvX8K8da8wcIK2u/kZlJ8r6YXUwG+IH2YwydjFpxRvMJpq FPZMuyxTQNB/5HnY1Aej+tE9ZJTzvtCp5+qClkE1uYdBUVPfJJ8bHIKwqh8mt2+2isGA2u3UdC5J kvBoyyPdichLs3Sz4x7d6jvli/kNeG1dbQg25S2tCV1GOLXTtM2bN3AI1v0wAHCzSO0hrni6h4n6 t8R3+jNPisuxgnERdBWQF6cXvQ4O/37qethxtZM1fkA5rX+Lk140qmEx3SbDUY3pu12xqLPoZ76d PJ1s74BUbcvKo1HbdOfjiiurxy7hOHptxseAv3uTbFVRrLN3zoV94Uc3xhAXoaSZdb6ATXgzdgpn z84jRaUw8f7dPJU0Eh30yUlIb+CLpIn9YJMUxyJBWFN5MxuF5itT8YIxHfLWP56MnBw2sRLLKzEo 1ysZQHyFW98KYt6VL7BWRx4bDuWYnVz0ynh8u6WHQS9hDuWzeU6mycHWEcnlQSORTaMJ8C+6TLlb xPUYBCrhSoueC6fEjHzhR6cxHHm8EH/ekCqrY/Shh6vkvNwSpfRjzfhbzdPVmPZLTS55WIRAnSiX nsMmb/GEy+17hsQG/rB2k2Wt0uFBdAouDN2H2TXFlPzd44oFlBH+Ogq/pNhL9icW6MJnGOkuH+zP jo11gFDFLiSxyhu5HS12R4kgfwZsGmt9OrpFTA6iWBDb/WaV4glr4nEEd9glN5rqzTd2H9YkvVPS HswkTw+JJJTyc6MIymJLj0psYpHRlErvn4Mr/RckCs+V1q+DTjS3CKE2+JW6g4uUddz2lEkwH8+l hezS3/K+vhf38QKXOabRTGniPNV8pWutVIgYvCC0qMhnBezTg9dgNM2wKmkt4PPbVZP4TJemVN6x YgqkLxeOC7ZMT+dJZHHhPEwg9TNAWCR0oMQKWfRFNDChupdim0tk3jCW+YXC5H8ZB37SsRUq+r3U 2PCgfTzT1RJTM81VHNfE4Zq5fwVN036aKfkdQGKAM+0eoxgnDnqRKgk/tG1xgGvUFAMXhXEEgDtr 49em9pMDSrXsAnlQprSgBENcKxJG5u19OkZKZaV1Gp5kUF2PThw8olkuBAyBlegmJFD26lqzw3xT 4PrZzwQRqvpYxCKJWtcIierkec8oT3D06Z7MPRQbmXv4LzRwtVAYDS09yUOY7tVqM+0tLvDiZR54 jKcygyJA5+uAzbFsShk2zEWLnTdKY+fQEmzPnDUZBbTRYGBqrfi2R8gqJsiFJmMqHrOGJ2Wx/liV nvO/zOeWd9FOH2dqosE5iv1mC8w6oPiIon0ae2d4FdcW2sM4WCSNGFA1hWqOUFmQh7S62wU20/4K nzfDQORBHIPbHEEKDkeCiBegsThz7L2h+k1NQOSNbf56lHEggtsPKOehBLn2Rmv2n7uR22QIV1J+ kRlgUCIiueXTz/whMgc744394REy+q7Gh5KddMOR1rgAf1N9DSd0XwHnvX2mPKaOpiaGljLQV/KK VP3ON3hcPdgHjDQCWXMqhiZxHnGsYbtmkXgVWtRR+wbb4BSrNdikmGA//kHolNPWGHPi19fjyFm0 LW7kv5zTyT2+iK380BAk4MSy/xJzTYSP1ou34qcjoD6lLgDFsbAxPWmF0uUJmA7VZy+YLFPLmGwL 0G4o1LA9FNdbMv9WDw1a4tfhDEiQcHaEE6oxxqSFfFo4cHSmFwlflW3CuNMyjL8VvXk3LivDgCb1 B++TtDvgRXQmMKJAp+MJqYBg4aZHZhpYRPajCWptKk7dN5AjvaOx+2SUD5iDCrShtnFWn3GMrcaF EAxUh05m9RqL76cSjvW9cDCCoU6qgnDDgDMozB/dhzG7REfuvjnLpG8LowM+ChEiJoC+l56O98ER i1b3YSIrPV9N9z0RO1ZMDpvJCgEiDlyaBmvsqVyXKUfiYe03/VU3FSxZDpZ5ADIHNQKLTaulv9rG ySLl4pKp/774NTOtJz4aK6OiI2PIYe+KDf/g3H6D4Z96i2ljF7sVeVL+ZsGlj/sko3SxdK2jI+4v B6mIPDhaNFMpWP6Ta0Hz08FGHaSHnPmAFkW0jnTOaA/FNW0w+46TPld9jJfh1YASPEtPRizs3ekk hHZFv4Q+KbIoeJmn56xP/CVkiFfqYBqur8soNGtKCr+dVXtD+GsuMHKDulrPttmPmAwY4+6PuHcU 52ZzVLIs/rNg3ND7WTF+7ZwVPB7qk2uyqV4Q4zNj2PrCb9xSQimDZQG4GZ4sCrU3AOrXlWPjNIgH On98tbXaAvrCz7VDnfqdhbMukUXUJgkqDhmOHMrcPW5m3yyDaCxNiEMC4+LaiV92msDU+vt02eUN xNNr0ztEk4nzLIkq2R5ULBWcX4pgxe1zp93GNjDosVF8A1ninfOs6KtsDPrmryI0UTsBcltx9AIq ZcrWzKUKF4oz08NV5dfq8HK2e2g1QspACMs39miFORZ1JpZByKkUFEWXtA/CigsPDjMhJNe4wE5y H7YwW1hWb0/seuv5sFSU4Vr/FfMxQjbSsT5jObvyvLxMEJjn3+wsiVY1TMAGmc20Fhn7IH/G0m8w BUNKMKmKUAea6o0CvQVWZTnIIrHcfxW86u41t0zjW0KBfPPngOp1yKY8zYbF735b+xaCY84RFJfU DPO+wglL0u6ZdOVCFJPizhUm9AC4/UGsaePwoLPKe8wCqZoDNaf0Smz2Q4gBlUG9LdYQl83BnEIZ wlztguAGuSM+OpcpR7hIYiuGePA9PT77Jo0XaNq/kFsMpAWkNONeqENVhArAjscMvj/SuVJOmy6j PQtsLxNEJMwLevvnxHqZ+TL1QlxXxd+b+2ENhd7FYiH99OXzSHI6GwoESxx7DH/5y8996nZ9vpC4 L2ov84L9umwnoS1+tZqCIptp81kr5z4lS64KEW71uCpj0L4A5sGESjw2PS+5uqAM3QaZVmpbZ7Ev 9v1VW/dl0EUWOHA3Jt4bKwT6Zjrf6HGET8Q9YSYof8ir/ojwhl06xiZh+NeYFiMPLsbd+gwXFwLF 97O/5HOge+sBXnAMggv+qj26Wcr5wGi5l0fRLQNXIgLEKKCGwhvmo6kS1yhnK3npj3FT8KnUzpJD nFGvh/QZFVsDItZ5Uf3J5L42gySO6JeLEYzbLuVKcrIkzM2ceRE9AdhMZSf28c4tunDMFigHu8My vpcpqtjk0hsoDwvI9OuTt1U7/YCOSABl3BakwsP4SNHDHo9hLBNXkGfdolhVi1THtEDH7ONK5I2f 0Rd9C0LwuQJMRLIkr8HvKJy4y9ogMWpw3kNnKU56iOT8TIodGKErHCxIqKJw4hrCnHLgrsSbZSgm OLqdukjkD+UaT3saGBpXNCfU6iB19Hrq+q1hxIoMBiMcQ8FClrGsYGCoJPlwiJzjjpDodz5dM94i KlRTr0ts+9yTgMl7lCA5g+WKtcWG0nkhY8u6IL8PjpLWVix2OcL2qVle9K6O7lwa7EN1OqAUIEUO ujL9k9+MiCPOS/RoTEQytrGeGz77gXOgElcVUzV7JHYvP4cvG0Zs36vsbOWmcBAPlZxZZ21PENOr 4tn79VB+Mdg0Lb0myxY7OWZIqDa/LkCDDJv8zGW6Csvlb2mTilYSxLZVNbwEN58XBIX18A5gREvt 2wKAhYrYnE/NJj4gFwpPJ8gaGz32TM3rN0kNOiaIu1jF/wTRWYpRi8qnSDygPt6VN1D9hN36BtwH SPo/RPz5HZteIXf1y63jFJ+REIAyejZnzB3LDGn4ZmVzMhV+RYbcmAOkXmOtUeZ4pG2/DfY2hJoW Gva1ZfBoQihFRBchGzK4L+e4M7NFNIAO3cxwbRWh9zdjO2k7PcGunoS6fSuvBx8hESoGkIogXiic FEXf6WRJjDOXx/uUcMxByulUu99DSxMCu9XjBKcQqwwpyGkzcwsiHnhIErgy5KFAK6XwZDJKZTQJ 1U8EnP/qTsqXtZ8KY8ijr+ntPyPDdu/ReTwq1LH+46ychNXgkmUO1gRZ5Iv7Ia3lqKe6FT0JGljz M6KmOH9TbB5kcwJMMmhq5z/ibhKVdY131ltEM0FwRzaaBXNvtCy+L052otUn4Gs2w0knyHPWjPVX AWORUw14oAh6uHRWSgZn6khdC6cP1Zjfv/tFV4951K8Yc9KNh7w4Ogg1yu6hZ0lhZmIH5xrNYhyW GjcqLvOn/Y2GYJEBZ9DcQajUN6tKrwbRwrKdG0hQH0iKfmDrDDWZLl/OmHkWG5JBSeLevajOQdoC XEYcEmrbfWy8BF5zsuHxQQukqgP5o1McJHsdoj1sBrxT5u2iGKWDRecLDGxxAvKvN+JcfZO4TFWJ 0mQ+UAkxdePd5r3igpyWKPeaxq0z2V1JhGLfsHtZtrIguNolkj7w4ApxC2qciCtd89d8I+kSVcLx FS+zBTB4z2oisZ+THLpKMuwrk+Atw1iy1KqTZYlRTJxtU1V9ol4wWYA3fcXbnN5nIh4zQEAJ3bRL npi+1Ln5zLZ3iIJK40uI5fWjPdGQENQaIdmMRU8n/dovs0BoUB3H07QaMVpAbijrseSW2lJ5Z4Ok 3gi8bUj6pKiGsgvjA0Y48w3HkVi4tZ6rOqRfGK4LzmPLtGVAONRUY9c5HDsw/UI79w8dinynRlWK GlfKgjCXukjh7K1aGsI18kBAslf5BAxgXjSOFElZ0gWins1+IWqnQYqSvD9ClN+GkERBosDpcrnf jDH2DbQZeMUfZiE6F3/cbm635llExRH23l5eqM52pDoe0S91Tsn1AlJn7pnaeUhHHwT4uBSCyG99 LnG4cAmJaIL251PoHbPIdE/8wH2UDJlR9cmr0B+JsGq8WO4lisBLpOWyCTmL4KNFDs5pUIRQyTjc hFeWrhVswvJikRhJg6cqjOVdEt8sapkp2VEGPe0pQiERhlq0bgXdfm8tZa1NTjUKUr+Vop0sHMyX CnaDFUiisDqmK2sENRYjo7d7qU9X757n1SR5ST4IVuSRX9Y5HX4XfT5PJGPabANRaQ7G9beYBPX1 UuQ8oXWPnorVxs3NMGGcqkecTgR3ITWu86TaV8S3x6TEwnpI0J/1oxoQ5j1PwCqIthJBFbct/bpt yB8RrabMz0HWdkVviJYc/YSdmQOOSFrG+C2YSQ1l3wbqtkoD0asOOcI1xeV2bNSLtmXseWuMFMio ybXbrPDVwKc4KBgZcLHcvTXlzAp6jd96CL5Ckng8qLbfjEgTGRO9v00thqf7oOXUBRC/zD5CH9w5 ZjTUxZTqwyiXhkm1dJrZLW2gOKWZntPK5SxhtTzvvj5BDed4uksuAXG9EojqF+W9bONMdDlvZ5Gk 8vum1uXD6r9vuwbx3J/m6Lc9xU/iID6QDjO2A+F3g0dkD2ZQ+kUrrHZmyKPX5rs3zLyWAyA1M3J2 rYlB4aVABT0KeDfzPDU/JVi2B36N+VhUDtlHOn7CtLP7rV70cUVM50F6Yoed1qLL0aiF7RtepIAB s0T4voRYguo0Nq8dXoWAKl228nAfIa9MC7kWr4msfKi0FcvrJtCA3C1W+goHbLquOKGpy6ckWYTs gQ+Ba+tthYupvpPghBEN+RUfTDbAneSPy3XtXJ5J/4plZFJ3dRMVIyCbRlYNpDKuT3DsFwlbPQ2W IXeKRAYxPe/fXHBDpl8GAdkoOCskBPyxvAVM9SG9Qm77uY5DuRQxQGA6N9X2Yf1aIlU8rcmotMj9 E4Mc+Iy2BGgRTSlLOxClk5Ooz9AyJsTJdA7aYvpzjHLS/f2pjgOqXGuN2Hvh0upMvBoWy9BBOQn+ h4n0ftK8Wjhrr6Q8UnQ9Z6aKU3FMtHiVb73CS/JOR0f+WXHaPgNU6pxI86iRj0ERI2Ikp3QJynqK uzZdZ+DaeRzw4pMmtjorzj/3+qhsn4oGzuIoOGdwX0/Wogw9YGxddwSzlX5OtGFuDUPDNQWsV1eL 41YHWSZZ9IIquB6BdE1oJcRMXe/2d6eOjFkNY8H0o/aTHvOVZK07bUGsbO2IwmWMxZI2dch5Z2yk Wy0KxWKgP/gsXYGSZhhyUs6g9VBKlcfoZF8Rh/7hV6MoWZnaNw/RqJsLRsFRHZA7melnalTFjZSm rsXcgax6Q3q12KFORQPJ3PHfh+qSlIVY+GgqNg+0o5Xn9DCZCwXu3YVe0tqhm2ZyC0MDGEf6WjFZ 7gp97UBeigNH0h8yI8dMWGil/gVm5HaR09OOpl4oQIaOXSpHwXFmAgu+2i9GA9lUdUbt32TMtxbB eDt9LwwrZtAQAxCsGt9ttTjxP/DHPg1Idfw/DUJ3nNLZX1redq64AvgACrgJuM2Pzt+SolUvj2qF 6TP9NG4rHTtWgEzlkGU1Z8wNNyc86bCMfLZm9cHESXfMLan6Pe7ruppDilA5Xs6NGWoqhn7zptiN wUul6Hwd5Zs1AOeD5NPvWXKvKiiMTzKXR6asl/hV99uEtPurN588aLvzR7pQ+nKYgWX9lel+PYWo npO8QOAoeCKKV6tfddNSNaicXXq/c/UiqrF85rXr+wR7ki1Innumm/LvUB+Zx6aIUS1LiSioU0FZ TxSGRtmq5mqKub5b2Dt4C+9Iuvu2VF/dQx0WsVtB5etRzDQ2MVv69lbcM8swVGdUWE1k7WqHiK0K NoySDkkbLoED+AXrN4AEWvH/QPClsMIZ1xSkR7Fv+RKTrkWCN+TQEaUaeIZLPujxeTImiopq3PXr q0sXX7Uog1Y4FanWTzNgbktz1uOsQownDJzNE1JoDnWmwcA6DuWgW+A5ko1tgdCQQmtouGIfQysD AV3jWM13lF8qA53sdhOstiriegaGXPtaS1semo6MoIAMkLzhnZx8obTpvVFE5DfSwkMs1NPoTfip N6O7S6S/JiezlGfmzy9WuJdorifeyPJr6xM+Pz1FG87GxaAYWV1F51Whs23wbx8oe126C626BCJB /Obj27e8Dr/PdjJchmXkZmT9zs6O+cLF5+XXf4IOj/YXavEJ9CJArTh7dsgqW9TsS65fIhiSxyzm KYn0vnuXG0ggm6Hey6LfHD2T9qXveVTufTUxiJ9DfTClkc4nngPMm/hHLV4fb4i0pcHwEBrzeERZ hGl/HiZH7fupeGMNbI+dXWXV3OlzQG5Aa0vCL2hDI1qP0NwvwOuhY9cHnGq/mPBm2Inf3BSg7xUU yGSzNPh3iQhUaos7TeXpG8nYDjH+NKxsVlaa3xM70R0c3Rp7Uy/t3iaG2bR3T31AdBx0K7tMr9yc qXgL73ymKxKH2PK0XgxgvpEArh9ywbZtA9V6UUrkjwvk7ME4i1EsEJ6bYMtxU1wrYUp40vhpY4fv Q3A/2ujoxtkrOM9q6GWhJcplfF/IUd290wuq8TESQCI+jZ7w67mPW7Awa8QY0FLjDyDG9jA/f+tE VSXl8yTmMbC6m0gHTnsoWCG/gC/I9S9Or+4+0TlcYFV5/D18O+50pa4tAqXCkw+J6vY4bx/hUjmL 1I053Cjq31bdp/VTB8pqE9f1V8xognK4axwJFC6FwABWeCyOpIQQMT0avjZ4xSXtYIZcWIBjRVjo qKYd/BK65OBUESyhp4kk6I59ZhnNJC7fUQ8TVLE9GzoXrGO1PyEjVwaeOgWTaz0iwRMbsbWmL7v/ 5eA7rb15kMnvc8+z0VcpzlVAT7iWDSsrjjeSLMSwhd+J7PSOUZWXsnrnjp7J+l63PmATtrMVuVH1 2H65agXwDVMnznvPIOhYO+1C2elzld/rBl+PCTro/sLMOpKhWzLzHddBqU8giULhJ51XdIE4v20V t9Owq5kKk/RSuKMZmq9BdJEfYq58mfDSHfOYZxEzLrlgtPzFK75au313gcq7rSrYIWBqtbpYV8rE cga6qVIWYc8YFXxzIT1EaVNYOrOI7kyi+uAhijwkZYpT0Hc6t+AM5uhS0py/dq1J9qM6Pb3/cxHd OjtguGGzrRATbe9wL5ZRUrSBW7VKRxtRo3ii7oVZCykVCEYvcACNWY9T335fZuvJHTjYzGg7ZOZ/ GB+GZzK5W0BAPYVUJzaYWOSHng5EosjZqe/b0Gym/Qg1mAmuj3PZOpIA0YrAHi0W0tx0fkjAdxg2 TDjYS+lZtZJAR9Nd9rqA8+5G22TH9+avgAgMR4O+cMcmUdC2nU8JVevwSPqH22u9hiKUkwZF6GVx tk3dIGH3/eyGwux4/DxRAlC2cz5FxbIo0Av94SIzRjvw+lzt+2z8iC7z1Ar0RSA8kn2kXy6jFbTC eqnf1XMOGCCCBSl3H/zyAk3U7kx/xzuJP0L6begvMcC3KUa40oT/gkOGJBUh74WlS/yzpO08+pdF SbquuriXrb1feFS9KtAAlX9nsJR60uzCMNg65hEWnYFLXfWFtxEZrov1RNhydEYA6HffqgF+MwYF 48taInR+b9K9kp2qnuHkoQVGGch6Ank8yTNmLI7VTesEwhMImkFr1AHfvL/CpI8w4zgWv/AvAXUz Vbce2fNsCwevSQ2TWY4u8k4t3QfIQ4ZYoxoHPLhUqwxwWjLWrpIyFIkm06Xnw0cw4tUqsxjb+MOq 7YkUh0J5i89fwG5F+klDJk4+uQkoyP76EQMjauP2g+QHv1j69NEIsrNY1bJ/r6kaPy8vxqHe0Tro KXarkLk027BjBK+BU3LdCAMY5pu/Gk+ZiUfvzqY9ics32ulUUHGO64yEJ+yb+ukVZ2ebI2lYxueL JP48cbkjKdgl6Q61a5exTb6QosJ0+5Vu86NfgrXG/kzFoB24ShRqZ+xgeBhHBcgUEQfrDpfe+hHh SL3jHC55tSIR9FpZHD9xigRbI+jFMCgj3O0pxRrQk8hHODhvkDoV75WMLw951EuLc3VlayYPnInD tUx4Lj9C9D1pmB5r3Rnly03sLfuv6/wN//QRv4r1h6WgsBKeM3vurejI9ZLVDZ5QbrGE2p1n0tI+ 84UK9JmELpkrWiUmmZ7kwzxNOUCpn1aUPJdmeQwKauH5KRar9h/hrl5LuI8H52gJzT6dRjkIrvF/ arErgY1ARCy7jVZY8otkkGRBrflD6Td5D54nRPSaSBIbGHHslzlW1JWh+JbcZwSnhlYm9Ih2nUHq BlYryjoz/sP96lvy7GFss7cVpuVgS0uiQoFqIVuHv1jAQCX1NUW18FCljWcgz5j8BIr1S6Pj2WCL ki4SWrf/IczZWyJv5qNbpnmfyEEPDMIxp1rXJ5XJZOBL6RBiPM116HTEQWd7riZvvfVzQgsjUA0U bGUWTTpZPHeg4gKxwNmNHSJJJMTcOkcU7PwDLDWT8Waw1LWJkEYB/6GmS907krB5QEzYXTDTjvFx Oe0Mnrndq3BSreJRUuhJsDhOnfMHmRUWfgaoZF+wdSi7EEj4A/Si/mW1TMPKjyjBohFIm0LfOHhj MYqagylREkyOzdBlxglTjDmN0e/Nj34tZ1xXil0WTl8hSgffTroh2s1PKSgYAdcvYZ2R3LOtplQh QR3oy9inrAGzDy/HvFEUHBpsNYsnMZ+sO0bf5HgX3N+Ls8p7ZTS/BVhXjoLgh+jlEiG4M3Tx1BcV 7umjTrst3q05XVMsYpCTqJ4hjLnla1BtCWjK8ujc8nbMKXL2op20Ccj4iJ9cK7JsHYSr9aIJciGQ qU6VLDWIOde7cU8a/6b8eA/BSko0Bhp0Frz2HlHkTgXPULrUa+rdz5BNun49vwq7vFPcS4AEgt7I c7fZtEcGSCrmrr3Dbo05v35vLwiMQuINCnvJBBr/RMbyBgq/p6duD0yxkdc0e4WyGjUjP8/u3ofN WKEs/DPrmsdgc1TF/sDeMbDFAymU9kkTVyM1u9kV7+0oJWheKEUn2+374QSaVzD2b8Dcbv+F/yS/ qjUJ83R0DiO7ZlwD/Vn6A+BaWn7+7yu+dKEDtUO1hx4StTCFwuDANdvKmpDe7ctl8lnp8QoRr4+O Rup6ZmRJpOY5NSv9gyFYBCyz/Rjgohi65fazuLe1REucK+Be4AtY2JpGPGCy+KzfLhZ9W5OBvtR4 cyLntXw/tO7zFeyVp5Fn4fyl+OpkXrSA5BUScun4++l1NLcmC6dpZSWp5J4HMtnd8MoQC5abczQL fESEfw4IDh/zquuLaJv/ZhIauRPTWQnm78yGNk7BzdrbN60QPTjU1c6SJ+Pj90ENN9OnkBFOVxMB zLmJ8B5xNXPjjLtICZZKCwPmavFLBhWdMa/pLtbuj3CasaKagIqe7D6nx928lUbloToNw1Eqiavt ZgbOlwcdaB9srQsQJwGyim4l2xI8ZjYL8UOAkgBi1vT6vf5vLA4NLQTt6QguskhUgkoWDJ2zmMAn 5Fa6q3yMDMfyQywL1GMp2aGpS5uUx67+kSXsy7pfFqzjGJmLvQnm8ZdYQaXovVQAfrJh7yOLSeTL 4WhWfs6zMDrlpMue7m3bmGF07+s8iJ2teOuCOIqt5MAG+kXCSVuhdQatGcS+jWdfFjmX4l7LWBUO jb0XSfdqCaOeHhOGR/6hKVoOuBkk9qriz7pbxTxH+3kC0wwtekFbFSlMwZKMJ4ONzGk0fayp0l8u Hngdjx/dbxLJqo+Xu0Gofu18XPIP0j1SlI7QAKdLI9eDN2Q6NIGf9wl4ePGJ8MJyMoUaP6YKQ/5E xt2vho4n8PTDpcW0ZPCIm3Hu7p7NpFp9amXPqyXBPc2ZQ7RIk4lYQFzX6285nPDod98kwUikTQFQ 89Melrujk4bfVAGZW2KrX+WhDsmbLRiS0k5qz3I/eA8v9j0Vk7cFyMX+4pvQZWNdAL3wukOefdeu ieE1rT7cSd7n/BuVop99honwUXqLrglmlddbC9asR6PztTb83CLslDvEMZe66hkaZ688yLk4YHr+ WswhLHd4PEYavjICn2fVkDESUdTuwJCJaSKpLiJO5gLy3vGMG02ZYL4xPK9e8FLZK0l4czZ1DwaD CbDg44Yn5uxen9Zx6aXMJtzZ4uWuyaJEHnBvsaNzq1rivruDhimI+myPvR5R/yn9DPa8Ql5nvS20 SuKEX3oj83IVJEn0HaVwYfD65r1Mx9oO+z43zbszZS3e6ZQ8KSWF90zF8YdJMKCiAEit523ckOsj xLAyt6pf9wMwU0TQOcBFGc6JGEESx7K5wj6ROuJ7hwIPIVhEX9AXqxGEqlkrSYjO06fdkHMGnlew H5GNiRgjHey352ixEsC9NLBYE8a3XeTTwAG426lM6M/LUTllc6LHBIgyaC99uAOpcQq6CvvqXx/v QyZLckVK6N5WRd5GL0y1jtQoggYbstnxYpUQFssV+hSq1TrnQPQ7jo9edy4rUxoXbmlXrG/48xa7 qQ/ukOGdtoFcVzZwMZbyfxEVYvsRQJNAyIj/dHml/gVzp5P+szrrCiPuEiis+v5RzmPovi4jLv7b QYuU2LXvyigzZWIiy+UFl91dbyGt6xS/pxLcw80wezVF65FLve4k9GD+N1cr7Q8cfwzgiwrff9g5 1ToC5KQ0/ElNvD8Pidg5Dyhl+1W5xCJ2BzTv0znDWb79ourNZN9vmGA9ir2gB6vn9Ae7pdapFg6K 3WHjTj8T1fBwvHlarzaNC+Jps1NQspl5V0InKWwSN6Ltt6ByIHw6Al4d3+26pfvL3zQnw24TxVJO eHtaoDZdswTlO/o1xXDAY5NP8NXHqKIfA5zRK5kBTbyKWQt2dzMPyeD7Zi+BlE5qWKaJ923f8dCC OXiPTFst/Zymrktisvnoh0o2GR7zmnRrBA3z0aWzwNw5oEB+h0VGrppjNwP/C2cuFE2rXlJGGUrA 0OSJ0+QQyn+hOdtKBbFeyJ/wYm9qDX3ZFjnV5HXHJhotdgSuSorhFc5OsOxcjEoiC6tLZ0MvGuIH /VCP+fVhZw7CQUXq4KugakqVznrgGin876iwyi9uuXaDuVrWt46C3qNWqa7v4ZYv5g/xX1+vDhYS 4NEaVg9fv/T4H668qdZwAABUIEMj6uIEaefWj5zJGcF5XFtyCNrLbbXPa3tDgOJaVsrISjl1RdJU TFnBbOlO1jqh+RJsM/Fq5Bmx9rujbPcIgtO0vwYgiiGSl0pB1+Wa0oBbdFJEyNasaWNA0Soar05a Wnh7jO6FxDENo/3rNQ5FDHe7bQxfbrkH39bMO0to5kT/z0r48oO7Z3OgsdXo0MThjKHcy4Rcs4dB uIfanqrWejA3p3Tbb/dGzuwCjDfOwuKoRcQ6P81v8IMpDy4Haby/Du5PC8+nUC/WQ3PlwzMr3vrg x5a2DAYApmjm4ZxXDQNjfjOyc9ttPGMlxN6ZGJs7+SCNg+b3c0zC0papKjUbrrXNw1VcGTZwRlgs eIXjC9XPgDrDNcK4EMsgef+UBC90/OhhjgeOszV1x8vOPOx8JEG80c1ICzeMCuVeI/Gju/oixz8Y vOXfjf49cgfrupABSuyy/blXxsQBhEp9xZJjGwLMB/rfNkk9Cnx5YdYMqiu3nWTgP5XWgd/R0Dew PdCeeK8iecr8356uU3+vapMTBjZqYoBFlxUq7ZtUokfXokkRMjKzXeTINjWKnayYRYhjjhAE6jtq yqHyA8F75MemyBNZyBeN4JKX//n4G0/m6qEMoE/EBZX7R5I4gdGXAqYlqrittzhnG8BQ5CQ9x9vz igvxgv7d/W96ELea5EALRssGZytDv7Sr+lJ7Cp2Z2a6abBt/S+LekQcY+X3UILT+zIqI9dGUgYCD D752rGsZTzGAD3cPIDHd7CGBnGMtmvDAP0gih5sQqHMuP5Q7le3a6KtN3v9ViwKtw05wPlFTZiTH St2TfLkXByx99wo0CLd1m39DRj6xnw9x5DBRpZgvFpjoxpW459s7l9qJ2/wVr/XdiSkVh4Njf4YI RUAMzo70xIx4b1M7TX1uPAIdxLN9j9xHvzOZcnNzhP4qfkf1BhaZNhjkLL8VJxqIP0zhMTX5O53h q1z2VyhlfPlKQ+58UUg3p7/9MQJx2VtFRU9wiG15Yn+kqjOQ4wGjW8B7NuV48ocX3le5UQanwRfo bb47w7794PcjHj7hIPVmI6nMio4EgiCnUCFAyY3QuQlsaXxFhE5xlZKlNt2OldqjPndp3i8Da0Uz HWrPlgxb6id96OIOzy6XJwNnYXcAvfE1JhlgfnEK697eXps2Ce2nHGjVpg/oDVew9S6oL+/tHqI8 YHDynhJZV2WdLIYKCRwp7uXo4RlrC/PEP5DOHjmjOf6+H+FYIos4lyj2lp7bjZ5BMhMqyEXqow9U MFhQGFzevhLsn+87KUysZJyMo0AsZg0pim6RO41uvqiPDZxkrgPb4/wOubYuCEfs1Mc0uDUMJHs2 ogOTaxcOWhFvXeImVvj2HXmV5VUFncbadZlNajZRshhIc4oTe9fy+9258ol+T43ZQBnlV2uZkOm9 L26xgMVvOYEcuKaBeBRpuuovkCLLUpMREqJle0ajSRKNAbPxgXfqvp4A0hVaET9n5mlANr/lRnok 7xJONzNi9kKtemHzvcAZ80WQ5bmOsk0ST9laHSxKpYyo7pbfd8w57nBdOYrcdIU/wOSZ17MFrKoK 8d4Y67nVHzNQSjcSHbUr89RA6efEUYLEoOCzTdu3nkWcodcRNPbE9Ds6f2Qs6YyQTOSWXwonPXmJ cWztEKuBI2rsuVBotPXLJVyE05EEjryPzf0DYpx/vLZYYsu31tE3jj+MhJZQMybucRLCFF4zd5ag 6H3UAIV5Ry6hNBgdyWgA1qI1FTbFsFMkz1Vak0Qfu/LQfptm4TEO8apahkxrsHsRvlpTz4oFl4n9 76pq4tbDLikTSRsLS8lJhBFO7hk5el4jIJ8OwQFl6ttm8FKJ1wVirDhWmW+KLQ/4LRhf9osOIa3s RPuWcz0SdIlqYZAiy8yZhmnRsiGMXHx0nYZWMHGMElCQuFAjLewTXy19f42M0mik2wGGm9BV50TN flAaEQDHmDIdOewynZ1cr1g8gZ2my+xx2Qw/6n5EYuEuZoEw6kwoWH/AhfQHgtbpiaQgmE5Nt0X3 EtRYYZwizRpdVhK87gB/Ov8DtPVuf8PmjFZxni4Zz7/qHEiL/R3ejqMTj4o6JmMkNKf7h9jF0IDI 3u9S6fY59yqV36ylRPVOBFzjdhBIdo4sSm/XhSO2fGAi1pmXjbGGpUtetrTwg+mr8WFnDLTT4gJH taJdUgaq0Y3kvWxuoMHyg4HVHn7+xUU9Ko3DVUQNGdPkDHsejKWMQoqIE5vCKi2edO0F6P4F7g/m DPpJ2tOAFQOX9CfvCSitI2yoPi4wE4Oahp6xMEKDcoFKorECGtbZ1ahn7NgXiPZV8QcSDNSiBIoh FsmI7fzJwTuXbVoQ2HaJ2DraeNt5C3osKYutr3sdmCr5BahuPZHaFqaBUSTdH/jcM+HXY3D6aBbB UKQ0yNNNe71FEjwZhqSpCq2NoRBBYV7WnKMRJIXkkbEdV1NWbGxOmGF77jv8AJIxiflW8q/S+PTl zqkrT6f6PDNShcvusPgVK864AcFFXq/TEi7puPUZhgRg6qztFUj8ls8ot1jnhVgkzpPYnyrDoyQk oTn0ST959JuQpu3tu4uUq+/e1JPyyZK4gP0Z0odlE/D/DQlA9r8fdJB7qXjq3IB5iXfYSNkZWMIJ iilgYTBvhR8y3AcX/RpYokBWr44jHRywgc33BQODRGCylp47/kZ5gQgzeWNSHDFr9pv1U5aIZ/Xq ZEvywGo1FbcUibHB06yCKaIuFZUu7ZoR+36XnM7/WsroccAm4yrPTp9KVD35DoMpcLLLQRmL4zAM aEKf1Nyf78lR54GfjCjpEFyieMyof1YNyb+Kj5IjX3OIDXeLqPlfsgL01yYKsShXGnaxrYGrqv03 h2aUPd4n34kCUYdUC5bZMVn9wzCAbZRHx/iN+A+Vx1SAkO0l78GoFEhg5WrvaqjAaXjJ/4n9BL/f 0AzHrapBe+wiLcqX9iB9fENp6xa8G46UJrg/marWI83Fw/sZ7SCMVVF9X/4beRv6edC2aDTxvtLi 6HeSqiBEHcpDCe45FpD1QM4g7YHRgU0nxriuNfAvJKGU+UvllqCy1VEq/Chv77k5M0Q+/jrsKcC+ NEMHneuYwV9J+pKaliwcKMzJoSQ3NZN8rTnFArvDBgVgKzM8sCE5+0LdclCqXpq88GDh72fAqWtJ ZQyQGltOuvGcguJ/BrqPx7GT7kJBHoYRNiV39QzFcUGVCLujLM1PtjO/dOA1oIGzrcxdTKKlSfiU U0dkJu4c5j/zWwaZnSnroXU3bjvQ84GYaBA3oMH9TIPC2UCX6pnA6H56q0adZ7eTcB2zeSDgLWmG HsunTtuxHUKPg8Wv0vj/n/prV18MITL/L0zFAeTPii8Cgzdn6zq1dn+v0yrBcytdnZctv8S7qMhz sU4QVHOB76Mokry8el/zCDn87ovp7CBuVViETq3++JtjR71L49k6DxNg/VwCxPQkop8ohmN9FTgw PvNTgKEleAr0LdX3Qs002cGVB1Ec+K5lq+ub9/pwCk6DiLqUUJ513bKi+XO1Fv89qGvddg/L3Dzk HE5t4KGgkI/N/JQSRMSWEkqUnsHX8Zbkuqu8Pd6pUhXGfanw6RIn3xijSy7ptH6qqINZ7ChcTP11 TiKtpgd3y5BoPMYIuDsdFpVTHq/yuF4Tgb9MlKnhnG5EVP31sEyu/PTXFuJUw3YYwC3oURBqcfLp GhZB+NOfWyFwxwdwcBNXpAh4cjgnVeA4PitX8BENH+cWbuv5wiDwX+xJ8pFLUIVIYK7mq4Lqrf24 OtZZ4wWchiw02sJVwP5tTw0Moa+tdky9Aqi2L6kb46rW1MX/YJavEdARmrjHZINx/tJcBjhK/BSj mFPZHvlpf1dSeWVYQJl7NtZYBj7T7CS0uUs1GZoFOhpve62AUx1aj05pr8BU6HvB/gaBrXOLKXGT kA9X1H4ghVSw0mhAnUNMh6JLDGWXtMc5mGcMwphBjoJpTd0loKCR7rzl8d0Ihnhjeyp5QWE3FOzn 10Dxz46nxnkO4A14RgAh9Ws3XtCWj6Az78MvszF8Xci9yOUAC+Ag4+bMNdMgiXC4vOIow3kHO5sq 8V7R5bs4XLdmuNDRdEa6HptHHcnTMgJWpgYyGTb92TIvUMNnLVqFnp+h/oHpGRWZAth5brug/qFx LNofZUPDb5unTS78QTxcLHuVyMzCH1w44fcEJG9XRssB7NYOnyWx4YZMiZFruxRQ97RGkc0GUJtE +7lQ81trj/Y3R1b+zy/K7dH4dQJk1Bum8D6LMuprK80XeOlpFSFcVTiv9p04cFvg0pbppwz0P/xN 4xzO40ZXrVKVzfj9e9kH57By+a9bnF5Xkm7wR04E5fhqmNwVyOH+Vq7JF4l2/PrGmeD/DtqJw7ma e2OjcZhgLk9/rkbwvHlvJuJhWtr2XAL3MFB01tG96hWQq0yVTdKjPWv9W8lo1e5AAnTyPRc7fGyx vvuv5R6xbMRUVVPmwUpdPsFB9hbFJTxVxPrjC5gF73tL6GwsLYkDpSiv0FcimWdKl9sjMfwWnP// 9TUazt8+avyIR3LcO6vq+DSobTB5BbNVwSp6QYLAwzLXmQuKuIKFKSaFuLaBdDufGvnHuLrb0/QY pwRoexI85Jt96WdXeXlInQggp+JGbCH99n7l0cOT2GclISKPQh4Nh/m3R7OOSV8XSI9lGqfqbyce dY9LevRBzFEoE1pbrd5ZkUcm9RPd/H1Ma9FSN9/hyrLbeVmtOIH+yxTrpqdt67u+QV9a3VetqmZx rVJFPtD4Hdx7PCNqr6BbmHO33J+D4diL4+fhX2uP1cDp/a1xbdSRHM56LbOBxRIPikx657nuyUXo o3Y3OajFFzEo2bTEmaR8mDef1hR2YfRBvRXKvPZSRhhHG4yuStHs7u1LPHZt0Y1ssCnqcdFgWREi SACwt5jDXDu4P/yZXqsAPohAw/yKB825/oM78I6A6wwciGAl0o4pgfI+QIch5WQmBfN5QUQYeFy3 WyiiOt52/ZLgo35mIUZUZGj64AqUBOqTD52LpCjtb9dbPrC3zjgvQR96PQjX4gHwHGdHhcohnDaB pr3SKvLzWmMstRWzmOBB85yyfbJ9oj6K90mXIJg7VUKDomfAWBLzoB2FmFqGeGEAolr+NphiwvDg ZkOP9S08XwhaNxMGEpdJz0YsyT3Ykwx6HBvuzytZRoNnuBzryXikpeZtnoDjv8WvLUl2lJmFztB/ rrkIHZ3PkjiBYzAJIEY05PRUCgQvTbkXyB5XKHT8MB7LyU1EAN+qQ9MGAaSegOaWGKbhbCxQnaoX Frc1RVSEfAASqRKXLux704YyBUc3d/qyLTzraN46jvX589aenRAfjaBD6d1otmDtZMsrz4/6eD3x 2wLJxkEVmvbXKY2LiC7qASE4He5+m4EVJSx/MZfceEFSGk3VTC2zoN87sj/xfKaZs/Z5xb+DW/Zu gUQbmjCdQfAAhd60MM30YDfPfCraXhSRG8/3U3cqMCdgEtpqDI7DXFzS4rfGdZoWvv0TtUPL8IRY 6LK/Q7r/KKuU5pxJ5y3Cjwah6ooJnWaCqG6zpPotXyrwxC0whp1TXRWMyo6vtJj7XT2AnNIyH+B1 60jS+F73fO9fDGcCtEzs5VrS962TdaZWhPJjvR42pJcQVPCw99ntdHpzSFW7LG7h8fhka0RlnNPa xUkTbF2qorWnGcWak4FNeXMUWz8vyVDuhZ7J4DkaR/hJ1MUME731DBEjZLJIXk+AIVOEjChGMUgg SyVi0VHmcZsiw1rHRjFF139twPRXle3Ii8pKBOQydT4KGEDA9cHSw+I06VW3GgnsomhUPpkk0LZv IxswFFy+4kUaQDy+tM4++YAjlxNXTSjzIe/yF+iaU8eea1mktN5OkQgFlaiIO5bGLjoBTcIjJJE/ ILLopXCnAMLJOhXX7aOllcwszTnKbv5ikPdVO7oB0Z3cI5AF3t64+ukXe9CIng5HuYTfbjb8oWlj N8psHV0IkQs82ZZDF5AP6YtnXn5xJWqg9/faupiYfnk1DQTurEbBt3crOK9F3q2+pYp66zlk8wuG IMPg22EXeTV7mWJUk0l5htAB6+9HQF/Thcn6xt98ftxDc2oqup5rKf6qo6vQOXLnd1z2kVgSsToL dCDviTed0cOL8PJmQ6x53BUWCq0Bp5QY6BbpgLaQ/DbGGXzSXFqPe9Mvdhgl0RIkb1+Pcydm11UD ctPJjA3/G/cog56wHzvKu6a9X0ujjhTsJ0o9LPHZ7sUgmTPJhElPsAkRKUePPKBf6qVkH1RKM5N1 1GQXdDhU3Dwwjugs50f/fr0/NZH0EqdAFSnkkP/dwLfaa/a00uV+MKaJN4K4hPkbcYteAtw37DbS pd72O4H9vkLhMJYPh+5kt+XOzNASj35Xb4rAQAOa/ubtn8rcrByZ2Qa1B/xYs0TH/SnbC7pndNvc f/aOOuHCEiQsZClriCOAWSN2LgG9byZnF20xLq0P2tc0YAZ3jy0H6ohY+hmKom0ESQvexW1ETQ2x P+XXTs08+SUWkgu3COdRYYWpLgJLovXJnd5L4kucr6/L+LfNzxXwDCeg3oB/IvHSybQuhuCWqtZv ynXM09ICKor8lfalmJWfI9xmKhAHhvFaiF9393j9dfps6NZLMJs81acoHvlSgF8I3V5qhCJTzI8z 6snN+/klV+6GDk8PF8JvAmtZubhVmqdOCLgvYukVH0AHDanxG9OHRngKpT3vcviaBYmyIUDXj+9W 3Drq0a9jfj+nhJn6xHsNyyncTSmr+QCZDh3eYmLQwhDUc+QXdaGqG8OEMxof/BgqMvWGsHiBM+zy 613s3t+bRJYScOMEUv1/5RP8K3ZOKy9RGlbBcdsiGrmnHCOfogjD7Hw3TWwKFRQxPsWeaS9v1bIM /2hEqiSYYFi7ximQSBiWpHOAnfUeVq3gF4iiB5vDRKpeUHfnzxuXeb6Sg4+XEafGM9QsEyo6odzE Z1fh+FXgh+14E0GDrELybJhK10WMAos++wa+XpxjlGWP29KDVoTHTEkWGd8rU6u7NyRcDxdiXC6I 8ptu0WmTv6WsfvxNe0I4ZSaxw1ItbXQ+aV6YNda0wsvJfOTEdvRJSPuYx4Wld7JKbceC+SrAgIo4 BZ6N4/7vG3s0xMpnsOUT4UDU+ocuPXemTnVFoieNMUMEKstlQabtM99GIaWTLVexbOyzjtIyo9rE 831j30XUbJxjB8qia0I+Nujz8jUeQ7zlyW0mmjb3WjJjzAXob/nMWsNzKxeS5wCooGR4/Il5wb7e HT/pZp91aXEjg0KEp9+urt9lTkPkFm/jBEFcvhY4/mTBe9Tw4QFg/hXDV8WgY13cDF7cOW8o02fS 0Ga7gDqazDwgJtqggFvzp6uBrUp7Tv5yaP/IZAAk1fhV+AQHvT6V/s3YCzpcw5ssjOxFFBzRi8I/ jfzSsgbdTwWDD3oCcSujXhXbrroSi5BKrdrq0E/ztZniDyQT6z/h7rUvSPx3iCjwAi8QVcpergoZ dqc/BKR0M1xaVwS2miTJTdPILqp1QLSXWeXxgBxUDNOx9cjGojGWInJ0qdyLnMNDa+T9kS/wLPZN /X0NHi2EFR46dHJ3U+rgsDYEQfIX26+/5NoNoi5Zfw+GWpFlw1GyfbFwOGYhTitpGiDYK5URaxX9 0na3q2gQjoz94x3Rq4jsbmQDs2lL2ixhn6U40KHBmXeV6zVnav6z+toImTlbqhjVSFv/QCB7k7/3 6GvdeNHJyvZFNvc93B484gfDwHT16Krbrg0H1SzAbMIaNtJjttKvwHxhOhACqQDZsbAIE/Y48MS2 69wOe+xJDFyRflQojxzGt+ID7bQwM2Z9sZvvx1JH2aadrle3nqllSjtDOfTSEsc2PjwF31Tkt+Pr KD6O1HyDl4OKonXJz9oHbXRpeqSrPeRwKi9rm1WzNqcj+V1joarRQ4lqHyToEOs6F3e8z7E+gWlU XPkZazpFcBkhK3ioNOCgo64YESL0VuQbFyjbtlE45K96rWY1Gjc8k24mKb6fMHNAQU81xVTEMuGg 6+AkhvYCYrNEXETa9qbIzF/9lRJEPbuTz/eAJsTjYUVaey48NX3Bobw5ZYfbElowjUmYqLOVDfIb RjAr1nMImflvot7UVpuGckqzXOf/uc3IoeHYrbLIKKpDG8gsRxQlkkxvonjEb07OiIKORxjgK9K/ x8SM6mzvIQjE5Y0wbv7M90kdDT4081vtmgmHZT3rf1Vbs4AbV0Xr2SjHoBUs6jF36e7zlG3OEsh3 52XHh6Yynx0b8sAbwhK9LtwZJ8RErozYzFiXpRVSXdzCFf2B8kanf55RIjX5fKnP3tRMqtRR2v84 68gKMyiCUN5Fj3uddBSILlJH8HJzrRVsfCFex2BqwSin1ZNeWkZGQFxn0CEadUu55ctpD1YyZYpI 0gZCqcrTWndgohUQoPJjfjYOvjphMlRwSbalNbd/lAac8vh5FtNCp87a0+UgmeBEazzG9PN+e03d b+BerPpmwqG0KA7A7HN08R4l/6orby1n8TYncmsx+z1heuogua1XAOXS+DPmmHru5OR7FKXIcDbm +0qHtEAvF+X3+R3MnBIzYYjPTvKXux9KzKmxv6a4SrZ3WI23sy9ycnQ2yf5fSfj7H8yEyHMHh0jM xhq+JEI7FEky2/qUdMgS8A4hJGku/4Rpf5mNqZqCRTsaGvezd+qWfdhhhZWH0G6sqiIjzz7RVJx3 l8rlF3NHVbfvXBMacDMzT0dLNZKsoSyLOfLrlvnpk1pOqPIzxtEyUHC5wvlQOj549smi4JwP0vyw uofmPzfB0wMO52hYawnVJnB2vdP9L08Y9Lhbr+Ckkpr50i7ar/34S0XU8Q62mCLXpTx2ELHLzuoD 7lSanfdbrvn239wK5eacaSxoleJz/9fZyM5jqt5LHZIaCGuUM1Nx5aiH5+ALe0qcDwX8sTatvOqI 9sPEatGMcSwlRq1rmClVA2LIsbrwH4T4UtB1iO+X6L4vxAT4sFl5wpjDutzGrB0cC2cbY8iN7ujC AmiQSP5quDTy7BsDY5HhR5oqH/mPd+7cpD+PmDPEN88FSQtL8F2BdhNy4qbswpo5W+7ApjVUsGjU OwOoSbGix5qieJDd9KGeKbG9ml7A78piqPjAQwNVr/l0wOp9hHSIW4jOCbGHUQpgFHW9ePL1/O5a GxRXmV2qwjYFXJppbqAXzEGTuh7/qXSq3Z65Zker3zc3vyaW4+Rmh+R8PRPKYLouRWjngSYsyfIb jzDVUd1LiNuwRNJi09L5vQq7m20tiMWpnQGoH4RjylHDUoSuwP4jm7aeJGaBV3ednDuYLveYQ1Tk DHhT1smcRunY4zzJoBcSdLy5FM3zmv6pdlNiFMT+tfm3GePgZvckJlKwx3WGEexU2YqaR9BIviMA N5MMp8C51avf16KzV9lGd8P7mp/pVifvVKP/o/UvZun++Bqw1g5z9zyNG4XRukasuf+2bYm804Tj LoyibD55M28h5zUAJ69j++p4GlSgL1Aj5zrywjEtry8ql4FS7fstpdfxNPcyXB8wY29aJY5WHyil tHCUtYsBD1dmFSSjRQHeDLG85P+2Zfagvu991M5PXujqPISouh3VnJmE6kijpCm7TshsEQLJ/DMo M5I4Ph/X4XjAO59TMgdDySPGqjWrJ7PesW2cpuxyoQx5tUY24gzHQgVXDVfPQ/PnWFX8V0cfiwJr GTSymL/JhhXyjfhmwawt5zKfOy2/tlRQgH/IKx3qhQ6atLu5QdNopG444/WTvdv2vfyCEkuFNalU G55LSWwtcMHdokX13ZFLD49N11zmI8yy4m0Zohcl4GrrnotIJT2Q6DXp8nb8rgvbV2YBKIQLBbQJ JJyDcS2YZOIogi2/XoF3VIL+uRYs6AfUU0LpbcqefhwtVJRR2q6TsEp/DCeMf8ZJSvH5bkDFB7K1 KT76v85MeoE+IdKsyaIPcqB4hb7SNxu0Hj8NyoHMx8vklaIh2ee98w9h/kMGZDNLOxVqKFFcVP8f xrd6eU8ssosFF41LV4niGQs6Tfu7E1zRKqTqKst34llUab5lASQhV0XVDYN7GVoCw/nel5pir43L qaStIC0mbPIGu1aVSJkT2vG9EmhdJQytFwQHezJkgNn7ZhdpKsrEA4iV+DN+CehTe279MAAsQCwB ctBFWzZAJ/SnhyaQDdSeXdqLC2653sljV1V8Fgw46cpUsV3ziWoFg3oQj+O3WNAaqdhkj4yj6+7i 9zspcMEluJW0muasYt703wnKhb4QChJJRhmGw5y9dsnmivlDd4YN41+SjGu7m0XvpvgVCGuvco3H 7RtT0x8OVxyzwVyHDS6J8r8bIEMk+3nwt48Mz5hrljbh7YE9a4HLkkRZop/xc4dbAVWNzPIw0cZS nAqK9KbYaoSwTWEjuhu/AeKqJo0PXlkROatMboBdTzdo9tjZshSVgerVnWIvi/y6t2FzpjPT1C5+ a9GK9vqDu617aGW8LCQSJNvofs3vFoLnB6ZbCCXg3t7AIfuzJdvtJ+oJnwGJW6ipVpcnNPXmNuQh nhtFzAeWQEMXs+49mWdYvNgp5Bh7Ub6wZ1RfzQVqgVW/yiPYx/Rj2QrcPBxNRIMItYnRzDxgp03g gMaciqoQnwptyxikNX1ED5Dyuj9ySYPhDXkq1S1Udrfbgu6dZQx0XbXtw92vpwWCWIaqze/ihV3C URNM5UObFJ6dUgmLWs6JtJ1xggQIcgp+VCC/SkdJI1ckyQ9YRBYrfsdpSwKtr9GSPnbVA9r5Jdt1 2wXruX39K05cuxTUUSF1WUzxsYQnN2un1bPKYalH32rNVS4hIDJnt1dIQrYTGYlnl6tsqi2i810H e98kRAYBSs8weHQztTZmlWYe8O767hkTsROvOlzSfoDlb3SdUSEUS/mtwvEOirV8SzDJl0CZaWo7 T6eQHfLYkgOWjeRHfds+MMXrnZayOuj7z2ZHtVm/wgkCP8wCQKq7YjhhCIhzBrcNn6upwa83z5mO G9UvapvvuSWmYS+XzaurSY5gn7Zt0ae1E093I3V/8tIK8rvVKvXNLKDgmrD2NKPjYpPhNbBjSXZQ c+bhLFWJ7BZYdVhy2sCZDHkxRhBSmd1Ir28ez0RpEesap+VLW3FwWmCm7fww85nqlzapZXTjfRcb IVJFiDwP42FO9wl1mhTqBIgHiMxHKbdlKkNb/o2VqKBn0GrNvPoyusLLGZ7yKnf6C8N9XjUzn1iU bLOlryfa8Q/dWKnY4o5fixUyjQAxL5+mcoGurm90jl5mVTd5892jUTs3jiqZWT1fZXD5w6f2Fc5p Y76P8P+ha5efx9NfA1hKanhxWmPXX0iomWbGcY+3L3bNq0RAQlHd0CCi9tVvrr3Y/I9W7676HsxN qtX/PeACkCS70cV5SBUBv8BffL1VHI5PHBRur6plQM2L6DkxhftsgJhZGnH/Yxv9IqOmhAOlzoYp OXMbhvnCRFSW9q538qFBnMQDKzJa8lKeJX7wrGXMIeFU9bzRyiH4xj+xT0JV+LWsr06JFIozF+Aj Cp9iQAl+Kl7r5EziYFkxCzUEATTQmFH5nkBBwIhtvPGvEIDLWOMCg9u/OrYYCUH2vDnK91RKgaR7 j6DTodezAXlR/IXyWHd5d+yAV30s6W3NT/S5Ist3ea1KBT52um5rzc+Kv/OhzJcEMaVCQcxfQSbO kt0Tfn+hZc0ER5dx0zEnd564hI6pwIZKnrhG2GKebI/x7jWyxuVn9jCkeAOv9jQSbJgXGBvM6HdJ RUpNhgbU1C07WjQcV1L8eWtPW1+LRswgxrxEwzC4Enfg3ZSjhU2p3UW68k8lfIoPYF7ah4A4+7Ha DlZJLlYn3jITPFDVtmkSLkZen5HvS+Oc4Bwo2WDCdHRLCUeyIZKMmoFpqoCpbz7xJSLhl2ZB1lIA Paf/8be3eKhRqQDx1o1Wlxf32DVM3BJPFVVOPvJCL8J7g4IzY1rOkpVLSPcWpAuMM0PuvivAmRE7 Jv4E4agrlK1XVjzXwtNf2jmGos9qSgBIw5UHYPCHnQ9gnHpYQ1tWF6zjIEws++k+dpI7ToXAZny4 /SGPCMr65DC6Y1RAk3Bt2V24f/izH8BA7o+6EhxOKcfLNU1RZ9sDFlklOGtnd5uA7QavIKss0/o2 dEOTK9rUd1Z1fluAkkYE+M6MK/QCnnsEN+QmYK6aJg6HegUjsjn8ji4WdoM2i6zO4q/c4BeT0q6j tJcfWgtAQL+aK24Ti5lscTjxq666/LMZN0bCa3KmhIUk+VkBGFEFyulB9mx5BnDMvY7+U0EdhB7r pEl6xtmuoGjQEnGaD8bg9QOPjUUQi4ZFX9YxpFPiJqYvc7cbvRtvRibcArIvHro7role2B0ziURR bPrgFdJ7bGAwQPNxIyMWX+o7fz3Nq55SlRR1TunINSA/QM8annZ3+zKFkDoXG6ENCVrE6e2XHzCr rAv1P9peawnPUnY4qMdtV4VJnMQ6x9Swy2iUNkbuX8p+FCqZ4NtN+sND14D0PQQZbt4QJ00zhTsD Wt/N9Twmux/WyjUhZovB7Ofw/9cHkCVPsh5zMuBMDvfPrwEm1gkcHqPWHS4WmGfifyaFQzQx8usi uwcIiZviaA4xInPylEFp6kHx2W0ZoY8+nx0PmFy4EgVnnm1GdGPP0CZ0AMC0KY0CjF+fop1kOYN2 FTYYUhcZ/TJaz3SGsYHW6AsBKx7C7qNiMJbF4GfUpnwCQnrYvaU98eMb4V+Yv95qsX3AEGpIR/tB IoqlN7/Bw3QzqEPQGczGcJgqlmMGbQPUx4Zoqamhl/f2fT7+VWLy019/ByU0om0UbfPYaO7ijuaq 3uBKzvDVs4EPzijuICWT8Xdc4cSXsWr0kqVQt+j8lfuIy4z5sgtgQ4vRPJ3w9sdBwafV0PyY+mK8 KXm+Vh81Y/ucG2Ri9gmE0Hqul2Yv7Tncp6cZuSRv30eXfSNZBm3UkXip4L4imbesNhHzyTRJahD+ 0MOAXLNSCp7gh6TpXUGFtDizp2slLF5Ewx1RmXk2ejWBPUOrCdbfEbRyafEM/7RRqISrlBQEaCdy Noi+VPPgXHrL8LDDbXMLOjDQgVomoGTdZiW8DCqF51jQRU8rHcxWPUbui8pqoHLTPJHcC/SUAbnJ lrCr8s3UfHFZmb2vqQgTESeR4If5nw+TGSVYnEfaepTPk674kSzRAGhrN16WDXMpwJmwZhZHHaam NKdVXJT/HyqqMflvmBStRR/segFj8n62xEbQRHLYotqTL97p+v75Ivqdej+avKRhVkL5SBzqHMSo R8HiUZAsQhNEQGzbpiEhwJQimENewiIR6Y4oRUj2S5e3+mcfgqUkeUHU4HwRQFDCdl/Ena4tyxPy aO7CmWym6yp+pDe3F9y5fjQ+eJ9gC/G5cTDP10dpeUj5IRm2aMdcMDm2/eHUI4ZqLFHmzL9vDucN cNFdshaASmhvM97XT8f7+AwAWUnpyvvCNrIEYbSjiG+sQb0prYzAovGzgECxp9lzJb+1QS6C1n+C lZXDl2EsTGy4NJ82eSLpxuFd8Cjj/apszhxvK/W90T7XZQfqTpo/atGVwQyQBjwbqJDLYdHfPQ3z SDIcz1Bhx1ROoQuKWmdBJYyINzusKnLrkkhfWT5oQrvLxUpmm+ztF5fvv3XBGk2z/MdukJbHWWbj zNfZqO1eNnLUpqYEae+zx7Tw1nCpXdKGvkBq+267qzKcXv+0W+Ld3AV2lYBuSPLZb3y7Mz24xOF7 rnL2DKuioibiV5eh6KmL4mGEbdWunU37rLL008N16nr/c+dXCyJjWJXG10iAdQb7T2I+lZ8BLqas IyvWeyo22qceJ5UrzDyxD/3HRH7JNaMlE4BRShSmpq4HZZhuRIkjlsw/YpDWldpEWhN3pTD3OUGd X0qDR7FZUQbIvugDPrrO3UcEvjy/03ZU/lRhM4oHmthLOxQPR1ewmI5TSDaHlA5NGzfgeAAysd9N Pqi4VZG7iD57fEhqAdFhciZ/NuyFpCgJm+I0X48qjKdnQa6Uv3VWN0GdI+4anODB/2XFDR3zWWcf y1HUB/1bI7mnezdgmdGqPDh1NDVfBjvgMkQ3YkOdLXMRYjfl+dSr/ViBN9nSbAeyTQucoj4K7D58 SNrJpMfO5i61HTQ1FmaaWJSbtPmO4qKzDA/E5mzHD3HiO7Znf76oPbRrG0f6nSklZR+wHTAGHgds Dj9nSwbUA7pRLFQljpsEdxvNXJa1fpfCntGrx5ifz0h1fxuo90dJ5Q+QEmPJefYN+V/vQhI5Gii3 tFlE2uSCUumgBRnubh6JlP9FNGJk4DGXgP67QCaSw5c+lTR0XcV0MW95qtr5YRdUWcg9dsOHu1QP SvtvZN4tJEe+QkbpjgcJ7ywltuSqlQWYWEiiooFeF1C2l45yEET9NIotjK8Hiw6//FeClZGS61MK CmSbmkF9gQaeiT/z5zDf0aKjo74u3EqzdLXv2w45rjEGCLihY1oanzupeduWRmuMxPkx9i1I7uyO hhvqhWvIzyiCzQZGt4jdEmWfp+wFmz0bXl6y9KUiyhnyNi/nZTDD7VLgZ0RrW9oULTpTwya374L3 VfRmNitZfx+A+RB6jAb9r9QKAwPcsdkMb5xIkk1WS78p0/SxU5u3r6iBu9L4S51rl7E5N5xE3Xhl yUnub/N1OokUv9Piz4HTn7WtdqgJlB4POkdqGwkHutzYIZb+rrgGYz4xDYDB1gvfEdtksfKciwbv el3ji+sQ6fvyMOVSXRPHIb/5tAfMINQgz/LRijJ7AqlCqW+RMXeNTpkPAzeLWpxPiNy9aOzCqr9r xq31erHzjPC1ZvQIi3f8SNfzVEUCUz9/ZaLt53BlStE3lkcA0K1K2eDWHUGokqG7oH5NUW8HbbWA Dxst93Cr9IRm24Rd4fMzqiePMmElQvad3/AzHDuUcP/8aq6MVuAkVmT/kkX820FGoEFDvAjokGtH shoOrVPZ6FlFPrT45oQPI4WnYod2J+ERJ8QFKVP9p4jojeZq8Zim1QrVyDBZRpf3gdKQn8+rK5qz D/N8LMZbudI6ksF3NC4BgqLmlcYtisfeKpfFvvXLozrx2XAxRIXRjBqq8bJAlu1o36/SSXoOom/3 4+2W/q55WV1VBTJOHCkucakg3qVPbgbF6fXGTjwl07Du8LAC8bTlBPF0EL/EJ48OgE4dn0ijv0c2 CcS2cOAMRtnaDoqCt6xlhAM1ENsaYsHMN+0haHGkAqYIpeSWBOOTuAy2UEAltL/WV6tLNuWfIYWc +kSoLoToFiqJHdgZrlb5QGDAZ1oC3TzeO9M5ShNFU9LJ9k3C6jbCabEl9BuEnquDVOpw03seTHFf ukW3aTa8l851e32SxReunvgoeanRzXxXmcrDWeQx1YTYav5kzWhg260pvYUPtywYcsldNdSXcfrh ush87iK2tQUQMT4SHYXoiklWrHviJKCujTYElsbcB2kiyFZt+4cp8eqIJ2SeSUO9dwgI70kC+Ch/ FlsM+7xUNePCW40raVKbkdPGXDIWhU3/q7qSf1Hl+z2hjbNSsKe99e7CL9it1DeYDtXq/nkal3av LveK8127G0AHz8Q+A08EsD5mo8xcn/9jkAQEiHl2vdnUVAys6TDX84aQCr/k7CUkHo1xBGL3oNIZ Rn6Haj/4U7Wi5y9xWNNDafpIX73ZfaKcHl6FqSdGyVtENfp2ny5BPe5FW1JTQXsLhUAZVl2J9vQZ n7gD5Ed8rn/rv/ncVxsr6o5LpKqn9DndDk+wffK66gPAw9+Ci6PzSrWr/Cr+1n0ZWD9aap5kShGn sDycz69G5QNwFy9Y+Ei64csHTcA+ZpXufib0NPel5MFOU+9utlkR+gmK5N21i3JH1syEPVJ4QHVk VEfw2mgWVXoUdPIIMV71ekN9liN7hgMQHLy4yzPePE9hpQNrxSNTZ47ZzGOaybpOnesIRGZ4kpRm lppoSJyU+YafkONKG/qUtt2NNdOB62Afrsg6Zf0ZNdvJumMueYXOax+81IK9B0ApTgvWd1opEAay HdMIj5vn3Nbn/ifw0GD8cLFS2w36bl5jAOYEvIkd/zIzgZCM3jqgf7B0AXLw8BLHzdhQV8c8kwtT Pb8c9oTLykY5p/90E3QfZ/My/34wDSCt0n8SxnvoGvCUb9qSmR5bMu+iUbuYQzPYSFlzwCqir0OI lpul/YE0ZfLc/HZ2gUaSZOIbP0fjHsi8ZmxQzBBLu3AXCccxhs7Oy/BYguXs/Bh3iJadVTNLpwMF Z/C17XvWwjFRDmtjPUmG14RpzWDXeqip/eb6vsXemfMwZnCQcAy2yLbh/El3cWeDqX5mqM3T2qte /VtGAL8Q1LwgfyE6aQBsKtdkifYAmrIGAuqmYlo6Vr4lyM2F94xQ2lANeziKG/87wU9Un22RAhzl 88aoEYHlxcRHKnDAZOJIKS9rxCQ6rWU1bHQGZWsEWcth2bhUAA4sITsz9aHvZGwn1B5thrIJiL4O oEsMPn1UdAc4SaJBHv+3D+y8XfHriHINnzKaKgkO2Ok7zNmm2KQZYuN7nqv8ufmqJ9c1DBWkKQFi hulXjycxfqJNWXxAwizxlj3zzakRd3v4rMqj+do4cy6QHhpFfJvk/lqiIFSsf1/0KNfGHZUpxcGq ErFO560vpQqfAI9lTI028+lDsB1lvr8/AzE9FuY74P3NdXzmcZDrfGd65mCXw/blPvZx04cI3F2E y/jkOZybSHKJ93O0SMkqGRgoa7L8Tan5MrJh2y8EIHi7bPP6mfDLwfKrZweZn2HWaptaRj8jVHzY 2XT/5wa2+uxXbaIdUglyxa1WYy2nBwCgjNS/s6pHTvixIGwdj1d9ocRyY+/bL3QDrHBiHXAVis6M AdKnWRj352HH30m46JeKBjJ2mhqmhnsHnv1O6xYqcuQzh60Vy42fnlYiOp3x9fwqvOcDI1fZNQJt yhV0iTwE+dgfy9VtVa8TMwGhHWDpF/PRmgl42JzZGlCGnkTHpi7D0CJbc8siWZqe6r3ci3QCJ7BN 4qEfdJaf+zUzAx4IQHSj/FXCEBH+FQJrFGQCcaUdwCAHiTAAgmOjvpc4gDStBiifz0hTzBU4XSrB sXjhVAtttpn78l01VihiD4va7pSA4+Jl9GfKHwaFeBwWIkYzp2lXBCTI5fyeOJLu0NUh50m2dXKE vLr3O2KQeqOtpPHISXkl9NjrWbVgv/QN5yRnmWU0AX7jPESlp7uCWxRWujA1UBv2AMF6lBIxoCFv cnQW/nmIwVF5nS1oTouqVKTfkPMraSYTopByfwxr/NwrkjYijMGzBj9M17Wb+QgOIWzvJ/ENb1b8 du90hrg4349BB6cbuB81bmUoHTJnTkXpITUL1PfpewH4tHZJJ5+PjO61r5F7LLfqLKFLk6B427Ce Xm1mTEiX+wCXphhe6GcjVq6VHvXDImIruv19GL8wjqKbTNQEGYe1P91nmx6I8SMGpcDlUXeCkSXY 6ehxB+Ivy3ECbbk6UUQ/Is2S5efNPsIF2YV5F5Et0J/6HKrTB9g84EhT9Zom6/HLRFCJqpPPlxoI iUF9A16XsONHW4oJbD0kF7ojS+WQ02y4YHQlTzNh3r+X4AH6wr9sXBSAIyGgrXU3xAM9pYy55Fpy 78bW1QJjOeG2Prt7hmsy8v3OZUapwhHYHM9ZxHeSDK7QkN19xjKXyOMCu2BiRt/QS6qn5RfSVLPK kBdqYy+9wzHRkoO5fNRLil3GaM66bDyNCsnlPQR/eLEVWYt5cL6be3kHk/Vr4spuW3AFBHhQ1rVO AN0Z48R58Dh4+dqy1HFZoMVgD7HFRY0GGomRRVfTK9GrGr1BjXTm3Pvoxvmf5lDAgn324i1XNNgY RNJyIhBXGx4B43W/xAPhzBtii3d5YtD1V7Cl0rQNzr8XpPBXL5uOIzOMJAYVWcImvhCXjW+bZymw OukpxBfNDORUJpKjFE+WdRK3cLzu26yIf+V6eAj/ow0o9A9PgrTIZOHMPkJqYwMMtqFO2B/94gJ/ OBqPPHanml9BiLokJzTVzO1uK+SBs0bYAEyVefuSQ7uwkp1BzjC2vSX/LDY1SQukc/K++J4L5emT Zxq06/TSiQxjTnqKWCaTE0tnApQs3K5T70sAHzStf7j+BwPYIua2FJqZ/2572nY8xlVWR8CH71Y/ y5CF8MAc1uvdjagjrDRHBnjqwUCsuvS2xi3ZfvwohgnMkzlptukI3yfvQhfkD+Vv8UU+WS12hBKE OfIfljl9WujuIhhN4nVgkGxaWc+VyWQCWqkc/mYHuuPMEXJt6zjAGLlBQeSaqlzjv9uFiJfUzyht BPIWQAYfWNAXjjFmBm8rT30p01rhfxELnUZtrQhwxpkxW2jevmqEGPGLlO474jew46UU+2qApXf6 7yFlaTZSDR9cQ627pZkSm3DZhEzDPdu0cUNbvWaykceIuQkYw1JGRZbcokPY76OGjJBPwgJPvAXv OIPY71FvmWAb64eeFG7VkNaXaWk09ldxGLG8jw9lwZSOEcR5GQjjqJFxajPzq6Ballq66t5D73Jw +iPRK07sx3T2HvK1iE7lLCzf4UaRkRyuusNZYaY6LGSZqS7EdWBerFFxucbGb1ri+QV1J+fQVaHu s6i5Ti3xMKPUVuBYakzAkqCmZVs+YHNAAk7oA14jOHrgiD8/DJzVWLyYaLBYHPvQUDf+xZYL4Z0u Om6yYBOKn0aE6PRThxU0XgZuPmjdBhX/y586zGy8DZhnuLbAXXTdgKBmuX3ux8P7YQZW8wlXWVpK 5kz32L8az4VizWsFQY2u+itttqieIomOKAH2daiqqzWd8bY6luVwmtOk6nxBS2f+Ylq5xON9GL+x 9DMIZPm3J/LpSKGDdq6xR8iEY8xRL2twKKwki1J29WB4oRKVGqGdV+aYJyzhcatmQo+XJPX/CxWe RkFzbDKwxdawgvBAIeQlCSDC5a1gGSapUSU8GMxm4ogP9+SH7wMAbynhyxN+Z2U4id3h1rWscVpJ bfJ8u91WNGrxxU7TSSu4tBetZiivLGh0xG0niG6ivkeYmIyvODoQynqn0qFGG2Z7JuU/taMJfM76 jRwFgYjuANg7waTj7Gw1I94tMZBaHW6+KSpvBEi6TIguVR0AoSm2zrMIYKE+ghl/loBHSe/XAmrb FM+QtR515yhu6QuBDtct6owTxKszG5o6ZjDmoV39NX+DkfJTIH0SZ3ST5u5iiNQBzaA65p2XIBKp fLZ5PWkpeKUIHaThoV+EJCwjD4z6PtBaPGLd+co2VqkKcAkxu+bjdjtUK/9gQ7royjKYuUIjuAtP uXV+wzmCmcowyf9UR4TvxCmmkugwvkqcN54Diogm5ex9mRlK59o9TYqsNdYco5djbgTu11LP7KzT 4QX3KZ1KkG+BrQAAAm0fT1S9PaJsggLYiSDAACB2PX74EnbV421jSkdFgt7kv4xiuYVY/Rg2McYF wNpCKPX1CxvZdZVWicl04jjvOASWq05rZi1P6IDGU+WSVIpfJX8tAeaHqn5GAIG+2LfrvmlaUCWp JxV5+PEmelEghv33j6RMUuSnwTAKgY+iLukUHOG5enyWGdWmwgHUkNAc4mCuH8HFzgAIqGTyFXpg +9sTTeMD1DjJkbSymlyp1hZ3yg0/3tqwDz3EL6oK2Cwxb9seOLJ1kdAQGZxe00jzGpRAzF8zQyIA ixrfRvNWAt+iZayNykUWZygTqXiFFak+5TePWeRj7kc8CjGO+J7PxaJtXxzpKWSljtKLsQPreRQP NKRF/nelG906qMhGSAws29zNiDa/CCZ0BjH9qlebnH3TU1sKF4RskebIVZtxR7pqBvKYg1IDIMyY U4NEB5ydHzUuOs3lRbze39+Qn9IkkmbftbfSYQInhjQksedDxjJhPJI9uhwn/c//HetpYBmYzoFy 6uLg2KvYbWVrcBC9seuF6X1EnVEd0ZZi6nst0uXYD7j0C5AgV5ObVfoVCIhiM5GYkYC37NnU9xEg YQKEUVXQJh7rOUG1wpJcuFzi27aqNPJtTz8I0ivRA7Q6KR5gAVUNkuPFOZukK+OHcVLQDSjIlSgU ARDTLDxr5inlNASKDv7qz9eRvJ92MDwh/6T0KiXU59NR3oZ4yDtt+rveNtXsw35dLCDDXoGYpBnX SKbxWoAY192C/h8rqZBD7oRhNFr8SL1DAZxf08OYPvy+fyyfPXrT951YKkSsEZ53etq0JSc/eldJ vH/5WlnepygRdVeo9wAXoyAkj01KTfIueWTxeUJefZhuby0wQkqB1rhC9KqwHWQ1jA8mYEpFqCF3 tZcJDU1SfO9DPVCIupbbAn1mB6ZmBUzMuPCmPDNYeZo0GE7VXfkHdS4+Qyu71JeBEw64i1FscxyJ ydYxNHNbfrEGPjcMlPfkXGuvLVLXbgN5fwGg0T6ry8dfaPz0RN311BttxSVUdZm2Z6vwVL4biGZK xiAoePl3LMsbrK4TMm7K5sBQ3LHsG9S0YjaumQ3mm4DgOLBiAMSey0xO6hOfEBMjlDKb2BXp4iZD ybNWDnCMKwNnNG6R7I2+CvKQaE7h5qhDe54ZnNV9RO3jA4zR39vRENIiItEBkeVZNQNBkeHk2GZG OE7Q3/3jZlFTAOpKdCydcSUOpV8h9LxiVgJBHy/FrqL7qjKy1xAXvENoCo6T8ptXM+/EE/rn6DUg Jzxt+VsqeTZ2KD3wU6kFMYC/Y/sbUPMpPpJEEI5DREY+XiGBRevELem0wF3pU9x9as8fDuzySoIK W8+rmOyCzSajBiiCX3M/W+Ye9qz5nR9cNiBLr5UruQXZWM8SsVmjJ7ZSzN2PKRrtl/9EU59zm5Dq 7V8MaJ9r55t/YdgsCd0rm3bDOkxhjyY00Q5ziKrk9bBb31iq2bEJTHAV510CyuDnP5BwhhvUBbh1 oJpONcHKxly9PYAXUVIyTJcd+wB+qs+elS+Lu4UHX/oxDq+z+V/Y8y6IPWrUGCzcSzUuarzlkMJY ZSJRsrFecoKRsfKW8wXFHHPd0IrzJ08iJPWhw3HZC3y5DOoCs14qoqyJE+P//j7nQpqUN2G+J0EI nYd6wOTdt+TsWS488VNRiN0h+ruqX4OzYAkvDvLlanQgehcWRNH1UuRUbYl+Div7P2FmZmBjTP0F XIFJf7FFF/Pa/A57YPCnJVIydLx//A6bJye9WrrejaVQCqw9WTRHYyOY51W2R5Xl55OrFAOAcAqk zWHI9IgiN/LSuN5gZTLbAkiJXSfPnAIekcWZtB+3f+xDWbXAfME5nEtSKWlJAEGxVJGvjxM8ixVe Rpdutu+9iwbhs7PFgSpiXLTJjYmUnWyTETlTmyGuU3vcADwpujcsDPzgDDnBR4+sgo99lyM/HZa0 HgdKHZMBnq/l9OqHAf0/olhAbFIgA3cjsSu/KGgk0L7hofFX+Jyvl3rjyCWPxOXaYOEr5I+LN1F3 c4+ceak2vzB8B6gfOwtcs6WV9EdGf18kU/vZBI07Vw0e6dUc9evNcrIB9xAm7nWwSu727XK/QchT TfUytcesb52sCw1CHAtSgdYGzp73yKGF2DcE8Qz/CyAZU+9mDQsEtiytAjAnJQLwVB0JlLVXYZIw kjbVzrqARHX0FuEdSgyyTKfD1oxO6jOyEwYv9pI1vA8v8UBAvfRjABTEp4O2sfJJdrdeSOBWzzOK /DziHOvHAUxTLue1hpQR8KBkx9Q+RHkIWj6K/s8403GK5bk/iP1cA495U206K8FJ9hOwhJVhDDX2 kNAwHvGlx6iStOddpmQFno4vzhUy+VEZi/pPVFma00Ja5SEyqJBNsqrcCG3LTvY+TkKQ4YTGq1AA kQl4WGRZHqNSQb8Y/0j/YmtJjdWnervdYiTGaqFeL5a/OsqXJfqMH32CXyuIst+aAsGkFOmnpNCD xJ+6iasGmW1QEwh2dh6MPiDV+bwVBZ4s/s4Qemvw9ATRf5BmgaVsdFnPK9AA7Yhbnj53vesNUUpZ AorV7IPYFdPZa/jW9cQkONUud124gyf3sBSxnrMTiHBlSQLoYe9F0bjncFrSJe7g5eNeCscjBphc t/t7jYtT0l5JKAmQMUDe9jrPsYLCa6FYHLP08CVIx8pU2nowpOhPJ8MdnrfhGxKHjVuarjQjuXh8 9sNtcD6n5qqvv4m3o/av3XCvXRJbsPWq3XkICnoCVJH2IKP5yKOC7rtjlbOGAddHjq0R65DSRLbZ 8QEsSDlVW2Z3muTcuHFBG1t01/Fcl0U0PKLJS9qeV07NgeFPtJhx49B5kUGrKJfYJaPzvGtgTwlo NIhKW/cx60UYfdUJdwnFUlhvBWqcmdeZLWikL7i7oItRCoiMLmwEvGVgOUcdSfpGMEFOPPYYfj3H kF609q14FR4fcDs7cQ+uxkz0854+XCSdjARv9Cl8Bo9IhQs0hgdWhNlv/LfRrtrYACy0RGVXlZa2 Uthud4Xt7EkmptNFjTdPm48Y0DBVHCMXSFsaerbAIlpK53CTGI3KcIR38aeBBCXQ5WJMkBy77+sq ojvGkSOJDqsUYdNT6crhEA10Jv2GdDYY+a1fA/KtRbMVQvaYzj/DRwq++LCSiojqWLg6qSQ7oFAK CW0IkhX6yve8VCeNpIzc+s2rIjlhiuTJhKi4Dkw2Ty6L9lck868ZNmFezOYkrOxaUqUCmri0BsCF EcMH7KY8ZG0ID3gFl0QBs6wdYTlRm/kB4emybTf3gNcE2trt81KK+VSpmQWjL6ZYscTs6t89PivO erMb7c7hgU5InS46A7Y6G6t4w8yvuXxMVruvfWu4nZHwyFdCD8jJC0IsOYDQULQkbADY4XPoknFp GHw+0mbeLwKPck2y5qeBTWqR5uQWyYKXl0sehX+NlUl2g73RCiGmUBqwfiQBdkzCyWLTcww5hHtn dB97gglaYxx7wXcnqY2m+ahvIFvnBJbSzYmPUL1G8b+mjyxnVdbbStbVLqn0BuIPQEdCwWtLeBXB t69245K6MrmCuBtT2/cZLzejQdL9Sh/PF5pQwkjkvc60zDNC7Wq+VnZREKkeV+wYyFBD+vjWCC3N 5ZkOCBh+5JHpb5vbBCkQ0duUITQyqaepGbHD9bgoaYmzau3YhwjMLj/Mz3UKMmAuzKb55UbTVRRQ DtjDNSqNda6axAkVaBQXITChSDLL2irdlW8LZb41EpwM92zxQ+KIcGy6w4sKioJobbt3pYhbNeQT kvbZKY278cap73ruBcpQ3oOrhPPGJK6awBNNR6PhwyaQH5gqAfa3R/EDnWect/3xKpkWRSh0g45E U32wK1lzVOHLdGvgZslN1U2bDo3xi17j7QSan9rh7hYSBgl4xJo+h5ly+rz9/rBWKgDvo5T1C1UA 3qH99Ejh+ytxhbXU1Wbf2+xrV0/uDi3LKnJbLd3QGDOxKcI2Yavpo7E8Us6g0X7rsObIO1JKhPBZ +kiBJ5mlFRbg6mR/TOglJbXiwmnrdUmM0xjZF0im1FeSRw17sqGYXy3zOYDO/meTetoC7QVnyN1y m2M8MqJnVJw9CAp9Pn2ZiMrlUTvrfHL6DmfFgwHIOTsRo0F3V5e05VQvUIGAFxOVvSKw2AVf6/9y NfWpCpH3zToqDSf3qJKrDx2HXkInQbEwCXJ+HZ8vRcyAMmnRRzS823E1Btdi9f70/ALWLavgi72Y D/P24WEmEkOeei1dY/X06CQpjuif65xh9pS0UJtcPKvCl9dlNjB2E5lbyaQ1bdRfQ8GCSk7Ug5lk JWwvs4krYeS5CcvbW4hL6m2XISi9r4zn/HmcUJ0H4YAVCpYlhzf6q1GFYbf1w6tmA30tqmvtuFXk X/Zv1dOVPIIaF5+Pg28efYpNHSCLUBUVpEAbc21IyvFunOfAfPPrneBQ3BYimKv0ytwRG0RDOpOg LIHtUlUDCLspDTkQN6F+1NQY7ggQ8kwr71O7Xe3EY8EhuuLQN28VqgvzdGKXxFD+ch9qE3YK+3ZN C4gLHPvKzcf0YNi6u5kWkYOHX8jgTu9iAwUPSZ/v/g8x686c3yafWMHwSaZZzhW7pk16J3r9/fH+ 0epFGLCgGmtPbF9Tar1wMjZJGVDci8Rt8eygzbvs4nws1EUL6dKFJfG+lXCuCMwdLjPH3NleWDAc eOCfOVkca/7OmWQcF+zRG4YTTHrxnSdBDRAF8ehzpAB/uheg0OWrS9Msua9G3tMtbSgXmyV2nTpi qOv5+St4bG0gx9wVABRZ/Cm/WVUp6RUSKWIom9z3xS+EAgaaN3+r4JvSO2yCL3mK/nzg2CXusGTG raOzNZI1fs4iu8+PsKs0jyfe3IYQe1gkyDlzAYTyWAT+oCkvke2ljmGXZDOqPIprR0nhwsLhRcxQ vfa52PXfJIwvnSquyNdm3XTXsD7mO7IDFcCnXlhzscjDBcnVmpFndRPI+R1z2qI1ggfGXJtJzI2a KSpK/sWB+XRUkZN9cg+m2XCD6bpjxtlyOmox1u/jywEu9DWGgWcvjQ5/AGjC1s4LxyjthA0pxjeo pJy/Q7SvHEJwj/VptzRCAAdA+L/4mJp30/0CA1S38UBEn+JjPiDYY/IpskPs0ghyy/ekgLs4rV3L 3ga4W9zItaa09FxtE3r9+JYaMj/RG/I2KIeTdH8m/Bet8j2iI31Tqv7oD/5VBcB9s5aoV6N2/Jiy H0jxt584x+hLw3/hkyp3RguoEpcbut8BOOOpxQvKB888ArJsrV0m7GiCi5HOgvmFmNGR3HTIZRwV 1MMnXYaXfk88iatjlM4xzTYJ3yBLeZv21m1aolg80yMl4ZwKGv6EGmOgTfJ0+/CiK2n++Tj4FMs2 ftMGf3085pCkIaAB2wgl+B55mvrM1cGdTTm/x4i286f6PcteV0ENE9QsnyvyJ+BD2NVTV/n9aoFp R8eC7dsEIq2o8v8nwfn4k4CuOTGC96VH0F+Sn2NQzJbvy+5mmkMquy5mE8wOxmmM8h3cjlLffTn/ /xOc5eV85xQmQbPrtj3Ta8qbev5rZD0nYt+oLKSBpfza3IikCN4YxYP2UetvwGZFRS31pVm/zwS9 eNOLGZe6vnpZJYPfL6749kKsgnc+B6p/964WKyyUDlrjJGMf0QQESDxd22nH5wxIBicRZsgNAQfC 4zDH2Q5XtdlJHAclzb5+8MLrL4uxeNXoi0oP0tyaahJz1zzq5vgz8WFotEqdtfQXDfLIr2lwZhSw A8D8sQsTllSl0WRRKZwJL6R/ZgdTNAFAQSOG9wpjlwfnBd8quOEZMbHhWyDEh5uKVKycQlrgjXWE J0a6gxGvko6w4AOKPuvirWc7YcE3imcJ0/gmGBQg92i3r9qCUG1IYdOYYgjlalZGm2w8P5HjaTYh VVHLPv9AUDzGD1fulzLpLhYwXFTwjqkLN5tnuwPRDlkVTOOuWDuV5/04WvXvKrmYp+SLHr+iirw4 1l6Vom7qAxxxJaO29tQoVwKkc5mdmDHhZPQfez7rFFXpIm3r+Ls0+r6cvzywwzGzwQnnbUTI3hS8 7ygavQBikQH7deS2B8IAQpV292i4a5vilMVlr8cxbV8f+rwZjA6UAu3rmyr2Bvce2FzffCuQb5aD TWeyRrorbkOBkukKNiH4jwgLEOHKSPI2Wn4HgegXTzUkviZ8klgcZW7dELaIu2VzQYjogrO4hKDQ 0uPidMQPxcgL4B1BGVOJvcRkDoE3twogqSau50Fw4IUTpqMp7fa6blfBNAbZXlf8iHUeFM1rERgG W3AvsNVe1B4Hdhz16LjVai+QrgqY8gojm5EfPeFUDmyV88p6V0BVABsZFrBu8NBQO+UBebZeypZF B+Su/JDQox7pOFLKIuYKOtJmpl2LOmIrIiRdkTqhhUsSVwzlj7G/E3WxIcDS1YVxINFgGAQU/4Ib EuUGIR2BDzM0TxKDBa455Nw8BRw74EJ8bsQ0tm1Zih+R++uI8FFw2up7cW9hVOGanOcO3UbDEMBR Qw0IYTvs4J3qxWcCjcT5AVWyU62zyRehopvJ34onootbMNFXwm9lBzjivbC9yy/A8VAhcj4Lqnw+ edCFWttJdnvySmEIWhJLOrpDR8VJWpr9iihvyuNhpHmnXrvUoqMS0S+wgWS8QJRJj0ZI/zfTP36z cgv6vWIUhmsfGorEo3zFeKlFwK5DBxkMo36XWLGvCa2z9H562Jrmx19IDIP60uEVlP8ZTjazMTAS a7g4AytAuraCeqShA+BbmChlDMLVBe5/jTNsuHyHcAY2bEqOuEEKGuN/d3j9V1m3rd3FF0MdPrCC T8vnEuWSDvLpPQn2QZuc6WhpTH/KNJnFHpXMfMXBG2e0WIehLtVRICyvQTyLG8Ml1D9L/FgitiEM X66DkYzPr+hWK4W4qFtDLh6QojAhP5wH6fchZGtxIKQ7SmbAxyzV9r/JUT5fACS3TvyDEXVXbomK Hp3nwi4ALhyuR/nPCNfoUB4VEfPZsCVP3cQ/KclRMIxHeROTua7aBRMmjl6mOJH3Q5GOx+d1QJHU SrLwwy5v7aWThTGxjyJKyCAOnRt57Jk00gmFN5/YD5r3KUgtwFWGXeDQLWKUNI4dX1xg/+aU/+RK LclofDyxsvXmzhMlpcZ3wfUkATof6sgSq4s8BtkaQBPcvGBV24Hm4eZKLEvUZ3W2JKwIL/ZyI49d MeNAuBe/U0orHdtGP2pUTMSb/mj95qyW/5D84aDhHPOlxII0tqoPUPl4G2YeZtT4lyf/qKhalK0f ZZrvgt/QAkm0rZUKpzpq2P7XtQDICbgffQYxUAQCHmC4n9DL3+VvIcfu3P7PmXtqtt758U4RHsZG A0uKJTpJ9E5rdmxvEOKmDtDiGIi//rxkyo2GcoarBhswUCPc4Ifw4yJHy0KgRsakWYumleiuCe68 C+LLGgCMcogLNPZ1mYX1WLTEuM5FrfKaosXSu/tE3e8EkcTMa+DdmMgegewirBI6M1BAly8TGPFq n8/BjzAE2+kKP99XdkH6IwQWmuRCHqt74LbNWXtUpcZLrGM3bc8TcSs59nK3K7l1T5iVuTudf9US rwKjEa+qSFj5RD+ZJFIVqCqu+XqyrUhs60UUcZa4YDPtfCE7vrjhZ/GtFKKwmlqGow14mOgzG+U8 Ar6D/1BnzBnWR5DzGKCCUplXLU1tySgjpeorKTGQDlmuW4D93PLoCKq0DLg4TnQVNMnD0c/97xcw tHlHKV0dFSWftc6jS6CqAlnOcajfUxb+kHLAnOt270r3PiGq77KHxpnDApb3/8/gMDYh1PyeeuuX SbSdeTQ+YdKZAzcDbfK4XbxBfpnohuZYIvLQy4s9I2uiKraIfIypAonG205pLYkgv7QU2ZujohYG lOwy+ZV+8nkBDAjEc89VQX520X47J5mgvtNuWWJpLL9kIeuQ+CFM+nCLwBP5qfFDckkOPqT9hYA+ B6suFLKOiv9tX+yh3Dr3xRwICoHfryEreuCwFFWVWK10SBePBc9pytE2c1tg6j1j1xTFVJ5MaH/0 iWqmEUB6CO9RD4VJIHxXoSoXz/pYuD8bEbwOs2GJ/7H6MjK9ynJ/i4hIcA+dmA+7oOI1XTmFgbCl fNaQ8ghORQHPuF1+3pHMMGnarHH1Du8WTGIeYIQzQM6fpEk1S9LXoQZ2BbaqIcH/cqsqbAybCmaR mBiNbKXInq3MvrjEzBavZ6/cicIYxsfWmzRosz6VZC0a9ze+9A5cyK4eSKIhqM+H+cp4h6jPetHg yOi2xvd1CcP4elcKQpb/HcfjuY0Bq/Ls3FSslCW97xLdzNjPd1TTMonI9bPid/E2AI2SuCZjgIsQ Iz2EHq24zZmx9XSMYcCX9cw25wUpP9yqDN68sq5hFKYxc3Lg8qVl2ZLTnBYjli92axUCqvz1weD1 SopbK8sn6j8kI+EvdhuveBs99vPvdxUKVGZrcTZclxcnKOdj+VSBov/H2Rywg48FFwB2vTiic3fy 2NoqBvRqdQo7b2Y+ggFzc6507744PNDFFxETbCSHDRx4Hlp/IGx0NwNJOaoJHBqF49j9g+yvUGS/ Pyim/XkGi2TgGLRv7o0UCQWsrN5Jv5mWtwcV0DaAPvip0eNSSRu0aowRVVsyBZKWJlpVMhbZKrJL WKeMGvIaJpmbqSu53JGC/lmTKVhvWjJcGglVzFxoqbVDQT2GYBWeUiYaTXkt9ZfEx1ovetoRoQUD gy1jCiUEkQ5NyGA7UP8/6j/iNJHAk8UTje/Zba0SR0ooGq7sunzc1dnENgQhLdH0b1+Nvaw57Mag 96Fx/Fk3ht1IP/BEcPPVBDsnB6RmhD+Yle8omSc4w109GJ/QfaAxgr5YQwunLGed+GDmNcGZmEjR FvbpE230XJ2fWZeQ18PjJ881C9vZQNn+49XNfZ0xrqIaxq0QFeJ6xE4DIogqmH9QwtWbZvWOpwng vB+ofpqkgK7oTuWr4p+mO90wnC+bbCQN5wgXPeiy6yKQr1oaQTWXIO5x5lalnvCFMZuhgD9zsQvz AN1q0kJOvKqYtYvNdpi4zjEbIoE2L7FlPc2LvhUE7o4fVD1QjVP8uzwYJsds5bU2gmmFyKjSsfXU EPscFyFaPJRENKAXMfZBKz2eEqf5kPumDD5FPoQN2DGPHBe6Avu0CbNwINPJIsron5TimKtLI9TP KMrKBwg0AeCQTh5ZkGNh4ckypgr7kZtQSqR+9lx7VXTxEFcRWKQZ+ymri4Y7pf6cdble3k0c2U33 mIGZ6IiiDZZNz3I6ix4xY/juJivIUuifylTg1UIbj8ozAYCzVgoUsh+c1r3jTjYQKYO/XA9BgGVQ 0BvJAmiywB/7vhpPDouSAaPvU38E9K1K181sxzdb1jUWJFUnDEDGSGS+6BXn+gHACM06c5844iZx sYdwDMPTRKdIEGfAJJzqLUdW9FDaTcjPOcwIzC3w4tECdLZ3179QGGOhBts/t6zzeI6rWmYf+qvP g8IpS15qhp8Wd/NknZVkC4eufpwxKTXCcvSC+4l8BP+hUidmAG/7gzyG/8OEczYvaQOKNx3TgfY3 BWLETD0kg6beZV0Yf2Dz7kW+sJIe3WQ6mgX01FS6W6ke8VYkeA0+Fpg/UD+ftbJyNL8a/xs7D8QE ZnYmiY3eLmen0rS22wrMMvBXG6OSijxgpUaTZeB12jHe5xvVJJDv/50GpfKFa6NxjuI8+brFG9bw zwKEMVCKcIW+giDlA0XroFsw+nHqJNbXOyESCumNA7h+pXTJOamiUeaCiVPTcbySviCSkHChPEo1 3XZiqliQlSOA+nc58L9hV06a9O7age+pFSgQBFGeAesvsD9T8l3h93q4EwV4/EmmIMRpnWxb4Fr8 3jvmSO3PSoicQdW1HHd5/tINhryXOcKvo9x99K4vjzirjMbfSH88OIPZuu2k0x5Vtr6Vx+FCDoCj z6DQ8GziOJfYHhN9UinT3lok1JmUCG+vz8/cjoc9VyfPB/pDL8MsP32JiTwpaHt59Xmg5L6r1ju5 gfH2FsIi2EHAKX8xeuNWeFPNj+OD1nNOMkLhCv0mQ6yE8hvWLm8fgS4Ev0DdAfdKgXdfek0Ua+eW DUnEZI65QHEUxTyMhR9I42937SeJ5rFrcIcIxMTfs1cTkGffsnenP9ucf1ldOGAxZa30mB9ak/B+ lrYhwHPoFcxcqLaLU7xzXO1O/xreNalvu+rrDAMRn4XJrLuiTocJv63/r5fx2MUD549QPu1XD7zt GH4MSixyC/HHyMEax3IWS1veHxvN2PNlQAXZFLcydMIWnccjrR9a+ZU6yzLQuP1s86QQk/+/A1Jp O0MGT3zY/paC0G5zTgjUn0xKAVuTmehleI9VqipRI0NiSJs9Gk6PF6E7tjHcQRLHK35aURZnh4PC VJTwvGiK62yA/gqBq2Od2gr29050XWIUQWXQtW0O8ygt/XV310XtEJ1sC+ai9/N4XtwTX1phKNK0 1XJ4LBHquHMUVAljh0wJYfQrFdFWJso9yX2Y48nE14gP/U8ZPk++jKCBBVAQz8STBdGsH0PBZFtO NOk8fV6arGCYLIMBm77bOZoCUipytF4PUAsdIBFxg1yEHml+/BJegSraVwzIlFWRLBTOuIvpQb+r /8KWaKmS3l3qIF3mnvS8w1L4kCk7Ra4svv9xjBZat4cQHbKEjjfIbcJ8+BXl+WKDfMQtpaW2FtYN 9r6EcOgYKTbbGK073WC3NtAXIhborwKCplo9wTQnb4k9jSC4ViDniFFSCUum3V3tVqs2rbd/mjLr 6YPoyUpmthp7x4YAOajdW4a+jnfB/HWJqKd74hF7CgJGjzJmr+jkGWUhTy9kRPEqpQrbix8AJ7n6 0aMqvZSvH0Kq9EIgW6NxJeC28I/2JILaggz54VHo0tGOsToXYUk4lCgBzWhQugOmEAOKZxBCN0GS wN9iU3bLlGQIA0VpfqEq5NvejmG2/lyGmKgSMhLYti+d55H5mZ3GhKsSLuLtlPlIsnkdOQ8xs2Uz yO6kIufytzR9qqljt58fji3fq+E+Xz5YVGGPVV6+IrhNeciIi/QODujmuxUY/PltC/QwNA3W5lSh mlnCxvTwz9YsmEAxWvlT0m8S0ouFFZwHzgHsq6eva7R4i1qsHuFYd3C79sJs+ecV5JoPciPXGXxn iLKinZeJg9ANWA+j+Jtr2/FpyTJTX1VwXZI8F542qh2ETLzQuOPDOWkntoY8uM7RXD6UCywi6zxZ iZT2yG3+KBGQa73zBVGd9vNimhXe47fNYKhOqltNvKRqw6pbXUeZ9N25QgLAm5J773K0yxO9CeNk BYkoiq3NCjXPZhayQXPTRK6qD9SBF2QpqW0Vr7QcKS5SSetcW2+BTrEwqK9BPwu+bdG0urEkKtfE i1YnzlcX74BI8FjsAk4sWdN0f2psrxbe167fUIEerzRjKD2LdShBlzQZKfYSHnsh/ideR/BizjXV 2ocCcFiUT2p5HZlYe0JMqyEx7vDI/mZKyK3t7BZvA3gArI4WXxD5CIP6cOHzrRclhdZP2qPqnT8Y 8qppShhgEpAlxs0BdFjFCAZ5XgYGCEq87cNUZ9lDmUIIYN6O1OrjAG07VW9zMKOcoZDCk/yV773e X3LZwGBOVdVbjZUt7xZ6NpiFwmaC5bG3bJbRt/app9O69GvXhH7D9qiXDa7In8GX3VIMl4MTUhoM pXxrizTRkPNZIl+RJGBMu3Ga9vlj34eSBclEfn8qoEFQMsEsX7jySmVGD5Tgc1ImRCMbPOXRcyn4 ACDs/nyCvS1k5cbbucwElz2nMGzibKVHNm+TZ2UaThfVqigvEfUCF7G5fvMcZwcNg9z/XtywkIhB 5Ab629PXFq9Dx9aNWixFMVGjOMkm0fhLN/pDv9xzQqFaWHRSasC7V+zoRa5a4N49UUP0sQeKRrKo pZDEDXDGxvpKy/t1xXoB/qe74YXCXX9yhY9fWtp2d7ixxxbbEj5F8MKEWW2O0Gzlvp1uX8vNOUke e/GVNgaN+u6rURZqyDfWXJksaQTEXZ3WHZJVvD8Gn/ORGpYrSm1hzlxxWIRMhviEYF5ODkBGiREa 96il1NPRUac+LFD/LY5jLYX4Q1fDTKNLzsPqpbmkbZVCTLhvve7pcVv2rKubUzXJGwI9VUiFX3u7 XOPYRtEIWwZvo4J8CidHQ4e1AHEgXDfaR0OqFhiLCKFJz9yopPzDL+iv3/4eigTo9x4thlvhIsva plORzsX5l++zPBWwVRc/NaSuG+Fj5g3QWCKNNqADcEFUJyNUE9h3rBT7gT6CRnXERh6f2RF2eKDn 5J1oJuG21ep+z9/VAX96XkdZ7ILmku1OqVcysqlIWBGbtpEqzy7tNY+/gN7Mrg/g4IuWeCOOQoqR jKdy7adOfgBO3+DmbPzp1pJH9SL6GulY4Ic0k0SrOwyqtQn8Vdzgk4xEe7pAeG4YLErqvKOlnkEW p6sWK0eMsNpZ4/sazNWe5d/BozBiUHndOrR3yCcLJX0ch9wFCToC7GSfE2cBFjUpI7/Vkwf4RQsa exIJnjSzghFipAKeK2OO5b8+Mv2ZzEfPMITIB4B7HEtjeZzI5tzjuRk9e1Zxc5JbOsM5SrGuF0Eu Mawk6Mxpk0ggqkxHgRF9jaUUzF8W9zZFNus8fFDFm4JhaWz8QEQwbtwOr8nj43E8nHI394SGOJC1 eTPo8Xw6vMYnQHa8rXiF/8kXKcvQ+5pBFwAc0smnk84pHA7s6kKQ3kTXRRjwbxj1WRUX5LBWIQXx BF1h4gSAtQslZ4lmgktSyYYiFioG7cZ3WFoLb/wKE1H5jFOjiPXuUWUCOIP4oBUx3cyvwy7OP7Yl /ATjGbcOsdHgkXB0OhhAOh40GCR3QEYH6O1JZo12KAtt4QIaWLtwB5mD9JoIYK77tkhSEHFUx72r 2S4iqvZ/YW5tO67HC3Hqg9nIJNa27E/OEFW0S3gt69J0xFJQJMK1tWuq+zLLOzVracP0XedPdIMa gLpHZmNrBxx9jE4+y0fCRRjbMlYdjiU8ZAfsInyeA3HlDX0zid27MP2hAbTd0uzTxK0y2IpMgPUB PdrydyIMHCgp9dRnsrs44nLGScR+JslqHpSlTkGVbs3Q6uWkuCoz08sur0fhf03rnbiCqVF8zUc7 s9PUdDK5hGTWWxiSNUmNN3YV4o0mg+rgL4dvTAwqQcoV8/uVEXOH0K2B6H7EjKkLn8f9VxhdmJ96 m2Lr5p2GVfhmOzRw9fFrQ7U+GbVLiXNDSnV6bzq2qieclm4mKofnv3UcwwnxgDRVgm94Z9FJz8T9 vQigVWLc5MTt6GLvoEHJ2Fw0274Cc2K3l0L7thkYRh2ghyFiqvXfizlFA9S1JQi94u9BJLM/J/Gz 834JHsP7yo/PNCWM8sfCKa5O9Y/t4mMJEAHdV18Pgs+HFClsI3Pf5jG2gqozP9qb20zC0TzlodmG TMLIoBm1gSpenblh3bjS32PRaUaemtzUhQMmuunpmJnoAxQOcb6nQV40yTuzBt/DbMubId++6fwR lwHjnEOJgA53RrGd0smsocJ3Nb2+QnebvEAUc04/rf5dFKUK9IfnjvhnVZ4klYDt5dNzI5SjbP1S oi8z+dsMQ+cj3W6gqkP5dCrOqq0nlwsb61iB/ebezcOOnRni3/GyzT1Rb/sD5mAOkEGPPWbQmaLZ jBrtzQD8iVitcuECoPPCzEU3fbVUAbFi63ON/LvwvorQOh8TEf0u+VMXb+8MYCUkkhUVcqyxGZEZ R72GfY8e3ijz2/YhICJr1646mu4XZ1Usob0zkJgON+8FjX8iha+iUwuND/D36poFKFD/Wy/UYv4J 1ZZ3LszcShDNXvbZQEPs8nw6fYiNEG3Xwwk9hCYL6o8gto4bx4NuIgnIgmbJS/+53yEIO2Tl4Oho eiTkEpNTVGAt//sUAhe9TVnzfUSdxgsw0kjS+mYMPpGjaSeWaBywec7/kDrHeovlQx96iXxwmNfz rot/GIPhw0fFfstx/KSyrOJuy9ZyXrfMnYC947d/6FDGM3eSK8Yele0T7ogXbw9cJSMltf+/5oXt llpO9FjTxYpPUbaN1OvbaIjG1/K8aXG8QWgTTBacvHhHndRSgtlY5WA9+iwfj6/889bbWXJUOyWp OKy6uLQZzp27deB4UVKXS8rZWZ1MxOyBl4V/1VeYGGn4H6aqUs/MUqbRpHZ5R9f8q/mBkTuBeYak 0vFmBlaCekhjtD2uo76b1+EB+ZTh4CMvT7QoyN3vWe+aSl7s8d4yO0CPwpavB6s2s2Ba7AX+ziqD Haj79ciqSS51A6CqbwbrFOGDpe0iZhRLSHJPCoqKk51dd0VzC8z5tgHBlpW/NkjUlP6DhIAGj6+U VLgDsb6J7x8kbU6CYIqnl8J5W/QG4MqhIwv80K6vkPhS14qsuV9MwJEau8cGb1G86JzOA3dJmhqt OOlfF+QcBYVFtty+3XcalexsNOqd9p+2E/9DynmFz5M3W/heoylpSg7AV/BsvG44grKq7fycARJW 7GQVi4xxNS+s79ocpYZt57nxlRi2PJNDVNzECxgUiB0buPEidIfxVWcK3h5aX47B8MGjENLIOuAn 3xbpxzyiK8jIuuKoQW9Z3qBtbM80HiObPaxxK9oJrvPyjErTEsi96yaXWndwCz+ouIbH0LKHoB9K srF5AeHxCbZsgAmXieqs3in3ocBxYxlxllmdHt4KLZNNhtleLFYdGOKcCwVxFIS8+Bvs/J2ntHUd NmSy7fRhh0D0vq+mZeUFYYfM7SO6bPQJN0PvbInAQvBYnFEHezx5l+PhAwOwWlVRWXMnBDdlU51O FrrTDiguqq6nXlKC2eCKjcex9BasqFeru22QO6o1rgLVI32Du6S+a/SB0pCtFYEM5JayLnWGS54M Evl6EtimBWZTejpIxMOOe9wI5dB0h/39N+y0tyZB91zwMrZRDA8VH3B+UQc5+idjNNOo5HzJ2/km cxMymrqwrUk8mPcbVkzuOr5fLrRewHEsu5pxSaVzDJcBQqkIW3hptThZnr8nZDksnz6/V6NzauOn hIJLiDD41WBdLC/0A5HIlc+GpC4JjndTDntOJrYQVK1oPxaYJedmdzuGT2CU3+c7MLObvKtVV6AJ 89THpBDS//ho8VfKSkXkczuBMYNG4Ot5VFSpU3EctRl/z6zEOThLmKEi21BrbD4FNHqT+8XbhiKH SZGsAdg9lCO4s2Vi9NEaB58IYoyuz7bXN8jnNDnsDOZ8Xe43Gr5Q+DGPd2ZZn8d01kfAUl41UVl6 Ob8oK4TYelGe3KpWQr5jsyWO7G+IQTzNQ7uP7JouiR/XyAjDvlgCyu2NPqeEPt3ft7fpb2g3BOqd qhdsJ7sdXors6VvQe8RsOWqE+vrNwI4XExjviIm+13wdYjKtw2Y+DQ9mCKUaAr6naxwvtA24WSau bB6h+0IZ428u22vcuLcFs+KryenDLlaF3FKFpcQJh/7ZSLLGEZ33Zq30SWpHZfS/6CAR7dnXKP/F we4H7R37Kco4utqynWOjfE0rzLzQWJtKkClPM4d1ZiAA9YzqK24I5bYfW8+XJSAGIGjsurHWDUjm vaw3q7AQy0HPCSGEIu5e6lH8Jo0saoJ63rGShmLg6/Cw/vYfvpXoiTmsFVJe6SBhLf/ba0ifz2iJ wHr3i5qw3Id1O7TnclzIAZ48jTK254mqWlAhJAHxYeDe8p9N7h3r6ipcQS47DfvYTtKRekIOH9Pv 2A/inUY3sd6IHGiRYIks3qvdrBU6p5PG0YHmDca+PazMg1c7FMjlEgmD42SkoaB+pxaFejyI99qE Qc1q+f03u9P5PvhelSpGNMRGZpHMDByn8D+QMoyd16KrNjM9KAyleF1cd40QWjTv7jIeS2gCTH9m R/T5TwwY4oxnBqm9+FRxb/Rek9MQxYwQBMDtAX28ogkoB1Oc0qqcrifipJN20PsKwynNRSb9nyv2 jCImnZqvj4Ual5BuQUSuoyorRa1ar2MaMUvhQN5gLxe0Elopa7uVGwWGcffqoguweEACXRMxn5lX lzvDewF/6wfaLG7bZEeUgMjSVyy/sS3jOvRh/0mhHaHhbc9gJLFtt0CxrJxKtkp0kopCk675VA1X U8cXO8g+7IZ3lzOtj88m1jS7+EfBDW6j28JuvRd0tYl0YNHAia9R0wqwTIReO+nW8Qh/q52ktDzs h4hA2aqbbpoffiVC708lc4ZhWFbkscnkItge0eFnvIkOoQUSsc9ZLavfMixTSXElJaYixCz+HkoA 4kDwVftAV/2dQllvWMnFpwc2KuseoLtQpojXRwo0LdL6JucSNv039Puo8VGpuGO/+9AtuXomYu7M KQwjw9AYHFfX+qtOK54FKOEfyKbNEsnhA9suyAC8SEY9MJZtTd7v6pDFdSjrWgiK8XjRD7GmeZqA OCNgJtyswtRkZ11balcLwi0XHaqsBSZ9eIAIhdBkg6GuAOhhq/vB1p/iIFhp4Q0dQlg6e75KDFTB LF7H/cm8k4mvbsNDsn9IrBPQ8Klk2I+hys4E0kDJbvnwM+Lb/FbJ/5pPTrd+lv0d+0q1MiAY09be W5CQHcae+Gg5CL7iXSGok4XEpunC/tY3M7m4yqbrXm/pwb4sMjKLRF0XKKOoGPljIoK6WIrlf5Rl TT62U/9XDCECRRb4lG1dJBUvjhgWd+Z5SJ8WWn7UM3gAByEGqr+0R+flApenTH7jcnmzvqrdjFjQ 2OPdDJY6kLLfwKa0YquJ0fxYLomLHe2hkmdkmYwh47sMd5YvaTooA368upmraEZDvn2yr8K9PWXN 7T8amVcYAxYEvL2QJlmv4lFfc2ogHbk1S09rXn90K/n8+l+aSkCw29LMp2s6kuaDCTx/2rizAzPS C7eWzguRcZYGtVPVxe//BVlXUj9ilAgODAkdoT2e91lu6Ktg2jRhOlmT1aVlHmRXitBc4HxR1iyu asXu6HJgE8EZN1fdUaedPjrAuTmTdzb0+2oegca/uHISHg1L8QeFTUQzZjb4gAVFb+FcproAVVX1 Wm5srKmAPaAMQuHJo/hvfx7J14KdggnsdhpATNpYvZN55EsEQ7GNYBcja/6l5+333IP5gNhk8S14 NM2bNUeEPNXdQuwZz6p76+zUecWj3ZK6R4VjjgCjGiMtwdkW6URsQySc2UklvtE6kE7jQT4QJ2fJ Xx6C+N76IFlsasEMswKQrZty4hHKvAxP6LPqEmivQTqLphPkEeSuBQ0/lRq3Q7WSeXBuWYFvs3tw ClZSefgFl3yzvWJMSGCBXBepd+8IhhMmSYdQICA84Tu1Ve3G8R4CEN9qpjFO2bpyeK0t6PG8YncM An3H89yqNxYs4sDcvuKEc/EFB8SjkFeb+MdQWjX2jC2R0nxf8RYL2MqnH0z5TIieP/k3Q17iT4cB WA0Lp832hWWNOUfrkIZvYKwlIyAHA0QGCzhHDhXt8wJF5NBMdtdJGvCiGijRYaJuPa0Rea9sLThJ EBU01ED9nUP5fVLCBnmPpN2ZMX47+q+AKJ5/qLO7ouvpEu27ccWpxeUfVaQ1EFbNACt+FZHiAF7d KHX/2sbFLG+E4iwfXVVSAj23W3GON+asmxReqaWQFEZR+UadOY+OoU9dwdPvPc2XsIc3EY6qCs8v y/Bjd/q8C97stD+PD0/vgeVh5DPTvVLkqAT4WpMF5+nS6k05tU+uEeG2g6Jmmdd5wAVaRarJ/1pQ b1L+eNJe8TIZc1yjjlUNy/ijvtO1XzWie4obMIhcXI4wbR3MtQPfKtirhQN3KG2C1+hYdaTWfU2T tSpTlMQyfqatmlgasVF2flrOBDfH+qFcSWphGplMLcy/aqbkB8aDiBFVUhH4tt0O/mgG0YD8L68r MUDtBvXhcOOW7eTIsSHCvd7YkGO5gPMnTHF1+czxuGH/4Q9l338A3NUCtnLM4NJH/dVUaksNEgc3 BcAsEqQNkuocW3qL7Ft8EbS1py8+evu4Dqul+MRqK9sS0aBDVpY+03iiFDnC3ucV0aBtpoOTycVu ByNsxLrT6OTGZWiMNeowOAuui4rrEj+PM6vNZou/Ml7DurcQA3rmIF0oMAzgW3V8EOGg7a89jMnA Vn4BNNMzhfIRehciyJ99wHOro1durqcnxZ13W1Wph/QCqBQWFacSbv4PpSsB7g1+EOBL86xdgCC1 hc5nXudjtzkoMH4CXKRhVDoIbB0sVGNagjegazyJfscszxHAvSU2evorv3fHpIZx6CCvwn6JTP1c gLSjBfvbwDKhMP5OEGq4WBUdK5H28lIMbnGxoBTCb21AoUM/OO3MQLaPKMSsBs6OH4D/Zq2fxjTZ i90UYnWyIMX+K67E1+3J2/dfDRE3jQwxhe4i6klrHTkg2aJG9hAV7Zdn9My9ORATrg8cFdnIE15W 1gATj20nLg6UaOrNJ193/nv3CdQKIRom5y1asy8iIIChoiBQVFMsphKgTRQff6fv8Jx5hOP8j7kE 6RrAyJWCApUtt+HfQBIdDd0stqsRVsUfpbzxFYWN0FDR87f94Fi7i9G69AaTPXfZf0G1AjwnxgIg qofZk4YysdFPDw4LmNkTk3sqLZdTC4t3y0qVWLKNFkqqAS996IbIiD1Ya9xUHSeGr4H9ydhiqZem CzhaN3wPHQf2y1kQ5Mw5DMg7ZADK7sNpcVi+/TLs6lx2AaDP61/06ijlWdzo0tPKMwlOtfU8Ycpv 4rR8dphXJEU/zdNmHErCHjTtNBId2tXJlwvL1kwIYxTi3cD87BLkaER4/P0lACnAtuPp3hKckCd9 ZPffd6G4QuaZZhJcd9JLk9H1qE0tMzMbrfHFZKnYxovS8Fq3TvV0+nS85AQld4r902Z12dnZK5cR W947Ia56clPcnuuB2iyFSaOChZlx1/FqRfXzfOHFqIsi2M2n/HdZ9t59vkEAB0vOb3zCL1m+iG4F gT43JIoDSXPSySvAE1li19MBlT86M2H0EiEGSvebj8TwbrTJ4rGR5KqIRO4OrRCL7lyLcW25o54D EmAe6KcIX3Agky1SDxbr9FMmZ3GDxXLzFfX57dwU4c1c7Nqrh31fT9zx6BOnYs48AE88AOxX/gHr QjTg7J0OqcQJIxwFVAxV3BRsdeErp/8cQuy312EcD0De7PaABqgXKfHsRoXQYNt+mOMKlC0ex0Ko pnfmA13wZl8AZ77wkFpwCQQSbhlb3MQT/NkSkQRrTkxQT9OFnfpFNuaN9iGSaaHxgLdoDERpDWeH q+6YfoWknRgqWOntD0GzY5uWinU4j4Lbs6sCRf33Cr/NncsGuls5AjRyWYXVWASZLyPUUgKrjdPE hSNuK3aG4kmsc/ZZu2zO9hGBlBTbwOW6l8ldxDN5qD59cGXG4n8mIErjCayhm+RGFHt4wvGZJN/f SHIjeTq63zmVFjvGXUBahWhcKuNlyjFAndkgAQXGaSzVvLYVIBJ5KgmzNnmSZsqezc1PVC53UA4K CWSL9rTwCT6RXDFegKmN9fchqE4QT0+JNnOZuCIN5dxdBAs3qxty6BMOLdBdDo1A0BnhmeqSfCLh 763B2Ls342bL5caxqBwhs5VpW0ZJQm5JXZLk6nxHO8G1ck5jpVBWjkE8QqKdbIfuYzy/26ATDNnL LICEW9J25rSxn2SMMoZftOVqc7F3xh8PMHvJ2dV8e95YU7LprqrDja/H8+DsRIU02UjTFwhRKZQ3 mfD/PGtabSbg9c1wRmUphxxO89i5itxLqOHc6/ua8i2Li2sccy9j68iiOCpeEjl5a0AbV2dhQfe3 3tCt+f9FkTA32kJuTffPeA6DjULOb4IwDfNjziDan1z5kfU5/qwr5xnCZ+3E5QdQ3560LYAl/XFE Y+7UwLSGSMAF4YwSi2KQffQBqaLIctl3NP87UQqr+OEgpZicy+yWkmYeltgXwdc8WONwrJVHk86K gwNNn3P1k6Mru2tpnWyNsf9N7g603QEfkU+AZdurAyCuvHF1rMt7nTcyEgeBMmAFLMeA1Xr1TuT7 e2lPHX3zU2lCEquBoNOBcehSgGcQePjj1O+Euy6WrEHQcL6tm3KqW2T5tCVer04aO5T0MyX+5WEf wHbOLn4vtyjvwsSztHVrr0HEUHHZ+CaHvQM8kW2MLBseDkTP4GIGn0CytlFHsc6uxIjEeKBC4QDx MUYrGo58r8BL9HsjZQkYzVj0Tel6MTaUDCZtQKZkgbZmLbBhG9E18ekIJTnibSCBTBLyDvMGPTQc azUERjGfU3+1A+I4Z9WplL6Z8nu7toA5E/7mIkU+8udjo6Yk35SIFlcmh9JWVwwjT+2/iBLSZSnk x7HK52yDuifxt0t9wuv3TXQvQBDUupvFqwVZCM4MwHlBiLN0dIt3z1upchUkfy/7GCU2Ib6cJqUN J8rkm8wJPBCYlOQP76FA1ysbqaJXFZUeyt4F0ERk3uINflRM2SvhfINaXNxb3BEpDfZpkxtTRJX5 XngLli08umbq+uYReoAtb/0zEqWiGC8PxLLo+K74kqR5kt+lR8kKxOWgpIxsBV7iuj9b+Qp5Y5pu nLZnnsNjmCcZYjyoQEHp/iLxDjconHchPXFAe0k25PLJFyUKtiHGJhd6C1OBPIrq1I8nvzBHiUZw ZfWMSCH+etjI5R4LTys4zpwCv+dwTVu5Tfr9bOo7m1uMtTefllClbaUryvoXiT4fQwqePvQjhCfq G9cNMuGrhPk0WDZXJnFO8JUUcjBZWnj2//GA+KT+LJnk0QGahh/XhYlfAtOKBrd4vFm4Ya6GtF09 Lk42PFw7ux5OMgpfblJPXYOdAyjOozf+wiTqxoVGqK4WpuKrCDF9t075vl+LOwaKV4ERkrBUIggI KG9L+WOtpRgctF5+JtKYAAQV8WsqpRfMvj4odj4TSpyW12jX8fA3BX7Ila6zSOMmHekb2l7WAgoi mrME9WtS91xgheMv6YxS3APEwuPHU9X1Rr8cc2pTu3Mt+JD4A8iTuPXjPGVk44lW1e1VdyRkYbgv Uf7WM3nuGayGHp0fE4SPvAnDiYPpnxPzphyV7otqLb6dAlxyc2Per2HMeif+Y4cngSAxHy5Qzqpc 8OJdRLnRmTLdLSvSW16aqxLXtqEiCfyAzYcxu/3WU8hdjUAPbDvHHzvELvIeYCMksaMdcQHAIym+ EYMcmRNEkuEm+HnCC5JSuoT5UPq9n8G+zbzh9pZUtImnLNmmRF8eiDafC4Oi06JhotHxpmIr/Kcr TV8XTrbs7cGtcybXvCmLqTfDJKUY1tgJsjiLoySOisn58KOeWvHZCQc5Eo9T8Ttc0W/UJuWitSBk RDrOdG7zoaodYH6UcHbpdb7HE+aQtq98m1avlfHehaaU7wNG/b/TBPu49bpLQp1w/isngEdotYLb 0WRh6uasqj06NIwuba8TVtbx2QXK0f2vICC/RCu8Rfvojc3S/IkB7ObF72AkStcV92G/R1rJkBm2 O5PBsvN38yfl00/AD7Irmos9TVWN5qQsBrchQNIRIFpWcLnFrsZhHBkpPW7PDNWo0Y8B0LLwtLZD F0LOzeaHz5u28tjCFs36IUARWaZXYdwdqDArLNvx4xSly3M7Q5Yk40l9pOr0dcHI1X46Es+Evlxw gO942LAC/OA+chcg7rXEOZid5SZq7rhIpWMMGdP5M5+ngaokOzsNINdTeZ6hgsydj9x+YCo9z47w Pv1NwNaKJGvXzO5+XbnkGMivWmMSK8qlQCTsF5pIv+/0KS2YiwBcnTwXRMC99KaHEXWzWOhFm4X5 aunJJmMbfHFPAEeiuXn2JZi2+z0jYCKjSoyaWCS9TnzyiWJSj43komTXObo2a2O1R8IaL90DyWgo KMGOQ/pBVFyJf/QnTuQ0qUUn4x6/VY5eMTN3cwOc3dE8tD50avx/xOHUCR4HNe8Tb9acqlZf04lw 0ny8SjKxkpCisOUJQFWuH21vA+4TsZtpoibMl4OZZCpTgii/AJWM5MQ57ZIFKClxVudJOt/vXEKt zIfwlZWpKqSDm88yQZtuXHO0CKoW8N0hZaZKT5qqi+CdJ3OO6sbuAoek7ID66Th1/Cv5vw2OxdDJ n99SzsRMMv4fmm6ZDPIIi4vi4QhM6JgW2NYpLrzdbzHehkrWwr7Q+0A7JycYtfSx1FqVyguz3eCl NHKNWQVaxwrrEWpnEVH5+py0M5mlAK3rIOTGBOwijOtXlchcRe9S4Ld2FyAgHcz63rkfb/YeNEYW 1E98KuKCn0R4jXQFmeHDpIlgigXkKkFb3++meAN/ESUejDJnHbEHvLvotxmTULrKkv8kWGWhOasT 5C5/eH1c96wEJC+UdEWAjwH8DqZo+lENYgrhSd19MUIaF5IriQKRJaxRNSng50TolZXilZijikWu G9jaU/j3imeju6qaxwFHPFMIs9U5jybSyHn9q/MFCRw3vscr6Pqj0ZB6UBT0ETNcl9yWkzfDl+N1 8g3xbINggwug0qqDR95WwrcTdNDuOCyReitILh5eLhqDl6FmGBtZPLrOQKI4w833y41ML5mbS7X9 7V8eIdKjcSS30ZHmkFpEH1bQJTckpsFRJF+Iq10YfBt3rZ4bOKcTyDKpVlqNJwXdQRvdU+wk1PLr QiQ+BlPD2IBlR+mnQEje54rN+qwtz3UIMd/yTMVHHrTzWYTTVjb/rZahJEiBDAGv9RqM036/gBGy +tkfZlMi6UkPvK12NokRHDgunJmbMqLu6XstcddWXApnTRUeoP8bkPESE/09FOKxMmkE3i0t1ino q7n7D1d02SSfQPL3zEOp7p5XklC+cBSFdeCY8MIStg3PzcPznusmDWdHStQhVCF2GmqhM7+h/Sic ze6F6YIpswhZ2q6Gf9LTQlFsn12Fgz3yM9a/DpQ60pnBXY0xYLZQ2OB13upxwp4JEbmXs7z0NF3F pYbu3Qo4zHD7ehquFYJZQ1g7hJ+giYa7mJLlDAtWuAs4Ra2Ax8tfRxg2r2/Yqmf9f/oQ0w1BYBpF RrKRVXFZjF963oLAtKaEiQ7z2l/A+H+OeP/k2SP6gIPvc9/ECEGlqxJ/ppigxJ94rkX+xAhpujuY m5nrjHMQcu+1dkBo4rjxIUR6MgRUc28bwF+429HAz8NpI3znxasJXKhhJwNWC1sXz+fscEh+F3Eq QPFBMRZu03Tat7e/nVCAJvLHs2FAoZT2BuiFByLfXuUkfwvpyMUzBUQHK1F9xP5G0LZz+37jZABv KYNVzIdnX7RobNkpmEEinoQcckbDHcHsDZ9sraCPZH0d8fzwUvnrTPsmPNHNh+QBO4LoHXFlmbnB w34lmY4T5ITGEUmg78Nxyfr+e+MziA4R2yX0q+sb2or2pYPM9f6FT2aSem3n3CED/CZKpS6c+WtV JiECZyXct/4YUxrOWnJWPTLXQb9+E3XcAA30e9hvT3VhXwiftL+UH3Xfjv/5r+KCppmodHCZDMPO 6iwTQWQpLbATlfwgauv2277LKmkYhMUSapqeZK10eG+d7aJPYt7l9FuW2gmnfi2vx/j6M7Fxr+9D sH9FCvvEZcyzu+MnNdTB6JgCv/Iwlw76FjQQbUv7VZt0pK0M5oLr4h8SsQOXscx00rbwPXphLNxT tl6guzGlckiybezxymvGOoyh1wb9WLpTNdl0s5rZcIDoR3fNgF1WGrR8J9zAs7f0HSBkUyt/Q8nP HBq4zI2IMKHdY5ssUUaFY6mM1uJUpQ5J3jRmlZgSa0kj2XUvkQtsVDQNjpuZbM0MhuTxklVbTmvV OQ0aE2dd8dz5ozys+MRyHEY2dQDbXw3VHcAhCghyg4WJzZkrwiIyFkBt/NmI02piakunupSz+KcC FotDNxmPjszBplhnYyBnMsO+ncUBXW/nGOlyswhpSH5dFZyBywfjdXpH93xrQZqm5/9YHanKDrOU muOoGEQOalPZDBfmkshSHGfZnjdHK5eGb+3ZqdPhDyWyrLibuRR3E6d2SOJKKMv4d6z0MqEv8hsQ MKbo/HvuFDjtid8QxunS0oQNDXpEozCm0/0ZF7agcjuokeU+N6t8pVUpCqTaLiIO6Vsxfcyae2UV qSKzrGNbEtQ6LK22KbYZor9teIiApDHdZgcJOqWme09RD5Tjb75uSxrd3ajXMeH0v5D1Gt17ZhRr L+IjLNsy7aHBrzYZhtANs5YNFi6mRW+VczqzmHDRX3W9If9e3ECa/GjZU5g5zo9CLpsCEvwdaHx1 DoLE5oD0wv9lw/LUiFM3MxuGzBeCSGfHPtNjB8cwZwscyPxWKslh91G4WSFd1PhKQclQcCVrzbNN ppOj5eztsOq6DHfWqnrB2YiClmdtxil8AeMOgl3Yq4hEXX10q9KA6o1A6ri3lVXMnOhMG49pbHAL jS8MuEOp8lRiQUqWb2aHWjQmpyuoRJfrX0PDT99pFzmDKs2Mk7IwyWzoLBphvUFZuXTBjHCmKCBW kRLdYRNaUIWog3ks2tc7tfJmhuW3FnEtLzh43VK809AT6H3a7Np1ikjsL7aoOU14EZzcOTwPa+6t m1le7bDH+f0T0BBMkIPznvLjLaYEr1ItxI33WTC3aOKRT7HZW6m0URWXfdkDf2Jb9i9PMgETZgB9 CmKwYynSPx6zTdd72dE9USkSh8WcBPBhtmPxxah722AxI0sX3C8vEd0smH2zh174Qrgzx2UWFlGo CEYwpMv3go632dtWApHh/CoPmdSZzCKnN3sbaBg24vTVukiQO851hubBizmshiBVD49SPHzfAJTl 6YhrcJv3NoRymZR+nlmhI6YsBoOBRLZ7dtOUs/i08vHDSm/WJ2LI+Qof1NiKxh5LFp7hDPhQ5Rtr plhzC4TzNYsTi+YFFLCCiFGsJmS46WvljDtEkWl8L5q/euO40NBAAQSfDuOk6WtCw1hmXF+TxnN2 u7NPKHblj7PwUQZHjokxookXdNOa0tilqxONjK5ZbCy2yMOtL50yGoWp8rhq4Hy3dt1lEFUV0TIg clDjcxllkhZMZPhhts3GHODxOiNW8gBcTPdZxPddTd3eRRr13J5kuAEwvevIBFKCN3YOFwQOlmNq aWgtGo3mA38PEBeyab45urJQazBIepmY1GlD7Um1ZIKDvz2fXFDEagXtMyItfPYZxwcXIk3UwUvz oXM0Fs5URBc4jFz/AoMRtMg7YjognUkSpCN23ZRgS3xqWAZOBoeAKnbW4WqJEdGdrfTfFBSLHM2x CiC8QqxXs5mQzp4ZVyvf2Jk1mAdNVwzQnP8T249fH73Fy0hFwGq2YWh0c4jsOqhEiA7osga2nGK7 QDDDDwL92bWITZeALBm6IDI0TrrFrZ5ZbOQP3ILwXsupG4PFyhrrOm3Q2YgHpAwPOj1vauYHmpno QjhLiuhIcwD4+X4yktwgK1xgkWo+hN7pn+3wHL1JQqA6amba+20TUFMlCFCAi2FYF/34gclU+ijk UsKFU10TPfSn1Gqq2B6VeU13RrdjJXBPKKU6zIqCHnaky8/yyvf7YbQKXbTCJQSHMbH/FVavtprp PWJlxFUi6bZ2kTQj9M8DGkcLkC/5vWUxe46CqZHuXydfbJDW7m5lkLqO8H9fOqLt74JkFPip3jQ/ pFJNuPK0DtztH9ziJojg1LGiF5H4MbD7Ep9maykcwoqcJEdT5J22so1zPl8FiX9YBc7LNW6xEZL5 uq9lpXK8IR7ONQK0o1LErakrcPVO1Mr8wBj4FsEAjc/Vpc1LogXbOXHHi4mOb6iOjs72rgvPEscF xlHHUYoV9ESyc4drBG6r9meLxwFzz+Ef1PNtGqZ0HAFEQHrVk+dHpG9g7VrpN23PX8Y448daNzZe 7rpXjZMHMu9s/PEmM3kTk6J/GkIX+LFLCpFSflU3cAVg0StPvlUtNbg2/H5VwaosIJFLgrcO+bvQ jdMUz2Y54EI2Ww+KNTuPonU/ODH4liX2wTfuqXSFU31ftyLUCQELjWHzVg2tN8ZaI+y0zWT933dw d4almlc6k/SmWosAjoy1X99wisIlzzuCx8wEuYvJTJzBWdSu2x3eEt6HJGeVhlfGzIMCkj8MmgpM ITigpNP74slJrBC48Iq4IMyP1jIjXRpf0kUGoVd4JwwTIeRBq2jGF45qIZ8Lp9bciwLJHSbqKyUV DC/oNynOre/iIObkdANK5UhJ380OB7JCNFDa5xGasdLbvuxn/mPYd3Dd/BFNdH3mMJTD19wfbc+p 9TXxKBLkBrTOT7XGnwcsxdAzb5sMVmQki/slsgpQHAocS5sLhHoJVHdw3+fPKBFb1R0CPvHgqn+C mOnxQzWlyKyMU16gFoUWbFg4+ZHy5LRCI7VxiIbU5xV223TBLtE0Zok2ypbCQfADclWDQWyciHyF kHCR+cV/RnnBYivxHPtM93UgQholsSlNGoGmI88sGM6dWTo0fT+3dldLHrGOnLtG1x8VPTPj4dPq fZh3GyMmAZU+BOO/q/kieVTe3homgiNW4qh4yZLDLa3dnJt7sdPI9wsJcjLXRaS1lupVWo9JGTSO FEBvdSxPA0suEfbDvoG8GVyr8EREEqnHthVh7laS3XLmsJcsLDBMU+W5Jjn80MYoUH8aYnLxXOcX GtadY9fTQckz8382k9tW6Apybf7JRi7bU8Miu9Mx41v6Xu3fLh42x84Q17PEBuPupGtxEMDTyB0A /Ebr1EcIcjFD1XwdMY2IsYxrDRgKg1VmRIdbWQcmx9pVRx25mD+Z3THmCSTI0c7kJ62l9AySBpqy o9cKovlHE4SnGlAj4GkGgIPsOFt642FUBlmAb0bMZNOTqNp2c5D10X8qPkh+0aJZS6pwrji0CEEX MfO31aEv2hNjuM1AUlvqeYlgO47YrV/y14nLJhPeS060zO8rUPHJQ1VkGKTu8V+ubp2UcWfThm1B ZyIM9axTZej5hIp9zWspG8EGWKCwit+lq2vK6AWt6tv153xSQFyb8So5OOGyYvqC8Dj+xUVm40pG IrNt8QvH1CMdw6rtpKwAbpz2DWV/QO8pfWwQUHDQnNtPWp0sHW9R0yJNWEY0U/JR9Rt3rQAJQPa/ AILT0/OR2tY1FpHgzRKPwoiMxPL7GANNb7OFJh8JXme/QoP4LTV7Rw8vdOkxAkkZzw5h1ScMNILB l8z+lnkZluwLlgG8p0KYRzL8uPkJ5xk1djrqnshlQSvHonktevGdeREaO9jECLtFsMrSQxox2Glc zxnBvljw6npBsDSmEOOV7kx98R4pzZEWCD58u+lRKPssiqYY0MEl1mgcumuN7y7JjnohGiIMF3AX /uqpPC+oNRPfF6htk/h2Adlo0BAiFUC7OtH1Z7Sy5o1mEAhZc5HqBo0AYG/ROW9P+wtnf7+mfQl9 x94yEnX+VsL8c4FX0bXHNKXNQ4fKYYJShk4yOVuQXcQnA8II4m+Vg91qT8p60VhfRuA9R42X1soG Uj03gcZHZsmkVn0VyMiZAlxJ+GMGP7cW7Hiq8ua81mXRSfkdTUYhBBCHbnRjvy7gEPhzBA3txb/Y QP4fgzRxDWKG3WacCKVCr5Q0+j7X7e/etqkTiVgn/EZdMveKKd2mG0G/4gnGWtm7+339zzH+V2fa ue21sDbQN+0V2inlK9L/n1RmKdeiWAQqoc91q0AeWbcckW8t8IKzYSHwWb1AfiGFoPpwPP3JAWJv 7Lf3gGU8H3rECq6GJAbXldlHjZz5+7+Er6eegIkLsr6Akd0QgK418O7CUbEUOSzB69wGPmITllCr 07/kjUA1+MPEN3oiPizEFfAi06x6idVZdEdVdyVzyDxegq1ZAV6ECz/6WPoWk+CTr+PgUN+2EuYL Zs+CuEq3BfEFHQg5d3m+mGXvp+M07mW4NxjItkFtEiVwy4U7GxwE8gS6OXEVEHDFan4lQG0n4Zqp zZFXQj5lSWOGw37XbGKNBnzmPheaBRCWH5vhAJtvqF7WpH6a3STkzaXhmSje5lD0hyW750/ly7yy E0SuVAYx3nJaR175PNRQrQ/RRthyKhfv4iRz2Xpzs2UuR+SFUCrD9cTh+F5Bq4EVUNFpWK6I+mQT IAIpbox2BURsWlZPYmrRdttUycpT+Hw8nzdpaJIl67/KoqXh5DQin2theeU8E58yks09qVBwTAye BdJJgm0F2t87UJBvFiSafG97KGAU/b5Co6zbpqWI+fhB8rLL68H2QiP3NcWsgbzwbc0hOqWKBNoQ dkfocC9CpXlN0qgV4x7/SJqcIELz0fgBZ5b/bvcF9Fl4mwuEJsSW4X3LfxK0tJ6w+6AjbHiBzmT2 u89Hx04ne4/yOinkVHBlA8mBQPM7jiHcxBArtFdvJ5WKumaxi5CGox0oabvvkHKN2n1ppzzB0SNr yjMLCiQl1HENDc4G24Wv/y9ikk84gc49+w25gSKPMELqhqaHRU2Fgy/bG0fRI8gpWbKJuciZ+axX 0VBQuVvOIFClSbQ5PLiLvSC68MFk+Zw06I7SIdZ1oFg+wzTQCshrXVW+9oQaU7D6IipJDtsKAc6D vgNJkbKjmFXiLbrUvRgzb1g1nFGiWvkw4A3ErvL+u/OdWu5yT8bUfJnvPCMVzeDXnRVnOhfiiK1f zp6l2c+czZba8/jobbvR9WS/qLTIxSFxiR44tszrHCZOGVJT69mYsipYw5mfNfbuZXHB61hcZG6I oKnsd0CIk51UIBFOumFxUgowpyEug35QnfFU79sIRAEQYvW0fj8ijwDrs8eNe9JoEQAIYbpitsfQ 4y/X2Lst6rFbfViEX3wDd9avSdPKt2mfG33CEoh6nkP0U3Gq7kzr5kcGemn0NXmPr6HipDqrbMiQ vsZNKHiBSmfDldZx5Yy0048j9Klvze/UjmzNV/NF8lFo/0pQv4YfSOPj7TvXS0YS8uBz7qdzNM4F K4GPfdNIBFKTEu/y+XLL+RiB3PtrknKkRfmwrsQaSU+UBewtiMWZd3TEPpqgqXepQn+UVASQ4QK3 vCHQG796euxDwASYL4DWzPZ+mJU36iNCwlJEBkUXi/T4/Fqiw32gT49FB5cKUukCqnmDlPoUd64N be7P+NgcZq/rC2ZI1HFmhMRP25s9bMj2OeiOPeUCUxl5N8LMm9ZnMachxOHURUXtQ9VC129RIfNE 6IFqm3RjV+35lhfKUdQWUgl8vVtpSjWW8UDXnpmFkj7qk/hSReY4Da6ClpggDMDUnAb3AJeJ/KpE 0VPiu5U7q0+8Cngv1JCLIi53Jip2VBuyWRrsw/a8hsDrV531oAOXkAApQAkV8aGD58lvk5AUZPoL nADR4QBl2qlaNnYW1X5vEuuO1NiEGAjKcb7uSxanI2PI6PQzbcMNwgHj1fL5O3abs+P5pAbiHZQo LPAX6fOIIelVm/YpwQmxQOQZXZFxsy4Pb7e3SlHKFWSgKdtKDpSTYodDGYz4rAnxtG49to4kRbBV QyIKhmXEOB2MMl4M8VcBgzFhvADgedn1azHmsLgI0NHCI3g9IUsgbxZyrqM0YdUz34ymqvznmyXG 3v7pteUMyI/kAt6CdPRROlh8pTmjnFIxJVmGkJ/2RfTFUGILjKsy23tN9FakSAdkFGCv+t4GEcY0 qbiv0HPMdJQLNYxOrXCR4RWEYX6T8GQkNL6SZH9WS8du6F5D6WyP6ndFp3FaR3DniULvAxY2G2gM dCG08JQK5GPQjMDEPjgoozr0FUVafMib280MqARAyn+Z1vLu1KYR4SU+8LVJ/feeHmjtlnz1obC1 Db+ZTsiJaa2TgyG2gRiq4a3XGItSqiQx8ckxERqyelBbS8W+r2UxgsQaQWpANe69L1vTm/dU4lNW 8uuSbyqFmtHjvKBTXhcYHyiL6xRoOgSINtvUCQjOYjQMnAFFS63cMJszNo4iCN0swBxT+bLUWc54 o+bcF4eII8azucruH/A44ZjFqxZ43XlM6vLM2vWOnY77J9uldJc+xvlxFm7eAND789xPPReU7M7K lXvgw2jQ+1FxCsRMWQ2nGelHEemH5xs4X7qMyiiHbgqP2LbsQp0q1ah+hQyp2eVGME916EOaay8z kRAhF6MrVJIdUxKe4ihgd1UYWoTPDeFV7dSGmz/jXqi4rVVFKZIxUDYWfaQnLcFmJaMesata7HpB 25abguLrmFAL5JzeTes1FeSafld4Af80EtzwNdhU5l+1QXtqPmqt56rJj1wlj6BJZ/nUZfHqR76p Oo9A0lIK7IHyhGhM9fj9ZFhcogHR0shmJuwuyEIkWcHQdktMI08By0V6li2Xq6fhWJy17Y+2reV9 4daO0kjjNjoXaQuUSwXdjy1tCET8djBdSe+Ixi41bYqoGZ26s2KJCOyh256ov21MHk/YGF8Lwbop oDoAzUEaN9R10evrKa+nXzpt3TcxcyEi2VreJC5YQeXFcu8t6MpjemoeEmynS3T6MjhL1zBA0Hui JREVEKQTWODOf+eKOqATnhcfhJ8lSllywF9CvOp+1u2HxUBKKhWL1W53nRxeC+H12LLL8cAur+T/ oCe6QTq5/gm7PQusCjSVBN+T5ZCt4kH2sMdOxSiUnXnTJabQWI0rX5saASKy35h/rxhfb0QH/fFz vWF7bVelVs0QBbL/clZ+xBN6BLVMTeQ77TZ+B9d9jdpUhNsJN/GtYp0gIsqOwqX3YuQ44F7ruuDQ 500cO0KtbRpH8L6eKKA3tACmRxqEe//VRKPkOx8htafKnO70FS0eyr6wuChQNSwSz6BUN70BIRq/ HsFuefE9L2rR6Tyi4CkU6rpnkF6N1UVKQSwTVGDQyi4vC+b6Dxu9/zrISxGVDU1gOkY/44gv2FY6 fD834vCDLOoF8RjmqowsoQgQ6KEnEyxvZfdgvDoFmoUxumssDwU2pt1t4zQkpcpfhbGiu+0V3i9L /1V8B/3cE+nQJqNPbu6YW7qOPcvqP1k2YNC+Aso60BHzO1RmG6JuuiUp6kVxP4EUpY4iJS0L1XMu Ee6IksNyHV0NchnY+CyOXMRziYLcUNoTECb9C/S7LY25X0Lo+Qtu8Eh5q3pQa0aZGA17zm/TXOKI kAKlY68Q2tUxxFAOPtjFpoTpFhua2VUQXW605eIIEDN7jM2Ao+9H7fsM4ZyqAJTYxBsevXpMDgeL SLjdfdtZ9eEEiWE/2ruzK+b5QPelz9ONr6A7XZzsAjGnpeROf1QMNoZejsw+2zF2CnmahlisXgCH vwSiTByYz/e/NWwa/YtZYMM8y9VrTX4WvNQXs89cxZjzy0i7CtW2fgHplNjm1bphKpLfr5iWe7WN rF6R8TvbVGT3LRXs0PkFV45sD+sAMxxbSIf9SrRAKJbKfVcwRXhhgzn14SPpVAwMr04lcigNXzH0 //u1QNW66I9tS8CneN656z3WnH5KAIoVAVBydBzURdnJFcy1nW1C7AIZ05Ik9g0IerfR6WJkmHq7 2LDUGHil9BaGUsLEwPnRIMPIrUZ4LDHFdFzaqEFk2WULPRLLm6OoGslz4wMXg1yc/MS4aHbctsJg m0VbKeY50TK5lTqoKAAHfc3NKhwyEpR8FbeEFGXAMBTUJukg/8KFKzAQHJZRR2qFndaHwYlEa45p 8SWL5x01FgP4/LWwhgIkxauCwchpfspYt59lCkzx1Ar86WwevwAaFPI9NIEjCIXitMelX3T+syYa OrUHbVQ1swTWrfiaX6/bEA3ly6RMl+isYSFqsEycwOWJjdpLzyvcqRLsiJBMNi0UTZcC+J/7/Xu6 UnxC0GCMlnuMjoWDhmKkhu3xhDMct6huikZIXpQqUohaS5cBqgPk7Nz3LyvjxxSTn5sCHboW4WAK wvusl2KjbO2tJDeXCr8SNnHPqvfV8dmaY0zYXPg3iCUAFNGPjtsSUnF8bqftaXq8ze7De9Yw5HIb 356GcNxWF4krQeu4GQt8icFKchqj4E100QUml4uDpurR/7EKt1Y3Jmgg4+DZs+8PFZCuj+UfRXpX VJBe+mHHVmVKQb2SHRq/60sGlPYCJRHfkpDXEzp1i1hDMasz6ViJWoRNU7rbHEot9CyP8/f2FOkY I2V1ZuPfidAOT8S9B1RtxwauyR/WnoX/TDJnhmIhk/ujvh4Hst2cvTEWrEYM2ah5UObNi7yySB39 Y0cVe/dwfB1JAQe0CSsdZxzvjF5SU5DNj3MV3d08d64sARqoIxeQy1jhs354P+yjw+DDvM9Jrfr5 LZGv+Qh3qPLf3zwABYYLtktiOipkWxiOzGtox9ZMRd53ovXtvO3HrRd81BQVuvhj5nn3zoNqjfbU YWoAMWAyhD6+3tligpdn9lirMdlvJNfwutqh9zqJre37yKRJ1N8+qT4MVsUFFWUB3pZAiaQ1TWn5 0G7cfLTnTKgJhS0089+R+K9GTJbbWSxyBoLw9Q6Os2l3kjjuH26cDFC3YCRtU+Sf/2LFWDpp5xps JFNr5Ft+MYBRFVnvTR3JIRaKwkAtzLp/V9cnk7lfqfCucNlfj8YUq5x8YCcVyANvWGJTO9DWWEY4 ythIXA0u+jt0FC/8DtWbFBKQXJ3BEoZHOrIeXHZ5ppapSrTyweerNoHj3ZGJRs1VDhGDrQXv/g7/ QVBFb4s7I6vG3MG30Fn3SoUy7kgBRd+5nbwxT1/SmBEuxcDQFMfZyrMahdXCLQw6sH21ZZKTwjho QwhZIr7jS7IlXIggb0pQgRpUd74SlocKtmxqW6bMvgF5VXtA7Lt9aJVHCb5nQwcavymqkBptvDzv 2k0vxkAN8qyEbM7AWXXv8XUUraFrxOLNClm5eLoCihlUBCepnpCURAfFSGEpMbT5cAOa6CYfgEkS Pr4K/fk02vBOvPuy3WHihzcnHEstQhcy1kK4/vKqyt3utDvgCV9GOpOoDfpv898jrPpKHZxyp9tK 1DhY34CK34KQCFpSfGE/6NIi8U1ChtDoqJRMdnK22WZeXHRXkUHDHpqPRugOwpA8er621MG333Bi +KFmNbHT7qAHlS+FKkNwVSZi+lhRG0Y57jkcPsAFzvl+OhH4jXMM/9JWkqAazUC7Pe/6v6WFZtUS IXxgsDXq0K49XAT4NEJZy2wON89yvOBVmC2xlsr6NmIwY4sTSZfclkMElAYwWPxRwP3kscTAyVaw WYJaaiih+kUa9bSHBHdC+018aaQPvuu92VyFpL59BTWeQpbUCdtsPOhpTpRWHbVCFbQzd1P9dhcl kxA7yrwZXwd6vXYFsqyKlk4/3YUlgRztrJcs/A6uDnrmR8Ojirafh3oDC2t9b+NHjyRKEYOteNQt Fj3V/mIb1vuGYsEy63Dm3EhUEJprNzB6OSOuhY+7cA7IVv+kAS7KY2R4XvWYpondJCJcCxKb+NA6 PElA0ZXn/kp7p7vXPCumxGuFu0yPPWGa2h79wbV9Ih3fTsRGr2gt+91pHXi4aqkITpeEjCDXPlOz xvhOVDV8eHsxas1IMnMkVby6l2TSHfl5Dya8ZebZ6G3NUUkssJSz/pX3wfklLTrNdljbqu8dBu3q NUTkZ0y74higOOdrcP3xOBvXFvzqSyZJ1mRoJWPsOXpUiuSA+ixbil0AGapX3y1fo4WSnGRQKn7H ILEFn5RXIDeWAN2/BHjbN3sOM0WBWSMAWITGGdHxhxV1GO61WWt3ziEUvp4Xks0V4bwMuauViMe0 lbU++nX/msvzt/l4mMcFDPsU9QxqQV3KodXHLTFSQEf1IILiFuzxTElC77NB48HFq9YDTJYlDLD4 VLYUePZSVP+8A39cKX3HlCb2VCt0voa6cSlsZlFd9o8JGImyZHUe6OzfgPZkIRiEnJSjNJ+W/atW iP/62iiVqQymPVhDJyTaxw6g4hf1Nfx3/ttlqAjochgYVXF+63VUoE0N8yfD8In6cE7TUaowz1GN mcH4HSUckLUxMoGRaL6BsYNn2ixObl/OidE+nDlMuYVojzAxvdNHCUAfnwqn1b55YCOcAeqrZA3o K+hnNWwnrrfolRI6h0isqnDXVO/41FCCKvRhP9Vk8zKg2Zv3YTEHhGrwVrsDM5e2w717L+y3Ce+N JUZuS1vw+KEC24keP017FMChznt1UA7twl5u3M4hXcxGI+WpXaY6JCzlHb7BzK/LDVjqnK3zHBKB 8Zh59SvLA1NK67xCmJEigQJPSiTtYoW/DEC7dhq/bLGMNa/LcLu1xVXU3MSZRyzcUEChRaNbPAAD 2/c4qOgt71/Hvdu8tn5JwFXA0Uc1NqWTgbVgSRUI8hXSYSJXSTx0fP30T7D1eITeUcWiOulSn4U8 BJJREDBmX182J5aPDoQtUYTtbrJXlUsGzwL/qvicKX+5+lvQdzAmIPIxWX0dcFVv/U2UVfDvaImH TybevSqrrEZGEgcmWVMtltcy1HbvUH7LCwje6UOkPcJSu6uH6r7XnzcWKqpfTPHb5YaGM6umB/Zn hCdu6mcS3Vxs7WB479e063xL/+yJ3UnUVMbodE3X7WyFvjmlmdOlxEoapDu+lmBYWyQc8wPevJLO 8joG/k34nd/gKPzQb9YR+A+M6GcnPHw3mSGwHfQQZXU9lk9D9ppFuu/yyr4Ue5sruRx0qaCwWw7j kD3jiNC4LvK9bq5QqRjj9vRKpJ1vlTwBeurzBO7awqEpySTIq/BDZWrAKYlsASbb2oOrYFDK0SG2 pR8N35mXtVsCHr+B3Uqwx/tFG5gOzorXRdqLKMumrmDDbd0YZK7e7jm2Bpiha/TiR6eJGcY5Pwj0 i+M3v7tjKkvoRTK5efgNESytbOqDVgAguciCoOw9T8Z8tS6amcVZPnHFke9XvWMDroF7zIax1bhd SqEByxYAaJEOogoNtb96zeTRjZGdvggNpUD2q+hsDmObB5fKb8gF7QRgw0x93n5AcuDmlWCJOgAP T7VWxgM5knAHm2EAbiHHLFyyd6iKkKN5PgqvlwvWGy3mn0wOnSQgYgAg4AStPZUwxMVDglWXWRGw bsYBHpQ16NTiPRhAJEjLrhVox4LJOxIp81nJ6AufOCYvw6Wl1oFhzB820258JC1BxjTr6Up8RCTw wkkMTRJWSP0MzQj1JmkE1hi9icgtKNONILIHURZ9t2wU8nDhY2gkBDlkTIvhx0Gi389DNC2V30ft kv/hf5/NI9FFZqNNgH0lkav3L9BkpukoQQJCSCKPhoLoUg7FdDMsl6LxQ88kcjMufsPeidYg1KSa vQRPWBQuhtc0LpQzXbgHEOb3/djefzjQqGITrwopWPm71CR9EdaOs0IObv3NgICSwf2ZaPdh1b+w 7CJUxCel4V7XiW7oyHqIItRKeOVKfx4Wvp6I4daPNM6eZqrssCu8dXLG+qbGTTkHBAHC8VFV8vP+ xYHVqktiF2ckhVQfGpUp49R6r7gKc6sCeLzf5Jjbf44ZzTW/Kb6wotBhQENcndqcBygpJurAFwXG iu3xzY86zhghUpOHY5L9aZ81YDGa+FzEQaUk6gwDHheEfcQgPUtmw2pqrHZXMrr97ZjDGSXnc3XQ wAMd/RBE83GLGBpSKlmdRghoqpIUF81BojcrDEsOjnj+3hQaRC6E1xfe+J1vzJ/z9OyQURqGDDp+ h0/8bR4aBd4WmaI6wBxWe4zizNuOMlWevy9MDNYSexnSAxnHhXOw/Ygfm2gcA7G7e2/7EJc2T9Wk Ijsr/kyU1FacAdo9p8kbAgnEV4GdRbL0bo6rWUXAFpNOLOaPHyX6ojKoDVMqc02/kpn0rbEdIW9w K143C1alFAEeEcfLus5PpGsY1JB7EMcVFRRcukTR+JJ3GC5j8MBV8pGrKMHwZPknvGxEeUy3XrBd WPV3utSilS3W+fs8Bj3a+CF/o889m26VFJ3mdGcMZQVoQw61yCzA5iOrgLpvk4AZvxO3chIpq5zQ i+HF2Z7Gub1ode8ZkSsqPDFKYM2AK01gRAUbNOJ0/Vh62CItEk1ost7bNDD8giBZTL70wDmHOFuU jYeZ4TycOpUekVAwqE/VTxl4bBkP4svzKwTbTHmaPrzhSUC13/NWj8DFQg/3m/A/2VSXV+mGIlzi 2xQiEsXX0WAjL/C0+uJjxF5CrzBQ8tJ8zaPYWnqiz29BfxBG3QylhZJuP7qwO4v4/mO2WGFfjUjD s+oXJVcv/gnHPRW9d3K4Da3bNstN+gO2lftjTgZJelJ2hAgVpn3H3i6dgB5L+IrOAyfetTLDNqke ukq02mlHac3inMbH6QnFbO402hq1TQZMr+Jtt0F6Z6RJWX0nQ9K55Ic7j70gisWBC4/Mwm8uV6T6 TLoeuADMz+ybO+IPElPuGI/AkjdXutdZaQELHfmjry3P2JGo8JJypwoJEJjFNZ3Z2ejl6aZkyoz8 XrHQH7dPBuOvbEc4Y2TYEagb7a9ItnQwI7W7LgWRieXmLCeygJWQqGkeN0C4aUa5A1Vz5pQS+2DO BTb95q5woX0Ha2is27wHEkTaLlrTPOUoVzcwVoTW+EjOdm+EagfuUuV47T4kiOJzCrR3dkm+9+Lw OxsU/OU6FWgZEqmp7cqJ85KWFLEZNsSjWeV/9KBrdmNeFL0yC9VfAbTiUroVzEFacjHJ+LFN7uoC VV0lJYbYPK/5DH/UOB+IYPLp0aNW1OHhMo+4IimT0/w+gv79Xtdq4GAmgXDU/rf/uYdsXZui5bKj fvIy4Dp4OHkuTYoSzzGRSxPRNrFKQhpeYs2eml815/g0p5pFAdaEy/TBcYHyHyuSV3dWkuQ3uvZ7 jmfBUPX2sRaCrJQfzK9VewI19S8qXp+gLHbimYD1uYDoeD7xQ0DvbZAgPXa4FmB2G7hMc6+EBzGD k5+pNr5o1A4jXYfhUQ44Chp/9qYTj5v6Xr01JWy9bIC1v+nEGZKSutz0+hyA92q+4o+qUvKxwcBp a5ruRcQDzRFihi7zK8qIujTfAJxmiK0mIkuI+pnrwMBATezP9vjSogoAx9/WYu2fmAzlMbya1mcS Na/H2ECKLWLL+zVT8IIpzNKvGJAItLO1yOr4yf2VkK0WvWBGErbo8/NIKIAEmt5HBEJ54fyAuQu7 35hDYDXUJrXcwKI4e8Vq/u7vvr0XwX0e5wEj42xQiAihvntE34B0cpl2sm1vhhgEkBWS3f+sAoZF YGa71aW3PBJEZDo35AwNuJkZsioWVVx3Re556iLy5LdojeRU1hKf4AgB1/2Op/Vh8aUZxPxo6TQM 77EYxOElcbIm9K+V7ghdL9imoOIwUCkdkr0GwAXBaqaez/lOoyai68hG5oeIRqFMY7xYWdfyFUAK 3KbAgJEOfJfzfCg7OmT9r1/jZWe9/BJSDISqb7ktYMD34LNkxdzxjUF8wvHvvxF/Jgl0emCj4luK E68pncKRGWMZvfzRRGkxyQ7TcVndqdhfWmXxUFdADO559arIpRGOsrH4/0k2I95H2JzbifQ0wfvi GF7dDOlZ2kNuK4p/Jx6s48prLNs/q9lnbmJeL27cy1B0zs+8NcGP/PdXs7LfhNjsudioMtrJ/FcN VZlYFZQ0ToakbsoLb5XWdlwZk3/9Y6vOe0ouwEz9HuKaKZBxDOZLU8KOMWivE0fxXY4/reMeLRfQ jfeG/Nh0x2HBmK8LObMvBgAjR0cSSV0biYOfNR3uaMPtQ4BNsT5fh2txI17fkcDxNL7fhXxiroBl ARlCeAtaa29y3+sAAoNTcaIR1qIFLGZBpznNI1frD4dTjoPDeEnBFE6vviE+LnOO4szVHGG42AeS n6b/hh1huyssNwTJs9WVq7ZQBWrml4P5D0yjw1tHNPtpS/dqUgEXQ78Jjuxo9s4vLuWyHCMtg3cF qAJLVl5wpna0k2nbwk7DuxOhhWzqKRF28l2b7ZmrbI7NUUTQez5lAwRgb453581l3JJvkQO/+W3I sg87wFyx/eBJY2V/d5f5DNMlWz+BhQ4mpsEIxu1JNFRsnPamD0gF9EPab4e8B2i/YGUiELcnr/4S E+Nyz7vWSbUdgeJCTTmn995pox77s3/K/OADiWw4ON1FQGJUzRwyenz2dQiphZQA9o4bMXPKR/Kz SqDWJovIz0Hc1gT8mBX2zU+KJ2BWC+4bePrQ/X5U5FwhbCRlGD3FpMrWfd9u4UZs5wfjFBQTE9XU QOzUbaKRbJ9BOmdgnD7aQJ2IB+P2VqxG4I6qkisPFWm2RViCwbD64xDP3xWHg+l8quI+GHL7mfOv KoMnPeCE4fizyi/WFN5yQ2n6D0EEsG6vodclUMhNgTBIyeJAPSsofZZzG7py3anbPnSQH/1MuvxX oN/Tps/obTYHBkdLjlCv0p1HU2m2Yj0Y2XX0PXlBAePi7z6ElW/p2A3Vw6dVH9q59IOZXosOWYEJ fpwVrxql1CNNi1UHY556ZU2tvNO1JeztBWB+RM5z92y/m8DV5EoXqP5ic5ENEp1OpQKgQ/wA781R ZG00yBh5K9DIJMZgGrQ8ihlO0CFRMLE1KNCkrHDpB92b1Actl/ofO3Q3Xu1ie8RdWAXl2CSudr52 +thGNIwIAanL4CbmrccDfRJV0rW9QscZZ8W6C2B5xX5dARC8HvHK7JXX5FCPOqYoayOauDTz04re mc3dIGnrMsow0o7a3raZqVMJHJmC77VeuyUZ3ex2K6SyZN5Jd0lvLyCFQ4kJUI2JfaLVH2g/OiKj 2MZcevqWL3fH0q4nIzc5Ohz8P6WMRmhAowM7N2LvvUjRADeyZr5iVMMJyMQTfY/n914cnZxUfYUf zzRou+pvXl4wEUKT4d1bQAyObNhcJwJS6YRloJ6MpPJQdEirKTkqOIRPD1XJhIlRGLn1iNHfEujA wQUQzRO/2VCZAjj89lR8o6sXgYaF7NWs3iLqE3Iah+h0Q1cfSNL8oaax0BJbj5AfagQgFPoZQ8Ar QSwG+BeqHjcpFLT38M1P2SEIXg6tJ18+ZF6AsaD63AdxnTCSAYTqCWEZv5XqHDBxoWP9H944e+D6 oe1s86zIF8YDXsRZ2vtCGIh/aLLT0ybp2Atc/dI6puxylk0T85j1bbnpc2NRzV3zBvmMIe+G13wr 9OaAvg5WvSQNMP3xDkGd2UHvs5PMMHDSzVoEwbee/vXagMhfMBIYTmCVp2GCWtRSScBf2/relUO7 jhCT2yzIoY7ornSrM8NWCSNjcHCSqj4AMFkVrL/MyDGFOI5SOybmlv2h/JHMVOs7lEo1wnLgtjDw eplZPhk9FGGHXeXSgKiVrAXuHxYF8TfJ5dfY2vNN5ABK4eU44tVVTOOZsTGfAtJIMzv6wy8voyRT rOu24xWF/Z1mMGFHoCt4XFu2t46TgypErJSOTRdtMRPuolWzoAx4m81df9zfBjp2ezMBQQ4D0iMf +nAFscHL2mjMoZ9TVs9pFbk7390ZyiRuI3mP27Y1spvasNjJb1xKVUdCnTQj7kZKzwaUApPgqWdd TumYse8SCfCdLgfZwUhKe0z8/9ZHdZDcuLRwVHvoP/Kcb/AdczISmRsLqDAVsxhUOhUD8TdJ83Hc 113cbgnMS7JgZx/LBd5y5MDXi7vcui7o1qAPbZ1ZAgIwRpsY/owsjMZvSoOO72wMXPaRk3pyK3Pp b8W3NmkU+AgpZ77LJkU/DOlZmhA5clF0cu1PrEKnvQEfEz3pkTYY92BrP1RDF+gdLFBbyBDfjhM7 JK7iDbBdtNNpfZb+XcO9cbuDJgF9zNOdLzreatufEbtS9MZA0BLb3iV/vgGycLxfPtqMQ9eAsK2k 399rKzwua5nAsnL/xKYWqhXEFgbeM2A5xcsgbKUo6yv3OmQHYgZ6H8uoX8lMwQL07d/ggGWJciEu /5fmmd0b1JQ8NSLfXlurQHx7A7v7dg/p1cWoSVTMTXScEaDGgpYCFsY5RZl/Qp6N475PeWQwYXfF kQQehgpvGo9ANd0LPEzQVfoIqShVKbrBu5poX2DNbuoO/38QLYA0w0onrtTeFsg9fl7RVtbjfYH7 73HLjgbcTq+u7ZY4qEQ9MX4lyCPIKuuSaLn/v7qHHBDajp2+BDUbkCYmMW/iWCC9Hbtbu4Z0FUmt /2UWsvufc/DOmn+mMa+QTPGz2yks+Lz6nRntpLSGTBBbbh6lkTEwvVvtr98PwG2KTaRyvq8AArUr lsGjfLjTbLTaOKJLTzFu/9cKllOzaslWBb19iMNAdpjG37qkY8ZEilvMo6b5tgudZETzSmn/8KZi mzREyxeq5u/yIaoJjj3UwS3bVKXLTnyXUO+N3Lv98rIn+QYn9bcKuVA0zfWPKzP5tqNQBZQqLipY b9TSxrnQa6Wb+RUqtjmIsucGqnM4Azt9cYihgmMtdHZdsIJDWidLseT16xOINXj6oP3oO3NGDfHc XxKjzFNx194wwoA+siXnuEButC4s3ip8e/1D/htZjujGkdWL3gSDKHK+uM/7n/k713Y/hiurS+CB Njdu6snkGE7RxLYHfGgCxIsKkzzyGRYSJ2mKUb3fqjef7sIchC8xVA5kJHdUb6q4b9pdSbFOFLZk dJXPUPquG0VlHEjOSKjdg0m8pB+tGHwRrZ1TGZ7I9N6qKp0FFetNQqKyYF4pvWJ530N980zVoPOm d4NfOQ9Df6LPtaJHale2VKI3O+BtM4+WDntQaWHDIE+PLTKXUbYxKOrZAH2eiMbyJtgFeQLzVqiR a18iwv2vaP4YUNDwjE71HvtQEe6Dua2Loc9XUqlT3PEX35xHwGq6mRrgjycsEN2EjWUQG5IRZouT UsuITP5VkJnA3/za3+ga27Nrl2LoWL3ejvL4At4+TUiEzKcRE7rWdoJIBiPlb4RHVKp3st8vob64 wLCOym5yjbmngXvq84QFmnQqj1SvuanupAlGgUyyJbF3LQOOP2BAz0Q+gu1uHKE/4S16bm6zJ3qY b6pKhpn29Dj8u3WIehgkc4oU8o3cDC4WXHrfOkzrKmH6B3W4HBrfkSgwk8NpAZ5Ofa7GAvfy73os aVj3l+ons/U6cFx2TOr62t3s0kFpRln9sfpZwUvkYGVSM+U4LTLKG/WijnVqT1f0IIFv6V9uloCe /MrkWLO/CtE91XxcskWx7vyeSGa/2J+exXaxA+Ih0u2me6DWWWOFV83GSo77e+pzL7nNhbKyQS45 0EnF5cVS+lkx1Z4wCrw4Sbx2hBNeAqzKA1ticOSCov2LX4JhzvkX2nDAbCVNf+TH/pz4d62xJQs5 PBIYqSXl4L6qTY+RqppXHvcNyP5LNeFdxlLEj+tk+W2YjLBT5dFLpPMEEjHvzid67rCPJW3Mo+XS EqfXGINm4tVxYGhHz5qDCMZ3fxkxN0KLJet2PnDpfWUrAibmVLrzLE2S3WuNlMxmPOsfiSEgB9JS e310FExwDEU3UMqUUvXFbbWpyuPnH+foMv0PC9a2EgqM661WqUShh4MDfrBCW8hOYd8w3WTAy3+z FXhp7nf2NA2dbavafHleEHCtwZ4/ua3uYiF9k8O6191xpqtOWHxAA1foWO81Ipi/y2aeEG1/fOvs WqOLuBWIYBdiyjqElmYtqzgwb3Z8q6S6IHHlP9NnexQ9/VKog0asIXdIOq0aeN4MW5EIyU245SXZ SmaCDXoOCErwD7B3UDp1G0kG4fb6ZHIm5XXulv3UJvtkoqqsA6qqAUC6PkvTEuXD44dwOD3aB3mC kWcrJ9sPwUFiEWWBC8fBY5lCWhluEh0UaSpozmniFQeyPEAcNot2ZfxcAGTHH4QRWPccdfbo0U9N SmQhIC9im02ElX1IRk67qaJx/ykvdr0kM7O7Tel1IWHj4QrYHAyOAMlnGRdTlBI3Fdt+6XzD81ab TCApF4DA2O1Y/MUdi8DSs+4+0mFNNvifGtJt3AYoWgzcullPGpcZiLzxCZt7wmiJbCfVFZLihwfo 9rs/bmOraF1Xv79DpO02zvGeh6+ttLlyxSm7iISe8Fc0mFH8htPiG1JcGkZGSzxKFoKPEmdqoBJL 7EP0x+pFoFQk4j30aWNSMoGK7fbHwwnmWr8ITJHE05uSrwYEj/nfQy4V2INPGabTFYyk2XYPPy0v nq0RQPSVtOxqBXvdHwmYeDbd7GWChV/+E5g+H5QcaNmghfoCoiySqg6jTKVGmv95wQGtaRKT4sHq CLCowzF7vnnMSdg3KJZowVn9s9Z9IYQ2ZhgHrQyASyTisk85VUXmM08nXfRYuBo3rSxBJNcdKA7T z3JV+bNuWE1GBJ9S9StythLusvZxUesvFLmCu7uXQLbJKELWI8TIoVVnSLD5hiPnPvFKhfKvIOrt kkBWi4SZJCv69VhYNUu/5BrA/af80l6H9zP6jDqwelwZmlIrYXR6+vCK1t2MX6W3eohMnPI2sJAu iMrBiAu6ULbVF+DPQvda+1bTObtV/Jqfd4+Yc+SQAGT8UBmZ93bBouU3+QQIgyideGatT3DNyP0u Dzc7jubhipgJU4/7GWgeTMVbGx9Xic7yYEDSHf0QtQZ6uf0u81vCfG2KMq2KLRQA32+T2y7tA1zG ggWxXNbXrFVP3oG8MkMHmfsMWbejCVXdvJrKHg0Cyin1UzUvYtTkAOzqpd3mWNFHYTiaPQNq1KTI iB48LFahzKqIAN2l1YcSGAktyaElHULNcty23leiHrgJ00ZZ11AasS0A0C6DAEREtGRc55WM39TX hXKTAIJWOuLC+DPrJSOgfsb0IuN2hq1zf86SvEslhbJ8ePs0xXA4eiKKjcLUmye6lhrImveOJ5Oc z7/ep//SbhJrS6cujAMd7ULneYV6/fs+LV+L1Sq9d9UFEE1qo4CDiqj5ODXb9B+OM/wDbh/QrJyD 9IHkX+UIxQwV+QrcKj+/heuHnZG8nEGsA4jZsAKKJ2lrr7YOfit8yAGm7x7By4/b4yJH+XAlKURV tnpTVpklqjNV05JX5t7ng2IkgLNVBH6Wzaz88h51fLV5kPEcJc12f6dnjI37EjfmonSrrKCBGsO2 4uzyty+KhlMmnnr7FB8GrFvU1+882EunBWdhfnKPdu2Cgej0SlYCXAyJjiLzCci5sIBVCEwKPYKb vmTo1vls8/HT/zoexozrduQCqQBc/GM7LkyllQI8BGyI111+26cuFp7wciBSPmQoZ0HZCJ4R8nyQ jrH5tdcOETVj2p0xvRpiKxqiX9qRgEXBCebUGvqesHSwgJuhMvx/6/F3LXMCVBTWKk1cpeyiEr7k 4O35Q/+XaLu5oVb/hQtUiBl2sYM5S3WCiLVg6CKC/8k0/dxkJY4efENpOFiD7sCvXRdtL+p10+vK HxLKz2QwhJb6OHbYmpRSFrUmtXqZu5zp/zOfn5w5lJIC0mttNrFcHnP799ywoK19NkcAE/HIMdUs ndGuQdOJxZmCM2WLxVzvFg7aT4+CV8fxBfpIEb0rLKZNGZonaMN4SgMlW51e46CxM+ae2qkRU9Kw Tu2oi+ZQD6r5R8d6gDaD3UtWQUB1GSP/pA+T68/JKd1+i3b9bxrhvP4klP9fLnyYuS1Dp0KXWydA a6sJ/cQejuc8LHmyxGriVJ+rYXdc/J0MvZ0WFw3ktIqBoQ0qEvjiWYdpx5ptJLC/zXArhh6jOO0D Jc8//9rQNC57EseouJh5vx+CNUNN2ePctBit6+1boBcNLPnWpOqfjh5ZzwRlE88QFB0ncMOlCsC8 TeUS/oz1KRN2ZATKmqiDSLqJ/0eUgeyGtOR4lSx8AsiJ4bZtZUm3slKeFm+kcYss0XkzE6DcSYoG efuy/YKkLjts2mvEBDa1JPLTdwi5R/GVOd62FaO5XHPS4XWSjSJ8MT1aVNNGNr4p/ZhFetkDYuWd S7NXXxdZxvL7oyFB6TcO+57M8b3TGakdpPrFAANZiJPGaRNp4nOPD40h/vef5PNlIjmxFCk9Cv4P MbrsacYGsYU4R/fzMF6yuzqlxyzy/1GIbzS0qhCBO+yYQU4V/fMlPe2k8NMXTrf/YNuXMytdtZfX Ppsu+ub/n0wY2m00aMnvgc/hCgtPXAiQGDFEkVr9yemJqkY6ijgk3ycnwf2pIsnBwQV9M0mq0Jd9 10a3i304BZCcI7x9sXuTa1le14GN5qnYrBhm0q/y30S8WrxT04DY44HDPHsUVM3VOtYzJqp0FB3q Uj5ybKgsAlIZmrUXlybhqIp3XW0sCnClEo/RO6N9cgyLtIVZAvIzapv+VKJUyokC4kvERyQwSHMN BQszRKHtPUUke4vMMN168XfUgv+MsBTdi2nJxYnDRFF7AO2lQXVy29lpW7mbi9SgBMNr2UE/b1uC ztBx+YaHbLtFAs3Dz922q0JyBxWsRfoyDywso+mUm4FqFm52n9C0wyp6iDGm1Gyh8lCz5xb6NtB8 bbOEgu3Jm0603m6t5XvIJzXomF7RKnpDtrigzwCotyBPetVldz9x+GxfgpavO26li+5KHFCmInkT 8JPMHLPkDQLxeaRQqcbh1eBBP7WYGSvRtOPYQ7Gpz+Bem2p3G+7lSp/1U8cZgqBG3w398ZSzFUJe 6vH/lhavkJ4dtZRWB8EQSeG7qxdLpBZrwM6N+e+eZEE6zVb8wdCVU5C4+U/uAeakPxfp1pAzQ1Hn AKAPVF9KOnOMg4qLNgaY+uLS8spm7dPEHYQHuKn4IveSaM3E3xJM7xgaw5KxVozcEmSYQizg/qf4 YDhIVsdXwJxKMSz9jIt+aOTT80TSuTr7b6jbSfEf6Wwmoh5COccGzhGciBkRsxpOyTT2D00p2YHg Op62XfZ6VD3ULSebundxXGaoz/SHmwtiyD14qZtEZT3hqUcmLS1nFBKZLC/DXgcLEoiIPEl0wJ/y iE3eQyUQHXu3nrUWurzhzxl/8cIOFr1NMWCfOyoqfsqr9bqD+dctdy3E/vNcOknaktuF0FGs4HWH X0KfW2k7gN3XTNiCIxtnSpsVTBqcopW7/HDSSvIreUtKOyfh+o4pixFTzZkRxYOlmFqjJ2Ojnjxs 7n1ZDf+Y5tiUzzvNzX6sYcI7pTT5HMZS4mGG7oLHmkXTMXfhFyhViKFLzurKvwQF8Lb/GX4Ysesi ztOOTEBVq9WITL/9JcxQEg8I0yKAlYpgyVArOiytGj42c/TGfk+/f7tMK30VqKLhLPp/pQitqV+F 47h6guNGkQhBLhscJDR8v0BdOu+x6KTVTkTXuFwMdq7ZucZXJsROOiGlTwSaf1U3g5BqHztrP0vH yMgCqa7BOWGkzaQSWuPodoXjNk8AjqLHvPUxbin0WjKw5WKAZLbV/5f73ujV8PKcQDR0TIf2lyRm bwPGwIQXxGJpuvqHRH6xiBCfBPpeapLAWwU2kudxaAvluYaSWIJWOmBvv7XTlfJvQLeWc5+/xyuh Z3wfTnQ6NR70KHhmwZQT3DvJzewReI6bc393CEKhGblqUOfNSv2hsINbzrZtM9OeE/ptYmOPGYrI zpEhs8CcDoA/4VAq9WNa6iO5lDMETuuMFHn5W0Jpz3irX5cnO1sZRLebji/z+o4eU6gxDMAnPG6U YToB4cseDGxRY2qamRgMxIo2L03f/Akd2l4r7IUxet0l7UWWWfteu0ZfGfSsG/eSB1AP/9qhwcgK Yj2XE/Eh4HpqwUZ8ZPEzXCdCelpPcmKaDq7EKlBJUi+NohWx3yDbNULDY5mGnXvOGKtUTi6zw50Z lh/zVOXu2PXr7zsk1njN88zJBjar+VVAkHjyapiViRU/KSQKn3WoEj4h+t7gc9uPNFbEp4XueWB7 2QzYhDOkOJyIiRRRMngbXid63MW09m9NWaX8z/AyR3mLQm0c6ekl5n/PCR3ggyXwWVz5jt49bo2a jM+mh2vuHLi5/RsGXLM7/4pyYwnhdiRWQ0Os5CaIM68jcVr6Zv19BTd3+FrhaujgGM6xS6dSS8Qx Kt0Ypi5hXWseaz0nSPu8mDwrJy4gRPbjkhxSQBnvuCIVQ29hkRw3Vx5x1zuMBj4PhQMpInmaIFbg e6bEfHErqYAShliu89pG9KHikFpVKbzRYM7ZPRySP21LoNrkM//kPpmZw9irZlS2heB6QZjY+z8G 4OMkyHxrUHXzK3LJHf3DiPnDO+UGQ9OICONIK/mzV2PS427tHYUcBPQpj1KhJ/tkyQjyVA1aSpxn BhLbIQlH7qezuYlL3so0pmbtahncY2zrxs87sOpGW9TGLq6II4/dPvfMoNdlOlYYeLokalPbE0Tn 48tIXX98CsViNjLWjPU7ux6mkQ3+tvKdU3AIZnrKIzqs/UA365sxOIqe5vFWpgBMuWtgLrLmHuuz NgivKuIf+fss2nz+M5ld5Z3zpTAySzP8bGt4f/PX6QuUK4CtP55o8vBMhguvqbPTLEKT7Qb6fZ8h ZUIIqmAhFhGZ9n/Hdp8dW+Z1JKnc5pFzHOlUu7yTcp6uJk9+cYWzMy+vweQAfO4brcJqkU+phi3A /p8EgtkvpZFUS8vRSci+K5XhLwCXMXNXp7IYr1HxMWUV8v9X9NYUJGqCmxGMkIxUoUvMZbOILBXg BnDhJb6t89ROH6oFgR0M1p9p5AOe8I4/4MUBPPoG8cAUqIIfgCFLqMIp9sPkomZbACQNoVKGrZOj 4yDDEiBeXNo9mgHQQTipxxkfuTwfvgLJoflJNRA6OdyPVRGeiH5YIVtQB/DUOzBXE/xcwG0rkKwe iFd7secyetUGmFLhd4XQ7v3Pgu7JfoRmDxmMHoWJwEX6eeSx2TuWQ1Wi2HlqhSXUAsZ4761hYWgi BusDZr3XkTY/9TYp96k/mI+yye1mcmacaYYXJ6hDNpTYqW1LoHZuAsu9wpKKZSqrYuqWD4csV5ke lUxWn+7QMG5ZcK8dRWi9heDS71Et5/MAZmZJxwS5ZnenOWSy0OeE065KO8JnRAYfd/3KKYg/Gbbl 27Gp2RLVenm+p3o0k75NFTBSuhpnOhR24RTzBix/ohckjE3TQ2viaeTAOjzr6CGJox2kJIwW/mUy JioLEc4eqWZtgm5yYxYrmIJVDvPjAkAzRjzkgAGUQtzfCgFSr9HHGTMGXQ/an+R8DtXiYfz+8tyh gex/MGb9du234+APYm7QsasI4C3DHyK3ybKq0Ogrh1HrLjxJ9sTGhL0YwHQvA9/2zeiVAYg4d22G 9Hw75r5us8/TX+YlMK2ZEFDgL8p7JDMhFROwHSVSravyS1m1vzggtFFurDonUQmpzfue8MvEmW5A 7CWh+qhxemssLKE2+KyTnZzUp4D9RnYd2hrcwXAxRlDXueLzfFbvUeyIGYuo7yZo+boteW9jGBKw 0WHzpWpVidVt28WxQUL3XJ5ZBjDPt12AtO6N+3u0sKu67ZGdBTZWawl4zAhKWDJ+WVMM4UD6y0WG DJbyGPs1dPNPwjX4aTISNaFrraGkARgL79LVA5ZMCD3eYvfungrmrbS0iuhUYppgf/u+FSGJWQeQ nOwa6NM5nldO/kDtp3pNGcNcSvDNmKmV6YS8FYnTNSgQOUFIw6S4RzLvzOsfO/lzMZjuxdqa4VPI lMJg2cEfkx25KXp3H+DU5Y9wxCAy+y4CWGYC5BA5ByAHpK3qp6Ctit2KzbyUV0NauxBm0Q573/bO 1ECghchoUlTRIaq6DQZaF1oRYt/gMCYFjTy2RXysk/cl4Rb2RvlxtwQmiQ0xR5IrIqh+OIzhOxtW 3mrxTPKtJey3j5iFpTEyb8rmx7SeGTZaNEMnqXGJqm1A6F+5HlHZI82g16Z/iyJH+n+RuGnY1oaf X/fxDgYuxn7By6aF6cUwZGiG77uI7oADQ2944Qt7NDZfz/fYsJvbWwaSuv/01j7t4EBWGIrX/aol KHUGOrgrh8KobZlXCpNRobmsvDgK6KJV91NQN6BcsY3bHzrpA4on/zpxgXh7cHWgv56Rpg2QAva2 NXME2aCVq3SyCzKVyNu8JgQUTpSIHwiZTYj3n3XQSSR/w0w6eIon+bbcsyX1KGBEPJyeQ3rhWuZs GAnb54AwJuBgT/N7+QKgjLchPpWEMVUUE/+e4biQf9BHHJHcWu+sW7Cprm2OR3NazK1eBh6lJeI8 uQAaOzABHnI+l2is+PPvdP0NWQvweSs3W/KXG5QAwKDDB0kAe7DT6xzNMdAkOmtP+P7uWWDVzv+D dca38ezJWXyh91pNsU48SE/Gzt7w36zvB3oINA6IbUUX19JDjMNyA2aAtwVysDlvlGimfu5bhBjz MOPh2n7ASgBbC4RRx5OglhFRmtzCzSjdn5u3qUI6mtGTVTNOmK4fW/XPxtPHDg0txnb9Pjt9YSQ4 2cXqdNhQPx+b6efk2gDQLK7++yyczu+yG74XeFWN2+1WamNwIBWjlxTsNiGQWwKOzFR3U4CZxf9E KILpGq3qLsgGX6696ZTXZhIoLBBcKNpzFPW3XlQWSjWRLeiof/EctEarEzE05zSi2G1eIf/obWr/ VhXzVjG9Ov8Bhzpz1hhCy75qYcUS4xi9HiM9J4wm2/xXGck/FztH+faTczYOab9PQBWJOVshgUEa TvHMEKeH2iLXoWskXCAvMkBu0OziAYEF2VgRas7mI4gMTKhvybIFe+/pQaIl6f3NqPobR43QspTN n49CnUrv+X7iBBIvuaXBUZESMQ470S7nNmbg7LOGElRqmx+EbajmFMoPSm/HF2vyIeQEkooEVbFu BrNvQGI9yYyP7nIbK631mSkOAMR42033nsMzQhQFp8Fv01P0RRc6hiAaD076wtxo2Gb49L9CRG3Z Si+ebOeEy8l7NIuYcdxBytrEczNRh2XotEPYtDPN+W5D7mJ90NoM2tuTwFpVnmntTjRg6V1HqX4i aaZdROuZsvFpLmgrSBKBzpz+mVCzx2KNvTNaSemH5sNfO5zZmXZUtUA+xRf71eRCEN8IYKZHbbk7 rvO5Vj/3xH5wkRQ4E+JUZ/c0aEf5Op6qj5QPXxdR53UnaEKUxdZn6tKuR1/VsYAyOga3xxgb9uzx L4mtfOJOKaUXFEWKOP57SRG4PsiRXnsp/1oCBqz2FfZj9K7HhKqVYeqB4BC4H7B3fUJgoirFc8Mo hXZ/52daYLYa4j1UfyQfHkfqHNkp+ZSy5goC6rT+XlcD2twvRKBz1EA+GOFXzxrCrQZ/5UFsj3OX VBBY6PRuI8HOy6l/eSiF78ybcnDcUF1NcTOVax9jgr/JPe25U5BoQbMu2LZt27Zt2zZ227Zt27Zt 27tt292zz3/PxD0xM+/zcr8VuTIrV2pVvlRFYirPdd4J60yIloZSPBd4zbZbQwDjuYPxInqUvSy0 6/2Q8z5R5YpaSOYH/orrCfLTuwRAZIWbqXwufvqKmLMJcchSv0IrsSnw6+Pzo9Jm74AXVgf+lstg tJIxpwjR3NEySQeMa7/l4HsIgKFfaoj3hadeh8e1xLvzEjh5MoMbRephwB+M3di5RomSPRH7xdv7 3dmI4ckJBK5pjI55crCUH0Ki1mtWPA7lLj9brFXvV9U+d6IUN+pYhY7GjJsJ08TSC9ko56pkD6NF MJXza8db+B3rNcmDc7O82IaemgxdT1suUMzss9s1E+GyvM4shnSox8MetWptzP3aByihE71Ekqza y2AdCGRBKZYbSHORvQ/R8TSyEjWj722K9z7rUcoxiNSk+VeXtwdL8qH68D2sNrr5r1s/ED/ArQUA wUDHmHPYaCa0knIs+15M/ji2hH1OgxNq5YHkjNYGBnULLisxMEpfIzdZh6SqfE0/vRlluDkggmrz OC8wLvUifQ9K5PZ/sQrFODLd4dTcJY2N/8ZKVVLyiSynwpx4Yw1qS5Kg3nlThrlBF6xyTs+oaepP V1OAVwHl4HiOt1uqNGZ/VVApIQog32+lC37U4K8hBW8uu0l36zq48hq+5NAC5j6KhkE7TzrynH7e NJeuIARd14UJ2dwqvs0x5vPllqDHGN8faXg35VVcQj+ZV8Mv+NpF47WsQpK21a5hOjKro9fqNnwm jreqy7n9WrjP9mnyBKZ6Oa1oZiKLaS4gyGDDyOZ8j2+4xastQeIgwEac8nJ3V1TGeVZc/oGAEmw5 wf78hPJSXrtf/0s0mMgU5y/Y7Lt2VXebsMbPyXBC2aM9uicue51lsHnjM+iRsms/wpFC+0q3cgIb sq+OSsFsg6e+touB2cwWxAQYYMzVc3FcpcSE+xtn1HS107LILd4yJV/JTr+aHfAQa9hSIpKp1p2m CTqNC+pb8IYQMIFG9V1Do21HsksYScS734Keaqga+AT+yIj3dwwm/YPjiHuXeAMzFNWzujJylrDQ BwTLDhXzwM1DXf0mvvAQ1y0g/nAeVW9FcuvLhhCCXg4MAUAURH0Imracg8MP2jAZocDJaShSn6gC S9okXU95ngjpS1xdRT9WPfA4QsvLtU8bOemBnYlBkWZUN3uH63YIz/f+vcNdW5mesaamcnmCdOIA 582gnDNLuch6e28SPeCo8O2LCkWPajL8gpvYl7bbX1MU4XeyfVyNtUX0MHIZnxSbgyhw5gZHW0kZ EVyMBiGEqiJgyuLEF95oyh4DgWjpENoEbIX62EDFqySEutJXOx4cAAu4pz85RnJIO2tocxAmnCWx pIOTiwECCIz+SOrk+/nLvxALjBQ0arCMcYH/acsLq69N+36A8ArXVMi3ElAvcP+dpszexn89y6nv Yb12NP1iiqLRi0EyyOtunrPbosuYNeCl/49YqAd52CpUb42zxc+GtIqd2mTohm5nAmXJ2UEBDnIY PKcZ7rrdHlz/qo39lb/Nnjg2894pxtmjOiQsdTNrm9++1yn2DkJVbUmuxRSGmBpZnvLRnGSUEZRm 1Jwf91TpE5BNWrwsy6/T6cqHyUBxuVHUU2zm0kEwDteOnj+idUGMUF+SjkFKFjaA/HSrJEvvCrAT z5jsWXd2+CQtlM2j4ehAxQ1ch/9N5F+ocZ9kvcNXvG4SJu7o8UdOIEXOzZRQYaQgBkdV5Iay5/tl h4B9F0M54Dtt9lZIkMrS8uLpBsK6Te8jGGIK2x0+C8UBP3u1r0GJ141d7qp5ayvZige6v68ZospG A4Ca+bqsKcnqIpY+5/VtkjnGHB+22NpjZ3C9LpFunT+Si3H0IabUfmC0x1pVInKeGYw1VEIfRF5N 8go80d3hpz1wfioeIoHT8Nqr9mS5sG9kK7Pd4FfIYE7TvG6GrJDY8sBQ1PWbZeyqdfDBonBrDlFF 5dnvELkkrR8LuvEEd8rCJEtBp5vOmF+u13+3NOZdyf2mOA1LOhi2gjgSubh0PbaRNh2VSluIFiIB 2AOEcx+5gC4U4MNT+pyAHvbbpDOePGT1Ev7kOOW8KG4xOWJRxdE3032ZIRJjV8Ab7cIsfPNBtJzX jCpqQvjmn7hdhd9j9d+7NcVSY54H9e8G9adF0zO5rPvxKCkO7akKShG+VRLbnOtUS2Ex+FX8vT9P VzSxQh3351s7cHL1C91GNbUEpDQUnkii0tQLtfI7qk4Uv93ZdFQk2YXffze+hqpNmsfvDRdtDyBi THxniCPEmvGepC0/L0qqS+W5u89m2AmxpIfWLmY1VfDY2WA2iXXjaS3nzv5+UqxqxYPDFDGrsZf+ wac1USb/BDEdHYsWNiZxs8KagH79a9jd0dzknbP8QZzdILmGs1T+hihKT6V6AzqEQtrj6yaN97Mu afTObPFyd1NmAEWrQKn16L3fHovUUrU/SITZpykUMcWb78yjenEZMFdCXIKeUb6Xum3kprHshqZE /uZFDLAkilfYknZIa2waF67bOYwaY+fCPZcWdFc6Ve8EaqAp+PJViENinZqiUOvULJe1dI/Kxqvd 6TMIStS/xNmlUjnHQgnlU7nYLXJ40cJ/hqlP7/JoneRGVN8HldzeTYOS+LGD/u/IbMJtlJ+YtTxW uUcY7mj2STjjxMT7iJzmarc0ygjVmgDhvJnLvp42ubc02mnPqazH8CpSsYzSVgbjuDwcREIQSpi8 YMntWDTVTu9Ci0uFgSO0b3SMi8hPS1p4JsqDDggEo7L2kmDzFbA4icdtIfEtQA3HXtyb9OxuuFVW YRHQQWoCKQQ7UlYhgGm+1LAXH7Ze5u6bnZ4C766J29OovRoatR9N8wJfQihVbGNDBTb4cysribTK cvU1SNUxnsTY4To8Fz4idEYdzRWz55T6wJuPA11P3tm4K83BoeV3JWX1sEsGGUv29Lgz6zPFr4Cp X9Sg383fY+qfAiIeA6QSLRrzKry1tzTb8R2kgqei1WPU1qgYBPfbql5H+kghdyrKOT0hQAkAqf0C DqnvjLlk02BJ98K6RVMe2WcbWcrvMGjlKu8GmXDPkKvb0XWDRejHjZ+dLW+GHaetgy1m5v5p4vso UQ8UU/PO1yPThCzgrdVJL6ALAO4oG8ie/ny9+OeFGJMKI9Fv2bQBNb94oN2owVuiyRIqvVMdaDDq 5/PbSxNcqioFEdBFaZ3T/20o2UMaAyEPSChYW33K21Im33ZkPnx72APe3UHCAFgyZbmjx55EH4KB XFd7Gj/jYFKiwgbQCsLYQMHhGRUdWYQUZAWii7Wjfxx48DM9ZhhpCYJdPUyV61eMEq0wi9Ty4SdX CyeUGC1JCPm8dzynN9nEuCULbrHKbXfwksZ2NuYH3MpHKpcXWtD8hpf/zzXc2sLQ8bT7tugtJvHo vy0PGrunFXkeKLzMen0vw1/OjlVFO8v5nRwazgTojd0qz66EUa8vMov/QyTJWPcBbG/+R1nh1Slq A++CS+d8KpsCnxoHSdHtrnAIxfjWMtkpfHM2utFzc/0EtJlajJkKF3mSqFCOmXmc7dsa+ALrfqKK PsNIdoZxgBqkC+kXZMzzGd1r7ZZf2XVs5IWyepRC8Ubh1/ArNfBbVNRmycbfz3xBBnXjPHlACNr3 WewcGHmzPpBGvL/pTrCRe3sqW26ZZymAGbDGm6MJXiAH/veKXKxtzO4p4Rkvk/6vXcCXujugXb3B SnnHFXar2PROUrA2MfA2TfQqubUmFFDN0aexQjkjtD7kEV0L7d093AKXR49N+F0HmxSDFuutXA8b FOo6OMu5CBmmxK9gPcGlhJJnSOuofNhZukybMxawwHeto+w5ihU+xh9HYaQiOTMIAiVQjFiP7Kgv vt9u+OVXUKZvrchYhnMjitG59vLYChaFxdkMVLLWBNVIz4RVWq+mvzGz8hdpz6aHhH6Cq7+YgG1j /VZFV8El6ceEdqcQfqGkPtT8pqpaGe6we/jZjBMbZG6srPJxyxlynSnfuWyA6Y6IR8eSC6XnMbYz BtAdEvQfbHIjPWyWWu17jORwcE3toaV3ZetRftbnDK6gWIhxfsgQibzRSKOIeu5JnEyVrsylh6+T SSmDfvuTpk1nTyBtJWQtf7xr0z6aVmFq3p2guQGRj+oIZvP3D+XwM7x8hWtXcDt+5t3d4D/IlInU /PIX31vzg7+wggn2iF0rfRJTaK26Y5VkC2hjx52vawMpRt/LG+uMnejQnOpXEtUYwh/Kr7jONb4h 6bLa8CYuJVFSEx9wInoudb/dSiQbBhBqZmhifibNCXMG4W5nfESdlPUzM+tFyytIffrTZInRhXeT 1awSeFGlUYSZ2Ea5ZfbtirgplePB+/4E2vtDoIO8fZlrVrEw4iJkBplsDh8GGQ1wmM0YFY0aoIh4 qwB2dGgneSLGiYd8peAzdGDdSsE7Me89NKMkNmbHUXINF740nSTSFYvHkt486+BZQ8boI7jD6rk3 b3MY8NhalIz47EKYoKxPiHOqwA3xnR383ltmEU7LkR9J3lzJWpU6DvfW1TSnkB5uLMbepfaBtRs4 ASLVMwHpTYCdSbf9ooSpi0uNcR1cqnI3bwSYDigl9bNVIQ7QJQI54lWtuP/1CuzU7hwIrB0avc+C T6LRfrrCF70CBmNXQqkKPNQIlpTCpTGoGSEoEuWGdmRd/9o5ScYVki/CgtTpK+mYma0kr29LoSZB yFd3/EivpFijz/DarC+R1fD8PF5stVLrmzDCil3VxE7NhoIi3Xx5EkXz1AII2B30tcPACeSubO3f pTI8SjcqMY2n1elHaUfO+6RzNFnQYIDsKsev+ZSK2UPh6Eu0v4wHylhUFmLLkj3zfhlKIxWJcHaI IQy8evaJbDl0ufSUFas9c4iI2aLhUuVTq0HvGrmAEkKRVBIS2lX7+aR4ADMix7JAOZfbKZWD3l+s wBCqAzy0m8H1A+eWzvFOkxBIdcXuHDAzsZ6b9Z+QjHhp8Z3gUimBgaSo4uIpUyLPp+NCif17Gh9I ekdd3O71dqXyEisnUTlJf6o0rBUCTF6z+pLQ9M20pbBgFMBeYCxZT8+I9R7OlNRD3QbYTUFJPO9w bjEqWVtX53VSDqmt+aigFhYPq7KzruuB/xQpZkBGJkYnlPAb7/4pNFy1qcAVxnI2LtofoUP74J5u JNGdc8i27Qc+CdSp1B/JwzwRwx3Ou/QisjC5n2TcNmf5Me67QjMt/5kNarKjsYIj1enKjnknrg+3 Z5LRElctDPpCJuEYJTiJgwg4zjJ+5/swhmEjoy+w/egn/6F9nN5SR46DrjGkZxIV8VuWPhLarOJ8 qeq2GbFqHssYY6qH8mhqx3xWnDtSlj//p1w2IXmAGAqoe+D2/my03Sbg0yIfYRtaf0QZXBNLHGhS mrrtLlOHboEslFMfnDZ08FJHa6dqu+bVAgc2ekkbjJG9hryW393M1q2WPl66W+sQQz9MozPNYzSi LM7zxEBB20Vr1P8NY9dfnpjXHShQpjOCltdj6PbQ1QYjRS4xreT5Q8UZuE3XF8TXvlNYHArT8TMT vZK1iLK2zc18LFkx2wboWaDBIW9YBVAXgwBfzRsYIuIq+ote/6beWIxQaTzyCKILevno3E68ZCl4 HKS5klg1SJTU8QbRRUjCuN8G7d59ycyp0Rtp8uPO17J9MpF7m5KVQ0+icdHvlzLlxtHx0CMyR1hx H4HxZno+PlIux1B5L+hREZGkZkss+LA50rAnBLOd7tlpTe3cDFj6BHGdlRx3a/3ZuHxRcvbi8dd9 mhFnT4p5Maz1e6QmbU0uIJrJ04O+bb2UPE6TQhy535xOuINitP5kB85TRZWM8WdjBDeyCsXFNOCj ZJdXOWpLvFJR26xRcosVvJROyg6zLpZZYuJCjuQ0MPEifX8OaN6uwgQvHt1G+sfMrtw5WniiNGnm c+ff5cGzEAGhWU00/altQ0nmAKy9ocUNKDxjleM894MkwHExWXGBfFU6gIiVE3fiUs1zuegNIYN9 qDBQi3y1SxnfL1tZ/RuSR2XUKdf33LTFRQSDQ9shEhP59ugPAjscLwxoa5nMcJRwAmlZ7vPwOfOh WdxMXlp0Pe7PKCVue7OvLIJ4IcPMsOKjl6rVp8e8DeuaAGYRR7Um2QTBRvrFoTfMQ3Xv0GgCSXTA xhoGZ0BZz/Pr8x8qsT/wA2Q2qA6IC1UV7anPHZ8orxGK7OA8v7qWf1+qmcGYcItLBaOajpBBt5uB bWWMISpbTJqhieiQoqKetbnyDQdRmnAfs+uNR3cJlfyNnimX28Pe3x45p5/RWGCMu8FX8ioZgJWh Y5FETaaam8EamNN/33iBdSVvIxP8qWzcIs4ujx+hf9qTJlyAwqNkOkTbW+JQ9iMrP/pX+OoNfN/S KGaCmSxOXjjHjgo6qSnFeqnHKwWO1fxKTEYzPToQfKJb8+NSapw9KmeeJzfr3FWBz7Oq4vTKseDa FWjSu3jpfqpkjBuo5DobUtwDrG67Hpdqdd5yK/o3q9yCk0gYS5gZUFoEqx75MkqfY7wKKIhpmMez a7dWTMyMZGbEq+9kUp95QdtQ31MTWyO6GR/VM3Vfb9eKVrNjsy8RZ/2uQ7R1M8VuvEVRrD1AL1/e 7MfVvVpxP0BSJRgLlki2zsq0J7AmNiraZxKteRRxRdlxG5CVIkLcQzqiqxAglArLVu4iEfZMw2nn m9y99mCvyaiMW4feXEBRZ3ztlO5V1qtniX2R/YiLbXLAGmVyUBm9E3sIdDQXwoT5o106w7Nfvilo r9FewlG2gF9nDc2HZeQNyt07H9QF8zcgDF+LCvN+X/i1LkEXOLaMUyG77MabzCNfK4RIm7+sURP6 4aNGoLiNtxzM+GXNgjNfrETTKWrSqBiyFmXFEAFG6UlILQ5kPDnruXx0kwEbItHk3IW1tNOStygi UNwyA4ZLXiQLTEVMHyUlWEqLbD77fDzKXknracXSfflPgW35haT8bFZBl+uo/5JjEvaHFL78msqj 4LGZEODiHzjA8uYoOmKfPiTP+uvBkyQbzyma0B2AdnrtZOSSI0L1YMvxryCMyhTLh8pyB5hXcEW8 SvhkVKi20ptGigH4D9GOn/vIXiTn9JsNnoLDcbqUhllGXeE85Py+YrJB7PTGmsMCAxNx5o9OHVUa +UEKiGr4YUcfpoy2hLbWgDAZISLLXlw4MIbXOZg3ikjy1UDyQnX6AtBgt9FBSGA218zKIUenkDAt TX7JMzw0z0Cfm8KRp+Ju4ZOQVPZcJ5M/ZfV+Hl+62lugkMG0hHIaKSVr4uWzQ8Bl+lSK4MBozlFo 2BAoWDpF6ZCdiLKczhaYFkz6NHk1VCk6ZfZXPW1kj3hfVT7r7CSvLPVwXYwoMVJwr/h+XJFRCRoJ li7lpKhiu72QlyLuUJs9NB0tQMCuG9NmqPr0vHnkzt2x12+sZXaFzhfUBlPl8vRq8sOjDR6nGSmr WOTWQzYh0PQn6zgLl+EVOr5wTXr9qatV2J6CywfowH0UGSgHbs/6hks24QDD8/BAP8xGmk/yaFcQ GzMDlKnEIrHRr9FSwgOMrxnRFfQyCqySHDmf5Lczz5yj6Sf8uw2b6PbxxWdDA412TOYxbHNQIutp D+gGdR8z1FzRdHzi6yjDMY2v02lpw1a8n9DGuN3IaZ8TjCAUnJsSX6gJFTVQHcDy0eMhha0Ff3mW C0nJZZDx0FeDuWB2qR9YEONUTMqIL8ukPVkxv6fU/6v5fahQBUzE3N4aUS10MMa0PzCpE6nkNvfk T1h9XQbVdHa4YROG8HAmfeix5RNxzNS0HacOYKhvgg+SZs2wD0bxdF2WG8nWDmJTpNgnE7tcns65 UnD2MVj4oGhfj94A3nirTgS3+GC/d7yCHXMWdsxwKMmdRuZo13N98XLDrhxd4Bz2JxuikGjLuPnF 7wnijlwqrhp53cs/kpFA8LznxFI/4M/zCeilUuedqPOWT7RPs78OTwnyX6feK86x0AoBfyLJ/UGi Wx/Ree7pctDlJgutY7iUyC9T1saIaTEy+CSiu7Gj46EpS8KHHWUKS724m0eWNA705hMkQoP2Iixt EoihnbbW8xRhl4EWjTiIOYJOKKeSsPr3PlJOngLf5HvPaNw8Xy01guK0cYh1O3xwBITo4YyX00nW 3Q8VO3JL1IXvH3NI40ipOR/hIo+7Szh7lEduDIGL/Qfd+sA4hkS7SWTl34N0defGnjCyOPS+U5OP cr27xSY1vfF0JJ/Buu2vzPsQYtQM/YYXL9Spl1nIsIXiXMjCA1xtypijmYmsqfZ2+jjhZs0Y/8mR 1tYKUuMaOWL1rIb7cvJ7r90i6c8F9r526hHaguUXUdpEmsqeJaDPdk6Fc0aWBjphwtZHJKqjM1ff aXfznVVF3Zz0xoeVPiRHsvJhp4QZbwJ4ET4uhlS4H7V60XRloPSnRUVGyn3DYF66X7mJ1SqNeTm8 m6w1GJI4/NvtWjIJ/DUsI2tZFlNq2n0tL4vv62wYVGywgSiJk8VZr44wnARLU8tYhTxpgd2mXrUn 5sZrn1SXsjjmBbzvwyyAeTHjt0u7OHCFmYx+rgWzKczSmSFyCwPrMkHXGvgNShzUl8Ve0f0LGLH5 MfHMS0DvbmoVI9F5ta2sei81PBII5LH6ZG6Vr7ekh+2vJ+w+/S0SQJNwyuXvDVIGWJxA+qtcQYA8 rQn+eXwtOgj+oK32GneRs1yb2IRtn6s337PzZcGWxn5JKNi1UQ4Yu0ScKAGo9gEdeVTcZqTwrVXF PQs+rTbBDN4sJ/aOVTUexO/tz13HbnZSEOv7Xlyh1nE/IZZvCwowhQjrmMYY732gCZAe9IjQF0Uo k9gh3eR41+AjYC1rfKyZcHVtv5mCilQNVBx22LCi15xttk5ZUXaWbZqcB0YsVfxoWCcVoPJL0oAc zf60wcYWdRo63HXpUV1YOVyDsu5JrzKpN5lI0qbj2Xpk1wvxnEfRxP69O/q/M42M90MlK8enSznT 1SK5HCRl4+sgQQmlln+N5fYETzu0+4kKrumzQ6nnJ8CTWWQvGfT69oPGpBQz4LLEs70WyPseM5R/ VKfQhazzVRyFzxmOQHjrOnaETn58O5fJEiL00D1sLPJVOL4Zls/T/t6miKSx5XiIcFEvRHPrQ97k 9VVsMDQ5ljnXxyfPOgLv/sUED1XRLDSLEV6e9G8tZLcBZ5lirqEcBsaQALO03caLJfKoKMJI1OGa z54cuP+aly3eh0DQVESVi0fmQcCjbCUR0A3Y2KXsL9EdqoSHOGdm4rrnLm7b0S/wiksx5E9CJrub OvWz39R34HDP+AUm3IaAnjdb5HP1hoy1xCSEwqpUT9ZyYF52+YMy0LTmeRQZ3lC4bCzFFEOtbH0Q d3AMwuvIOFVe7gVHFjYApFYo2uao2lc3BNAXI/kIVMt5N1q7FWPCyuuiFMQRg5ATFaCsF0nQLph6 89EgqGOjIQVwtqT4+y1y47VMFel0xy1dwPsL90VZdwOMNy1GItKxMercOujrk0bX8RQkDmdlCXuo CrO0TOKYyY/t9+lXy0xMkuD2bNg0IWNwizAHGo9tjMcn1w1Afo9VFqEUh9LNJ35M0o9YvG+/uZgC pqBJSatl20kJkcaujXASicI7uyjoVilXENJpI4cIEC8J2VdkvQdAFpdAj5eYGGLAUwXhlYy04/kD 7uLtbc/5kX3z+PnM69W5TYeDvUT5HmgjV2q/Wiz1vRCix6+kchAkWhpxAjwUjOpUuDI0gUwsfuK/ xiyIsJIej4sVl/qyulRqhiPHd2xP+y2zleWdzon9vkRFdhn7MvzECSaleIwPKVGjDMsYojzo1pNL HGiXnMQQsPbiMRHlTlwZuvrtmGGvfT+47PQIJRl3fMexv5tRMA7TzlsrIsFW02pmSgeeBeN4NOxK CDh0Ox61ZRCYuCo0uMXtg5pR4qu3qO6lre4QoQ78wYt5aaBv3FNNcK9Ocm0CoCcmdja6DyaHpB3a 9Iw+auWVdZUb5+yfePx7sZpUnN3B1wd3Kt5R9K19a8nh/Ismkp7x2JFFn47nmmTmQQp/dg1sXg14 //MRgM+KSy8G2jRLKExsBYVZfTdJJY0rm5M6vDJsUrBCNX5cdLxuIkap0yc5cHjY+ka8lpijGyCX QH2HGr8lcIY73Z+Fb1JtEE/hsR2cko0Gru28iIjwrkhPtaNWca+2aAzRNPRhBZT8OgoyYrvmQ5ZU zFILaugPJaxmV6FKQVJ3ETm2wNF+00LMruOypRly34xZqK6Jxln0p5v8JXldI129TxjPwgr/tQDi WrMRyL/3qxYRMv99aMmsCtsGCC0XozA6nKutUWNTTIFovIEX8VOjAtDTJLtHmAy/ZQDVQAhc3JLI fDPynX9QCJVqF6ywdGaV0TQYmkurRPfNyIUxEbRPeMBSM6owTOgbleuvyd70ssnFkeYgi8S7K4Td 53SPKwlwfFV867XnTYT0O5yKjTf/qoXAOlOs4AN2PO+wiMdd+MI33SGuyPZPrAjVbZms/sA38NF5 7cG52bjvwMalLR61JbM5UORNEPtopQz58z7jfYDaVauCz6fqBY9pISMMqtpCfbEbkbJjr/fOVa2u 8zBoExX1i5yrfCEe8TBeHyMTGKf8DOGBlof38IG0h/MBij9aT3WEGDO6ZCKQ3O2Na04QZx23YhEQ 4KnDTjTLcHr72UynG5U2i4rfB/4b0EQyz9Q6zrCgaOWS/Foday+15Akn99e4rQmoRne9JiEQ1LfS cS24GPlPAadYVEwKg0rj50sqniqH9xrfzm2xHRu2Bc+vUV9xyy2UUU3rBkV5ikoi/svUw+XeeYuV Tc2HWJX240dEktbQNzSuhQZqre3D+IIVlztEUmx5jugPFIjuLQes8dj56w1P1jnW3PYUGGCiZPKY p6xjYTsqdRXLCpdCU3BcqixJP6WOVXwX3X59E4ZPbUXTVSgCWhQBPiVfVRHhkdOpPDwC4imw0yj8 DTblLePo9k39AqFMdM0TnlAB2aE37LW/ARRTlfLnNyecjD/13W4W+wTx+SpxQIbYob+g4uTJ2nc8 VL0JX42gSvxnSqnpqrJthTB63uqSVv63Mylt0QIeiZZfrc/EFYo6ONhyrbM3pZowusHwhOlqhLd3 8faOsqdCaQi7UPnGG0xm7AwAkvzi7ztCgn5wqgfndNQ0CFlLlDJ+7f4debmnAk/dJu8JiCBcPxb4 kiyMCkpOspQ4CmU9p+CoU0tlWRUWEBFCk1eyCMd4XyvEunbTPH+irMH0sDCb0LnJ7AoypCITLFQh EZ4pK/gH9oPB+xkQAADA2b/nH/SoJzScgWYIOhQxAQCiBt6c/slBo8wxIgHm/8vMnwFMTOsS8HwZ UtLv3Pzw32eUiY2Jfm9OggMpXAb9C9t3V46+xZFhrLfxpvdVu+vcj3fOug/Em5lZVabjq2+IRKG7 gGv7oU7ehrVgd3NXn5f3fWwKoSSEDmH8LQqrrZWC6DXyP4BiTjmhjiyTav7ZoPePHYBU1jO2eksD ww56pv1wWlT4WRlQf673+Ygwy8ojRoiDE2I9+y2NQiVQkaDyIri0KbrZDJrX1/LaJEd14p9uDzBL CGmup86IL27BBj54A9xRcOHZYD0DTo4xPz8wI4InJ/o7gxiDiIhIRT0xfPGjgCIB707OIZFmsRAr 7c+mq9oNGNGgmxDBdMCPnLyf1tf++jGaq0DzdnW/kbIxl9EqXEm7hGVHx2SGwc+kGFTFvPqRL6ZW lchKocW5hwg6GJBXWS4s9NuWhGJxr0cVFcN5NFWn58FNiwY+pCM/8/xd/FBiz9KvrBe1i54B63sX NDL23c/+ljIUUUmLJvMB00zZZPLoiPVCDXHKOl+Rz3tP8JPbCFGXkzDnrwqaH1tsqFwqXnzsjFSg AHDCcdaKlwEnC1eBoSEF71bPecZARhA58RueD3IgpqgOSMqq7TAn+dI0tHOcDjf5ijEM6/OY9IaZ HGVMt9aSRWDXXoZHU9tzHiqC2TXvXXhOOY04vl0r4+UugwbiIy7DRVWXtm35lrbcBa9VSeoeqNTj F5aRpx6CKZx0AIQj+gKLLFFml+p/VqKbkp4cjF7TmqCWZeUj4qWTOEXw9ltWYD2NDe4pYoAXkd27 IP1uQ0Z0QwEHZASRGUQrvbm4FoJuxLLSaFf3+PSITHtUWITFvjjPQodNBL+V/p6vIMNKQhk98R8T u+EycdauDlK1c1qLGZpb2xKN4964eeUbJpZJ+ZiFX+ru81LWZiolVORbwF5YnNPGxM9XIEhw8VOd kjAqa0l/yFXiLk0Y04zjbTEHyc4LNww98Ta4isvxXg8YT0eZ5CKEBmMY/raViku0iAvSzoliCbR1 GvCFK3bGdXaMlzMdcko4NcvmkrIZ64GfWqAd/qbiIG6GEVAoX6vECm8PkVPp5WsoRZftbeq6KG2v pCyTV5XosBV3MXubL96kuyZrhaHpIBSih6eNxN4InPsCskbxA41K8hCxoRVWlNoeuUAFeXswmb/z 3rmDAXpX+npOjXvMOnGK6eisBi4qiiROSXtiiUQsPrwW34Tgg8K4Y9psW3ts2KXvttyNp7vTmBu1 qTkVJOoXn9XgXlbhI9/0mJlbV4MDKmoAW7OmGj+cT63kVytv++aMvWSBZGgxB4jItQ3CtYU62Rl0 wtxh/4v1NM5NoFORXrr7ikTUf3zwLCZsUEyEluk40MfJLoNCTBJB0XibAQeH0BD4faLdSkmwDF5p xE9ErQKKBewMCIcOEHDwexZwEpW8Uro2XVO6lC+grKQqoa2k6Wxupmng56uZ05gU3BOaFZ1TGRan D1DzK+EUaeCTFNcVk5mcBq5Yv0Oa1aPbrr4b6BSV6jBR2Mk7nmadGkyPTfJbDpAO19fJXBWrzSZk JEG/coo603lkw50CpNZTsViVn0ySH5+SewragszP9jxnsHbVJM9YQxq3vfpRAr61tmXyHVXy9jXZ s4XDlw5OAnr3IJfBA1DMwud/iv5tQsjwjrrl3IYxgNTPUP3IfkgFRz+M8DJF/+L0/uP5GcyKkbN+ ZMCDxwmCTdR8tGtnGdzYk7R6sXnbYgBDMQORHEEmBiay6nZwFcA6RUTe8YMD/CdfPIKYk9PXfpjH EO50iuTGbeaT0jjrBXleYpstJnyHQHDv9YPmvX96f8MJJHtFZJ/c52GAfy6sAZ2GpDl/Oz9raS4a dU+G03qEkDa26qQgupDOvMs3MaqQj11R680N9PpCdDpZzOSG1PaBOwVfatCOuGk1d98AATSNVhQY e5kYBUa5iAjff9Lr4toeY+Pu+bs0tQKhjIYcOZKIW5IELH64u0lZkvOjmCyesc2ACESR+YPFnsVT 8eWsK+34D8GHKYTC32Xyu+xSh2zrRo+k+awIGSOvljowRz0t4AI4f5h799HHZvk9YPfDuWytc/bM DhnzgSSVMN9uv3QZQQkEtMmSrSUS9Wtp9AyU7YJBhe7AFkxltjQXgpNRuntvFUd7mi5y3XTsArJT qQj/GRQL+dzBinB0fusmhgvP1u6izgFcarVgPz9HHVFZeL+/9I8pzFYpYxpgMHrmBuRFggP4LLqQ bcM4UwK2KlH/+n/fL5ZUD7jxucT0FkJdNUvKgtA5KDqgE+TRExqK0eV5nxg018HAf702aWnUhKvl Kc+ctT1UaXIGWp9b3LEJbq16t6//IimPGAYzi0R7FM27qMSRexqmScSranKwjiC+brNsvHUjoGSI xROBrVDwNyUxTsiaJ908Q8qiR4p0YnxD8uP0V2CX79mA70tIpl0wAALUPY8zwOpXlFgghyUhbMuV VVqoV572F/Ocmq28sAFPv0wXI4T0yruSox/KH9AoEuVGQc7Rl96oV16D6fVclDtYDzukKcfokMUV jreIOUcw/W9g5IyTGb83htCPuWRS8Qr3q6xeUJRABQNq87VQ9SKDq+mR3IO0ApU/A8R8Xl4GQ5j4 361d/IeW3fEtXbH3BFFhHoIpvMWcCXcIUg47MW8ksPc/1QwjQdObR3a8AG7hvw6PcWRwA4YdRgJh vwzprK+yjl8X0MlqM6dcW0RgKyZ1OLwsllmPl9fkHAF+S/yfqgOKgiJew/cPCKwQA7uP7g1Uo0OF tlFEvUZDsyWsdwn1fYe/ZswmVkXZxP6T3CaNXIBuwNEVqy4WiUFZaj1QjTwC3nw6T/tYGQZ1UESG 2Na56WGEmek1ppn0VaQVNLwCd4kE2qfPjqC70/awKCKJrVsthx1n4WIDvnLvnr5Ba+q7eUQdv7Od EuG9RungkdsDX0MxUO/3f17novqoFqfG/XQvmkgjd9LUpnl88qIKzP7G6kDO0rVwPV/B7f50EDST jw6UdAc51NnK8HaE78crv45uC9zyySzxSo8fvYnmY1x1IlAViNvSLwJLc7k1yJ0DdYP73Ky+1wmy duqJRnrHpOzZ/xVG+xwBtSYTht28/7E57DQD/HJIARxmFoGBKPwAEGjg99fEVZmGqvrQ5ak0F4F1 skPFX9L31O+Fd4ik/yTMhKbpxbwunYa5pEXCtzlO0ZYTnVLZ0NfsPA5dzE89LSfhZ2zCMsKH0Fpz EujNvd3z2sBoiPWw3ZeFU65EfyLHXnfIwEPs+Bilzq2oo8V6Fy4Ec8nkriVK+q2Tfdl6nrc1/Top Z1MLahsbciGEcj3dzqhpl9nY+1EBl78EEGgNTgwQe6bc1voOXPZg8tCwbOEL+/T5XpwUEdn8yP5t UDTa0EyWevGm9TS8wLl1WbbAdjhWslIJvm8mOR3Dq5csnUm12W1oMScgWo0sczKBPiz78YZP7hX9 7m++oct6chjNjECsfoZKiBRMxnyyaLwzWLLL2ghtLw5BwKFsusIwJEw9aCFXnBq+tJEMw5uICi0k XRlh0veA6XYFedYtgWXGUhkJwiMi5CbkHSKdaAEA16G1rJSKRumKvyMnqKWpaDImIcI1u4PJuWlR Mr4jvkt4q+8qJZT007cJuCgrXpYad8JdSs3xtA4GEOmM7J1CsJFVhIW+S1RXEvN1EC4jJV8sgbi7 4+NbIlXr0nE9F/09iNra5DcKY0guNTq8p0VHAAHyHUKwlY+T/QF9Ggrt/GrAH55ZDrkIrneJDDeO ScA7jIuFMXWqh6pfgURRYAx8krp+ZdOzj9u/BUEbXohai7lxEseF7f3m722lMNOfxGcbrieBiBKj Zcme80U/y1/OO6AjSjf33vNzFPkR0LpqPqaMl1NERbLHqqRJPmNXQQENbNPfwgmRQl9PGedGSOt6 AV7AVno4hETVN3HQSgtGguqDW+H5CwrYB+cLYrFOYXNMeLmvVPhhr2VEWIA7c1pWp/7MKwjBQlMU D4HAtFCoPLUIir/ksBQ0dctvtOLBlRT3x+hnkM/qxvGX6cFGpPZH1tQ/lgrIT4mJh07DkBXsvLDd IgQ0ITfOuuvzfJ9hqan8fsbri7PTZcLJ4Bau8seh8Of8BTammbX3dSgBkCVv/mIbLtJo2bMRmEyw bn4y6cD1+6qFW/fqrqpZkQv4caDWAVLEmqzvHtEHvTyz+X1kG7bO2zNeFCbQRsB8JCiGypbR1Xcj P7wfy4+tbjF/EvbbVruwCuOPZ2Wo3680OyFRP3fKZz7m2Qn5PZQTHdIHrQDEaxtMXmWuE8WVbtAG 1rb7/Vgu5mudNMg8hxbLGu8cOfzn0neZE+xsAbJHe4XuqpQwClj0v2Ohh/SkQt54zytazsDrd2zL HGOYaN/VcXL5l1b43WO2VJ5noymvXeXFsY6d/9GND5clQ0Z6J8Ez/qfuR2LAeXNC+Qd/Fd1uI28+ RCRCY+oXj1IVZUEV02MxUCgL/Y294+CotMvp5eXVvD+9GWUJNSi8JpKiA+B564ErICbyPS5fRjLh FR314wOrQllShIC/W6LW6XpUnQ60IMhzSVq8y1+1eBKyLxDb3QWLXH3r1DFZGf+cY3xQkkcVLDeq j319sakzuD12Q/xsoUGdZbaZhzgd/axYnUNpUNQP+aKW6+nokHNN14yos6mFIFiOIhu5ueLBYePN ik0u9YIeHiXj9/V7/9Ay3molaEfn3njHtHqQO1lLlg+kppIauJlkaexw7pRjcoYnrrqxW72HGCFN QBk2KN5HonsitXKQQvSeKsrJteFxLGKiQ5GfiN6VEOax4vTsgENqFKWSnFL2rOu2Fjl94XkyX9Ik gXN6xLeWAA1XPme9EC4s4us+vBhGgG2bdJDOyqIvFXW+J62fhzv9Rrrwr7pelUEfFoZ8vbe07wKp e41ogfJ3QLVpx5e7/fDWbKqCNt5u82I0zyDmTozTAFnhXRstcJLIBmJztRVk2DkQATJYjS0+a/c0 cbayUVFcULl7E31xWo7pSsDUN76UumkoXNaPJ7rS+CCLbYvevrn9MqpAFFR2FagDFh2d2T+L3JWz Gch4XQBxtK/qIHELXZSCtXJVPo+6XZDpSfPaAcJefvH0ssR4FlfLd9FLspaDklyY0nxPgLQ7gz7c UA0WykhTdyRdVMZnjdllowJvG0x7ue/8oj/TgVu/svaui2wgzO7vIaawfP2Q0nUv9g40KyXa2oL9 mzcgbyMm7UZHD5DAxmy15Jl94rFzi25H1ATwT6lKa1zsnr6YmFZEI/wJOkxQJXfDE+r+G/T0kCWQ P8UtDTGpLitHuo8GYt4d+1Z770nJ++pdfhxuc8DtzJLmN9IIiGRxAtcAGSYSCujNenad7c3ilYsb BL7Bhg9sHYPG9/nG+6fJuhc0EXFihTt55eZU7rUHPVEP4lM2yraFVgdv0x4hdg7A9LSptwCcULkR yqsZR6JsYAf+vLXYZRJ0lynVhHLfZKMoeYoCTXq+f2LFe5y/TWYiEF3tjdXyFG7JQf1/Ws2K2o2g 70tqDmhwmaDOjtg5MLQrbhtIcIfZ1yqulu0ASXZA+bLUvVpUValSDZsr1VDWWcDVwgmn1Hj2Uiad ED1/egs58F44e2ooHILeFDVSdpAy31SmaQTMq2byBZo25kgl05YM1eZD/dISkT9A0yQodDpk6ysx 39ZJW7DAwrjuGX0o9yzKc4MsPh8tHbv7kO64L3yXlPJbraMMjHLlzrZukq+DONAK+aken8q/O5Yb Mi3xvV05OhQC2yZHUHaKXg7q3LIRvQsqFrmzT18ZzKzudSFEwlBzHweYzD/j91MOaNmTvGmu0wqF /ywxF/UrLWjlOUW8UTJoUVkoR4TjcF7NQG9U9+cfLAbBrPSnjGtu8ewD9fUQHhAKIW5xRhYuJcxy ouEwv8H8gQbGZLpPGrS6TOwcX5denaDabPEJjg40SgQ8HkLzvj88wL3uF5g/MAUSdK5BC1DlpQPQ wIFP8BLbsuORfUSJApCbRgL47aoIL/azpZqT1r2V/oO2byjuHkhJFxSoHDpG9he4F7VecwqRfU7C cS8bsmZdGQc9oGWyafND1bRyETAFNDUT1loqVhJC2/soTo+Q5q9IDIECSFD7+0JasDwPV/EBuGo3 qllWe3pO1GMwYHbx0o5fkog5+1wkp+RK2IVcQAVRntRqdd2Qch5oIPcfyvfGFoiAZUFGxxGEZCJf Up9dTgSt6432s0ZX/PKr36eXOJPX2cLHBipI6SveWjaelRh0SOhVk0iByRzZwVyhBmwFkdQwWhpf 9hxb49/mV78QrGgvUW3Kib+Q3sdKTKCh/Hq9SexF4HpRvGkM+x7aYCwwlXZaQ4qqxWHYZyILSuoF QpCLzBO0V4/putVViwPOEOSagldzxgfuGCoP5dbFcBrA5083d9pn5gv6r5psQVQgKH//YLlvzIax YQBgU8upGSf+YtFznXydTcSNRJVD5fIr0k7TYB3C5iKcPpPtsF+X/Q6vcwjSqPzdTLzGqsjLo6UH YhFvUiVG1cOfMwQPb6uWaKLhkggBfLLpkx+LxyR9uKMkC35AVmmyIfSAsf8YQmAyUVloKkwlo06c U4EZvocYyTgIigv1zIB5WpYgpytVK/rUqScZ/ndBz9Q78tXXNErCHHoAB95pbm0JEzTksaI3f/2s g1aLAN/F+wQ2GIGBKG3ePgOARCixHaj8wkBuO8eNcRjXuseuNyMYc0r9UT1tLpWRENc3Tyoz8scB 6jpVV1K2oPYRqb8DQs9m7XPK9xvoVNmZtWn8eH5nCP5pm7AxJK8D0is4rUc2jItHPCNMZNXNh3CR NsHARfkRLEfrHqvHXgAuH+L0uSvC9UxyjACCdu+lsiu4lspVvMh4CuPM+YN0Xo9MGJw5wGIbEUxA GkYW47OhqwT8SAQFe+llizfnVe7ZkiHvfvi8pc8L1YiMXybbxAYBFFU8nB5qwWfopXOMcStKoYW+ 9QMl/poebP3oTrB0no61qosFFt/YFZPbrjd4z/0JmieJbJbR1mTw5I0xzLruGbPnMT0xFfNQT8/r WWedO52TTD025f3g9bFl/ZvhQjNCgCbTI0mZPpvKHc2WSwdvEHJ6WIRtiBI//mzTJd1rLycNEW39 4/ckxT48kltIVA46YWDklsB0rsgoedlDVFMlCH2qvVjWCfrX3fRSl60rh6damTbc3uMcyDvGwW2l 0dkkLmCW54AM2d+ZlgrfzlhfBVgo1Dknc2L8aPikr/GATdLJvX1nUyr0AITKPcmy9xw1VQgRLhjB 8Rh1foWejpfJlt7ncPe9vXI+XI+sNF177VMItKnjgQHecBcSn+7iKYWbB1WjyzKgxhCuVYLaWQVb Z7/RE5JFPnGLk02+PYZHgu3P6AsKpJkMqsAVVHQquxtbHDlbwelmJb+rIif0RfIJGjgvlhKd7ofi 750y5GIhpkzyGe7LqClJNhhE8R+sgr6wJ/9yzV3yeY1L7JEAD0wCTpwVAIJaDLcN8z1zAdLRjhkK zcjTPCCYI94O5mm3UtPo9PAfYEkwZqgSseId9ksFqdfgRdOrqO3XK9iai5nD1mzqHCv4WaTLVPYc wzkVTESe6NwCJT8IDM/aPr3je39DHd8aF9U/Q38cu9PA4Et0RSX4ey43MTKINMQHMqkkvvfuDEpY r1J5K4FgaHQDgjo13jHE8HjBsGYiHnR6IOSXoXEojsL4AB0/EFa5l1GkbvBAr7VOaNuW9DUqVvfZ MfmeInRkyfl9VmK7q8NOTvR6IsJ7ugZxY7yrcsrmYrYwRm2iVwyjSngi+zbZEgla+pj1ZgxSsbvO TW9xcwwIMOOW3avJTlZsfNj2oEIVhJc/ouUuNYv2rHhnXjumpZzZYuB943aXlN3s2Yh0wN0Td4pH 5gvG3EYwK4vGVSoZQGYOAgiBm9luA39JZXewgI524pAeJ7uIcAMAt8orUbZoC9iyy7NuoYGQY0qc yqfdix9YTl0HstKgsA16qo6x5Ts6ZPSsxJ68HgLY/eospkg34q+7wmWq12XVgMYjgw5N4ZpFSaMr QcwI/ewHgtgREl+VUYNV/BPSrzanXV2h1mz56ocdpDTlWwJHCx/PakkpRy/wB1kH1mY/xkkM9TLR QAkQ5AJfjk2clMdtoICWyy4QFVxKWZPZQNUUP7DDsGdgj4wzH6QEHrK+if/oGmfkaHNsmTDOmgDV zm+h2ZN8MXhJsrT8xSbWh4Xf5TVZFDWtKNEpm6Yl8GAbPu0nAfoIQidIjPzOQLC2NinNt8oKfi7A g/gurmIRhjJfg1jVmNbEfiXhnvKaAbHNyr/5/SVGG3x2MEezoKfuAllsZ48jAqUmbvKmSo0eARrS 6Kn60hSMxNQAXmqgFMygMiDwLjsw6vGGf7ts84Mi5aRXH+f65L/zyg1KojyHlbyv42GM4kE1b34l t17ZOmYrUPSKwrE9ADjFwKgnzBNVTU2DEs9RagZQ5as4oQi0LP4g8smtUbMbEyiw6qCLTUt25C89 F+pu0Lw+VWwsAWDVg5oWtCdKS8Hgrk5Ay3tls0MlzNwHXGB2QA5zKsuN72Vprsm40tarHrCSeHlM BngK/VIUITGa29XdkTgnRQNyN5ikOTEAKPxxxLlADYJ0xTSrVJNHlwo/sX1oKOsyfDx85aoRM5xZ pGIIbr0BtVF5d6OOZqATpFMRwSnAY058SN8zKrlHErnWbyTE79T3KfsAaC9/xB8XP27fCoE+cgG8 ZAW8WC84YwMAANA8DU/cdqH11vJF0VZRG3VtCsFgHvqhGcn1r9AhqGlEDv5wEUswo7k1m+jjdQWy 5d6hiLGhb/hPEOxRgzOwfyGiTEggLmGZt0x+mU0iiO9/gS/PLoF+CZ6Bh7r+a+hjEgesHXLkAQyf IPT2PxywTMx//xVgYh5BBgCQHQBDAgAIAJDz5rQ9Q2BiHvfPTMPwv6L8Z270n3Swp050yFEsJBoB N4IoggCXQDME6VGD1FsBjxCTUgABQ8mSL7//5YFLp6kGC/y3PU2xGTDqLeA28h9/cwKCJ0zv/K9Y AYNCrcQll4Dt79aLhozIC4PvQYvqUYOgvyh17on/sYsaOYP+Zxh0tnQO81983OwNeGCo4jlNCox5 REL4Hy6Bfy9/BYJuAS8BzRSj5g6BNS8bNP/JQXf5/yk66I1/qIOnU0Kv4YEHz60eSzg9iPT7Fncp Da07kVCdbfaJGJtLyCTB7ZwOF8bsx3eEWhQXaC0VscGAjJu3UigjMWBUp83Mcgc8XNVPaA/J5+y4 APylxAYbZUg4ZgmyyOOiE9i9I7Zn15CeEynmg9nhYYbFhjJWXXhLML7z0A/D45RepX8xhnWsVgDt ckSlzrbNrH0wmYHd73n+LayMv3bZxQKncn0N/Dnk0vuLUW/lpt16SmTlKFcib+Dy1zuQYTSYU8ik sDNVLUS3WAymf+U/LQigIWEHAgD4NSEBAXg/Jz36/f2nnINL5cPT+a/J3f8C3z+Z7h+R/Q+d9D+Z 7X+s/yfU/ltv+d/8/7m2NnW0M7VhZqIzsbEBcHEydfxvEQBA3NRZ1t7ExcZUwtDOxMZU8J9K1tTJ ydDcVMjeXfB/5oD4z7tbFwjg4B+9/yMePSAA9X/k/Y8S/hGc/v+ubv0A8H+7CvzfeoH/V+W1Fzpa sCfCS3x2q1Zgyuq8KwygVuWJA/XXfkW4Iy1bI4654jBUUw/GBaQtFk3l1WbJOPzIjyvIxYbOR/sz VZxTe+YdmLXJQ/1ssXFOab9F+Lhhnuum4KeWc9m1sYRXj4o6dy8WFqIYzt41zhwEJf3jpYgrq0lc mvifwcNvHj5/cy6lG42BBJlZf6tXCye6CDsykvb0ZhmBUpVvcJodHcVSO6kgZWA3koyp/1AQqAaA tWZe29v3qIiwpT0cClkyY7b/z3/B0iJs/v/qzh+8ilWwy/VGs9k8gUAwOHyBIAhkSpUqjf9SCAZD Y7LabHU4XyZsI1Vd0x1a0SnTH9i4ajvfUPVDdvcKzhv/EZOJmsKOrlyCvvmkP3Whc6B/pTDU4Ypi 3xYr+iG6MnJTwP+cxc2rTwSvuaR8Mqaz4bzzdhVxnuOdR654I3mhwvxP/qm6TfjCD4MbS3svymt7 ZgnnW5Qf8dlN5hcTa1TspnmM2Le/kDU/LJcWlvyERTL6ps4ztNugnS90F1SYDpDtq5hZlWuoPS/0 V2TWtkxXnkyU6O/YicDd13QvVJxOoG3bKuFt/+q/Zym0s7cx2Ld1FXceZV+FL38h2SPl9Ib67MfO fetHzu8jLHRxs2E5McUjZpjlGgOs+GAup/bUhOycUols/itWfU16aOv7h/La2wCSbZZvB6Wqj/ne 1E0HqDsDIKhhQKz3mv7Y2d7RMEjQR5dxmmoLqa2P6MrOU0+mZx03rGdV/GaK4tKFTpPy1pZZkHXd fR646t7w3MRHB6pxG2FkpZ2l6of52oLOkfLIwPxffPclsd47plcjL03IzzncjJoBsbJ7slNTT1f6 a0pko9nFOTc3bjBbHSDV7hCTNwAASEgICCiA/4P/g/8/8H8BUEsBAgAAFAACAAgAkr7rLvz1hhKb QAEAAFIBAAsAAAAAAAAAAAAAAAAAAAAAAGRldGFpbHMucGlmUEsFBgAAAAABAAEAOQAAAMRAAQAA AA== --CSmtpMsgPart123X456_000_00417D51-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 11:10:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BIAi06025762; Fri, 11 Jul 2003 11:10:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6BIAii5025761; Fri, 11 Jul 2003 11:10:44 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BIAe06025750; Fri, 11 Jul 2003 11:10:40 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6BI8PUY002551; Fri, 11 Jul 2003 11:08:26 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6BI8Km7019052; Fri, 11 Jul 2003 12:08:20 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A5B557712; Fri, 11 Jul 2003 14:08:15 -0400 (EDT) Received: from whitestar.zk3.dec.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id DC9FC2777; Fri, 11 Jul 2003 11:08:12 -0700 (PDT) Received: from hp.com by whitestar.zk3.dec.com (8.12.6/1.1.29.3/18Jul02-1258PM) id h6BI8C7W090978; Fri, 11 Jul 2003 14:08:13 -0400 (EDT) Message-ID: <3F0EFD0C.9000501@hp.com> Date: Fri, 11 Jul 2003 14:08:12 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.3b) Gecko/20030318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 Advanced Socket API extension for Mobile IP References: <200307090217.h692H7tf632702@jurassic.eng.sun.com> In-Reply-To: <200307090217.h692H7tf632702@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Samita Some comments on the draft In the following section, the some of the members of the data structures are not properly alligned within the structure. 2.1.3 Home Address Test Init (HoTI) Message - cookie is defined as array of 32 bit unsigned integers, but does not allign on 32 bit boundry 2.1.4 Care-of Address Test Init (CoTI) Message - Same as 2.1.3 2.1.5 Home Address Test (HOT) Message - cookie and keygen tocken are defined as arrays of 32 bit unsigned integers, but do not allign of 32 bit boundry 2.1.6 Care Of Address Test (COT) Message - same as 2.1.5 2.1.9 Binding Error Mobility Message - IPv6 address 'ip6mhbe_homeadr' does not allign on 64 bit boundry. The recomendation is to change the type of all these structure members to uint8_t thus reducing alignment requirement to 8 bits. Section 2.2 assignes the value 62 to be the mobility header. According to IANA, valud 62 is assigned to CFTP. According to same document, the value 55 is currently assigned to IP Mobility. I am not very familiar with Mobile IPv4, but I did not think it required a new protocol value. In Section 3 you describe how to set the Home Address option through the ancilary data. However, you do not address what happens if the user specifies multiple options, include HAO, in the same ansilary data (same header). I would suggest adding a restriction that to correctly set the HAO in the destination header, the option SHOULD be specified alone in a given ancilary data object. In Section 4.1, the draft describes how to use the IPV6_CHECKSUM option on mobility headers. The draft seems to turn off "kernel" checksumming by default on the IPPROTO_MH socket. I belive that the checksumming should be on by default (similar to ICMPv6) with the ability to turn it off by the socket. The reason is that most Mobile IPv6 implementation are supported in the "kernel" and already do checksumming. The RAW socket interface can take advantage of that. So, at this poing NOT doing checksumming is an change to the expected behavior. To minimize that change, we can default to do checksumming with the ability to turn it off and let the applcation do it. That's about it for now. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX Network Group Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 11:14:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BIEq06025963; Fri, 11 Jul 2003 11:14:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6BIEqP5025962; Fri, 11 Jul 2003 11:14:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BIEm06025946 for ; Fri, 11 Jul 2003 11:14:48 -0700 (PDT) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with SMTP id h6BICXte442652; Fri, 11 Jul 2003 11:12:33 -0700 (PDT) Date: Fri, 11 Jul 2003 11:12:09 -0700 From: Michael Hunter To: Pekka Savola Cc: Alain.Durand@Sun.COM, itojun@iijlab.net, Michael.Hunter@Sun.COM, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" Message-Id: <20030711111209.4d14febd.michael.hunter@eng.sun.com> In-Reply-To: References: <4C89C019-B303-11D7-A6BA-00039358A080@sun.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 11 Jul 2003 08:00:36 +0300 (EEST) Pekka Savola wrote: [...] > > The other one is: if a NIQ is send to a RFC3041 address, do you reply to > > it? My take is that by default, you should not and have a switch to > > override. > > But I fail to see any use for this. Typically when you implement these, I > think they'll listen to all addresses ("any incoming packet"). It seems > that disabling one set of addresses and even giving users a toggle of > rather little value would be useless. But of course, one might have to > implement differently too. The association between RFC3041 addresses and other addresses is what you want to protect. If you let a 3rd party discover that association with NIQ then you've removed the little usefulness that RFC3041 addresses have. > > But the spec could say e.g. that NIQ's don't need to be answered at > RFC3041 addresses, and leave at it that. [...] I think it should be as strong as the statement about replying with RFC3041 addresses in NIQs. The reason for not wanting either is that both allow for the association between RFC3041 addresses and other addresses. I can't see making a statement about the two cases with differing levels of strength. mph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 12:08:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BJ8v06027853; Fri, 11 Jul 2003 12:08:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6BJ8vmZ027852; Fri, 11 Jul 2003 12:08:57 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BJ8q06027845 for ; Fri, 11 Jul 2003 12:08:53 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6BJ6cUu026943 for ; Fri, 11 Jul 2003 12:06:38 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6BJ6Rm7025866 for ; Fri, 11 Jul 2003 13:06:27 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHV00JTBJQQFW@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 11 Jul 2003 13:06:27 -0600 (MDT) Received: from sun.com ([212.158.47.2]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HHV007XCJQO90@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 11 Jul 2003 13:06:26 -0600 (MDT) Date: Fri, 11 Jul 2003 12:06:43 -0700 From: Alain Durand Subject: Comments on draft-hinden-ipv6-global-local-addr-02.txt In-reply-to: <20030711111209.4d14febd.michael.hunter@eng.sun.com> To: ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Section 8: Note that the address selection mechanisms of [ADDSEL], and in particular the policy override mechanism replacing default address selection, are expected to be used on a site where Local IPv6 addresses are configured. ==> This will not scale as there is currently no standardized mechanism to distribute a policy table to all the nodes within a site. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 12:43:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BJhZ06029030; Fri, 11 Jul 2003 12:43:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6BJhZt3029029; Fri, 11 Jul 2003 12:43:35 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BJhR06029022 for ; Fri, 11 Jul 2003 12:43:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6BJfDUu012465 for ; Fri, 11 Jul 2003 12:41:13 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6BJf3kg013934 for ; Fri, 11 Jul 2003 12:41:06 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6BJeTP31844; Fri, 11 Jul 2003 22:40:29 +0300 Date: Fri, 11 Jul 2003 22:40:29 +0300 (EEST) From: Pekka Savola To: Michael Hunter cc: Alain.Durand@Sun.COM, , , , Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-Reply-To: <20030711111209.4d14febd.michael.hunter@eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 11 Jul 2003, Michael Hunter wrote: > On Fri, 11 Jul 2003 08:00:36 +0300 (EEST) > Pekka Savola wrote: > > [...] > > > The other one is: if a NIQ is send to a RFC3041 address, do you reply to > > > it? My take is that by default, you should not and have a switch to > > > override. > > > > But I fail to see any use for this. Typically when you implement these, I > > think they'll listen to all addresses ("any incoming packet"). It seems > > that disabling one set of addresses and even giving users a toggle of > > rather little value would be useless. But of course, one might have to > > implement differently too. > > The association between RFC3041 addresses and other addresses is what you > want to protect. If you let a 3rd party discover that association with > NIQ then you've removed the little usefulness that RFC3041 addresses have. Please re-read what you write. What you're implying is that those you're worried about would learn your "true identity" and not RFC3041 would ones allowed to send NIQ's to you and you'd actually answer them? Never. Never. I'd go as far as state that off-link NIQ's MUST be disabled by default and MUST NOT be enabled unless there are acccess controls specific to the requester (e.g. IPsec SA) which allow that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 14:07:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BL7B06000809; Fri, 11 Jul 2003 14:07:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6BL7Bml000808; Fri, 11 Jul 2003 14:07:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BL7806000801; Fri, 11 Jul 2003 14:07:08 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6BL4sUu013535; Fri, 11 Jul 2003 14:04:54 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6BL4m6J024114; Fri, 11 Jul 2003 15:04:48 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 25832CB15; Fri, 11 Jul 2003 16:04:48 -0500 (CDT) Received: from whitestar.zk3.dec.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 6CC0A26C7; Fri, 11 Jul 2003 14:04:45 -0700 (PDT) Received: from hp.com by whitestar.zk3.dec.com (8.12.6/1.1.29.3/18Jul02-1258PM) id h6BL4j7W091527; Fri, 11 Jul 2003 17:04:46 -0400 (EDT) Message-ID: <3F0F266D.20400@hp.com> Date: Fri, 11 Jul 2003 17:04:45 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.3b) Gecko/20030318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 Advanced Socket API extension for Mobile IP References: <200307090217.h692H7tf632702@jurassic.eng.sun.com> <3F0EFD0C.9000501@hp.com> In-Reply-To: <3F0EFD0C.9000501@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ooops... I goofed > > In the following section, the some of the members of the data > structures are not properly alligned within the structure. > > 2.1.3 Home Address Test Init (HoTI) Message > - cookie is defined as array of 32 bit unsigned integers, but > does not allign on 32 bit boundry > > 2.1.4 Care-of Address Test Init (CoTI) Message > - Same as 2.1.3 > > 2.1.5 Home Address Test (HOT) Message > - cookie and keygen tocken are defined as arrays of 32 bit unsigned > integers, but do not allign of 32 bit boundry > > 2.1.6 Care Of Address Test (COT) Message > - same as 2.1.5 > > 2.1.9 Binding Error Mobility Message > - IPv6 address 'ip6mhbe_homeadr' does not allign on 64 bit boundry. > > The recomendation is to change the type of all these structure members > to uint8_t thus reducing alignment requirement to 8 bits. > It looks like I miscalculated on the above. They do align correctly. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX Network Group Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 15:23:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BMNh06001823; Fri, 11 Jul 2003 15:23:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6BMNgem001822; Fri, 11 Jul 2003 15:23:42 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6BMNc06001811 for ; Fri, 11 Jul 2003 15:23:38 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6BMLNUY021609 for ; Fri, 11 Jul 2003 15:21:23 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6BMLI6J017995 for ; Fri, 11 Jul 2003 16:21:18 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Jul 2003 15:21:17 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Jul 2003 15:21:17 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Jul 2003 15:21:17 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Jul 2003 15:21:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Jul 2003 15:21:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 w.g. Last Call on "IPv6 Node Information Queries" Date: Fri, 11 Jul 2003 15:21:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Node Information Queries" Thread-Index: AcNFwygz1aO+qnAvSUmN2Ftoi+DUTACNweLw From: "Dave Thaler" To: , "Michael Hunter" Cc: "Bob Hinden & Margaret Wasserman" , X-OriginalArrivalTime: 11 Jul 2003 22:21:15.0752 (UTC) FILETIME=[BE5ABE80:01C347FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6BMNc06001812 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun writes (in response to Michael Hunter): > >This looks like a strong draft. Several issues exist though. > > > >1) There is no mention of RFC 3041 (privacy enhanced) addresses. Both > >the issue as to if they should be responded with and if they should be > >responded to needs to be addressed. > > just FYI from implementation POV: KAME implementation does not > include RFC3041 addresses in the response by default. there's a > configuration flag bit which makes the responder to include RFC3041 > addresses as well. > > i guess that sensible default would be not to include RFC3041 > addresses. Unless you have a way to generate a temporary name for a temporary addresses (e.g. one automatically generated from the address). > >2) The security model is unclear as to the scope of responses. There > >is a sentence in the "Security Consideration" section which states the > >implementation should have a default configuration which refuses to > >respond to global scope addresses. > > > >If this means that the protocol should be limited to link local > >addresses that should be stated directly. Use of a 1 Hop Limit or 255 > >Hop Limit with check would enforce this (see LLMNR for example and > >reasons). I think limiting the protocol to the link local reduces > >its usefulness. > > i really would like to keep it usable globally (= do not limit > it to link-local only). we use the protocol to query name of > intermediate routers, which is several hops away, for debugging > purposes. I agree with itojun here. > >If its not limited to the link local then this protocol should probably > >be filtered at the edge of the administrative domain. > > it is up to administrator of the domain, therefore i think > recommendation like "SHOULD filter" is too strong. how about > "may want to filter" or something like that? I agree here too. -Dave > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 18:21:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6C1Ku06002861; Fri, 11 Jul 2003 18:21:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6C1KkQc002860; Fri, 11 Jul 2003 18:20:46 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6C1Kb06002845; Fri, 11 Jul 2003 18:20:37 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with SMTP id h6C1IKtf569136; Fri, 11 Jul 2003 18:18:21 -0700 (PDT) Message-Id: <200307120118.h6C1IKtf569136@jurassic.eng.sun.com> Date: Fri, 11 Jul 2003 18:19:13 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: IPv6 Advanced Socket API extension for Mobile IP To: Vladislav.Yasevich@hp.com Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, samita.chakrabarti@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2vYKe4oGivXBNqedOkJ4Lw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Section 2.2 assignes the value 62 to be the mobility header. According > to IANA, valud 62 is assigned to CFTP. According to same document, > the value 55 is currently assigned to IP Mobility. I am not very familiar > with Mobile IPv4, but I did not think it required a new protocol value. > Thanks for the information. Mobile IPv4 is at the application layer, so I'd assume 'IP Mobility' (55) is for Mobile IPv6. Does anyone else know for sure ? > > In Section 3 you describe how to set the Home Address option through the > ancilary data. However, you do not address what happens if the user > specifies multiple options, include HAO, in the same ansilary data > (same header). I would suggest adding a restriction that to correctly > set the HAO in the destination header, the option SHOULD be specified alone > in a given ancilary data object. > Do you mean other destination or hop-by-hop options or routing header ? It definitely simplifies if we put that restriction. Does anyone see any potential issue in having this restriction ? > In Section 4.1, the draft describes how to use the IPV6_CHECKSUM > option on mobility headers. The draft seems to turn off "kernel" > checksumming by default on the IPPROTO_MH socket. I belive Yes. As per RFC3542 only ICMPv6 has the default checksumming feature. > that the checksumming should be on by default (similar to ICMPv6) > with the ability to turn it off by the socket. The reason is that > most Mobile IPv6 implementation are supported in the "kernel" and > already do checksumming. The RAW socket interface can take advantage > of that. So, at this poing NOT doing checksumming is an change > to the expected behavior. To minimize that change, we can default to > do checksumming with the ability to turn it off and let the applcation > do it. Only issue, I see that it then somewhat breaks what RFC3542 claims for RAW socket behavior. Hence, setting IPV6_CHECKSUM for mobility header seems to follow the following spec. " The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 raw sockets, since this checksum is mandatory. For other raw IPv6 sockets (that is, for raw IPv6 sockets created with a third argument other than IPPROTO_ICMPV6), the application must set the new IPV6_CHECKSUM socket option to have the kernel (1) compute and store a checksum for output, and (2) verify the received checksum on input, discarding the packet if the checksum is in error." Thanks for your comments. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 20:10:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6C3Aw06003908; Fri, 11 Jul 2003 20:10:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6C3Aw50003907; Fri, 11 Jul 2003 20:10:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6C3As06003900 for ; Fri, 11 Jul 2003 20:10:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6C38eUY028791 for ; Fri, 11 Jul 2003 20:08:40 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6C38XbK007597 for ; Fri, 11 Jul 2003 20:08:34 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6C382N02553; Sat, 12 Jul 2003 06:08:02 +0300 Date: Sat, 12 Jul 2003 06:08:01 +0300 (EEST) From: Pekka Savola To: Michael Hunter cc: Alain.Durand@Sun.COM, , , Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-Reply-To: <20030711135539.7f313ed2.michael.hunter@eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 11 Jul 2003, Michael Hunter wrote: > On Fri, 11 Jul 2003 22:40:29 +0300 (EEST) > Pekka Savola wrote: > > On Fri, 11 Jul 2003, Michael Hunter wrote: > > > > > On Fri, 11 Jul 2003 08:00:36 +0300 (EEST) > > > Pekka Savola wrote: > > > > > > [...] > > > > > The other one is: if a NIQ is send to a RFC3041 address, do you reply to > > > > > it? My take is that by default, you should not and have a switch to > > > > > override. > > > > > > > > But I fail to see any use for this. Typically when you implement these, I > > > > think they'll listen to all addresses ("any incoming packet"). It seems > > > > that disabling one set of addresses and even giving users a toggle of > > > > rather little value would be useless. But of course, one might have to > > > > implement differently too. > > > > > > The association between RFC3041 addresses and other addresses is what you > > > want to protect. If you let a 3rd party discover that association with > > > NIQ then you've removed the little usefulness that RFC3041 addresses have. > > > > Please re-read what you write. > > > > I'm not understanding the following so I apologize if my response isn't > to your point. Sorry if I was unclear.. > > What you're implying is that those you're worried about would learn your > > "true identity" and not RFC3041 would ones allowed to send NIQ's to you > > and you'd actually answer them? > > So the issue I was attempting to communcate was that the association > between your RFC3041 address(es) and your other addresses was something > you wanted to protect. The following two points need to be protected > at the same level: > > 1) Somebody sending a request to a non-RFC3041 address and discovering > your RFC3041 address(es). > > 2) Somebody sending a request to a RFC 3041 address and discovering your > other addresses/name which resolves to other addresses. > > If you think one is important, I believe you should think both are > important. True. But now comes my actual point: you're making an assumption that all nodes in the Internet (basically) would answer to NIQ's from everywhere, and consequently there would be some information to disclose. I don't think this is reasonable. If you can't trust the guy whose NIQ's you're answering to enough that you need to obfuscate the association between RFC3041 and non-RFC3041 addresses, you shouldn't be answering those NIQ's at all. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 05:35:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CCZC06016938; Sat, 12 Jul 2003 05:35:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6CCZBDv016937; Sat, 12 Jul 2003 05:35:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CCZ806016930 for ; Sat, 12 Jul 2003 05:35:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6CCWqUu004297 for ; Sat, 12 Jul 2003 05:32:53 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6CCWkbK017534 for ; Sat, 12 Jul 2003 05:32:47 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6CCWbf05860; Sat, 12 Jul 2003 15:32:37 +0300 Date: Sat, 12 Jul 2003 15:32:36 +0300 (EEST) From: Pekka Savola To: Bob Hinden & Margaret Wasserman cc: ipng@sunroof.eng.sun.com, Margaret Wasserman , , Subject: Re: IPv6 w.g. Last Call on "Requirements for IPv6 prefix delegation" In-Reply-To: <4.3.2.7.2.20030708100322.02d75550@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 8 Jul 2003, Bob Hinden & Margaret Wasserman wrote: > This is a short IPv6 working group last call for comments on advancing the > following document as an Informational RFC: > > Title : Requirements for IPv6 prefix delegation > Author(s) : S. Miyakawa, R Droms > Filename : draft-ietf-ipv6-prefix-delegation-requirement-02.txt > Pages : 6 > Date : 2003-7-1 > > A two week working group last call was completed on March 17, 2003 on the > -01 version of the document. This version resolves issues raised during > that working group last call. > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end on 14 > July 2003. The document addresses the concerns raised previously, thanks. A few small issues I came across during the re-read are below; editing these and sending the document off to the IESG (unless others have issues) should be rather straightforward. 3.2 Use of Delegated Prefixes in Customer Network The prefix delegation mechanism must not prohibit or inhibit the assignment of longer prefixes, created from the delegated prefixes, to links within the customer network. It is not a requirement that the prefix delegation mechanism provide for the reporting of prefix delegation within the customer network back to the ISP. ==> When I read the second sentence ("It is not.."), I got confused, as the first sentence doesn't seem to imply any reporting back to the ISP. Remove or reword slightly e.g. to: Prefix delegation within the customer network should not be needed to be reported back to the ISP. that cusomters will be assigned a /48 IPv6 unicast address prefix ==> s/cusomters/customers/ An intruder requesting router may be able to mount a denial of service attack by repeated requests for delegated prefixes that exhaust the delegating router's available prefixes. ==> by "intruder requesting router" you're maybe referring to the CPE (as it would exhaust the delegating router's resources)? Please reword slightly for clarity. Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 06:07:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CD7v06017967; Sat, 12 Jul 2003 06:07:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6CD7ukA017966; Sat, 12 Jul 2003 06:07:56 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CD7r06017959 for ; Sat, 12 Jul 2003 06:07:53 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6CD5bUY002632 for ; Sat, 12 Jul 2003 06:05:37 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6CD5QQg003695 for ; Sat, 12 Jul 2003 07:05:27 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h6CD5Ei03313; Sat, 12 Jul 2003 20:05:15 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h6CD4ur19929; Sat, 12 Jul 2003 20:04:58 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Michael Hunter , Alain.Durand@Sun.COM, itojun@iijlab.net, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Jul 2003 20:04:56 +0700 Message-ID: <331.1058015096@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 12 Jul 2003 06:08:01 +0300 (EEST) From: Pekka Savola Message-ID: | If you can't trust the guy whose NIQ's you're answering to enough that you | need to obfuscate the association between RFC3041 and non-RFC3041 | addresses, you shouldn't be answering those NIQ's at all. Pekka, couldn't you say the exact same thing about DNS queries? The two are just different mechanisms for getting the same information after all (well, similar information anyway, each has advantages over the other for different uses). I haven't heard anyone claiming that DNS queries should be blocked at site borders, because you can't trust the big outside world to know any of that information. If sites want to filter any packets (any kinds of packets) going to/from any nodes in their domain at all, that's their right. But there's absolutely nothing here that mandates that people should be told that they really should block all NIQ packets, any more than we would consider telling people that they should block all DNS packets. In an earlier message michael.hunter@eng.sun.com said: | I think it should be as strong as the statement about replying with RFC3041 | addresses in NIQs. The reason for not wanting either is that both allow for | the association between RFC3041 addresses and other addresses. I can't see | making a statement about the two cases with differing levels of strength. Personally, I see no harm, and potentially some advantages, in returning 3041 addresses in an NIQ reply. Remember it isn't 3041 addresses that are supposed to be the secret, it is the identity of the node. If you already know that, then knowing its 3041 addresses is going to be pretty harmless. I imagine the theory is that someone could query every node it can find to build up a list of 3041 address to identity mappings, and so destroy the 3041 privacy? How? Remember that 3041 addresses remain valid for only a week (normally) and that new ones are created (and actually used primarily) every day. That means, to build up any kind of useful directory, the whole internet would need to be scanned with NIQ queries every week (and probably every day). That's absurd. Even scanning an organisation large enough to be able to make any practical use of this kind of privacy internally isn't really practical. On the other hand, I can see a utility in being able to locate a 3041 address that relates to a host I want to communicate with (a 3041 address that works right now). That could be useful to hide traffic communication patterns from people who want to snoop on the net and measure who is talking to whom, and how much. So, if I look up a server in the DNS, and want to communicate with it, I could send it a NIQ and request its 3041 addresses (I think a new request bit would be a good idea for this), and then pick one of those to use to send to (probably using the lifetime to pick the newest of them). Note that (if needed, and in appropriate circumstances) this query (including the fact that it is an NIQ query) can all be encrypted, and hence invisible. On the other hand, the IPv6 headers in the outer packets cannot be obscured (for obvious reasons). The other direction - responding to a NIQ sent to a 3041 address is a completely different issue of course. That would completely blow away the privacy that 3041 offers - so this is a completely different issue, there's no similarity at all between this and a request for 3041 addresses (including requesting "other" 3041 addresses in a query sent to a 3041 address - all queries sent to 3041 addresses should be dropped). While (as Dave Thaler suggested) one could respond to a NIQ name query with a random (or temporary) name - that's not really going to be any more useful than not responding at all, so just don't bother. Responding with addresses is a complete no-go area. Of course, it isn't only NIQ that suffers this problem when packets are sent to 3041 addresses - systems running such addresses need to be aware of all servers they're running that might identify them if queried, and make sure that none of those are listening on 3041 addresses - this includes SMTP, HTTP, FTP, ... servers, all of which normally simply volunteer the node's identity (but also SNMP, and lots more, that can be persuaded to reveal the info). The IDENT protocol (as bogus as that nonsense is) is another thing that you obviously don't want running on a 3041 address. Most of this really should be included in 3041 itself - perhaps 3041 should even be saying that hosts not respond to incoming connections addressed to 3041 addresses by default (ie: INADDR_ANY or its v6 equivalent) should not include 3041 addresses) no matter how innocuous they seem - that they be reserved exclusively for outgoing connections. 3041 assumes that incoming connections result from DNS lookups, and as 3041 addresses aren't put there, there will be no incoming connections to care about - but that's bogus, as the existence of the IDENT protocol demonstrates (even if it wasn't obvious without that). Note - this may seem to be in conflict with my example of why returning 3041 addresses in a NIQ response might be a good idea, but it isn't really. Servers that know what they're doing (ie: not to identify themselves to people who aren't supposed to know) can happily explicitly listen to any 3041 addresses they like. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 07:28:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CESM06020501; Sat, 12 Jul 2003 07:28:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6CESMpo020500; Sat, 12 Jul 2003 07:28:22 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CESI06020493 for ; Sat, 12 Jul 2003 07:28:18 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6CEQ3UY002731 for ; Sat, 12 Jul 2003 07:26:03 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6CEPvQg019496 for ; Sat, 12 Jul 2003 08:25:57 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6CEPkPO100452; Sat, 12 Jul 2003 16:25:46 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6CEPjjR226186; Sat, 12 Jul 2003 16:25:45 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA39984; Sat, 12 Jul 2003 16:25:42 +0200 Message-ID: <3F101A6F.9C136436@hursley.ibm.com> Date: Sat, 12 Jul 2003 16:25:51 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Alain Durand CC: ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-hinden-ipv6-global-local-addr-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain Durand wrote: > > Section 8: > Note that the address selection mechanisms of [ADDSEL], and in > particular the policy override mechanism replacing default address > selection, are expected to be used on a site where Local IPv6 > addresses are configured. > > ==> This will not scale as there is currently no standardized mechanism > to distribute a policy table to all the nodes within a site. That is a problem that has to be solved anyway. I don't see why it is specific to Bob's draft. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 07:43:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CEh606021121; Sat, 12 Jul 2003 07:43:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6CEh5Ur021120; Sat, 12 Jul 2003 07:43:05 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CEh106021113 for ; Sat, 12 Jul 2003 07:43:01 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6CEekUY005096 for ; Sat, 12 Jul 2003 07:40:46 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6CEeeNv006953 for ; Sat, 12 Jul 2003 07:40:40 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A022BA2; Sat, 12 Jul 2003 23:40:37 +0900 (JST) To: Brian E Carpenter Cc: Alain Durand , ipng@sunroof.eng.sun.com In-reply-to: brian's message of Sat, 12 Jul 2003 16:25:51 +0200. <3F101A6F.9C136436@hursley.ibm.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-hinden-ipv6-global-local-addr-02.txt From: itojun@iijlab.net Date: Sat, 12 Jul 2003 23:40:37 +0900 Message-Id: <20030712144037.A022BA2@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Section 8: >> Note that the address selection mechanisms of [ADDSEL], and in >> particular the policy override mechanism replacing default address >> selection, are expected to be used on a site where Local IPv6 >> addresses are configured. >> >> ==> This will not scale as there is currently no standardized mechanism >> to distribute a policy table to all the nodes within a site. > >That is a problem that has to be solved anyway. I don't see why it is >specific to Bob's draft. i don't think so. introducing limited-scope (local) IPv6 address is problematical in multiple ways (DNS lookup, can't use as referrals, leakage, just like site-local), so technology that needs "distribution of policy table" is not recommended. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 08:11:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CFBD06022062; Sat, 12 Jul 2003 08:11:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6CFBDBx022061; Sat, 12 Jul 2003 08:11:13 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CFB906022054 for ; Sat, 12 Jul 2003 08:11:09 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6CF8sUY010427 for ; Sat, 12 Jul 2003 08:08:54 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6CF8l6J004395 for ; Sat, 12 Jul 2003 09:08:48 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6CF8Yu5022358; Sat, 12 Jul 2003 17:08:34 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6CF8YjR129234; Sat, 12 Jul 2003 17:08:34 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA53208; Sat, 12 Jul 2003 17:08:31 +0200 Message-ID: <3F102478.2784A71F@hursley.ibm.com> Date: Sat, 12 Jul 2003 17:08:40 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: itojun@iijlab.net CC: Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-hinden-ipv6-global-local-addr-02.txt References: <20030712144037.A022BA2@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >> Section 8: > >> Note that the address selection mechanisms of [ADDSEL], and in > >> particular the policy override mechanism replacing default address > >> selection, are expected to be used on a site where Local IPv6 > >> addresses are configured. > >> > >> ==> This will not scale as there is currently no standardized mechanism > >> to distribute a policy table to all the nodes within a site. > > > >That is a problem that has to be solved anyway. I don't see why it is > >specific to Bob's draft. > > i don't think so. introducing limited-scope (local) IPv6 address is > problematical in multiple ways (DNS lookup, can't use as referrals, > leakage, just like site-local), so technology that needs "distribution > of policy table" is not recommended. I don't see the connection. We will have two-faced DNS, unreferrable addresses, and leakage anyway. They are part of life on the Internet these days. Having unique local addresses reduces the damage. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 09:19:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CGJX06023980; Sat, 12 Jul 2003 09:19:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6CGJX8j023979; Sat, 12 Jul 2003 09:19:33 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CGJT06023972 for ; Sat, 12 Jul 2003 09:19:30 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6CGHDUu021712 for ; Sat, 12 Jul 2003 09:17:13 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6CGH76J018949 for ; Sat, 12 Jul 2003 10:17:08 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6CGGDK07457; Sat, 12 Jul 2003 19:16:13 +0300 Date: Sat, 12 Jul 2003 19:16:12 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Michael Hunter , , , , Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-Reply-To: <331.1058015096@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 12 Jul 2003, Robert Elz wrote: > | If you can't trust the guy whose NIQ's you're answering to enough that you > | need to obfuscate the association between RFC3041 and non-RFC3041 > | addresses, you shouldn't be answering those NIQ's at all. > > Pekka, couldn't you say the exact same thing about DNS queries? Not really.. > The two are just different mechanisms for getting the same information > after all (well, similar information anyway, each has advantages over > the other for different uses). > > I haven't heard anyone claiming that DNS queries should be blocked at > site borders, because you can't trust the big outside world to know > any of that information. .. you don't query DNS information from the nodes themselves. You query it from designated DNS servers. Now, if NIQ mechanism would be made so that the nodes would report their hostname<->address mappings to some site-specific registries, and one would be able to query the data from those registries (applicable to the policy set by the network administrator for such queries), we would be talking about an entirely different thing.. not too far from DNS + dynamic updates (or IETF-specified protocol for standard Looking Glass lookups for certain information about routers, depending on whether you're looking at querying information from hosts or routers.) > But there's absolutely nothing here that mandates that people should be > told that they really should block all NIQ packets, any more than we > would consider telling people that they should block all DNS packets. Blocking them would be very much in line with the intended applicability of NIQs as written down AFAICS. I'd like to implement the stick (blockage) in addition to the carrot (nice words about applicability) in the NIQ specification so that it's not misused. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 13:57:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CKv806001515; Sat, 12 Jul 2003 13:57:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6CKv8wP001514; Sat, 12 Jul 2003 13:57:08 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6CKv406001507 for ; Sat, 12 Jul 2003 13:57:04 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6CKsnUu021953 for ; Sat, 12 Jul 2003 13:54:49 -0700 (PDT) Received: from chabrowa.net (chabrowa.net [80.55.182.106]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6CKshwq006848 for ; Sat, 12 Jul 2003 14:54:43 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by chabrowa.net (Postfix) with ESMTP id 92CF48D267 for ; Sat, 12 Jul 2003 22:57:33 +0200 (CEST) Received: from mm (unknown [10.0.1.2]) by chabrowa.net (Postfix) with ESMTP id 438208D1F4 for ; Sat, 12 Jul 2003 22:57:33 +0200 (CEST) Date: Sat, 12 Jul 2003 22:54:37 +0200 From: Marcin Markowski X-Mailer: The Bat! (v1.61) Reply-To: Marcin Markowski X-Priority: 3 (Normal) Message-ID: <28119604041.20030712225437@chabrowa.net> To: ipng@sunroof.eng.sun.com Subject: Strange problem with BGP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: AMaViS + mks_vir Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Few days ago our server was DDoSed and from this while some peers can't connect. They are in idle state. I tried to clear bgp sessions, restart bgpd, down tunnels and up it again, but this is for nothing. I'm using zebra-pj on linux with kernel 2.4.21-grsec. In logs i have: 2003/07/12 22:35:28 BGP: [Event] BGP connection from host 3ffe:400c:feed::6 2003/07/12 22:35:28 BGP: 3ffe:400c:feed::6 [Event] Transfer temporary BGP peer to existing one 2003/07/12 22:35:28 BGP: 3ffe:400c:feed::6 [Event] Accepting BGP peer delete 2003/07/12 22:37:56 BGP: 3ffe:400c:feed::6 [Event] Connect start to 3ffe:400c:feed::6 fd 23 2003/07/12 22:37:56 BGP: 3ffe:400c:feed::6 [Error] bgp_read_packet error: Connection reset by peer This problem is only with few peers, other works fine. In logs from my peer they have that same error "Connection reset by peer". Sometimes when they restart bgpd session will up. Anyone know something about that? Regards, -- Marcin Markowski mail: max@chabrowa.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 23:36:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6D6aJ06015881; Sat, 12 Jul 2003 23:36:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6D6aJiU015880; Sat, 12 Jul 2003 23:36:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6D6aF06015873 for ; Sat, 12 Jul 2003 23:36:15 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6D6XtUu027182 for ; Sat, 12 Jul 2003 23:33:56 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6D6Xmwq028949 for ; Sun, 13 Jul 2003 00:33:49 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6D6Xc219898; Sun, 13 Jul 2003 09:33:38 +0300 Date: Sun, 13 Jul 2003 09:33:38 +0300 (EEST) From: Pekka Savola To: Bob Hinden & Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Requirements" In-Reply-To: <4.3.2.7.2.20030701131314.02a684c0@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 1 Jul 2003, Bob Hinden & Margaret Wasserman wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Informational RFC: > > Title : IPv6 Node Requirements > Author(s) : J. Loughney > Filename : draft-ietf-ipv6-node-requirements-04.txt > Pages : 20 > Date : 2003-6-30 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end on 15 > July 2003. First, thanks for a very high quality document. First I thought I couldn't find any issues in it, but I was wrong ;-) Generic note: there are normative references to yet unpublished (but some of them accepted) documents: DHCPv6, MLDv2, MIPv6, RFC1886bis, RFC2096bis, RFC2011bis; as you surely know, the document cannot be published before all of these have been published. Depending on the timeline this may or may not be an issue. Personally, I'm most worried about MLDv2 and RFC20{11,96}bis status in this regard. ... And to the details (editorials and others are mixed up this time..) Nodes MUST always be able to receive fragment headers. However, if it does not implement path MTU discovery it may not need to send fragment headers. However, nodes that do not implement transmission of fragment headers need to impose limitation to payload size of layer 4 protocols. ==> I'm not sure what is referred to with the last sentence, in practice. When you try to send a data segment of 1300 bytes with UDP, the sendto() returns EMSGSIZE? I wonder how many apps that would break, but I guess this is not meant for devices which run any but very specific purpose apps... Receiving and processing Router Advertisements MUST be supported for host implementation s. However, the implementation MAY support the ==> s/implementation s/implementations/ If Path MTU Discovery is not implemented then the sending packet size is limited to 1280 octets (standard limit in [RFC-2460]). However, if this is done, the host MUST be able to receive packets with size up to the link MTU before reassembly. This is because the node at the other side of the link has no way of knowing less than the MTU is accepted. ==> actually, host MUST be able to receive packets with size up to the link MRU before reassembly. The important point here is that MTU theoretically could be different on the two ends of the link. I.e. administratively setting MTU to a lower value on the "stupid node" does not fix the issue. The term "link MTU" is used here; it could maybe be even slightly clearer to state it is indeed the physical limit of the link that sets the limit here. 4.5.1 IP Version 6 Addressing Architecture - RFC2373 The IPv6 Addressing Architecture [RFC-2373] MUST be supported. Currently, this specification is being updated by [ADDRARCHv3]. ==> forgot to update this after the release of ADDRARCHv3. ==> should one go to details on what portions of Addr-arch must be supported? 4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This specification MUST be supported for nodes that are hosts. Nodes that are routers MUST be able to generate link local addresses as described in this specification. From 2462: The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface. Duplicate Address Detection (DAD) MUST be supported. ==> (first paragraph) which parts of the spec, does this need elaboration? ==> this section can be read like "why routers MUST be able to generate link local addresses but not hosts?" -- which is not true: hosts need to do it because otherwise they would not support RFC2462, but RFC2462 says nothing of routers. So, I think some rewording in this section might make this distinction slightly clearer. 4.5.4 Default Address Selection for IPv6 Default Address Selection for IPv6 [DEFADDR] SHOULD be supported, if a node has more than one IPv6 address per interface or a node has more that one IPv6 interface (physical or logical) configured. If supported, the rules specified in the document MUST be implemented. A node needs to belong to one site, however there is no requirement that a node be able to belong to more than one site. This draft has been approved as a proposed standard. ==> add " - RFC3484" in the section title, and change the reference to RFC-3484 ==> the last paragraph can be removed as it has been published too. ==> discusses sites.. (in a few other places too, but it may be difficult to decide how to deal with them at this point) 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 Multicast Listener Discovery [RFC-2710] MUST be supported by nodes supporting multicast applications. A primary IPv6 multicast application is Neighbor Discovery (all those solicited-node mcast addresses must be joined). ==> the last part of the sentence is probably something that should have been spelled out but was forgotten.. :-) ==> One should probably add a short reference to draft-ietf-magma-mld-source-07, which clarifies a bootstrap issue with MLDv1. (Currently in IESG and nearing completion.) 6.1 Transition Mechanisms IPv6 nodes SHOULD use native address instead of transition-based addressing. ==> s/native address/native addressing/ (or the native addresses), or something. 6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 If an IPv6 node implement dual stack and/or tunneling, then RFC2893 MUST be supported. ==> s/implement/implements/ ? 7.1 Mobile IP Mobile IPv6 [MIPv6] specification defines requirements for the following types of nodes: - mobile nodes - correspondent nodes with support for route optimization - home agents - all IPv6 routers Hosts MAY support mobile node functionality. Hosts SHOULD support route optimization requirements for correspondent nodes. Routers do not need to support route optimization. Routers SHOULD support mobile IP requirements. ==> reword the last two paragraphs to: Hosts SHOULD support route optimization requirements for correspondent nodes. Routers do not need to support route optimization or home agent functionality. [or otherwise discuss home agent support?] Routers SHOULD support the generic mobile IP requirements. .... 128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is expected to The "HMAC-SHA-256-96 Algorithm and Its Use With IPsec" [ipsec-ciph- sha-256] MAY be supported. ==> broken references, should have been ID.ipsec-ciph-aes-cbc and the like in the XML? 8.4 Key Management Methods Manual keying MUST be supported IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast traffic. Where key refresh, anti-replay features of AH and ESP, or on-demand creation of SAs is required, automated keying MUST be supported. Note that the IPsec WG is working on the successor to IKE [SOI]. Key management methods for multicast traffic are also being worked on by the MSEC WG. ==> s/supported/supported./ ==> s/SAs/Security Associations (SAs)/ 9. Router Functionality This section defines general considerations for IPv6 nodes that act as routers. It is for future study if this document, or a separate document is needed to fully define IPv6 router requirements. ==> this sounds rather funny, reword ("if this document .. is needed to fully define ..") ==> maybe this should be moved to an appendix if the router requirements is intentionally left partial, and here only for a reminder? Network Management, MAY be supported by IPv6 nodes. However, for ==> s/, MAY/ MAY/ 10.1 MIBs ==> s/MIBs/Management Information Base Modules (MIBs)/ ? In a general sense, MIBs SHOULD be supported by nodes that support a SNMP agent. ==> s/a SNMP/an SNMP/ ==> reword like: s/MIBs SHOULD be supported/At least the following two MIBs SHOULD be supported/ ? The use of wide-area multicast communications has an increased risk from specific security threats, compared with the same threats in unicast [MC-THREAT]. ==> it would be have a better reference (e.g. an I-D or RFC) for these, or explain them in a slightly bit more verbose manner. I bet basically nobody will/have read the reference otherwise.. [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ==> probably some missing XML tag for the latter. [RFC-2373] Hinden, R. and Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. ==> ready for removal after some edits. [RFC-3019] B. Haberman, R. Worzella, "IP Version 6 Management Infor- mation Base for the Multicast Listener Discovery Proto- col", RFC3019, January 2001. ==> this reference is not used in the document. It merenkatu 11-13 ==> remove the non-ASCII char there :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 12 23:48:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6D6lx06016290; Sat, 12 Jul 2003 23:47:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6D6lxaN016289; Sat, 12 Jul 2003 23:47:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6D6lu06016282 for ; Sat, 12 Jul 2003 23:47:56 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6D6jeUu029906 for ; Sat, 12 Jul 2003 23:45:40 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6D6jXJg002891 for ; Sun, 13 Jul 2003 00:45:34 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6D6jTb19977; Sun, 13 Jul 2003 09:45:29 +0300 Date: Sun, 13 Jul 2003 09:45:29 +0300 (EEST) From: Pekka Savola To: Bob Hinden & Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-Reply-To: <4.3.2.7.2.20030702140452.02a49658@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2 Jul 2003, Bob Hinden & Margaret Wasserman wrote: > The chairs believe that this draft resolves the issues raised by the > IESG. Given the time that has elapsed, we thought it was important to have > another working group last call. Changes in this draft include: > > - Move applicability statement to start of document and update > introduction. > - Removed Qtypes query capabilities > - Limit returned TTL in node name to zero and removed text describing > non-zero TTLs. > - Remove text about A6 records > - Change to have all new Qtypes require IETF approval > - Updated security considerations > > The reasoning behind this set of changes was to resolve the issues raised > by the IESG and to maintain comparability with current shipping code. Node > Information Queries is shipping in the KAME and USAGI distributions and has > been found to be very useful for deploying IPv6 service and debugging > operational problems. > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end on 16 > July 2003. I've already commented on NIQ LC on other threads, but I'm sending in some other comments now.. The fundamental issues we should get consensus on quickly seem to be: - how much backward-compatibility we want preserve a) in the spec b) as possibilities in the existing implementations - how "good" (architecturally, design-wise, etc.) we want the NIQ mechanism to be Now, from my point of view, there are two options. 1) going for Experimental with a smaller amount of changes ==> and possibly revise later, _then_ breaking backward compat. 2) going for Proposed Standard with, if necessary, breaking backward compatibility IMHO, going for PS with the current spec is unacceptable. That aside, I honestly believe that something similar to Node Information queries (just a LOT simpler) is very useful e.g. in debugging and diagnostics operations, and possibly some other restricted scenarios (I work for an ISP NOC ;-). Likely, on-link queries, and queries restricted to specific requesters (e.g. those whose source address belongs to your site, or whose IPsec SA is good enough for you). major issues ------------ A lot of features should be removed; the spec seems to have enjoyed from a very extensive feature creep.. (On the other hand, by some modifications one might be able to evolve -- if we so desire -- NIQ's also to the direction of a replacement/augmentation of router-router discovery protocol like CDP, or to evolve to a generic router/host discovery protocol.) 1) NI Query ICMP codes and Qtypes implement similar functionality, leading to potential complications: Code For NI Query: 0 Indicates that the Data field contains an IPv6 address which is the Subject of this Query. 1 Indicates that the Data field contains a name which is the Subject of this Query, or is empty, as in the case of a NOOP or Supported Qtypes query. 2 Indicates that the Data field contains an IPv4 address which is the Subject of this Query. [...] The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be supported by any implementation of this protocol. Qtype 4 SHOULD be supported by any implementation of this protocol on an IPv4/IPv6 dual-stack node and MAY be supported on an IPv6-only node. 0 NOOP. 1 (unused) 2 Node Name. 3 Node Addresses. 4 IPv4 Addresses. ==> For example, what about NI code=0 w/ Qtype=2, or NI code=1 w/ Qtype=3? This seems like a totally unnecessary complexity to me. Whole Qtypes (or different ICMP codes for NI, just always use zero) could probably be removed completely. 2) Unnecessary complexity relating to IPv4 addresses. Itojun already pointed this out, but I believe everything returning IPv4 addresses (or requesting) should go away; in particular: - section 4, Code 2 - section 6, the last sentence of the first paragraph - section 6.3, flag C; last paragraph of this section - section 6.4 in entirety 3) Node names Qtype/generic syntax supports returning multiple node names. This seems like a completely useless feature: a node does not have multiple host names. Remove it; in particular: - section 6.2, s/Names/Name/ in the diagram; reword "Each name" in "Node Names; second paragraph at the end of page 6 and the beginning of page 7 4) The second paragraph of section 5 describes quite a complex mechanism to use for the formation of the NI Group Address. This seems useless; I assume it has originally been devised as a mechanism of filtering traffic on LAN's with a lot of nodes for not to overload them. I do not think that at least *this* is anything to be worried about. One could just use all-nodes link-local address, or just reserve another link-local address which all nodes implementing NIQ's would listen to. Plain & Simple. 5) The node addresses flags described in 6.3 are mostly useless. They seem only useful in scenarios where there are too many addresses that they don't fit in one response message. In that case, we may have to devise a mechanism to serialize messages or fragment them anyway. Otherwise, the only useful flag seems like an indication of whether to receive: - the addresses on this link, and virtual addresses on top of that *) - all addresses of the node Note: reporting link-local addresses should not be done except with the first option only. *) the definition could be like: "Address independent of any network interface (for example those assigned on the loopback interface)" 6) In Node Addresses, separate 32-bit TTL for each address is useless and could be removed. This is not a big source of complication though, just a remnant for backward compat. (Similarly, a single TTL in 6.2 is in a similar state.) ..... Another big issue is clarifying the area of applicability and consequently revising the security mechanisms connected to it. IMHO, the following might be adequate: Queries would be sent with Hop Count = 255. 1) link-local (those whose Hop Count is 255) queries are always answered. These include those to link-local scope addresses, and those to global addresses that just happen to be your neighbors. 2) off-link queries which have Hop Count smaller than 255 have to be separately authorized/authenticated somehow, otherwise the default MUST be disabled. Possibly good ones include: a) source address belongs to a list of allowed prefixes (default could be to allow your own site, if that information (ie. the prefix length) is easily obtainable) [note that this is OK because the reply goes to the same address as source, if you spoof your source, it doesn't matter] b) an IPsec security association .. in particular, answering a query from basically anyone in the Internet by default MUST NOT be enabled unless explicitly configured. In particular, the current security considerations text is rather weak: This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol SHOULD have a default configuration which refuses to answer queries from global- scope [3513] addresses. The information learned via this protocol SHOULD not be trusted for making security relevant decisions unless some other mechanisms beyond the scope of this document is used to authenticate this information. more or less substantial ------------------------ The applicability of these mechanics is currently limited to diagnostic and debugging tools. These mechanisms can be used to learn the addresses and names for nodes on the other end of a point-to-point link or nodes on a shared-medium link such as an Ethernet. This is very useful when debugging problems or when bringing up IPv6 service where there isn't global routing or DNS name services available. IPv6's large auto-configured addresses make debugging network problems and bringing up IPv6 service difficult without these mechanisms. An example of a IPv6 debugging tool using IPv6 Node Information Queries is the ping6 program in the KAME, USAGI, and other IPv6 implementations [KAME]. ==> the middle sentence (highlighted above) appears to assume that there is no IPv4 at all, and it's IPv6-only or nothing. A nice requirement in theory, but practically not so interesting. ==> s/a IPv6/an IPv6/ Data In a Query, the Subject Address or Name. In a Reply, Qtype-specific data present only when the ICMPv6 Code field is zero. The length of the Data may be inferred from the IPv6 header's Payload Length field [2460], the length of the fixed portion of the NI packet and the lengths of the ICMPv6 header and intervening extension headers. ==> aren't there any data length alignment/padding issues in ICMPv6? The Nonce should be a random or good pseudo-random value to foil spoofed replies. An implementation which allows multiple independent processes to send NI queries MAY use the Nonce value to deliver Replies to the correct process. Nonetheless, such processes MUST check the received Nonce and ignore extraneous Replies. ==> it might also be useful to log a warning in case you receive responses you haven't queried for (assuming the implementation keeps a short-lived record of these) -- especially if the response is directed to you and not multicast. If true communication security is required, IPsec [2401] must be used. Providing the infrastructure to authenticate NI Queries and Replies may be quote difficult outside of a well-defined community. ==> which brings us back to the applicability statement: I really don't think you could honestly deploy NIQ's under it's applicable environment in the scenario where you couldn't implement IPsec (and keying material in particular). ==> s/quote/quite/ Finally, if the Qtype is known and the response is allowed by local policy, the Responder must fill in the Flags and Reply Data of the NI Reply in accordance with the definition of the Qtype and transmit the NI Reply with an ICMPv6 source address equal to the Queried Address, unless that address was an anycast or a multicast address. If the Queried Address was anycast or multicast, the source address for the Reply SHOULD be one belonging to the interface on which the Query was received. ==> isn't the last sentence, at least, redundant in the face of Default Address Selection (which has overtaken NIQ's, spec-wise, which is why this draft even mentions this, I guess) Implementations SHOULD apply rate-limiting to NI responses to avoid being used in a denial of service attack. ==> note that the spec seems to apply rate-limiting only to failed or negative responses: not positive responses which are responded to. I think it might be useful to similarly rate limit positive responses, even though the rate-limit could be higher. editorial --------- ==> Add IPR considerations and copyrights sections IPv6 Node Information Queries ==> s/Node Information/Node Information (NI)/ ? Internet Draft ICMP Name Lookups June 26, 2003 ==> "ICMP name lookups" should be updated to be closer to "ICMP Node Information Queries" Address. A node receiving a NI Query will be termed a Responder ==> s/a NI/an NI/ without the domain. Where necessary, the cases of fully-qalified ==> s/qa/qua/ Five values of Qtype are specified in this document. ==> More likely four, or even less (hopefully) [the same in a few other places in the document, IIRC] Data In a Query, the Subject Address or Name. In a Reply, Qtype-specific data present only when the ICMPv6 Code field is zero. ==> s/data/data is/ 10. References ==> split the references -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 13 01:05:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6D85t06018241; Sun, 13 Jul 2003 01:05:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6D85s50018240; Sun, 13 Jul 2003 01:05:54 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6D85p06018233 for ; Sun, 13 Jul 2003 01:05:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6D83ZUu021892 for ; Sun, 13 Jul 2003 01:03:35 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6D83TmD006806 for ; Sun, 13 Jul 2003 01:03:29 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6D83OA20543; Sun, 13 Jul 2003 11:03:24 +0300 Date: Sun, 13 Jul 2003 11:03:23 +0300 (EEST) From: Pekka Savola To: Marcin Markowski cc: ipng@sunroof.eng.sun.com Subject: Re: Strange problem with BGP In-Reply-To: <28119604041.20030712225437@chabrowa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please bring this up on zebra-pj and/or Linux mailing lists, this is the wrong medium for these kind of reports. Thanks On Sat, 12 Jul 2003, Marcin Markowski wrote: > Few days ago our server was DDoSed and from this while some peers > can't connect. They are in idle state. I tried to clear bgp sessions, > restart bgpd, down tunnels and up it again, but this is for nothing. > I'm using zebra-pj on linux with kernel 2.4.21-grsec. In logs i have: > > 2003/07/12 22:35:28 BGP: [Event] BGP connection from host 3ffe:400c:feed::6 > 2003/07/12 22:35:28 BGP: 3ffe:400c:feed::6 [Event] Transfer temporary BGP peer to existing one > 2003/07/12 22:35:28 BGP: 3ffe:400c:feed::6 [Event] Accepting BGP peer delete > 2003/07/12 22:37:56 BGP: 3ffe:400c:feed::6 [Event] Connect start to 3ffe:400c:feed::6 fd 23 > 2003/07/12 22:37:56 BGP: 3ffe:400c:feed::6 [Error] bgp_read_packet error: Connection reset by peer > > This problem is only with few peers, other works fine. In logs from my peer > they have that same error "Connection reset by peer". Sometimes when > they restart bgpd session will up. Anyone know something about that? > > Regards, > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 13 14:47:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6DLlm06008460; Sun, 13 Jul 2003 14:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6DLlmRg008459; Sun, 13 Jul 2003 14:47:48 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6DLli06008452 for ; Sun, 13 Jul 2003 14:47:44 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6DLjTUY006679 for ; Sun, 13 Jul 2003 14:45:29 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6DLjOJg002440 for ; Sun, 13 Jul 2003 15:45:24 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 13 Jul 2003 14:45:23 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 13 Jul 2003 14:45:23 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 13 Jul 2003 14:45:23 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 13 Jul 2003 14:45:23 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 13 Jul 2003 14:45:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 w.g. Last Call on "IPv6 Node Requirements" Date: Sun, 13 Jul 2003 14:44:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Node Requirements" Thread-Index: AcNAILkD5uS+dYjmRO+bQ7Y/TmB2tgJZqLWA From: "Dave Thaler" To: X-OriginalArrivalTime: 13 Jul 2003 21:45:22.0961 (UTC) FILETIME=[10046810:01C34988] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6DLli06008453 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is a IPv6 working group last call for comments on advancing the > following document as an Informational RFC: > > Title : IPv6 Node Requirements > Author(s) : J. Loughney > Filename : draft-ietf-ipv6-node-requirements-04.txt > Pages : 20 > Date : 2003-6-30 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end on 15 > July 2003. I did find a bunch of editorial nits which I will send to the editor. The following issues are more substantive: Section 4.2: > Neighbor Unreachability Detection (NUD) ... is required for multicast. What does that mean? You don't do NUD for multicast addresses. 4.6: > supporting multicast applications. A primary IPv6 multicast > application is Neighbor Discovery (all those solicited-node mcast Neighbor Discovery is not an "application". ND is a network-layer function, not an application-layer function. Suggest: supporting multicast protocols and applications. A primary IPv6 multicast protocol is Neighbor Discovery (all those solicited-node multicast > 9. Router Functionality > This section defines general considerations for IPv6 nodes that act > as routers. It is for future study if this document, or a separate > document is needed to fully define IPv6 router requirements. > Currently, this section does not discuss routing protocols. This needs to be resolved before this document is published as an RFC. Making this document fully define router requirements would significantly delay publication (and this would certainly not be ready for last call). Hence, I think this document should not document router requirements at all, and leave that to a separate document. That is, I would suggest that section 9 be removed and put in a separate draft. 10: > Network Management, MAY be supported by IPv6 nodes. What does this mean? Does this specifically mean SNMP (if so say so). If not, what is the purpose of this sentence? It would basically be saying "A node MAY support whatever configuration mechanism it supports." which seems odd to say. > In a general sense, MIBs SHOULD be supported by nodes that support a Any MIBs in particular or just whatever the implementor wants? For example are the MIBs mentioned in 10.1.1 and 10.1.2 SHOULDs or not? 12: There's a lot of normative references to works in progress. Will this hold up publication of this document until they're all RFCs? If so, it might be good to see if some can turned into informative references or removed. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 13 22:31:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6E5VZ06020034; Sun, 13 Jul 2003 22:31:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6E5VYXR020033; Sun, 13 Jul 2003 22:31:34 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6E5VV06020026 for ; Sun, 13 Jul 2003 22:31:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6E5TGUY016416 for ; Sun, 13 Jul 2003 22:29:16 -0700 (PDT) Received: from mailout1.samsung.com ([203.254.224.24]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6E5TAmD024626 for ; Sun, 13 Jul 2003 22:29:11 -0700 (PDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HI000K271VI5D@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 14 Jul 2003 14:28:30 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HI000NWM1UH1Z@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 14 Jul 2003 14:27:54 +0900 (KST) Received: from JAYABHARATHI ([107.108.7.84]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HI000GCP1UBMF@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 14 Jul 2003 14:27:53 +0900 (KST) Date: Mon, 14 Jul 2003 10:52:13 +0530 From: Jayabharathi Subject: doubt in IPv6 Default address selection To: ipng@sunroof.eng.sun.com Message-id: <007e01c349c7$e669f890$54076c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_StuqpGD3LOBOlTY9wvhxjA)" X-Priority: 3 X-MSMail-priority: Normal References: <4.3.2.7.2.20030623112301.02735318@mailhost.iprg.nokia.com> <3EF816E8.000001.00468@OLNRAO.sisodomain.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_StuqpGD3LOBOlTY9wvhxjA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi , I got a doubt while reading rfc 3484(Default Address Selection for Internet protocol version 6). The deafult policy table is given as follows, Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 If a destination address which is not mapping to any of the listed prefixes in the policy table, what should be the precedence value to be used. For example, a destination address prefix 3ffe::/16 is given, what should be the precedence used in this case??? One more doubt, Each and every prefix presented in the default policy table maps to an unique address type, Can't we make it as address type, instead of Prefix while implementing the same. Pls clarify regds Jaya --Boundary_(ID_StuqpGD3LOBOlTY9wvhxjA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi ,
 
I got a doubt while reading rfc 3484(Default Address Selection for Internet protocol version 6).
 
The deafult policy table is given as follows,
 
Prefix        Precedence Label
      ::1/128               50     0
      ::/0                      40     1
      2002::/16           30     2
      ::/96                    20     3
      ::ffff:0:0/96         10     4
 
If a destination address which is not mapping to any of the listed prefixes in the policy table, what should be the precedence value to be used.
 
For example, a destination address prefix 3ffe::/16 is given, what should be the precedence used in this case???
 
One more doubt,
 
Each and every prefix presented in the default policy table maps to an unique address type,
Can't we make it as address type, instead of Prefix while implementing the same.
 
Pls clarify
 
regds
Jaya

--Boundary_(ID_StuqpGD3LOBOlTY9wvhxjA)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 05:04:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6EC4w06028968; Mon, 14 Jul 2003 05:04:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6EC4wd0028967; Mon, 14 Jul 2003 05:04:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6EC4r06028957 for ; Mon, 14 Jul 2003 05:04:54 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6EC2bUY025794 for ; Mon, 14 Jul 2003 05:02:38 -0700 (PDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6EC2Wwq003087 for ; Mon, 14 Jul 2003 06:02:32 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI0001GXK48BY@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 14 Jul 2003 06:02:32 -0600 (MDT) Received: from sun.com ([81.160.135.242]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI0000USK3AFP@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 14 Jul 2003 06:02:02 -0600 (MDT) Date: Mon, 14 Jul 2003 05:01:59 -0700 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "IPv6 Node Information Queries" In-reply-to: To: Dave Thaler Cc: itojun@iijlab.net, Michael Hunter , Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, July 11, 2003, at 03:21 PM, Dave Thaler wrote: > Itojun writes (in response to Michael Hunter): > >>> This looks like a strong draft. Several issues exist though. >>> >>> 1) There is no mention of RFC 3041 (privacy enhanced) addresses. > Both >>> the issue as to if they should be responded with and if they should > be >>> responded to needs to be addressed. >> >> just FYI from implementation POV: KAME implementation does not >> include RFC3041 addresses in the response by default. there's a >> configuration flag bit which makes the responder to include > RFC3041 >> addresses as well. >> >> i guess that sensible default would be not to include RFC3041 >> addresses. > > Unless you have a way to generate a temporary name for a temporary > addresses (e.g. one automatically generated from the address). Answering a temporary name is not the only issue. What do you do when somebody is sending a NIQ to your RFC3041 address asking for the list of your global addresses? If you respond, the little 'privacy' provided by RFC3041 goes out of the window. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 11:30:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6EIUq06012467; Mon, 14 Jul 2003 11:30:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6EIUqmU012464; Mon, 14 Jul 2003 11:30:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6EIUm06012452; Mon, 14 Jul 2003 11:30:48 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6EISWUu002511; Mon, 14 Jul 2003 11:28:32 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6EISRAh027487; Mon, 14 Jul 2003 12:28:27 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 4660FEB27; Mon, 14 Jul 2003 13:28:26 -0500 (CDT) Received: from whitestar.zk3.dec.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 5259024C6; Mon, 14 Jul 2003 11:28:23 -0700 (PDT) Received: from hp.com by whitestar.zk3.dec.com (8.12.6/1.1.29.3/18Jul02-1258PM) id h6EISN7W098300; Mon, 14 Jul 2003 14:28:24 -0400 (EDT) Message-ID: <3F12F647.7080805@hp.com> Date: Mon, 14 Jul 2003 14:28:23 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.3b) Gecko/20030318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 Advanced Socket API extension for Mobile IP References: <200307120118.h6C1IKtf569136@jurassic.eng.sun.com> In-Reply-To: <200307120118.h6C1IKtf569136@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Samita Samita Chakrabarti wrote: > > Do you mean other destination or hop-by-hop options or routing header ? Here is what I mean. If an applications specifies multiple options in the same ancillary data structure (ex: a single cmsghdr with IPV6_DSTOPTS level), what happens if one of those options is HAO? Since rfc3542 restrictes itself to header ordering described in rfc2460, do the implentations have to extract the HAO and put it into a separate header or leave it alone? If the ancillar data is left alone and the entry cmsghdr converted into a single Destination Option Header, then do we follow the rules for placement of the Home Address Option? That may result in incorrect placement of other options specified in the same header. If the HAO is extractred into it's own header, the implemention suffers a penalty for parsing the header, copying the data (which requires additional memory allocations), and re-padding and re-alligning the original header to accound for the now missing option. Doing this in a send operation would very negatively effect performance. > It definitely simplifies if we put that restriction. With the restriction, a single ancilary data item would contain the HAO. Implementations may support multiple ancilary data items for each level (i.e multiple IPV6_DSTOPTS level items) since they already have to support multiple incomming headers of the same type. > Does anyone see any potential issue in having this restriction ? > >>that the checksumming should be on by default (similar to ICMPv6) >>with the ability to turn it off by the socket. The reason is that >>most Mobile IPv6 implementation are supported in the "kernel" and >>already do checksumming. The RAW socket interface can take advantage >>of that. So, at this poing NOT doing checksumming is an change >>to the expected behavior. To minimize that change, we can default to >>do checksumming with the ability to turn it off and let the applcation >>do it. > > > Only issue, I see that it then somewhat breaks what RFC3542 claims for RAW > socket behavior. Hence, setting IPV6_CHECKSUM for mobility header seems > to follow the following spec. > > " The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 > raw sockets, since this checksum is mandatory. Isn't checksumming for MIPv6 control messages also mandatory? At least that's the way I read the MIPv6 spec. Since you are already extending rfc3542, the extended mandatory checksumming (as required by the MIPv6 protocol) also makes sence to me. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX Network Group Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 00:23:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F7NZ06029487; Tue, 15 Jul 2003 00:23:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6F7NY1m029486; Tue, 15 Jul 2003 00:23:34 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F7NV06029479; Tue, 15 Jul 2003 00:23:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6F7LDUu007632; Tue, 15 Jul 2003 00:21:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6F7L72a020228; Tue, 15 Jul 2003 00:21:08 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A08E76A923; Tue, 15 Jul 2003 10:21:00 +0300 (EEST) Message-ID: <3F13AAC2.2070708@kolumbus.fi> Date: Tue, 15 Jul 2003 10:18:26 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krishna Kumar Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Using Mobile IPv6 over PPP links References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Krishna Kumar wrote: > > > Hi, > > Is there any work ongoing to support mobile ipv6 over PPP links ? I am > trying > to do this but am having problems during movement. When I move from the > HN to FN (disconnect the MN's serial cable from one network and reconnect > to another network), the device vanishes and I lose the home address. So > when I reconnect it to the FN, I get a new device and new foreign address, > but > since I don't have the home address any longer, movement fails. > > I don't know if any discussions have taken place about supporting mobility > over PPP. Please let me know if anyone has any insight into this, or if > there is > any work related to this (in IETF or elsewhere). I'm not sure I understand your problem. Your implementation should be able to remember its home address even across connectivity changes in its interfaces. When you reconnect your PPP you get a new care-of address, and then you do an end-to-end exchange with your home agent to register your care-of address as the current location for the home address. --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 00:43:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F7ht06029979; Tue, 15 Jul 2003 00:43:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6F7ht4E029978; Tue, 15 Jul 2003 00:43:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F7hq06029971; Tue, 15 Jul 2003 00:43:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6F7fYUY015078; Tue, 15 Jul 2003 00:41:34 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6F7fTeR028401; Tue, 15 Jul 2003 00:41:29 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6F7fOBd002984 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Jul 2003 00:41:25 -0700 (PDT) Received: from SIVAV.qualcomm.com ([10.50.68.32]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6F7fKix028928; Tue, 15 Jul 2003 00:41:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20030715003754.02c2cc18@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Jul 2003 00:41:19 -0700 To: Krishna Kumar , Jari Arkko From: Siva Veerepalli Subject: Re: [mobile-ip] Using Mobile IPv6 over PPP links Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: <3F13AAC2.2070708@kolumbus.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:18 AM 7/15/2003 +0300, Jari Arkko wrote: >Krishna Kumar wrote: >> >>Hi, >>Is there any work ongoing to support mobile ipv6 over PPP links ? I am >>trying >>to do this but am having problems during movement. When I move from the >>HN to FN (disconnect the MN's serial cable from one network and reconnect >>to another network), the device vanishes and I lose the home address. It sounds like your mip session ends when the serial cable is disconnected (i.e., carrier detect drop resulting in the device disconnect and hence mip session end). If that is the case, you mip client would have to survive carrier detect drop and PPP disconnect/renegotiation. Siva >> So >>when I reconnect it to the FN, I get a new device and new foreign address, >>but >>since I don't have the home address any longer, movement fails. >>I don't know if any discussions have taken place about supporting mobility >>over PPP. Please let me know if anyone has any insight into this, or if >>there is >>any work related to this (in IETF or elsewhere) > >I'm not sure I understand your problem. Your implementation should be >able to remember its home address even across connectivity changes >in its interfaces. When you reconnect your PPP you get a new care-of >address, and then you do an end-to-end exchange with your home agent >to register your care-of address as the current location for the >home address. > >--Jari > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 00:52:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F7qq06000191; Tue, 15 Jul 2003 00:52:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6F7qqq1000190; Tue, 15 Jul 2003 00:52:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F7qm06000182; Tue, 15 Jul 2003 00:52:48 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6F7oUUu013512; Tue, 15 Jul 2003 00:50:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6F7oPAh001373; Tue, 15 Jul 2003 01:50:25 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA21362; Tue, 15 Jul 2003 00:50:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6F7oNF31248; Tue, 15 Jul 2003 00:50:23 -0700 X-mProtect: <200307150750> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3zSF42; Tue, 15 Jul 2003 00:50:21 PDT Message-ID: <3F13B23E.32DD275@iprg.nokia.com> Date: Tue, 15 Jul 2003 00:50:22 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Kumar CC: Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Using Mobile IPv6 over PPP links References: <3F13AAC2.2070708@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Is there any work ongoing to support mobile ipv6 over PPP links ? I am > > trying > > to do this but am having problems during movement. When I move from the > > HN to FN (disconnect the MN's serial cable from one network and reconnect > > to another network), the device vanishes and I lose the home address. So > > when I reconnect it to the FN, I get a new device and new foreign address, > > but > > since I don't have the home address any longer, movement fails. > > > > I don't know if any discussions have taken place about supporting mobility > > over PPP. Please let me know if anyone has any insight into this, or if > > there is > > any work related to this (in IETF or elsewhere). dont assign the home address to the ppp0 interface. assigning the home address to a virtual interface would be a good idea. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 01:24:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F8OF06001263; Tue, 15 Jul 2003 01:24:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6F8OFSl001262; Tue, 15 Jul 2003 01:24:15 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F8O906001243 for ; Tue, 15 Jul 2003 01:24:09 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6F8LpUu021237 for ; Tue, 15 Jul 2003 01:21:52 -0700 (PDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6F8LkO5028625 for ; Tue, 15 Jul 2003 02:21:46 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI200MSJ4K9ZK@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 15 Jul 2003 02:21:46 -0600 (MDT) Received: from sun.com ([81.160.137.222]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI2009P34K79Q@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 15 Jul 2003 02:21:45 -0600 (MDT) Date: Tue, 15 Jul 2003 01:21:44 -0700 From: Alain Durand Subject: ICMP name lookup implementation survey To: ipng@sunroof.eng.sun.com Message-id: <5EEB3A2A-B69D-11D7-83E1-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would be curious to get feedback from implementors of draft-ietf-ipngwg-icmp-name-lookups-10.txt on what they have implemented and what they find useful. For example, we only implement the unicast mode and not the multicast mode when the subject of a query is an address and we do not implement queries where the subject is a name, as it is completely redundant with LLMNR. Also, we do not implement the flag to request the now deprecated Site Local addresses, but we implement the queries for IPv4 addresses. Last but not least, we implement it also over ICMPv4 (not defined in the spec yet). What do other implementors do? - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 02:02:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F92M06001891; Tue, 15 Jul 2003 02:02:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6F92L2c001890; Tue, 15 Jul 2003 02:02:21 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F92H06001883 for ; Tue, 15 Jul 2003 02:02:17 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6F900Uu001190 for ; Tue, 15 Jul 2003 02:00:00 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6F8xrAh021921 for ; Tue, 15 Jul 2003 02:59:54 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6CF8013; Tue, 15 Jul 2003 17:59:51 +0900 (JST) To: Alain Durand Cc: ipng@sunroof.eng.sun.com In-reply-to: Alain.Durand's message of Tue, 15 Jul 2003 01:21:44 MST. <5EEB3A2A-B69D-11D7-83E1-00039358A080@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ICMP name lookup implementation survey From: itojun@iijlab.net Date: Tue, 15 Jul 2003 17:59:51 +0900 Message-Id: <20030715085951.6CF8013@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I would be curious to get feedback from implementors of >draft-ietf-ipngwg-icmp-name-lookups-10.txt >on what they have implemented and what they find useful. > >For example, we only implement the unicast mode and not the multicast >mode when the subject of a query is an address and we do not >implement queries where the subject is a name, as it is completely >redundant with LLMNR. > >Also, we do not implement the flag to request the now deprecated Site >Local addresses, >but we implement the queries for IPv4 addresses. > >What do other implementors do? KAME have implemented this draft well before it became wg group item, and always keep trying to catch up with the spec. therefore, some portion is based on the old spec, and we have whole bunch of backward compatibility support (like support for old packet format when Qtype was not defined at all). what we have implemented: noop (Qtype=0) supported query types (Qtype=1) node name (Qtype=2) node addr (Qtype=3), except IPv4 mapped address what we have extended: node addr (Qtype=2), flag bit for anycast address (not sure if it is good idea, as anycast address can be categorized as global/site-local/link-local address) backward compatibility support for Qtype=2 response without DNS name encoding what we did not implement, and no plan on implmenting: IPv4 address query (Qtype=4) IPv4 mappped address in response (Qtype=3, C bit) user modifyable toggles: flag bit to decide whether or not to respond to NIQ at all flag bit to decide whether or not to respond to NIQ to RFC3041 address flag bit to decide whether or not to respond to node addresses NIQ (Qtype=2) - we may not want to reveal address on other interfaces when A bit is present, like intranet side of firewall machine what we see as "frills" (should be removed in -11): any IPv4 stuff site-local (Qtype=3, S bit) noop (Qtype=0), maybe - "anycast address" text in 6.1 looks a bit useful we think multicast portion is the most important of all usage, i.e. to learn link-local address of peer on a p2p link. this is the most important usage in our debugging situations. (i.e. discover neighbor when routing protocol goes mad) A -p2p-- B -----> NIQ, Qtype=1 to ff02::1 <----- NI reply with source address (fe80::B) and name another usage is to know the name of the machine which is sending rogue RA (this happens too many times in conference environment). admin rogue router | | ==+===============+== -----> NIQ, Qtype=1 to ff02::2 (or fe80::rogue) <----- NI reply with source address and name >Last but not least, we implement it also over ICMPv4 (not defined in >the spec yet). KAME does not do it. itojun PS: KAME folks, any clarifications/corrections are requested. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 02:33:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F9Xw06002249; Tue, 15 Jul 2003 02:33:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6F9Xw7L002248; Tue, 15 Jul 2003 02:33:58 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F9Xs06002241 for ; Tue, 15 Jul 2003 02:33:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6F9VbUu014402 for ; Tue, 15 Jul 2003 02:31:37 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6F9VVeR018728 for ; Tue, 15 Jul 2003 02:31:32 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D18C096 for ; Tue, 15 Jul 2003 18:31:28 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Tue, 15 Jul 2003 17:59:51 +0900. <20030715085951.6CF8013@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ICMP name lookup implementation survey From: itojun@iijlab.net Date: Tue, 15 Jul 2003 18:31:28 +0900 Message-Id: <20030715093128.D18C096@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I would be curious to get feedback from implementors of >>draft-ietf-ipngwg-icmp-name-lookups-10.txt >>on what they have implemented and what they find useful. as i said during meeting, i share pekka's opinion that combination of Qtype and ICMP code is unneededly complex, however i would say it is too late to change unfortunately. > flag bit to decide whether or not to respond to NIQ to > RFC3041 address this bit also affects whether or not to include RFC3041 address into Qtype=3 response. > flag bit to decide whether or not to respond to node addresses > NIQ (Qtype=2) - we may not want to reveal address on > other interfaces when A bit is present, like intranet > side of firewall machine typo: Qtype=3. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 02:45:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F9jP06002493; Tue, 15 Jul 2003 02:45:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6F9jONB002492; Tue, 15 Jul 2003 02:45:25 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6F9jL06002485 for ; Tue, 15 Jul 2003 02:45:21 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6F9h4UY015767 for ; Tue, 15 Jul 2003 02:43:04 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6F9gwAh004054 for ; Tue, 15 Jul 2003 03:42:58 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6F9grA09796; Tue, 15 Jul 2003 12:42:53 +0300 Date: Tue, 15 Jul 2003 12:42:53 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP name lookup implementation survey In-Reply-To: <20030715093128.D18C096@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Jul 2003 itojun@iijlab.net wrote: > >>I would be curious to get feedback from implementors of > >>draft-ietf-ipngwg-icmp-name-lookups-10.txt > >>on what they have implemented and what they find useful. > > as i said during meeting, i share pekka's opinion that > combination of Qtype and ICMP code is unneededly complex, > however i would say it is too late to change unfortunately. .. which is why I argued that we should not propagate our mistakes, and go for Experimental not PS and add a stronger applicability statement. I really think some functionality like a simple version of NIQ is useful: but if we intend it for general consumption rather than as (still!) a rather limited implementation of Internet-Draft, we must do it *properly*. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 03:25:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FAP006003196; Tue, 15 Jul 2003 03:25:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6FAP0uV003195; Tue, 15 Jul 2003 03:25:00 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FAOu06003188 for ; Tue, 15 Jul 2003 03:24:56 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FAMcUY024424 for ; Tue, 15 Jul 2003 03:22:38 -0700 (PDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6FAMWAh015826 for ; Tue, 15 Jul 2003 04:22:33 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI200LXOA5KZH@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 15 Jul 2003 04:22:32 -0600 (MDT) Received: from sun.com ([81.160.137.222]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI200724A5HQS@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 15 Jul 2003 04:22:32 -0600 (MDT) Date: Tue, 15 Jul 2003 03:22:31 -0700 From: Alain Durand Subject: Re: ICMP name lookup implementation survey In-reply-to: <20030715085951.6CF8013@coconut.itojun.org> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Message-id: <3E56E932-B6AE-11D7-83E1-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, July 15, 2003, at 01:59 AM, itojun@iijlab.net wrote: > we think multicast portion is the most important of all usage, i.e. > to learn link-local address of peer on a p2p link. this is the most > important usage in our debugging situations. > (i.e. discover neighbor when routing protocol goes mad) > > A -p2p-- B > -----> NIQ, Qtype=1 to ff02::1 > <----- NI reply with source address (fe80::B) and name > > another usage is to know the name of the machine which is sending > rogue > RA (this happens too many times in conference environment). > > admin rogue router > | | > ==+===============+== > -----> NIQ, Qtype=1 to ff02::2 (or fe80::rogue) > <----- NI reply with source address and name > There are actually 2 different usage of multicast. What you are describing is multicast when the subject is an IP address. The other case is multicast when the subject is a name and you're looking for an IP address. This second case is the one I do not think is that useful. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 03:30:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FAU606003304; Tue, 15 Jul 2003 03:30:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6FAU6Iu003303; Tue, 15 Jul 2003 03:30:06 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FAU306003296 for ; Tue, 15 Jul 2003 03:30:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FARjUu025456 for ; Tue, 15 Jul 2003 03:27:45 -0700 (PDT) Received: from sina.com (sina187-156.sina.com.cn [202.106.187.156] (may be forged)) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with SMTP id h6FARdeR015218 for ; Tue, 15 Jul 2003 03:27:39 -0700 (PDT) Received: (qmail 34823 invoked from network); 15 Jul 2003 10:27:35 -0000 Received: from unknown (HELO liusand) (218.22.21.6) by 202.106.187.156 with SMTP; 15 Jul 2003 10:27:35 -0000 Message-ID: <000b01c34abb$ca6bfb80$bc4026ca@liusand> From: "Liusand" To: Subject: Is 2001:250:5400:: a valid IPv6 address? Date: Tue, 15 Jul 2003 18:28:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h6FAU306003297 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I failed to configure it as a gateway for 2000::/3 route on both usagi-linux24-stable-20030214 and usagi-linux24-s20030609, the command, "ip -6 route add 2000::/3 via 2001:250:5400:: dev eth0" reported "RTNETLINK answers: Invalid argument". But I made it the "default" gateway easily on both Linux 2.4.18 kernel and Red Hat 2.4.20-8 kernel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 03:57:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FAv206003855; Tue, 15 Jul 2003 03:57:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6FAv2se003854; Tue, 15 Jul 2003 03:57:02 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FAux06003847 for ; Tue, 15 Jul 2003 03:56:59 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FAsfUu000905 for ; Tue, 15 Jul 2003 03:54:41 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6FAsZbQ005948 for ; Tue, 15 Jul 2003 04:54:35 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6FAsWl10396; Tue, 15 Jul 2003 13:54:32 +0300 Date: Tue, 15 Jul 2003 13:54:31 +0300 (EEST) From: Pekka Savola To: Liusand cc: ipng@sunroof.eng.sun.com Subject: Re: Is 2001:250:5400:: a valid IPv6 address? In-Reply-To: <000b01c34abb$ca6bfb80$bc4026ca@liusand> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Jul 2003, Liusand wrote: > I failed to configure it as a gateway for 2000::/3 route on both > usagi-linux24-stable-20030214 and usagi-linux24-s20030609, the command, > "ip -6 route add 2000::/3 via 2001:250:5400:: dev eth0" reported > "RTNETLINK answers: Invalid argument". But I made it the "default" > gateway easily on both Linux 2.4.18 kernel and Red Hat 2.4.20-8 kernel. You're running your system as a router, and 2001:250:5400:: (subnet router anycast address) points to the loopback, I suspect. But in any case, this is not the right place to ask such questions. Use USAGI mailing lists. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 10:56:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FHuG06028194; Tue, 15 Jul 2003 10:56:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6FHuFCX028193; Tue, 15 Jul 2003 10:56:15 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FHuC06028186; Tue, 15 Jul 2003 10:56:12 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FHrsUY025321; Tue, 15 Jul 2003 10:53:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6FHrmiR002488; Tue, 15 Jul 2003 11:53:48 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29026; Tue, 15 Jul 2003 10:53:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6FHriB04535; Tue, 15 Jul 2003 10:53:44 -0700 X-mProtect: <200307151753> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdl320dg; Tue, 15 Jul 2003 10:53:39 PDT Message-ID: <3F143FA4.463749CE@iprg.nokia.com> Date: Tue, 15 Jul 2003 10:53:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: bo.liu@philips.com, Suvidh.Mathur@lntinfotech.com CC: ipng@sunroof.eng.sun.com, Jari Arkko , Krishna Kumar , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Using Mobile IPv6 over PPP links References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob and Suvidh bo.liu@philips.com wrote: > > >dont assign the home address to the ppp0 interface. > >assigning the home address to a virtual interface > >would be a good idea. > > If so, how to proceed when the node go back its HN? thats simple. even though you assign the home address to a virtual interface, you always assume that ppp0 is the interface which actually connects to you to the visited link or home link. you compare prefix information in any router advert received on ppp0 with the home prefix. assigning the home address to a virtual interface is also very useful when you multiple egress interfaces (for eg a WLAN and a GPRS interface). you can use the same home address irrespective of whichever interface you use to connect to the network. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 12:26:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FJQT06006651; Tue, 15 Jul 2003 12:26:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6FJQTQm006650; Tue, 15 Jul 2003 12:26:29 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FJQP06006643 for ; Tue, 15 Jul 2003 12:26:25 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FJO6Uu016285 for ; Tue, 15 Jul 2003 12:24:07 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6FJO19l029674 for ; Tue, 15 Jul 2003 13:24:01 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2003 12:24:01 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 12:23:57 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jul 2003 12:24:00 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 12:24:00 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 12:23:59 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 12:23:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: doubt in IPv6 Default address selection Date: Tue, 15 Jul 2003 12:21:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: doubt in IPv6 Default address selection Thread-Index: AcNJyY9u6YH6AV0oQQ+kLYpXbadl6ABPLutm From: "Dave Thaler" To: "Jayabharathi" , X-OriginalArrivalTime: 15 Jul 2003 19:23:52.0742 (UTC) FILETIME=[A0474C60:01C34B06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6FJQP06006644 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jaya, Since the default route (::/0) is in the table you list below, every destination address will match an entry in the table. The address in your example matches the second row, so the precedence would be 40. Also, prefixes are more general than address types so you can express more granular policies. Hope this helps, -Dave ________________________________ From: owner-ipng@sunroof.eng.sun.com on behalf of Jayabharathi Sent: Sun 7/13/2003 10:22 PM To: ipng@sunroof.eng.sun.com Subject: doubt in IPv6 Default address selection Hi , I got a doubt while reading rfc 3484(Default Address Selection for Internet protocol version 6). The deafult policy table is given as follows, Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 If a destination address which is not mapping to any of the listed prefixes in the policy table, what should be the precedence value to be used. For example, a destination address prefix 3ffe::/16 is given, what should be the precedence used in this case??? One more doubt, Each and every prefix presented in the default policy table maps to an unique address type, Can't we make it as address type, instead of Prefix while implementing the same. Pls clarify regds Jaya -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 13:59:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FKxG06015582; Tue, 15 Jul 2003 13:59:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6FKxGAt015581; Tue, 15 Jul 2003 13:59:16 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FKx406015559; Tue, 15 Jul 2003 13:59:04 -0700 (PDT) Received: from eng.sun.com (vpn-129-156-96-34.EMEA.Sun.COM [129.156.96.34]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6FKuhte370116; Tue, 15 Jul 2003 13:56:44 -0700 (PDT) Message-ID: <3F146CA3.A246296F@eng.sun.com> Date: Tue, 15 Jul 2003 14:05:39 -0700 From: Samita Chakrabarti X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 Advanced Socket API extension for Mobile IP References: <200307120118.h6C1IKtf569136@jurassic.eng.sun.com> <3F12F647.7080805@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your response. I'll discuss the issues you raised at tomorrow's presentation. If time permits, we can ask for wg input. For the checksumming, I understand your point. But we have to be careful here, unless RFC3542 does not change, having kernel to do the MIPv6 checksumming by default may bring some incomaptibilties between non-mipv6 and mipv6 systems in terms of application behavior. From socketAPI perspective, IMHO, it's good idea to stick to the existing RFC3542 specification - but I'll still discuss the issue at the meeting tomorrow. -Samita Vladislav Yasevich wrote: > > Samita > > Samita Chakrabarti wrote: > > > > Do you mean other destination or hop-by-hop options or routing header ? > > Here is what I mean. If an applications specifies multiple options in the > same ancillary data structure (ex: a single cmsghdr with IPV6_DSTOPTS > level), what happens if one of those options is HAO? > > Since rfc3542 restrictes itself to header ordering described in rfc2460, > do the implentations have to extract the HAO and put it into a separate > header or leave it alone? > > If the ancillar data is left alone and the entry cmsghdr converted into > a single Destination Option Header, then do we follow the rules for > placement of the Home Address Option? That may result in incorrect > placement of other options specified in the same header. > > If the HAO is extractred into it's own header, the implemention suffers > a penalty for parsing the header, copying the data (which requires > additional memory allocations), and re-padding and re-alligning the > original header to accound for the now missing option. Doing this > in a send operation would very negatively effect performance. > > > It definitely simplifies if we put that restriction. > > With the restriction, a single ancilary data item would contain the HAO. > Implementations may support multiple ancilary data items for each level > (i.e multiple IPV6_DSTOPTS level items) since they already have to support > multiple incomming headers of the same type. > > > Does anyone see any potential issue in having this restriction ? > > > >>that the checksumming should be on by default (similar to ICMPv6) > >>with the ability to turn it off by the socket. The reason is that > >>most Mobile IPv6 implementation are supported in the "kernel" and > >>already do checksumming. The RAW socket interface can take advantage > >>of that. So, at this poing NOT doing checksumming is an change > >>to the expected behavior. To minimize that change, we can default to > >>do checksumming with the ability to turn it off and let the applcation > >>do it. > > > > > > Only issue, I see that it then somewhat breaks what RFC3542 claims for RAW > > socket behavior. Hence, setting IPV6_CHECKSUM for mobility header seems > > to follow the following spec. > > > > " The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 > > raw sockets, since this checksum is mandatory. > > Isn't checksumming for MIPv6 control messages also mandatory? At least > that's the way I read the MIPv6 spec. > > Since you are already extending rfc3542, the extended mandatory checksumming > (as required by the MIPv6 protocol) also makes sence to me. > > -vlad > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tru64 UNIX Network Group > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 16:27:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FNRG06027281; Tue, 15 Jul 2003 16:27:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6FNRGjl027280; Tue, 15 Jul 2003 16:27:16 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FNR506027218 for ; Tue, 15 Jul 2003 16:27:05 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FNOlUu006130 for ; Tue, 15 Jul 2003 16:24:47 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6FNOgiR013425 for ; Tue, 15 Jul 2003 17:24:42 -0600 (MDT) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19cZ9B-0003B5-00; Tue, 15 Jul 2003 16:23:49 -0700 Date: Tue, 15 Jul 2003 19:23:35 -0400 From: Keith Moore To: Erik Nordmark Cc: moore@cs.utk.edu, mrw@windriver.com, ipv6@nosense.org, ipng@sunroof.eng.sun.com Subject: Re: Taking two steps back (Was: Re: one question...) Message-Id: <20030715192335.5ad5f53b.moore@cs.utk.edu> In-Reply-To: References: <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 22 Jan 2003 03:34:19 +0100 (CET) Erik Nordmark wrote: ] Granted that this is a hard problem, but we seem to be spending emails ] on multiple subsets of this problem (in different WGs) thus I think it ] would be worth-while to concentrate thinking on the identifier/locator ] separation problem. Mumble. If you really want to split identifiers and locators then you need a fast, accurate, scalable, highly available, and robust mapping function between the two. That turns out to be very difficult, especially when you want things to continue working on isolated or ad hoc networks or on networks with intermittent connectivity to the outside world. Even then, there will still be cases where the right thing to do is to talk directly to a locator. And there will also be lots of apps for which a locator is "good enough" that probably shoudn't be made dependent on the mapping service. So I lean towards a view where you can use identifiers or locators interchangably - you can specify an identifier as a connection endpoint if that's what you want, or you can specify a locator, and the higher layer protocols mostly shouldn't care about the difference (though things like TCP might want to know if the locator changes so they can discard RTT estimates and initiate slow-start, and some apps protocols may have a preference as to which to use and may not perform as well if the preferred kind of name is not available). Which further implies that identifiers and locators look a lot like IP addresses. As for identifier-to-locator mapping, I think we'll have to be able to tolerate multiple coexisting mapping systems, one that works with global connectivity, another that works bottom-up. So if your destination happens to be near you, so you can still use the identifier to talk to that host even if the global mapping service is down. Of course, you'll want to verify the authenticity of the host you're talking to in either case - you shouldn't trust the mapping service. And you can use the locator as a last resort. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 16:33:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FNXs06028173; Tue, 15 Jul 2003 16:33:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6FNXsmH028172; Tue, 15 Jul 2003 16:33:54 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6FNXh06028110 for ; Tue, 15 Jul 2003 16:33:43 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FNVPUu009226 for ; Tue, 15 Jul 2003 16:31:25 -0700 (PDT) Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6FNVK9l010235 for ; Tue, 15 Jul 2003 17:31:20 -0600 (MDT) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19cZFy-0006oh-00; Tue, 15 Jul 2003 16:30:50 -0700 Date: Tue, 15 Jul 2003 19:30:35 -0400 From: Keith Moore To: Keith Moore Cc: moore@cs.utk.edu, Erik.Nordmark@Sun.COM, mrw@windriver.com, ipv6@nosense.org, ipng@sunroof.eng.sun.com Subject: Re: Taking two steps back (Was: Re: one question...) Message-Id: <20030715193035.267b6632.moore@cs.utk.edu> In-Reply-To: <20030715192335.5ad5f53b.moore@cs.utk.edu> References: <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> <20030715192335.5ad5f53b.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry about that; I replied to an ancient message. for some reason my mail server had this one marked as unread even though it was read a long time ago. Keith On Tue, 15 Jul 2003 19:23:35 -0400 Keith Moore wrote: ] On Wed, 22 Jan 2003 03:34:19 +0100 (CET) ] Erik Nordmark wrote: ] ] ] Granted that this is a hard problem, but we seem to be spending emails ] ] on multiple subsets of this problem (in different WGs) thus I think it ] ] would be worth-while to concentrate thinking on the identifier/locator ] ] separation problem. ] ] Mumble. If you really want to split identifiers and locators then you need a ] fast, accurate, scalable, highly available, and robust mapping function ] between the two. That turns out to be very difficult, especially when you ] want things to continue working on isolated or ad hoc networks or on networks ] with intermittent connectivity to the outside world. etc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 23:32:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6G6Wj06005904; Tue, 15 Jul 2003 23:32:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6G6WjCT005903; Tue, 15 Jul 2003 23:32:45 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6G6Wf06005896 for ; Tue, 15 Jul 2003 23:32:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6G6UNUu004571 for ; Tue, 15 Jul 2003 23:30:23 -0700 (PDT) Received: from server2003.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6G6UDtI007343 for ; Tue, 15 Jul 2003 23:30:18 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Taking two steps back (Was: Re: one question...) Date: Tue, 15 Jul 2003 23:30:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back (Was: Re: one question...) Thread-Index: AcNLKQQS1VJdwtwtTuiS7JqPkOL2IgAOkSMQ From: "Michel Py" To: "Keith Moore" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6G6Wf06005897 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > Even then, there will still be cases where the right thing to do > is to talk directly to a locator. And there will also be lots > of apps for which a locator is "good enough" that probably > shoudn't be made dependent on the mapping service. Agree. > So I lean towards a view where you can use identifiers or > locators interchangeably Also agree. > Which further implies that identifiers and locators look a lot > like IP addresses. Yeah. Or actually _are_ IPv6 addresses. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 02:20:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6G9KN06017193; Wed, 16 Jul 2003 02:20:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6G9KNEe017192; Wed, 16 Jul 2003 02:20:23 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6G9KJ06017185 for ; Wed, 16 Jul 2003 02:20:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6G9I1UY009476 for ; Wed, 16 Jul 2003 02:18:01 -0700 (PDT) Received: from mailout1.samsung.com ([203.254.224.24]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6G9HutI026961 for ; Wed, 16 Jul 2003 02:17:56 -0700 (PDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HI4003011TQ2F@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 16 Jul 2003 18:17:50 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HI40058I1TPR7@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 16 Jul 2003 18:17:50 +0900 (KST) Received: from ep_was15 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HI400L9N1TPCG@ms3.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 16 Jul 2003 18:17:49 +0900 (KST) Content-return: prohibited Date: Wed, 16 Jul 2003 18:17:48 +0900 From: =?EUC-KR?B?udq89sir?= Subject: [IPv6 WG] Update NDP To: ipng@sunroof.eng.sun.com, soohong.park@samsung.com Cc: Reply-to: soohong.park@samsung.com Message-id: <0HI400L9O1TPCG@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030716181748@soohong.park X-MTR: 20030716181748@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all At IPv6 WG meeting, we saw update step for IPv6 such as ICMP, Stateless Autoconfiguration, NDP, etc... In order to make these, we should have some reference and applicability statement documents I guess. I am trying to write a document as Applicability Statement for IPv6 DAD http://home.megapass.co.kr/~natpp00/ApplicabilityStatementforIPv6DAD.txt Could you let me know your comment/feedback ? Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics TEL:+82-31-200-4508 FAX:+82-31-200-3147 mailto:soohong.park@samsung.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 04:35:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GBZE06029097; Wed, 16 Jul 2003 04:35:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GBZDWt029096; Wed, 16 Jul 2003 04:35:13 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GBZA06029089 for ; Wed, 16 Jul 2003 04:35:10 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GBWpUu015236 for ; Wed, 16 Jul 2003 04:32:51 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GBWjRi003606 for ; Wed, 16 Jul 2003 05:32:45 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h6GBYKBo002720; Wed, 16 Jul 2003 20:34:20 +0900 Date: Wed, 16 Jul 2003 20:34:20 +0900 (JST) Message-Id: <20030716.203420.128469637.yoshfuji@linux-ipv6.org> To: Alain.Durand@Sun.COM Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP name lookup implementation survey From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <5EEB3A2A-B69D-11D7-83E1-00039358A080@sun.com> References: <5EEB3A2A-B69D-11D7-83E1-00039358A080@sun.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <5EEB3A2A-B69D-11D7-83E1-00039358A080@sun.com> (at Tue, 15 Jul 2003 01:21:44 -0700), Alain Durand says: > I would be curious to get feedback from implementors of > draft-ietf-ipngwg-icmp-name-lookups-10.txt > on what they have implemented and what they find useful. We, USAGI, have two implementations. One is in-kernel, and other is user-space daemon. We have tried supporting all qtypes and all flags. (However, anycast and configurable policy is not supported.) > Last but not least, we implement it also over ICMPv4 (not defined in > the spec yet). type/codes? Extension to RFC1788 "ICMP Domain Name Messages?" It would be another issue. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 05:08:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GC8u06002017; Wed, 16 Jul 2003 05:08:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GC8uTu002016; Wed, 16 Jul 2003 05:08:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GC8q06002009 for ; Wed, 16 Jul 2003 05:08:52 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GC6XUu022423 for ; Wed, 16 Jul 2003 05:06:33 -0700 (PDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6GC6RAh005602 for ; Wed, 16 Jul 2003 06:06:27 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI4002LW9MR7H@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 16 Jul 2003 06:06:27 -0600 (MDT) Received: from sun.com ([81.160.173.145]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI400EWX9MO73@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 16 Jul 2003 06:06:27 -0600 (MDT) Date: Wed, 16 Jul 2003 05:06:28 -0700 From: Alain Durand Subject: Re: ICMP name lookup implementation survey In-reply-to: <20030716.203420.128469637.yoshfuji@linux-ipv6.org> To: =?ISO-2022-JP?B?WU9TSElGVUpJIEhpZGVha2kgLyAbJEI1SEYjMVFMQBsoQg==?= Cc: ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: multipart/alternative; boundary="Boundary_(ID_BWxxHxhCpofF+JRN3jnT4g)" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Boundary_(ID_BWxxHxhCpofF+JRN3jnT4g) Content-type: text/plain; charset=ISO-2022-JP; format=flowed Content-transfer-encoding: 7BIT On Wednesday, July 16, 2003, at 04:34 AM, YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <5EEB3A2A-B69D-11D7-83E1-00039358A080@sun.com> (at Tue, 15 > Jul 2003 01:21:44 -0700), Alain Durand says: > >> I would be curious to get feedback from implementors of >> draft-ietf-ipngwg-icmp-name-lookups-10.txt >> on what they have implemented and what they find useful. > > We, USAGI, have two implementations. One is in-kernel, > and other is user-space daemon. > We have tried supporting all qtypes and all flags. > (However, anycast and configurable policy is not supported.) Do you implement queries with a name as subject using the multicast hash? If yes, did you find this useful? > >> Last but not least, we implement it also over ICMPv4 (not defined in >> the spec yet). > > type/codes? experimentally same as v6. This would have to be defined and reserved from IANA. - Alain. --Boundary_(ID_BWxxHxhCpofF+JRN3jnT4g) Content-type: text/enriched; charset=ISO-2022-JP Content-transfer-encoding: 7BIT On Wednesday, July 16, 2003, at 04:34 AM, YOSHIFUJI Hideaki / Hiragino Kaku Gothic Pro$B5HF#1QL@(B wrote: In article <<5EEB3A2A-B69D-11D7-83E1-00039358A080@sun.com> (at Tue, 15 Jul 2003 01:21:44 -0700), Alain Durand < says: I would be curious to get feedback from implementors of draft-ietf-ipngwg-icmp-name-lookups-10.txt on what they have implemented and what they find useful. We, USAGI, have two implementations. One is in-kernel, and other is user-space daemon. We have tried supporting all qtypes and all flags. (However, anycast and configurable policy is not supported.) Do you implement queries with a name as subject using the multicast hash? If yes, did you find this useful? Last but not least, we implement it also over ICMPv4 (not defined in the spec yet). type/codes? experimentally same as v6. This would have to be defined and reserved from IANA. - Alain. --Boundary_(ID_BWxxHxhCpofF+JRN3jnT4g)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 05:34:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GCYv06004670; Wed, 16 Jul 2003 05:34:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GCYv8P004667; Wed, 16 Jul 2003 05:34:57 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GCYo06004628 for ; Wed, 16 Jul 2003 05:34:50 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GCWVUY022802 for ; Wed, 16 Jul 2003 05:32:31 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GCWKRi001463 for ; Wed, 16 Jul 2003 06:32:23 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6GCWGT23799 for ; Wed, 16 Jul 2003 15:32:16 +0300 Date: Wed, 16 Jul 2003 15:32:15 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: a concern on bridge-like nd-proxies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I tried to raise this issue in the monday's meeting, but let me try to augement it a bit. I have a concern that we're trying to solve all the possible problems with bridge-like ND-proxies. (After all, we're engineers and we like to solve the problems..) But, I think we need to really consider whether we NEED or WANT to solve those problems. - what's the applicability of bridge-like ND-proxy? * replace the "(consecutive) simple NAT boxes for home" deployment model? * a model applicable in scenarios where deploying a router would not work * an ability to expand a /64 over a few links of different L2 media in home (or similar networks) * single admin domain/trusted environment (where SEND doesn't matter)? - what's the non-applicability of bridge-like ND-proxy? * building large ad-hoc networks * a mechanism to replace all of your Ethernet switches / bridges * a replacement for routers (probably missed some but..) Based on this, I have a very strong gut feeling that we're going into a very, very questionable direction if we want to implement e.g.: - spanning tree protocol (implying at least 3 boxes which are not connected in serial) - supporting multiple routers connected in different branches of the bridge mesh - *having to* support SEND in every case (sure, supporting SEND would be nice but if it's too much bother..) I don't think it's the goal to emulate bridges as closely as possible, as bridges (or Ethernet switches) are generic devices. I don't think we want this to be. Of course, we could write a problem statemetn for ND proxies but Im not sure it's required. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 05:56:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GCuj06006836; Wed, 16 Jul 2003 05:56:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GCujkp006833; Wed, 16 Jul 2003 05:56:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GCue06006807 for ; Wed, 16 Jul 2003 05:56:40 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GCsLUY027692 for ; Wed, 16 Jul 2003 05:54:21 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6GCsFiR025993 for ; Wed, 16 Jul 2003 06:54:15 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h6GCtVBo003172; Wed, 16 Jul 2003 21:55:31 +0900 Date: Wed, 16 Jul 2003 21:55:30 +0900 (JST) Message-Id: <20030716.215530.15416813.yoshfuji@linux-ipv6.org> To: Alain.Durand@Sun.COM Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP name lookup implementation survey From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20030716.203420.128469637.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article (at Wed, 16 Jul 2003 05:06:28 -0700), Alain Durand says: > > We, USAGI, have two implementations. One is in-kernel, > > and other is user-space daemon. > > We have tried supporting all qtypes and all flags. > > (However, anycast and configurable policy is not supported.) > > Do you implement queries with a name as subject using the multicast > hash? > If yes, did you find this useful? If you mean NI Group address, yes, we support it. Well, we can live without it, however, it is reasonable to have NI Group address as we do for NS (solicited node address). Of course, if some do not support this, it becomes unuseful. :-p > >> Last but not least, we implement it also over ICMPv4 (not defined in > >> the spec yet). > > > > type/codes? > > experimentally same as v6. This would have to be defined and reserved > from IANA. Hmm, okay... -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 06:08:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GD8G06008115; Wed, 16 Jul 2003 06:08:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GD8GcN008114; Wed, 16 Jul 2003 06:08:16 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GD8C06008107 for ; Wed, 16 Jul 2003 06:08:12 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GD5rUY000977 for ; Wed, 16 Jul 2003 06:05:54 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6GD5mAh024814 for ; Wed, 16 Jul 2003 07:05:48 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h6GD7NBo003301; Wed, 16 Jul 2003 22:07:23 +0900 Date: Wed, 16 Jul 2003 15:07:23 +0200 (CEST) Message-Id: <20030716.150723.38409414.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Subject: Re: a concern on bridge-like nd-proxies From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article (at Wed, 16 Jul 2003 15:32:15 +0300 (EEST)), Pekka Savola says: > I don't think it's the goal to emulate bridges as closely as possible, as > bridges (or Ethernet switches) are generic devices. I don't think we want > this to be. agreed. --yoshfuji -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 07:03:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GE3306012877; Wed, 16 Jul 2003 07:03:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GE32Hi012876; Wed, 16 Jul 2003 07:03:02 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GE2x06012869 for ; Wed, 16 Jul 2003 07:02:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GE0eUY020242 for ; Wed, 16 Jul 2003 07:00:40 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6GE0YtI015238 for ; Wed, 16 Jul 2003 07:00:34 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 53F1713; Wed, 16 Jul 2003 23:00:32 +0900 (JST) To: Alain Durand Cc: ipng@sunroof.eng.sun.com In-reply-to: Alain.Durand's message of Wed, 16 Jul 2003 05:06:28 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ICMP name lookup implementation survey From: itojun@iijlab.net Date: Wed, 16 Jul 2003 23:00:32 +0900 Message-Id: <20030716140032.53F1713@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Do you implement queries with a name as subject using the multicast >hash? >If yes, did you find this useful? KAME implements stuff with multicast address with hash(hostname) at the tail, but i don't think many people are using it (= we don't find it useful). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 07:04:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GE4j06013192; Wed, 16 Jul 2003 07:04:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GE4j2C013191; Wed, 16 Jul 2003 07:04:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GE4c06013160 for ; Wed, 16 Jul 2003 07:04:38 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GE2JUY020807 for ; Wed, 16 Jul 2003 07:02:19 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GE2CRi019974 for ; Wed, 16 Jul 2003 08:02:12 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6GE25u5012800 for ; Wed, 16 Jul 2003 16:02:06 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6GE20nb281108 for ; Wed, 16 Jul 2003 16:02:04 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA40732 for ; Wed, 16 Jul 2003 16:01:56 +0200 Message-ID: <3F155AD8.607CCCFB@hursley.ibm.com> Date: Wed, 16 Jul 2003 16:02:00 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: a concern on bridge-like nd-proxies References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd go a bit further. I messed around with a large bridged network for some years, and this included messing with ARP proxies and all the troubles they cause. Basically, making a level 2 device simulate level 3 functions is a kludge, and it gets even worse when attempting to "bridge" different LAN technologies. It probably has some failure modes that are very hard to analyze. So while I understand there may be a market for such devices, I would have very low confidence in our ability to publish a watertight spec. An informational document would seem the right way to go, rather than anything that looks like a standard. Brian Pekka Savola wrote: > > Hi, > > I tried to raise this issue in the monday's meeting, but let me try to > augement it a bit. > > I have a concern that we're trying to solve all the possible problems with > bridge-like ND-proxies. (After all, we're engineers and we like to solve > the problems..) > > But, I think we need to really consider whether we NEED or WANT to solve > those problems. > > - what's the applicability of bridge-like ND-proxy? > * replace the "(consecutive) simple NAT boxes for home" deployment > model? > * a model applicable in scenarios where deploying a router would not > work > * an ability to expand a /64 over a few links of different L2 media in > home (or similar networks) > * single admin domain/trusted environment (where SEND doesn't matter)? > > - what's the non-applicability of bridge-like ND-proxy? > * building large ad-hoc networks > * a mechanism to replace all of your Ethernet switches / bridges > * a replacement for routers > > (probably missed some but..) > > Based on this, I have a very strong gut feeling that we're going into a > very, very questionable direction if we want to implement e.g.: > > - spanning tree protocol (implying at least 3 boxes which are not > connected in serial) > - supporting multiple routers connected in different branches of the > bridge mesh > - *having to* support SEND in every case (sure, supporting SEND would be > nice but if it's too much bother..) > > I don't think it's the goal to emulate bridges as closely as possible, as > bridges (or Ethernet switches) are generic devices. I don't think we want > this to be. > > Of course, we could write a problem statemetn for ND proxies but Im not > sure it's required. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 07:35:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GEZ806016164; Wed, 16 Jul 2003 07:35:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GEZ8mw016163; Wed, 16 Jul 2003 07:35:08 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GEYw06016101 for ; Wed, 16 Jul 2003 07:34:58 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GEWdUu004556 for ; Wed, 16 Jul 2003 07:32:39 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6GEWXiR017681 for ; Wed, 16 Jul 2003 08:32:33 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jul 2003 07:32:33 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jul 2003 07:32:32 -0700 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Jul 2003 07:32:32 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jul 2003 07:32:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jul 2003 07:32:31 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jul 2003 07:33:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: a concern on bridge-like nd-proxies Date: Wed, 16 Jul 2003 07:32:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a concern on bridge-like nd-proxies Thread-Index: AcNLoz+4HN/6gjRGQU+qx68wuLE04gAAdQ0A From: "Dave Thaler" To: "Brian E Carpenter" , X-OriginalArrivalTime: 16 Jul 2003 14:33:44.0611 (UTC) FILETIME=[42A30F30:01C34BA7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6GEYw06016102 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter writes: > I'd go a bit further. I messed around with a large bridged > network for some years, and this included messing with ARP > proxies and all the troubles they cause. Basically, making > a level 2 device simulate level 3 functions is a kludge, and it > gets even worse when attempting to "bridge" different LAN > technologies. It probably has some failure modes that are very > hard to analyze. > > So while I understand there may be a market for such devices, > I would have very low confidence in our ability to publish > a watertight spec. An informational document would seem > the right way to go, rather than anything that looks like > a standard. Currently the IPv6 charter has a goal: Jul 03 Submit Proxy RA to IESG for Proposed Standard. While I have no problem with Informational if we do publish the approach, the WG should decide whether it wants to either change the charter, or go with a different approach for PS. It sounds like you (Brian) are arguing for the former. It was also pointed out to me after the meeting that the spanning tree protocol is optional even for L2 bridges, so it ought to be fine for us to say that it's optional here too. > Pekka Savola wrote: > > I have a concern that we're trying to solve all the possible problems > with > > bridge-like ND-proxies. (After all, we're engineers and we like to solve > > the problems..) > > > > But, I think we need to really consider whether we NEED or WANT to solve > > those problems. > > > > - what's the applicability of bridge-like ND-proxy? > > * replace the "(consecutive) simple NAT boxes for home" deployment > > model? > > * a model applicable in scenarios where deploying a router would not > > work > > * an ability to expand a /64 over a few links of different L2 media in > > home (or similar networks) > > * single admin domain/trusted environment (where SEND doesn't matter)? I agree with all of the above except "where SEND doesn't matter", which I would say "where SEND may or may not matter" (depending on the environment). > > - what's the non-applicability of bridge-like ND-proxy? > > * building large ad-hoc networks > > * a mechanism to replace all of your Ethernet switches / bridges > > * a replacement for routers > > > > (probably missed some but..) I agree with these. > > Based on this, I have a very strong gut feeling that we're going into a > > very, very questionable direction if we want to implement e.g.: > > > > - spanning tree protocol (implying at least 3 boxes which are not > > connected in serial) See my response to Brian. The draft discusses it since several folks who attended the Seattle interim meeting provided feedback that they considered it a requirement. > > - supporting multiple routers connected in different branches of the > > bridge mesh Agree this is not a requirement, and at the moment the spec does not support that. I think it is useful to document the limitations that are not met, and they shouldn't be a probably due to the applicability. > > - *having to* support SEND in every case (sure, supporting SEND would > be > > nice but if it's too much bother..) Agree. > > I don't think it's the goal to emulate bridges as closely as possible, > as > > bridges (or Ethernet switches) are generic devices. I don't think we > want > > this to be. I also don't think it's an explicit goal to NOT be generic. Rather this is a feature or lack of feature of any specific approach. What is, however, a nice feature (but not a requirement) is that if someone already implements an ARP proxy, then making it work for IPv6 should not be overly difficult. -Dave > > Of course, we could write a problem statemetn for ND proxies but Im not > > sure it's required. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 07:42:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GEfx06017022; Wed, 16 Jul 2003 07:41:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GEfx15017021; Wed, 16 Jul 2003 07:41:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GEfs06017008 for ; Wed, 16 Jul 2003 07:41:54 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GEdZUu006908 for ; Wed, 16 Jul 2003 07:39:36 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6GEdUiR021710 for ; Wed, 16 Jul 2003 08:39:30 -0600 (MDT) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19cnRI-0000us-00; Wed, 16 Jul 2003 07:39:28 -0700 Date: Wed, 16 Jul 2003 10:39:12 -0400 From: Keith Moore To: Brian E Carpenter Cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: Re: a concern on bridge-like nd-proxies Message-Id: <20030716103912.6627b730.moore@cs.utk.edu> In-Reply-To: <3F155AD8.607CCCFB@hursley.ibm.com> References: <3F155AD8.607CCCFB@hursley.ibm.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ] I'd go a bit further. I messed around with a large bridged ] network for some years, and this included messing with ARP ] proxies and all the troubles they cause. Basically, making ] a level 2 device simulate level 3 functions is a kludge, and it ] gets even worse when attempting to "bridge" different LAN ] technologies. Lately I find myself wondering if there's not room for a uniform layer 2.5 interface that is designed to work over a set of bridged 802-style layer 2 networks, but presents a slightly different interface to the host. So for instance hosts would be explicitly required to announce presence on a link (no more passive waiting for ARP requests), there would be an explicit L2.5 multicast join/leave (no more sniffing for L3 multicast requests), and there would be a uniform way for a host to authenticate to the link (no more PPPoE), with hubs having a way to know whether a particular host/port/address was authenticated and the ability to switch that host's traffic differently depending on that bit. The same authentication interface could be used as a gateway to control access to a larger network. The point is to explicitly design such an interface rather than resorting to more and more tricks. (has this already been worked on and I just don't know about it?) Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 08:07:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GF7X06018444; Wed, 16 Jul 2003 08:07:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GF7X5V018443; Wed, 16 Jul 2003 08:07:33 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GF7T06018436 for ; Wed, 16 Jul 2003 08:07:29 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GF5AUY012488 for ; Wed, 16 Jul 2003 08:05:10 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6GF549l011185 for ; Wed, 16 Jul 2003 09:05:04 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6GF52u5005004; Wed, 16 Jul 2003 17:05:02 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6GF52rd281786; Wed, 16 Jul 2003 17:05:02 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA55682; Wed, 16 Jul 2003 17:04:58 +0200 Message-ID: <3F1569A0.EF7A7290@hursley.ibm.com> Date: Wed, 16 Jul 2003 17:05:04 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Dave Thaler CC: ipng@sunroof.eng.sun.com Subject: Re: a concern on bridge-like nd-proxies References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk inline... Dave Thaler wrote: > > Brian Carpenter writes: > > I'd go a bit further. I messed around with a large bridged > > network for some years, and this included messing with ARP > > proxies and all the troubles they cause. Basically, making > > a level 2 device simulate level 3 functions is a kludge, and it > > gets even worse when attempting to "bridge" different LAN > > technologies. It probably has some failure modes that are very > > hard to analyze. > > > > So while I understand there may be a market for such devices, > > I would have very low confidence in our ability to publish > > a watertight spec. An informational document would seem > > the right way to go, rather than anything that looks like > > a standard. > > Currently the IPv6 charter has a goal: > Jul 03 Submit Proxy RA to IESG for Proposed Standard. > > While I have no problem with Informational if we do publish the > approach, the WG should decide whether it wants to either > change the charter, or go with a different approach for PS. It > sounds like you (Brian) are arguing for the former. I don't know that there is any other approach except to say "install a router". I hadn't really though about this before yesterday, when you reminded me of issues I was handling operationally more than ten years ago. So yes, I'm arguing for publishing off the standards track (which is either a charter update or an IESG decision, I guess). Brian > > It was also pointed out to me after the meeting that the spanning > tree protocol is optional even for L2 bridges, so it ought to be > fine for us to say that it's optional here too. > > > Pekka Savola wrote: > > > I have a concern that we're trying to solve all the possible > problems > > with > > > bridge-like ND-proxies. (After all, we're engineers and we like to > solve > > > the problems..) > > > > > > But, I think we need to really consider whether we NEED or WANT to > solve > > > those problems. > > > > > > - what's the applicability of bridge-like ND-proxy? > > > * replace the "(consecutive) simple NAT boxes for home" deployment > > > model? > > > * a model applicable in scenarios where deploying a router would > not > > > work > > > * an ability to expand a /64 over a few links of different L2 > media in > > > home (or similar networks) > > > * single admin domain/trusted environment (where SEND doesn't > matter)? > > I agree with all of the above except "where SEND doesn't matter", > which I would say "where SEND may or may not matter" (depending on the > environment). > > > > - what's the non-applicability of bridge-like ND-proxy? > > > * building large ad-hoc networks > > > * a mechanism to replace all of your Ethernet switches / bridges > > > * a replacement for routers > > > > > > (probably missed some but..) > > I agree with these. > > > > Based on this, I have a very strong gut feeling that we're going > into a > > > very, very questionable direction if we want to implement e.g.: > > > > > > - spanning tree protocol (implying at least 3 boxes which are not > > > connected in serial) > > See my response to Brian. The draft discusses it since several folks > who > attended the Seattle interim meeting provided feedback that they > considered it a requirement. > > > > - supporting multiple routers connected in different branches of > the > > > bridge mesh > > Agree this is not a requirement, and at the moment the spec does not > support that. I think it is useful to document the limitations that > are not met, and they shouldn't be a probably due to the applicability. > > > > - *having to* support SEND in every case (sure, supporting SEND > would > > be > > > nice but if it's too much bother..) > > Agree. > > > > I don't think it's the goal to emulate bridges as closely as > possible, > > as > > > bridges (or Ethernet switches) are generic devices. I don't think > we > > want > > > this to be. > > I also don't think it's an explicit goal to NOT be generic. Rather this > is a feature or lack of feature of any specific approach. > > What is, however, a nice feature (but not a requirement) is that if > someone > already implements an ARP proxy, then making it work for IPv6 should not > be overly difficult. > > -Dave > > > > Of course, we could write a problem statemetn for ND proxies but Im > not > > > sure it's required. > > > > > > -- > > > Pekka Savola "You each name yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 08:09:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GF9q06018587; Wed, 16 Jul 2003 08:09:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GF9qNP018586; Wed, 16 Jul 2003 08:09:52 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GF9l06018566 for ; Wed, 16 Jul 2003 08:09:47 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GF7SUY013344 for ; Wed, 16 Jul 2003 08:07:28 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GF6vRi000365 for ; Wed, 16 Jul 2003 09:06:58 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 16 Jul 2003 08:06:51 -0700 From: "Tony Hain" To: "'Thomas Narten'" Cc: Subject: RE: AD response to Site-Local Appeal Date: Wed, 16 Jul 2003 08:06:49 -0700 Message-ID: <020601c34bab$e307dce0$b70fa051@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200307091300.h69D0Zq10846@cichlid.adsl.duke.edu> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6GF9m06018568 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk inline - > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Thomas Narten > Sent: Wednesday, July 09, 2003 6:01 AM > To: Tony Hain > Cc: ipng@sunroof.eng.sun.com > Subject: AD response to Site-Local Appeal > > > [Note that this message is very long because it includes the > cited email messages verbatim; we are not aware of an IPv6 WG > mailing list archive that provide URL references for > individual emails.] > > Tony, > > We have reviewed your appeal of the IPv6 WG chairs calling of > consensus to deprecate site-local addresses from the IPv6 > architecture. We believe they have acted properly, and > indeed, have done an admirable job of moving the WG forward > on a complex, subtle and divisive topic that has troubled the > WG and the IETF as a whole for a long time. We find that the > chairs have responded reasonably and appropriately to your > appeal and agree with their response. Based on our review, we > reject your appeal in its entirety. As I expected. I agree the chairs have moved the WG, but 'forward' is not the direction. > > Some specifics: > > Your appeal seems to center around the point that different > people had different reasons for responding to the question > of whether or not to deprecate SLs and that those reasons > were different enough that it isn't appropriate to use those > differing reasons to conclude a single outcome, namely to > deprecate SLs. > > We disagree. The question asked by the chairs was not about > the differing reasons, the question was specifically about > SLs, and whether the WG wanted to deprecate them. That the > question referred specifically to deprecating site locals > (and not the reasons why one might do so) is obvious. It is > common in the IETF when deciding technical issues for > different people to have different reasons for coming to a > particular conclusion, or to weigh tradeoffs differently. In > the end, if there is consensus on the answer to a specific > question, we have consensus, even if the reasons for reaching > a particular outcome are not shared. Unfortunately this is a misinterpretation of my point. It is not focused on 'different people had different reasons', because we agree there will always be different perspectives and opinions. The focus was that a significant number of participants had the specific reason 'remove limited scoping', and this is not something the IETF gets to decide. It is an operational issue, and network managers will build networks where addresses have limited routing scope. > > In your response to the chairs [8], > > "Tony Hain" writes: > > > Margaret Wasserman wrote: > > > (3) You do not believe that there is rough consensus to > > > deprecate IPv6 site-local addressing, because people > > > provided different reasons for why they believe that > > > IPv6 site-local addressing should be deprecated. In > > > particular, some people want to deprecate the particular > > > model of site-local addressing defined in the scoped > > > addressing architecture (ambiguous, scoped addresses), > > > while others do not believe that we need a local > > > addressing mechanism at all. > > > I was not objecting to 'different reasons'. The specific > complaint is > > that many of YES votes were for removing the architectural > construct, > > or need for applications to deal with addresses that are only > > accessable over a limited scope. That is not in the purview of the > > IETF to decide, it is an operational decision of the > network manager. > > Those votes are not valid as a result. > > It is certainly within the purview of a WG (and/or IETF) to > decide what it wants to work on. Given that the IETF defined > a designated site-local prefix in RFC 1884 it can also choose > to undo that definition. This doesn't remove the ability for > network managers to do filtering, or remove their ability to > allocate address ranges for any particular purpose including > "local use". Moreover, if the WG does not want to work on > defining a model that requires applications to deal with > "addresses that are only accessible over a limited scope", it > can certainly make such a choice. This response highlights the point that not even you know what the meaning of the question was. If the group had been asked explicitly about removing limited scope, I agree the group gets to decide that. If the group had been explicitly asked about removing ambiguity from the addresses used for local scope, I agree the group gets to decide that. What the group was asked was; - Should we deprecate IPv6 site-local unicast addressing? - - Valid responses are: - - "YES -- Deprecate site-local unicast addressing". - "NO -- Do not deprecate site-local unicast addressing". with the additional 'guidance' from the chair for those in the room in San Francisco that '... if we eliminate it we will also have multiple choices about what exactly that means ...' & '... may have to handwave ...'. It was only after the fact that the chairs started providing interpretations as to what the question might mean. > > We also note that you seem to have a broader definition of > "scoping" (and the requirements that must be met by the > architecture to support such scoping) than many, and you > appear to be choosing to view the decision to deprecate SLs > as an attempt to outlaw (or eliminate) all forms of such > scoping, including the ability of site operators to filter on > arbitrary addresses (which you seem to include in your > definition). This view is incorrect. The decision to > deprecate SLs is just that. It is not a decision to outlaw > all forms of scoping or to forbid operators from (say) > filtering packets based on addresses. I am only reflecting the viewpoints of some votes for deprecation. Those votes are the invalid ones, and must be removed. > > > > Point (4): > > > > > > It is true that the IPv6 WG has not produced a WG document > > > that analyzes the operational requirements for local > > > addressing. However, we do not believe that this is a reason > > > to invalidate the IPv6 WG consensus to deprecate IPv6 > > > site-local unicast addressing. > > > You said it multiple times in SF yourself, the WG needs complete > > documentation to do an appropriate analysis. You appear to > be letting > > your desire to 'be right' get in the way of your ability to analyze > > your own responses. I don't understand how can you > objectively say 'we > > don't need a document describing the need for X to decide that we > > don't need X'? > > The key issue is whether the community believes it has enough > information to make a decision and is ready to make a > decision. When complex issues are being discussed it is > important that sufficient information is available and that > the issue has been thought through. In such cases it makes > sense to try to get detailed documentation listing the pros > and cons of the choices, e.g., as internet-drafts, or as part > of email discussions. So while the advance availability of an > internet-draft on deprecation would have been good, what > matters in the end is whether the community believes it has > enough information to make a decision. The key issue is the claim that we know that SL does not meet the requirements, yet there is no document identifying the requirements. The community could not make a collective informed decision since there was no common understanding of the requirements, or understanding of the outcome of the decision. > > During the meeting (early on) one person suggested that there > wasn't enough information on which to base a decision. But > this claim didn't appear to resonate with others, either in > the meeting or on the mailing list. If a large number of WG > participants had agreed with the claim, one would have > expected them to speak up. Hence one can infer that the WG > felt that there was sufficient information to make a decision. Or that since the question was ambiguous, they had independent expectations of the outcome. > > In [6] you say: > > > >>> There is a vast difference between identifying > direction of the > > group and the actual yes/no to deprecate SL question that > was asked. > > In fact all other indications from the chairs were that the > question > > was NOT about measuring direction of the WG, but actually > about their > > intent to have local scoped addresses removed from the > scoped address > > architecture and other documents. > > The question asked was about a general direction for the WG > to go in. The alternative to "direction" would have been a > question about an existing document (such as an update to the > addressing architecture doc to deprecate SLs) which was > clearly not what was being asked. You are correct that the ambiguous question did not ask about updates to specific documents. On the otherhand the chairs summary outcome to the mail list (your reference [1]) explicitly lists documents to be modified. > > In summary, the INT ADs do not agree with the points that you > have raised in your appeal, and we do not agree to overturn > the consensus of the IPv6 WG based on the issues that you > have raised. We would also like to point out that while we > disagree with your position on this particular issue, we do > recognize the contributions you have made to the IPv6 effort > and we realize that your appeal is motivated by your desire > to do what you believe is the right thing for IPv6. We hope > that you will accept our response and focus on working to > define the local addressing problem and solutions in the IPv6 > WG. It is important for the working group to move forward on > this issue. It is important to move forward, but throwing something out without understanding the real requirements for its existence, or having a replacement is a step backward. Although that is not the point here. The point is that the chairs asked an ambiguous question, a significant number of yes voters expressed opinions to remove limited scoping from the architecture, and that opinion is not something the IETF gets to decide. This invalidates the call for concensus. It is unfortunate but not surprising that this could not be resolved at this level. Tony > > Thomas Narten & Erik Nordmark > Internet Area ADs > > > References: > > [1] Message from chairs to list, announcing results of consensus call. > > Return-Path: owner-ipng@sunroof.eng.sun.com > Message-Id: > <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> > Date: Wed, 09 Apr 2003 15:11:04 -0700 > To: ipng@sunroof.eng.sun.com > From: Bob Hinden & Margaret Wasserman > Subject: Consensus on Site-Local Addressing > > Hi All, > > Well, that was fun! :-) > > All told, there were over 200 responses to the consensus call on IPv6 > site-local addressing, approximately 3-to-1 in favor of > deprecating IPv6 > site-local unicast addressing. The final count (including > the room and the > mailing list) was: 155 YES, 56 NO (211 Total). > > There were also a significant number of the people on both > sides of this > issue that voiced (in their original responses, or in > subsequent messages) > a strong belief that we should investigate alternative > mechanisms for local > addressing and local access control. > > The chairs have read all of the messages on the list, and > based on your > considerable input, we have determined that the IPv6 WG does > have rough > consensus to deprecate the usage of IPv6 site-local unicast > addressing AND > to investigate alternative mechanisms for local addressing > and local access > control. > > In particular, the IPv6 WG will work to accomplish the > following things in > parallel: > > (1) Publish an informational document that explains the issues > encountered with site-local addressing and our reasons > for deprecating IPv6 site-local unicast addresses. This > document will officially deprecate site-local addressing. > > (2) Remove site-local unicast addressing from the IPv6 > scoped addressing architecture I-D, and publish the > parts of the document on which we do have consensus > (i.e., link local addresses, multicast, etc.). This > will include a note that the IPv6 working group is > investigating other forms of local IPv6 addressing and > that the usage of any new forms of local addresses will be > documented elsewhere. > > (3) Update the IPv6 addressing architecture to indicate that the > usage of the FECO::/10 prefix for site-local addressing is > deprecated. To maintain backward compatibility with existing > implementations the prefix should be reserved and should not > be allocated for other purposes. > > (4) Define and publish the requirements for a local addressing > mechanism to provide: > - Addresses for disconnected networks. > - Addresses for intermittently connected networks. > - Addresses that support merging of sites. > - Stable local addresses for changing ISPs without > disrupting local communication. > Once we have consensus on the requirements, the IPv6 > WG will work on solutions for local addressing that > meet those requirements. > > (5) Define and publish the requirements for a local access > control mechanism, then work on a solution that meets > those requirements. > > Each of these new work items will need to be added to the > IPv6 WG charter > and will go through the normal IETF document processes. For > (4) and (5) it > is important to make the rest of the IETF community aware > that the IPv6 WG > is undertaking these tasks, so we will consider methods to > invite wider > review and discussion of these problems. > > IPv6 site-local addressing has been a contentious issue in > the IPv6 WG for > some time, and we are both glad to see the WG reach consensus on this > issue. This will allow us to complete and publish the IPv6 scoped > addressing architecture document, an important part of the > IPv6 specification. > > We hope that people on all sides of this issue will respect the rough > consensus of the WG, and will work with us to achieve the > goals outlined above. > > Thanks to everyone who expressed an opinion during this discussion. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > [2] First message from Tony Hain appealing decision. > > Return-Path: owner-ipng@sunroof.eng.sun.com > From: "Tony Hain" > To: "'Thomas Narten'" , > "'Erik Nordmark'" > Cc: > Subject: FW: Consensus on Site-Local Addressing > Date: Wed, 9 Apr 2003 17:41:32 -0700 > Message-Id: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> > > Thomas & Erik, > > Please consider this the second step in the appeal process, > as I have already discussed these issues with the chairs on > more than one occasion. > > 'we reject kings, presidents and voting...' > The consensus measurement on the mail list was much more > indicative of the real lack of it (60/40%), than what was > effectively ballot stuffing by WG visitors without a complete > context. There was a very short presentation in the apps open > area, intended to raise concerns and incite involvement, were > those in the apps area were agitated, then invited to the > IPv6 WG session in SF to discuss the potential issues. The > subsequent short discussion in the IPv6 WG showed there were > issues to work through, and at least one question voiced > about understanding the requirements. Rather than deal with > the issues raised, the chairs decided to call an ambiguous > question of yes/no for deprecation. > > While the chairs do in 2) recognize their interpretation of > the consensus that the WG will investigate other forms of > local addressing, there is no mention of ambiguity and the > rest of the wording of 1) & 2) can be interpreted as local > scope addressing is deprecated. The concern is that we will > end up with a document lacking local scope addressing, and > claims that we had consensus to remove local scope from the > architecture. Many of those who bothered to state why they > were expressing a yes opinion claimed ambiguity was the > reason, while others were only interested in removing special > handling for local scope addresses. Those are technically > different issues, so they need different questions. What we > have is an indication that many are unhappy with the status > quo, but a lack of recognition that the call ended up > combining yes opinions for removing ambiguity with yes > opinions for removing local scope addresses from the > architecture. From subsequent discussions with the chairs, it > is clear that was not their intent, but never the less that > is the result of the lack of clarity in this consensus call. > > '... we believe in rough consensus & running code' & from the > Tao : 'running code wins' On several related mail threads > there were many comments about running code, and at least > Brian Zill & Brian Haberman said they collectively had host, > application, and router implementations of the current SL > running. Point 3) even acknowledges there are existing > implementations. This consensus call intends to invalidate > the running code, and all we have to replace it is a promise > in 4) that if the group can ever agree that operational > requirements of the site network manager are worth solving, > we might start to work on solutions, subject to appropriate > charter updates. This whole discussion is based on the > argument that some developers couldn't create running code > for an arguably bogus scenario where topology locators are > blindly passed outside their scope of relevance. Bias was > given to the opinions of those with a lack of running code, > at the expense of, and with the specific intent of > invalidating the code that exists. > > There were also claims in the meeting and mail threads that > we have analyzed site local as currently defined, and it > doesn't meet the requirements. At the same time, there is a > recognition by many of the same people that we need to > develop a complete set of requirements. It should be obvious > that the analysis is flawed if the complete set of > requirements are not understood first. To that end, and in > the spirit of making progress, > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > editor on 4/8, and is offered as an attempt to document the > requirements for address space with a local scope of > relevance. It is clearly incomplete, and largely based on my > previous email on the subject. > > While I contest the claim that the Yes/No opinions expressed > measured consensus for a consistent interpretation of what > 'deprecate site local addresses' means, I do believe that a > set of work items for the group were identified. It is also > clear that we can add new work to a group at any time, > without the need to remove existing items first. I agree with > the chairs that items 4) & 5) are valid outcomes of the > subsequent discussion, though one thing that their > interpretation of the result does not make clear is the > meaning of 'accomplish the following things in parallel:'. In > talking to the chairs it appears the intent is to start the > work at the same time, but we need to avoid invalid > transition states, so parallel needs to mean that all 5 are > to be forwarded to the IESG at one time. In particular, > without solutions to the requirements in hand, any documents > for 1) & 3) that intend to deprecate the only local use > address space will simply create chaos, and might need to be > rescinded if the complete set of requirements shows a need > with no other technical approach. > > In short, I do not believe the consensus call measured the > opinions that were consistent the chairs interpretation of > the question, so the claimed results are invalid. I do > believe that the effort identified work items 4) & 5), with > the potential that 1) & 3) might follow if there are no > outstanding requirements for ambiguous address space. I > question the wisdom of 2), but will reserve judgment until > the complete text identifying further work is spelled out. In > any case, I hope this appeal can be dealt with at this level, > and that the overall effort results in an expedited charter > update. It is imperative that new approaches exist prior to > removal of the current, and there is a very real danger that > the current destructive energy will dissipate in the face of > the hard work of creating replacements. > > Tony > > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bob > > Hinden & Margaret Wasserman > > Sent: Wednesday, April 09, 2003 3:11 PM > > To: ipng@sunroof.eng.sun.com > > Subject: Consensus on Site-Local Addressing > > > > > > Hi All, > > > > Well, that was fun! :-) > > > > All told, there were over 200 responses to the consensus > call on IPv6 > > site-local addressing, approximately 3-to-1 in favor of > > deprecating IPv6 > > site-local unicast addressing. The final count (including > > the room and the > > mailing list) was: 155 YES, 56 NO (211 Total). > > > > There were also a significant number of the people on both > > sides of this > > issue that voiced (in their original responses, or in > > subsequent messages) > > a strong belief that we should investigate alternative > > mechanisms for local > > addressing and local access control. > > > > The chairs have read all of the messages on the list, and > > based on your > > considerable input, we have determined that the IPv6 WG does > > have rough > > consensus to deprecate the usage of IPv6 site-local unicast > > addressing AND > > to investigate alternative mechanisms for local addressing > > and local access > > control. > > > > In particular, the IPv6 WG will work to accomplish the > > following things in > > parallel: > > > > (1) Publish an informational document that explains the issues > > encountered with site-local addressing and our reasons > > for deprecating IPv6 site-local unicast addresses. This > > document will officially deprecate site-local addressing. > > > > (2) Remove site-local unicast addressing from the IPv6 > > scoped addressing architecture I-D, and publish the > > parts of the document on which we do have consensus > > (i.e., link local addresses, multicast, etc.). This > > will include a note that the IPv6 working group is > > investigating other forms of local IPv6 addressing and > > that the usage of any new forms of local addresses will be > > documented elsewhere. > > > > (3) Update the IPv6 addressing architecture to indicate that the > > usage of the FECO::/10 prefix for site-local addressing is > > deprecated. To maintain backward compatibility with existing > > implementations the prefix should be reserved and should not > > be allocated for other purposes. > > > > (4) Define and publish the requirements for a local addressing > > mechanism to provide: > > - Addresses for disconnected networks. > > - Addresses for intermittently connected networks. > > - Addresses that support merging of sites. > > - Stable local addresses for changing ISPs without > > disrupting local communication. > > Once we have consensus on the requirements, the IPv6 > > WG will work on solutions for local addressing that > > meet those requirements. > > > > (5) Define and publish the requirements for a local access > > control mechanism, then work on a solution that meets > > those requirements. > > > > Each of these new work items will need to be added to the > > IPv6 WG charter > > and will go through the normal IETF document processes. For > > (4) and (5) it > > is important to make the rest of the IETF community aware > > that the IPv6 WG > > is undertaking these tasks, so we will consider methods to > > invite wider > > review and discussion of these problems. > > > > IPv6 site-local addressing has been a contentious issue in > > the IPv6 WG for > > some time, and we are both glad to see the WG reach > consensus on this > > issue. This will allow us to complete and publish the IPv6 scoped > > addressing architecture document, an important part of the > > IPv6 specification. > > > > We hope that people on all sides of this issue will respect > the rough > > consensus of the WG, and will work with us to achieve the > > goals outlined above. > > > > Thanks to everyone who expressed an opinion during this discussion. > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG Chairs > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > > [3] Note from Tony Hain indicating he will followup with chairs first. > > > Return-Path: owner-ipng@sunroof.eng.sun.com > From: "Tony Hain" > To: "'Thomas Narten'" > Cc: "'Erik Nordmark'" , > > Subject: RE: FW: Consensus on Site-Local Addressing > Date: Thu, 10 Apr 2003 10:04:41 -0700 > Message-Id: <0f9101c2ff83$46f11ac0$ee1a4104@eagleswings> > > Thomas Narten wrote: > > Tony, > > > > > Please consider this the second step in the appeal process, > > as I have > > > already discussed these issues with the chairs on more than one > > > occasion. > > > > Discussing general issues with the chairs is not the same as > > finding disagreement with a specific action that the chairs > > have taken. I suspect you have done the former, but not the > > latter. If you feel that the chairs have erred, and that they > > have taken an action that isn't supported by the processes as > > outlined in RFC 2026 (and RFC 2418), an appeal might be > > warranted. To file an appeal, the process is outlined in RFC > > 2026. Start with the chairs, use RFC 2026/2418 as a guide for > > what are appropriate grounds for an appeal, and be clear > > about what action (or inaction) you specifically have issue > > with and want reconsidered. Suggesting what remedy you > > believe is appropriate would also be useful. > > Well I did specifically discuss a disagreement with the > action of the chairs in calling the ambiguous question, but I > will accept this deferral and redirect the current appeal > comment to the chairs. > > Tony > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > > [4] Note from chairs to Tony Hain requesting clarification > > Message-Id: <5.1.0.14.2.20030411094553.040e3040@mail.windriver.com> > Date: Fri, 11 Apr 2003 10:16:09 -0400 > To: Tony Hain > From: Margaret Wasserman > Subject: Your Appeal Regarding Site-Local Deprecation (Was: Consensus > on Site-Local Addressing) > Cc: Bob Hinden , Thomas Narten > , > Erik Nordmark , ipng@sunroof.eng.sun.com > > > Hi Tony, > > Based on your messages below, we understand that you are > attempting to start an appeal regarding the IPv6 WG's > decision to deprecate IPv6 site-local unicast addressing. > However, it is not entirely clear to us what action (or > inaction) you are appealing and on what grounds. We > understand that you disagree with the WGs decision to > deprecate IPv6 site-local unicast addressing without first > defining an alternative local addressing mechanism, but that > is not, in itself, grounds for an appeal. > > In order for us to consider this appeal, you should follow > the appeals process outlined in section 6.5.4 of RFC 2026. > Your appeal should include a "detailed and specific > description of the facts of the dispute". In particular, you > should make it clear exactly what action (or inaction) you > are appealing. > > You must also indicate what grounds you have for appealing > that action (or inaction). There are two possible grounds > for appeal of a WG action, listed in RFC 2026, section 6.5.1: > > (a) [your] own views have not been adequately considered > by the Working Group, or > (b) the Working Group has made an incorrect technical choice > which places the quality and/or integrity of the Working > Group's product(s) in significant jeopardy. > > It might also be possible to raise a process appeal if you > believe that the chairs violated the process for session > management described in section 3.3 of RFC 2418. > > Please explicitly state what you are appealing and explain > your grounds for appeal. You should also supply any > information necessary to explain and support your position. > Once we have this information, we will carefully consider > your appeal and provide a written reply. > > We understand that your appeal is motivated by your desire to > do the right thing for IPv6, and we will make every attempt > to deal with it fairly and promptly. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > >Reply-To: > >From: "Tony Hain" > >To: "'Bob Hinden'" , > > "'Margaret Wasserman'" > >Cc: > >Subject: FW: Consensus on Site-Local Addressing > >Date: Thu, 10 Apr 2003 10:31:47 -0700 > >X-Mailer: Microsoft Outlook, Build 10.0.4510 > >Importance: Normal > >X-MIME-Autoconverted: from quoted-printable to 8bit by > >sunroof.eng.sun.com > >id h3AHY8mh023731 > >Sender: owner-ipng@sunroof.eng.sun.com > > > >Bob & Margaret, > > > >As I noted to Thomas a few moments ago, I have already > raised concerns > >about the initial action of calling the ambiguous question. > I believe > >his response indicates I also need to raise a concern with you about > >this specific action of declaring consensus. As the content > of the note > >below indicates, there can be no consensus because the > question was not > >clear. At best, this activity shows a desire to change the > status quo, > >but it does not and can not indicate anything else. The consensus > >declaration must be voided. > > > >As I note below, steps 4) & 5) indicate work that the group > believes we > >should take on. *If* the result of that work leaves us with > no further > >use for the current definition for an ambiguous address > space, then in > >that context I believe steps 1) & 3) are appropriate. Until > then they > >are not, and are very likely to create chaos, particularly if done > >before 4) delivers complete alternatives. > > > >You must void the declaration of consensus, and should > recognize that > >the original question was not clear. > > > >Tony > > > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > > > Sent: Wednesday, April 09, 2003 5:42 PM > > > To: 'Thomas Narten'; 'Erik Nordmark' > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: FW: Consensus on Site-Local Addressing > > > > > > > > > Thomas & Erik, > > > > > > Please consider this the second step in the appeal process, as I > > > have already discussed these issues with the chairs on > more than one > > > occasion. > > > > > > 'we reject kings, presidents and voting...' > > > The consensus measurement on the mail list was much more > indicative > > > of the real lack of it (60/40%), than what was effectively ballot > > > stuffing by WG visitors without a complete context. There > was a very > > > short presentation in the apps open area, intended to > raise concerns > > > and incite involvement, were those in the apps area were > agitated, > > > then invited to the IPv6 WG session in SF to discuss the > potential > > > issues. The subsequent short discussion in the IPv6 WG > showed there > > > were issues to work through, and at least one question voiced > > > about understanding the requirements. Rather than deal with > > > the issues raised, the chairs decided to call an ambiguous > > > question of yes/no for deprecation. > > > > > > While the chairs do in 2) recognize their interpretation of the > > > consensus that the WG will investigate other forms of local > > > addressing, there is no mention of ambiguity and the rest of the > > > wording of 1) & 2) can be interpreted as local scope > addressing is > > > deprecated. The concern is that we will end up with a document > > > lacking local scope addressing, and claims that we had > consensus to > > > remove local scope from the architecture. Many of those > who bothered > > > to state why they were expressing a yes opinion claimed ambiguity > > > was the reason, while others were only interested in removing > > > special handling for local scope addresses. Those are technically > > > different issues, so they need different questions. What we > > > have is an indication that many are unhappy with the status > > > quo, but a lack of recognition that the call ended up > > > combining yes opinions for removing ambiguity with yes > > > opinions for removing local scope addresses from the > > > architecture. From subsequent discussions with the chairs, it > > > is clear that was not their intent, but never the less that > > > is the result of the lack of clarity in this consensus call. > > > > > > '... we believe in rough consensus & running code' & from > the Tao : > > > 'running code wins' On several related mail threads there > were many > > > comments about running code, and at least Brian Zill & Brian > > > Haberman said they collectively had host, application, and router > > > implementations of the current SL running. Point 3) even > > > acknowledges there are existing implementations. This > consensus call > > > intends to invalidate the running code, and all we have > to replace > > > it is a promise in 4) that if the group can ever agree that > > > operational requirements of the site network manager are worth > > > solving, we might start to work on solutions, subject to > appropriate > > > charter updates. This whole discussion is based on the > > > argument that some developers couldn't create running code > > > for an arguably bogus scenario where topology locators are > > > blindly passed outside their scope of relevance. Bias was > > > given to the opinions of those with a lack of running code, > > > at the expense of, and with the specific intent of > > > invalidating the code that exists. > > > > > > There were also claims in the meeting and mail threads > that we have > > > analyzed site local as currently defined, and it doesn't meet the > > > requirements. At the same time, there is a recognition by many of > > > the same people that we need to develop a complete set of > > > requirements. It should be obvious that the analysis is flawed if > > > the complete set of requirements are not understood > first. To that > > > end, and in the spirit of making progress, > > > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > > > editor on 4/8, and is offered as an attempt to document the > > > requirements for address space with a local scope of > > > relevance. It is clearly incomplete, and largely based on my > > > previous email on the subject. > > > > > > While I contest the claim that the Yes/No opinions expressed > > > measured consensus for a consistent interpretation of what > > > 'deprecate site local addresses' means, I do believe that > a set of > > > work items for the group were identified. It is also > clear that we > > > can add new work to a group at any time, without the need > to remove > > > existing items first. I agree with the chairs that items > 4) & 5) are > > > valid outcomes of the subsequent discussion, though one > thing that > > > their interpretation of the result does not make clear is the > > > meaning of 'accomplish the following things in parallel:'. In > > > talking to the chairs it appears the intent is to start the > > > work at the same time, but we need to avoid invalid > > > transition states, so parallel needs to mean that all 5 are > > > to be forwarded to the IESG at one time. In particular, > > > without solutions to the requirements in hand, any documents > > > for 1) & 3) that intend to deprecate the only local use > > > address space will simply create chaos, and might need to be > > > rescinded if the complete set of requirements shows a need > > > with no other technical approach. > > > > > > In short, I do not believe the consensus call measured > the opinions > > > that were consistent the chairs interpretation of the > question, so > > > the claimed results are invalid. I do believe that the effort > > > identified work items 4) & 5), with the potential that 1) > & 3) might > > > follow if there are no outstanding requirements for ambiguous > > > address space. I question the wisdom of 2), but will reserve > > > judgment until the complete text identifying further work > is spelled > > > out. In any case, I hope this appeal can be dealt with at this > > > level, and that the overall effort results in an expedited charter > > > update. It is imperative that new approaches exist prior to > > > removal of the current, and there is a very real danger that > > > the current destructive energy will dissipate in the face of > > > the hard work of creating replacements. > > > > > > Tony > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > [5] Note from Tony Hain clarifying his appeal. > > From: "Tony Hain" > To: "'Margaret Wasserman'" , "'Tony Hain'" > > Cc: "'Bob Hinden'" , > "'Thomas Narten'" , > "'Erik Nordmark'" , > > Subject: RE: Your Appeal Regarding Site-Local Deprecation > (Was: Consensus on Site-Local Addressing) > Date: Fri, 11 Apr 2003 10:07:44 -0700 > Message-Id: <106f01c3004c$deceb8b0$ee1a4104@eagleswings> > > Margaret Wasserman wrote: > > Hi Tony, > > > > Based on your messages below, we understand that you are > > attempting to start an appeal regarding the IPv6 WG's > > decision to deprecate IPv6 site-local unicast addressing. > > However, it is not entirely clear to us what action (or > > inaction) you are appealing and on what grounds. > > What is not clear about? > >> As the content of the note below indicates, there can > >> be no consensus because the question was not clear. > > >>> Many of those who bothered to state why they were > >>> expressing a yes opinion claimed ambiguity was the > >>> reason, while others were only interested in removing > >>> special handling for local scope addresses. Those are > >>> technically different issues, so they need different > >>> questions. > > >>> In short, I do not believe the consensus call measured > >>> the opinions that were consistent the chairs > >>> interpretation of the question, so the claimed results > >>> are invalid. > > > > We > > understand that you disagree with the WGs decision to > > deprecate IPv6 site-local unicast addressing without first > > defining an alternative local addressing mechanism, but that > > is not, in itself, grounds for an appeal. > > I can't disagree because the WG did not reach a decision, the chairs > declared one. There were different interpretations of what people were > voting YES for, therefore there was no decision. The chairs > combined YES > get rid of scoping, with YES get rid of ambiguity responses > to arrive at > a count. That does not constitute a WG decision. > > > > > In order for us to consider this appeal, you should follow > > the appeals process outlined in section 6.5.4 of RFC 2026. > > Your appeal should include a "detailed and specific > > description of the facts of the dispute". In particular, you > > should make it clear exactly what action (or inaction) you > > are appealing. > > >> You must void the declaration of consensus, and should > >> recognize that the original question was not clear. > > The question asked was: > Should we deprecate IPv6 site-local unicast addressing? > > The answers indicated that some interpreted that as deprecation of > address scoping, while others interpreted it as remove the ambiguity > associated with the current definition of the FEC0::/10 prefix. Those > are technically different issues and require separate > questions, yet the > chairs combined the disparate YES votes for each perspective > into their > own interpretation of what the original question meant. This is not WG > consensus. > > > > > You must also indicate what grounds you have for appealing > > that action (or inaction). There are two possible grounds > > for appeal of a WG action, listed in RFC 2026, section 6.5.1: > > > > (a) [your] own views have not been adequately considered > > by the Working Group, or > > (b) the Working Group has made an incorrect technical choice > > which places the quality and/or integrity of the Working > > Group's product(s) in significant jeopardy. > > The working group was mislead by an ambiguous question from > the chairs, > and has not reached a consensus on anything other than more work needs > to be done. Some of the YES votes were for removal of scopes from the > architecture, and others were for removing ambiguous > addresses as SL is > currently defined. Those are technically different concepts requiring > different questions. The declaration of consensus by the chairs > indicates an incorrect technical choice which places the integrity of > the WG product in significant jeopardy. > > > > > > It might also be possible to raise a process appeal if you > > believe that the chairs violated the process for session > > management described in section 3.3 of RFC 2418. > > Well since you brought it up, the agenda listed Limited Usage, and > Moderate Usage as the topics of discussion. Then (someone > that was there > should verify this, but I have been told that) your > presentation listed: > Full > Moderate > Exclusive > Limited > No SLs > and you started the presentation by saying that the first one and the > last one were not under consideration. Later you call an ambiguous > question attempting to accomplish the last one. Is that proper session > management? If people are led to believe a topic will not be > discussed, > they are less likely to come prepared to discuss it, or stick > around to > make sure their views are heard during a discussion. I can only > question, maybe others that were there will appeal based on > mismanagement. > > > > > Please explicitly state what you are appealing and explain > > your grounds for appeal. You should also supply any > > information necessary to explain and support your position. > > Once we have this information, we will carefully consider > > your appeal and provide a written reply. > > I believe I did this in the original note to Thomas & Erik, which was > included in the subsequent note of appeal to the chairs. I am > appealing > the declaration of consensus based on an ambiguous question, > where some > responses indicate remove addresses with local scope while others > indicate remove ambiguity of the address range. > > > > > We understand that your appeal is motivated by your desire to > > do the right thing for IPv6, and we will make every attempt > > to deal with it fairly and promptly. > > >From my reading, this response does not indicate a desire for > promptness. > > Tony > > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG Chairs > > > > > > >Reply-To: > > >From: "Tony Hain" > > >To: "'Bob Hinden'" , > > > "'Margaret Wasserman'" > > >Cc: > > >Subject: FW: Consensus on Site-Local Addressing > > >Date: Thu, 10 Apr 2003 10:31:47 -0700 > > >X-Mailer: Microsoft Outlook, Build 10.0.4510 > > >Importance: Normal > > >X-MIME-Autoconverted: from quoted-printable to 8bit by > > >sunroof.eng.sun.com > > >id h3AHY8mh023731 > > >Sender: owner-ipng@sunroof.eng.sun.com > > > > > >Bob & Margaret, > > > > > >As I noted to Thomas a few moments ago, I have already > > raised concerns > > >about the initial action of calling the ambiguous question. > > I believe > > >his response indicates I also need to raise a concern with > you about > > >this specific action of declaring consensus. As the content > > of the note > > >below indicates, there can be no consensus because the > > question was not > > >clear. At best, this activity shows a desire to change the > > status quo, > > >but it does not and can not indicate anything else. The consensus > > >declaration must be voided. > > > > > >As I note below, steps 4) & 5) indicate work that the group > > believes we > > >should take on. *If* the result of that work leaves us with > > no further > > >use for the current definition for an ambiguous address > > space, then in > > >that context I believe steps 1) & 3) are appropriate. Until > > then they > > >are not, and are very likely to create chaos, particularly if done > > >before 4) delivers complete alternatives. > > > > > >You must void the declaration of consensus, and should > > recognize that > > >the original question was not clear. > > > > > >Tony > > > > > > > > > > -----Original Message----- > > > > From: owner-ipng@sunroof.eng.sun.com > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > > > > Sent: Wednesday, April 09, 2003 5:42 PM > > > > To: 'Thomas Narten'; 'Erik Nordmark' > > > > Cc: ipng@sunroof.eng.sun.com > > > > Subject: FW: Consensus on Site-Local Addressing > > > > > > > > > > > > Thomas & Erik, > > > > > > > > Please consider this the second step in the appeal > process, as I > > > > have already discussed these issues with the chairs on > > more than one > > > > occasion. > > > > > > > > 'we reject kings, presidents and voting...' > > > > The consensus measurement on the mail list was much more > > indicative > > > > of the real lack of it (60/40%), than what was > effectively ballot > > > > stuffing by WG visitors without a complete context. There > > was a very > > > > short presentation in the apps open area, intended to > > raise concerns > > > > and incite involvement, were those in the apps area were > > agitated, > > > > then invited to the IPv6 WG session in SF to discuss the > > potential > > > > issues. The subsequent short discussion in the IPv6 WG > > showed there > > > > were issues to work through, and at least one question voiced > > > > about understanding the requirements. Rather than deal with > > > > the issues raised, the chairs decided to call an ambiguous > > > > question of yes/no for deprecation. > > > > > > > > While the chairs do in 2) recognize their interpretation of the > > > > consensus that the WG will investigate other forms of local > > > > addressing, there is no mention of ambiguity and the > rest of the > > > > wording of 1) & 2) can be interpreted as local scope > > addressing is > > > > deprecated. The concern is that we will end up with a document > > > > lacking local scope addressing, and claims that we had > > consensus to > > > > remove local scope from the architecture. Many of those > > who bothered > > > > to state why they were expressing a yes opinion claimed > ambiguity > > > > was the reason, while others were only interested in removing > > > > special handling for local scope addresses. Those are > technically > > > > different issues, so they need different questions. What we > > > > have is an indication that many are unhappy with the status > > > > quo, but a lack of recognition that the call ended up > > > > combining yes opinions for removing ambiguity with yes > > > > opinions for removing local scope addresses from the > > > > architecture. From subsequent discussions with the chairs, it > > > > is clear that was not their intent, but never the less that > > > > is the result of the lack of clarity in this consensus call. > > > > > > > > '... we believe in rough consensus & running code' & from > > the Tao : > > > > 'running code wins' On several related mail threads there > > were many > > > > comments about running code, and at least Brian Zill & Brian > > > > Haberman said they collectively had host, application, > and router > > > > implementations of the current SL running. Point 3) even > > > > acknowledges there are existing implementations. This > > consensus call > > > > intends to invalidate the running code, and all we have > > to replace > > > > it is a promise in 4) that if the group can ever agree that > > > > operational requirements of the site network manager are worth > > > > solving, we might start to work on solutions, subject to > > appropriate > > > > charter updates. This whole discussion is based on the > > > > argument that some developers couldn't create running code > > > > for an arguably bogus scenario where topology locators are > > > > blindly passed outside their scope of relevance. Bias was > > > > given to the opinions of those with a lack of running code, > > > > at the expense of, and with the specific intent of > > > > invalidating the code that exists. > > > > > > > > There were also claims in the meeting and mail threads > > that we have > > > > analyzed site local as currently defined, and it > doesn't meet the > > > > requirements. At the same time, there is a recognition > by many of > > > > the same people that we need to develop a complete set of > > > > requirements. It should be obvious that the analysis is > flawed if > > > > the complete set of requirements are not understood > > first. To that > > > > end, and in the spirit of making progress, > > > > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > > > > editor on 4/8, and is offered as an attempt to document the > > > > requirements for address space with a local scope of > > > > relevance. It is clearly incomplete, and largely based on my > > > > previous email on the subject. > > > > > > > > While I contest the claim that the Yes/No opinions expressed > > > > measured consensus for a consistent interpretation of what > > > > 'deprecate site local addresses' means, I do believe that > > a set of > > > > work items for the group were identified. It is also > > clear that we > > > > can add new work to a group at any time, without the need > > to remove > > > > existing items first. I agree with the chairs that items > > 4) & 5) are > > > > valid outcomes of the subsequent discussion, though one > > thing that > > > > their interpretation of the result does not make clear is the > > > > meaning of 'accomplish the following things in parallel:'. In > > > > talking to the chairs it appears the intent is to start the > > > > work at the same time, but we need to avoid invalid > > > > transition states, so parallel needs to mean that all 5 are > > > > to be forwarded to the IESG at one time. In particular, > > > > without solutions to the requirements in hand, any documents > > > > for 1) & 3) that intend to deprecate the only local use > > > > address space will simply create chaos, and might need to be > > > > rescinded if the complete set of requirements shows a need > > > > with no other technical approach. > > > > > > > > In short, I do not believe the consensus call measured > > the opinions > > > > that were consistent the chairs interpretation of the > > question, so > > > > the claimed results are invalid. I do believe that the effort > > > > identified work items 4) & 5), with the potential that 1) > > & 3) might > > > > follow if there are no outstanding requirements for ambiguous > > > > address space. I question the wisdom of 2), but will reserve > > > > judgment until the complete text identifying further work > > is spelled > > > > out. In any case, I hope this appeal can be dealt with at this > > > > level, and that the overall effort results in an > expedited charter > > > > update. It is imperative that new approaches exist prior to > > > > removal of the current, and there is a very real danger that > > > > the current destructive energy will dissipate in the face of > > > > the hard work of creating replacements. > > > > > > > > Tony > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > [6] More followup/clarification from Tony Hain > > From: "Tony Hain" > To: "'Bob Hinden'" , > "'Margaret Wasserman'" > Cc: > Subject: Appeal clarification ... > Date: Thu, 24 Apr 2003 22:45:30 -0700 > Message-Id: <047f01c30aed$e1f8ed20$261e4104@eagleswings> > > Everyone should check out the video at: > ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 > - 03202003 > - INT ipv6.mpg ... Starting at 1:02:05. It is very > instructional about > how not to call a question. The claimed consensus was over > (and I quote > from the AD & chair 2:18:20) 'just to be clear, deprecate I > assume means > ...' ... '...we may have to handwave - wave our hands around that a > little bit...'. > > In further discussion with the chairs, the appeal issue is still not > clear. This note attempts to make it clearer, and adds documentation > from the video of the SF session. > > Appeal: > The chairs have asserted an incorrect technical choice which > places the > quality and/or integrity of the Working Group's products in > significant > jeopardy. > > The working group did not make a decision as some of the YES > votes were > for removal of local scopes from the architecture, some for removal of > the need for apps to recognize that local scopes exist, > others were for > removing ambiguous addresses as SL is currently defined, and > others were > for removing the threat of NAT. Those are technically different > architectural concepts requiring different questions. In particular, > local scope addresses are the result of an operational choice, and not > in the purview of the IETF to decide. The IETF can decide to > set aside a > well known prefix for that use or not, but removing the well-known > prefix does not mean local scope addresses go away, or that > applications > are exempted from handling them correctly. It only means that there is > no consistent way to identify which addresses are local use. > > There is no document identifying the requirements and needs of the > network operators, therefore no reasonable and complete > evaluation could > result in the conclusion that deprecation is an appropriate > action. The > chairs chose to ask an ambiguous question that the group clearly had > different opinions about the meaning of, and shortly before > the initial > question was called there was an explicit statement about lack of > clarity in the consequences of the alternatives. Forcing a YES/NO > question for an end state rather than a process, without a widespread > understanding of the consequences and trade-offs, was an inappropriate > action by the chairs. > > The working group was mislead by an ambiguous question from > the chairs. > The asserted conclusion is invalid as the WG has not reached consensus > on anything other than more work needs to be done. > > > Background: > The entire open discussion in SF started off misled by a > bogus technical > assertion by the chair: > 1:42:04 ... it is always going to be possible to implement > wrong unless > we get rid of whole concept of private addresses ... you will always > have the possibility ... for leaking addresses if they exist in the > architecture > >>> Existence in the address architecture is not what creates > the possibility for limited scope addresses to be leaked, that only > allows identification of them. The thing the creates the > possibility for > leaking limited scope addresses outside their realm of > applicability is > the ignorance by the applications that the real network has limited > scope addresses and they require appropriate handling. > Removing any tag > for the application to identify which addresses have limited > scope only > ensures that they will be leaked. > > > There was no enumeration of the requirements for any > solution, therefore > no reasonable and complete evaluation that the current SL is > inadequate. > > 1:06:49 MW - you can only document the cost/benefit analysis > of a point > that's understood > > 1:36:30 - 'Do we have enough information to decide' > >>> on slide but not discussed > >>> discussion about overriding need to reach consensus > > 1:39:00 - Pekka - Exclusive is just broken ... if we want ... > >>> indicates need to understand requirements > > without further analysis, that requirement is met by access > prefix thing > access prefix is less intrusive and easier to implement > >>> where is the analysis that backs that up? > > 1:41:42 - Alain - ... if we want to avoid leaking ... > >>> indicates need to understand requirements > > 1:50:05 - Erik - we don't have enough information to decide yet, and > part of what I am looking for is so what are the benefits of these > things anyhow > >>> indicates need to understand requirements > > 1:52:33 - look at benefits before we try to decide something > - MW 'anything we are doing here should be a cost/benefit > tradeoff ... maybe we'll decide we need more information ... > we need to > do an intelligent cost/benefit analysis and have a supportable reason > for our choice > > 1:58:00 Leif - Erik's comments were first time I heard purported > benefits - applications shouldn't have to worry about > topology that's a > fundamental comparing the benefits with breaking fundamental > assumption > that apps shouldn't care about topology - its clear that you should > eliminate SL > >>> an informed conclusion after 5 1/2 minutes evaluation of a > partial verbal list of requirements ??? How many others were > in the same > place? > > 2:11:39 Dave - I agree with Keith's attempt to clarify the wording of > the question people are arguing for the eliminate proposal which there > isn't any draft about ... > > > In fact over the meeting it was clear that there was no common > understanding about what 'deprecate' means even by the > chairs, and this > carried onto the list discussion: > > 2:09:24 MW - that would be eliminating it, you can always bring > something back later someone can have a research group, but if take it > out of the specs, ** that is what eliminating it means ** > 2:09:35 Keith - alternate proposal for a way forward - I don't believe > the bit patterns that are defined for SL will be allocated for some > other use so I don't think we are eliminating them entirely, > but I want > to know if we can get a sense of the group that discouraging use of SL > is the appropriate way to move forward - part 1 part 2 - > identify the > things that SL was supposed to solve and work out alternate solutions > for those > 2:10:20 MW - instead of eliminate I think the right word would be > deprecate because I agree that we are not going to suddenly decide to > use those bits for something else - I agree with you on that but > discouraging ** is that deprecating? ** > 2:10:35 Keith - deprecating in a sense, it also leaves the idea that > until we find something else, you might have some usage of SL but the > plan is in the future to deprecate it > > 2:11:39 Dave - I agree with Keith's attempt to clarify the wording of > the question people are arguing for the eliminate proposal which there > isn't any draft about - this is a question to you to clarify the > question - Erik made and Dino added - zero conf asked what do > routers do > - do we want to enable a zero config thing - if so do you > want to enable > SL in a deprecated sense as Keith put it, for that or is the > proposal to > eliminate them and force zero config guys to not work because we don't > care about that, or to force them to use some other well known prefix > clarify which one of those is actually the proposal ? > >>> questions never answered or even discussed > > 2:12:51 Christian - if we say that we are going to eliminate > SL we have > to actually eliminate it and ** that means ** that we have to make it > explicit that at some point in the future all implementations are > supposed to discard any packets sent to the specific prefix > > 2:13:19 MW - I'll resay what I said earlier which is I had > said we would > say eliminate it or keep it and then we'd have multiple choices if we > kept it but apparently ** if we eliminate it we will also > have multiple > choices about what exactly that means ** > >>> 'multiple choices' how does that indicate a clear meaning > ??? > > 2:13:31 Erik - I think there area some details about what it > means if we > actually choose to eliminate ** I think that means ** that people at > their leisure can go ahead and delete whatever code they have that > currently recognizes FEC0 but they don't have to do it > tomorrow, because > we are not going to allocate this for any other purpose in the near > future, but it means that you don't have to add any more code, but you > can at your leisure delete what you have > > 2:14:05 Brian - I got up to say that the question that you > were going to > ask is one that ** I would have difficulty answering because > I wouldn't > vote for keeping SL unless I knew which of the options we > were going to > go for ** > >>> though voting against without understanding the consequences > didn't appear to be a problem > > 2:16:09 Bound - IPv4 NAT is a national security problem, at > least in the > US so ** what I am hearing to day is we should stop it and > not give any > credence to help proliferate them ** > >>> a belief that removing SL removes the threat of NAT ??? > > 2:16:45 Keith - ... ** the real trick is ** that applications > shouldn't > have to special case these things, Dns shouldn't have to special case > them, routing shouldn't; have to special case these things > >>> in other words applications continue to ignore the reality > of limited scope addresses, because without a well-known tag it is > impossible to special case them > > 2:18:20 Thomas, just to be clear, ** deprecate I assume means ** > somewhere to the left of the limited use model > - MW Yes, somewhere to the left of limited, the bits would > somehow become deprecated but probably you wouldn't get to reuse them > and we would not want to invalidate existing implementations so we may > have to wave our hands around that a little bit to make sure we do it > right - Bob, Christian just added - and probably needed to be > blackholed > >>> 'somewhere to the left'; 'somehow be deprecated'; & '...may > have to hand wave...' those are not clear indications of the > meaning of > the question or consequences of this action. > > 4/2 JB - Ambiguous addresses are a nightmare... > >>> a common theme > > 4/5 MW - The proposal is to deprecate a prefix in the addressing > architecture for which we have found no suitable use. > >>> Translation - we refuse to acknowledge the uses in shipping > code, though we do acknowledge that there is shipping code which uses > them. > > 4/5 DL - I thought we were voting on something more meaningful, i.e., > site-locals themselves. Now I understand that site-locals > do not exist > as such and we were just voting on the deprecation of the > prefix itself. > > 4/7 AW - I have come to the conclusion that the consensus > call email on > the list failed to adequately describe what a YES for deprecation > actually entailed, and has pretty effectively shot itself in the foot. > > 4/4 HA - Note: By "Deprecate Site-Local", ** I mean ** "Do not require > any application, host, router, protocol or IETF practice to > have to make > special > consideration for the idea that an IPv6 unicast address > outside of the > link-local range can refer to two different hosts". > > 4/4 PF - So, when I say I want Site Local deprecated ** I > mean ** I want > routing and addressing separated, and given that separation, > we have to > work on > solving the real problems we have with Internet today > > > While there was no single clear statement about what deprecate means > (though many architecturally different assertions), there was a clear > overriding concern by the chairs that some conclusion be > reached, even a > bad one: > 2:07:43 Erik - call for comments for SL Bob - give us a > second here > MW - if we are going reach any conclusion we can't accept a sudden > influx at mic > 2:08:45 Bob - if you want to support SL independent of usage > model come > to the mic 2:15:22 Bob by the way... MW cut off> we have to cut off > discussion with the people who are at the mic because we have > to try to > have some conclusion > >>> where was the fire? If the question had not been called in > SF, would the world have ended? Allowing 7 1/2 minutes for rebuttal > comments to a discussion that was not on the agenda, there were no > documents published, and people did not come to the meeting > prepared to > discuss is inappropriate in any case. Cutting off discussion just as > people were getting their thoughts together to form reasonable > statements about requirements is improper meeting management > and biases > any attempt to measure consensus. > > > > Despite the lack of agreement about exactly what deprecate > means, there > was a comment: > 2:17:19 MW - lets see, just a sec ... we are going to call a question > and the question is going to be a yes no question do we want to > deprecate SL addresses or do we not want to deprecate SL > addresses - we > realize that both of those answers no matter which answer you > give there > is more details that need to be worked out, but we are trying to get > what is the direction, does the group want to go away from SL > addressing, deprecate it work out how to get it out, does the > group want > to keep it and figure out what the right usage model is for > it OK, this > is a usage model issue. its is like do we want to support usage of SL > and come up with a usage model for it, or do we want to deprecate it > > which was not made to the mail list consensus call. > > >>> There is a vast difference between identifying direction of > the group and the actual yes/no to deprecate SL question that > was asked. > In fact all other indications from the chairs were that the > question was > NOT about measuring direction of the WG, but actually about > their intent > to have local scoped addresses removed from the scoped address > architecture and other documents. > > >>> This drive for a decision despite multiple statements (by > the chairs no less), that a cost/benefit analysis can only be > done with > a complete set of requirements. Where is the supportable > reason for the > asserted choice to change the architecture? For that matter, where is > the requirements document that a supportable reason would be > built from? > > > > In preparing the question, it should have been clear that the chairs > were not thinking this though clearly: > 2:18:57 Perry when you say it is a yes or no question, > therefore it must > be phrased differently than do we wish to deprecate them or do we not > wish to deprecate them > - MW I am tired, did I actually say that? > > Yet seconds later: > 2:19:20 MW Question - show of hands, how many people think that we > should deprecate SL addressing? > > > > > Keith's wording at 2:09:35 would have been an appropriate pair of > questions for the chairs to ask (I acutally support part 2), but the > chairs chose to ask an ambiguous question that the group (and even the > chairs) clearly had different and inconsistent opinions about the > meaning of. Shortly before the question was called there was > an explicit > statement about lack of clarity about the consequences of the > alternatives. The fact that many of the YES responses were > about removal > of local scope addresses invalidates the asserted conclusion. The > existence of limited scope addresses are an architectural > consequence of > operational choices, and not in the purview of the IETF to decide. > > Tony > > > PS: 2:14:05 Brian ... I also a comment that RFC 1597 is one > of the worst > end runs in the history of the IETF. > >>> I am arguing that through an ambiguous question this > desperate drive for a conclusion which intends to remove local scope > addresses from the architecture superseded it. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > [7] Chairs formal response to Tony Hain's appeal > > Message-Id: <5.1.0.14.2.20030428165715.046a3888@mail.windriver.com> > Date: Mon, 28 Apr 2003 17:02:02 -0400 > To: Tony Hain > From: Margaret Wasserman > Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: > Consensus on Site-Local Addressing) > Cc: ipng@sunroof.eng.sun.com, Thomas Narten , > Erik Nordmark , Bob Hinden > > > Hi Tony, > > We have considered your appeal regarding the IPv6 WG consensus > to deprecate site-locals. Based on our analysis, we believe > that your appeal makes the following points: > > (1) You believe that deprecating IPv6 site-local unicast > addressing is an incorrect technical choice that places > the work output of the IPv6 WG in jeopardy. > > (2) You believe that the question asked by the chairs > was insufficiently clear to be understood properly > by the WG. > > (3) You do not believe that there is rough consensus to > deprecate IPv6 site-local addressing, because people > provided different reasons for why they believe that > IPv6 site-local addressing should be deprecated. In > particular, some people want to deprecate the particular > model of site-local addressing defined in the scoped > addressing architecture (ambiguous, scoped addresses), > while others do not believe that we need a local > addressing mechanism at all. > > (4) You believe that it is invalid for the IPv6 WG to > deprecate site-local addressing without publishing an > IPv6 WG document that analyzes the operational requirements > for local addressing. Without this analysis document, you > believe that the IPv6 WG has made an uninformed choice. > > We will now respond to each of your points. > > -- > > Point (1): > > The chairs do not believe that deprecating IPv6 site-local addressing > is an incorrect technical decision that will place the work output > of the IPv6 WG in jeopardy. > > The consensus was to "deprecate" the usage of site-local addressing > instead of simply removing it. This was done purposely to avoid > interference with any current implementations or deployments > that might > use site-local addressing. In addition to the time it will take to > formally deprecate site-local addressing by publishing an RFC, the WG > understands that it will take some time after the publication > of an RFC > for implementations to change. The decision to deprecate site-local > addressing, rather than simply removing it, was made to avoid harm > to IPv6. > > In fact, we believe that the previous disagreement over the usage > of IPv6 site-local addressing was damaging to the WG, and that our > lack of consensus was delaying our work, particularly on the IPv6 > scoped addressing architecture. The consensus to deprecate > site-local addressing will allow us to move forward and complete > our work. > > --- > Point (2): > > The question was: > > "Should we deprecate IPv6 site-local unicast > addressing?" Possible answers were YES or NO. > > The chairs believe that this question was sufficiently clear > to be understood by the WG. This is supported by the following > points: > > - Over 200 people responded to the question. > > - Many of the responses on the list (both YES and NO > responses) included reasons or comments that > followed from the question in a way that indicated > that the responders understood the question. > > - There were only three requests for clarification of > this consensus call on the mailing list, two of which > were procedural. All of these requests were answered > promptly by the chairs. > > - The chairs sent the consensus results to the list > over two weeks ago, including a course of action for > the deprecation of site-local addressing. There > have been no objections from people who originally > expressed YES opinions that the chairs' course of > action fails to match their expectations. > > --- > > Point (3): > > The chairs do not believe that consensus on an issue is > invalidated by the fact that people have multiple reasons for > coming to the same conclusion. We suspect that this happens > in most WG consensus calls, and this is not a reason to > invalidate the consensus. > > All of the groups that you mentioned in your message agreed > that IPv6 site-local unicast addressing should be deprecated. > They may disagree on what we should do after deprecating site- > local addressing, but that does not invalidate the consensus > on this point. > > --- > > Point (4): > > It is true that the IPv6 WG has not produced a WG document that > analyzes the operational requirements for local addressing. However, > we do not believe that this is a reason to invalidate the IPv6 WG > consensus to deprecate IPv6 site-local unicast addressing. > > There has been considerable discussion and analysis of site- > local addressing performed over the past year, including > extensive discussions during three IETF sessions. There have > also been several drafts published on the subject, including one > draft that attempts to analyze the cost/benefit trade-offs > of site-local addressing. > > This period of discussion has offered sufficient time for anyone > who has an operational need for any of the currently-defined usage > models of site-local addressing to document those requirements in > an Internet-Draft and/or to discuss those requirements on the IPv6 > mailing list. > > During our discussions, several operational benefits of site-local > addressing have been raised on the IPv6 WG mailing list, > including benefits for disconnected sites, intermittently- > connected sites, renumbered sites, etc. We have also uncovered > several issues and complexities caused by the current model of > ambiguous, scoped site-local addressing, and we have determined > that this particular model places burdens on other parts of the > TCP/IP protocol suite, particularly routing protocols and > applications. > > In a recent phone discussion and in your appeal clarification, you > have indicated that the chairs should void responses from > people who do not think that the IPv6 WG should specify any type > of local addressing mechanism, because you believe that those > responders are uninformed about the operational conditions that > require the use of local addressing. > > While operational necessity is certainly an appropriate argument > to raise in support of your position that the IPv6 WG should > specify some mechanism for local addressing, the fact that you > disagree with the reasons that some people offered for why they > want to deprecate the current IPv6 site-local unicast addressing > mechanism does not invalidate their contribution to this consensus > call. > > It is the opinion of the chairs that the IPv6 WG did have > sufficient information to make an informed decision regarding > whether or not to deprecate IPv6 site-local unicast addressing. > > --- > > So, to summarize, the chairs do not agree with the points that you > have raised in your appeal, and we do not agree to overturn the > consensus of the IPv6 WG based on the issues that you have raised. > > Tony, while we disagree with your position on this particular > issue, we do respect your contributions to the IPv6 effort and > we realize that your appeal is motivated by your desire to do the > right thing for IPv6. We hope that you will accept our response > to your appeal and focus on working to define the local addressing > problem and solutions as we outlined in our email to the list. We > think it is important for the working group to move forward on this > issue. > > Best Regards, > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > [8] Tony Hain's reaction to the response from chairs. > > From: "Tony Hain" > To: "'Margaret Wasserman'" , > "'Bob Hinden'" > Cc: , "'Thomas Narten'" , > "'Erik Nordmark'" > Subject: RE: Your Appeal Regarding Site-Local Deprecation > (Was: Consensus on Site-Local Addressing) > Date: Mon, 28 Apr 2003 18:38:26 -0700 > Message-ID: <066f01c30df0$07ae4740$261e4104@eagleswings> > > Margaret Wasserman wrote: > > (3) You do not believe that there is rough consensus to > > deprecate IPv6 site-local addressing, because people > > provided different reasons for why they believe that > > IPv6 site-local addressing should be deprecated. In > > particular, some people want to deprecate the particular > > model of site-local addressing defined in the scoped > > addressing architecture (ambiguous, scoped addresses), > > while others do not believe that we need a local > > addressing mechanism at all. > > I was not objecting to 'different reasons'. The specific complaint is > that many of YES votes were for removing the architectural > construct, or > need for applications to deal with addresses that are only accessable > over a limited scope. That is not in the purview of the IETF > to decide, > it is an operational decision of the network manager. Those votes are > not valid as a result. > > > > Point (1): > > > > The chairs do not believe that deprecating IPv6 site-local > > addressing is an incorrect technical decision that will place > > the work output of the IPv6 WG in jeopardy. > > > > The consensus was to "deprecate" the usage of site-local > > addressing instead of simply removing it. > > By asking an ambiguous question, it is easy to insert your > interpretation as the collective consensus. How convenient. > SF question -- > ... how many people think that we should deprecate SL addressing? > Mail list question -- > Should we deprecate IPv6 site-local unicast addressing? > > Neither of those mention 'usage'. In fact if you watch the > video of SF, > you will find that you spent much more time talking about elimination > than anything else. > > > This was done > > purposely to avoid interference with any current > > implementations or deployments that might use site-local > > addressing. In addition to the time it will take to formally > > deprecate site-local addressing by publishing an RFC, the WG > > understands that it will take some time after the publication > > of an RFC for implementations to change. The decision to > > deprecate site-local addressing, rather than simply removing > > it, was made to avoid harm to IPv6. > > There was no decision. You had an inconclusive discussion with Keith, > then later a vague discussion with Thomas about a 'hand wave'. Neither > of those even come close to a decision, let alone a WG > decision. Are we > supposed to just say YES to any ambiguous question you ask, so you can > make up the content of the consensus later? > > > > > In fact, we believe that the previous disagreement over the > > usage of IPv6 site-local addressing was damaging to the WG, > > and that our lack of consensus was delaying our work, > > particularly on the IPv6 scoped addressing architecture. > > While you may believe that the disagreement over SL was delaying the > work, most of those disagreements stemmed from a lack of > agreement over > the fundamental requirements. Removing SL does not solve the basic > problems that need to be addressed in the scoped addressing > architecture. > > > The > > consensus to deprecate site-local addressing will allow us to > > move forward and complete our work. > > No it won't. A scoped address architecture document that ignores the > reality of addresses that are only reachable within a limited part of > the network is incomplete on its major point. It is absolutely useless > to pretend that we have a document that discusses a scoped > architecture > when the case for the majority of nodes in the Internet is missing. > > > > > --- > > Point (2): > > > > The question was: > > > > "Should we deprecate IPv6 site-local unicast > > addressing?" Possible answers were YES or NO. > > > > The chairs believe that this question was sufficiently clear > > to be understood by the WG. > > Clearly you didn't watch the video of the SF meeting. Why > would Thomas, > Keith, Dave, and Christian make a specific point of trying to clarify > the question if it was clear to begin with? Since the question didn't > change, it remained just as unclear as it started, and none of the > 'somewhere to the left' & 'hand wave' comments were sent to the list. > > > This is supported by the following > > points: > > > > - Over 200 people responded to the question. > > > > - Many of the responses on the list (both YES and NO > > responses) included reasons or comments that > > followed from the question in a way that indicated > > that the responders understood the question. > > I disagree. Many of the responses indicated what they meant by saying > yes, which is not the same as understanding the question. In > fact, their > need to explain what question they were answering is an implicit > statement of lack of clarity in the question. > > > > > - There were only three requests for clarification of > > this consensus call on the mailing list, two of which > > were procedural. All of these requests were answered > > promptly by the chairs. > > > > - The chairs sent the consensus results to the list > > over two weeks ago, including a course of action for > > the deprecation of site-local addressing. There > > have been no objections from people who originally > > expressed YES opinions that the chairs' course of > > action fails to match their expectations. > > Why would there be? They all have their own interpretations, so there > won't be objections until the actual next steps begin. > > > > > --- > > > > Point (3): > > > > The chairs do not believe that consensus on an issue is > > invalidated by the fact that people have multiple reasons for > > coming to the same conclusion. We suspect that this happens > > in most WG consensus calls, and this is not a reason to > > invalidate the consensus. > > You missed the point that many of those responses are for an > architectural change that is not in the IETF's purview to decide. See > above. > > > > > All of the groups that you mentioned in your message agreed > > that IPv6 site-local unicast addressing should be deprecated. > > No, some of them believed this is about removing local scoped > addresses > from the architecture, or consideration by applications. That > is not the > same as 'usage' of a defined prefix. > > > They may disagree on what we should do after deprecating > > site- local addressing, but that does not invalidate the > > consensus on this point. > > There is a vast and architectural difference between removing > addresses > which are only reachable over a limited part of the network, and usage > of a specific prefix to identify those. You keep claiming there is a > consensus, but any objective observer of the SF video would disagree. > > > > > --- > > > > Point (4): > > > > It is true that the IPv6 WG has not produced a WG document > > that analyzes the operational requirements for local > > addressing. However, we do not believe that this is a reason > > to invalidate the IPv6 WG consensus to deprecate IPv6 > > site-local unicast addressing. > > You said it multiple times in SF yourself, the WG needs complete > documentation to do an appropriate analysis. You appear to be letting > your desire to 'be right' get in the way of your ability to > analyze your > own responses. I don't understand how can you objectively say > 'we don't > need a document describing the need for X to decide that we don't need > X'? > > > > > There has been considerable discussion and analysis of site- > > local addressing performed over the past year, including > > extensive discussions during three IETF sessions. There have > > also been several drafts published on the subject, including > > one draft that attempts to analyze the cost/benefit > > trade-offs of site-local addressing. > > There have been personal drafts. The WG has not taken this on as a > specific work item. > > > > > This period of discussion has offered sufficient time for > > anyone who has an operational need for any of the > > currently-defined usage models of site-local addressing to > > document those requirements in an Internet-Draft and/or to > > discuss those requirements on the IPv6 mailing list. > > They have been discussed on the mail list to the point that > people stop > paying attention. This argument is disingenuous because there > has never > been a WG item about creating this document. In addition, I > have offered > a draft on the subject multiple times in the last month, yet have not > even received as much as a simple 'no thanks' from the chairs. > > > > > During our discussions, several operational benefits of > > site-local addressing have been raised on the IPv6 WG mailing > > list, including benefits for disconnected sites, > > intermittently- connected sites, renumbered sites, etc. We > > have also uncovered several issues and complexities caused by > > the current model of ambiguous, scoped site-local addressing, > > and we have determined that this particular model places > > burdens on other parts of the TCP/IP protocol suite, > > particularly routing protocols and applications. > > Most of those difficulties will persist, because they are the > result of > inconsistent views of the network topology. There is nothing about > deprecating SL that will change this. The only affect will be > to make it > harder to figure out when the burdens exist. > > > > > In a recent phone discussion and in your appeal > > clarification, you have indicated that the chairs should void > > responses from people who do not think that the IPv6 WG > > should specify any type of local addressing mechanism, > > because you believe that those responders are uninformed > > about the operational conditions that require the use of > > local addressing. > > > > While operational necessity is certainly an appropriate > > argument to raise in support of your position that the IPv6 > > WG should specify some mechanism for local addressing, the > > fact that you disagree with the reasons that some people > > offered for why they want to deprecate the current IPv6 > > site-local unicast addressing mechanism does not invalidate > > their contribution to this consensus call. > > I am pointing out that their 'reason' is not in the purview > of the IETF > to decide, so their YES votes are not informed or valid. I am not > objecting to their opinion, just the chair's interpretation > of consensus > is in error because it fails to discount the votes for an > architectural > point that is out of the IETF's control. > > > > > It is the opinion of the chairs that the IPv6 WG did have > > sufficient information to make an informed decision regarding > > whether or not to deprecate IPv6 site-local unicast addressing. > > Even though a long-term member of the WG said right before > the question > that he did not have enough information to vote NO ... and another > participant stated he had never heard the requirements before > Erik gave > a verbal partial list. How do these create 'an informed decision'? > > > > > --- > > > > So, to summarize, the chairs do not agree with the points > > that you have raised in your appeal, and we do not agree to > > overturn the consensus of the IPv6 WG based on the issues > > that you have raised. > > I am not surprised. > > > > > Tony, while we disagree with your position on this particular > > issue, we do respect your contributions to the IPv6 effort > > and we realize that your appeal is motivated by your desire > > to do the right thing for IPv6. We hope that you will accept > > our response to your appeal and focus on working to define > > the local addressing problem and solutions as we outlined in > > our email to the list. We think it is important for the > > working group to move forward on this issue. > > I will be escalating to Erik & Thomas, because I do believe > that is the > right and expeditious thing to do in this case. > > Tony > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > [9] Tony Hain's appeal to the INT ADs. > > From: "Tony Hain" > To: "'Thomas Narten'" , > "'Erik Nordmark'" > Cc: , "'Bob Hinden'" > , > "'Margaret Wasserman'" > Subject: RE: Your Appeal Regarding Site-Local Deprecation > (Was: Consensus on Site-Local Addressing) > Date: Mon, 28 Apr 2003 18:43:47 -0700 > Message-ID: <067001c30df0$c7ae0ad0$261e4104@eagleswings> > > Thomas & Erik, > > I trust that you will take a more objective view of this, because any > outsider who needs to watch that video will be rolling in the > isles with > laughter at the absurdity of the process abuse in this case. > At least 5 > long-time IETF participants (including yourself) felt the > need to state > what they meant by 'deprecate SL'. One has to assume they bothered to > assert their interpretation because the YES/NO question was unclear to > them, or that their need to explain which question they were answering > is an implicit statement that the original question was unclear. Even > though the question never changed, none of the (amazingly vague) > clarifying remarks in SF were sent to the list version of the > consensus > call. > > If a legal professional were to watch the proceedings here, they would > comment that the WG gave the chairs the freedom to interpret > the meaning > of the question any way they choose. In fact we have examples of that > already on the mail list and in this response. > 3/30 chair email claimed > > As part of deprecating site-local addressing, we > > agreed in the meeting that, in addition to deprecating > > site-local addressing in the addressing architecture > > and removing it from other places (scoped addressing > > architecture, address selection rules, etc.), a document > > would be written that would do two things: > > > > - Explain why site-local addressing was deprecated > > - Outline alternative means to address some of the > > problems that could have been solved by > > site-local addressing. > > That question was never asked of the room, and those > statements were not > made by the chairs in SF. How could there be an agreement? > > > The decision to deprecate site-local addressing, > > rather than simply removing it, was made to avoid > > harm to IPv6. > > There was nothing more to this than vague conversations > between Margaret > & Keith, and Margaret & Thomas. There was no decision by the > WG, just a > chair proclamation that one had occurred. We can't allow the > WG process > to degenerate to the point that a chair can call an ambiguous YES/NO > question, then make up anything they choose to have it mean later. In > particular, when the chair explicitly states '... if we > eliminate it we > will also have multiple choices about what exactly that means > ...', and > '... may have to hand wave ...' there is not a clear indication about > what question is being asked. > > I put specific rebuttal comments to the chair's rejection in a list > response to the chairs. In summary I believe the chairs have > declared a > consensus when there really wasn't one due to the ambiguity of the > question. Specifically the YES votes for removing addresses with local > scope from the architecture or consideration by applications are void, > as that is not something the IETF gets to decide. Had the chairs asked > Keith's original question about finding an alternate way > forward through > replacement technologies, we would not be going through this process. > > As for a path forward, I would expect you to invalidate the consensus, > then have the WG stop the pronouncements that SL is dead, and work on > finding appropriate replacements. This effort must begin with > identification of the requirements for addresses of local scope, and > under local network manager control. With requirements in hand, the > scoped address architecture document needs to specifically deal with > handling mixed scope addresses, both between and for > simultaneous use on > a singe node. That document in particular is hopelessly gutted and > meaningless without such a discussion. IF we get to the point were all > requirements are met by alternatives, the current SL definition should > appropriately be moved to historic. If not, it will likely > end up in the > corner case use that Keith was trying to achieve. Either way, > the entire > WG must decide exactly what happens. We must not allow the 'ambiguous > YES/NO question - chairs subsequently decide what it means', > process to > set a precedent. > > Tony > > > > > Margaret Wasserman wrote: > > Hi Tony, > > > > We have considered your appeal regarding the IPv6 WG > > consensus to deprecate site-locals. Based on our analysis, > > we believe that your appeal makes the following points: > > > > (1) You believe that deprecating IPv6 site-local unicast > > addressing is an incorrect technical choice that places > > the work output of the IPv6 WG in jeopardy. > > > > (2) You believe that the question asked by the chairs > > was insufficiently clear to be understood properly > > by the WG. > > > > (3) You do not believe that there is rough consensus to > > deprecate IPv6 site-local addressing, because people > > provided different reasons for why they believe that > > IPv6 site-local addressing should be deprecated. In > > particular, some people want to deprecate the particular > > model of site-local addressing defined in the scoped > > addressing architecture (ambiguous, scoped addresses), > > while others do not believe that we need a local > > addressing mechanism at all. > > > > (4) You believe that it is invalid for the IPv6 WG to > > deprecate site-local addressing without publishing an > > IPv6 WG document that analyzes the operational requirements > > for local addressing. Without this analysis document, you > > believe that the IPv6 WG has made an uninformed choice. > > > > We will now respond to each of your points. > > > > -- > > > > Point (1): > > > > The chairs do not believe that deprecating IPv6 site-local > > addressing is an incorrect technical decision that will place > > the work output of the IPv6 WG in jeopardy. > > > > The consensus was to "deprecate" the usage of site-local > > addressing instead of simply removing it. This was done > > purposely to avoid interference with any current > > implementations or deployments that might use site-local > > addressing. In addition to the time it will take to formally > > deprecate site-local addressing by publishing an RFC, the WG > > understands that it will take some time after the publication > > of an RFC for implementations to change. The decision to > > deprecate site-local addressing, rather than simply removing > > it, was made to avoid harm to IPv6. > > > > In fact, we believe that the previous disagreement over the > > usage of IPv6 site-local addressing was damaging to the WG, > > and that our lack of consensus was delaying our work, > > particularly on the IPv6 scoped addressing architecture. The > > consensus to deprecate site-local addressing will allow us to > > move forward and complete our work. > > > > --- > > Point (2): > > > > The question was: > > > > "Should we deprecate IPv6 site-local unicast > > addressing?" Possible answers were YES or NO. > > > > The chairs believe that this question was sufficiently clear > > to be understood by the WG. This is supported by the following > > points: > > > > - Over 200 people responded to the question. > > > > - Many of the responses on the list (both YES and NO > > responses) included reasons or comments that > > followed from the question in a way that indicated > > that the responders understood the question. > > > > - There were only three requests for clarification of > > this consensus call on the mailing list, two of which > > were procedural. All of these requests were answered > > promptly by the chairs. > > > > - The chairs sent the consensus results to the list > > over two weeks ago, including a course of action for > > the deprecation of site-local addressing. There > > have been no objections from people who originally > > expressed YES opinions that the chairs' course of > > action fails to match their expectations. > > > > --- > > > > Point (3): > > > > The chairs do not believe that consensus on an issue is > > invalidated by the fact that people have multiple reasons for > > coming to the same conclusion. We suspect that this happens > > in most WG consensus calls, and this is not a reason to > > invalidate the consensus. > > > > All of the groups that you mentioned in your message agreed > > that IPv6 site-local unicast addressing should be deprecated. > > They may disagree on what we should do after deprecating > > site- local addressing, but that does not invalidate the > > consensus on this point. > > > > --- > > > > Point (4): > > > > It is true that the IPv6 WG has not produced a WG document > > that analyzes the operational requirements for local > > addressing. However, we do not believe that this is a reason > > to invalidate the IPv6 WG consensus to deprecate IPv6 > > site-local unicast addressing. > > > > There has been considerable discussion and analysis of site- > > local addressing performed over the past year, including > > extensive discussions during three IETF sessions. There have > > also been several drafts published on the subject, including > > one draft that attempts to analyze the cost/benefit > > trade-offs of site-local addressing. > > > > This period of discussion has offered sufficient time for > > anyone who has an operational need for any of the > > currently-defined usage models of site-local addressing to > > document those requirements in an Internet-Draft and/or to > > discuss those requirements on the IPv6 mailing list. > > > > During our discussions, several operational benefits of > > site-local addressing have been raised on the IPv6 WG mailing > > list, including benefits for disconnected sites, > > intermittently- connected sites, renumbered sites, etc. We > > have also uncovered several issues and complexities caused by > > the current model of ambiguous, scoped site-local addressing, > > and we have determined that this particular model places > > burdens on other parts of the TCP/IP protocol suite, > > particularly routing protocols and applications. > > > > In a recent phone discussion and in your appeal > > clarification, you have indicated that the chairs should void > > responses from people who do not think that the IPv6 WG > > should specify any type of local addressing mechanism, > > because you believe that those responders are uninformed > > about the operational conditions that require the use of > > local addressing. > > > > While operational necessity is certainly an appropriate > > argument to raise in support of your position that the IPv6 > > WG should specify some mechanism for local addressing, the > > fact that you disagree with the reasons that some people > > offered for why they want to deprecate the current IPv6 > > site-local unicast addressing mechanism does not invalidate > > their contribution to this consensus call. > > > > It is the opinion of the chairs that the IPv6 WG did have > > sufficient information to make an informed decision regarding > > whether or not to deprecate IPv6 site-local unicast addressing. > > > > --- > > > > So, to summarize, the chairs do not agree with the points > > that you have raised in your appeal, and we do not agree to > > overturn the consensus of the IPv6 WG based on the issues > > that you have raised. > > > > Tony, while we disagree with your position on this particular > > issue, we do respect your contributions to the IPv6 effort > > and we realize that your appeal is motivated by your desire > > to do the right thing for IPv6. We hope that you will accept > > our response to your appeal and focus on working to define > > the local addressing problem and solutions as we outlined in > > our email to the list. We think it is important for the > > working group to move forward on this issue. > > > > Best Regards, > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG Chairs > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 09:40:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GGev06025874; Wed, 16 Jul 2003 09:40:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GGev0S025873; Wed, 16 Jul 2003 09:40:57 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GGer06025866 for ; Wed, 16 Jul 2003 09:40:53 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GGcYUY026062 for ; Wed, 16 Jul 2003 09:38:34 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GGcSsR003037 for ; Wed, 16 Jul 2003 10:38:28 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6GGcIN19016; Wed, 16 Jul 2003 12:38:23 -0400 (EDT) Date: Wed, 16 Jul 2003 12:38:18 -0400 From: Keith Moore To: "Tony Hain" Cc: moore@cs.utk.edu, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: AD response to Site-Local Appeal Message-Id: <20030716123818.22fc0283.moore@cs.utk.edu> In-Reply-To: <020601c34bab$e307dce0$b70fa051@eagleswings> References: <200307091300.h69D0Zq10846@cichlid.adsl.duke.edu> <020601c34bab$e307dce0$b70fa051@eagleswings> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > We disagree. The question asked by the chairs was not about > > the differing reasons, the question was specifically about > > SLs, and whether the WG wanted to deprecate them. That the > > question referred specifically to deprecating site locals > > (and not the reasons why one might do so) is obvious. It is > > common in the IETF when deciding technical issues for > > different people to have different reasons for coming to a > > particular conclusion, or to weigh tradeoffs differently. In > > the end, if there is consensus on the answer to a specific > > question, we have consensus, even if the reasons for reaching > > a particular outcome are not shared. > > Unfortunately this is a misinterpretation of my point. It is not > focused on'different people had different reasons', because we agree > there will always be different perspectives and opinions. The focus > was that a significant number of participants had the specific reason > 'remove limited scoping', and this is not something the IETF gets to > decide. It is an operational issue, and network managers will build > networks where addresses have limited routing scope. and this, I believe, is a misrepresentation of that side. IETF should not be bound by your representation of other people's opinions. IETF doesn't get to decide how people filter traffic on their networks. What it does get to decide is whether there is an expectation in the standards that a _particular range_ of addresses will get filtered at some ill-defined boundary. And it has decided against it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 11:08:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GI8106006364; Wed, 16 Jul 2003 11:08:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GI81QC006362; Wed, 16 Jul 2003 11:08:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GI7n06006288 for ; Wed, 16 Jul 2003 11:07:49 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GI5UUY013615 for ; Wed, 16 Jul 2003 11:05:30 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6GI5OsP000608 for ; Wed, 16 Jul 2003 12:05:25 -0600 (MDT) Received: from ocean.jinmei.org (unknown [2001:7f9:8400:10:8919:3164:a252:e6f3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B027C15248 for ; Thu, 17 Jul 2003 03:05:21 +0900 (JST) Date: Thu, 17 Jul 2003 03:05:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: ICMP name lookup implementation survey In-Reply-To: <20030715085951.6CF8013@coconut.itojun.org> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 15 Jul 2003 17:59:51 +0900, >>>>> itojun@iijlab.net said: > PS: KAME folks, any clarifications/corrections are requested. The description basically looks correct. A minor point: I'm not sure if we provide the client side of "noop (Qtype=0)" and "supported query types (Qtype=1)." Probably we don't. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 12:14:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GJED06013624; Wed, 16 Jul 2003 12:14:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6GJECxo013620; Wed, 16 Jul 2003 12:14:12 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6GJE306013563 for ; Wed, 16 Jul 2003 12:14:03 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6GJBcQ21513; Wed, 16 Jul 2003 21:11:39 +0200 (MEST) Date: Wed, 16 Jul 2003 21:10:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a concern on bridge-like nd-proxies To: Keith Moore Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20030716103912.6627b730.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Lately I find myself wondering if there's not room for a uniform layer 2.5 > interface that is designed to work over a set of bridged 802-style layer 2 > networks, but presents a slightly different interface to the host. [...] > (has this already been worked on and I just don't know about it?) There is a recent proposal in draft-perlman-zerouter-rbridge-00.txt which doesn't have authentication and tries to make the network more scalable by doing better than a spanning tree. Whether or where this fits in the IETF is an open issue. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 22:21:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H5LH06017425; Wed, 16 Jul 2003 22:21:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H5LGfM017424; Wed, 16 Jul 2003 22:21:16 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H5LD06017417 for ; Wed, 16 Jul 2003 22:21:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H5IrUu028110 for ; Wed, 16 Jul 2003 22:18:54 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H5Im65013905 for ; Wed, 16 Jul 2003 22:18:48 -0700 (PDT) Received: from ala-mrwtemp.windriver.com ([147.11.233.33]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id WAA29187; Wed, 16 Jul 2003 22:18:24 -0700 (PDT) Message-Id: <5.1.0.14.2.20030717010944.030e45b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Jul 2003 01:12:38 -0400 To: Keith Moore From: Margaret Wasserman Subject: Re: a concern on bridge-like nd-proxies Cc: Brian E Carpenter , moore@cs.utk.edu, ipng@sunroof.eng.sun.com In-Reply-To: <20030716103912.6627b730.moore@cs.utk.edu> References: <3F155AD8.607CCCFB@hursley.ibm.com> <3F155AD8.607CCCFB@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:39 AM 7/16/2003 -0400, Keith Moore wrote: >Lately I find myself wondering if there's not room for a uniform layer 2.5 >interface that is designed to work over a set of bridged 802-style layer 2 >networks, but presents a slightly different interface to the host. So for >instance hosts would be explicitly required to announce presence on a link (no >more passive waiting for ARP requests), there would be an explicit L2.5 >multicast join/leave (no more sniffing for L3 multicast requests) [...] > >(has this already been worked on and I just don't know about it?) IEEE 802.1 VLANs (Virtual LANs) are intended to provide this type of function in L2 switches... Many people even refer to VLANs as "layer 2.5"... I think that the idea of Dave Thaler's draft, though (and similar work by others) is to switch at layer 3, so that there is no need for layer 2 switching in this type of environment. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 00:18:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7Ie06024042; Thu, 17 Jul 2003 00:18:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H7IeRw024041; Thu, 17 Jul 2003 00:18:40 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7Ia06024034 for ; Thu, 17 Jul 2003 00:18:37 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H7GGUY024921 for ; Thu, 17 Jul 2003 00:16:16 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H7GADk003685 for ; Thu, 17 Jul 2003 01:16:10 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6H7G9u01899 for ; Thu, 17 Jul 2003 10:16:09 +0300 Date: Thu, 17 Jul 2003 10:16:09 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: global/link-local nexthops and RFC2461 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Discussing one implementation, a possible source of ambiguity in RFC2461 came up. RFC2461 discusses that next-hops must be on-link. However, section 8 on redirect basically requires: - routers know each others' link-local addresses (not an issue from hosts' perspective, just use routing protocols or other mechanisms) - hosts are able to verify that the redirect comes from the link-local address the host is currently using as its next-hop The latter is a bit problematic. How could the host know this in the case where the next-hop has been configured using e.g. a _global_ (but on-link) address? What's the deal here? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 00:28:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7SN06024228; Thu, 17 Jul 2003 00:28:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H7SNVr024226; Thu, 17 Jul 2003 00:28:23 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7SJ06024216 for ; Thu, 17 Jul 2003 00:28:19 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H7PvUu026085 for ; Thu, 17 Jul 2003 00:25:57 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H7PpDk006744 for ; Thu, 17 Jul 2003 01:25:52 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3093493; Thu, 17 Jul 2003 16:25:48 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Thu, 17 Jul 2003 10:16:09 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: global/link-local nexthops and RFC2461 From: itojun@iijlab.net Date: Thu, 17 Jul 2003 16:25:48 +0900 Message-Id: <20030717072548.3093493@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hi, > >Discussing one implementation, a possible source of ambiguity in RFC2461 >came up. > >RFC2461 discusses that next-hops must be on-link. > >However, section 8 on redirect basically requires: > - routers know each others' link-local addresses (not an issue from >hosts' perspective, just use routing protocols or other mechanisms) > - hosts are able to verify that the redirect comes from the link-local >address the host is currently using as its next-hop > >The latter is a bit problematic. How could the host know this in the case >where the next-hop has been configured using e.g. a _global_ (but on-link) >address? to say it backwards, for the ICMPv6 redirect to work correctly, nexthop address on the routing table MUST be link-local (even when manually configured). i think adding this text clarifies the concern. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 00:33:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7X306024409; Thu, 17 Jul 2003 00:33:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H7X35G024408; Thu, 17 Jul 2003 00:33:03 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7X006024401 for ; Thu, 17 Jul 2003 00:33:00 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H7UeUY001983 for ; Thu, 17 Jul 2003 00:30:40 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6H7UYv5018993 for ; Thu, 17 Jul 2003 01:30:34 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6H7UTl02174; Thu, 17 Jul 2003 10:30:29 +0300 Date: Thu, 17 Jul 2003 10:30:28 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-Reply-To: <20030717072548.3093493@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jul 2003 itojun@iijlab.net wrote: > >Discussing one implementation, a possible source of ambiguity in RFC2461 > >came up. > > > >RFC2461 discusses that next-hops must be on-link. > > > >However, section 8 on redirect basically requires: > > - routers know each others' link-local addresses (not an issue from > >hosts' perspective, just use routing protocols or other mechanisms) > > - hosts are able to verify that the redirect comes from the link-local > >address the host is currently using as its next-hop > > > >The latter is a bit problematic. How could the host know this in the case > >where the next-hop has been configured using e.g. a _global_ (but on-link) > >address? > > to say it backwards, for the ICMPv6 redirect to work correctly, nexthop > address on the routing table MUST be link-local (even when manually > configured). i think adding this text clarifies the concern. Yes, this would fix and clarify the issue, but I think it might substantially change the overall assumption of the document, i.e. "next-hop must be onlink". It might be interesting to hear if this was an issue that was debated when RFC2461 (or previous versions) were specified. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 00:39:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7dp06025051; Thu, 17 Jul 2003 00:39:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H7dppN025050; Thu, 17 Jul 2003 00:39:51 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7dh06025007 for ; Thu, 17 Jul 2003 00:39:43 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H7bMUu028781 for ; Thu, 17 Jul 2003 00:37:22 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6H7bGsP004885 for ; Thu, 17 Jul 2003 01:37:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 68B7013; Thu, 17 Jul 2003 16:37:14 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Thu, 17 Jul 2003 10:30:28 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: global/link-local nexthops and RFC2461 From: itojun@iijlab.net Date: Thu, 17 Jul 2003 16:37:14 +0900 Message-Id: <20030717073714.68B7013@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> to say it backwards, for the ICMPv6 redirect to work correctly, nexthop >> address on the routing table MUST be link-local (even when manually >> configured). i think adding this text clarifies the concern. > >Yes, this would fix and clarify the issue, but I think it might >substantially change the overall assumption of the document, i.e. >"next-hop must be onlink". are there any linklocal address peers that are "not onlink"? note that it is because the defition of "onlink" is a bit vague: - sharing the same subnet number - same link-local scope zone i'm using the latter definition, and i guess you are using former. multilink subnet folks are using the former. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 00:59:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7xr06025598; Thu, 17 Jul 2003 00:59:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H7xrk6025597; Thu, 17 Jul 2003 00:59:53 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H7xo06025590 for ; Thu, 17 Jul 2003 00:59:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H7vUUu002725 for ; Thu, 17 Jul 2003 00:57:30 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H7vJ65022360 for ; Thu, 17 Jul 2003 00:57:24 -0700 (PDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6H7vFR29255; Thu, 17 Jul 2003 09:57:16 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6H7tiof048079; Thu, 17 Jul 2003 09:55:44 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307170755.h6H7tiof048079@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-reply-to: Your message of Thu, 17 Jul 2003 10:16:09 +0300. Date: Thu, 17 Jul 2003 09:55:43 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Discussing one implementation, a possible source of ambiguity in RFC2461 came up. RFC2461 discusses that next-hops must be on-link. => this is an obvious requirement. However, section 8 on redirect basically requires: - routers know each others' link-local addresses (not an issue from hosts' perspective, just use routing protocols or other mechanisms) => routers may know each others' global addresses too, mainly through prefix-infos with the R bit set (so this R bit is useful outside mobile IPv6 and should be added in a RFC 2461bis) or through external routing protocols. BTW when routers don't know each others' global addresses you can't use standard network management tools (i.e., SNMP with standard MIBs) to perform a topology discovery (i.e., a network map) because you can't go further than the local links. This issue was signaled by Jean-Luc Richier many years ago but was never solved... - hosts are able to verify that the redirect comes from the link-local address the host is currently using as its next-hop The latter is a bit problematic. How could the host know this in the case where the next-hop has been configured using e.g. a _global_ (but on-link) address? What's the deal here? => I agree RFC 2461 expects the next-hop is always characterized by its link-local address (as it is on a shared link it always has one). There are some implementations which enforce the use of link-local addresses but I agree that global addresses are not forbidden, or the use of more than one link-local address... BTW I don't believe a host is required to redirect its packets. Regards Francis.Dupont@enst-bretagne.fr PS: I've looked at BSD (mine old stack and KAME) codes: the source of the redirect is compared with the "gateway" field of the route to the redirected destination: if they don't match the redirect is rejected. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 01:01:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H81d06025692; Thu, 17 Jul 2003 01:01:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H81dUV025691; Thu, 17 Jul 2003 01:01:39 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H81X06025678 for ; Thu, 17 Jul 2003 01:01:33 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H7xCUY009080 for ; Thu, 17 Jul 2003 00:59:13 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6H7x6sR005652 for ; Thu, 17 Jul 2003 01:59:06 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6H7x1502613; Thu, 17 Jul 2003 10:59:01 +0300 Date: Thu, 17 Jul 2003 10:59:01 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-Reply-To: <20030717073714.68B7013@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jul 2003 itojun@iijlab.net wrote: > >> to say it backwards, for the ICMPv6 redirect to work correctly, nexthop > >> address on the routing table MUST be link-local (even when manually > >> configured). i think adding this text clarifies the concern. > > > >Yes, this would fix and clarify the issue, but I think it might > >substantially change the overall assumption of the document, i.e. > >"next-hop must be onlink". > > are there any linklocal address peers that are "not onlink"? > note that it is because the defition of "onlink" is a bit vague: > - sharing the same subnet number > - same link-local scope zone > > i'm using the latter definition, and i guess you are using former. > multilink subnet folks are using the former. This is not a problem (IMO): the problem is that certain global addresses are *also* on-link, but cause issues with redirects. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 01:02:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H82l06025734; Thu, 17 Jul 2003 01:02:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H82k5g025733; Thu, 17 Jul 2003 01:02:46 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H82g06025726 for ; Thu, 17 Jul 2003 01:02:42 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H80LUY010485 for ; Thu, 17 Jul 2003 01:00:21 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6H80BsR006241 for ; Thu, 17 Jul 2003 02:00:11 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 281FD13; Thu, 17 Jul 2003 17:00:09 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Thu, 17 Jul 2003 10:59:01 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: global/link-local nexthops and RFC2461 From: itojun@iijlab.net Date: Thu, 17 Jul 2003 17:00:09 +0900 Message-Id: <20030717080009.281FD13@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is not a problem (IMO): the problem is that certain global addresses >are *also* on-link, but cause issues with redirects. so i suggest replacing "next-hop must be onlink" with "next-hop must be link-local". itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 01:25:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H8Px06026687; Thu, 17 Jul 2003 01:25:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H8PwD8026686; Thu, 17 Jul 2003 01:25:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H8Pt06026679 for ; Thu, 17 Jul 2003 01:25:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H8NZUY016751 for ; Thu, 17 Jul 2003 01:23:35 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6H8NT1v028581 for ; Thu, 17 Jul 2003 01:23:29 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6H8NGR02897; Thu, 17 Jul 2003 11:23:16 +0300 Date: Thu, 17 Jul 2003 11:23:16 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-Reply-To: <200307170755.h6H7tiof048079@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jul 2003, Francis Dupont wrote: > - hosts are able to verify that the redirect comes from the link-local > address the host is currently using as its next-hop > > The latter is a bit problematic. How could the host know this in the case > where the next-hop has been configured using e.g. a _global_ (but on-link) > address? > > What's the deal here? > > => I agree RFC 2461 expects the next-hop is always characterized by its > link-local address (as it is on a shared link it always has one). > There are some implementations which enforce the use of link-local > addresses but I agree that global addresses are not forbidden, or > the use of more than one link-local address... Note that this also happens if you'd like to use an anycast address as the nexthop: even in the link-local scope, e.g. fe80::. (I'm not sure whether these are realistic scenarios or not..) > BTW I don't believe > a host is required to redirect its packets. You mean, host is not required to respond to redirects sent by the routers? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 02:00:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H90O06027630; Thu, 17 Jul 2003 02:00:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H90N9A027629; Thu, 17 Jul 2003 02:00:23 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H90K06027619 for ; Thu, 17 Jul 2003 02:00:20 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H8vxUu020849 for ; Thu, 17 Jul 2003 01:58:00 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H8voDk007226 for ; Thu, 17 Jul 2003 02:57:54 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6H8vkR30597; Thu, 17 Jul 2003 10:57:46 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6H8uEof048339; Thu, 17 Jul 2003 10:56:14 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307170856.h6H8uEof048339@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-reply-to: Your message of Thu, 17 Jul 2003 11:23:16 +0300. Date: Thu, 17 Jul 2003 10:56:14 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > There are some implementations which enforce the use of link-local > addresses but I agree that global addresses are not forbidden, or > the use of more than one link-local address... Note that this also happens if you'd like to use an anycast address as the nexthop: even in the link-local scope, e.g. fe80::. => even if in theory this should work in practice this doesn't work at all (at least it was a disaster when I tried many years ago :-). (I'm not sure whether these are realistic scenarios or not..) => there are many nodes with multiple link-local addresses and in these nodes some are routers. IMHO we should not try to support redirect sent from a "random" link-local source address but we have to address the problem, i.e., just change on-link by link-local is not enough to really answer to your question... > BTW I don't believe > a host is required to redirect its packets. You mean, host is not required to respond to redirects sent by the routers? => host is not required to update its routing table (i.e., there is a SHOULD, not a MUST). Thanks Francis.Dupont@enst-bretagne.fr PS: I have a limited interest question about redirects: some implementations drop received redirects on routers, in fact RFC 2461 only says it MUST NOT update its routing table, so a redirect received from an unknown router should give a new STALE neighbor cache entry... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 02:01:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H91206027660; Thu, 17 Jul 2003 02:01:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H911fn027659; Thu, 17 Jul 2003 02:01:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H90w06027651 for ; Thu, 17 Jul 2003 02:00:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H8wcUY028681 for ; Thu, 17 Jul 2003 01:58:38 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H8wV65021010 for ; Thu, 17 Jul 2003 01:58:32 -0700 (PDT) Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 18-md50000000068.tmp for ; Thu, 17 Jul 2003 11:00:02 +0200 Message-ID: <11b701c34c41$c8e74210$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 10:59:47 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Thu, 17 Jul 2003 11:00:02 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I feel that we need to "revive" this thread. If we include, for example, in the node-requirements, that one of the IPv6 node requirements is to "avoid" the support of NAT or any other kind of address translation mechanism (I'm not suggesting exactly this way to say it), any vendor that do that, can be "banned" by the community and the Interop/Conformance test, because he is not complying with the specs. Some still will do that, but we can then tell the network managers and users, that the product is NOT IETF complaint. Regards, Jordi ----- Original Message ----- From: "JORDI PALET MARTINEZ" To: Sent: Thursday, March 20, 2003 1:02 PM Subject: avoiding NAT with IPv6 > After the today's decision with site local, is clear to me that we don't want to have NAT happening again ;-) > > We know that the people will do it anyway, but we must do an effort to avoid is as much as possible, and some ideas that could > support this are: > > 1) Clearly show the advantages of end-to-end and no NAT model. > 2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any > interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the > manufacturers to avoid supporting NATs. > 3) Indicate that if someone wants to keep using NAT, should do it with IPv4. > > I'm not sure if the rest agree and what is the correct document to say this, may be as part of the changes for the local-link > deprecation ? > > Regards, > Jordi > > > ***************************** > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Register at: > http://www.ipv6-es.com > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > > ***************************** > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Register at: > http://www.ipv6-es.com > > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 02:14:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9EK06028353; Thu, 17 Jul 2003 02:14:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H9EJxo028352; Thu, 17 Jul 2003 02:14:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9EG06028343 for ; Thu, 17 Jul 2003 02:14:16 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H9BtUu024379 for ; Thu, 17 Jul 2003 02:11:55 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H9BnDk011974 for ; Thu, 17 Jul 2003 03:11:49 -0600 (MDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H9BmB02365 for ; Thu, 17 Jul 2003 12:11:48 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:11:48 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:11:47 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:11:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:11:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 12:11:45 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: avoiding NAT with IPv6 Thread-Index: AcNMQfEbQbBZLtidQkWbf+vTWNcWmwAANujA From: To: , X-OriginalArrivalTime: 17 Jul 2003 09:11:46.0259 (UTC) FILETIME=[726A3A30:01C34C43] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6H9EG06028346 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jordi, > If we include, for example, in the node-requirements, that > one of the IPv6 node requirements is to "avoid" the support of NAT or any > other kind of address translation mechanism (I'm not > suggesting exactly this way to say it), any vendor that do that, can be > "banned" by the community and the Interop/Conformance test, > because he is not complying with the specs. > > Some still will do that, but we can then tell the network > managers and users, that the product is NOT IETF complaint. I feel ambigious about this - avoiding NATs is a good thing, however IETF is not a protocol enforcement agency. Interop & conformance testing happens outside of the IETF, so I am not sure this is in scope for the IETF. Additionally, the WG chairs chartered the Node Requirements work to document existing requirements, and I actually don't think we have any IPv6 RFCs that have any related statements like 'You MUST NOT NAT IPv6' ... so I am unsure how to procede on this subject. That noted, there are well known RFCs published already on the dangers of NATing, so I'm not sure what good it would do to put something in the Node Requirements document. Finally, I actually don't know what a reasonable requirement would be to add to cover this. If you think you have good text, please send it on the mailing list. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 02:19:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9JV06028566; Thu, 17 Jul 2003 02:19:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H9JVtl028565; Thu, 17 Jul 2003 02:19:31 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9JR06028556 for ; Thu, 17 Jul 2003 02:19:27 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H9H7UY003322 for ; Thu, 17 Jul 2003 02:17:07 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6H9H1sP005652 for ; Thu, 17 Jul 2003 03:17:01 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6H9GtZG020196; Thu, 17 Jul 2003 11:16:56 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6H9Fnce230234; Thu, 17 Jul 2003 11:15:50 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA36940; Thu, 17 Jul 2003 11:15:47 +0200 Message-ID: <3F166949.9652862@hursley.ibm.com> Date: Thu, 17 Jul 2003 11:15:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: ipng@sunroof.eng.sun.com Subject: Re: Fw: avoiding NAT with IPv6 References: <11b701c34c41$c8e74210$eb88a051@consulintel.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm very sympathetic, but I think it is conditioned by what we are discussing today - having an agreed replacement for the ambiguous FEC0:: space (which is an open invitation to NAT). Once we have such a thing, we can make positive requirements for exploiting it that make NAT look silly. Brian JORDI PALET MARTINEZ wrote: > > I feel that we need to "revive" this thread. > > If we include, for example, in the node-requirements, that one of the IPv6 node requirements is to "avoid" the support of NAT or any > other kind of address translation mechanism (I'm not suggesting exactly this way to say it), any vendor that do that, can be > "banned" by the community and the Interop/Conformance test, because he is not complying with the specs. > > Some still will do that, but we can then tell the network managers and users, that the product is NOT IETF complaint. > > Regards, > Jordi > > ----- Original Message ----- > From: "JORDI PALET MARTINEZ" > To: > Sent: Thursday, March 20, 2003 1:02 PM > Subject: avoiding NAT with IPv6 > > > After the today's decision with site local, is clear to me that we don't want to have NAT happening again ;-) > > > > We know that the people will do it anyway, but we must do an effort to avoid is as much as possible, and some ideas that could > > support this are: > > > > 1) Clearly show the advantages of end-to-end and no NAT model. > > 2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any > > interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the > > manufacturers to avoid supporting NATs. > > 3) Indicate that if someone wants to keep using NAT, should do it with IPv4. > > > > I'm not sure if the rest agree and what is the correct document to say this, may be as part of the changes for the local-link > > deprecation ? > > > > Regards, > > Jordi > > > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > 12-14 May 2003 - Register at: > > http://www.ipv6-es.com > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > 12-14 May 2003 - Register at: > > http://www.ipv6-es.com > > > > > > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 02:25:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9Pw06029074; Thu, 17 Jul 2003 02:25:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H9PwKc029073; Thu, 17 Jul 2003 02:25:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9Pt06029066 for ; Thu, 17 Jul 2003 02:25:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H9NZUY005111 for ; Thu, 17 Jul 2003 02:23:35 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H9NS65003388 for ; Thu, 17 Jul 2003 02:23:29 -0700 (PDT) Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 41-md50000000069.tmp for ; Thu, 17 Jul 2003 11:24:55 +0200 Message-ID: <127601c34c45$42dbc7a0$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 11:24:37 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Thu, 17 Jul 2003 11:24:55 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, I know this is a difficult topic, and we don't enforce the vendors, but we do "de facto". I mean, if a vendor don't pass a given RFC in a conformance/interoperability, because they do NAT, then a lot of customers (ISPs, Telcos) will not purchase it, because that's what the market do most of the time. And this is a "market" enforcement ... What about something like: IPv6 has enough addressing space that allows avoid the need of any kind of address translation, that is considered harmful according [RFCxxxx]. Consequently, IPv6 nodes MUST NOT support any kind of address translation. Regards, Jordi ----- Original Message ----- From: To: ; Sent: Thursday, July 17, 2003 11:11 AM Subject: RE: avoiding NAT with IPv6 Hi Jordi, > If we include, for example, in the node-requirements, that > one of the IPv6 node requirements is to "avoid" the support of NAT or any > other kind of address translation mechanism (I'm not > suggesting exactly this way to say it), any vendor that do that, can be > "banned" by the community and the Interop/Conformance test, > because he is not complying with the specs. > > Some still will do that, but we can then tell the network > managers and users, that the product is NOT IETF complaint. I feel ambigious about this - avoiding NATs is a good thing, however IETF is not a protocol enforcement agency. Interop & conformance testing happens outside of the IETF, so I am not sure this is in scope for the IETF. Additionally, the WG chairs chartered the Node Requirements work to document existing requirements, and I actually don't think we have any IPv6 RFCs that have any related statements like 'You MUST NOT NAT IPv6' ... so I am unsure how to procede on this subject. That noted, there are well known RFCs published already on the dangers of NATing, so I'm not sure what good it would do to put something in the Node Requirements document. Finally, I actually don't know what a reasonable requirement would be to add to cover this. If you think you have good text, please send it on the mailing list. John ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 02:30:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9Ul06029421; Thu, 17 Jul 2003 02:30:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H9UlTE029420; Thu, 17 Jul 2003 02:30:47 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9Uh06029413 for ; Thu, 17 Jul 2003 02:30:43 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H9SNUu028771 for ; Thu, 17 Jul 2003 02:28:23 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H9SGDk017083 for ; Thu, 17 Jul 2003 03:28:17 -0600 (MDT) Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 59-md50000000069.tmp for ; Thu, 17 Jul 2003 11:29:38 +0200 Message-ID: <129201c34c45$eb499bb0$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <11b701c34c41$c8e74210$eb88a051@consulintel.es> <3F166949.9652862@hursley.ibm.com> Subject: Re: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 11:29:19 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Thu, 17 Jul 2003 11:29:38 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IETF is slow, and we know it. We should work in parallel as much as possible, and I feel we have an opportunity now with the node-requirements. I think is much better that the 2nd option a BCP, as this will not so easy for conformance test ... Regards, Jordi ----- Original Message ----- From: "Brian E Carpenter" To: "JORDI PALET MARTINEZ" Cc: Sent: Thursday, July 17, 2003 11:15 AM Subject: Re: Fw: avoiding NAT with IPv6 > I'm very sympathetic, but I think it is conditioned by > what we are discussing today - having an agreed replacement > for the ambiguous FEC0:: space (which is an open invitation > to NAT). Once we have such a thing, we can make positive > requirements for exploiting it that make NAT look silly. > > Brian > > JORDI PALET MARTINEZ wrote: > > > > I feel that we need to "revive" this thread. > > > > If we include, for example, in the node-requirements, that one of the IPv6 node requirements is to "avoid" the support of NAT or any > > other kind of address translation mechanism (I'm not suggesting exactly this way to say it), any vendor that do that, can be > > "banned" by the community and the Interop/Conformance test, because he is not complying with the specs. > > > > Some still will do that, but we can then tell the network managers and users, that the product is NOT IETF complaint. > > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: "JORDI PALET MARTINEZ" > > To: > > Sent: Thursday, March 20, 2003 1:02 PM > > Subject: avoiding NAT with IPv6 > > > > > After the today's decision with site local, is clear to me that we don't want to have NAT happening again ;-) > > > > > > We know that the people will do it anyway, but we must do an effort to avoid is as much as possible, and some ideas that could > > > support this are: > > > > > > 1) Clearly show the advantages of end-to-end and no NAT model. > > > 2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any > > > interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the > > > manufacturers to avoid supporting NATs. > > > 3) Indicate that if someone wants to keep using NAT, should do it with IPv4. > > > > > > I'm not sure if the rest agree and what is the correct document to say this, may be as part of the changes for the local-link > > > deprecation ? > > > > > > Regards, > > > Jordi > > > > > > > > > ***************************** > > > Madrid 2003 Global IPv6 Summit > > > 12-14 May 2003 - Register at: > > > http://www.ipv6-es.com > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > > > > ***************************** > > > Madrid 2003 Global IPv6 Summit > > > 12-14 May 2003 - Register at: > > > http://www.ipv6-es.com > > > > > > > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on-line at: > > http://www.ipv6-es.com > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 02:33:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9Xj06029860; Thu, 17 Jul 2003 02:33:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H9Xjt0029859; Thu, 17 Jul 2003 02:33:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9Xd06029831 for ; Thu, 17 Jul 2003 02:33:40 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H9VJUY006999 for ; Thu, 17 Jul 2003 02:31:19 -0700 (PDT) Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6H9VCsR019308 for ; Thu, 17 Jul 2003 03:31:12 -0600 (MDT) Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SRFP6XG>; Thu, 17 Jul 2003 10:31:27 +0100 Message-ID: From: matthew.ford@bt.com To: brian@hursley.ibm.com, jordi.palet@consulintel.es Cc: ipng@sunroof.eng.sun.com Subject: RE: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 10:30:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Making NAT look silly is good. One case I see where IPv6 NAT still doesn't look completely silly is where ISPs hand out /64s to end users. Pay your EUR10, buy your IPv6NAT and you have a /48. Mat. > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 17 July 2003 11:16 > Once we have such a thing, we can make positive > requirements for exploiting it that make NAT look silly. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 02:43:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9hu06000900; Thu, 17 Jul 2003 02:43:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6H9huba000899; Thu, 17 Jul 2003 02:43:56 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6H9hr06000892 for ; Thu, 17 Jul 2003 02:43:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H9fWUY009367 for ; Thu, 17 Jul 2003 02:41:33 -0700 (PDT) Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6H9fQ1v006490 for ; Thu, 17 Jul 2003 02:41:27 -0700 (PDT) Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SRFQB20>; Thu, 17 Jul 2003 10:41:42 +0100 Message-ID: From: matthew.ford@bt.com To: jordi.palet@consulintel.es, ipng@sunroof.eng.sun.com Subject: RE: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 10:41:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="windows-1252" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't think this makes much sense. The node requirements doc is the wrong place to introduce new requirements. More importantly there's no way to enforce this in conformance testing. I understand the sentiment, but this is the wrong solution. Mat. > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] > Sent: 17 July 2003 11:25 > To: ipng@sunroof.eng.sun.com > Subject: Re: avoiding NAT with IPv6 > > > Hi John, > > I know this is a difficult topic, and we don't enforce the > vendors, but we do "de facto". > > I mean, if a vendor don't pass a given RFC in a > conformance/interoperability, because they do NAT, then a lot > of customers (ISPs, > Telcos) will not purchase it, because that's what the market > do most of the time. And this is a "market" enforcement ... > > What about something like: > > IPv6 has enough addressing space that allows avoid the need > of any kind of address translation, that is considered > harmful according > [RFCxxxx]. Consequently, IPv6 nodes MUST NOT support any kind > of address translation. > > Regards, > Jordi > > ----- Original Message ----- > From: > To: ; > Sent: Thursday, July 17, 2003 11:11 AM > Subject: RE: avoiding NAT with IPv6 > > > Hi Jordi, > > > If we include, for example, in the node-requirements, that > > one of the IPv6 node requirements is to "avoid" the support > of NAT or any > > other kind of address translation mechanism (I'm not > > suggesting exactly this way to say it), any vendor that do > that, can be > > "banned" by the community and the Interop/Conformance test, > > because he is not complying with the specs. > > > > Some still will do that, but we can then tell the network > > managers and users, that the product is NOT IETF complaint. > > I feel ambigious about this - avoiding NATs is a good thing, however > IETF is not a protocol enforcement agency. Interop & conformance > testing happens outside of the IETF, so I am not sure this is > in scope for the IETF. > > Additionally, the WG chairs chartered the Node Requirements work > to document existing requirements, and I actually don't think > we have any IPv6 RFCs that have any related statements like > 'You MUST NOT NAT IPv6' ... so I am unsure how to procede on > this subject. > > That noted, there are well known RFCs published already on > the dangers of NATing, so I'm not sure what good it would do > to put something in the Node Requirements document. > > Finally, I actually don't know what a reasonable requirement > would be to add to cover this. If you think you have good text, > please send it on the mailing list. > > John > > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 03:51:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HAp306002755; Thu, 17 Jul 2003 03:51:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HAp2Na002754; Thu, 17 Jul 2003 03:51:02 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HAox06002747 for ; Thu, 17 Jul 2003 03:50:59 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HAmeUY020497 for ; Thu, 17 Jul 2003 03:48:40 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6HAmYsP002878 for ; Thu, 17 Jul 2003 04:48:34 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6HAmTe04485; Thu, 17 Jul 2003 13:48:29 +0300 Date: Thu, 17 Jul 2003 13:48:28 +0300 (EEST) From: Pekka Savola To: matthew.ford@bt.com cc: brian@hursley.ibm.com, , Subject: RE: Fw: avoiding NAT with IPv6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jul 2003 matthew.ford@bt.com wrote: > Making NAT look silly is good. One case I see where IPv6 NAT still doesn't > look completely silly is where ISPs hand out /64s to end users. Pay your > EUR10, buy your IPv6NAT and you have a /48. Well, this is still a case we can "fix" with a bridge-like ND-proxy. The question is whether it will make the problem worse.. Substitute the /64 with /128 and you make it really enticing. Not much we can do about it, except just try to say why it's such a bad idea. > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: 17 July 2003 11:16 > > > > Once we have such a thing, we can make positive > > requirements for exploiting it that make NAT look silly. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 04:23:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HBNn06004864; Thu, 17 Jul 2003 04:23:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HBNnB5004863; Thu, 17 Jul 2003 04:23:49 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HBNj06004850 for ; Thu, 17 Jul 2003 04:23:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HBLQUu021214 for ; Thu, 17 Jul 2003 04:21:26 -0700 (PDT) Received: from klapautius.it.su.se ([81.160.170.167]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HBLJ1v019558 for ; Thu, 17 Jul 2003 04:21:20 -0700 (PDT) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6H9RRF16277; Thu, 17 Jul 2003 11:27:27 +0200 Message-ID: <3F166BFE.4060401@it.su.se> Date: Thu, 17 Jul 2003 11:27:26 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: jordi.palet@consulintel.es, ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 References: In-Reply-To: X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: >That noted, there are well known RFCs published already on >the dangers of NATing, so I'm not sure what good it would do >to put something in the Node Requirements document. > >Finally, I actually don't know what a reasonable requirement >would be to add to cover this. If you think you have good text, >please send it on the mailing list. > I think you answered the question already. There are enough widely deployed applications (sip for instance) which don't really work over NAT. Given this it would be unfortunate if we didn't take every oportunity to ensure that those applications won't break in ipv6. Cheers Leif -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 04:52:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HBqG06007293; Thu, 17 Jul 2003 04:52:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HBqF96007292; Thu, 17 Jul 2003 04:52:15 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HBqC06007285 for ; Thu, 17 Jul 2003 04:52:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HBnrUY002859 for ; Thu, 17 Jul 2003 04:49:53 -0700 (PDT) Received: from c001.snv.cp.net (h024.c001.snv.cp.net [209.228.32.139]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with SMTP id h6HBnm65009889 for ; Thu, 17 Jul 2003 04:49:48 -0700 (PDT) Received: (cpmta 1416 invoked from network); 17 Jul 2003 04:49:47 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 17 Jul 2003 04:49:47 -0700 X-Sent: 17 Jul 2003 11:49:47 GMT Message-ID: <004b01c34c59$87ff1f30$03051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <11b701c34c41$c8e74210$eb88a051@consulintel.es> <3F166949.9652862@hursley.ibm.com> Subject: Re: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 14:49:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As we still have not provided a replacement for the FEC0:: addresses I would be hesitant to start trying to make rules about what is allowed and not allowed until a replacement is defined. As it is the WG is spending a lot of time debating items that make a lot of sense rather than offering reasonable alternatives. As I understand it we have removed site locals (FEC0::) after they were included in an RFC and implemented in many places, so now it was recommended to not assign this range to prevent conflicts (which makes it a de facto usable site local). Lets not make the same mistake. A best practices or RFC that gives a solution is better than trying to tell people that is bad and not supported so if you do it you are not compliant. If NAT is so bad, then offer an alternative not a critisim. Network Admins. have gotten in the habit of blocking reall addresses from the public network and will need a good altnative before they stop doing it, so let's find an alternative. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 05:02:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HC2W06008376; Thu, 17 Jul 2003 05:02:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HC2Wk9008375; Thu, 17 Jul 2003 05:02:32 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HC2Q06008346 for ; Thu, 17 Jul 2003 05:02:26 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HC07UY005035 for ; Thu, 17 Jul 2003 05:00:07 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6HC02sP024546 for ; Thu, 17 Jul 2003 06:00:02 -0600 (MDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6HBxsj3261864; Thu, 17 Jul 2003 07:59:54 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-252-1.mts.ibm.com [9.65.252.1]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6HBxm95119016; Thu, 17 Jul 2003 05:59:48 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h6HBxFM29507; Thu, 17 Jul 2003 13:59:16 +0200 Message-Id: <200307171159.h6HBxFM29507@cichlid.adsl.duke.edu> To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-Reply-To: Message from pekkas@netcore.fi of "Thu, 17 Jul 2003 10:16:09 +0300." Date: Thu, 17 Jul 2003 13:59:12 +0200 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola writes: > RFC2461 discusses that next-hops must be on-link. > However, section 8 on redirect basically requires: > - routers know each others' link-local addresses (not an issue from > hosts' perspective, just use routing protocols or other mechanisms) > - hosts are able to verify that the redirect comes from the link-local > address the host is currently using as its next-hop As I recall, routers use LL addresses in RAs for source addresses to avoid aliasing problems. If a router has multiple addresses (and if those addresses change over time, e.g., as a result of renumbering) a host could get confused and think there were (say) two routers on the link when the two were really the same. Having the router just always use its LL address when talking to the host via RAs/redirects avoids a bunch of potential problems. E.g., when a router A sends a redirect saying use router B, and B later sends a redirect saying use router C, the source address B uses in the redirect better be the same one router A used as a target in its redirect or the redirect gets ignored. Note that ensuring this would require two different routers to be in sync with each other, which is a pain at best (no obvious way to do that) if any address could be used. Using LLs avoids unneeded complexity. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 05:19:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HCJ706010070; Thu, 17 Jul 2003 05:19:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HCJ77I010069; Thu, 17 Jul 2003 05:19:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HCIu06010004 for ; Thu, 17 Jul 2003 05:18:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HCGbUY009349 for ; Thu, 17 Jul 2003 05:16:37 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HCGV65022424 for ; Thu, 17 Jul 2003 05:16:32 -0700 (PDT) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 14:16:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 14:16:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: avoiding NAT with IPv6 Thread-Index: AcNMRoa+Qfzfd1C+Rn66XDvXa926BgAFSxNQ From: "BAUDOT Alain FTRD/DMI/CAE" To: , , Cc: X-OriginalArrivalTime: 17 Jul 2003 12:16:24.0093 (UTC) FILETIME=[3D518CD0:01C34C5D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6HCIv06010005 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the contrary, maybe, providing a /48 while having a /32 as an ISP makes NAT coming as a solution, according to the potential number of customers... and, for sure, I do agree that we have to make NAT silly. Alain. > -----Message d'origine----- > De : matthew.ford@bt.com [mailto:matthew.ford@bt.com] > Envoyé : jeudi 17 juillet 2003 11:31 > À : brian@hursley.ibm.com; jordi.palet@consulintel.es > Cc : ipng@sunroof.eng.sun.com > Objet : RE: Fw: avoiding NAT with IPv6 > > > Making NAT look silly is good. One case I see where IPv6 NAT > still doesn't > look completely silly is where ISPs hand out /64s to end > users. Pay your > EUR10, buy your IPv6NAT and you have a /48. > > Mat. > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: 17 July 2003 11:16 > > > > Once we have such a thing, we can make positive > > requirements for exploiting it that make NAT look silly. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 05:26:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HCQu06011093; Thu, 17 Jul 2003 05:26:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HCQuQm011092; Thu, 17 Jul 2003 05:26:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HCQp06011079 for ; Thu, 17 Jul 2003 05:26:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HCOWUu005431 for ; Thu, 17 Jul 2003 05:24:32 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HCOO1v018223 for ; Thu, 17 Jul 2003 05:24:27 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 17FAD13; Thu, 17 Jul 2003 21:24:22 +0900 (JST) To: "BAUDOT Alain FTRD/DMI/CAE" Cc: matthew.ford@bt.com, brian@hursley.ibm.com, jordi.palet@consulintel.es, ipng@sunroof.eng.sun.com In-reply-to: alain.baudot's message of Thu, 17 Jul 2003 14:16:22 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fw: avoiding NAT with IPv6 From: itojun@iijlab.net Date: Thu, 17 Jul 2003 21:24:22 +0900 Message-Id: <20030717122422.17FAD13@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >On the contrary, maybe, providing a /48 while having a /32 as an >ISP makes NAT coming as a solution, according to the potential >number of customers... and, for sure, I do agree that we have to >make NAT silly. ISP can ask for more address to RIR when they have got 2^16 customers. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 05:33:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HCX106011506; Thu, 17 Jul 2003 05:33:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HCX1A4011505; Thu, 17 Jul 2003 05:33:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HCWv06011495 for ; Thu, 17 Jul 2003 05:32:57 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HCUcUY012387 for ; Thu, 17 Jul 2003 05:30:38 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HCUXDk016014 for ; Thu, 17 Jul 2003 06:30:33 -0600 (MDT) Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h6HCUWUZ022937 for ; Thu, 17 Jul 2003 05:30:33 -0700 (MST) Received: from motorola.com (mvp-10-238-2-239.corp.mot.com [10.238.2.239]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h6HCURlf001530 for ; Thu, 17 Jul 2003 07:30:30 -0500 Message-ID: <3F1696DF.4090709@motorola.com> Date: Thu, 17 Jul 2003 22:30:23 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: a concern on bridge-like nd-proxies References: <3F155AD8.607CCCFB@hursley.ibm.com> <3F155AD8.607CCCFB@hursley.ibm.com> <5.1.0.14.2.20030717010944.030e45b0@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030717010944.030e45b0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > At 10:39 AM 7/16/2003 -0400, Keith Moore wrote: > >> Lately I find myself wondering if there's not room for a uniform >> layer 2.5 >> interface that is designed to work over a set of bridged 802-style >> layer 2 >> networks, but presents a slightly different interface to the host. So >> for >> instance hosts would be explicitly required to announce presence on a >> link (no >> more passive waiting for ARP requests), there would be an explicit L2.5 >> multicast join/leave (no more sniffing for L3 multicast requests) [...] >> >> (has this already been worked on and I just don't know about it?) > See also http://www.ietf.org/internet-drafts/draft-perlman-zerouter-rbridge-00.txt It doesn't address authenticating link access. > I think that the idea of Dave Thaler's draft, though (and similar > work by others) is to switch at layer 3, so that there is no need > for layer 2 switching in this type of environment. Right. And also to providing bridging of IP traffic across link layers that don't use 48bit 802-style L2 addressing. - aidan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 05:50:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HCoT06013753; Thu, 17 Jul 2003 05:50:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HCoSDV013752; Thu, 17 Jul 2003 05:50:28 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HCoP06013742 for ; Thu, 17 Jul 2003 05:50:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HCm6UY016361 for ; Thu, 17 Jul 2003 05:48:06 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HCm01v029844 for ; Thu, 17 Jul 2003 05:48:00 -0700 (PDT) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 14:47:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 14:47:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: avoiding NAT with IPv6 Thread-Index: AcNMXl8X114zrWVvT9Coq0RxCKYxigAAYtvw From: "BAUDOT Alain FTRD/DMI/CAE" To: Cc: , , , X-OriginalArrivalTime: 17 Jul 2003 12:47:39.0200 (UTC) FILETIME=[9AF82C00:01C34C61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6HCoP06013743 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >On the contrary, maybe, providing a /48 while having a /32 as an > >ISP makes NAT coming as a solution, according to the potential > >number of customers... and, for sure, I do agree that we have to > >make NAT silly. > > ISP can ask for more address to RIR when they have got > 2^16 customers. > Sure. I just wonder if a /48 at home is really apprpriate. Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 06:00:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HD0p06015117; Thu, 17 Jul 2003 06:00:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HD0pkr015116; Thu, 17 Jul 2003 06:00:51 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HD0m06015109 for ; Thu, 17 Jul 2003 06:00:48 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HCwTUY018499 for ; Thu, 17 Jul 2003 05:58:29 -0700 (PDT) Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HCwMsR025422 for ; Thu, 17 Jul 2003 06:58:22 -0600 (MDT) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SWDSK38>; Thu, 17 Jul 2003 13:58:26 +0100 Message-ID: From: matthew.ford@bt.com To: alain.baudot@rd.francetelecom.com, itojun@iijlab.net Cc: brian@hursley.ibm.com, jordi.palet@consulintel.es, ipng@sunroof.eng.sun.com Subject: RE: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 13:58:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: BAUDOT Alain FTRD/DMI/CAE > Sent: 17 July 2003 14:48 > Sure. I just wonder if a /48 at home is really apprpriate. My /48 is certainly appropriate for my home, and I'm very glad my provider didn't assume otherwise. Mat. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 06:03:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HD3K06015619; Thu, 17 Jul 2003 06:03:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HD3KhY015618; Thu, 17 Jul 2003 06:03:20 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HD3G06015605 for ; Thu, 17 Jul 2003 06:03:16 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HD0vUu014867 for ; Thu, 17 Jul 2003 06:00:57 -0700 (PDT) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6HD0pv5014858 for ; Thu, 17 Jul 2003 07:00:51 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6HD0bnx050914; Thu, 17 Jul 2003 15:00:37 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6HD0ace284042; Thu, 17 Jul 2003 15:00:36 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA53374; Thu, 17 Jul 2003 15:00:32 +0200 Message-ID: <3F169DF6.13B9354E@hursley.ibm.com> Date: Thu, 17 Jul 2003 15:00:38 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: BAUDOT Alain FTRD/DMI/CAE CC: itojun@iijlab.net, matthew.ford@bt.com, jordi.palet@consulintel.es, ipng@sunroof.eng.sun.com Subject: Re: Fw: avoiding NAT with IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Unless you think we are likely to exhaust the 35 trillion /48s quickly, it's entirely appropriate (because it keeps things simple). Brian BAUDOT Alain FTRD/DMI/CAE wrote: > > > >On the contrary, maybe, providing a /48 while having a /32 as an > > >ISP makes NAT coming as a solution, according to the potential > > >number of customers... and, for sure, I do agree that we have to > > >make NAT silly. > > > > ISP can ask for more address to RIR when they have got > > 2^16 customers. > > > Sure. I just wonder if a /48 at home is really apprpriate. > > Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 06:16:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HDG106017713; Thu, 17 Jul 2003 06:16:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HDG1MF017712; Thu, 17 Jul 2003 06:16:01 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HDFu06017705 for ; Thu, 17 Jul 2003 06:15:57 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6HDDWQ13581; Thu, 17 Jul 2003 15:13:33 +0200 (MEST) Date: Thu, 17 Jul 2003 15:11:50 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: global/link-local nexthops and RFC2461 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, section 8 on redirect basically requires: > - routers know each others' link-local addresses (not an issue from > hosts' perspective, just use routing protocols or other mechanisms) > - hosts are able to verify that the redirect comes from the link-local > address the host is currently using as its next-hop > > The latter is a bit problematic. How could the host know this in the case > where the next-hop has been configured using e.g. a _global_ (but on-link) > address? > > What's the deal here? Per rfc 2461 the source address of the redirect must be a link-local address. Thus if you want to create a static route on the host and make redirects work at the same time you'd better use the link-local address of the router in the static route. So apart from this requirement on the manually added static routes, what is the issue? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 06:18:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HDIN06018036; Thu, 17 Jul 2003 06:18:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HDINEp018035; Thu, 17 Jul 2003 06:18:23 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HDIE06017990 for ; Thu, 17 Jul 2003 06:18:16 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HDFrUY025633 for ; Thu, 17 Jul 2003 06:15:53 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HDFlDk003075 for ; Thu, 17 Jul 2003 07:15:47 -0600 (MDT) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 15:15:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 15:15:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: avoiding NAT with IPv6 Thread-Index: AcNMY5eypEImkiSQTyKMgdS7E/jezAAAHdvA From: "BAUDOT Alain FTRD/DMI/CAE" To: "Brian E Carpenter" Cc: , , , X-OriginalArrivalTime: 17 Jul 2003 13:15:34.0748 (UTC) FILETIME=[81AC81C0:01C34C65] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6HDIG06017993 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Unless you think we are likely to exhaust the > 35 trillion /48s quickly, it's entirely appropriate > (because it keeps things simple). > Agree on simplicity. A fix length is necessary. My concern is just about the ratio between the /32 and the /something provided to everyone. And then comes the need of an efficient process enabling to get hundreds of /32 in order to have a reasonable number of happy customers. Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 06:33:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HDXt06019948; Thu, 17 Jul 2003 06:33:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HDXtxV019947; Thu, 17 Jul 2003 06:33:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HDXp06019940 for ; Thu, 17 Jul 2003 06:33:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HDVXUY004885 for ; Thu, 17 Jul 2003 06:31:33 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HDVM65001922 for ; Thu, 17 Jul 2003 06:31:27 -0700 (PDT) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 15:30:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fw: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 15:30:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: avoiding NAT with IPv6 Thread-Index: AcNMWhxGXaA531y7SXyr0jQNiRhFUQACxa3g From: "BINET David FTRD/DMI/CAE" To: "EricLKlein" , X-OriginalArrivalTime: 17 Jul 2003 13:30:20.0406 (UTC) FILETIME=[91913160:01C34C67] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6HDXq06019941 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Eric. I don't think the right thing to do is to forbid smth and to recommend to not support some translation mechanism. If we want customers or end users do not use IPv6NAT, we have to adopt right policies, to enable "NAT assets" by other IPv6 means and maybe better communicate on NAT drawbacks but it seems difficult to forbid NAT and afterwards problem will be solved. I do think that a right policy consists in not providing /64 to customers even if some mechanism such as ND-proxy maybe can be used to prevent NAT use. > -----Message d'origine----- > De : EricLKlein [mailto:ericlklein@softhome.net] > Envoyé : jeudi 17 juillet 2003 13:50 > À : ipng@sunroof.eng.sun.com > Objet : Re: Fw: avoiding NAT with IPv6 > > > As we still have not provided a replacement for the FEC0:: > addresses I would > be hesitant to start trying to make rules about what is > allowed and not > allowed until a replacement is defined. > > As it is the WG is spending a lot of time debating items that > make a lot of > sense rather than offering reasonable alternatives. > > As I understand it we have removed site locals (FEC0::) after > they were > included in an RFC and implemented in many places, so now it > was recommended > to not assign this range to prevent conflicts (which makes it > a de facto > usable site local). Lets not make the same mistake. > > A best practices or RFC that gives a solution is better than > trying to tell > people that is bad and not supported so if you do it you are > not compliant. > > If NAT is so bad, then offer an alternative not a critisim. > Network Admins. > have gotten in the habit of blocking reall addresses from the > public network > and will need a good altnative before they stop doing it, so > let's find an > alternative. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 06:58:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HDwV06022161; Thu, 17 Jul 2003 06:58:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HDwU4f022157; Thu, 17 Jul 2003 06:58:30 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HDwP06022135 for ; Thu, 17 Jul 2003 06:58:26 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HDu7Uu001082 for ; Thu, 17 Jul 2003 06:56:07 -0700 (PDT) Received: from oak1a.cats.ohiou.edu (oak.cats.ohiou.edu [132.235.8.44]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HDu1Dk017738 for ; Thu, 17 Jul 2003 07:56:01 -0600 (MDT) Received: from hkruse.csm.ohiou.edu (hkruse.csm.ohiou.edu [132.235.75.144]) (authenticated bits=0) by oak2a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h6HDpFPN1118493 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 17 Jul 2003 09:51:16 -0400 (EDT) Date: Thu, 17 Jul 2003 09:51:20 -0400 From: Hans Kruse To: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 Message-ID: <228478654.1058435480@hkruse.csm.ohiou.edu> In-Reply-To: <127601c34c45$42dbc7a0$eb88a051@consulintel.es> References: <127601c34c45$42dbc7a0$eb88a051@consulintel.es> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But, as has been pointed out many times, getting the address space allocated is not always possible/affordable/practical (which is where site locals came from). I would much prefer the approach mentioned before -- create an addressing infrastructure that solves known issues better than NAT. I think the current draft(s) being discussed are getting close. --On Thursday, July 17, 2003 11:24 +0200 JORDI PALET MARTINEZ wrote: > What about something like: > > IPv6 has enough addressing space that allows avoid the need of any kind > of address translation, that is considered harmful according [RFCxxxx]. > Consequently, IPv6 nodes MUST NOT support any kind of address translation. > Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 07:11:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEBI06023150; Thu, 17 Jul 2003 07:11:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HEBHO2023149; Thu, 17 Jul 2003 07:11:17 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEBE06023142 for ; Thu, 17 Jul 2003 07:11:14 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HE8tUu004725 for ; Thu, 17 Jul 2003 07:08:55 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HE8nsR005801 for ; Thu, 17 Jul 2003 08:08:49 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6HE8jY06466; Thu, 17 Jul 2003 17:08:46 +0300 Date: Thu, 17 Jul 2003 17:08:45 +0300 (EEST) From: Pekka Savola To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-Reply-To: <200307171159.h6HBxFM29507@cichlid.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jul 2003, Thomas Narten wrote: > Pekka Savola writes: > > > RFC2461 discusses that next-hops must be on-link. > > > However, section 8 on redirect basically requires: > > - routers know each others' link-local addresses (not an issue from > > hosts' perspective, just use routing protocols or other mechanisms) > > - hosts are able to verify that the redirect comes from the link-local > > address the host is currently using as its next-hop > > As I recall, routers use LL addresses in RAs for source addresses to > avoid aliasing problems. If a router has multiple addresses (and if > those addresses change over time, e.g., as a result of renumbering) a > host could get confused and think there were (say) two routers on the > link when the two were really the same. [...] Yes, routers use LL as source addresses. So, basically you could specify that, like, when you discover the L2 address of your router, you'll record it's source address somewhere (to be used when redirects arrive). (you don't even have to wait for RA's I think) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 07:15:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEFl06023543; Thu, 17 Jul 2003 07:15:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HEFkas023542; Thu, 17 Jul 2003 07:15:46 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEFh06023532 for ; Thu, 17 Jul 2003 07:15:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HEDOUY016196 for ; Thu, 17 Jul 2003 07:13:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HEDI1v014315 for ; Thu, 17 Jul 2003 07:13:19 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6HEDE106529; Thu, 17 Jul 2003 17:13:14 +0300 Date: Thu, 17 Jul 2003 17:13:14 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jul 2003, Erik Nordmark wrote: > > However, section 8 on redirect basically requires: > > - routers know each others' link-local addresses (not an issue from > > hosts' perspective, just use routing protocols or other mechanisms) > > - hosts are able to verify that the redirect comes from the link-local > > address the host is currently using as its next-hop > > > > The latter is a bit problematic. How could the host know this in the case > > where the next-hop has been configured using e.g. a _global_ (but on-link) > > address? > > > > What's the deal here? > > Per rfc 2461 the source address of the redirect must be a link-local address. > Thus if you want to create a static route on the host and make > redirects work at the same time you'd better use the link-local address > of the router in the static route. > > So apart from this requirement on the manually added static routes, what > is the issue? I think the question whether: - we want to specify next-hops must be link-locals - we want to clearly state that redirects work only when using link-locals, and when the link-locals are the same as used in next-hops - we want to figure out whether it's worth exploring the details needed to make redirects work with global/anycast next-hops. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 07:17:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEHY06023843; Thu, 17 Jul 2003 07:17:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HEHXFj023832; Thu, 17 Jul 2003 07:17:33 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEHO06023780 for ; Thu, 17 Jul 2003 07:17:24 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HEF5Uu006106 for ; Thu, 17 Jul 2003 07:15:05 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6HEExv5023096 for ; Thu, 17 Jul 2003 08:14:59 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6HEEsk06547; Thu, 17 Jul 2003 17:14:55 +0300 Date: Thu, 17 Jul 2003 17:14:54 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-Reply-To: <20030717080009.281FD13@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jul 2003 itojun@iijlab.net wrote: > >This is not a problem (IMO): the problem is that certain global addresses > >are *also* on-link, but cause issues with redirects. > > so i suggest replacing "next-hop must be onlink" with > "next-hop must be link-local". Would this also apply in some other cases, like configuring 6to4 nexthop as 2002: ? (or in P-t-P links or tunnels where redirects aren't possible) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 07:19:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEJb06024179; Thu, 17 Jul 2003 07:19:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HEJbSt024178; Thu, 17 Jul 2003 07:19:37 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEJX06024165 for ; Thu, 17 Jul 2003 07:19:33 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HEHEUY017269 for ; Thu, 17 Jul 2003 07:17:14 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6HEH8sP011254 for ; Thu, 17 Jul 2003 08:17:08 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6HEH7J21007 for ; Thu, 17 Jul 2003 17:17:07 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 17:17:07 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 17:17:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 17:17:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 17:17:06 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: avoiding NAT with IPv6 Thread-Index: AcNMXjKilhhZbf59Tuq725WSbuQOlQADup0Q From: To: , X-OriginalArrivalTime: 17 Jul 2003 14:17:07.0200 (UTC) FILETIME=[1A8BF800:01C34C6E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6HEJX06024167 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jordi, > I mean, if a vendor don't pass a given RFC in a > conformance/interoperability, because they do NAT, then a lot of customers (ISPs, > Telcos) will not purchase it, because that's what the market > do most of the time. And this is a "market" enforcement ... Is this true, there are a number of RFCs that tell about the bad things NATs do, but NATs are not slowing down at all. http://www.ietf.org/rfc/rfc2993.txt?number=2993 http://www.ietf.org/rfc/rfc3027.txt?number=3027 http://www.ietf.org/rfc/rfc3424.txt?number=3424 > What about something like: > > IPv6 has enough addressing space that allows avoid the need > of any kind of address translation, that is considered harmful according > [RFCxxxx]. Consequently, IPv6 nodes MUST NOT support any kind > of address translation. A purely procedural problem exists - the above drafts are information, so I don't think they can be used as a justfication for use of MUST NOT in this document. Someone correct me if I am wrong. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 07:31:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEVh06026066; Thu, 17 Jul 2003 07:31:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HEVg2A026065; Thu, 17 Jul 2003 07:31:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEVd06026055 for ; Thu, 17 Jul 2003 07:31:39 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HETKUu010531 for ; Thu, 17 Jul 2003 07:29:20 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HET9sR018002 for ; Thu, 17 Jul 2003 08:29:09 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6HET5R05058; Thu, 17 Jul 2003 16:29:05 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6HERWof049270; Thu, 17 Jul 2003 16:27:32 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307171427.h6HERWof049270@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-reply-to: Your message of Thu, 17 Jul 2003 17:13:14 +0300. Date: Thu, 17 Jul 2003 16:27:32 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think the question whether: - we want to specify next-hops must be link-locals => I disagree (the must is far too strong) - we want to clearly state that redirects work only when using link-locals, and when the link-locals are the same as used in next-hops => I agree - we want to figure out whether it's worth exploring the details needed to make redirects work with global/anycast next-hops. => I disagree (we have far more useful things to do). In conclusion my opinion is N/Y/N. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 07:34:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEYs06026582; Thu, 17 Jul 2003 07:34:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HEYsP1026581; Thu, 17 Jul 2003 07:34:54 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEYl06026540 for ; Thu, 17 Jul 2003 07:34:47 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HEWSUY022015 for ; Thu, 17 Jul 2003 07:32:28 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HEWB65005120 for ; Thu, 17 Jul 2003 07:32:22 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h6HEVt822146; Thu, 17 Jul 2003 21:31:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h6HEVes29115; Thu, 17 Jul 2003 21:31:40 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 2003 21:31:40 +0700 Message-ID: <28691.1058452300@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Jul 2003 15:11:50 +0200 (CEST) From: Erik Nordmark Message-ID: | Thus if you want to create a static route on the host and make | redirects work at the same time you'd better use the link-local address | of the router in the static route. Of course, an implementation can easily (if asked to install a route with a non-LL address as next hop) send a NIQ and get the equivalent LL address ... (in unix type systems the route(8) command would do that before installing it in the kernel). If something like this isn't done, we won't be able to do route add name-of-gateway as the name-of-gateway to address translation is unlikely (normally anyway) to produce an LL address. I certainly agree that next-hops should always be LL addresses. I also don't think the "router has multiple LL addresses so we can get confused" case is likely to ever be common enough to bother anyone, so I wouldn't waste any effort on looking for solutions to that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 07:41:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEfN06027181; Thu, 17 Jul 2003 07:41:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HEfNXP027180; Thu, 17 Jul 2003 07:41:23 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEfK06027170 for ; Thu, 17 Jul 2003 07:41:20 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HEd0Uu013296 for ; Thu, 17 Jul 2003 07:39:01 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HEcjsR024155 for ; Thu, 17 Jul 2003 08:38:46 -0600 (MDT) Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 62-md50000000080.tmp for ; Thu, 17 Jul 2003 16:40:14 +0200 Message-ID: <157801c34c71$4f202cf0$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 16:39:59 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Thu, 17 Jul 2003 16:40:14 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, Yes, probably you're right. Let's then put it in another way (the positive one): An IPv6 node (having forwarding capability for packets for what isn't the end destination), MUST NOT translate the source or destination addresses. We can add part of my previous text to explain this. Regards, Jordi ----- Original Message ----- From: To: ; Sent: Thursday, July 17, 2003 4:17 PM Subject: RE: avoiding NAT with IPv6 > Hi Jordi, > > > I mean, if a vendor don't pass a given RFC in a > > conformance/interoperability, because they do NAT, then a lot of customers (ISPs, > > Telcos) will not purchase it, because that's what the market > > do most of the time. And this is a "market" enforcement ... > > Is this true, there are a number of RFCs that tell about the bad > things NATs do, but NATs are not slowing down at all. > > http://www.ietf.org/rfc/rfc2993.txt?number=2993 > > http://www.ietf.org/rfc/rfc3027.txt?number=3027 > > http://www.ietf.org/rfc/rfc3424.txt?number=3424 > > > What about something like: > > > > IPv6 has enough addressing space that allows avoid the need > > of any kind of address translation, that is considered harmful according > > [RFCxxxx]. Consequently, IPv6 nodes MUST NOT support any kind > > of address translation. > > A purely procedural problem exists - the above drafts are > information, so I don't think they can be used as a justfication > for use of MUST NOT in this document. Someone correct me if I am > wrong. > > John > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 07:42:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEgJ06027258; Thu, 17 Jul 2003 07:42:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HEgJiZ027257; Thu, 17 Jul 2003 07:42:19 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HEgF06027247 for ; Thu, 17 Jul 2003 07:42:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HEdvUY024133 for ; Thu, 17 Jul 2003 07:39:57 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HEdo65009878 for ; Thu, 17 Jul 2003 07:39:51 -0700 (PDT) Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 64-md50000000080.tmp for ; Thu, 17 Jul 2003 16:41:21 +0200 Message-ID: <158001c34c71$770445d0$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <127601c34c45$42dbc7a0$eb88a051@consulintel.es> <228478654.1058435480@hkruse.csm.ohiou.edu> Subject: Re: avoiding NAT with IPv6 Date: Thu, 17 Jul 2003 16:41:05 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Thu, 17 Jul 2003 16:41:21 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agree, but doing both things (address space and avoid NAT) will be more useful than just one. Regards, Jordi ----- Original Message ----- From: "Hans Kruse" To: Sent: Thursday, July 17, 2003 3:51 PM Subject: Re: avoiding NAT with IPv6 > But, as has been pointed out many times, getting the address space > allocated is not always possible/affordable/practical (which is where site > locals came from). > > I would much prefer the approach mentioned before -- create an addressing > infrastructure that solves known issues better than NAT. I think the > current draft(s) being discussed are getting close. > > --On Thursday, July 17, 2003 11:24 +0200 JORDI PALET MARTINEZ > wrote: > > > What about something like: > > > > IPv6 has enough addressing space that allows avoid the need of any kind > > of address translation, that is considered harmful according [RFCxxxx]. > > Consequently, IPv6 nodes MUST NOT support any kind of address translation. > > > > > > Hans Kruse, Associate Professor > J. Warren McClure School of Communication Systems Management > Adjunct Associate Professor of Electrical Engineering and Computer Science > Ohio University, Athens, OH, 45701 > 740-593-4891 voice, 740-593-4889 fax > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 08:16:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HFGJ06029544; Thu, 17 Jul 2003 08:16:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HFGJGC029543; Thu, 17 Jul 2003 08:16:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HFGF06029536 for ; Thu, 17 Jul 2003 08:16:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HFDuUu023688 for ; Thu, 17 Jul 2003 08:13:56 -0700 (PDT) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HFDo65000630 for ; Thu, 17 Jul 2003 08:13:51 -0700 (PDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6HFDknx044106; Thu, 17 Jul 2003 17:13:46 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6HFDjtC273096; Thu, 17 Jul 2003 17:13:46 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA33608; Thu, 17 Jul 2003 17:13:42 +0200 Message-ID: <3F16BD2C.524C49B8@hursley.ibm.com> Date: Thu, 17 Jul 2003 17:13:48 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 References: <157801c34c71$4f202cf0$eb88a051@consulintel.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually, what might be reasonable is for the next revision of RFC 2460 to contain a list of header fields that are mutable end to end (such as the hop limit and the traffic class) plus a statement that all other header fields MUST be delivered unchanged. Then a future version of node requirements can cite this. None of which will stop NAT salespersons. Only a more attractive carrot than NAT will do that. Brian JORDI PALET MARTINEZ wrote: > > John, > > Yes, probably you're right. Let's then put it in another way (the positive one): > > An IPv6 node (having forwarding capability for packets for what isn't the end destination), MUST NOT translate the source or > destination addresses. > > We can add part of my previous text to explain this. > > Regards, > Jordi > > ----- Original Message ----- > From: > To: ; > Sent: Thursday, July 17, 2003 4:17 PM > Subject: RE: avoiding NAT with IPv6 > > > Hi Jordi, > > > > > I mean, if a vendor don't pass a given RFC in a > > > conformance/interoperability, because they do NAT, then a lot of customers (ISPs, > > > Telcos) will not purchase it, because that's what the market > > > do most of the time. And this is a "market" enforcement ... > > > > Is this true, there are a number of RFCs that tell about the bad > > things NATs do, but NATs are not slowing down at all. > > > > http://www.ietf.org/rfc/rfc2993.txt?number=2993 > > > > http://www.ietf.org/rfc/rfc3027.txt?number=3027 > > > > http://www.ietf.org/rfc/rfc3424.txt?number=3424 > > > > > What about something like: > > > > > > IPv6 has enough addressing space that allows avoid the need > > > of any kind of address translation, that is considered harmful according > > > [RFCxxxx]. Consequently, IPv6 nodes MUST NOT support any kind > > > of address translation. > > > > A purely procedural problem exists - the above drafts are > > information, so I don't think they can be used as a justfication > > for use of MUST NOT in this document. Someone correct me if I am > > wrong. > > > > John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 10:21:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HHL706011372; Thu, 17 Jul 2003 10:21:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HHL7Uo011369; Thu, 17 Jul 2003 10:21:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HHL206011362; Thu, 17 Jul 2003 10:21:02 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HHIhUY020247; Thu, 17 Jul 2003 10:18:43 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6HHIbsP026883; Thu, 17 Jul 2003 11:18:38 -0600 (MDT) Received: from ocean.jinmei.org (unknown [2001:7f9:8400:10:9d96:4a30:894e:d334]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 07E4615248; Fri, 18 Jul 2003 02:18:34 +0900 (JST) Date: Fri, 18 Jul 2003 02:18:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vladislav Yasevich Cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 Advanced Socket API extension for Mobile IP In-Reply-To: <3F0EFD0C.9000501@hp.com> References: <200307090217.h692H7tf632702@jurassic.eng.sun.com> <3F0EFD0C.9000501@hp.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 11 Jul 2003 14:08:12 -0400, >>>>> Vladislav Yasevich said: > In Section 4.1, the draft describes how to use the IPV6_CHECKSUM > option on mobility headers. The draft seems to turn off "kernel" > checksumming by default on the IPPROTO_MH socket. I belive > that the checksumming should be on by default (similar to ICMPv6) > with the ability to turn it off by the socket. I don't have a particular opinion on whether the checksum calculation on a IPPROTO_MH socket should be enabled or disabled by default, but would like to clarify one thing: > The reason is that > most Mobile IPv6 implementation are supported in the "kernel" and > already do checksumming. What exactly do you imagine about the implementation that supports mobile IPv6 in the kernel? If it generates, does checksumming, and sends a packet with a mobile header completely within the kernel (the KAME implementation apparently acts like this), it can do so without conflicting with any API spec. So I don't get why this is the reason for specifying the behavior on a raw socket used by applications (i.e., not by the kernel.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 11:24:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HIOE06018960; Thu, 17 Jul 2003 11:24:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HIOE1D018959; Thu, 17 Jul 2003 11:24:14 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HIOB06018952; Thu, 17 Jul 2003 11:24:11 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HILpUY015888; Thu, 17 Jul 2003 11:21:52 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6HILkWv021304; Thu, 17 Jul 2003 12:21:46 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 71F1FB1CA; Thu, 17 Jul 2003 14:21:45 -0400 (EDT) Received: from whitestar.zk3.dec.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 941396F6; Thu, 17 Jul 2003 13:21:44 -0500 (CDT) Received: from hp.com by whitestar.zk3.dec.com (8.12.6/1.1.29.3/18Jul02-1258PM) id h6HILf7W113443; Thu, 17 Jul 2003 14:21:43 -0400 (EDT) Message-ID: <3F16E935.40604@hp.com> Date: Thu, 17 Jul 2003 14:21:41 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.3b) Gecko/20030318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?windows-1252?Q?JINMEI_Tatuya_/_=3F=3F=3F=3F?= Cc: Vladislav Yasevich , Samita Chakrabarti , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 Advanced Socket API extension for Mobile IP References: <200307090217.h692H7tf632702@jurassic.eng.sun.com> <3F0EFD0C.9000501@hp.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / ???? wrote: >>The reason is that >>most Mobile IPv6 implementation are supported in the "kernel" and >>already do checksumming. > > > What exactly do you imagine about the implementation that supports > mobile IPv6 in the kernel? > If it generates, does checksumming, and > sends a packet with a mobile header completely within the kernel (the > KAME implementation apparently acts like this), it can do so without > conflicting with any API spec. So I don't get why this is the reason > for specifying the behavior on a raw socket used by applications > (i.e., not by the kernel.) I guess I was originally looking at it from the recieve side. On a aystem that already implements MIPv6 message handling at the network layer (in the kernel), it's rather pointless to set the IPV6_CHECKSUM option since the packet will be checked anyway. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX Network Group Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 11:41:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HIfA06021901; Thu, 17 Jul 2003 11:41:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HIfAPB021900; Thu, 17 Jul 2003 11:41:10 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HIf306021883; Thu, 17 Jul 2003 11:41:03 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HIciUY023596; Thu, 17 Jul 2003 11:38:44 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6HIccQY004433; Thu, 17 Jul 2003 12:38:39 -0600 (MDT) Received: from ocean.jinmei.org (unknown [2001:7f9:8400:10:792b:b272:314:6133]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D87BC15257; Fri, 18 Jul 2003 03:38:33 +0900 (JST) Date: Fri, 18 Jul 2003 03:38:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vladislav Yasevich Cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 Advanced Socket API extension for Mobile IP In-Reply-To: <3F16E935.40604@hp.com> References: <200307090217.h692H7tf632702@jurassic.eng.sun.com> <3F0EFD0C.9000501@hp.com> <3F16E935.40604@hp.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 17 Jul 2003 14:21:41 -0400, >>>>> Vladislav Yasevich said: >>> The reason is that >>> most Mobile IPv6 implementation are supported in the "kernel" and >>> already do checksumming. >> >> What exactly do you imagine about the implementation that supports >> mobile IPv6 in the kernel? >> If it generates, does checksumming, and >> sends a packet with a mobile header completely within the kernel (the >> KAME implementation apparently acts like this), it can do so without >> conflicting with any API spec. So I don't get why this is the reason >> for specifying the behavior on a raw socket used by applications >> (i.e., not by the kernel.) > I guess I was originally looking at it from the recieve side. On > a aystem that already implements MIPv6 message handling at the > network layer (in the kernel), it's rather pointless to set the > IPV6_CHECKSUM option since the packet will be checked anyway. I see, but my point still applies: if the implementation receives, validates the checksum, and processes a packet with a mobile header completely within the kernel, it can do so without conflicting with any API spec. The KAME implementation apparently acts like this. It in fact does not send the received packet with a mobility header to the "raw IPv6 socket" layer. Instead, it directly passes the packet to a separate routine dedicated to Mobile IPv6 where the checksum is validated. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 17 13:08:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HK8406003572; Thu, 17 Jul 2003 13:08:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6HK84Fr003571; Thu, 17 Jul 2003 13:08:04 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6HK7x06003564 for ; Thu, 17 Jul 2003 13:08:00 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6HK5WQ12830; Thu, 17 Jul 2003 22:05:32 +0200 (MEST) Date: Thu, 17 Jul 2003 22:03:49 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: global/link-local nexthops and RFC2461 To: Pekka Savola Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - we want to figure out whether it's worth exploring the details needed > to make redirects work with global/anycast next-hops. Explored the global part long time ago. Conclusion was: In order to make redirects work well in this case and maintain the check to only accept redirects from the current nexthop requires the host to maintain an equivalence class for each router on the link i.e. knowing all the addresses of all the routers on the link. This adds memory requirements and some more complexity on small hosts for not much benefit. Also, accepting redirects from non-link-local sources removes one security check (but we still have the hoplimit=255 check; but implementation bugs means it might make sense to have two checks instead of one). Anycast is harder due to the "no anycast as source" requirement. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 00:44:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I7iB06008743; Fri, 18 Jul 2003 00:44:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6I7iBBH008742; Fri, 18 Jul 2003 00:44:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I7i706008735 for ; Fri, 18 Jul 2003 00:44:07 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6I7fjUu027783 for ; Fri, 18 Jul 2003 00:41:45 -0700 (PDT) Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6I7fdQY024746 for ; Fri, 18 Jul 2003 01:41:39 -0600 (MDT) Received: from paul2 ([81.160.243.20]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with SMTP id h6I7fbk13454; Fri, 18 Jul 2003 09:41:38 +0200 (MEST) Message-ID: <002e01c34cc5$89501120$14f3a051@etri.re.kr> From: "Jaehoon Jeong" To: "IPv6 WG" Cc: Subject: DNS discovery discussion Date: Fri, 18 Jul 2003 09:42:58 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h6I7i806008736 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi IPv6 members. As it seems that the discussion of DNS discovery is related to IPv6 wg, I send this issue to IPv6 wg for listening to IPv6 members' liberal opinions and comments. In this DNSOP meeting and mailing list, RA-based DNS discovery has been being discussed in comparison with DHCP-based DNS discovery. You can find the mails related to this issue in the following link; http://www.cafax.se/dnsop/maillist/2003-07/maillist.html For consistent and time-saving autoconfiguration, I think, we need to adopt one of two alternatives in sequence (stateless and stateful approaches). In IPv4 domain, DHCP is enough for the autoconfiguration. But, in IPv6, we introduced stateless autoconfiguration. Like Tim's opinion, DNS information is missing in the current IPv6 stateless autoconfiguration. Of course, DHCPv6 is a good solution. However, in order to get only DNS information, it is so limited direction for all kinds of IPv6 networks, such as home network, HMIPv6, NEMO and MANET connected to the Internet, to adopt only DHCPv6-based DNS discovery. IMHO, RA-based DNS discovery is a really really good companion with DHCP approach, not enemy or competitor. Just in order to announce DNS information, isn't to run DHCPv6(Lite) overactive? RA-piggyback announcement of DNS information with prefix information is efficient in the respect of the amount of announced traffic. In current Cisco router, we configure the addresses of recursive DNS servers for its own name resolution. Therefore, the DNS servers' addresses have already been configured. We only have to use the information so as to announce DNS information through RA message. I think DNS discovery is indispensible in IPv6, as you know. RA camp including me continues to appeal the need of RA-based DNS discovery for IPv6 working more flexibly even in the environment where there is no DHCPv6. If many of IPv6 members think that RA-based DNS discovery is not necessary, there may be no reason to discuss any more and the RA-based DNS discovery should not be suggested forever. I wait for your liberal and frank criticism or opinions. /Jaehoon Paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 01:13:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I8DV06009657; Fri, 18 Jul 2003 01:13:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6I8DV26009656; Fri, 18 Jul 2003 01:13:31 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I8DQ06009639 for ; Fri, 18 Jul 2003 01:13:26 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6I8B5Uu003661 for ; Fri, 18 Jul 2003 01:11:05 -0700 (PDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6I8AxWv028781 for ; Fri, 18 Jul 2003 02:10:59 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI700CJNO2B47@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 18 Jul 2003 02:10:59 -0600 (MDT) Received: from sun.com ([81.160.221.46]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI700LR7NVQZB@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 18 Jul 2003 02:07:06 -0600 (MDT) Date: Fri, 18 Jul 2003 01:07:08 -0700 From: Alain Durand Subject: Re: DNS discovery discussion In-reply-to: <002e01c34cc5$89501120$14f3a051@etri.re.kr> To: Jaehoon Jeong Cc: IPv6 WG , dnsop@cafax.se Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This discussion has been going on in the v6 wg for a while without success, it is now to dnsop, let's go there and hope we'll make progress. no need to crosspost, IMHO. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 01:17:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I8HP06009883; Fri, 18 Jul 2003 01:17:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6I8HPXb009882; Fri, 18 Jul 2003 01:17:25 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I8HE06009862; Fri, 18 Jul 2003 01:17:14 -0700 (PDT) Received: from eng.sun.com (vpn-129-156-96-166.EMEA.Sun.COM [129.156.96.166]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6I8Eo9j686810; Fri, 18 Jul 2003 01:14:51 -0700 (PDT) Message-ID: <3F17AE95.16B6AB44@eng.sun.com> Date: Fri, 18 Jul 2003 01:23:49 -0700 From: Samita Chakrabarti X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav.Yasevich@hp.com CC: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 Advanced Socket API extension for MobileIP References: <200307090217.h692H7tf632702@jurassic.eng.sun.com> <3F0EFD0C.9000501@hp.com> <3F16E935.40604@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > What exactly do you imagine about the implementation that supports > > mobile IPv6 in the kernel? > > If it generates, does checksumming, and > > sends a packet with a mobile header completely within the kernel (the > > KAME implementation apparently acts like this), it can do so without > > conflicting with any API spec. So I don't get why this is the reason > > for specifying the behavior on a raw socket used by applications > > (i.e., not by the kernel.) > > I guess I was originally looking at it from the recieve side. On > a aystem that already implements MIPv6 message handling at the > network layer (in the kernel), it's rather pointless to set the > IPV6_CHECKSUM option since the packet will be checked anyway. > IPV6_CHECKSUM is already implemented through IPv6 Socket API, so there is no additional work to support IPV6_CHECKSUM socket option for MH protocol in the API layer when checksum is already performed at the kernel. Kernel needs to handle a few lines of code for not doing checksum when the option was not set. So, I don't think it's a big issue to debate about IPV6_CHECKSUM, let's keep the way it is. Thanks, -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 01:21:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I8LX06010212; Fri, 18 Jul 2003 01:21:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6I8LXv6010211; Fri, 18 Jul 2003 01:21:33 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I8LT06010193 for ; Fri, 18 Jul 2003 01:21:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6I8J8UY012802 for ; Fri, 18 Jul 2003 01:19:08 -0700 (PDT) Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6I8J1uR019692 for ; Fri, 18 Jul 2003 01:19:02 -0700 (PDT) Received: from paul2 ([81.160.243.20]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with SMTP id h6I8Iqk13512; Fri, 18 Jul 2003 10:18:52 +0200 (MEST) Message-ID: <006401c34cca$bd0e1f70$14f3a051@etri.re.kr> From: "Jaehoon Jeong" To: "Alain Durand" Cc: "IPv6 WG" , References: Subject: Re: DNS discovery discussion Date: Fri, 18 Jul 2003 10:20:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h6I8LT06010197 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk That's Okay. I appreciate your previous work related to DNS discovery until now. I really hope we'll solve the issue successfully. Thanks. Jaehoon Paul ----- Original Message ----- From: "Alain Durand" To: "Jaehoon Jeong" Cc: "IPv6 WG" ; Sent: Friday, July 18, 2003 5:07 PM Subject: Re: DNS discovery discussion > > This discussion has been going on in the v6 wg for a while without > success, > it is now to dnsop, let's go there and hope we'll make progress. > no need to crosspost, IMHO. > > - Alain. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 01:55:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I8t206013602; Fri, 18 Jul 2003 01:55:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6I8t2Ks013601; Fri, 18 Jul 2003 01:55:02 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6I8sw06013593; Fri, 18 Jul 2003 01:54:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6I8qbUY020375; Fri, 18 Jul 2003 01:52:37 -0700 (PDT) Received: from ltitlout.lntinfotech.com (lntinfotech.com [203.199.54.8]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6I8qTuR005177; Fri, 18 Jul 2003 01:52:31 -0700 (PDT) Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2003071814241446:84 ; Fri, 18 Jul 2003 14:24:14 +0530 Subject: Re: [mobile-ip] Re: IPv6 Advanced Socket API extension for Mobile IP To: JINMEI Tatuya / =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, owner-mobile-ip@sunroof.eng.sun.com, Samita Chakrabarti , Vladislav Yasevich X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Suvidh Mathur" Date: Fri, 18 Jul 2003 10:52:16 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 07/18/2003 02:21:51 PM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 07/18/2003 02:24:15 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 07/18/2003 02:24:48 PM, Serialize complete at 07/18/2003 02:24:48 PM Content-type: text/plain; charset=iso-2022-jp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I agree that MIPv6 implementations within the "kernel" would be self contained units, complete with checksum calculation functions. But in such implementations, the MIPv6 messages would be formed and consumed entirely within the "kernel" and may not have provisions for handling of IPPROTO_MH packets sent from "user space". What I mean is that MIPv6 implementation might consider all packets generated from outside the MIPv6 module as data packets and interact with such packets all for addition of routing header type 2 or home address option. The checksumming would be left to whoever is responsible for generating the message, which would be RAW in this case. A similar scenario could be imagined on the receiving side, i.e. any IPPROTO_MH packet delivered to MIPv6 would be checksummed by MIPv6, but would be consumed there only. Sending of such a packet to any user space application listening on RAW socket would then be the responsibility of the RAW implementation. Suvidh JINMEI Tatuya / $B?@L@C#:H(B co.jp> cc: Samita Chakrabarti , Sent by: imobile-ip@sunroof.eng.sun.com owner-mobile-ip@sunroof. Subject: [mobile-ip] Re: IPv6 Advanced Socket API extension for Mobile IP eng.sun.com 17/07/2003 10:48 PM >>>>> On Fri, 11 Jul 2003 14:08:12 -0400, >>>>> Vladislav Yasevich said: What exactly do you imagine about the implementation that supports mobile IPv6 in the kernel? If it generates, does checksumming, and sends a packet with a mobile header completely within the kernel (the KAME implementation apparently acts like this), it can do so without conflicting with any API spec. So I don't get why this is the reason for specifying the behavior on a raw socket used by applications (i.e., not by the kernel.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 08:18:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6IFI106000871; Fri, 18 Jul 2003 08:18:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6IFI18R000869; Fri, 18 Jul 2003 08:18:01 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6IFHn06000796 for ; Fri, 18 Jul 2003 08:17:49 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6IFFTUu014130 for ; Fri, 18 Jul 2003 08:15:29 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6IFFNt7022841 for ; Fri, 18 Jul 2003 08:15:23 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6IFDEA2016761 for ; Fri, 18 Jul 2003 17:13:14 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA12119 for ipng@sunroof.eng.sun.com; Fri, 18 Jul 2003 16:15:20 +0100 (BST) Date: Fri, 18 Jul 2003 16:15:20 +0100 From: Derek Fawcus To: ipng@sunroof.eng.sun.com Subject: Re: global/link-local nexthops and RFC2461 Message-ID: <20030718161520.J4137@edinburgh.cisco.com> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <200307171427.h6HERWof049270@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200307171427.h6HERWof049270@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Thu, Jul 17, 2003 at 04:27:32PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Jul 17, 2003 at 04:27:32PM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > I think the question whether: > > - we want to specify next-hops must be link-locals > > => I disagree (the must is far too strong) > > - we want to clearly state that redirects work only when using > link-locals, and when the link-locals are the same as used in next-hops > > => I agree > > - we want to figure out whether it's worth exploring the details needed > to make redirects work with global/anycast next-hops. > > => I disagree (we have far more useful things to do). > In conclusion my opinion is N/Y/N. I basically agree with Francis' points above, with one provisio. I may occasionally be possible for a router (with a static route via a non LL next-hop) to discover the corresponding LL and hence validate redirects. Hence I'd say the answer to the second point is that you're only guarenteed to be able to get working redirects if a LL next hop is used. With a non LL next-hop it's imp. (and specific config) dependent if you'll get working redirects. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 19 02:35:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6J9Zi06015480; Sat, 19 Jul 2003 02:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6J9Zija015479; Sat, 19 Jul 2003 02:35:44 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6J9Zf06015472 for ; Sat, 19 Jul 2003 02:35:41 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6J9XKUY002213 for ; Sat, 19 Jul 2003 02:33:20 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6J9XDlQ004370 for ; Sat, 19 Jul 2003 03:33:14 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6J9XCJ26261 for ; Sat, 19 Jul 2003 12:33:13 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 19 Jul 2003 12:33:12 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 19 Jul 2003 12:33:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DNS discovery discussion Date: Sat, 19 Jul 2003 12:33:10 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A16@esebe005.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS discovery discussion Thread-Index: AcNNBXSr/+jCx1E1QQqkgqfE03RzlwA0nsNA From: To: , Cc: , X-OriginalArrivalTime: 19 Jul 2003 09:33:11.0696 (UTC) FILETIME=[C56BD900:01C34DD8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6J9Zf06015473 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, related to the previous comment by Jaehoon Paul, I strongly support specifying (also) a stateless mechanism for IPv6 DNS discovery. (Stateless) DHCPv6 can provide a solution, but still we need a stateless mechanism for environments where DHCPv6 is not used. And I really believe that there are / will be such environments. Cheers, -Juha W.- -----Original Message----- From: ext Jaehoon Jeong [mailto:paul@etri.re.kr] Sent: 18 July, 2003 04:20 To: Alain Durand Cc: IPv6 WG; dnsop@cafax.se Subject: Re: DNS discovery discussion That's Okay. I appreciate your previous work related to DNS discovery until now. I really hope we'll solve the issue successfully. Thanks. Jaehoon Paul ----- Original Message ----- From: "Alain Durand" To: "Jaehoon Jeong" Cc: "IPv6 WG" ; Sent: Friday, July 18, 2003 5:07 PM Subject: Re: DNS discovery discussion > > This discussion has been going on in the v6 wg for a while without > success, > it is now to dnsop, let's go there and hope we'll make progress. > no need to crosspost, IMHO. > > - Alain. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 19 11:00:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6JI0J06016655; Sat, 19 Jul 2003 11:00:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6JI0JxV016654; Sat, 19 Jul 2003 11:00:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6JI0F06016647 for ; Sat, 19 Jul 2003 11:00:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6JHvtUu005179 for ; Sat, 19 Jul 2003 10:57:55 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6JHvlOu022664 for ; Sat, 19 Jul 2003 10:57:49 -0700 (PDT) Received: from consulintel02 ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 7-md50000000012.tmp for ; Sat, 19 Jul 2003 19:59:12 +0200 Message-ID: <01a001c34e1f$6e2ea810$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <157801c34c71$4f202cf0$eb88a051@consulintel.es> <3F16BD2C.524C49B8@hursley.ibm.com> Subject: Re: avoiding NAT with IPv6 Date: Sat, 19 Jul 2003 19:58:55 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Sat, 19 Jul 2003 19:59:12 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, Yes, this seems to me a good approach. In fact, the same text can be used as part of the node-requirements ... Regards, Jordi ----- Original Message ----- From: "Brian E Carpenter" To: "JORDI PALET MARTINEZ" Cc: Sent: Thursday, July 17, 2003 5:13 PM Subject: Re: avoiding NAT with IPv6 > Actually, what might be reasonable is for the next revision > of RFC 2460 to contain a list of header fields that are > mutable end to end (such as the hop limit and the traffic class) > plus a statement that all other header fields MUST be delivered > unchanged. Then a future version of node requirements can > cite this. > > None of which will stop NAT salespersons. Only a more attractive > carrot than NAT will do that. > > Brian > > JORDI PALET MARTINEZ wrote: > > > > John, > > > > Yes, probably you're right. Let's then put it in another way (the positive one): > > > > An IPv6 node (having forwarding capability for packets for what isn't the end destination), MUST NOT translate the source or > > destination addresses. > > > > We can add part of my previous text to explain this. > > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Thursday, July 17, 2003 4:17 PM > > Subject: RE: avoiding NAT with IPv6 > > > > > Hi Jordi, > > > > > > > I mean, if a vendor don't pass a given RFC in a > > > > conformance/interoperability, because they do NAT, then a lot of customers (ISPs, > > > > Telcos) will not purchase it, because that's what the market > > > > do most of the time. And this is a "market" enforcement ... > > > > > > Is this true, there are a number of RFCs that tell about the bad > > > things NATs do, but NATs are not slowing down at all. > > > > > > http://www.ietf.org/rfc/rfc2993.txt?number=2993 > > > > > > http://www.ietf.org/rfc/rfc3027.txt?number=3027 > > > > > > http://www.ietf.org/rfc/rfc3424.txt?number=3424 > > > > > > > What about something like: > > > > > > > > IPv6 has enough addressing space that allows avoid the need > > > > of any kind of address translation, that is considered harmful according > > > > [RFCxxxx]. Consequently, IPv6 nodes MUST NOT support any kind > > > > of address translation. > > > > > > A purely procedural problem exists - the above drafts are > > > information, so I don't think they can be used as a justfication > > > for use of MUST NOT in this document. Someone correct me if I am > > > wrong. > > > > > > John > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 20 01:26:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6K8Qh06005699; Sun, 20 Jul 2003 01:26:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6K8Qgr4005698; Sun, 20 Jul 2003 01:26:42 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6K8Qd06005691 for ; Sun, 20 Jul 2003 01:26:39 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6K8OHUY005417 for ; Sun, 20 Jul 2003 01:24:17 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6K8OBfw004230 for ; Sun, 20 Jul 2003 02:24:11 -0600 (MDT) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h6K8OAn19772; Sun, 20 Jul 2003 01:24:10 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 20 Jul 2003 01:24:09 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipng@sunroof.eng.sun.com cc: "Wijnen, Bert (Bert)" Subject: Re: IPv6 w.g. Last Call on "Management Information Base for the Internet Protocol" In-Reply-To: <4.3.2.7.2.20030702160927.02a49658@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2 Jul 2003, Bob Hinden & Margaret Wasserman wrote: > This is a IPv6 working group last call for comments on advancing > the following document as a Proposed Standard: > > Title : Management Information Base for the > Internet Protocol (IP) > Author(s) : S. Routhier > Filename : draft-ietf-ipv6-rfc2011-update-03.txt > Pages : 114 > Date : 2003-7-2 > > Please send substantive comments to the ipng mailing list, and > minor editorial comments to the author. This last call period > will end on 16 July 2003. My apologies for missing the deadline, but I did not notice the following change in draft-ietf-ipv6-rfc2011-update-03.txt until today: Restored ipRoutingDiscards to a current object from the deprecated group per discussions with previous MIB authors. The argument to move it to deprecated relied on the fact that it really belongs with the routing group rather than the main IP group. However as it already exists in the IP group and any router must contain the IP group it is not reasonable to remove it and create a new object in the routing area simply to adjust where the object is rooted in the MIB tree. This object was placed in a new group "ipRoutingGroup" and the group was made mandatory in order to mimic the previous MIB. Although I will be the first to agree that it is not reasonable to deprecate an object and create a new one simply to adjust where the object is rooted in the MIB tree -- indeed, I think I advanced that argument myself in some of the earlier discussions -- there was a different argument for deprecating the object advanced by Bill Fenner based on more solid considerations of semantic ambiguity: >>>>> On Fri, 31 Jan 2003, Bill Fenner wrote: Bill> The IP-MIB revision (draft-ietf-ipv6-rfc2011-update-01.txt) Bill> deprecates ipRoutingDiscards and ipv6DiscardedRoutes in favor Bill> of inetCidrRouteDiscards. The thought was that you can't tell Bill> whether an ipRouteDiscards counts v4-only (as it would if a Bill> system implemented RFC2011+2465) or both, so it's better to Bill> define a new object with well defined semantics. If we Bill> decide that's not a good justification, we should remove Bill> inetCidrRouteDiscards and un-deprecate ipRouteDiscards in Bill> 2011-update. Note that the assumption made in current routing table MIB document draft-ietf-ipv6-rfc2096-update-04.txt is that ipRoutingDiscards will be deprecated, and so it retains the inetCidrRouteDiscards object, defined as follows: inetCidrRouteDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the inetCidrRouteTable which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries." ::= { ipForward 8 } and contains the following text in Section 6, "Changes from RFC 2096", explaining why: 3. Creates the inetCidrRouteDiscards object to replace the deprecated ipRoutingDiscards and ipv6DiscardedRoutes objects. Now, I could live with either decision -- either to deprecate ipRoutingDiscards, as in earlier versions of 2011-update, or to leave it undeprecated, as it is now -- but I think it's clear that whatever path is taken, 2096-update needs to be in sync. For the record, let me state that after reflection I've come to agree with the argument that having ipRoutingDiscards count anything other than discarded IPv4 routes causes semantic ambiguity. From this point of view the correct thing to do is to deprecate the object and add a qualification to its DESCRIPTION clause stating that it counts only discarded IPv4 routes. That way a system that implements 2011-update+2096-update and that supports the deprecated IPv4-only objects for backward compatibility will exhibit the same behaviour with respect to the IPv4-only objects as would either a 2011+2096 IPv4-only legacy system or a 2011+2096+2465 IPv4+IPv6 legacy system. The other alternative -- to remove inetCidrRouteDiscards and related text from the next version of 2096-update -- would also work, but it would cause ipRoutingDiscards to mean something different w.r.t the ipCidrRouteTable in a system that implements 2011-update+2096-update plus the deprecated IPv4-only objects than it does in a 2011+2096 IPv4-only legacy system. That does not seem to be quite as satisfactory. The second thing that caught my eye was this: In response to a question about the size constraint on the various InetAddress objects (0..36). I have decided to leave this as is for now. The actually size will be one of 4, 8, 16 or 20 depending on the type in use and the syntax could be reduced to cover those sizes. However using such a small limit might require a new mib if a new address type is added to the InetAddress MIB that uses a larger size. 36 seems to be a reasonable compromise for allowing possible growth but avoiding problems with index length limitations. An alternative that is worth considering would be not to use any SIZE clause at all but instead document the constraints that must be obeyed in the applicable row object DESCRIPTION clauses (see section 4.6.5 of ). According to smilint, there are four row objects that could have an index overflows if the SIZE constraints were lifted from the InetAddress objects by changing the SYNTAX values from InetAddress (SIZE(0..36)) to InetAddress The resulting warnings are: ./IP-MIB:2081: [5] {index-exceeds-too-large} index of row `ipAddressPrefixEntry' can exceed OID size limit by 141 subidentifier(s) ./IP-MIB:2234: [5] {index-exceeds-too-large} index of row `ipAddressEntry' can exceed OID size limit by 139 subidentifier(s) ./IP-MIB:2372: [5] {index-exceeds-too-large} index of row `inetNetToMediaEntry' can exceed OID size limit by 140 subidentifier(s) ./IP-MIB:2677: [5] {index-exceeds-too-large} index of row `ipDefaultRouterEntry' can exceed OID size limit by 139 subidentifier(s) The constraint for ipAddressPrefixEntry could be documented like this: ipAddressPrefixEntry OBJECT-TYPE SYNTAX IpAddressPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Inet prefix entry. Implementors need to be aware that if the size of of ipAddressPrefixPrefix exceeds 114 octets then OIDs of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { ipAddressPrefixIfIndex, ipAddressPrefixType, ipAddressPrefixPrefix, ipAddressPrefixLength } ::= { ipAddressPrefixTable 1 } and similarly for the other row objects. It's worth noting that that drops the requirement for index objects of type InetAddress to have a SIZE clause and allows the constraints to be documented like this in a DESCRIPTION clause. One final comment: many of the ASN.1 comments in the MIB module start with "- --" in the left-hand margin. The MIB module will not compile until these are all changed to start with "--". Regards, Mike Heard -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 20 05:15:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6KCFe06005951; Sun, 20 Jul 2003 05:15:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6KCFdrU005950; Sun, 20 Jul 2003 05:15:39 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6KCFa06005943 for ; Sun, 20 Jul 2003 05:15:36 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6KCDDUY026381 for ; Sun, 20 Jul 2003 05:13:13 -0700 (PDT) Received: from mailout3.samsung.com ([203.254.224.33]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6KCD2E6010126 for ; Sun, 20 Jul 2003 06:13:07 -0600 (MDT) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HIB00201OLORI@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Sun, 20 Jul 2003 21:13:00 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HIB001H8OLOEG@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Sun, 20 Jul 2003 21:13:00 +0900 (KST) Received: from sisojk1gxw7d0k ([107.108.4.39]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HIB0021POLMRQ@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Sun, 20 Jul 2003 21:13:00 +0900 (KST) Date: Sun, 20 Jul 2003 17:40:54 +0530 From: Sreedhar Y Subject: testing IPv6 stack To: ipng@sunroof.eng.sun.com Message-id: <005d01c34eb7$f8fc93b0$27046c6b@sisojk1gxw7d0k> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am newcommer to this group. I am using TAHI test tool for testing IPv6 stack. Can any body help me in defineing and sending our own packets using TAHI test tool. And also how and where in TAHI test tool *.def files are parsed. Thanks in advance. Y. Sreedhar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 21 14:18:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6LLIJ06018345; Mon, 21 Jul 2003 14:18:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6LLIJQo018344; Mon, 21 Jul 2003 14:18:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6LLIF06018337 for ; Mon, 21 Jul 2003 14:18:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6LLFrUu004426 for ; Mon, 21 Jul 2003 14:15:53 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6LLFmUg011759 for ; Mon, 21 Jul 2003 14:15:48 -0700 (PDT) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se. [208.237.135.117]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h6LLFlVf025107 for ; Mon, 21 Jul 2003 16:15:48 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id PKK5KRVV; Mon, 21 Jul 2003 16:15:46 -0500 Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h6LLFlGx024345 for ; Mon, 21 Jul 2003 17:15:47 -0400 (EDT) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 21 Jul 2003 17:15:47 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B095@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/LMC)" To: "'ipng@sunroof.eng.sun.com'" Subject: RFC 3513 EUI-48/MAC-48 confusion Date: Mon, 21 Jul 2003 17:15:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Folks, Maybe this has been raised before, but I have not found any answers. Appendix A of RFC 3513 has the following text <<<< FROM RFC3513 Links or Nodes with IEEE 802 48 bit MAC's [EUI64] defines a method to create a IEEE EUI-64 identifier from an IEEE 48bit MAC identifier. This is to insert two octets, with hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the company_id and vendor supplied id). For example, the 48 bit IEEE MAC with global scope <<<< FROM RFC3513 The referred document [EUI64] talks about a different method of creating EU-I64s from MAC-48s. The procedure followed in the RFC seems to be the one recommended for EUI-48s. Is this the intended behaviour? Thanks Suresh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 21 17:27:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M0R206019170; Mon, 21 Jul 2003 17:27:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6M0R2Ik019169; Mon, 21 Jul 2003 17:27:02 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M0Qx06019162 for ; Mon, 21 Jul 2003 17:26:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6M0OaUu021064 for ; Mon, 21 Jul 2003 17:24:36 -0700 (PDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6M0OToF013321 for ; Mon, 21 Jul 2003 17:24:31 -0700 (PDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KYK0UZKG7S9C6IW1@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Tue, 22 Jul 2003 10:21:41 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CDBB412C00E; Tue, 22 Jul 2003 10:21:33 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id B4E1612C011; Tue, 22 Jul 2003 10:21:33 +1000 (EST) Date: Tue, 22 Jul 2003 10:21:33 +1000 From: Greg Daley Subject: Re: [Call for Feedback] Applicability Statement for IPv6 DAD To: Soohong Daniel Park Cc: ipng@sunroof.eng.sun.com, Hinden , "'Marc Blanchet'" Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F1C838D.2090404@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <001801c3476c$775539e0$b7cbdba8@daniel7209> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Daniel, It looks like there are three largely unrelated sections in the draft (or only related in that DAD is involved). Firstly, there are the issues of MAC address duplication and source address filtering for DAD packets. Secondly there are descriptions of existing DAD optimizations. Thirdly, there are references to some protocols which use NS (DAD) packets to do some additional configuration. At this stage, (I know it is a -00 draft), my guess is that the description of the issues with MAC duplication and filtering aren't of great interest to many in IPv6 standardization. (Since for those intimate with Neighbor Discovery, the statements are {believed to be} reasonably well understood). Even though I say that, it is likely that people who run the networks (as opposed to standardizing them) may gain something from explicitly stating these issues in a document. If this is the case, though, I wouldn't put that work into a document with any other data (not even the optimization work). The survey and comparison of the existing DAD schemes is good to have, but maybe not in IPv6 at this time. The DNA BoF showed interest at the meeting on Friday to look into DAD optimization schemes. Maybe this is where that section should be targeted at this stage (maybe as a separate document). I'm not sure what to do about the third section (DNA configuration using DAD). Greg Soohong Daniel Park wrote: > Dear folks > > Once I discussed a DAD related issue "IPv6 DAD Consideration for 802.11" > in IPv6 mailing list, I received some feedback and request to make a > document > like above subject. > > Recently, some drafts are trying to contribute optimized and expanded > IPv6 DAD > for various environments but we can not find out any references. > So I have written very rough document right now, and I would like to > listen more feedback from many experts in IPv6 WG. > > http://home.megapass.co.kr/~natpp00/ApplicabilityStatementforIPv6DAD.txt > > I think this would be useful contribution to IPv6 wg as working item. > > > Please let me know your view on this with your feedback and comment. > > > > Daniel (Soohong Daniel Park) > Mobile Platform Lab,SAMSUNG Electronics > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 21 19:33:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M2XO06019982; Mon, 21 Jul 2003 19:33:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6M2XOOh019980; Mon, 21 Jul 2003 19:33:24 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M2XK06019967 for ; Mon, 21 Jul 2003 19:33:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6M2UvUu028109 for ; Mon, 21 Jul 2003 19:30:58 -0700 (PDT) Received: from mordani.com (mordani.com [66.92.28.204]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6M2UqoF009178 for ; Mon, 21 Jul 2003 19:30:52 -0700 (PDT) Received: from moon (chirayu.chirayu.org [202.142.102.54]) by mordani.com (8.12.8/8.12.8) with ESMTP id h6M2OJj9012000; Mon, 21 Jul 2003 19:24:21 -0700 From: "Chirayu Patel" To: "'Suresh Krishnan \(QB/LMC\)'" Cc: Subject: RE: RFC 3513 EUI-48/MAC-48 confusion Date: Tue, 22 Jul 2003 08:01:49 +0530 Message-ID: <004701c34ff9$6a76afc0$010aa8c0@chirayu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830837B095@eammlex037.lmc.ericsson.se> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6M2XK06019968 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Can you quote the text from (http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) which you think is contradicting Appendix A of RFC3513. As per my understanding, the two match. Section "Encapsulated MAC-48 values" in the tutorial says the same thing as Appendix A, which is to place the bytes 0xff, and 0xfe between the OUI id (company id of 3 bytes), and extension identifier (vendor supplied id of 3 byes) Regards CP > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > ipng@sunroof.eng.sun.com] On Behalf Of Suresh Krishnan (QB/LMC) > Sent: Tuesday, July 22, 2003 2:46 AM > To: 'ipng@sunroof.eng.sun.com' > Subject: RFC 3513 EUI-48/MAC-48 confusion > > Hi Folks, > Maybe this has been raised before, but I have not found any answers. > Appendix A of RFC 3513 has the following text > > <<<< FROM RFC3513 > Links or Nodes with IEEE 802 48 bit MAC's > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > IEEE 48bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > (between the company_id and vendor supplied id). For example, the 48 > bit IEEE MAC with global scope > <<<< FROM RFC3513 > > The referred document [EUI64] talks about a different method of creating > EU-I64s from MAC-48s. The procedure followed in the RFC seems to be the > one recommended for EUI-48s. Is this the intended behaviour? > > Thanks > Suresh > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 21 19:37:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M2bT06020042; Mon, 21 Jul 2003 19:37:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6M2bT5G020040; Mon, 21 Jul 2003 19:37:29 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M2bQ06020031 for ; Mon, 21 Jul 2003 19:37:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6M2Z4UY029750 for ; Mon, 21 Jul 2003 19:35:04 -0700 (PDT) Received: from mordani.com (mordani.com [66.92.28.204]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6M2YwUg004099 for ; Mon, 21 Jul 2003 19:34:58 -0700 (PDT) Received: from moon (chirayu.chirayu.org [202.142.102.54]) by mordani.com (8.12.8/8.12.8) with ESMTP id h6M2SRj9012011; Mon, 21 Jul 2003 19:28:29 -0700 From: "Chirayu Patel" To: "'Suresh Krishnan \(QB/LMC\)'" Cc: Subject: RE: RFC 3513 EUI-48/MAC-48 confusion Date: Tue, 22 Jul 2003 08:05:56 +0530 Message-ID: <004801c34ff9$fe0a8860$010aa8c0@chirayu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830837B095@eammlex037.lmc.ericsson.se> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6M2bQ06020032 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Can you quote the text from (http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) which you think is contradicting Appendix A of RFC3513. As per my understanding, the two match. Section "Encapsulated MAC-48 values" in the tutorial says the same thing as Appendix A, which is to place the bytes 0xff, and 0xfe between the OUI id (company id of 3 bytes), and extension identifier (vendor supplied id of 3 byes). The same procedure applies to EUI-48 ids. Regards CP > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > ipng@sunroof.eng.sun.com] On Behalf Of Suresh Krishnan (QB/LMC) > Sent: Tuesday, July 22, 2003 2:46 AM > To: 'ipng@sunroof.eng.sun.com' > Subject: RFC 3513 EUI-48/MAC-48 confusion > > Hi Folks, > Maybe this has been raised before, but I have not found any answers. > Appendix A of RFC 3513 has the following text > > <<<< FROM RFC3513 > Links or Nodes with IEEE 802 48 bit MAC's > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > IEEE 48bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > (between the company_id and vendor supplied id). For example, the 48 > bit IEEE MAC with global scope > <<<< FROM RFC3513 > > The referred document [EUI64] talks about a different method of creating > EU-I64s from MAC-48s. The procedure followed in the RFC seems to be the > one recommended for EUI-48s. Is this the intended behaviour? > > Thanks > Suresh > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 21 19:59:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M2x406020522; Mon, 21 Jul 2003 19:59:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6M2x4lU020521; Mon, 21 Jul 2003 19:59:04 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M2x106020514 for ; Mon, 21 Jul 2003 19:59:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6M2udUu004087 for ; Mon, 21 Jul 2003 19:56:39 -0700 (PDT) Received: from mordani.com (mordani.com [66.92.28.204]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6M2uXoF019965 for ; Mon, 21 Jul 2003 19:56:33 -0700 (PDT) Received: from moon (chirayu.chirayu.org [202.142.102.54]) by mordani.com (8.12.8/8.12.8) with ESMTP id h6M2o1j9012070; Mon, 21 Jul 2003 19:50:03 -0700 From: "Chirayu Patel" To: "'Suresh Krishnan \(QB/LMC\)'" Cc: Subject: RE: RFC 3513 EUI-48/MAC-48 confusion Date: Tue, 22 Jul 2003 08:27:31 +0530 Message-ID: <004901c34ffd$01ca6f30$010aa8c0@chirayu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <004801c34ff9$fe0a8860$010aa8c0@chirayu.org> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6M2x106020515 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Digging some more, I realized that there is indeed an inconsistency in the tutorial. The text says - "A unique EUI-64 value is generated by concatenating the OUI, an FFFE valued label, and the extension identifier values. The (MAC-48 like) transmission-ordered binary representation for this encapsulated MAC-48 identifier is listed below:". The examples show FFFF. I think the general protocol is that we should go with the text. I tried looking in the archives but could not find any emails clarifying this inconsistency..... Regards CP > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > ipng@sunroof.eng.sun.com] On Behalf Of Chirayu Patel > Sent: Tuesday, July 22, 2003 8:06 AM > To: 'Suresh Krishnan (QB/LMC)' > Cc: ipng@sunroof.eng.sun.com > Subject: RE: RFC 3513 EUI-48/MAC-48 confusion > > Hi, > > Can you quote the text from > (http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) which you > think > is contradicting Appendix A of RFC3513. > > As per my understanding, the two match. Section "Encapsulated MAC-48 > values" > in the tutorial says the same thing as Appendix A, which is to place the > bytes 0xff, and 0xfe between the OUI id (company id of 3 bytes), and > extension identifier (vendor supplied id of 3 byes). The same procedure > applies to EUI-48 ids. > > Regards > CP > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > > ipng@sunroof.eng.sun.com] On Behalf Of Suresh Krishnan (QB/LMC) > > Sent: Tuesday, July 22, 2003 2:46 AM > > To: 'ipng@sunroof.eng.sun.com' > > Subject: RFC 3513 EUI-48/MAC-48 confusion > > > > Hi Folks, > > Maybe this has been raised before, but I have not found any answers. > > Appendix A of RFC 3513 has the following text > > > > <<<< FROM RFC3513 > > Links or Nodes with IEEE 802 48 bit MAC's > > > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > > IEEE 48bit MAC identifier. This is to insert two octets, with > > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > > (between the company_id and vendor supplied id). For example, the 48 > > bit IEEE MAC with global scope > > <<<< FROM RFC3513 > > > > The referred document [EUI64] talks about a different method of creating > > EU-I64s from MAC-48s. The procedure followed in the RFC seems to be the > > one recommended for EUI-48s. Is this the intended behaviour? > > > > Thanks > > Suresh > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 00:10:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M7AS06021324; Tue, 22 Jul 2003 00:10:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6M7ARuD021323; Tue, 22 Jul 2003 00:10:27 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6M7AO06021315 for ; Tue, 22 Jul 2003 00:10:24 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6M77xUY000286 for ; Tue, 22 Jul 2003 00:07:59 -0700 (PDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6M77rEE013510 for ; Tue, 22 Jul 2003 01:07:54 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KYKETFHZHS9C6J6D@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Tue, 22 Jul 2003 17:01:11 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B8DA220008; Tue, 22 Jul 2003 17:01:10 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 90CCF20006; Tue, 22 Jul 2003 17:01:10 +1000 (EST) Date: Tue, 22 Jul 2003 17:01:10 +1000 From: Greg Daley Subject: Re: RFC 3513 EUI-48/MAC-48 confusion To: "Suresh Krishnan (QB/LMC)" Cc: "'ipng@sunroof.eng.sun.com'" Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F1CE136.3020907@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <7B2A7784F4B7F0409947481F3F3FEF830837B095@eammlex037.lmc.ericsson.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Suresh, I think that you are correct that the document which is referred to indicates the addition of FFFF for MAC-48 and FFFE for EUI-48. Maybe this is because the terminology has been confused previously. In this instance, though we're definitely discussing MAC-48's though (as indicated by the section title). Suresh Krishnan (QB/LMC) wrote: > Hi Folks, > Maybe this has been raised before, but I have not found any answers. > Appendix A of RFC 3513 has the following text > > <<<< FROM RFC3513 > Links or Nodes with IEEE 802 48 bit MAC's > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > IEEE 48bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > (between the company_id and vendor supplied id). For example, the 48 > bit IEEE MAC with global scope > <<<< FROM RFC3513 > > The referred document [EUI64] talks about a different method of creating > EU-I64s from MAC-48s. > The procedure followed in the RFC seems to be the one recommended for > EUI-48s. Is this the intended behaviour? I think that the disinction between EUI-48 and MAC-48 in IETF standards documentation has been mistakenly blurred. In this case, EUI-48 and MAC-48 should be considered distinct numeric spaces, but aren't. The pre-existence of this text in RFC2460 means that existing implementations of IPv6 will utilize this incorrect mechanism. So we may have increased the chance that EUI-64 IPv6 addresses will have collisions (up to doubled! :) because of the mapping of these spaces onto the same part of the EUI-64 space in RFC2460 and RFC3513. I'm not sure if we can really fix this issue, but we may be able to change the text in the document so that it is correct (refers to EUI-48 only rather than MAC, or maybe says MAC-48 with FFFF). Is it worth doing for correctness? Greg. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 08:11:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MFBK06023570; Tue, 22 Jul 2003 08:11:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6MFBKTh023569; Tue, 22 Jul 2003 08:11:20 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MFBF06023562 for ; Tue, 22 Jul 2003 08:11:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MF8qUY019968 for ; Tue, 22 Jul 2003 08:08:52 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6MF8kxk010022 for ; Tue, 22 Jul 2003 08:08:47 -0700 (PDT) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se. [208.237.135.117]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h6MF8jVf008363; Tue, 22 Jul 2003 10:08:45 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id PMD0R5QJ; Tue, 22 Jul 2003 10:08:43 -0500 Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h6MF8iGx016364; Tue, 22 Jul 2003 11:08:44 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id <337NSDA7>; Tue, 22 Jul 2003 11:09:50 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B097@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/LMC)" To: "'Chirayu Patel'" Cc: ipng@sunroof.eng.sun.com Subject: RE: RFC 3513 EUI-48/MAC-48 confusion Date: Tue, 22 Jul 2003 11:08:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Chirayu, There is no inconsistency in the tutorial. It mandates use of FFFE for EUI-48 identifiers (not MAC-48). The 802 addresses are MAC-48s. The inconsistency is in the RFC as it uses the EUI-48 method on MAC-48s. Regards Suresh -----Original Message----- From: Chirayu Patel [mailto:chirayu@chirayu.org] Sent: Monday, July 21, 2003 10:58 PM To: Suresh Krishnan (QB/LMC) Cc: ipng@sunroof.eng.sun.com Subject: RE: RFC 3513 EUI-48/MAC-48 confusion Digging some more, I realized that there is indeed an inconsistency in the tutorial. The text says - "A unique EUI-64 value is generated by concatenating the OUI, an FFFE valued label, and the extension identifier values. The (MAC-48 like) transmission-ordered binary representation for this encapsulated MAC-48 identifier is listed below:". The examples show FFFF. I think the general protocol is that we should go with the text. I tried looking in the archives but could not find any emails clarifying this inconsistency..... Regards CP > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > ipng@sunroof.eng.sun.com] On Behalf Of Chirayu Patel > Sent: Tuesday, July 22, 2003 8:06 AM > To: 'Suresh Krishnan (QB/LMC)' > Cc: ipng@sunroof.eng.sun.com > Subject: RE: RFC 3513 EUI-48/MAC-48 confusion > > Hi, > > Can you quote the text from > (http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) which you > think > is contradicting Appendix A of RFC3513. > > As per my understanding, the two match. Section "Encapsulated MAC-48 > values" > in the tutorial says the same thing as Appendix A, which is to place the > bytes 0xff, and 0xfe between the OUI id (company id of 3 bytes), and > extension identifier (vendor supplied id of 3 byes). The same procedure > applies to EUI-48 ids. > > Regards > CP > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > > ipng@sunroof.eng.sun.com] On Behalf Of Suresh Krishnan (QB/LMC) > > Sent: Tuesday, July 22, 2003 2:46 AM > > To: 'ipng@sunroof.eng.sun.com' > > Subject: RFC 3513 EUI-48/MAC-48 confusion > > > > Hi Folks, > > Maybe this has been raised before, but I have not found any answers. > > Appendix A of RFC 3513 has the following text > > > > <<<< FROM RFC3513 > > Links or Nodes with IEEE 802 48 bit MAC's > > > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > > IEEE 48bit MAC identifier. This is to insert two octets, with > > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > > (between the company_id and vendor supplied id). For example, the 48 > > bit IEEE MAC with global scope > > <<<< FROM RFC3513 > > > > The referred document [EUI64] talks about a different method of creating > > EU-I64s from MAC-48s. The procedure followed in the RFC seems to be the > > one recommended for EUI-48s. Is this the intended behaviour? > > > > Thanks > > Suresh > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 08:11:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MFBA06023560; Tue, 22 Jul 2003 08:11:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6MFB9nm023559; Tue, 22 Jul 2003 08:11:09 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MFB606023552 for ; Tue, 22 Jul 2003 08:11:06 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MF8hUY019932 for ; Tue, 22 Jul 2003 08:08:43 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6MF8bEJ004269 for ; Tue, 22 Jul 2003 09:08:38 -0600 (MDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se. [208.237.135.118]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h6MF8XVf008323; Tue, 22 Jul 2003 10:08:33 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id PMD8FLC4; Tue, 22 Jul 2003 10:08:06 -0500 Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h6MF8WGx016355; Tue, 22 Jul 2003 11:08:32 -0400 (EDT) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 22 Jul 2003 11:08:32 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B096@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/LMC)" To: "'greg.daley@eng.monash.edu.au'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: RFC 3513 EUI-48/MAC-48 confusion Date: Tue, 22 Jul 2003 11:08:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Greg, You are right. This seems to be carried over from RFC 2460. For people who have been involved with IPv6 since then this might be natural. As a new implementor this was confusing to me. Because nobody else complained probably there is no need to correct it? It is upto the WG to decide. Regards Suresh -----Original Message----- From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] Sent: Tuesday, July 22, 2003 3:01 AM To: Suresh Krishnan (QB/LMC) Cc: 'ipng@sunroof.eng.sun.com' Subject: Re: RFC 3513 EUI-48/MAC-48 confusion Hi Suresh, I think that you are correct that the document which is referred to indicates the addition of FFFF for MAC-48 and FFFE for EUI-48. Maybe this is because the terminology has been confused previously. In this instance, though we're definitely discussing MAC-48's though (as indicated by the section title). Suresh Krishnan (QB/LMC) wrote: > Hi Folks, > Maybe this has been raised before, but I have not found any answers. > Appendix A of RFC 3513 has the following text > > <<<< FROM RFC3513 > Links or Nodes with IEEE 802 48 bit MAC's > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > IEEE 48bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > (between the company_id and vendor supplied id). For example, the 48 > bit IEEE MAC with global scope > <<<< FROM RFC3513 > > The referred document [EUI64] talks about a different method of creating > EU-I64s from MAC-48s. > The procedure followed in the RFC seems to be the one recommended for > EUI-48s. Is this the intended behaviour? I think that the disinction between EUI-48 and MAC-48 in IETF standards documentation has been mistakenly blurred. In this case, EUI-48 and MAC-48 should be considered distinct numeric spaces, but aren't. The pre-existence of this text in RFC2460 means that existing implementations of IPv6 will utilize this incorrect mechanism. So we may have increased the chance that EUI-64 IPv6 addresses will have collisions (up to doubled! :) because of the mapping of these spaces onto the same part of the EUI-64 space in RFC2460 and RFC3513. I'm not sure if we can really fix this issue, but we may be able to change the text in the document so that it is correct (refers to EUI-48 only rather than MAC, or maybe says MAC-48 with FFFF). Is it worth doing for correctness? Greg. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 09:06:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MG6p06024333; Tue, 22 Jul 2003 09:06:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6MG6otH024332; Tue, 22 Jul 2003 09:06:50 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MG6j06024319 for ; Tue, 22 Jul 2003 09:06:45 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MG4MUu008833 for ; Tue, 22 Jul 2003 09:04:22 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6MG4CSw000958 for ; Tue, 22 Jul 2003 10:04:16 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6MG48l03182; Tue, 22 Jul 2003 18:04:08 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6MG23of072361; Tue, 22 Jul 2003 18:02:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307221602.h6MG23of072361@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Suresh Krishnan (QB/LMC)" cc: "'greg.daley@eng.monash.edu.au'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: RFC 3513 EUI-48/MAC-48 confusion In-reply-to: Your message of Tue, 22 Jul 2003 11:08:24 EDT. <7B2A7784F4B7F0409947481F3F3FEF830837B096@eammlex037.lmc.ericsson.se> Date: Tue, 22 Jul 2003 18:02:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: You are right. This seems to be carried over from RFC 2460. For people who have been involved with IPv6 since then this might be natural. As a new implementor this was confusing to me. Because nobody else complained probably there is no need to correct it? It is upto the WG to decide. => this is an old issue. IMHO the best solution is to consider the MAC-48 -> EUI-48 -> EUI-64 transform in place of the direct MAC-48 -> EUI-64 transform. BTW the EUI-64 stuff is a big joke: *no* IEEE layer 2 uses EUI-64s as addresses today (IEEE 1394 aka I-Link aka FireWire uses 6 bit node addresses). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 09:11:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MGBM06024399; Tue, 22 Jul 2003 09:11:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6MGBL5T024398; Tue, 22 Jul 2003 09:11:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MGBI06024390 for ; Tue, 22 Jul 2003 09:11:18 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MG8sUY008779 for ; Tue, 22 Jul 2003 09:08:55 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6MG8nFt008238 for ; Tue, 22 Jul 2003 10:08:49 -0600 (MDT) Date: Tue, 22 Jul 2003 09:10:22 -0700 Subject: Re: a concern on bridge-like nd-proxies From: Alper Yegin To: Keith Moore , Brian E Carpenter CC: Message-ID: In-Reply-To: <20030716103912.6627b730.moore@cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 7/16/03 7:39 AM, "Keith Moore" wrote: > ] I'd go a bit further. I messed around with a large bridged > ] network for some years, and this included messing with ARP > ] proxies and all the troubles they cause. Basically, making > ] a level 2 device simulate level 3 functions is a kludge, and it > ] gets even worse when attempting to "bridge" different LAN > ] technologies. > > Lately I find myself wondering if there's not room for a uniform layer 2.5 > interface that is designed to work over a set of bridged 802-style layer 2 > networks, but presents a slightly different interface to the host. So for > instance hosts would be explicitly required to announce presence on a link (no > more passive waiting for ARP requests), there would be an explicit L2.5 > multicast join/leave (no more sniffing for L3 multicast requests), > and there > would be a uniform way for a host to authenticate to the link (no more PPPoE), We are working on a standard L3 solution for that part: http://www.ietf.org/html.charters/pana-charter.html FYI.. Alper > with hubs having a way to know whether a particular host/port/address was > authenticated and the ability to switch that host's traffic differently > depending on that bit. The same authentication interface could be used as a > gateway to control access to a larger network. > > The point is to explicitly design such an interface rather than resorting to > more and more tricks. > > (has this already been worked on and I just don't know about it?) > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 09:15:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MGFu06024581; Tue, 22 Jul 2003 09:15:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6MGFuiu024580; Tue, 22 Jul 2003 09:15:56 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MGFo06024563 for ; Tue, 22 Jul 2003 09:15:50 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MGDLUY010580 for ; Tue, 22 Jul 2003 09:13:21 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6MGDFEE007303 for ; Tue, 22 Jul 2003 10:13:16 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6MGD9J18359; Tue, 22 Jul 2003 12:13:10 -0400 (EDT) Date: Tue, 22 Jul 2003 12:13:08 -0400 From: Keith Moore To: Alper Yegin Cc: moore@cs.utk.edu, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: a concern on bridge-like nd-proxies Message-Id: <20030722121308.3f07636f.moore@cs.utk.edu> In-Reply-To: References: <20030716103912.6627b730.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > and there > > would be a uniform way for a host to authenticate to the link (no > > more PPPoE), > > We are working on a standard L3 solution for that part: > http://www.ietf.org/html.charters/pana-charter.html > > FYI.. thanks for the information. but I really hate to see this all done piecemeal. it really needs to be a l2 solution, and it needs to be comprehensive. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 09:27:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MGRU06025099; Tue, 22 Jul 2003 09:27:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6MGRUhe025098; Tue, 22 Jul 2003 09:27:30 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MGRQ06025091 for ; Tue, 22 Jul 2003 09:27:27 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MGP3Uu016667 for ; Tue, 22 Jul 2003 09:25:03 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6MGOwEJ023534 for ; Tue, 22 Jul 2003 10:24:58 -0600 (MDT) Date: Tue, 22 Jul 2003 09:26:31 -0700 Subject: Re: a concern on bridge-like nd-proxies From: Alper Yegin To: Keith Moore CC: , Message-ID: In-Reply-To: <20030722121308.3f07636f.moore@cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, >>> and there >>> would be a uniform way for a host to authenticate to the link (no >>> more PPPoE), >> >> We are working on a standard L3 solution for that part: >> http://www.ietf.org/html.charters/pana-charter.html >> >> FYI.. > > thanks for the information. but I really hate to see this all done > piecemeal. it really needs to be a l2 solution, and it needs to > be comprehensive. Do you mean a L2 solution that works on all types of link-layers? Alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 09:39:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MGdC06025382; Tue, 22 Jul 2003 09:39:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6MGdCUD025381; Tue, 22 Jul 2003 09:39:12 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MGd806025374 for ; Tue, 22 Jul 2003 09:39:08 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MGajUu021618 for ; Tue, 22 Jul 2003 09:36:45 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6MGadEJ001501 for ; Tue, 22 Jul 2003 10:36:39 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6MGaYJ18401; Tue, 22 Jul 2003 12:36:35 -0400 (EDT) Date: Tue, 22 Jul 2003 12:36:34 -0400 From: Keith Moore To: Alper Yegin Cc: moore@cs.utk.edu Subject: Re: a concern on bridge-like nd-proxies Message-Id: <20030722123634.48df112e.moore@cs.utk.edu> In-Reply-To: References: <20030722121308.3f07636f.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > thanks for the information. but I really hate to see this all done > > piecemeal. it really needs to be a l2 solution, and it needs to > > be comprehensive. > > Do you mean a L2 solution that works on all types of link-layers? [off-topic for ipng - further discussion in private mail if you wish.] I'd be happy with one that worked on 802.*-like link layers, or to be more precise, link layers that have addressing, > 2 points of access, and multicast. PPP could still be used for point-to-point links. Some of the details might need to vary from one L2 to another, but they should all share a common framework, multicast group space, and credentials space, so that bridging them makes sense. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 10:32:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MHWQ06025770; Tue, 22 Jul 2003 10:32:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6MHWQAX025769; Tue, 22 Jul 2003 10:32:26 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6MHWM06025762 for ; Tue, 22 Jul 2003 10:32:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MHTxUY012849 for ; Tue, 22 Jul 2003 10:29:59 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6MHTsDZ001290 for ; Tue, 22 Jul 2003 10:29:54 -0700 (PDT) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se. [208.237.135.117]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h6MHTlVf009212; Tue, 22 Jul 2003 12:29:47 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id PMD0SGQJ; Tue, 22 Jul 2003 12:29:45 -0500 Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h6MHTkGx021547; Tue, 22 Jul 2003 13:29:47 -0400 (EDT) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 22 Jul 2003 13:29:46 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B098@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/LMC)" To: "'Francis Dupont'" Cc: "'greg.daley@eng.monash.edu.au'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: RFC 3513 EUI-48/MAC-48 confusion Date: Tue, 22 Jul 2003 13:29:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, Agree with you almost completely except for this > BTW the EUI-64 stuff is a big joke: > *no* IEEE layer 2 uses EUI-64s as addresses today (IEEE 1394 aka > I-Link aka FireWire uses 6 bit node addresses). I assume you meant EUI-48s. CDPD uses EUI-48s for layer 2 addresses. Don't know how relevant CDPD is anymore though. Regards Suresh -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] Sent: Tuesday, July 22, 2003 12:02 PM To: Suresh Krishnan (QB/LMC) Cc: 'greg.daley@eng.monash.edu.au'; 'ipng@sunroof.eng.sun.com' Subject: Re: RFC 3513 EUI-48/MAC-48 confusion In your previous mail you wrote: You are right. This seems to be carried over from RFC 2460. For people who have been involved with IPv6 since then this might be natural. As a new implementor this was confusing to me. Because nobody else complained probably there is no need to correct it? It is upto the WG to decide. => this is an old issue. IMHO the best solution is to consider the MAC-48 -> EUI-48 -> EUI-64 transform in place of the direct MAC-48 -> EUI-64 transform. BTW the EUI-64 stuff is a big joke: *no* IEEE layer 2 uses EUI-64s as addresses today (IEEE 1394 aka I-Link aka FireWire uses 6 bit node addresses). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 17:14:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6N0ET06027231; Tue, 22 Jul 2003 17:14:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6N0ETEV027230; Tue, 22 Jul 2003 17:14:29 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6N0EQ06027223 for ; Tue, 22 Jul 2003 17:14:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6N0C2UY021702 for ; Tue, 22 Jul 2003 17:12:03 -0700 (PDT) Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6N0BvDZ012247 for ; Tue, 22 Jul 2003 17:11:57 -0700 (PDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KYLEJY1MTG9BDCOS@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 23 Jul 2003 10:04:19 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 741E512C008; Wed, 23 Jul 2003 10:04:19 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 57EA112C005; Wed, 23 Jul 2003 10:04:19 +1000 (EST) Date: Wed, 23 Jul 2003 10:04:19 +1000 From: Greg Daley Subject: Re: RFC 3513 EUI-48/MAC-48 confusion To: Francis Dupont Cc: "Suresh Krishnan (QB/LMC)" , "'ipng@sunroof.eng.sun.com'" Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F1DD103.2050409@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <200307221602.h6MG23of072361@givry.rennes.enst-bretagne.fr> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, Francis Dupont wrote: > In your previous mail you wrote: > > You are right. This seems to be carried over from RFC > 2460. For people who have been involved with IPv6 since then this > might be natural. As a new implementor this was confusing to > me. Because nobody else complained probably there is no need to > correct it? It is upto the WG to decide. > > => this is an old issue. IMHO the best solution is to consider > the MAC-48 -> EUI-48 -> EUI-64 transform in place of the direct > MAC-48 -> EUI-64 transform. BTW the EUI-64 stuff is a big joke: > *no* IEEE layer 2 uses EUI-64s as addresses today (IEEE 1394 aka > I-Link aka FireWire uses 6 bit node addresses). It's an old issue maybe, but has caused confusion here, and may do so in the future. This is because the IETF's proposed standard is incorrect. If the proposal you mentioned is useful, then why don't we formalize it in text, or (more to the point) abandon the example in the document and refer to the IEEE's authoritative description of EUI64? I'm not worried about the chance of address collisions because of existing implementations really. It makes sense to update the text when the document is revisited for the site-local clean-out. Greg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 18:38:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6N1ck06027655; Tue, 22 Jul 2003 18:38:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6N1ckIc027654; Tue, 22 Jul 2003 18:38:46 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6N1ch06027647 for ; Tue, 22 Jul 2003 18:38:43 -0700 (PDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6N1aHfM001430; Tue, 22 Jul 2003 21:36:17 -0400 (EDT) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h6N1aHH2005294; Tue, 22 Jul 2003 21:36:17 -0400 (EDT) Message-Id: <200307230136.h6N1aHH2005294@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: samita.chakrabarti@Sun.COM, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM From: Sebastien Roy cc: ipng@sunroof.eng.sun.com Subject: comments on address selection API Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jul 2003 21:36:16 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have some comments on draft-chakrabarti-ipv6-addrselect-api-01.txt. 1. I'm puzzled by the following IPV6_SRC_PREFERENCES settings: IPV6_PREFER_SRC_TUNNEL /* Prefer tunnel interface as source */ IPV6_PREFER_SRC_NATIVE /* Prefer native IPv6 source addr */ IPV6_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope source */ IPV6_PREFER_SRC_LOWERSCOPE /* Prefer less than largest scope */ What do they mean? It would be nice if there was a description of what source address selection rules they affect and how. One point of confusion is that there are no source address selection rules that have to do with tunnel vs. native addresses, so I can't really guess what was intended here. The second pair, largest vs. lower, are confusing. There is a "Prefer appropriate scope" source address selection rule, but neither of these constants represents the "default" behavior for that rule. What was intended here? I'm guessing that this was an error and that these four settings shouldn't exist... 2. Some of the AI_ flags have strange names. Here's what I mean: AI_PREFER_SRC_LARGESTSCOPE I'm guessing you meant AI_PREFER_DST_LARGESTSCOPE since this settings presumably alters the "Prefer smaller scope" destination address selection rule...? AI_PREFER_SRC_LOWERSCOPE Same. Also, why is this "LOWER" instead of "LOWEST"? Its buddy is "LARGEST". AI_PREFER_SRC_TUNNEL I'm also guessing that you mean AI_PREFER_DST_TUNNEL, as this setting presumably alters the "Prefer native transport" destination address selection rule...? AI_PREFER_SRC_NATIVE Same. 3. There is no explicit text on what an implementation should do if they don't support Mobile IPv6 or CGA addresses. Should they define these socket option constants and ignore them if set, or should they return EINVAL if set? Same question for the AI_* flags for getaddrinfo()... My inclination would be to define them, but ignore them when set on such implementations. Thanks, -Seb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 00:33:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6N7Wx06028678; Wed, 23 Jul 2003 00:32:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6N7Wx4x028677; Wed, 23 Jul 2003 00:32:59 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6N7Wt06028670 for ; Wed, 23 Jul 2003 00:32:55 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6N7UMQ27769; Wed, 23 Jul 2003 09:30:23 +0200 (MEST) Date: Wed, 23 Jul 2003 09:28:27 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on address selection API To: Sebastien Roy Cc: samita.chakrabarti@Sun.COM, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200307230136.h6N1aHH2005294@strat.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 3. There is no explicit text on what an implementation should do if they > don't support Mobile IPv6 or CGA addresses. Should they define these > socket option constants and ignore them if set, or should they return > EINVAL if set? Same question for the AI_* flags for getaddrinfo()... > My inclination would be to define them, but ignore them when set on > such implementations. "Ignore" seems to be the right thing. The motivation is to be able to write software (such as a DNS stub resolver) where using the CoA as source is better for performance when the node is indeed a mobile IP node away from home. But when this is not the case you don't want to see a failure or require that the application only set PREFER_SRC_COA when it knows it is running on a mobile node away from home. Makes sense to make that clear in the spec. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 01:11:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6N8BU06029166; Wed, 23 Jul 2003 01:11:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6N8BUa3029165; Wed, 23 Jul 2003 01:11:30 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6N8BQ06029158 for ; Wed, 23 Jul 2003 01:11:26 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6N892UY025813 for ; Wed, 23 Jul 2003 01:09:02 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6N88pSw010980 for ; Wed, 23 Jul 2003 02:08:56 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6N88ml15033; Wed, 23 Jul 2003 10:08:48 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6N86bof074272; Wed, 23 Jul 2003 10:06:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307230806.h6N86bof074272@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Suresh Krishnan (QB/LMC)" cc: "'greg.daley@eng.monash.edu.au'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: RFC 3513 EUI-48/MAC-48 confusion In-reply-to: Your message of Tue, 22 Jul 2003 13:29:42 EDT. <7B2A7784F4B7F0409947481F3F3FEF830837B098@eammlex037.lmc.ericsson.se> Date: Wed, 23 Jul 2003 10:06:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Hi Francis, Agree with you almost completely except for this > BTW the EUI-64 stuff is a big joke: > *no* IEEE layer 2 uses EUI-64s as addresses today (IEEE 1394 aka > I-Link aka FireWire uses 6 bit node addresses). I assume you meant EUI-48s. => no, I meant EUI-64s. IEEE 1394 was used as an example of an IEEE layer 2 using EUI-64s, this is true but what takes the role of addresses in IEEE 1394 are Node IDs (6 bit long) or Bus + Node IDs (16 bit long). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 05:39:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6NCdH06001196; Wed, 23 Jul 2003 05:39:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6NCdHPX001195; Wed, 23 Jul 2003 05:39:17 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6NCdE06001188 for ; Wed, 23 Jul 2003 05:39:14 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6NCamUu004234 for ; Wed, 23 Jul 2003 05:36:48 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6NCaNEJ007317 for ; Wed, 23 Jul 2003 06:36:29 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h6NCZrh24423; Wed, 23 Jul 2003 19:35:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h6NCZU902428; Wed, 23 Jul 2003 19:35:34 +0700 (ICT) From: Robert Elz To: Francis Dupont cc: "Suresh Krishnan (QB/LMC)" , "'greg.daley@eng.monash.edu.au'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: RFC 3513 EUI-48/MAC-48 confusion In-Reply-To: <200307221602.h6MG23of072361@givry.rennes.enst-bretagne.fr> References: <200307221602.h6MG23of072361@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 2003 19:35:29 +0700 Message-ID: <175.1058963729@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 22 Jul 2003 18:02:03 +0200 From: Francis Dupont Message-ID: <200307221602.h6MG23of072361@givry.rennes.enst-bretagne.fr> | => this is an old issue. Yes. | IMHO the best solution is to consider the MAC-48 -> EUI-48 Is there such a thing? I thought that MAC-48 and EUI-48 were distinct (though very similar looking) number spaces. | BTW the EUI-64 stuff is a big joke: | *no* IEEE layer 2 uses EUI-64s as addresses today It certainly is currently. There isn't likely to be a link layer that uses EUI-64 until something remarkably new appears (something that no-one wants to be compatible with ethernet in any way) but which is designed to be of similar utility to ethernet. This combination is perhaps unlikely... But it does no real harm to allow for EUI-64 - we want IPv6 addressing to last for MANY years into the future - EUI-64 is certainly a plausible addressing structure for some future link layer to adopt (given that it is defined, etc). If it never happens, big deal (we're not about to switch IPv6 addresses to be 112 bits, and nor do we need more than 64 bit prefixes (48 bit site identifiers)). On the original point - the stupid thing is that Deering (I think) had the transformation defined originally using FFFF (the correct value to convert MAC-48 to EUI-64), but the WG was then told that was the wrong value, and FFFE was the one that should be used. And we believed it... I'd suggest now just documenting the thing, perhaps reserving FFFE for EUI-48 to EUI-64 conversion in IPv6 addresses (should this ever be needed). IPv6 addresses don't use "true" EUI-64 anyway, they have the U/L bit inverted. If it is OK to invert one bit, it must also be OK to (sometimes) invert another bit... It is weird, but it costs nothing beyond the explanation in the doc. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 07:39:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6NEdq06003873; Wed, 23 Jul 2003 07:39:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6NEdq8C003872; Wed, 23 Jul 2003 07:39:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6NEdm06003859 for ; Wed, 23 Jul 2003 07:39:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6NEbNUu005937 for ; Wed, 23 Jul 2003 07:37:23 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6NEbKGg012776 for ; Wed, 23 Jul 2003 07:37:21 -0700 (PDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6NEbHl22697; Wed, 23 Jul 2003 16:37:17 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6NEZ5of075594; Wed, 23 Jul 2003 16:35:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307231435.h6NEZ5of075594@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: "Suresh Krishnan (QB/LMC)" , "'greg.daley@eng.monash.edu.au'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: RFC 3513 EUI-48/MAC-48 confusion In-reply-to: Your message of Wed, 23 Jul 2003 19:35:29 +0700. <175.1058963729@munnari.OZ.AU> Date: Wed, 23 Jul 2003 16:35:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: | IMHO the best solution is to consider the MAC-48 -> EUI-48 Is there such a thing? => not really but the difference between MAC-48 and EUI-48 is more a problem of interpretation (address != identifier) than something else. I thought that MAC-48 and EUI-48 were distinct (though very similar looking) number spaces. => The IEEE (http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html) is not cristal clear about this: overlap between spaces is discouraged but not forbidden. So as the real issue is possible collisions between EUI-64s from real EUI-48s and EUI-64s from MAC-48s using our bogus translation rule, IMHO this is not (yet) a real issue. BTW, as they are defined by the IEEE, we should not get real EUI-48s in an IPv6 context. I'd suggest now just documenting the thing, perhaps reserving FFFE for EUI-48 to EUI-64 conversion in IPv6 addresses (should this ever be needed). IPv6 addresses don't use "true" EUI-64 anyway, they have the U/L bit inverted. If it is OK to invert one bit, it must also be OK to (sometimes) invert another bit... It is weird, but it costs nothing beyond the explanation in the doc. => I agree... Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 13:31:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6NKVV06013208; Wed, 23 Jul 2003 13:31:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6NKVV8p013207; Wed, 23 Jul 2003 13:31:31 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6NKVR06013200 for ; Wed, 23 Jul 2003 13:31:27 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6NKT1UY014551 for ; Wed, 23 Jul 2003 13:29:01 -0700 (PDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6NKSu7W021309 for ; Wed, 23 Jul 2003 14:28:56 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIH000OOVK8L2@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 23 Jul 2003 14:28:56 -0600 (MDT) Received: from sun.com ([129.146.17.35]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIH00HLZVK65K@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 23 Jul 2003 14:28:56 -0600 (MDT) Date: Wed, 23 Jul 2003 13:28:54 -0700 From: Alain Durand Subject: Re: playground.sun.com unreach (IPv6) To: ipng@sunroof.eng.sun.com Cc: itojun@iijlab.net Message-id: <3F1EF006.4010704@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <20030620023545.CFBB492@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The AAAA record for playground.sun.com has eventually been deleted. playground is now v4 only. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 04:33:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OBXW06020311; Thu, 24 Jul 2003 04:33:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OBXWC2020310; Thu, 24 Jul 2003 04:33:32 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OBXS06020303 for ; Thu, 24 Jul 2003 04:33:28 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OBV2UY029607 for ; Thu, 24 Jul 2003 04:31:02 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6OBUpGg013362 for ; Thu, 24 Jul 2003 04:30:55 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 24 Jul 2003 16:44:09 +0530 Received: from suvendum (suvendum.future.futsoft.com [10.20.6.98]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h6OAtX0r025677 for ; Thu, 24 Jul 2003 16:25:34 +0530 Reply-To: From: "Suvendu M" To: Subject: Same global address on Multiple Interface of an IP6 node Date: Thu, 24 Jul 2003 16:30:17 +0530 Message-Id: <001701c351d2$c53b84a0$6206140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, I have a generic question on Ipv6.It is : Can a single global address (say 2222::1111) be configured on multiple interfaces of a single ip6 node. If so is there any specific purpose for doing that ?? What about link-local address, how would it be used, if single link local address is configured on multiple interface of a same node. Thanks in advance for your response. Regards, Suvendu *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 05:13:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OCDb06021478; Thu, 24 Jul 2003 05:13:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OCDbhm021477; Thu, 24 Jul 2003 05:13:37 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OCDX06021462 for ; Thu, 24 Jul 2003 05:13:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OCB7Uu004449 for ; Thu, 24 Jul 2003 05:11:07 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6OCAtC0004724 for ; Thu, 24 Jul 2003 05:10:56 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h6OCAih07108; Thu, 24 Jul 2003 19:10:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h6OCAUP05201; Thu, 24 Jul 2003 19:10:31 +0700 (ICT) From: Robert Elz To: suvendum@future.futsoft.com cc: ipng@sunroof.eng.sun.com Subject: Re: Same global address on Multiple Interface of an IP6 node In-Reply-To: <001701c351d2$c53b84a0$6206140a@future.futsoft.com> References: <001701c351d2$c53b84a0$6206140a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jul 2003 19:10:30 +0700 Message-ID: <3838.1059048630@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 24 Jul 2003 16:30:17 +0530 From: "Suvendu M" Message-ID: <001701c351d2$c53b84a0$6206140a@future.futsoft.com> | Can a single global address (say 2222::1111) be configured on multiple | interfaces of a single ip6 node. Depends what the implementation allows, but I doubt many would permit that - the address (with the prefix length) generally also defines the prefix for the link, and those need to be unique for routing to work. | If so is there any specific purpose for doing that ?? Not that I can think of. | What about link-local address, how would it be used, if single link local | address is configured on multiple interface of a same node. This one is impossible to achieve. You can set addresses with the same bit pattern, but they're all different addresses, as they're in different scopes. Whether or not the bit patterns look similar, there's no great magic to how LL addresses are used - if there's more than one possible scope (ie: there's more that one interface, usually excluding the loopback interface, that no-one I know of enables LL addresses on) then the scope must always accompany the address for it to have any meaning at all. in that sense, the scope is part of the address. [Of course, if the multiple interfaces concerned were bridged together, then they would all be in one link, all have one scope, and having just a single LL address for the collection of them would make perfect sense]. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 05:33:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OCXp06022380; Thu, 24 Jul 2003 05:33:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OCXpYE022379; Thu, 24 Jul 2003 05:33:51 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OCXl06022372 for ; Thu, 24 Jul 2003 05:33:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OCVMUY012809 for ; Thu, 24 Jul 2003 05:31:22 -0700 (PDT) Received: from rediffmail.com (webmail34.rediffmail.com [203.199.83.247] (may be forged)) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with SMTP id h6OCVFGg009735 for ; Thu, 24 Jul 2003 05:31:16 -0700 (PDT) Received: (qmail 12261 invoked by uid 510); 24 Jul 2003 12:29:09 -0000 Date: 24 Jul 2003 12:29:09 -0000 Message-ID: <20030724122909.12260.qmail@mailweb34.rediffmail.com> Received: from unknown (203.197.168.166) by rediffmail.com via HTTP; 24 jul 2003 12:29:09 -0000 MIME-Version: 1.0 From: "Chandra Bhushan Singh" Reply-To: "Chandra Bhushan Singh" To: ipng@sunroof.eng.sun.com Subject: small delay between unsolicited NA Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Following para is from rfc 2461, "A node that has multiple IP addresses assigned to an interface MAY multicast a separate Neighbor Advertisement for each address. In such a case the node SHOULD introduce a small delay between the sending of each advertisement to reduce the probability of the advertisements being lost due to congestion." Could anyone of you please tell me what should be the exact value of this "small delay"? Regards Chandra ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 05:50:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OCoQ06022977; Thu, 24 Jul 2003 05:50:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OCoQrn022976; Thu, 24 Jul 2003 05:50:26 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OCoM06022969 for ; Thu, 24 Jul 2003 05:50:22 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OCluUu013367 for ; Thu, 24 Jul 2003 05:47:56 -0700 (PDT) Received: from ltitlout.lntinfotech.com (lntinfotech.com [203.199.54.8]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6OClnvH004870 for ; Thu, 24 Jul 2003 06:47:50 -0600 (MDT) Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2003072418204216:5229 ; Thu, 24 Jul 2003 18:20:42 +0530 To: Cc: From: "Suvidh Mathur" Subject: Re: Same global address on Multiple Interface of an IP6 node Date: Thu, 24 Jul 2003 18:09:04 +0530 Message-ID: MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 07/24/2003 06:17:28 PM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 07/24/2003 06:20:42 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 07/24/2003 06:20:53 PM, Serialize complete at 07/24/2003 06:20:53 PM Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk see inline..., > >All, > >I have a generic question on Ipv6.It is : > >Can a single global address (say 2222::1111) be configured on multiple >interfaces of a single ip6 node. If so is there any specific purpose for >doing that ?? I'm not sure what you mean here. There seems to be two possibilities: 1. multiple interfaces connected to different networks. In this case, the global addresses cannot be same since the network prefixes MUST be unique. 2. multiple interfaces connected to same network. In this case, DAD for the address would fail. Thus multiple interfaces having same address do not make much sense, except maybe in case of virtual interfaces / backup interfaces etc. >What about link-local address, how would it be used, if single link local >address is configured on multiple interface of a same node. For link local addresses, the scope, i.e. the interface forms a part of the address itself. Even if the LL address bit pattern is similar, the scoped address becomes different. regards, suvidh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 06:01:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OD1d06023388; Thu, 24 Jul 2003 06:01:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OD1dxJ023387; Thu, 24 Jul 2003 06:01:39 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OD1Z06023380 for ; Thu, 24 Jul 2003 06:01:36 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OCx9UY018961 for ; Thu, 24 Jul 2003 05:59:09 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6OCx41h003049 for ; Thu, 24 Jul 2003 06:59:04 -0600 (MDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6OCwqUj242856; Thu, 24 Jul 2003 08:58:52 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6OCwpFC203656; Thu, 24 Jul 2003 06:58:51 -0600 In-Reply-To: <001701c351d2$c53b84a0$6206140a@future.futsoft.com> To: Cc: ipng@sunroof.eng.sun.com Subject: Re: Same global address on Multiple Interface of an IP6 node MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 07/24/2003 08:57:57 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 07/24/2003 08:57:57 AM, Serialize complete at 07/24/2003 08:57:57 AM, S/MIME Sign failed at 07/24/2003 08:57:57 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/24/2003 06:58:51, Serialize complete at 07/24/2003 06:58:51 Message-ID: Date: Thu, 24 Jul 2003 08:58:46 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Can a single global address (say 2222::1111) be configured on multiple > interfaces of a single ip6 node. Yes, it can. There are a few ways to accomplish this. If all the interfaces are on the same lan, then you could have a "primary" and a "backup" interface. If the interfaces are on different lans, you can run a dynamic routing protocol and advertise the address as being reachable through each physical interface on a node. In this case, the address isn't really configured on the multiple interfaces per-se (you instead have a "virtual" interface which is assigned the IP address), but the result is any interface on the node may be used. There are other methods which may be used as well. > If so is there any specific purpose for doing that ?? Redundancy. If one interface goes down, traffic will automatically switch to the another interface without disrupting existing connections. > What about link-local address, how would it be used, if single link local > address is configured on multiple interface of a same node. I'm not sure it is particularly useful. Link-local addresses are really intended to be used for bootstraping, configuration discovery, route table maintenance, and the like. Most, if not all, of these protocols work on a per-interface basis. I suppose it could allow an interface to act as a "hot standby" for another interface, automatically switching over if the primary interface fails. But this would only work if the interfaces are on the same physical lan. If they are on different lans, then the two interfaces are in different link-local scope zones and are treated as unique addresses. Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 06:36:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6ODaS06024255; Thu, 24 Jul 2003 06:36:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6ODaSqr024254; Thu, 24 Jul 2003 06:36:28 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6ODaO06024247 for ; Thu, 24 Jul 2003 06:36:24 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6ODXnUY026167 for ; Thu, 24 Jul 2003 06:33:54 -0700 (PDT) Received: from fries.net (ns0.fries.net [66.210.106.26]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6ODXhvH026747 for ; Thu, 24 Jul 2003 07:33:43 -0600 (MDT) Received: from shadow.fries.net (cywhldnd0nst6psal9yf@localhost.fries.net [IPv6:::1]) by fries.net (8.12.9/8.12.9) with ESMTP id h6ODUSw8013463 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2003 08:30:29 -0500 (CDT) Received: (from todd@localhost) by shadow.fries.net (8.12.9/8.12.9/Submit) id h6ODUQrV006247; Thu, 24 Jul 2003 08:30:26 -0500 (CDT) Date: Thu, 24 Jul 2003 08:30:26 -0500 From: "Todd T. Fries" To: Roy Brabson Cc: suvendum@future.futsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Same global address on Multiple Interface of an IP6 node Message-ID: <20030724133026.GC27276@fries.net> Reply-To: todd@fries.net References: <001701c351d2$c53b84a0$6206140a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: OpenBSD shadow.fries.net 3.3 GENERIC X-PGP-Fingerprint: B6 3B 70 46 BC 0F 8C DD 14 D4 C7 D1 47 F6 23 FA X-URL: http://todd.fries.net X-tra-email: todd@{fries.net,OpenBSD.org} toddf@acm.org toddfries@yahoo.com X-IM: toddfries@{AIM,Yahoo} 115268457@ICQ {toddfries,fr[1i]es}@*.irc.fries.net X-Jabber: todd@tipic.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I understand there are tricks for faster thoroughput on IPv4 with regards to multiple interfaces (network cards) and a single IP address. Say, two 100mbit cards plugged into the same 100mbit switch. Is this `trick' available with IPv6 in any fashion? -- Todd Fries .. todd@fries.net Free Daemon Consulting, LLC Land: 405-748-4596 http://FreeDaemonConsulting.com Mobile: 405-203-6124 "..in support of free software solutions." Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) Penned by Roy Brabson on Thu, Jul 24, 2003 at 08:58:46AM -0400, we have: | > Can a single global address (say 2222::1111) be configured on multiple | > interfaces of a single ip6 node. | | Yes, it can. There are a few ways to accomplish this. If all the | interfaces are on the same lan, then you could have a "primary" and a | "backup" interface. If the interfaces are on different lans, you can run | a dynamic routing protocol and advertise the address as being reachable | through each physical interface on a node. In this case, the address | isn't really configured on the multiple interfaces per-se (you instead | have a "virtual" interface which is assigned the IP address), but the | result is any interface on the node may be used. There are other methods | which may be used as well. | | > If so is there any specific purpose for doing that ?? | | Redundancy. If one interface goes down, traffic will automatically switch | to the another interface without disrupting existing connections. | | > What about link-local address, how would it be used, if single link | local | > address is configured on multiple interface of a same node. | | I'm not sure it is particularly useful. Link-local addresses are really | intended to be used for bootstraping, configuration discovery, route table | maintenance, and the like. Most, if not all, of these protocols work on a | per-interface basis. I suppose it could allow an interface to act as a | "hot standby" for another interface, automatically switching over if the | primary interface fails. But this would only work if the interfaces are | on the same physical lan. If they are on different lans, then the two | interfaces are in different link-local scope zones and are treated as | unique addresses. | | Roy | -------------------------------------------------------------------- | IETF IPng Working Group Mailing List | IPng Home Page: http://playground.sun.com/ipng | FTP archive: ftp://playground.sun.com/pub/ipng | Direct all administrative requests to majordomo@sunroof.eng.sun.com | -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 07:59:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OExl06026061; Thu, 24 Jul 2003 07:59:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OExl3B026060; Thu, 24 Jul 2003 07:59:47 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OExd06026053 for ; Thu, 24 Jul 2003 07:59:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OEvDUu013110 for ; Thu, 24 Jul 2003 07:57:14 -0700 (PDT) Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6OEv8LL027862 for ; Thu, 24 Jul 2003 07:57:08 -0700 (PDT) Subject: RE: Same global address on Multiple Interface of an IP6 node MIME-Version: 1.0 Date: Thu, 24 Jul 2003 07:57:08 -0700 Content-Type: text/plain; charset="us-ascii" Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Same global address on Multiple Interface of an IP6 node Thread-Index: AcNR6SaEFyBpUv4YRv2KxcjDBGRyxAABYjyg From: "Michel Py" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6OExe06026054 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Todd, > Todd T. Fries wrote: > I understand there are tricks for faster thoroughput on > IPv4 with regards to multiple interfaces (network cards) > and a single IP address. Say, two 100mbit cards plugged > into the same 100mbit switch. Is this `trick' available > with IPv6 in any fashion? There would be interesting issues with having two interfaces with the same IPv6 address on a switch related to the switch's CAM table, I doubt it could work without channelizing at a lower layer. For what I have done, these tricks are not specific to IPv4 but lower in the stack by combining several physical interfaces into a single logical bundle at the data link layer; the IPv6 address is applied to the newly created logical interface. I mostly use Fast or Gigabit Etherchannel. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 08:09:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OF9d06026280; Thu, 24 Jul 2003 08:09:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OF9cZN026279; Thu, 24 Jul 2003 08:09:38 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OF9Y06026266 for ; Thu, 24 Jul 2003 08:09:34 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OF78Uu015731 for ; Thu, 24 Jul 2003 08:07:08 -0700 (PDT) Received: from fries.net (ns0.fries.net [66.210.106.26]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6OF725K009021 for ; Thu, 24 Jul 2003 09:07:02 -0600 (MDT) Received: from shadow.fries.net (tt52mjltkbbes9isk81f@localhost.fries.net [IPv6:::1]) by fries.net (8.12.9/8.12.9) with ESMTP id h6OF43w8006481 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2003 10:04:03 -0500 (CDT) Received: (from todd@localhost) by shadow.fries.net (8.12.9/8.12.9/Submit) id h6OF43R3001478; Thu, 24 Jul 2003 10:04:03 -0500 (CDT) Date: Thu, 24 Jul 2003 10:04:02 -0500 From: "Todd T. Fries" To: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: Same global address on Multiple Interface of an IP6 node Message-ID: <20030724150402.GA25748@fries.net> Reply-To: todd@fries.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: OpenBSD shadow.fries.net 3.3 GENERIC X-PGP-Fingerprint: B6 3B 70 46 BC 0F 8C DD 14 D4 C7 D1 47 F6 23 FA X-URL: http://todd.fries.net X-tra-email: todd@{fries.net,OpenBSD.org} toddf@acm.org toddfries@yahoo.com X-IM: toddfries@{AIM,Yahoo} 115268457@ICQ {toddfries,fr[1i]es}@*.irc.fries.net X-Jabber: todd@tipic.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the details. I was never fully certain as to how this worked. It makes sense though. And it definately allows for IPv6.. -- Todd Fries .. todd@fries.net Free Daemon Consulting, LLC Land: 405-748-4596 http://FreeDaemonConsulting.com Mobile: 405-203-6124 "..in support of free software solutions." Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) Penned by Michel Py on Thu, Jul 24, 2003 at 07:57:08AM -0700, we have: | Todd, | | > Todd T. Fries wrote: | > I understand there are tricks for faster thoroughput on | > IPv4 with regards to multiple interfaces (network cards) | > and a single IP address. Say, two 100mbit cards plugged | > into the same 100mbit switch. Is this `trick' available | > with IPv6 in any fashion? | | There would be interesting issues with having two interfaces with the | same IPv6 address on a switch related to the switch's CAM table, I doubt | it could work without channelizing at a lower layer. | | For what I have done, these tricks are not specific to IPv4 but lower in | the stack by combining several physical interfaces into a single logical | bundle at the data link layer; the IPv6 address is applied to the newly | created logical interface. I mostly use Fast or Gigabit Etherchannel. | | Michel. | -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 09:30:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OGU106028546; Thu, 24 Jul 2003 09:30:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OGU0p8028543; Thu, 24 Jul 2003 09:30:00 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OGTq06028527 for ; Thu, 24 Jul 2003 09:29:55 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OGRQUY022444 for ; Thu, 24 Jul 2003 09:27:26 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6OGRE5K015219 for ; Thu, 24 Jul 2003 10:27:20 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12785; Thu, 24 Jul 2003 12:27:08 -0400 (EDT) Message-Id: <200307241627.MAA12785@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-park-ipv6-dad-problem-wlan-00.txt Date: Thu, 24 Jul 2003 12:27:08 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 DAD Consideration for 802.11 Environment Author(s) : S. Park et al. Filename : draft-park-ipv6-dad-problem-wlan-00.txt Pages : 6 Date : 2003-7-24 This memo tries to consider a problem when IPv6 node performs DAD procedure to verify address duplication in 802.11 [WLAN] environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-ipv6-dad-problem-wlan-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-park-ipv6-dad-problem-wlan-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-park-ipv6-dad-problem-wlan-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-24122453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-park-ipv6-dad-problem-wlan-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-park-ipv6-dad-problem-wlan-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122453.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 10:07:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OH7E06029565; Thu, 24 Jul 2003 10:07:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OH7Eu5029562; Thu, 24 Jul 2003 10:07:14 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OH7B06029552 for ; Thu, 24 Jul 2003 10:07:11 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OH4jUY008099 for ; Thu, 24 Jul 2003 10:04:45 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6OH4d0P012430 for ; Thu, 24 Jul 2003 11:04:39 -0600 (MDT) Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel13.hp.com (Postfix) with ESMTP id 5F2E11C00A91 for ; Thu, 24 Jul 2003 10:04:39 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 519E81C00A8B for ; Thu, 24 Jul 2003 10:04:39 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Jul 2003 10:04:39 -0700 Message-ID: From: "AGARWAL,SWATI (HP-FtCollins,ex1)" To: "'ipng@sunroof.eng.sun.com'" Subject: Reverse lookup for IPv6 on Windows Date: Thu, 24 Jul 2003 10:04:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I am trying to do a reverse lookup on IPv6 on Windows. I am using getnameinfo for that. I am not able to successfully do this. Does someone have an example code for this? Swati -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 11:37:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OIbX06001915; Thu, 24 Jul 2003 11:37:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OIbWm7001914; Thu, 24 Jul 2003 11:37:32 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OIbT06001907 for ; Thu, 24 Jul 2003 11:37:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OIZ3Uu028855 for ; Thu, 24 Jul 2003 11:35:03 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6OIYwLL019785 for ; Thu, 24 Jul 2003 11:34:58 -0700 (PDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se. [208.237.135.118]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h6OIYsVf017927; Thu, 24 Jul 2003 13:34:54 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id PMD8L49V; Thu, 24 Jul 2003 13:34:25 -0500 Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h6OIYrGx010539; Thu, 24 Jul 2003 14:34:53 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id <337NSS7Z>; Thu, 24 Jul 2003 14:36:01 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B09A@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/LMC)" To: "'AGARWAL,SWATI (HP-FtCollins,ex1)'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Reverse lookup for IPv6 on Windows Date: Thu, 24 Jul 2003 14:34:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Swati, It has been a while since I did this, but here goes. Regards Suresh <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> SOCKADDR_IN sinDest; int iDummy; // Length if you want to use it in case of error in WSAStringToAddress // WSAStartup blah blah // strIP is the char * with your IP address // strHostName will be the resolved hostname (char *) sinDest.sin_family = AF_INET; WSAStringToAddress(strIP, AF_INET, NULL,(LPSOCKADDR)&sinDest, &iDummy); if(getnameinfo((struct sockaddr *)&sinDest,sizeof(sinDest), strHostName,sizeof(strHostName), NULL, // Service info - don't care 0, // Service info - don't care NI_NAMEREQD // I want an error if it is not resolved )) { // Error } else { // Success } // WSACleanup blah blah <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 1:05 PM To: 'ipng@sunroof.eng.sun.com' Subject: Reverse lookup for IPv6 on Windows Hello, I am trying to do a reverse lookup on IPv6 on Windows. I am using getnameinfo for that. I am not able to successfully do this. Does someone have an example code for this? Swati -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 11:58:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OIws06002739; Thu, 24 Jul 2003 11:58:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OIwscY002738; Thu, 24 Jul 2003 11:58:54 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OIwo06002731 for ; Thu, 24 Jul 2003 11:58:50 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OIuKUY028359 for ; Thu, 24 Jul 2003 11:56:20 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6OIuE0P020805 for ; Thu, 24 Jul 2003 12:56:14 -0600 (MDT) Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel13.hp.com (Postfix) with ESMTP id 924A61C01A58; Thu, 24 Jul 2003 11:56:14 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 72F4B1C00A8C; Thu, 24 Jul 2003 11:56:14 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Jul 2003 11:56:14 -0700 Message-ID: From: "AGARWAL,SWATI (HP-FtCollins,ex1)" To: "'Suresh Krishnan (QB/LMC)'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Reverse lookup for IPv6 on Windows Date: Thu, 24 Jul 2003 11:56:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Suresh. I tried it. But I am getting the following error: WSANO_DATA 11004 Valid name, no data record of requested type. The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record-indicating the host itself exists, but is not directly reachable. According to the above error it says that this is a hostname to ip address translation. In my case it is vice versa. Also I am doing IPv6. I am able to get the resolve the IPv6 addresses with nslookup using the 128 bit string. Any thoughts? Swati -----Original Message----- From: Suresh Krishnan (QB/LMC) [mailto:suresh.h.krishnan@ericsson.com] Sent: Thursday, July 24, 2003 12:35 PM To: 'AGARWAL,SWATI (HP-FtCollins,ex1)'; 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Hi Swati, It has been a while since I did this, but here goes. Regards Suresh <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> SOCKADDR_IN sinDest; int iDummy; // Length if you want to use it in case of error in WSAStringToAddress // WSAStartup blah blah // strIP is the char * with your IP address // strHostName will be the resolved hostname (char *) sinDest.sin_family = AF_INET; WSAStringToAddress(strIP, AF_INET, NULL,(LPSOCKADDR)&sinDest, &iDummy); if(getnameinfo((struct sockaddr *)&sinDest,sizeof(sinDest), strHostName,sizeof(strHostName), NULL, // Service info - don't care 0, // Service info - don't care NI_NAMEREQD // I want an error if it is not resolved )) { // Error } else { // Success } // WSACleanup blah blah <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 1:05 PM To: 'ipng@sunroof.eng.sun.com' Subject: Reverse lookup for IPv6 on Windows Hello, I am trying to do a reverse lookup on IPv6 on Windows. I am using getnameinfo for that. I am not able to successfully do this. Does someone have an example code for this? Swati -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 12:18:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OJIx06003441; Thu, 24 Jul 2003 12:18:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OJIw2f003440; Thu, 24 Jul 2003 12:18:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OJIt06003433 for ; Thu, 24 Jul 2003 12:18:55 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OJGTUY005819 for ; Thu, 24 Jul 2003 12:16:29 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6OJGOZG014313 for ; Thu, 24 Jul 2003 13:16:24 -0600 (MDT) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se. [208.237.135.117]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h6OJGMVf026899; Thu, 24 Jul 2003 14:16:22 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id PMD0Y272; Thu, 24 Jul 2003 14:16:17 -0500 Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h6OJGLGx012206; Thu, 24 Jul 2003 15:16:21 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id <337NSTH1>; Thu, 24 Jul 2003 15:17:28 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B09B@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/LMC)" To: "'AGARWAL,SWATI (HP-FtCollins,ex1)'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Reverse lookup for IPv6 on Windows Date: Thu, 24 Jul 2003 15:16:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Swati, Does your DNS server have the PTR records in the IP6.ARPA (or IP6.INT) domain for the IP address you are looking up? Short of that nothing else strikes my mind. Regards Suresh -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 2:56 PM To: Suresh Krishnan (QB/LMC); 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Thanks Suresh. I tried it. But I am getting the following error: WSANO_DATA 11004 Valid name, no data record of requested type. The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record-indicating the host itself exists, but is not directly reachable. According to the above error it says that this is a hostname to ip address translation. In my case it is vice versa. Also I am doing IPv6. I am able to get the resolve the IPv6 addresses with nslookup using the 128 bit string. Any thoughts? Swati -----Original Message----- From: Suresh Krishnan (QB/LMC) [mailto:suresh.h.krishnan@ericsson.com] Sent: Thursday, July 24, 2003 12:35 PM To: 'AGARWAL,SWATI (HP-FtCollins,ex1)'; 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Hi Swati, It has been a while since I did this, but here goes. Regards Suresh <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> SOCKADDR_IN sinDest; int iDummy; // Length if you want to use it in case of error in WSAStringToAddress // WSAStartup blah blah // strIP is the char * with your IP address // strHostName will be the resolved hostname (char *) sinDest.sin_family = AF_INET; WSAStringToAddress(strIP, AF_INET, NULL,(LPSOCKADDR)&sinDest, &iDummy); if(getnameinfo((struct sockaddr *)&sinDest,sizeof(sinDest), strHostName,sizeof(strHostName), NULL, // Service info - don't care 0, // Service info - don't care NI_NAMEREQD // I want an error if it is not resolved )) { // Error } else { // Success } // WSACleanup blah blah <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 1:05 PM To: 'ipng@sunroof.eng.sun.com' Subject: Reverse lookup for IPv6 on Windows Hello, I am trying to do a reverse lookup on IPv6 on Windows. I am using getnameinfo for that. I am not able to successfully do this. Does someone have an example code for this? Swati -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 12:20:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OJKB06003457; Thu, 24 Jul 2003 12:20:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OJKBJb003456; Thu, 24 Jul 2003 12:20:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OJK706003449 for ; Thu, 24 Jul 2003 12:20:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OJHfUu015481 for ; Thu, 24 Jul 2003 12:17:41 -0700 (PDT) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6OJHZFW020510 for ; Thu, 24 Jul 2003 12:17:36 -0700 (PDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id 75CA31C00E92; Thu, 24 Jul 2003 15:17:35 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 6B2D51C000B1; Thu, 24 Jul 2003 15:17:35 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <3F3QLLJ3>; Thu, 24 Jul 2003 15:17:35 -0400 Message-ID: From: "AGARWAL,SWATI (HP-FtCollins,ex1)" To: "'Suresh Krishnan (QB/LMC)'" , "AGARWAL,SWATI (HP-FtCollins,ex1)" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Reverse lookup for IPv6 on Windows Date: Thu, 24 Jul 2003 15:17:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes the DNS server here has PTR records in the IP6.INT domain. Is that a problem? Swati -----Original Message----- From: Suresh Krishnan (QB/LMC) [mailto:suresh.h.krishnan@ericsson.com] Sent: Thursday, July 24, 2003 1:16 PM To: 'AGARWAL,SWATI (HP-FtCollins,ex1)'; 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Hi Swati, Does your DNS server have the PTR records in the IP6.ARPA (or IP6.INT) domain for the IP address you are looking up? Short of that nothing else strikes my mind. Regards Suresh -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 2:56 PM To: Suresh Krishnan (QB/LMC); 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Thanks Suresh. I tried it. But I am getting the following error: WSANO_DATA 11004 Valid name, no data record of requested type. The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record-indicating the host itself exists, but is not directly reachable. According to the above error it says that this is a hostname to ip address translation. In my case it is vice versa. Also I am doing IPv6. I am able to get the resolve the IPv6 addresses with nslookup using the 128 bit string. Any thoughts? Swati -----Original Message----- From: Suresh Krishnan (QB/LMC) [mailto:suresh.h.krishnan@ericsson.com] Sent: Thursday, July 24, 2003 12:35 PM To: 'AGARWAL,SWATI (HP-FtCollins,ex1)'; 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Hi Swati, It has been a while since I did this, but here goes. Regards Suresh <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> SOCKADDR_IN sinDest; int iDummy; // Length if you want to use it in case of error in WSAStringToAddress // WSAStartup blah blah // strIP is the char * with your IP address // strHostName will be the resolved hostname (char *) sinDest.sin_family = AF_INET; WSAStringToAddress(strIP, AF_INET, NULL,(LPSOCKADDR)&sinDest, &iDummy); if(getnameinfo((struct sockaddr *)&sinDest,sizeof(sinDest), strHostName,sizeof(strHostName), NULL, // Service info - don't care 0, // Service info - don't care NI_NAMEREQD // I want an error if it is not resolved )) { // Error } else { // Success } // WSACleanup blah blah <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 1:05 PM To: 'ipng@sunroof.eng.sun.com' Subject: Reverse lookup for IPv6 on Windows Hello, I am trying to do a reverse lookup on IPv6 on Windows. I am using getnameinfo for that. I am not able to successfully do this. Does someone have an example code for this? Swati -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 12:40:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OJeO06004465; Thu, 24 Jul 2003 12:40:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OJeOif004464; Thu, 24 Jul 2003 12:40:24 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OJeF06004446 for ; Thu, 24 Jul 2003 12:40:20 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OJbhUY017528 for ; Thu, 24 Jul 2003 12:37:44 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6OJbc5K029565 for ; Thu, 24 Jul 2003 13:37:38 -0600 (MDT) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se. [208.237.135.117]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h6OJbbVf001397; Thu, 24 Jul 2003 14:37:37 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id PMD0YK9A; Thu, 24 Jul 2003 14:37:32 -0500 Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h6OJbaGx013093; Thu, 24 Jul 2003 15:37:36 -0400 (EDT) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Jul 2003 15:37:36 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B09C@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/LMC)" To: "'AGARWAL,SWATI (HP-FtCollins,ex1)'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Reverse lookup for IPv6 on Windows Date: Thu, 24 Jul 2003 15:37:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Swati, Maybe. The IP6.INT is deprecated (Check RFC3152). Use a packet grabber on your windows network and capture the outgoing DNS PTR query (Query Type 0x000c). Check what is being sent in the query. If the windows hosts sends a PTR query for .IP6.ARPA then your server needs to have the PTR record in IP6.ARPA Regards Suresh -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 3:18 PM To: Suresh Krishnan (QB/LMC); AGARWAL,SWATI (HP-FtCollins,ex1); 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Yes the DNS server here has PTR records in the IP6.INT domain. Is that a problem? Swati -----Original Message----- From: Suresh Krishnan (QB/LMC) [mailto:suresh.h.krishnan@ericsson.com] Sent: Thursday, July 24, 2003 1:16 PM To: 'AGARWAL,SWATI (HP-FtCollins,ex1)'; 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Hi Swati, Does your DNS server have the PTR records in the IP6.ARPA (or IP6.INT) domain for the IP address you are looking up? Short of that nothing else strikes my mind. Regards Suresh -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 2:56 PM To: Suresh Krishnan (QB/LMC); 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Thanks Suresh. I tried it. But I am getting the following error: WSANO_DATA 11004 Valid name, no data record of requested type. The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record-indicating the host itself exists, but is not directly reachable. According to the above error it says that this is a hostname to ip address translation. In my case it is vice versa. Also I am doing IPv6. I am able to get the resolve the IPv6 addresses with nslookup using the 128 bit string. Any thoughts? Swati -----Original Message----- From: Suresh Krishnan (QB/LMC) [mailto:suresh.h.krishnan@ericsson.com] Sent: Thursday, July 24, 2003 12:35 PM To: 'AGARWAL,SWATI (HP-FtCollins,ex1)'; 'ipng@sunroof.eng.sun.com' Subject: RE: Reverse lookup for IPv6 on Windows Hi Swati, It has been a while since I did this, but here goes. Regards Suresh <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> SOCKADDR_IN sinDest; int iDummy; // Length if you want to use it in case of error in WSAStringToAddress // WSAStartup blah blah // strIP is the char * with your IP address // strHostName will be the resolved hostname (char *) sinDest.sin_family = AF_INET; WSAStringToAddress(strIP, AF_INET, NULL,(LPSOCKADDR)&sinDest, &iDummy); if(getnameinfo((struct sockaddr *)&sinDest,sizeof(sinDest), strHostName,sizeof(strHostName), NULL, // Service info - don't care 0, // Service info - don't care NI_NAMEREQD // I want an error if it is not resolved )) { // Error } else { // Success } // WSACleanup blah blah <<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>> -----Original Message----- From: AGARWAL,SWATI (HP-FtCollins,ex1) [mailto:swati.agarwal@hp.com] Sent: Thursday, July 24, 2003 1:05 PM To: 'ipng@sunroof.eng.sun.com' Subject: Reverse lookup for IPv6 on Windows Hello, I am trying to do a reverse lookup on IPv6 on Windows. I am using getnameinfo for that. I am not able to successfully do this. Does someone have an example code for this? Swati -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 13:10:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OKAg06005493; Thu, 24 Jul 2003 13:10:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6OKAg67005492; Thu, 24 Jul 2003 13:10:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6OKAb06005474 for ; Thu, 24 Jul 2003 13:10:37 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OK8BUu002774 for ; Thu, 24 Jul 2003 13:08:11 -0700 (PDT) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6OK850P029877 for ; Thu, 24 Jul 2003 14:08:05 -0600 (MDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id 279001C01B5B; Thu, 24 Jul 2003 16:08:05 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id E6DC11C009F0; Thu, 24 Jul 2003 16:08:04 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <3F3QL4J8>; Thu, 24 Jul 2003 16:08:04 -0400 Message-ID: From: "AGARWAL,SWATI (HP-FtCollins,ex1)" To: "'Matti Aarnio'" , "AGARWAL,SWATI (HP-FtCollins,ex1)" Cc: "'Suresh Krishnan (QB/LMC)'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: Reverse lookup for IPv6 on Windows Date: Thu, 24 Jul 2003 16:05:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I changed the address family to AF_INET6 adn using SOCKADDR_IN6. I got the DNS name resolution to work. Thank you for all your help. Regards Swati -----Original Message----- From: Matti Aarnio [mailto:matti.aarnio@zmailer.org] Sent: Thursday, July 24, 2003 1:40 PM To: AGARWAL,SWATI (HP-FtCollins,ex1) Cc: 'Suresh Krishnan (QB/LMC)'; 'ipng@sunroof.eng.sun.com' Subject: Re: Reverse lookup for IPv6 on Windows The example code snippets are written with explite IPv4 lookups (AF_INET), NOT for AF_INET6 Another small detail is usage of SOCKADDR_IN, whereas correct one would be SOCKADDR_IN6 (All this without having any idea of what windows API supports, but knowing RFC API, and its UNIX incarnations.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 25 00:00:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6P70n06003628; Fri, 25 Jul 2003 00:00:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6P70nrp003627; Fri, 25 Jul 2003 00:00:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6P70i06003608 for ; Fri, 25 Jul 2003 00:00:45 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6P6wCUY008356 for ; Thu, 24 Jul 2003 23:58:13 -0700 (PDT) Received: from puku.zamnet.zm (puku.zamnet.zm [208.224.176.40]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6P6ufil005871 for ; Fri, 25 Jul 2003 00:56:51 -0600 (MDT) Received: from kaingo.zamnet.zm (kaingo.zamnet.zm [208.224.176.42]) by puku.zamnet.zm (8.12.9/8.12.9) with ESMTP id h6P6xChW078732 for ; Fri, 25 Jul 2003 08:59:12 +0200 (ZMT) Received: from fish (fish.zamnet.zm [208.224.176.99]) by zamnet.zm (Rockliffe SMTPRA 5.3.4) with SMTP id for ; Fri, 25 Jul 2003 08:55:40 +0200 MIME-Version: 1.0 Message-Id: <3F20D4EE.000009.03816@fish.zamnet.zm> Date: Fri, 25 Jul 2003 08:57:50 +0200 Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_ECJKMY50000000000000" X-Mailer: IncrediMail 2001 (2001107.2001107) From: "Albert Zulu" X-FID: D64B2275-2539-4D8A-9435-E29B28E47B50 X-FVER: 2.0 X-FIT: Letter X-FCOL: Islands X-FCAT: Nature X-FDIS: Turquoise Water X-Extensions: SU1CTDEsNDEsgUmBSSiZiTCRkZ2NTZGNlcVNiSjBJE3FiZWNTSyRxTCRwSyJnTCNgUksSU1CTDIsMCwsSU1CTDMsMCwsVHlwZVZlcnNpb24sMywxLjAs X-BG: <57E79BF2-3220-486C-A474-DA1543D524B3> X-BGT: no-repeat X-BGC: #38c8f8 X-BGPX: center X-BGPY: center X-ASN: BFF138F0-3EFC-11D4-BA3D-0050DAC68030 X-ASNF: 0 X-ASH: BFF138F0-3EFC-11D4-BA3D-0050DAC68030 X-ASHF: 1 X-AN: ANIM3D00-NONE-0000-0000-000000000000 X-ANF: 0 X-AP: ANIM3D00-NONE-0000-0000-000000000000 X-APF: 1 X-AD: 601231A0-325F-11D4-BA2D-0050DAC68030 X-ADF: 0 X-AUTO: X-ASN,X-ASH,X-AN,X-AP,X-AD X-CNT: ; X-Priority: 3 To: Subject: IPv6 in Unix and Windows server 2003 Disposition-Notification-To: "Albert Zulu" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------Boundary-00=_ECJKMY50000000000000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_ECJKH890000000000000" --------------Boundary-00=_ECJKH890000000000000 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All,=0D I am trying to implement Ipv6 in windows server 2003 and Unix. Does any o= ne has an idea on what I should start with. What are the major differences between IPv4 and IPv6?=0D =0D ----------------------------------------------------------------------=0D Albert Zulu, MCP, MCSE, MCDBA, =0D Customer Support Specialist, e-mail: albert@zamnet.zm =0D Tel: +260-1-225358/59, COMESA Centre, Lusaka=0D ----------------------------------------------------------------------=0D Faster connection, Cool Price, Internet Access for K106,850 monthly @ ZAMNET. www.zamnet.zm =0D =20 --------------Boundary-00=_ECJKH890000000000000 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Hi All,
I am trying to implement Ipv6 in windows server 2003 and Unix. Does = any one has an idea on what I should start with. What are the major diffe= rences between IPv4 and IPv6?
 
--------------------------------------------------------------------= --
Albert Zulu, MCP, MCSE, MCDBA,
Customer Support Specialist, e-mail: albert@zamnet.zm
Tel: +260-1-225358/59, COMESA Centre, Lusaka
--------------------------------------------------------------------= --
Faster connection, Cool Price, Internet Access = ; for K106,850 monthly @ ZAMNET. www.za= mnet.zm
 
______________________= ______________________________
<= A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&lang=3D9">= 3D""  IncrediMail - Email has= finally evolved - = Click Here --------------Boundary-00=_ECJKH890000000000000-- --------------Boundary-00=_ECJKMY50000000000000 Content-Type: image/gif; name="IMSTP.gif" Content-Transfer-Encoding: base64 Content-ID: <2AA2DD4E-00A8-4716-85A8-833ECDADFBA5> R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= --------------Boundary-00=_ECJKMY50000000000000 Content-Type: Image/jpeg; name="jag_frame.jpg" Content-ID: <57E79BF2-3220-486C-A474-DA1543D524B3> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAKAAA/+4AIUFkb2JlAGTAAAAAAQMA EAMDBgkAABpWAAAfQAAAQsf/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgXEhQUFBQS FxcbHB4cGxckJCcnJCQ1MzMzNTs7Ozs7Ozs7OzsBDQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQU HSUaFxcXFxolICMeHh4jICgoJSUoKDIyMDIyOzs7Ozs7Ozs7O//CABEIAYkCPQMBIgACEQEDEQH/ xADcAAADAQEBAQAAAAAAAAAAAAAAAQIDBAUGAQEBAQEBAQEAAAAAAAAAAAAAAQIDBAUGEAACAgEE AgIDAQACAgMAAAAAARECEhAgIQMxEzAiQEEEUGAUcEIyI0QRAAEDAwIEBAUDAwUAAAAAAAABESEQ IDEwUUBBYQJQcRIi8IGRoTJgweFwsRPR8UJSAxIAAQEHAwMFAQAAAAAAAAAAMQAQIEBQAREhMGBh cEFxgPBRoQLhEwEAAgICAgEDAwUBAQEAAAABABEhMUFREGFxIIGRMKGxQPDB0eHxYFD/2gAMAwEA AhEDEQAAAPVA+9+NAAAAAAAAAAAAAAAAAAAAC+nPTmn0+nl6fHn3+WdPJnqy7efIpXigGAG0im3A 05gFgAAEAxUWNQapczVSZlFkmkCAuQAAAAAAAAAAAAAAAAAFAbaGSoqjM74xrjLN4gsWd87z6q7e FZ9nZzQDQayp0HPGeh3jhW5OuD2UYz1TefKdcuPMdCsyq3OkVQ9KY5t7nrceueHbXn6eNHs6dOfz j97zt+PyZ2x9XzgCwAAAAAAABQom5GrABQbeiXTnom69Pn2yn2tPJ6fG09LbO+Xl9Hgl8sv0fVx4 K+j4fP28Je9wdufnLaO3OC1UugTdZqNZll1UQ9Lzec6s2cZ3q55Z2nWee9VpmUNyW5F28rzrqfIY nf1eZ28t9GSvGvn+f1PJ9/wgDpwAAAAAAAuNJ10rTo5fR87P0eLaFZom6nSadzfo+vxb/P8Abny5 8vbn3+j5nXy3l53b0dM+d6++nDpNNcui8j08OmPF6/Uvpj53L1fO9HHN095Ws9uNXt0X5PRy12Vj WWqMaI0FyrQTy/N+k8H08OWdp9PDNWaQ9HEdWOmdGeyzcaurhdS6OO/M8f3vF9Pychrv4QCgAAAA CpudtPT8zfl9bfhual09WXZNKhy7rJ4003Y2nm9Hr+R3efv3RL8/WiZqtImNcqzs4OTt4/V58qqu mH2dPX5fRw9rnl0ZEy7GDOgxI1nNVvwb8e8cj3y9PDnWs7zLbF1dHRw7eZ3T0Y1N1XPc56ynjeL9 h5fr+X4+PrR6PD5Z15dOGJcXmAUAD0yqduhl8/qQ7qbzejdM3prm5nuT5+vhHVh35S6Caess9lHD r1z58ZvVzRXTG2nK5e9c23Pc8WmfblLb1nb0/H25dfUjE49dZzVjINS652m88+dm2c76znp3Xy6e Tl7Ss8Z+otTK55ZrRZLeO1cjl9B+eZ1rzvHrx6q4nOd+b3T18/lR18fo+WAb5AAXGs1W3Lvj2dN5 bcvoo00z1vvwfn7a5RkYR159uWD0LI7eW869LPn5+XR51PbiAWAM0nTo59OXTqeNcWfbz7xk6NQS QxCAFNrfNi/RXHry592Ms3jlqd1cNZvZOcTW/Mo3mC73jLbfflvzH3KuU7ORnjnrz68MNsK1nn8z 1vM7/NxA7+EAAAe2Guenf6vl+p4/uN1lx9U46b7zyd2Ouda82zzrin1crnkvcXLi3y6c4KN85KCS gdvXHTF1AD6ouoXHrwrfLvxgo1Jb0iKCXa+czroWJF5hqG2Ll6csyV7ZdMta5nLpaAVIDj7OfWOW Knv5oL49878kn0/HAOnEAAAKm5erv8fu4/Q7iNOH0+zXlz49+uJzOo5BOx8dy9OWMaiml05pUIhg hgqTGJyjRAACaoAExg04q8qmhVKCZSY4TGr1gzrR53NNEwqxNZ1mIsWmfDvzdPkzh6vkgHbygAAA AAXKdy6eP0drh8Pp3IpactdFBGilDQrKQhiBiBiBuWNy4YIYgZIUhDcsolq3LhiBiRQkU5JaJC3m 1uDBOhwxyFkcXfjvh5fP14+r5GA1vzAFAOB3pO2HTe/P1Lpyrl9HQzM9NVCNTITWsdYFCSyHVpEj JEombNFCZ1eLNXFTbJqBWLKqQAQZJQ6WW3LJSECGADSGSxgNHVyaZudXFCI1HKjXJ8XZjvh5ZU+n 4wBRcOXo25+rl721Oeuqi4qs3DTaJMYlXRD0JVvk8dW2mqQpQCyVaEVSzVTNWhzQSK1SRJqmTSOp JqhzKVFim4SnAaQrVUpViodZ1LRKW8tIZxcnTlXJtx748ufSvR87nNs7idM6s7NMOnj71ReOo6rP SNE5SNVLmbQkVaQRBd53NBM2WgBwktTVjpLOrMizoOW5eiajPRqZuVNmoXNwMmaopzTmBLzRYXMm jx1V56VLzHVNxzPoZjpam0qS4rSNYyLnXOANTn4/X8/p5uQDv4NenhMdvRvy6z29evI359fQvy9p r0FxmN9lcNL2nE5epcwdJhRdQLoopUtBEoZrcmdyqm5bnWJXRhNZ5p9ORrlvKF8+d6Bos05miaml c0gtFLmKtRk1LcKpc7U3NmMM9L4p1ntz5Zue2eJaz21wM6uHfl3y5gPR89DCVSJbKTZCbAG5EURJ QqpBd5GddGvE869HTyqz19afNrPT1n5Lz09bPgqa69vPpfTPOeOmqyW+e18xG85KzqvimO3TzEel Hnq59OvKmz2ebzZuPRjgeufVPMax0TirnSJespUXMjKkYSqVSrRIwAKABDBFEJsROiE2CbIkoVDc IYCoEU4h0ElJZdIBkAMStKlQiVCobiWFJ1KIbJVIFRUtUZulZJTIGyRhKualUqU3JIFAABQhsltw nQTSqAZCbBFKUCyHShFMigJuXLI7JStSWyXTiHLpVRLFqzFisouJWKkkqaTaCdM0aV1M6SJjJadS rlKi4IKWkq5TMDQaChkpSoTZANQqogGKObiacyplEosG81VztETUg6SxauM6JDRpYS1QnTJbSYlr mF5bGOl5FE7GGsNMx6VjWe5nc0ROrshKiS4sSqbJKtcs6jWYA1CpZbHmg0tqlLNJjqLgKUtTOkIq FdBLNLSIVIqdJlm3lVoIjUFztgZb5k2BDepk00dFTeDbuQ1ylhxvY87yNMrdkxvmBOxzu8dZ2UuW Lm7M2MM7Kyz2w3iU1rIAaVJnWrhS3URGsmizqpmlVkTcVEmkLWemJpM6o2RNOs9YJ6ONevm1qWOr PGamHeufTz7PHXmYa51vydU3nDpHUC5q1ca56RNZdHPtY+bZkj0JxvY5L2xs0yW1YxS1kedJaGuL Zc1zXGs5gbwADQFSBUgab41jfSD59cx1ZNJxcOZXEPWarCbN6x1zp7Ss7nQQKEmq1xmsNsujWNcn Gembl65nXlWd5b81WduTyx0zWuG+e/RydmOmWWuFzWmG1m3FpvNce+O+sRpmSmfVx2ZrPPvwe2Ol l1i866DB51EOevIAsAAAAAAB3neb2QVy7zTk0rnUVllPXlak1gaDo6vO6ufXokXLq89kJNk3Oi40 aF4dmGd4Z6muc7tzea3zi+Rmsm2rzoSzmt+fqJcJS3ztTRpJmsjx1ztRlvOaDrwGgKkCpAAoAAAA AAAAGiOrblXPr2YTEtzMbwgNYAKAC9MXnXTXLeN7PlDvXGprs089HqT522dd145c+qhmub7+S89K w6eOzTTLSy8ssrnorODsrk1x0eF8m+W5x315678Nps+eTTJreACwAAAAAAAAAAAAAAAAhiC5QVIA BQAAAAAAAAAAAGmZHp7eP2cPV0TOuNyr5bJ50u/lNMzWXUBpCDbJEumYWAFAAAQAUAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAGmZm6GYtSFgBYAAAAAAAAAAAAAAAAAAAAAAAAB//aAAgBAgAB BQH5WzPhXJ+Ofw8lsakjWSSSSSdlrQSzMV22vktaD2Md2VmW4S7HK7E3snSSSdr5IQ1pXlbmxPZa W1UsuU4VrzpVwPsZW0ob4yMnspZvY9W0U32Ui42RrbbXS12NzpBBBVc6uw2yXpS4ron4JPZzOjG0 zEgggWlqkEaQQeDIzMzyQYmIkQLgWx6SPkgnRirtyYm9rMhMgxIEiR2MiWTpTYy5ySkPTIli2c6N 7oRGx7FouSqjbZaQQQQR+LBBElaxub/NQtkjeyB/jPYtj/wESTo9J+WPkkncno0YGLMWQQQR8b+O DFkMggXxwjFGBiYmLII1hkMxZizBmBgYohf+Fl863Pa/iXyR8L2MQzwPREax8UCWrX4UfJBBG2DE xMTEjRi0gggSMSCPyXXRSJbI/N4OPwv/2gAIAQMAAQUB+WtZF0S3/OPqY6xpBgRsgxZhYxZDGmvk gwseux67HquYWPXY66tC4J0dZPS2LpQ6D6mPpZ6mKgqpaJJmKH1plupVT87oGhVK9YqirJ6xdaHW oqqcFDpGkbYMTFkCrBBBBLEzydih7a15r18PrRiiCCqSTsJjUirGj5MBqNEuYIWy62IggSZ37qSV Y3JGs612vRV3N8aqolo0d3Q2PqZjspZIRGkGGxJmRJJI3omTrJJ5MTExPBJJkWZJakl1D0RSxVkC 4JI0Q3txQ0t2JBJJI3oqmJZEad+yrU9bTRyLTEgeyFoluknWRbLaWaR2XyeqOq/JJJJJP4sklrQd nbO2Dr6/zb1lWq9io2U6iqjWUSjJGSMkZIzR7EexGRkZGRkZGRJJkZGRkSKyJJJRdStEUsZszZkS ckHItkEEfFOyUShwSXsh1ZAiuLIRiiCCCNESSTrIracfDBiYkLWFpevIrwe09qF2o9iPYj2IzRki UcbYIJEST8Eozqe2p7KnsRmi9l8cszsLtZ7T3I9lRdiPYjJGSM6nsqe6p7ke9D72e2x7LGdiX/yy PyGtI3PSN7+do8njYtq0g8kbnuW6dyP0IQ4gQxHkWj8SLSfikb1q9I1ga0ghDZBJD1/Q38kkjeyS TIzMzInSpYUDsSSNmQrGX5NbaOEN7J/N5Ofwv//aAAgBAQABBQH8y1LVEmx9XYh0sli/+BUU260v Z2tWXUkh1Td3VIhfBBHwQcCSMTAwGqIxHVoxszDhqH/iIyZJ19kUffYdtkawQRzHEcc6w9EciqRq hdNmvVVrs6aqqoPqtFOq9q9vTatrKH+TBBBgyn8jsr/zuhiYmJiYkfBBiY6QQQYmA6oxIMTjd02V bcPTgxqJItVM7nD7UsvyEpOv+Xh/ytHpadf522uqp/R18YwRJTpvc7f57daxI1ggjWNIIIII3wyC CCCBFe2Eu1z7WKzsLS1JO1eu7ifkS0fwVUvr/nlqhgjFSXtiu3sq6n8nFuD+imZX+TrR39FaaRug tS1SCCCBVZbrsjGDBlum9ViQR8VHzkj2GR/TVtfJXyoY68WpGkbIIP5uhEJK1rK1+9z1Xdmf0K0F Ou1zp6fXWBDP6HLVWz/q2db9d6beuqdsUxdNGW6Uzr/mqivV11cIaTHSrOutS9FdX/kY6tPf19cn ZTFwLSRHYnL8/HWEdeMpVZ2dbe9HS0qu6O3tk8vrhN9qhz2i/npFKKi1t4r0rGtK1R/TRsdWtYOi ktKq0XwW5V6tOCCNIIEI8kEGLF0WFWFd/a6WTTXyI60nXtfGkba2VVmxudJJOt80sSSSSOvM6X8X 7OypZ5PStLMXV3VVK9j+B6Sf04wqNjW6nQ2Wo6vp64r6a5OiZBdSv6E7Vm1bNSmmviSEZuHzrGkf AkJYujOSNMkZIkktyWVmNcxp0NKmskmRkZGRJI7QrxYVoOXZ6QQdPXWLSU85InVjVWdvT12dv5ZP V2Vq0Y9bLVS311ggggggr12sYNEbUS2dVyUZFuwybasVbMpHI20rLnTqcNWROr1kkkd0PsOBUtZ+ rsLdVkoIEijhOw7iuZo9orIyRbscu5Wyjhp0rF8U2kPdkxCWkEEEFa/brWNezrXYu3rweylHZ/8A XPTA20TYkRKQ7Sqv6u6Sdntra05GRkjIyRlUzPYh3etKZFUqqTyYpj66t361j6vrk90vSGSSzkZ2 b0kxCgR5IIOuiYlWPA+2C3L0gg6camaLdiLTuq3HLK0bfqcvraI0Q7MkknbDK0ydupIraDJsVrGT JZJJJatW4IIPTaMWKstdTbtWpZMiDyJKLVl34tt+jEqzWE6iIF12KVaH2QO0qtHd26mh1aII0SMX De+ljJJ/Vk1j2VLQ3A18HWk7cELR9Y00SzNiuxWHYz1VGyvWkIvDEkiRuWX8CTZ2LjtUX3LzXFWS K0ol6pOaJ9jetaxWYLGLIK0k9TLOFvxMLGLMSNOtIvVNPenAuw9h7D2MyeiKtEos0JSVpIuqp4Hs aH5bG508HZ2JVs8nvreF0PMUGTLWkVBdRg6ibZDZgtHREDsWc/AmkZobT1o1DsZF1tx+VFWZE7rj 0hnZ2os238FaydbrQpdGTEdaaMkWcpODJGRkiSS1uH+T9Y+BC2OTMzM2ZH74qrdrZ23U/DVIbqdb pBVnsZlzXsUNnOkmTHZ/mN/DImSSedknEXtKv2u3yVrJ1VUwhJDjZOk/5dnCnY0dtbS11FsfixK0 hVX+lOnb7Iq5psupT6ubKiHG6GY2MbCr96V43SSLkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkknZ Os6SVpl10tVVna2ztze6GVq2esVGhIRJJJJJKMkSUvVVTPsckMhkMhkMg+wpHkKSRIgxYqsghEEI hEIggSRiiCCCDExRiYkGJiKpgzBmLFwOWQzGw1Y5OTksi3nZU505JsZQ+W1Wx62Y1J6UZdZJizBm Vke0Vqk1jgTaJenJycn2IZDEnpwQSScHJySiVrOs6RrBC0hGMEkt686YlpnnRouky8ZbEIq7DnTg +pNSKMxRBBG1Esln2P1vnRfBLJIWiIORbZQlJwSTpnBmZHsRIxkFoi13Y9Y+uR0rU+sirdi67Rgz 1nrFQwMUJIgxhwYkIhEIgjTjWSUTujXjVnKJJ08EjQteB1scozJOWQNWMbEHg+rFUVGQkN10hnrq NIhaXpZrD7i5OtnJyIxsJGJC2ckM5PsSxWJkZOvJOsEM50ixVs/WSHdGRK0jSNnG9a/UwqzGpxpJ JI4JHkQyLH2IOf8AsaK0Ot2ZnsqK9SUSIyJekkmQ3pBDMUyDjXg+unOjENJiHyRUd0ZCUioYkoy0 jdwQRtl68HB9dGNaNoWv/wCjTIyZnY9thdwu3hd1Rd9D21PYew9jPYz2M9rPaz2MzMkZE6tDWldI IEhIgvUjWrRadEInZGmEjrAxMlGaMkZE1M0j2ofce1Huqe6p7ansqZVMz2HtZl/934cszsLtse5i 7hdqF2IynStlEo4GSJiLH71beiJMkeTwSiRMdx2R7EPtPcj3I9zPfcfb2GVn8fP5fJlYzZmz2HtP aj2ntZ7D2j7T2I9iPZU9tT21Pcj3I9p7T2M9tj2XM7kv/Tje1vjZH+ZGyNFpEng8kbo42Rtg8C2x ouSGcH708/4njRatEE6xsjg/R50ejFpAiwnAzxp+yCeTnR/hxvjZwQ9HqhLTxs+sECQ9PA9OWhsS ZaNHBBI0hFYl+WedGmcM8bYa1fwRrGvEQzwIZEDFrGnOkQSIkexc6RGiekQm3D5IgQ68IXBw20pO MYLSVZGkJ1jgmSJfJwMggkcD4+GNi0g50S1SPAhLWGJcfvy404EOSGYnEQJIso04Ik4RjpVloGI+ uMDiF5fJyUbmy5UoVoIrYaK8EJrFn7OR+B8/CiDwSQeNIlqEIRGkDgWkaYiqyVo2tOIIJcGIniuT wQJkurt9h0EoENS2oKqU68QOUpctyeCZ0YiUOvHIuSefA0S5tDI2LT9yJawRA2VnT7HkrwSOWVRY SISHInJ4JbJUWRVSW4dVkoIRPNlWMbRVjhnMusCcHDIHiiWKg0mW40qoMrIYpJLVSJyJRzDmORWG +EeBohRyNH62yeRQMgwjWDLiWIhk8aPgyYoRPOkirJasE2FWsN80Tm1UizF5/wDSyYkjgraHLsWU OBwOlVXE5E7DRKOtSX8iUKqLPiCBvhOS0p8WOWOCGhFlBOmSi2xaTpKE4HaRHg5EuaqBuDJkaftM fnyJEobEJstCoUbK1Vr2SRZJr6kI64G0SjKCSi4dm3DhHhklS1ZMYM8VwzFw6sqsa5yVWVfrGJk5 8p8EwNoVuE0TI6ENaPxs40y0y0T4UxnzwO0vWC2snA5PJDRPAlUV8RNy6stjBW3FbNF7CshwxISi uQoMJLdbS50rZEKP/iWhlW0V5ePFpngpI05s/rVVLWG4XshclbDaK4i4P/Vv5P1LKVl34dYJFr+m 2SOyRlLXnCDFRJKFZlhSUdmOrZiV4Jm1rScHBRSWqzkVmirkdubJYwytGxTQsmy0zV88pZWY0rKG daZFmLJis0X1RDesjs6p/JJPEpKZKogTOEW7IH2SZGT0TgrJkyUJmIxMbRWzGmYuExVRZkWRyJ6W qQV8N8rRWaS7T2DlvKiKzZ3lCtBVJlmkYyWUPJItZWH53T8y1gs0ZstZstvq4VYY6lOuS1UmoIQ5 Esk6spQyrQuO4rVMUytGhuB9yHYTK1lSkK1WNFetxajh1aIscpu5S0q3l8Inhv8AGRS3C4GcHA3v rBnUyOTJoVrEjsjIyRbwmkTI8WoRAmysl3y1IkUSsN4idWfuT2i7LIfI7Fbw3ZNrsshWWVmpd5Ha V+P4MucuE50fndJKJRnUyRkLsaM2Zk1E6lXQrVllYWSFJEFbNF7UspUu6sK/rV7uz/dbpD7FY8Ct JZsu1ovDbZkWZP5LYifrPE8fhVOq7iE21DkVWzG0WtA3OisS5raCzJMuMmZuP9eRNtKRVMqo7O3l uf8AgfstCu0Z2l2b/wCVf//aAAgBAgIGPwHad1xJbrExw5bT4kmYHPWSskr49Rv/2gAIAQMCBj8B 1jhFh0gwa4QQ0PhuGmBy0Q9uz+dg3pVCS4xo4kN47L1sW2EKUcDxe7tECXPdWFf1dmmELwaPtBCO DPzXmkk/PmkCWFFFFoQaUel+Yvzs7iQWm/8A/9oACAEBAQY/AeMlBkkntHVIU8/0Em3MXuVI/wBR Oxk3Ebkermh5Y4XnWTmpFMEjeOZudoMEJNJwQnMVVwNxzu3yM/H14iNGUc6Xepe1tl/uiir244p+ 6kI5KMYIoxCCKuF46b37efIjVnT9VXq/OixnnRO1EncdXUdF+WjN3uRqyjcCqpO/Ty140fUuSDoQ TTMU9qOTK2eRA6Z2Pclsn7UhB+6V2HRJpJKEJAyntX5DLoTgblc7T/dNVx1X5EkctBnnQZLVfmMi MlEXPQmx9tRXzotyqzE08k/HzO704QnVdRe3Q6rc2jBI61hHpMaaEDYufugb6D81PUTTYZY7nhSc 8xPsTqNxGxuliImt6SbX5qQOuUulEUV0PYrbH/Y93/n6U3RyFXrH8meA9qOToNc61xY+tFHVIsas 6KsN2x5jvroMbKNm1kM+ZCmeKak0diMkZ1na/Og1Xtfno9KNgY31WI0XSz9hr2IFu2MmfsZe/oRc /LSczSNKaRSCNGB1zpN9k1Hta2TYbwtbdh9DEjryq1JH5WNwj8f6e3JOkzkXN4o5GNxu366TkuMi Sn7+Muoq9/4phBsJqbEr18a6bHPzQ9v30sz4sn+Nsy+wi+afe7DeUk5+hF+DBj5ieKumT/HzTD3Q fhofyfzprC+pyUUxoYJQiCZ43Jkdu0nt7fpq5M/azl5Cr6kn4g/I/InuNyCF/Yz96YUwZbzNyIM6 WaRwWbIUwpKGLOZiySL8krXn9D/kS9G0PxMcFgwYuwTp86cz8rJHGRCVPaSs9DpSLtjPhOTNm5mx +ZCqSr2YJnzsZIPRTI3qMvWY08kkamdXGpvTFcXZs+NqwlmaZ09jJGnmzBjjMmRrPja/FcmTKGUO RyORlDKHLwfNcUyZMmTJkzX1fGPDcWRbmsJTJnw7Jk5HIyh+RkyczmYMGDFMmVM/0Cf9HxSCdGPF Otzac6PXwyazfNkmatoyR4RFMVeyCaOMg61dCa9CLJWskY4eeDZCSCaZqzTRlo1NqupBIwlIQmvW j1e2NTqPZBNr6DG6j0avQ6dSBzJFPdSNCKxR6YG3vdKQulJFJIpJF3SjGboJHpFckDqOYWvKjCLz W7EEEm5gZjerKdCExSIJtbQcjQjU2J7vdRhsDIpmjkygzUhTYcxRiVN0NiSK9TdTYyStPSzLuPgg nIyDWZoyZ1ko980mmDI9ZIHHUj50YgnJJFnQ6XPkdIp7j9qwp0GMKMlOo5NJNxydRLJsak1yekTq QSlIHIJrKEDWRoYHYmKIqr5ITgjkSKw6K5gwOw619XbWD08h9ZBrJIuhDBEXxhRxh6PX20ki+SEo zvSeYyUhTKqNiyLJ1kungJWkjM47MSpI9MEoRZKEW7qOqSIdBt6bj8TGlODnJFmKStItiyCSKSRi jJd6cCvHH+ejgwfj9zFkmDmT3KP2r6kriv5J6jNHQ6nQdDFkU6oSI/Lj04NvS4yowyvYq+r5H+1Z HN0IpnFG8ZzR1gye1UX9CMQP+q//2gAIAQIDAT8Q/Vov4iiyZitYh9C/quUlyyCP69kz1eZZLjTA wgTR4v6BSV8Ll+GVB94E7ZfqYgV6isPrv6QOY2XcpRIMdKWkULo5SgFwfNwtzLmEA8yurgy5cuA2 nqmbEpI6HnT9TqUMuJfhY03DoUlmBBIdxMTXglaI6SgVzLlSYriyNFXG3bBrmW3cuBdQZcuJTGIO MxScbMePt9aaQUly4sp4ahvMoJUpYGZTouXLCUV7iKVLS0IoDLVzLlx7rD3HFeAu7hhYxOA/Zgff 8/xBvyxZcuNJbYgKWS4gMwarh7wBG3EcsQ14sz5q9S3UO8aFxd4MQfJKYxAEpKSk+cA8Xybis8sE cRBzLLEBuA8S5mVAu7h5VFxHgnIJfEoleFRcvWqmGspR1UYIQjTcXiWrUEcw4RPcX0BlrrqFsOvA d6cQQh6xZxDR4uXF6Qv4iHuU3cGyXFm4wp1AqJcConiNu/O8KgcDMEfQ6mG244MRaqw4Svifoa+l PpcyvFICHdNp/H03L7j5qV+rX1VKlQhGjEdr9D4LmVK8AhguVKJiYlEqVMTEsmJiYmJZMTExMTEx PVhCoEdPln2SohuZ/sn3ZiWzHUTxXm/NH1MPOZUplMLvwWA1f3lIywxWPtL9y5bL9wuNyvFeaj4A z7R8XKgVKuJLSfHwtnuDLeWfeXA6HxbFRLiPQy/UV1PjLSmZ8X4Z94sG8QCJIZjjyyzvxU+03LdT 0MOqX9xcL+T6b+lnoj0REuaYueiL6l7upT1Kemehl3E9UPVPZCvMB34PVADj+iuXLly5fi5cvzfi 5fi5cv8AUuXLly5fh+i/FxfqPAy5fgl/Vfi/D9K+Liy5cuHfgYy7mpuXHs8X3PiWeLh4fpZfjnwv jM3ucxZcE8KeP5l9wYuIX4HEcTZM3HwfUpfG5cfB5YrmlubbmoNMzMM+PvLg5mWoNEX95og3uahK a8Ygz9FSozF1PVeDcrwSo5mZUN54jUDOvGWInUBuE9PIZd3NJ/iZP/YCMTwD6kmJctBqUeOaeoOa 8PcXEFvUtikF6gVmLbKOYIa8VioGcwIeVSv0GywUPoJcX1LS3i0OfxKXvwLga1URr3DHO5Z4xPhE ZQzGdSBX6lSv0kuVN9+Amj+JREGIMAqoAgBr+se1febQrj+h/9oACAEDAwE/EP1VZ7a/7LEMFZrn mCXl6ggpPvOQP3le7g3B94W02f5ijjX0W+PnE6y5704sWcGZmq1zaFfqW9fmej9yf2kn9pImX/Mn cV8s9ECpImFO/B8fxX+Zc6ewv9oLm4Avvf3lw4V3zAOHEeC/2h1WXYMGwQA0QzM2YLYBUz1WqzxD SPf1BDE98ytqK7MTcjB+8MyhcvYCBY5cIJRHA1Eli2KLoiEp1KOvCMqZRXU5Kl3iDbefcpKwpplE 7IgKZf0yyf8APqZDisOZdof9TqVNBWoQd4AomahlRliJSFlz4LgQHOZca14uBA8wuupR1KlFVBKQ lSpU9ohl+IC7ILRO3H+fqyUZGVGpYh3828ZiTHi5ZHUv9pUOrvPqBUuXLlzUlARPGK2ENyjiAiRA zPcPtFGzJFnJ8af3qIjT5RF4/iZFkMpULSlYcxKa8AriBbjTiKYQWMyzxWVKS5ZKdx6zKgKzE8Mv 3FRTLS8t1EolNJCGn2XDY81zp9OIw6A1slgQigzFahV5JUwbix8gJuHJOAzMtl+DLU+UeRMNw8QM q9Tsm0AIwPqA2cP0EC4pu6v7SoNOpgMSlDXzEWPtKEdvkh2RqWTFVErwHgUtFuDUbQEKPIs+I3Bb VReoOPoNpi/2lNNBrv8AeDbmUI8p8fF/Vj9FQxDxaMVXF3k/7ExPz/r6ROpWinTADzcv+kuX4YSV vcqN+xr+/wARK8Aui4IIv7+0Uy3sc+oYrxZPcQuyCPZPZ4vmiXD+I1WC+0OYSF+GfNPhPhPjPjBd S/Uv1PhPhPgz4M+LOQMTxf4ifce6XRb9v9RKU68Km6uL/f8AsxLTUt3h81MubZVwfuYr3+0o8P5l Exh8R0Z/iAbP2JTKY+37wMASr8JLqWQZZLIvhYzBLg7vEqYnwlSkFeNxavJ0RYhi1qpS839moAG3 7ocahAU4IlierlDiKdMRxHybg+p8Z6YpzFhOmAzJ4WNMMQjb1PV/LPmQL/2V8RA5nRGOoZ3C8NBS DTsk9hDsnsnvIcfhuEOPBE9QtmNS4qUjSFpcuEp68Wdyx5lHJEuSewi3JPh/MJIwdN+lcC0sC5g9 kC7IRu58FeVZPWnrfmPQlXCAc3HhGUaURr90eoi3MU5Rbafv9Ny/6Ovpr+kqV4qVK8BKlSvFSpUq VKlRJUrxUrxX11KlSpUCVKqB4qB4qVcTifESBeGVUC4cyoHDK8K7lSpUfoqV4JUqVKxAlSiJUpq4 D+YHcS+4HJBJZK6lNeoHUSiBmUlRpuVeYmZiBK8D6bPGtSoepUfUyzEPcofniVQAzqYCVbKvMSwX HEoJdwalC4mM4lRFJUYS8wy1RAtiNNZmyMxcxKqL6Ll+Gatlc+OJcoQzcBIAbZbriJiwi19RdL8G hauKnMXBuJL8mJ04nbqJXGK/eDM79wUKfnEUS3EGUi/UMyyqJSoty3xwamdxVXVSoDqCughVQ5Nk Q7gtcRDbUso6hUtYoCmLlszzrqXt1F4cxxivA+Ll/oFaiLPc6PoKED3KdxEKdQu8H3lg1vwqcxF7 G4rZcNzJjUoG89QfLmGSziUe/mOTFv8AUuL+kNS0tx3N6KjK39mWvqCkFG4rdxTXqKu/6w2q/tNe ajfP7/0P/9oACAEBAwE/EP6sFQC10QIahsPtFwFOgmHS3Rt/aHqmh7goIen2/wDgitaN26MsxhMU P2QhWGQqV+GDgGKWe2+Yd4DTnn1CQ5dmjqYMnxzG7B/MQvX8yzqX68YgMw45nD1FXVfErGfqBdFy 3OPmV2X4IrZ6P9kLu8T0v9pfkEE2nOj/AHEOjq7ZsNMNRS5ZVN8v/wDFdMKK4NfaHPnuDmq8yg3V MRbivhLi+olbJ9pbqXwuKmh1BNGXLZxr5mg4zETwJoYibKgfX3JmUpOjUDr8wgCEFw4sm7idp8Yi Z/MZfYtVtnKUOU67iSykIuLC+4xZfNmXL1AUN1/UVK8hf/yCav8AEApp4y/yQy7J3QRf+yA9v2xL ev3l4RtKolzn6bMFywBAPB6ly1hr4jhWcQAetxBSYlTQ+Y40rc4ZqvWZYeLfvMvP0Ewgs76lDqDG DRGxTLm6IHUIzeykyn5iXCiYr4+wisk23TV/H9LUqVKl6iWdnREAW7eOpgzFRk/dQVYldEpfHGJZ 04rYwapb0EUr7zglGDgs4emfCNIkr6AEDEIryEHhqpUSJKiS53j4+qBRv8RGFfUvl1xLm2M1dHMI TbM5GvRpxWYJ4jK+vZ8S+1weHj9ULdcYgItmoKfNQJUCBKQ9whWuCUgOOiYc8yurHuATIRAmzoNF xtbcvbKgchjpXEw1UoIKbpkPmAbA06gOVmrQEFdMYplSpUCCv5ipTeniWhBBKNF/BMCiclxapKem dBcILB1cVHxJKlSoHjiU+KQK1CrDcoTKH1g4OX2/VEcuM/jMvUrW0r9ruFcTmsRq3yWRM+FQJULQ jEyrR0QwSXS/T1D300HEFjV3MhuKsE5i1bKYtk4RKHZlrRMJgRndQnDPaK0FfULkrujoVXrm5UqV AgDgS2i2fh81KdT/ABcrgwOsM74McCUwnaAYAK6mAAnUtkVeyDHFbHzKL4mxd7RkFJhIkSVKlSoE 3CK91UwbKyRtBmCjiDMbiA7xArBX/gwUiqp0/qWC2SNJfq0oKKmmLLoLvqISpUCAwIMzGhUZzqJp zLyOJUpo29w+WDiWK4MsYQtXmHQqXmXFhFC1ZG7B/CYEjjxVN0x0PcRoUuaZUCEZg0cO598ywC8Q BuPrxz4qUGuZcFoNNYYFfNcYXV0134VBb8Qmi4uFojeRvhctdGfDNkt4+ZaNTeJjEt2nZGEucFm7 OkU2eb7feIUKav8AP6ZTOEvEWYqDkf6lSvAIECGJSD2Mb7vHUsXAzL4/iWd59RqDA8QKyVWI4fRr Ar9uIRiJOw3EMCuPiP8AaJUCI5LdTGAOd5jAmj3KD5ly5cK8WRQZSWJi7+8TwxKAWRj7RDXUqETq A3iE5DquZy1fCFcL2Xx6mRTMo0ZNMAFcS9NnFwCFWS0jx9pYvcB5vcwzQZvXT/uO0Kf0SpRkfmDm UUYiVbKgQgPAIHirlSoEuQ7i2GzUdA5NwtuHeJXMLNyzFwN0y3EuNwChUK0deATZAb+ZvMqpcaxf iOHifCbLxG43XUUAccMRG3uAvOZXgQcsssjxAinXuAtsMzqhclksIh2XCEMcIgzYxbXEMXgN2toe LIrWB6R/e6uGK95/gXUtFY7YEUNWvOSn/P1FOO5hiAQIweQeC/spvqNkKPhUqVAm0NiEOFExYY4b lWLsYgIykvb4ScUsNSiArqfAlQgWmjqKMMcIsWKLF6goKWgJdiKm46pVcsSNFdEwYdpfwVTqHkai UxLtJchhEjD9oC4sG40vqKVamZ7uKy+8SpQnXEeBoeBD9ql9oOgh84nOm985+9QBVO/qA/8AI7Jk lEAeGUIehN8MAAGOoeNGmCYci5UqVA8aNQ2hZWipq7Rbaz8rhQEr3LGD7xoIBdTCPtF3bviNypUM SoBh3le57JS6uJ8z2RNwojHEtcviqjgPzAA0TLUSlCzpjtBjsgmoTZwxKqHCo0u0Bke40VcVYeCW k9m/CivTLVUNVxe0tWck98aoefrEwBrT3Bq0UwZjRsPQxmysRdncwhGyL7ZpGAr7SzXROBEuue5U rwIQqS24CblTDmZIrrxx5CsXAJQLAa+5iVSI8zUYdnhUSNkRLS3hcvwQbQ/iMIx29Qq3fZE1hrSz VFQ5CYtS9Qyz4aQGkiL8C3zMB5YQbFJKwuUBwQliFDvmKBr7kVRdQAYxAXc7joWXq6/xAAOH6lqV VQIFmPvEAFfxEg2+wixZk9QLrfqe8Q4PcHzg6g2CDkfkix1yY7yIJb5KlzQWsRwYZuIy2JKleaGn UOIpl1W1K7EUaMx2BUEtBb6imEp9yvqCGAWSweuiB5AXzAGBXSb1ue9gPNxLBq3fXhsalqyl3ArF k5g4HXgGpM9wugp5ZQJdfLEDUF/DxqeJZY2Xan80MxF3YP1gQLQu5WmX3ZCGgywmG2IUohJjCOWA 65lR90aKq6i3csyDXcslTewOIA39jOxX3ElRJXioFy0ELqHJGhv7eFeoMsKdMVHLzBSkqVKlSoRN NxuczI6lyPVFMxpbCptc+A8SzdEQ4iKiLtORmAYGAiIKRRbjTuBUsFW7zFH4ixUFD+8tiq4rmKr2 /oDUYOY9Ao5F7jOSvm5u64mtiLiDYrHXMVY2OfUyZrtnOfxLjOYBRTBBrgb1CmKuMGo8MqVKiSoE zExTWFTMCBohBveZRlLTTKlSpWZZpUqIX4BdfoW+HTKZ6wbBOY0/ExxAxGyXckF55lXqJFpRANh3 u/8AEQrt/RRoNVmIqqvf9sGVVX3/AKj7oncFVxcocxGDTj7Qz6QhUdw7o31EkCMn5iSpXipXkmPB LfFxb8V9BKzBqCsyn6alSpXhas7iy/tM8MR2wQ5YviLRLYxTB1KuH4YQlRc9B6zOaa3y/Of0kCmq 47iHBPz/AMhiwoz79pgCluAbLZgoIraAR3LG4KMQbgjUx+oqKvivNea+g8X+gfQIN1csdV9I8TmF QSY6lkrzEsQW8Rw15cqiJNSaisQpqvZ8kx4pKDmv1LRaBebiA7HTrgzXUKLCXC35mTGpuEuAD5ll /wCIjgluo/VefN/VZdS/pv6b8X9Fy5cuXLh8y3uXFRN8QtT35S4Ki6OIC11zpc3X8Gv4mUs1z+k3 CluMwxvesnuCZvHAYhLiy5cuXLlxZcuXLly5cuXLgy5fi/Fy5cuXLly5cuXB+i5cuXLlkuX4XHjk 1reu1VAH0/sKXL8LMdv06iCyvg0feY9Lyo/gzPvXv6hNC/BPY/DPY/DGA52rYcRAGqFUM/zDBLly 5cvyBtXBf4/oAAAfqgACD6QXLl+Fy/C/CuobXGl6tRgqOavfhcWLZLagDC3pxAbY1vb9V+aZhEf4 IN/t/qEUU/d/qKNv8sw6+kE9yrbHvJbp/DEZRCgODcyJSprHPE+XMq+q+5BeQ+895n5ie0nsGfP+ JbliHQT5/wCRLafe4L8H7/vATJjLFp8yw3PXLPyemcqpjxjxU6l3iIU3FcY+0oZnsgSFuJV1KSjx fxKf/YC5vEhjMMNtx9n8kR2NSwwz76f3KgVRk5pdfebK1rNjX3i7oPjUPkgGe9RhIvy362fxN+K9 OfpAtuRxvUFuyeoE959Q6H5mTJVdwQOQcmx/DLz0V04D0KiMoDiv/I1XavvAs/uMdm/gNR4iX6JZ Kf8At6lrv+UpcK/Dn+YYqgdl3G5WPouOz8AKqAZHyIjyH7pgMurnVFX5lAxPZj1fySlhqp1JOyn4 hc4JTz+Etm7YIbUBWcvZKf8Au5Sj0L+ZQ2k7EhwZg9Yg1zPaYjiWg2RsPHuWmLg3zP7LlHMvOLgz mj3uU0K6ijmhiU/L/wBgBo13cBTj7DA4DXxK9MA7LQhcInQIH3mCyj71DsbPSv8AEJRr/n6VTca0 jo7Y/Ba+dT2LyXcx8w+yaZ/CAH/ghsPugOnHZLXlfzA5s1AJ8SpuAO24lepbkGBOPwihjL3LRoH8 wvZb7hZg+8ruVGjmY3cPUJQ4zHLV/bwR/wCykNv5h6nEHoiG20F9PELZqWc/tMmswWZ/mo0e/vD1 fmU6Hw3HWMx/BDOklZ4iNZPyQBjMac59S44nvBxepRa/ZBOh+LI12j5GC6F9X/uDS7a/vqNSU7T4 lqtfDELBa6xCbBfN/wDIXbuec1FdnHN4P3mCv5EXlp9bz4JwalU2C/tL9tw+EPQfiU7JlzSBbL6n /oiOiJsLWW1b95kZblVZgyKz735/xG3BMOCDill8GfefhjTf7TJgtjwqZZT6hfcBvd/iA3BXDVYJ jllcKiCxD8cQKUYi4otc2QNVdsMx+yFvcAzj7xV3MVdMQ6qUhyj6JwjXshyJ+A/zOgfmD7/iPAwo ZLT1RORz7ZbTn+Itu31KW3yXEtL+yb/mdOdIQzij4iMGWacX/mOxoe3P4hXab94HCV1TKGx+0TFV 9pZE+GNy+zP/AC/GamgQNMuoBzSFjPDl4mfKnFIkflv9ol2X7lX/ALCtZgHUaDF/AS74K+9sx3df Nset38Zj3U+Wv4iPKJ8PcKOnUVbqUeLhYdRXhv3FBuNiofPgUeCFHMRciuUbuWqYBk4+Yi4nAlOY pqBcBBeCPKWH/sEeH3jgzg9S1pfvF6Ll5zAWMYMWM1OfUECF9wquk+8q0PzD0PxcX2noxKGMvliH gP3gNP8AqVOp1Cq7iXIfaW8T7TJsfiGeQqNzOPiVgrN6vjyMKR7iNgSxxcOez5jNCe6F8aTA1cFH qgvJmX4KhXZc66IEEdkR1KjYJYzADCiDlWZ4InZDLUDtUs4n7IBUB3Acs0H2QBArWO5RlLfc0Akb x8CLW7ljbAfbG2AJUt8S6O42RxBIVPlEPMoQuDW5durINeovg16nObnG8QRzEbn/ADAGhZfRU94L mkA5EJsLK3uNVG7w4la+VjmdTKuYD7+Ypsw74H1OWJO5PmX6P3nrC3H5J7vyhZv85Vz+c/8ARhBG 5jLdQ5ZlrwK7YJq5ZKGFmoHmVxeJ8401Oxnuh1Rjc4jTEMcMzcxeGIGwiqwjBXERthlxiL7uKf8A IW1Kdbg9p2iYNXcw05juhq1MuG5StCIZvMeMv2iGqfMXsI8xjC9mLQp4THQgvTAOCX1Z6/Dz9p9o xlQJUqVAlSpUqVKmYHpYBzBQ5IMWbiOZTkRC9wVLgnMv5RcwXiQJeJmVHGROZTAxiIwtz95mZamB VXMlMBTGCPJT8wsy3PViAZRWY6pJe3XyxPSEHrHsfsSjQsT0RXVH2ipdxRXubleKleameJ8pmt57 +llSpUJUDzUqVK+ipXMqVKgjTAsX4TcwfuA9w7pfsqHUmfH8z5fk+F6if3if2SI/8T3/AIRHsTrX 5jnj90s8Pyx4hOmiMy3+6K7T958xKlXKzKuUyu/FYldyjjxTE8Pion6FSvFSpUqBKlTcqB4rzV+A iQiJvfMC40m2BZHqASoQDcqpUruO5UHiMawwpwRIBJmYr3CVcriFSpVvE5jdyrnMp+8CnMTbUZUo +JrxWIy/0alSoQIEqHqV4ZWIJjjECMMM4hXMBKrM6NzEY4ZmEXqBZKD3HthRG+T7SupklGjcqKNa gYvmFcxFgBufy1G8JkxKhm6iU5g9xx9SkxK4ae4g9kLNOPcqsIg1XO5Wfc0z+YOavcqnMeyJ3Mm9 T4mYn1VKlQPBu4Qs8blMD7+KKtmVqUczPGpR94GJU1KxEoNzeWYCubxLPvDcQN1cBvZAGJTB43FX mY7jRr7xMwSkm9yr/hFxUNCATDADJZ0+ZTuV7iXiYF195m25YK3uKt4lEs1KabWS0rvkiXpuVjMs ZGAEuYHIxKXVyzTBQVkjT6mpWLPvNleHf1BKhAzmViB3N6h2lUzUzcrNGY1VTPEFzDEQvEC3qUHD cU1qBUD8wHgjYQC9QKUMy24Wb1c23uBWX95atFQ9nT5iZlnqAbbIutSoKEZXmVMckLiWDiGM79ER S/xEU1iEOq+JXJiL3vqW2RuVygNFJLuNzQ1DQzbBTfcyLlLgIDLFAxXpLRQYjSxNOjud3+SYRuMj WcR1jfubeSE5+J8an8w5SgqN3RKVApxK7YOCsyyNYP2iVrUDqVG7Z2IB3LRs4mVhwMszXuOUBfvK Dco4ddwF7g7WBvd3DO8wKvj3BEbXUsg11epgEaXuZA5ZCO+vUKs6iN4N6hcVL6ZQC4lwD9pxYPuN urxLrjrdTDi47ZUdSrxTPMckagWxtS0csaNDcQoqpVdl3iF8hUumnJzMgC1K5Eum+oFWMQaLxxFG HMMKvMaNXiOdk2b55ljWYEWQOCfSVKg4gv5mnuImXHUE+WIsppgW41EBfMVnVaiLTMENYjbhnI65 igwX7j/eNedcxKFMELVtgjORuUuBfc9H2iueIucK9zLLEGSFXJiDMx0lul59xF5alQ05pjZasBM2 l21qfncETINsXXB87mMA0TNWycDkxEu0d/HbKdnLw3GhelMQsvcPIz1ByjRxHEwdcQFnvZKG7OA1 AXT4lhVXtK3eIjbUHkaeJQbK7haBSqlbqZaHH7QnssN+iJa6riJ5oc6gkpv1Aq8XM1/Hi2xzCvlB OCZuUsWMwzlxDAzAiMFsCtGJpmETjNynUzKDMb51AOoAYdxTl13BN5DuJFGHhZby45qUnk5YFNaS hfHtZlS1wGyKUQEQvodMHfLBoei8wvhgtgG+5cL1GpCt8zpD1BQ126lHJ+ZRVbeAgFykEqfmWaov Q4lgpYQaxMDDYbIkbPUGFJcrXrcLWNmWJOq/lDt4h/LUzOoI6tJZRs2QR6IC2feYU7Fam7Vl4iBd kds6DRAmLLhdSy/2jXHkXCuY3k6ijWokL4ukUA5O5ZxywtOZcwUwtYYhbXeO5RtuBySVGwyTE7Ql yxVYZ9x3LjtgyrtZViiuyJgy9DMzgYI5F+jqNYuYDpx7gKFMttFQpjcqLS4AIKPySs2fcQsMfaU6 Z0G4WLNu4Xp1qKLwUx3BV5r3Ksfu4gmrbXlgGrL4mw4YF26NwXH7y2Br1NuSULEuqnqvmFKQwxrT PzBjTj1K2481M2wXcGURfaygsLA5/wARUiZO5Y4hmyMBDe4uax7g0VBvuIFEEtdTSsHUbFb7lZbs iurquOZ35Nwy1L4QCEaUf3SgFWMoqsLhZcMuzMaCnuKNkyKT8Sj4gxFXALtEIlNGkOoKss0r1EFu XBL7NjEyVqVRaITNrVcsbK9y7Wd8zAGVRt6j6l2RZ3ECmLmxQPe4V4aOiIw2luX5QZoIws4eYGSI 9kzAS5V/dg8hgl4qOgGg6jUXo5Iji4A+fcEZyVGc0Q5CKLMG1ZuFby7mboUykUo8XFVcqh2VU7lC u25S7sqU0W+iFgQIx6XGywKauW2MepmoIrI9wzNHTxMl5viIcGX8RBjk6l3Tpj7jhmL/AB9CpxBO 6fcsXjJyS+Rj8zJeVdwVaKckZWaeGWXuVtUcBrLqNYTLEtZuWnhLOINB1NUDTyxuhuWNvG7iyTuA wIZMxE6ZdyxN0l3ywLX5QVAVoC2W3TcNfD1AT/KWeYPxLJtBBTmYKD81AtHoJdVgf3USaNdJLZUX 1zMnLFOcfVxlgEEw+Ym7YvmomCIUWFHcAv8AhEDsnVwLv4S6pagsStzK4T0gy/AxYHLfBERyPXcb OzcRgqjbUFpVtDmKG1g5YanPDLsqOmZmKFgvl3GZcfzNe1OpWRw8MAKfyhGm71UoWZcREacsYrhO PoGm4q0VBTUsmVxzHfct9upbdzFNts5Qz+0tyusS7Ns+9zuEiDkgjWKg/MBtlRoIBeFDEA1XuU5P 2gjbbwTNZQmQflN9i4EdXrK/4iK3xKmC+yAqddRFTSxbCs3traNXBIH0qv8AaAOzAXBTqJLH2mSt Q3zlmTm6/eNBtXEGbWhq5dhItabrkg05gXOZbS3OghmXHqnUsNgmkFXBNwqODPMyY4D5M0NBxKBb uO9XDsIx0V7S871u4m1oOSCDo75gWb/mCzFoxCy7VlhF0oNkQY/MdscRgWwcEtMJvDyRbyu4vH6Y 4jgVgtC/EpIRMVGlwwXEViUMxXjEFq3zFpXh4dRLlfzLBlxMk2vWv9wduS6Eiugs3Y4irHXSKcgf mCeiVGCn9pSyxyVApXMYzsQHUrllwmAxbLDxAVyHc4uo1kGOSV0gJxj1FV89MSIPmJbNTAajltcR mnXDKCt+BIoYKLs1i2L6OosmjFVKLFrqUYryxsUkW3Uu6ulCG43ZBAWrrLEDYHB1KGKJmkuz8x1o ZMiRAWIOi5Rlc8EW24kt40zI2cksofySy9fMooYGBlJNrcu5N3z+o2o4CXC88Qdc1n0xWTPzKGCL g85gpyDhhcIuviKMr9gi3iYK/wARVy5iKziMU7OpYUhnW9i4zYpUb5uYNXiVlXEaM9RDTdQ5w4nm PqZcWyQgguJoIlsV7i21HunXMaUu07uIOG3qI9WMH/xGtC3kuFJQVLlr3Mlbe5ZLvMNzlAjt7ip2 hx6jSq9o9BOJlXGzL1cBpY+tECzHpfcaB7HBKK3TPuX2468DU1SoKNkG2gy8S6cQzXKz9bszVsCw TNblFHfcOUG4bxr3M+KPiZ+ikVp8fUWtDOVqjmVMuYGayRFsJUeoBxBHE1WY4ItFATULo5Zp0ie7 T3EOqbtjWipqK64SBsAHURaL9wTTvqIK09S9cgmbVwrMEeg1FUuDmU55Sl18QVKvt5iVLnqIIFfM HQ7KlGCcIigadkaqs9uoWs5ySWhT9peglNwrMHhItt/0qBzGEJvLEKlxCZ6xWZ3At6MsMsItt/Vs dG5QrY5BVQRWbfLUxaR+0VVmOe/xKpaLN5IHWPuQK8B3C8yVKNkX1cqFteSZbTHvceiX1HPcQQZC odlNamcVrlhKaSyYjqCu4zQcEvXB9QpVvT3CtHUG1ZcwnPUalSvibKujuZb81LAZssP5jLajGATC zr5IbZafmUMgIY7lqBTz/UD2qkv/ADNrv/RChcjWZdbwBf3lqYMqorSd/WUKQSehAuP5Ytly5yij seh/5L8Wff8A5BKC33mLtv8Ar+JlgCTF/vAZsMNoPp/5Eizguj+GWM/iUMZuBcpgEu3jqOWx5VDY /wDCI2vjdw6jFcYyfmc4YHHvUJD8yVWb2IzTYHMReXZO5+ZQLL+cfiIc4K/aWqV+4qxWA2WPplIZ VzzC+V4fbqEuL9X1BkXNn9ObiN9XcVX3WI5PdB9twojuOAcZ+/8ARq8A/vC21NF/7Y4BXpxUHFFm ioCo28kwigcAWKms9rlKVcGYKNm49WmzXuKK2XcwhKOILhYPtBH+oFz0c/4qAq3lirWb/j/9fUFe VgoE18ss7XomDTN3iGWEPkjFOwQ/5HdtfYr/AOCvqKq2HeJ/3z/uLaL95/m4JTX4/wDqv//Z --------------Boundary-00=_ECJKMY50000000000000-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 25 00:36:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6P7aR06005190; Fri, 25 Jul 2003 00:36:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6P7aRBw005189; Fri, 25 Jul 2003 00:36:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6P7aO06005182 for ; Fri, 25 Jul 2003 00:36:24 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6P7XsUu021515 for ; Fri, 25 Jul 2003 00:33:54 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6P7Xn5K002094 for ; Fri, 25 Jul 2003 01:33:49 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jul 2003 00:33:48 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Jul 2003 00:33:48 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 00:33:54 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 00:33:42 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 00:33:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C3527F.122E959B" Subject: RE: IPv6 in Unix and Windows server 2003 Date: Fri, 25 Jul 2003 00:33:25 -0700 Message-ID: <0B1BB7EBFD223F4B93E30A09BD3126D102E6682D@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPv6 in Unix and Windows server 2003 Thread-Index: AcNSeyE6eYJ7ixxKSkC3vahzDqItXQAArJyg From: "Chris Mitchell" To: "Albert Zulu" , X-OriginalArrivalTime: 25 Jul 2003 07:33:52.0035 (UTC) FILETIME=[1868C730:01C3527F] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3527F.122E959B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C3527F.122E959B" ------_=_NextPart_002_01C3527F.122E959B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Albert, there is a lot of information available on Windows 2003 and IPv6 in general at www.microsoft.com/ipv6. In addition, you may find the newsgroups at microsoft.public.platformsdk.networking.ipv6 or feel free to email ipv6-fb@microsoft.com with any questions or comments. Thank you, Chris Mitchell Microsoft, Windows Networking and Communications =20 ________________________________ From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Albert Zulu Sent: Thursday, July 24, 2003 11:58 PM To: ipng@sunroof.eng.sun.com Subject: IPv6 in Unix and Windows server 2003 =20 Hi All, I am trying to implement Ipv6 in windows server 2003 and Unix. Does any one has an idea on what I should start with. What are the major differences between IPv4 and IPv6? =20 ---------------------------------------------------------------------- Albert Zulu, MCP, MCSE, MCDBA,=20 Customer Support Specialist, e-mail: albert@zamnet.zm=20 Tel: +260-1-225358/59, COMESA Centre, Lusaka ---------------------------------------------------------------------- Faster connection, Cool Price, Internet Access for K106,850 monthly @ ZAMNET. www.zamnet.zm =20 =20 =20 =20 =20 ____________________________________________________ = IncrediMail - Email has finally evolved - Click Here =20 ------_=_NextPart_002_01C3527F.122E959B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Albert, there is a lot of information = available on Windows 2003 and IPv6 in general at www.microsoft.com/ipv6.  In addition, you may find the newsgroups at = microsoft.public.platformsdk.networking.ipv6 or feel free to email ipv6-fb@microsoft.com with any questions or comments.

Thank you,

Chris = Mitchell
Microsoft, Windows Networking and Communications

 

From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Albert Zulu
Sent: Thursday, July 24, = 2003 11:58 PM
To: = ipng@sunroof.eng.sun.com
Subject: IPv6 in Unix and = Windows server 2003

 

 Hi All,

I am trying to implement Ipv6 in windows server 2003 and Unix. Does any one has an = idea on what I should start with. What are the major differences between = IPv4 and IPv6?

 

----------------------------------------------= ------------------------

Albert Zulu, MCP, MCSE, MCDBA,

Customer Support Specialist, e-mail: albert@zamnet.zm

Tel: +260-1-225358/59, COMESA Centre, Lusaka

----------------------------------------------= ------------------------

Faster connection, Cool Price, Internet = Access  for K106,850 monthly @ ZAMNET. www.zamnet.zm

 

 

 

 

____________________________________________________   IncrediMail - Email has finally evolved - Click = Here

------_=_NextPart_002_01C3527F.122E959B-- ------_=_NextPart_001_01C3527F.122E959B Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= ------_=_NextPart_001_01C3527F.122E959B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 25 10:09:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6PH9u06002158; Fri, 25 Jul 2003 10:09:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6PH9tSb002157; Fri, 25 Jul 2003 10:09:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6PH9n06002134 for ; Fri, 25 Jul 2003 10:09:49 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6PH7FUY027860 for ; Fri, 25 Jul 2003 10:07:15 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6PH79gO019123 for ; Fri, 25 Jul 2003 10:07:09 -0700 (PDT) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se. [208.237.135.117]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h6PH74Vf010615; Fri, 25 Jul 2003 12:07:04 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id PMD05WKM; Fri, 25 Jul 2003 12:06:58 -0500 Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h6PH72Gx010961; Fri, 25 Jul 2003 13:07:03 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id <337NSXZL>; Fri, 25 Jul 2003 13:08:10 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B0A2@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/LMC)" To: "'Albert Zulu'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 in Unix and Windows server 2003 Date: Fri, 25 Jul 2003 13:07:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C352CF.2A16EFC0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C352CF.2A16EFC0 Content-Type: text/plain; charset="iso-8859-1" Hi Albert, Don't know what Unix you are using. If you are using Linux there is a great HOW-TO at this URL http://tldp.org/HOWTO/Linux+IPv6-HOWTO/ As far as the differences between IPv4 and IPv6 I had this old draft called "Case for IPv6" that has been removed from the IETF drafts directory, which gives you a good overview. It is attached to this mail. Regards Suresh -----Original Message----- From: Albert Zulu [mailto:albert@zamnet.zm] Sent: Friday, July 25, 2003 2:58 AM To: ipng@sunroof.eng.sun.com Subject: IPv6 in Unix and Windows server 2003 Hi All, I am trying to implement Ipv6 in windows server 2003 and Unix. Does any one has an idea on what I should start with. What are the major differences between IPv4 and IPv6? ---------------------------------------------------------------------- Albert Zulu, MCP, MCSE, MCDBA, Customer Support Specialist, e-mail: albert@zamnet.zm Tel: +260-1-225358/59, COMESA Centre, Lusaka ---------------------------------------------------------------------- Faster connection, Cool Price, Internet Access for K106,850 monthly @ ZAMNET. www.zamnet.zm ____________________________________________________ IncrediMail - Email has finally evolved - Click Here ------_=_NextPart_000_01C352CF.2A16EFC0 Content-Type: text/plain; name="draft-iab-case-for-ipv6-05.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-iab-case-for-ipv6-05.txt" Internet Architecture Board Steve King, Bay = Networks=0A= INTERNET DRAFT Ruth Fax, Bay = Networks=0A= Dimitry Haskin, Bay = Networks=0A= Wenken Ling, Bay = Networks=0A= Tom Meehan, Bay = Networks=0A= Robert Fink, = LBNL=0A= 22 October 1999 Charles E. Perkins, Nokia Research = Center=0A= =0A= The Case for IPv6=0A= draft-iab-case-for-ipv6-05.txt=0A= =0A= Status of This Memo=0A= =0A= This document is a submission by the IAB Working Group of the=0A= Internet Engineering Task Force (IETF). Comments should be = submitted=0A= to the iab@isi.edu mailing list.=0A= =0A= Distribution of this memo is unlimited.=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all provisions of Section 10 of RFC 2026. Internet-Drafts are=0A= working documents of the Internet Engineering Task Force (IETF),=0A= its areas, and its working groups. Note that other groups may = also=0A= distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at=0A= any time. It is inappropriate to use Internet-Drafts as = reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at:=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= The list of Internet-Draft Shadow Directories can be accessed at:=0A= http://www.ietf.org/shadow.html.=0A= =0A= Abstract=0A= =0A= This document outlines the business and technical case for IPv6. = It=0A= is intended to acquaint both the existing IPv4 community with = IPv6,=0A= to encourage its support for change, and to attract potential = future=0A= users of Internet technology.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = i]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= Contents=0A= =0A= Status of This Memo = i=0A= =0A= Introduction = 2=0A= =0A= 1. The Business Case for IPv6 = 3=0A= 1.1. IPv6: Standardization and Productization Status . . . . = 3=0A= 1.2. IPv6 Design Goals . . . . . . . . . . . . . . . . . . . . = 5=0A= 1.2.1. Addressing and Routing . . . . . . . . . . . . . = 5=0A= 1.2.2. Eliminating Special Cases . . . . . . . . . . . . = 6=0A= 1.2.3. Minimizing Administrative Workload . . . . . . . = 8=0A= 1.2.4. Security . . . . . . . . . . . . . . . . . . . . = 9=0A= 1.2.5. Mobility . . . . . . . . . . . . . . . . . . . . = 10=0A= 1.3. The IPv6 solution . . . . . . . . . . . . . . . . . . . . = 11=0A= 1.3.1. Address Autoconfiguration . . . . . . . . . . . . = 11=0A= 1.3.2. IPv6 Header Format . . . . . . . . . . . . . . . = 12=0A= 1.3.3. Multicast . . . . . . . . . . . . . . . . . . . . = 13=0A= 1.3.4. Anycast . . . . . . . . . . . . . . . . . . . . . = 14=0A= 1.3.5. Quality of Service . . . . . . . . . . . . . . . = 16=0A= 1.3.6. The Transition to IPv6 . . . . . . . . . . . . . = 16=0A= 1.3.7. IPv6 DNS . . . . . . . . . . . . . . . . . . . . = 17=0A= 1.3.8. Application Modification for IPv6 . . . . . . . . = 17=0A= 1.3.9. Routing in IPv6/IPv4 Networks . . . . . . . . . . = 18=0A= 1.3.10. The Dual-Stack Transition Method . . . . . . . . = 19=0A= 1.3.11. Automatic Tunneling . . . . . . . . . . . . . . . = 20=0A= =0A= 2. The Technical Case for IPv6 = 20=0A= 2.1. IPv6 Headers vs. IPv4 Headers . . . . . . . . . . . . . . = 20=0A= 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . = 22=0A= 2.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . = 23=0A= 2.4. Destination Options Headers . . . . . . . . . . . . . . . = 24=0A= 2.5. Routing Headers . . . . . . . . . . . . . . . . . . . . . = 24=0A= 2.6. Fragmentation Header . . . . . . . . . . . . . . . . . . = 25=0A= 2.7. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . = 26=0A= 2.8. IPv6 Authentication Header . . . . . . . . . . . . . . . = 27=0A= 2.9. IPv6 Encryption Header . . . . . . . . . . . . . . . . . = 28=0A= 2.10. The IPv6 Address Architecture . . . . . . . . . . . . . . = 30=0A= 2.11. The IPv6 Address Hierarchy . . . . . . . . . . . . . . . = 31=0A= 2.12. Host Address Autoconfiguration . . . . . . . . . . . . . = 34=0A= 2.13. Other Protocols and Services . . . . . . . . . . . . . . = 38=0A= =0A= 3. Transition Scenarios = 39=0A= 3.1. First Scenario: No Need to NAT . . . . . . . . . . . . . = 39=0A= 3.2. Second Scenario: IPv6 from the Edges to the Core . . . . = 41=0A= 3.3. Other mechanisms . . . . . . . . . . . . . . . . . . . . = 42=0A= =0A= King, et.al. Expires 22 April 2000 [Page = ii]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= 4. Security Considerations = 43=0A= =0A= 5. Acknowledgments = 43=0A= =0A= A. Myths = 44=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 1]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= Introduction=0A= =0A= This document was produced at the request of the IAB, based on an=0A= existing original. The base protocol specifications are now = Draft=0A= Standards, and are thus unlikely to change. Some other related=0A= specifications are still in progress at the time of this writing, = so=0A= that the technical details are subject to change, and the = references=0A= cited may become obsolete; as with IPv4, there will always be = more=0A= work to do. The intended audience includes enterprise network=0A= administrators and decision makers, router vendors, host vendors,=0A= Internet Service Providers (ISPs) managers, and protocol = engineers=0A= who are as yet unfamiliar with the basic aspects of IPv6.=0A= =0A= The Internet Protocol (IP) has its roots in early research = networks=0A= of the 1970s, but within the past decade has become the leading=0A= network-layer protocol. This means that IP is a primary vehicle = for=0A= a vast array of client/server and peer-to-peer communications, = and=0A= the current scale of deployment is straining many aspects of its=0A= twenty-year old design [4].=0A= =0A= The Internet Engineering Task Force (IETF) has produced=0A= specifications (see section 1.1) that define the next-generation=0A= IP protocol known as "IPng," or "IPv6." IPv6 is both a near-term=0A= and long-range concern for network owners and service providers.=0A= IPv6 products have already come to market; on the other hand, = IPv6=0A= development work will likely continue well into the next decade.=0A= Though it is based on much-needed enhancements to IPv4 standards,=0A= IPv6 should be viewed as a new protocol that will provide a = firmer=0A= base for the continued growth of today's internetworks.=0A= =0A= Because it is intended to replace IP (hereafter called IPv4) IPv6=0A= is of considerable importance to businesses, consumers, and = network=0A= access providers of all sizes. IPv6 is designed to improve upon=0A= IPv4's scalability, security, ease-of-configuration, and network=0A= management; these issues are central to the competitiveness and=0A= performance of all types of network-dependent businesses. IPv4 = can=0A= be modified to perform some of these functions, but the = expectation=0A= within the IAB is that the results are likely to be far less = useful=0A= than what could be obtained by widespread deployment of IPv6. On=0A= the other hand IPv6 aims to preserve existing investment as much = as=0A= possible. End users, industry executives, network = administrators,=0A= protocol engineers, and many others will benefit from = understanding=0A= the ways that IPv6 will affect future internetworking and = distributed=0A= computing applications.=0A= =0A= By early 1998 a worldwide IPv6 testing and pre-production = deployment=0A= network, called the 6BONE, had already reached approximately=0A= 400 sites and networks in 40 countries. There are over 50 IPv6=0A= implementations completed or underway worldwide, and over 25 in = test=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 2]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= or production use on the 6BONE. The 6BONE has been built by an = active=0A= population of protocol inventors, designers and programmers. = They=0A= have worked together to solve the questions and problems that = might=0A= be expected to arise during such a huge project. Their = experience=0A= has served to validate the expectations of the protocol = designers.=0A= =0A= This document presents IPv6 issues in several parts:=0A= =0A= - The Business Case for IPv6, giving a highlevel view of = business=0A= issues, protocol basics, and current status, and=0A= - The Technical Case for IPv6, which describes more of the=0A= functional and technical aspects of IPv6.=0A= - Transition Scenarios, which discusses mechanisms that have = been=0A= designed to ease the transition from IPv4 to IPv6.=0A= =0A= 1. The Business Case for IPv6=0A= =0A= Given the remarkable growth of the Internet, and business = opportunity=0A= represented by the Internet, IPv6 is of major interest to = business=0A= interests, enterprise internetworks, and the global Internet. = IPv6=0A= presents all networking interests with a opportunity for global=0A= improvements, which is now receiving the collective action that = is=0A= needed to realize the benefits.=0A= =0A= 1.1. IPv6: Standardization and Productization Status=0A= =0A= IPv6, the Next-Generation Internet Protocol, has been approved=0A= as a Draft Standard, so that it is known to be highly stable=0A= and appropriate for productization. A large number of end-user=0A= organizations, standards groups, and network vendors have been=0A= working together on the specification and testing of early IPv6=0A= implementations. A number of IETF working groups have produced = IPv6=0A= specifications that are finished or well underway. Current Draft=0A= Standards include:=0A= =0A= - RFC 2373: IP Version 6 Addressing Architecture=0A= - RFC 2374: An IPv6 Aggregatable Global Unicast Address Format=0A= - RFC 2460: Internet Protocol, Version 6 (IPv6) Specification=0A= - RFC 2461: Neighbor Discovery for IP Version 6 (IPv6)=0A= - RFC 2462: IPv6 Stateless Address Autoconfiguration=0A= - RFC 2463: Internet Control Message Protocol (ICMPv6) for the=0A= Internet Protocol Version 6 (IPv6) Specification=0A= =0A= Current Proposed Standards include:=0A= =0A= - RFC 1886: DNS Extensions to support IP version 6=0A= - RFC 1887: An Architecture for IPv6 Unicast Address = Allocation=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 3]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= - RFC 1981: Path MTU Discovery for IP version 6=0A= - RFC 2023: IP Version 6 over PPP=0A= - RFC 2080: RIPng for IPv6=0A= - RFC 2452: IP Version 6 Management Information Base for the=0A= Transmission Control Protocol=0A= - RFC 2454: IP Version 6 Management Information Base for the = User=0A= Datagram Protocol=0A= - RFC 2464: Transmission of IPv6 Packets over Ethernet = Networks=0A= - RFC 2465: Management Information Base for IP Version 6: = Textual=0A= Conventions and General Group=0A= - RFC 2466: Management Information Base for IP Version 6: = ICMPv6=0A= Group=0A= - RFC 2467: Transmission of IPv6 Packets over FDDI Networks=0A= - RFC 2470: Transmission of IPv6 Packets over Token Ring = Networks=0A= - RFC 2472: IP Version 6 over PPP=0A= - RFC 2473: Generic Packet Tunneling in IPv6 Specification=0A= - RFC 2507: IP Header Compression=0A= - RFC 2526: Reserved IPv6 Subnet Anycast Addresses=0A= - RFC 2529: Transmission of IPv6 over IPv4 Domains without=0A= Explicit Tunnels=0A= - RFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6=0A= Inter-Domain Routing=0A= - RFC 2590: Transmission of IPv6 Packets over Frame Relay=0A= - RFC 2675: IPv6 Jumbograms=0A= - RFC 2710: Multicast Listener Discovery (MLD) for IPv6=0A= - RFC 2711: IPv6 Router Alert Option=0A= =0A= There are too many related RFCs and Internet Drafts to list them = all=0A= here, but among them are included the following:=0A= =0A= - RFC 1888: OSI NSAPs and IPv6=0A= - RFC 2292: Advanced Sockets API for IPv6=0A= - RFC 2375: IPv6 Multicast Address Assignments=0A= - RFC 2450: Proposed TLA and NLA Assignment Rules=0A= - RFC 2471: IPv6 Testing Address Allocation=0A= - RFC 2553: Basic Socket Interface Extensions for IPv6=0A= - OSPF for IPv6=0A= - Mobility Support in IPv6=0A= - DHCP for IP Version 6=0A= - Router Renumbering for IPv6=0A= - Site prefixes in Neighbor Discovery=0A= - Routing of Scoped Addresses in the Internet Protocol Version = 6=0A= (IPv6)=0A= =0A= Standards work on IPv6 and related components is far enough along=0A= that vendors have already committed to a considerable number of=0A= development and testing projects. All of the major router = vendors=0A= have made plans to support IPv6 in their products.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 4]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= Most or all major vendors have likewise begun the task of = delivering=0A= IPv6 on desktop machines and servers. Many organizations are=0A= working on IPv6 drivers for the popular UNIX BSD and Linux = operating=0A= environments. Network software vendors have announced a wide=0A= range of support for IPv6 in network applications and = communication=0A= software products. Software is available from Microsoft for=0A= Windows-based clients.=0A= =0A= 1.2. IPv6 Design Goals=0A= =0A= IPv6 has been designed to enable highperformance, scalable=0A= internetworks that should operate as needed for decades. Part of = the=0A= design process involved correcting the inadequacies of IPv4. = IPv6=0A= offers a number of enhanced features, such as a larger address = space=0A= and improved packet formats. Scalable networking requires = careful=0A= utilization of human resources as well as network resources; so, = a=0A= great deal of attention has been given to creating = autoconfiguration=0A= protocols for IPv6, minimizing the need for human intervention=0A= when assigning IP addresses and relevant network paramters such=0A= as link MTU. Other benefits relate to the fresh start that IPv6=0A= gives to those who build and administer networks. For instance,=0A= a well-structured, efficient and adaptable routing hierarchy=0A= will be possible. The following sections give an overview of the=0A= improvements that IPv6 brings to enterprise networking and the = global=0A= Internet.=0A= =0A= 1.2.1. Addressing and Routing=0A= =0A= IPv6 helps to solve a number of problems that currently exist = within=0A= and between enterprises. On the global scale, IPv6 will allow=0A= Internet backbone designers to create a flexible and expandable=0A= global routing hierarchy. The Internet backbone, where major=0A= enterprises and Internet Service Provider (ISP) networks come=0A= together, depends upon the maintenance of a hierarchical address=0A= system, similar to that of the national and international = telephone=0A= systems. Large central-office phone switches, for instance, only=0A= need a three-digit national area code prefix to route a = long-distance=0A= telephone call toward the correct local exchange. The current=0A= IPv4 system also uses an address hierarchy to sort traffic = towards=0A= networks attached to the Internet backbone.=0A= =0A= Without an address hierarchy, backbone routers would be forced to=0A= store route table information on the reachability of every = network=0A= in the world. Given the current number of IP subnets in the = world=0A= and the growth of the Internet, it is not feasible to manage = route=0A= tables and updates for so many routes. With a hierarchy, = backbone=0A= routers can use IP address prefixes to determine how traffic = should=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 5]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= be routed through the backbone. In recent years, IPv4 has begun = to=0A= use a technique called Classless InterDomain Routing (CIDR) [30, = 15],=0A= which uses bit masks to allocate a variable portion of the 32-bit=0A= IPv4 address to a network, subnet, or host. CIDR permits "route=0A= aggregation" at various levels of the Internet hierarchy, whereby=0A= backbone routers can store a single route table entry that = provides=0A= reachability to many lower- level networks.=0A= =0A= But CIDR does not guarantee an efficient and scalable hierarchy.=0A= In order to avoid maintaining a separate entry for each route=0A= individually, it is important for routes at lower levels of the=0A= routing hierarchy, that naturally have longer prefixes, to be=0A= collected together (or "summarized") into fewer and less specific=0A= routes at higher levels of the routing hierarchy.=0A= =0A= Legacy IPv4 address assignments that originated before CIDR and=0A= the current access provider hierarchy often do not facilitate=0A= summarization. The lack of uniformity of the current = hierarchical=0A= system, coupled with the rationing of IPv4 addresses, makes = Internet=0A= addressing and routing quite complicated. These issues affect=0A= highlevel service providers and consequently individual end users=0A= in all types of businesses. Furthermore, renumbering IPv4 sites=0A= when changing from one ISP to another, to maintain and improve=0A= address/route aggregation, is unnecessarily complicated (and thus=0A= more expensive) compared to IPv6's ease of site renumbering (see=0A= section 1.2.3).=0A= =0A= 1.2.2. Eliminating Special Cases=0A= =0A= Many of the same problems that exist today in the Internet = backbone=0A= are also being felt at the level of the enterprise and the = individual=0A= business user. When an enterprise can't summarize its routes=0A= effectively, it puts a larger load on the backbone route tables.=0A= If an enterprise can't present globally unique addresses to the=0A= Internet, it may be forced to deploy private, isolated address = space=0A= that isn't visible to the Internet.=0A= =0A= Users in private address spaces with non-unique addresses = typically=0A= require gateways, and possibly Network Address Translators=0A= (NATs) [31], to manage their connectivity to the outside world. = In=0A= such situations, some services are simply not available. A NAT=0A= is meant to allow an enterprise to have whatever internal address=0A= structure it desires, without concern for integrating internal=0A= addresses with the global Internet. This is seen as particularly=0A= convenient in the existing IPv4 world, with its more cumbersome=0A= address space management. The NAT device sits on the border=0A= between the enterprise and the Internet, converting private = internal=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 6]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= addresses to a smaller pool of globally unique addresses that are=0A= passed to the backbone and vice versa (see Figure 1).=0A= =0A= |=0A= |=0A= Private address space | Unique global addresses=0A= |=0A= |=0A= --------------- |=0A= / \ +-----+ +----------+=0A= | Enterprise | | | | |=0A= | |----| NAT |-----| Internet |=0A= | Network | | | | |=0A= \ / +-----+ +----------+=0A= --------------- |=0A= |=0A= |=0A= |=0A= =0A= Figure 1: Network Address Translator (NAT)=0A= =0A= NAT may be appropriate in some organizations, particularly if=0A= full connectivity with the outside world is not desired. But for=0A= enterprises that require robust interaction with the Internet, = NAT=0A= devices often get in the way. The NAT technique of substituting=0A= address fields in each and every packet that leaves and enters = the=0A= enterprise is very demanding, and presents a bottleneck between=0A= the enterprise and the Internet. A NAT may keep up with address=0A= conversion in a small network, but as the enterprise's Internet=0A= access increases, the NAT's performance must increase in = parallel.=0A= The bottleneck effect is exacerbated by the difficulty of = integrating=0A= and synchronizing multiple NAT devices within a single = enterprise.=0A= Enterprises with NAT are less likely to achieve the reliable=0A= highperformance Internet connectivity that is common today with=0A= multiple routers attached to an ISP backbone in an arbitrary mesh=0A= fashion. Furthermore, use of NAT devices takes away the = additional=0A= element of reliability afforded by the possibility for asymmetric=0A= routing, since NAT devices require control of traffic directions = both=0A= to and from internally addressed network nodes.=0A= =0A= NAT translators also run into trouble when applications embed IP=0A= addresses in the packet payload, above the network layer. This=0A= is the case for a number of applications, including certain File=0A= Transfer Protocol (FTP) programs, Mobile IP, and the Windows = Internet=0A= Name Service (WINS) registration process of Windows 95 and = Windows=0A= NT. Unless a NAT parses every packet all the way to the = application=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 7]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= level, it is likely to fail to translate some embedded addresses,=0A= which will lead to application failures. NAT can also break = Domain=0A= Name Servers, because they work above the network layer. NATs=0A= prevent the use of IP-level security between the endpoints of a=0A= transaction. Today, NAT devices are helpful in certain limited=0A= scenarios for smaller enterprises, but are considered by many to = be=0A= generally disadvantageous for the long-term health of the = Internet.=0A= See [16] for a fuller discussion about the effects of NAT use on = the=0A= Internet.=0A= =0A= 1.2.3. Minimizing Administrative Workload=0A= =0A= A major component of today's network administration involves the=0A= assignment of networking parameters to computers and other = network=0A= nodes, that are needed before they can begin any sort of network=0A= operation. Information such as an IP address, DNS server, = default=0A= router, and other configuration details have to be installed at=0A= each network node. In many cases, this is still done by manual=0A= configuration, either by the network administration, or worse yet = by=0A= the users themselves. Recent efforts to shift this = administrative=0A= load onto departmental servers have focussed on deployment of the=0A= Dynamic Host Configuration Protocol (DHCP) [14, 1], but this = comes=0A= along with its own administrative difficulties.=0A= =0A= IPv4's limitations also aggravate the occasional need in many=0A= organizations to renumber network devices -- i.e., assign new IP=0A= addresses to them. When an enterprise changes ISPs, it may have=0A= to either renumber all addresses to match the new ISP-assigned=0A= prefix, or implement Network Address Translation devices (NATs).=0A= Renumbering may be indicated when a corporation undergoes a = merger=0A= or an acquisition with consequent network consolidation. Since=0A= routing prefixes are assigned to reflect the routing topology of=0A= the enterprise networks and the number of nodes attached to the=0A= particular network links, there are two ways that the choice of=0A= routing prefixes can become inconvenient or incorrect:=0A= =0A= 1. The routing prefix can become too long for the administration = to=0A= be able to increase the number of nodes that can be attached = to=0A= the particular link, and=0A= =0A= 2. The ways that the network links are connected together, or = are=0A= connected to the outside world, can change.=0A= =0A= Either of these occurrence would indicate the need to renumber one = or=0A= more enterprise networks. It would be quite profitable to be able = to=0A= renumber enterprise networks without requiring expensive downtime = for=0A= the networks and or the nodes on the network.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 8]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= Address shortages and routing hierarchy problems threaten the = network=0A= operations of larger enterprises, but they also affect small = sites=0A= -- even the home worker who dials in to the office via the = Internet.=0A= Smaller networks can be completely dropped from Internet backbone=0A= route tables if they do not adapt to the address hierarchy, while=0A= larger networks may refuse to renumber and cause a larger routing=0A= problem for the backbone providers of the Internet. With today's=0A= IPv4 address registries, ISPs with individual dial-in clients=0A= cannot allocate IP numbers as freely as they wish. Consequently,=0A= many dial-in users must use an address allocated from a pool on a=0A= temporary basis. In other cases, small dial-in sites are forced = to=0A= share a single IP address among multiple end systems.=0A= =0A= A unique IP address sets the stage for users to gain direct=0A= connectivity to other users on the Internet, as determined by = local=0A= policy. It also simplifies a wide range of productive = interactive=0A= applications, of which telecommuting and remote diagnostics are = only=0A= two examples. Today's hierarchy of limited and poorly allocated = IPv4=0A= addresses has already caused problems, and will continue to do so=0A= as more and more devices of varying capabilities are added to the=0A= Internet.=0A= =0A= 1.2.4. Security=0A= =0A= Encryption, authentication, and data integrity safeguards are = needed=0A= for enterprise internetworking and virtual private networks = (VPNs).=0A= For these purposes, IPv6 offers security header extensions.=0A= =0A= The IPv6 authentication extension header allows a receiver to=0A= determine with a high degree of certainty whether or not a packet=0A= originated from the host indicated in its source address. This=0A= prevents malicious users from configuring an IP host to = impersonate=0A= another, to gain access to secure resources. Such source-address=0A= masquerading (spoofing) is among the techniques that could be = used=0A= to obtain valuable financial and corporate data, or could give=0A= adversaries of the enterprise control of servers for malicious=0A= purposes. Spoofing might fool a server into granting access to=0A= valuable data, passwords, or network control utilities. IP = spoofing=0A= is known to be one of the most common forms of denial-of-service=0A= attack; with IPv4 it is typically impossible for a server to=0A= determine whether packets are being received from the legitimate=0A= end node. Some enterprises have responded by installing = firewalls,=0A= but these devices introduce a number of new problems, including=0A= performance bottlenecks, restrictive network policies, and = limited=0A= connectivity to the Internet or even between divisions of the = same=0A= company.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 9]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= IPv6 uses a standard method to determine the authenticity of = packets=0A= received at the network layer, ensuring that network products = from=0A= different vendors can use interoperable authentication services.=0A= IPv6 implementations are required to support the MD5 and SHA-1=0A= algorithms for authentication and integrity checking to insure=0A= that any two IPv6 nodes can interoperate securely. Since the=0A= specification is algorithm-independent, other techniques may be = used=0A= as well.=0A= =0A= Along with packet spoofing, another major hole in Internet = security=0A= is the widespread deployment of traffic analyzers and network=0A= "sniffers" which can surreptitiously eavesdrop on network = traffic.=0A= These generally helpful diagnostic devices can be misused by = those=0A= seeking access to credit card and bank account numbers, = passwords,=0A= trade secrets, and other valuable data. In IPv6 privacy (data=0A= confidentiality) is provided by a standard header extension for=0A= end-to-end encryption at the network layer. IPv6 encryption = headers=0A= indicate which encryption keys to use, and carry other = handshaking=0A= information. IPv4 network-layer extensions for this have been=0A= defined and are compatible with those for IPv6, but are not yet = in=0A= wide use.=0A= =0A= Both IPv6 security headers can be used directly between hosts=0A= or in conjunction with a specialized security gateway that adds=0A= an additional level of security with its own packet signing and=0A= encryption methods.=0A= =0A= 1.2.5. Mobility=0A= =0A= IPv4 has difficulties managing mobile computers, for several = reasons:=0A= =0A= - A mobile computer needs to make use of a forwarding address = at=0A= each new point of attachment to the Internet, and it's not = always=0A= so easy to get such an address with IPv4=0A= =0A= - Informing any agent in the routing infrastructure about=0A= the mobile node's new location requires good authentication=0A= facilities which are not commonly deployed in IPv4 nodes.=0A= =0A= - In IPv4, it may be difficult for mobile nodes to determine=0A= whether or not they are attached to the same network.=0A= =0A= - It is unlikely in IPv4 that mobile nodes would be able to = inform=0A= their communication partners about any change in location.=0A= =0A= Each of these problems is solved in a natural way by using = features=0A= in IPv6. The benefits for mobile computing are apparent in quite = a=0A= number of aspects of the IPv6 protocol design, and go beyond = merely=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 10]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= providing dial-up support for road warriors. The improvements=0A= in option processing for destination options, autoconfiguration,=0A= routing headers, encapsulation, security, and anycast addresses = all=0A= contribute to the natural design of mobility for IPv6 [20]. In = fact,=0A= some satellite work in Europe is already starting to become IPv6=0A= based. The IPv6 mobility advantage may be further emphasized by=0A= combining flow label management to provide better Quality of = Service=0A= to mobile nodes.=0A= =0A= 1.3. The IPv6 solution=0A= =0A= IPv6, with its immensely larger address space, defines a = multi-level=0A= hierarchical global routing architecture. Using CIDR-style=0A= prefixes [30], the IPv6 address space can be allocated in a way = that=0A= facilitates route summarization, and controls expansion of route=0A= tables in backbone routers. The vastly greater availability of = IPv6=0A= addresses eliminates the need for private address spaces. ISPs=0A= will have enough addresses to allocate to smaller businesses and=0A= dial-in users that need globally unique addresses to fully = exploit=0A= the Internet. Using an example from crowded telephone networks, = one=0A= might say that IPv6 eliminates the need for "extensions", so that = all=0A= offices have direct communication lines and do not need operators=0A= (automatic or otherwise) to redirect calls.=0A= =0A= 1.3.1. Address Autoconfiguration=0A= =0A= Each IPv6 node initially creates a local IPv6 address for itself=0A= using "stateless" address autoconfiguration, not requiring a = manually=0A= configured server. Stateless autoconfiguration further makes it=0A= possible for nodes to configure their own globally routable = addresses=0A= in cooperation with a local IPv6 router. Typically, the node=0A= combines its 48 or 64 bit MAC (i.e., layer-2) address, assigned = by=0A= the equipment manufacturer, with a network prefix it learns from = a=0A= neighboring router. This keeps end user costs down by not = requiring=0A= knowledgeable staff to properly configure each workstation before=0A= it can be deployed. These costs are currently part of the = initial=0A= equipment expense for almost all IPv4 computing platforms. With = the=0A= possibility of low or zero administrative costs, and the = possibility=0A= of extremely low cost network interfaces, new market = possibilities=0A= can be created for control of embedded computer systems. This=0A= feature will also help when residential networks emerge as an=0A= important market segment.=0A= =0A= IPv4 networks often employ the Dynamic Host Configuration = Protocol=0A= (DHCP) to reduce the effort associated with manually assigning=0A= addresses to end nodes. DHCP is termed a "stateful" address=0A= configuration tool because it maintains static tables that = determine=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 11]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= which addresses are assigned to newly connected network nodes.=0A= A new version of DHCP has been developed for IPv6 to provide=0A= similar stateful address assignment as may be desired by many=0A= network administrators. DHCPv6 [2, 27] also assists with = efficient=0A= reconfiguration in addition to initial address configuration, by=0A= using multicast from the DHCP server to any desired population of=0A= clients.=0A= =0A= The robust autoconfiguration capabilities of IPv6 will benefit=0A= internetwork users at many levels. When an enterprise is forced=0A= to renumber because of an ISP change, IPv6 autoconfiguration will=0A= allow hosts to be given new prefixes, without even requiring = manual=0A= reconfiguration of workstations or DHCP clients. This function = also=0A= assists enterprises in keeping up with dynamic end-user = populations.=0A= Autoconfiguration allows mobile computers to receive valid = forwarding=0A= addresses automatically, no matter where they connect to the = network.=0A= =0A= 1.3.2. IPv6 Header Format=0A= =0A= IPv6 regularizes and enhances the basic header layout of the IP=0A= packet (see Figures 5,6 in section 2.1). In IPv6, some of the = IPv4=0A= header information was dropped or made optional. The simplified=0A= packet structure is expected to offset the bandwidth cost of the=0A= longer IPv6 address fields. The 16-byte (128-bit) IPv6 addresses = are=0A= four times longer than the 4-byte IPv4 addresses, but as a result = of=0A= the retooling, the total IPv6 header size is only twice as large;=0A= many processing aspects are substantially more efficient. Note=0A= that a number of other designs were considered, including = variable=0A= length addresses; in the end, simplicity won out over infinite=0A= extensibility, partially because 128 bits offers such a huge = total=0A= address space. Recent work [13] in IP header compression promises = to=0A= reduce or perhaps even effectively eliminate any additional = network=0A= load associated with the use of 128-bit addresses over = low-bandwidth=0A= links.=0A= =0A= IPv6 encodes IP header options in a way that streamlines the=0A= forwarding process. Optional IPv6 header information is conveyed=0A= in independent "extension headers" located after the IPv6 header=0A= and before the transport-layer header in each packet. Most IPv6=0A= extension headers are not examined or processed by intermediate=0A= nodes (in contrast with IPv4). This enables a big improvement=0A= in the deployability of optional IPv6 features, compared to IPv4=0A= where IP options typically cause a major performance loss for the=0A= packet at every intermediate router. IPv6 header extensions are=0A= variable in length and can contain more information than before.=0A= Network protocol designers can introduce new header options in a=0A= straightforward manner. More details about the comparisons = between=0A= the IPv4 and IPv6 headers are discussion in section 2.1.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 12]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= So far, option fields have been specified for carrying explicit=0A= routing information created by the source node, as well as for=0A= mobility, authentication, encryption, and fragmentation control.=0A= At the application level, header extensions are available for=0A= specialized end-to-end network applications that require their = own=0A= header fields within the IP packet.=0A= =0A= 1.3.3. Multicast=0A= =0A= Multicast Source=0A= +---+=0A= | |=0A= | |=0A= +-+-+=0A= |=0A= |=0A= |=0A= = ---+------+----+----------+---+----+-----+--------+------+-----+-=0A= | | | | | | | | = |=0A= | | | | | | | | = |=0A= | | | | | | | | = |=0A= | +-+-+ | | +-+-+ | | | = |=0A= | | | | | | | | +-+-+ | = |=0A= | | | | | | | | | | | = +-+-+=0A= +-+-+ +---+ | +-+-+ +---+ | | | | | = |=0A= | | | | | | +---+ | | = |=0A= | | +-+-+ | | +-+-+ Multicast | = +---+=0A= +---+ | | +---+ | | Group |=0A= Multicast | | Multicast | | Member +-+-+=0A= Group +---+ Group +---+ | |=0A= Member Member | |=0A= +---+=0A= Multicast=0A= Group=0A= Member=0A= =0A= Figure 2: Multicast in Action=0A= =0A= Modern internetworks need to transmit streams of video, audio,=0A= animated graphics, news, financial, or other timely data to = groups=0A= of functionally related but dispersed endstations. This is best=0A= achieved by network layer multicast. Typically, a server sends out = a=0A= single stream of multimedia or time-sensitive data to be received = by=0A= subscribers. A multicast-capable network routes the server's = packets=0A= to each subscriber in the multicast group using an efficient path=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 13]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= (see Figure 2), replicating only as needed. In the figure, a = single=0A= packet from the source will be received by all the multicast = group=0A= members. When there are multiple networks containing multicast = group=0A= members, a packet distribution "tree" is created for the = multicast=0A= group.=0A= =0A= Routers use multicast protocols such as DVMRP (Distance Vector=0A= Multicast Routing Protocol) [11] and PIM (Protocol Independent=0A= Multicast) [9] or MOSPF (Multicast Open Shortest Path First) [24]=0A= to dynamically construct the packet distribution tree that = connects=0A= all members of a group with the multicast server. Only members = that=0A= have joined the multicast group perform the processing to receive=0A= the data. A new member becomes part of a multicast group by = sending=0A= a "join" message to a nearby router. The distribution tree is = then=0A= adjusted to include the new route. Servers can then multicast a=0A= single packet, and it will be replicated as needed and forwarded=0A= through the internetwork to the multicast group. This conserves = both=0A= server and network resources and, hence, is superior to unicast = and=0A= broadcast solutions. Multicast applications have been developed=0A= for IPv4, but IPv6 extends IP multicasting capabilities by = defining=0A= a much larger multicast address space. All IPv6 hosts and = routers=0A= are required to support multicast. In fact, IPv6 has no = broadcast=0A= address as such; it has various multicast addresses of various=0A= scopes. The improved scoping offered in IPv6 promises to = simplify=0A= the use and administration of multicast in many applications.=0A= =0A= 1.3.4. Anycast=0A= =0A= Anycast services, supported in the IPv6 specification, are not=0A= defined architecturally in IPv4. Conceptually, anycast is a = cross=0A= between unicast and multicast: an arbitrary collection of nodes = may=0A= be designated as an anycast group [26]. A packet addressed to = the=0A= group's anycast address is delivered to only one of the nodes in = the=0A= group, typically the node with the "nearest" interface in the = group,=0A= according to current routing protocol metrics. This is in = contrast=0A= with multicast services, which deliver packets to all members of = the=0A= multicast group. Nodes in an anycast group are specially = configured=0A= to recognize anycast addresses, which are drawn from the unicast=0A= address space [19].=0A= =0A= Anycasting is a new service, and its applications have not been = fully=0A= developed. Using anycast, an enterprise could forward packets to=0A= exactly one of the routers on its ISP's backbone (see Figure 3). = If=0A= all of a provider's routers have the same anycast address, = traffic=0A= from the enterprise will have several redundant access points to = the=0A= Internet. And if one of the backbone routers goes down, the next=0A= nearest device automatically will receive the traffic.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 14]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= ----- ----- -----=0A= | X | | Y | | Z |=0A= ----- ----- -----=0A= \ | / ------- ISP transit domain = ---------=0A= \ | / | = |=0A= ------- | ------- = |=0A= | rtr |---------------------------------| rtr | = |=0A= ------- | ------- = |=0A= / \ | / \ = |=0A= / \ | / \ = |=0A= ------- ------- | ------- ------- = |=0A= | rtr | Enterprise| rtr |---------------| rtr | Anycast | rtr | = |=0A= ------- Network ------- | ------- Group ------- = |=0A= \ / | \ / = |=0A= \ / | \ / = |=0A= ------- | ------- = |=0A= | rtr |---------------------------------| rtr | = |=0A= ------- | ------- = |=0A= | | = |=0A= ----- | = |=0A= | Q | ------- ISP transit domain = ---------=0A= -----=0A= =0A= Figure 3: Anycast Addressing=0A= =0A= In figure 3, suppose some hosts Q, X, Y, and Z in an Enterprise=0A= Network send data to the anycast address served by the backbone=0A= routers in the Anycast Group of the ISP Transit Domain. The = border=0A= routers in the Enterprise Network forward the data just as they = would=0A= for data sent to a unicast address. Then, any one of the = backbone=0A= routers in the Anycast Group may receive the data, eliminating = the=0A= overhead which would have been incurred if the backbone routers = were=0A= instead configured to form a multicast group. If there are = multiple=0A= home agents for mobile nodes on a single home network, they also=0A= join a anycast group. In that way, a mobile node can register = with=0A= exactly one home agent even in the case when it doesn't know the=0A= address of any specific one.=0A= =0A= Anycast has been proposed to allow endstations to efficiently = access=0A= well-known services, mirrored databases, Web sites, and message=0A= servers. It can provide a versatile and cost-effective model for=0A= enabling application robustness and load balancing. For = instance,=0A= anycast could provide enterprise robustness by assigning all the = DNS=0A= servers in an enterprise the same anycast address.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 15]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= 1.3.5. Quality of Service=0A= =0A= IPv4 carries a "differentiated services" byte and IPv6 carries an=0A= equivalent "traffic class" byte, intended for support of simple=0A= differentiated services. Both IPv4 and IPv6 can support the RSVP=0A= protocol for more complex quality of service implementations.=0A= Additionally, the IPv6 packet format contains a new 20-bit=0A= traffic-flow identification field that will be of great value to=0A= vendors who implement quality-of-service (QoS) network functions.=0A= Such QoS products are still in the planning stage, but IPv6 lays = the=0A= foundation so that a wide range of QoS functions (including = bandwidth=0A= reservation and delay bounds) may be made available in a open and=0A= interoperable manner.=0A= =0A= An additional benefit for QoS in IPv6 is that a flow label has = been=0A= allocated within the IPv6 header that can be used to distinguish=0A= traffic flows for optimized routing. Furthermore, the flow label = can=0A= be used to identify flows even when the payload is encrypted = (i.e.,=0A= the port numbers are hidden).=0A= =0A= 1.3.6. The Transition to IPv6=0A= =0A= The transition from IPv4 to IPv6 could take one of several paths.=0A= Some are lobbying for rapid adoption of IPv6 as soon as possible.=0A= Others prefer to defer IPv6 deployment until the IPv4 address = space=0A= is exhausted, or until other issues leave no other choice. = Either=0A= way, given the millions of existing IPv4 network nodes, IPv4 and = IPv6=0A= will coexist for an extended period of time.=0A= =0A= Therefore, IETF protocol designers have gone to great lengths to=0A= ensure that hosts and routers can be upgraded to IPv6 in a = graceful,=0A= incremental manner. The transition will prevent isolation of=0A= IPv4 nodes, and also prevent "fork-lift" upgrades for entire user=0A= populations. Transition mechanisms have been engineered to allow=0A= network administrators flexibility in how and when they upgrade = hosts=0A= and intermediate nodes. IPv6 can be deployed in hosts first, in=0A= routers first, or, alternatively, in a limited number of adjacent = or=0A= remote hosts and routers. The nodes that are upgraded initially = do=0A= not have to be colocated in the same local area network or = campus.=0A= =0A= Many upgraded hosts and routers will need to retain downward=0A= compatibility with IPv4 devices for an extended time period = (possibly=0A= years or even indefinitely). It was also assumed that upgraded=0A= devices should have the option of retaining their IPv4 addresses. = To=0A= accomplish these goals, IPv6 transition relies on several special=0A= functions that have been specified by the ``ngtrans'' working = group=0A= of the IETF, including dual-stack hosts, routers, and tunneling = IPv6=0A= via IPv4. A dual-stack host is a computer able to handle both = IPv4=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 16]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= and IPv6 packets. Such a computer can deliver packetized data to=0A= a single application that has been equipped to ask for data from=0A= both addressing domains. This facilitates easy transition from = IPv4=0A= to IPv6 since the application can then still receive data from = its=0A= current communications partners, without change in any way = noticeable=0A= to the users.=0A= =0A= 1.3.7. IPv6 DNS=0A= =0A= Domain Name Service (DNS) is something that administrators must=0A= consider before deploying IPv6 or dual-stack hosts. In response = to=0A= this issue, IETF designers have defined "DNS Extensions to = Support=0A= IP Version 6" [33]. This specification creates a new "AAAA" = (quad=0A= A) DNS record type that will map domain names to an IPv6 address.=0A= Domain name lookups (reverse lookups) based on 128-bit addresses = also=0A= are defined. Once an IPv6-capable DNS is in place, dual-stack = hosts=0A= can interact interchangeably with IPv6 nodes. If a dual-stack = host=0A= queries DNS and receives back a 32-bit address, IPv4 is used; if = a=0A= 128-bit address is received, then IPv6 is used. Where the DNS = has=0A= not been upgraded to IPv6, hosts can resolve name-to-IPv6-address=0A= mappings through the use of manually configured local name = tables.=0A= =0A= IPv6 autoconfiguration and IPv6 DNS can be linked by using = dynamic=0A= DNS updates, coupled with secure DNS. By these means DNS servers = can=0A= be securely and automatically updated whenever an IPv6 node = acquires=0A= a new address, enabling an additional measure of convenience = compared=0A= with renumbering in IPv4 today.=0A= =0A= 1.3.8. Application Modification for IPv6=0A= =0A= Applications that do not directly access network functions (i.e.=0A= do not call a socket or DNS API and do not handle numeric IP=0A= addresses in any way) need no modifications to run in the = dual-stack=0A= environment. Applications that use certain interface APIs to=0A= communicate with the network stack will require updating before = using=0A= IPv6. For example, applications that access DNS or use sockets = must=0A= be enhanced with the capability to handle AAAA records and = 128-bit=0A= addresses. Applications which are expected to run both IPv4 and=0A= IPv6, as well as using IPv6 security, quality of service, and = other=0A= features, will need more extensive updating.=0A= =0A= Adding such a dual-stack architecture to all the existing hosts=0A= is, in fact, a significant effort. This effort has to be = balanced=0A= against the benefits of IPv6, and against the effort to renumber = the=0A= existing hosts if the network deployment grows past the = restrictions=0A= resulting from insufficient address space.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 17]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= 1.3.9. Routing in IPv6/IPv4 Networks=0A= =0A= Routers running both IPv6 and IPv4 can be administered in much = the=0A= same fashion that IPv4-only networks are currently administered.=0A= Multi-protocol extensions to BGP4 have been defined by the IETF; = one=0A= of them carries IPv6 prefixes. The IPv6 extension has been used=0A= widely in the 6bone since early 1997. It has been implemented by=0A= all the major router vendors and by the well known gated daemon, = and=0A= is described in a Standard Track document. IPv6 versions of = other=0A= popular routing protocols, such as Open Shortest Path First = (OSPF)=0A= and Routing Information Protocol (RIP), are already running.=0A= =0A= Administrators may choose to keep the IPv6 topology logically=0A= separate from the IPv4 network, even though both run on the same=0A= physical infrastructure, allowing the two to be administered=0A= separately. Alternatively, it may be advantageous to align the = two=0A= architectures by using the same domain boundaries, areas, and = subnet=0A= organization. Both approaches have their advantages. A separate=0A= IPv6 architecture can be used to replace the inefficient IPv4=0A= topologies burdening many of today's enterprises. An independent=0A= IPv6 architecture presents the opportunity to build a fresh,=0A= hierarchical network address plan that will facilitate connection = to=0A= one or more ISPs. This simplifies renumbering, route aggregation=0A= (summarization), and other goals of a routing hierarchy.=0A= =0A= Initially, many IPv6 hosts may have direct connectivity to each = other=0A= only via IPv4 routers. Such hosts will exist in islands of IPv6=0A= topology surrounded by an ocean of IPv4. So, there are = transition=0A= mechanisms that allow IPv6 hosts to communicate over intervening=0A= IPv4 networks. The essential technique of these mechanisms is = IPv6=0A= over IPv4 tunneling, which carries IPv6 packets within IPv4 = packets=0A= (see Figure 4). Tunneling allows early IPv6 implementations to = take=0A= advantage of existing IPv4 infrastructure without any change to = IPv4=0A= components. A dual-stack router or host on the "edge" of the = IPv6=0A= topology simply inserts an IPv4 header in front of = ("encapsulates")=0A= each IPv6 packet and sends it as native IPv4 traffic through = existing=0A= links. IPv4 routers forward this traffic without knowledge that = IPv6=0A= is involved. On the other side of the tunnel, another dual-stack=0A= router or host "decapsulates" (removes the extra IP header from) = the=0A= IPv6 packet and routes it to the ultimate destination using = standard=0A= IPv6.=0A= =0A= To accommodate different administrative needs, IPv6 transition=0A= mechanisms include two types of tunneling: automatic and = configured.=0A= To build configured tunnels, administrators manually define = IPv6-to-=0A= IPv4 address mappings at tunnel endpoints. Outside of the = tunnel,=0A= traffic is forwarded with full 128-bit addresses. At the tunnel=0A= entry point, a manually configured router table entry dictates=0A= which IPv4 address is used to traverse the tunnel. This requires=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 18]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= +-------------------+=0A= +-----------+ | IPv4 Network | +-----------+=0A= | Dual-stack| | | | Dual-stack|=0A= | IPv4/IPv6 =3D=3D=3D=3D=3D=3D=3D=3Dtunnel = through=3D=3D=3D=3D=3D=3D=3D=3D IPv4/IPv6 |=0A= | router | | | | router |=0A= +-----------+ | | +-----------+=0A= / | \ +-------------------+ / | \=0A= / | \ / | \=0A= / | \ / | \=0A= +--+ +--+ +--+ +--+ +--+ +--+=0A= | | | | | | | | | | | |=0A= +--+ +--+ +--+ +--+ +--+ +--+=0A= IPv6 endstations IPv6 endstations=0A= =0A= Figure 4: IPv6 over IPv4 Tunneling=0A= =0A= a certain amount of manual administration at the tunnel = endpoints,=0A= but traffic is routed through the IPv4 topology dynamically, = without=0A= the knowledge of IPv4 routers. The 128-bit addresses do not have = to=0A= align with 32-bit addresses in any way.=0A= =0A= Mbone deployment using IP-within-IP tunneling has been quite=0A= successful, and validates this design approach as well as = supporting=0A= the likelihood of smooth transition.=0A= =0A= 1.3.10. The Dual-Stack Transition Method=0A= =0A= Initial users of IPv6 machines will require continued interaction=0A= with existing IPv4 nodes. This is accomplished with the = dual-stack=0A= IPv4/IPv6 approach. Many hosts and routers in today's = multivendor,=0A= multiplatform networking environment already support multiple = network=0A= stacks. For instance, the majority of routers in enterprise = networks=0A= are multiprotocol routers. Many workstations run some = combination=0A= of IPv4, IPX, AppleTalk, NetBIOS, SNA, DECnet, or other = protocols.=0A= The inclusion of one additional protocol (IPv6) on an endstation = or=0A= router is a well-understood problem. When running a dual = IPv4/IPv6=0A= stack, a host has access to both IPv4 and IPv6 resources. = Routers=0A= running both protocols can forward traffic for both IPv4 and IPv6 = end=0A= nodes.=0A= =0A= Dual-stack machines can use totally independent IPv4 and IPv6=0A= addresses, or they can be configured with an IPv6 address that=0A= is IPv4-compatible. Dual-stack nodes can use conventional IPv4=0A= autoconfiguration services (DHCP) to obtain their IPv4 addresses.=0A= IPv6 addresses can be manually configured in the 128-bit local = host=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 19]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= tables, or preferably obtained via IPv6 autoconfiguration = mechanisms.=0A= Major servers will run in dual-stack mode until all active nodes = are=0A= converted to IPv6.=0A= =0A= 1.3.11. Automatic Tunneling=0A= =0A= Automatic tunnels use "IPv4-compatible" addresses, which are = hybrid=0A= IPv4/IPv6 addresses. A compatible address is created by adding=0A= leading zeros to a 32-bit IPv4 address to pad it out to 128 bits.=0A= When traffic is forwarded with a compatible address, the device = at=0A= the tunnel entry point can automatically address encapsulated = traffic=0A= by simply converting the IPv4-compatible 128-bit address to a = 32-bit=0A= IPv4 address. On the other side of the tunnel, the IPv4 header = is=0A= removed to reveal the original IPv6 address. Automatic tunneling=0A= allows IPv6 hosts to dynamically exploit IPv4 networks, but it = does=0A= require the use of IPv4-compatible addresses, which do not bring = the=0A= benefits of the 128-bit address space.=0A= =0A= IPv6 nodes using IPv4-compatible addresses cannot take advantage=0A= of the extended address space, but they can exploit the other = IPv6=0A= enhancements, including flow labels, authentication, encryption,=0A= multicast, and anycast. Once a node is migrated to IPv6 with = IPv4=0A= compatibility, the door is open for a fairly painless move to the=0A= full IPv6 address space. IPv4-compatible addressing means that=0A= administrators can add IPv6 nodes while initially preserving = their=0A= basic address and subnet architecture. Automatic tunnels are=0A= available when needed, but they may not be necessary when major=0A= backbone routers are upgraded to include the IPv6 stack. = Upgrades=0A= can be achieved quickly and efficiently when backbone routers = support=0A= full remote configuration and upgrade capabilities.=0A= =0A= 2. The Technical Case for IPv6=0A= =0A= In this section, the technical aspects of IPv6 are discussed. In=0A= many cases, the technical details illustrate the concepts of the=0A= previous section. Other features are introduced as needed to = help=0A= provide a fuller understanding of the protocol.=0A= =0A= 2.1. IPv6 Headers vs. IPv4 Headers=0A= =0A= To start the technical look at IPv6, we compare the IPv6 header=0A= with the IPv4 header. Both headers carry version numbers and=0A= source/destination addresses, but as Figure 6 shows, the IPv6 = header=0A= is considerably simplified, which makes for more efficient = processing=0A= by routing nodes. Whereas IPv4 headers are potentially variable = in=0A= length, IPv6 headers have a fixed length of 40 bytes. This = allows=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 20]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= router software designers to optimize the parsing of IPv6 headers=0A= along fixed boundaries. Additional processing efficiencies have = been=0A= realized by reducing the number of required header fields in = IPv6.=0A= An IPv4 header, illustrated in figure 5 contains at least 12 = fields,=0A= depending on how they are counted, and can also contain = additional=0A= (and hard to parse) option fields, not illustrated in the figure.=0A= IPv6, on the other hand, only uses 8 fields.=0A= =0A= = +-------+-------+---------------+-------------------------------+=0A= |Version| 4 bits| 8 bits | 16 bits = |=0A= | =3D=3D 4 | IHL |Type of Service| Total Length = |=0A= = +-------+-------+---------------+-------------------------------+=0A= | 16 bits | 4 bits| 12 bits = |=0A= | Identification | Flags | Fragment Offset = |=0A= = +-------------------------------+-------------------------------+=0A= | 8 bits | 8 bits | 16 bits = |=0A= | Time to Live | Protocol | Header Checksum = |=0A= = +-------------------------------+-------------------------------+=0A= | 32 bits = |=0A= | Source Address = |=0A= = +---------------------------------------------------------------+=0A= | 32 bits = |=0A= | Destination Address = |=0A= = +---------------------------------------------------------------+=0A= : 0 or more bits = :=0A= : IP options = :=0A= = +---------------------------------------------------------------+=0A= =0A= Figure 5: IPv4 Header Format=0A= =0A= One of the first IPv4 components to be discarded was the header=0A= length field, which is clearly no longer required due to the = fixed=0A= header length of all IPv6 packets. The total length field of = IPv4=0A= has been retained in the guise of the IPv6 payload length field. = But=0A= this field does not include the length of the IPv6 header, which = is=0A= always assumed to be 40 bytes. The new payload length field can=0A= accommodate packets up to 64 KB in length. Even larger packets,=0A= called "jumbograms", can be passed between IPv6 nodes if the = payload=0A= length field is set to zero and a special extension header is = added,=0A= as discussed below.=0A= =0A= The time-to-live (TTL) field of IPv4 has been renamed the IPv6 = ``hop=0A= limit'' field, to describe more accurately its actual function. = The=0A= field is used to break loops, by decrementing a maximum hop value = by=0A= 1 for each hop of the end-to-end route. The hop-limit field is = set=0A= to the appropriate value by the source node. When the value in = the=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 21]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= = +-------+---------------+---------------------------------------+=0A= |Version| 8 bits | 20 bits = |=0A= | =3D=3D 6 | Traffic Class | Flow Label = |=0A= = +-------+---------------+-------+---------------+---------------+=0A= | 16 bits | 8 bits | 8 bits = |=0A= | Payload Length | Next Header | Hop Limit = |=0A= = +-------------------------------+---------------+---------------+=0A= | 128 bits = |=0A= | = |=0A= | Source Address = |=0A= = +---------------------------------------------------------------+=0A= | 128 bits = |=0A= | = |=0A= | Destination Address = |=0A= = +---------------------------------------------------------------+=0A= =0A= Figure 6: IPv6 Header Format=0A= =0A= hop limit field is decremented to zero, the packet is discarded. = The=0A= IPv6 hop-count field allows up to 255 hops, which exceeds the = needs=0A= for even the largest of networks, as best we can calculate today.=0A= =0A= In addition to the header length field, a number of basic IPv4=0A= fields were eliminated from the IPv6 header: fragment offset,=0A= identification, flags, checksum. The IPv4 type-of-service field = is=0A= replaced by the IPv4 traffic class field, plus the all-new flow = label=0A= field. The IPv4 fragmentation fields (offset, identification, = and=0A= flags) have been moved to optional headers in IPv6, as discussed = in=0A= section 2.6. Finally, the IPv4 checksum field has been abandoned = in=0A= IPv6, since error checking typically is duplicated at other = levels=0A= of the protocol stack. Bad packets will be detected below, at = the=0A= link-layer, or above, at the transport layer. Requiring routers = to=0A= perform error checking has caused reduced performance in today's=0A= Internet.=0A= =0A= 2.2. Extension Headers=0A= =0A= IPv4 headers include an options field, which conveys information=0A= about security, source routing, and other optional parameters.=0A= Unfortunately, options are poorly utilized because routers = typically=0A= offer degraded performance to packets that contained options.=0A= =0A= The IPv4 options field has been replaced in IPv6 by extension=0A= headers that are located after the primary IPv6 header and before = the=0A= transport header and application payload. IPv6 extension headers=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 22]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= provide security, fragmentation, source routing, and other = functions.=0A= There is no set limit on the number of extension headers between = the=0A= initial header and the higher layer payload. Since IPv6 = separates=0A= options into modular headers, processing should be simpler and = thus=0A= can remain on the fast path as needed. Figure 7 shows encryption = and=0A= fragmentation headers occurring after the primary IPv6 header and=0A= before the Transmission Control Protocol (TCP) header.=0A= =0A= = +----------+-------------------+----------------+-----------------=0A= | IPv6 Hdr | Fragmentation Hdr | Encryption Hdr | Transport, etc=0A= = +----------+-------------------+----------------+-----------------=0A= =0A= Figure 7: IPv6 Extension Headers=0A= =0A= The protocol type field (e.g., TCP or User Datagram Protocol = (UDP)),=0A= is has been replaced by the "Next Header" field; each header = field=0A= indicates the type of the next header, which can be a TCP/UDP = header,=0A= or another IPv6 extension header. IETF working groups have = already=0A= defined a number of extension headers for IPv6 and have suggested=0A= guidelines for the order of header insertion. The suggested = order=0A= for extension headers, if any are present, is as follows:=0A= =0A= - (Primary IPv6 header)=0A= - Hop-by-Hop options header=0A= - Destination options header-1=0A= - Source Routing header=0A= - Fragmentation header=0A= - Authentication header=0A= - IPv6 Encryption header=0A= - Destination options header-2=0A= =0A= followed by the upper layer headers and payload.=0A= =0A= Each extension header typically occurs only once within a given=0A= packet, except for the destination options header (as explained = in=0A= Section 2.4).=0A= =0A= 2.3. Hop-by-Hop Options Header=0A= =0A= When present, this header carries options that are examined by=0A= intermediate nodes along the forwarding path. It must be the = first=0A= extension header after the initial IPv6 header. Since this = header=0A= is read by all routers along the path, it is useful for = transmitting=0A= management information or debugging commands to routers. One=0A= currently defined application of the hop-by-hop extension header=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 23]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= is the Router Alert option, which informs routers that the packet=0A= should be processed completely by a router before it is forwarded = to=0A= the next hop. An example of such a packet is an RSVP [3] = resource=0A= reservation message for QoS.=0A= =0A= 2.4. Destination Options Headers=0A= =0A= There are two variations of this header, each with a different=0A= position in the packet. A Destination Options header appearing=0A= before a Routing Header will be processed by every node listed in=0A= the latter. A Destination Header appearing after a Routing = Header,=0A= or without a Routing Header, will be processed only by the final=0A= destination.=0A= =0A= 2.5. Routing Headers=0A= =0A= IPv6, in [10], defines a "Type 0" (zero) routing header, which = gives=0A= a sending node a great deal of control over each packet's route. = The=0A= IPv6 routing extension header replaces the loose source route = (LSR)=0A= option supported currently by IPv4. This optional header allows = a=0A= source node to specify a list of IP addresses that determine = which=0A= routing path a packet will traverse.=0A= =0A= IPv6's loose source routing (LSR)) is illustrated in Figure 8. = In=0A= "loose" forwarding, unlisted routers can be visited by a packet. = So,=0A= for example in figure 8 the packet could be routed from router 3=0A= through router 4 and then to router 5, even though router 4 was = not=0A= specified in the routing information field of the routing header.=0A= The source routing feature works in conjunction with another = routing=0A= header field that contains a value equal to the total number of=0A= segments remaining in the source route. Each time a hop is made,=0A= this "segments left" field is decremented.=0A= =0A= IPv6 corrects another deficiency in the specification of IPv4 = source=0A= routing options, by relaxing the requirement that destination = nodes=0A= reverse the source route for transmitting packets back to the = node=0A= originating the source route. This requirement is among the = reasons=0A= that IPv4 source routing has almost entirely fallen out of use,=0A= because it opens up a big security hole. If a source route were = to=0A= be reversed, without being sure that the source route was in fact=0A= originated by the indicated source node, then any other node = within=0A= the Internet could easily masquerade as that indicated source = node.=0A= IPv6 source routes, on the other hand, do not carry with them the=0A= same security exposure, since the recipient of such a routing = header=0A= is not required to use the information for sending packets back = to=0A= the source.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 24]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= IPv6 Packet=0A= +----------+-----+-------------------------------+- -- -- -- -- = --=0A= | IPv6 Hdr | ... | Route Information: 1, 2, 3, 5 | ...=0A= +----------+-----+-------------------------------+- -- -- -- -- = --=0A= =0A= +---+=0A= | X | +-------+ +-------+ +---+=0A= +---+ ---| rtr 4 |------------| rtr 5 |------| Y |=0A= \ / +-------+ +-------+ +---+=0A= \ / \=0A= +-------+ \ +-------+=0A= | rtr 1 | \--| rtr 3 |=0A= +-------+ +-------+=0A= \ /=0A= \ /=0A= +-------+ /=0A= | rtr 2 |--=0A= +-------+=0A= =0A= Figure 8: Source Routing Extension Header=0A= =0A= When Type 0 routing headers are used, the initial IPv6 header=0A= contains the destination addresses of the first router in the=0A= source route, not the final destination address. At each hop,=0A= the intermediate node replaces this destination address with the=0A= address of the next routing node, and the "segments left" field = is=0A= decremented.=0A= =0A= 2.6. Fragmentation Header=0A= =0A= IPv4 has the ability to fragment packets at any point in the=0A= path, depending on the transmission capabilities of the links=0A= involved. This feature has been dropped in IPv6 in favor of=0A= end-to-end fragmentation/reassembly, which is executed only by=0A= IPv6 source and destination nodes. Packet fragmentation is not=0A= permitted in intermediate IPv6 nodes. The elimination of the=0A= fragmentation field allows a simplified packet header design and=0A= better router performance for the great majority of cases where=0A= fragmentation is not required. Today's networks generally = support=0A= frame sizes that are large enough to carry typical IP packets = without=0A= fragmentation. In the event that fragmentation is required, IPv6=0A= provides an optional extension header that is used by source = nodes=0A= to divide packets into smaller units. If higher level protocols=0A= are using larger payloads, the source node can make use of the = IPv6=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 25]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= fragmentation extension header to divide large packets into = 1500-byte=0A= units for network transmission. The IPv6 destination node will=0A= reassemble these fragments in a manner that is transparent to = upper=0A= layer protocols and applications.=0A= =0A= The IPv6 fragmentation header contains fields that identify a = group=0A= of fragments as a packet and assigns them sequence numbers. The=0A= source node is responsible for sizing packets correctly, so it has = to=0A= determine the Maximum Transmission Unit (MTU) of the end-to-end = path,=0A= which is the smallest MTU of each link along the path. For = instance,=0A= if two FDDI networks with 4500-byte MTUs are connected by an = Ethernet=0A= with an MTU of 1500, then the source node must send packets that = are=0A= no larger than 1500.=0A= =0A= +--ICMP Datagram Too Big--<--+=0A= v |=0A= +---+ FDDI +-----+ FDDI +-----+ Ethernet +-----+ FDDI = +---+=0A= | X |--------| rtr |--------| rtr |--------------| rtr |--------| Y = |=0A= +---+ +-----+ +-----+ MTU =3D 1500 +-----+ = +---+=0A= | |=0A= +-->-MTU Discovery Message->-+=0A= =0A= Figure 9: MTU Discovery Process=0A= =0A= End nodes can determine the smallest MTU of a path with the MTU=0A= path discovery process [23]. Typically, with this technique, the=0A= source node probes the MTU by transmitting a packet with an MTU = as=0A= large as the local interface can handle (see Figure 9). If this=0A= MTU is too large for some link along the path, an ICMP "Datagram=0A= too big" message will be sent back to the source. This message=0A= will contain a packet-too-big indicator and the MTU of the = affected=0A= link. The source can then adjust the packet size downward = (fragment)=0A= and retransmit another packet. This process is repeated until a=0A= packet gets all the way to the destination node. The discovered=0A= MTU is then used for fragmentation purposes. Although = source-based=0A= fragmentation is fully supported in IPv6, it is recommended that=0A= network applications adjust packet size to accommodate the = smallest=0A= MTU of the path. This will avoid the drawbacks associated with=0A= fragmentation/reassembly on source and destination nodes.=0A= =0A= 2.7. IPv6 Security=0A= =0A= IPv6 has two security extension headers, one that enables the=0A= authentication of IP traffic for security purposes, and another = that=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 26]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= fully or partially encrypts IP packets. Implementation of = security=0A= at the IP level can benefit "security aware" applications, as well = as=0A= "security ignorant" applications that don't take explicit = advantage=0A= of security features.=0A= =0A= 2.8. IPv6 Authentication Header=0A= =0A= Using IPv6 authentication headers, hosts can verify the = authenticity=0A= and integrity of the IPv6 payload data. The authentication = header=0A= makes use of an established security association, that may, for=0A= instance, be based on the exchange of algorithm-independent = secret=0A= keys. In a client/server session, for instance, both the client=0A= and the server need to have knowledge of the key. Before each=0A= packet is sent, IPv6 authentication creates a Message Integrity=0A= Code (MIC) (using, e.g., MD5 [21]) based on the key convolved=0A= with the entire contents of the packet including data within the=0A= Authentication Extension to eliminate replay attacks. The MIC is=0A= then recomputed on the receiving side and compared. This = approach=0A= provides authentication of the sender and guarantees that data = within=0A= the packet has not been modified or replayed by an intervening = party.=0A= Authentication can take place between clients, or clients and = servers=0A= on the corporate backbone. It can also be deployed between = remote=0A= nodes and corporate dial-in servers to ensure that the perimeter = of=0A= the corporate security is not breached.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 27]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= 2.9. IPv6 Encryption Header=0A= =0A= <-------------- Unencrypted ---------------> <----- Encrypted = ----...=0A= = +-------------+----------------+------------+------------------------=0A= | IPv6 Header | Extension Hdrs | ESP Header | Transport Hdr & = Payload=0A= = +-------------+----------------+------------+------------------------=0A= =0A= Figure 10: Transport Mode of IPv6 Encryption=0A= =0A= <-----Unencrypted--------> <--------- Encrypted = ----------------...=0A= = +--------+--------+-------+--------+--------+-------+---------------=0A= |IPv6 Hdr|Ext.Hdrs|ESP Hdr|IPv6 Hdr|Ext.Hdrs|ESP = Hdr|Transpt/Payload=0A= = +--------+--------+-------+--------+--------+-------+---------------=0A= <-Encapsulating Headers--> <--------- Original Packet = -------.......=0A= =0A= Figure 11: Tunnel Mode of IPv6 Encryption=0A= =0A= Authentication headers eliminate a number of host spoofing and = packet=0A= modification attacks, but they do not prevent passively reading=0A= of data traversing the Internet and corporate backbone networks.=0A= This protection is offered by the Encapsulating Security Payload=0A= (ESP) service of IPv6 -- another optional extension header. = Packets=0A= protected by the ESP encryption techniques can have very high = levels=0A= of privacy and integrity -- something that is not widely = available=0A= with the current Internet, except with certain secure = applications=0A= (e.g., private electronic mail and secure HTTP Web servers). ESP=0A= provides encryption at the network layer, making it available to = all=0A= applications in a standardized fashion.=0A= =0A= IPv6 ESP is used to encrypt the transport-layer header and = payload=0A= (e.g., TCP, UDP), or else the appropriate IPv6 header fields = along=0A= with the payload. Both these methods are accomplished with an = ESP=0A= extension header that carries encryption parameters end-to-end. = When=0A= just the transport payload is to be encrypted, the ESP header is=0A= inserted in the packet directly before the TCP or other transport=0A= header. In this case, the headers before the ESP header are not=0A= encrypted and the headers and payload after the ESP header are=0A= encrypted. This is referred to as "transport-mode" encryption, = and=0A= is illustrated in figure 10. If it is desirable to encrypt the=0A= entire IP datagram, a new IPv6 and an ESP header are wrapped = around=0A= all the fields (including the initial address fields) of the = packet.=0A= Full datagram encryption is sometimes called "tunnel-mode" = encryption=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 28]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= because the payload of the datagram is unintelligible except at = the=0A= endpoints of the security tunnel (see Figure 11).=0A= =0A= Fully encrypted datagrams are somewhat more secure than transport=0A= mode encryption because the headers of the fully encrypted packet = are=0A= not available for traffic analysis.=0A= =0A= For instance, full tunnel-mode encryption allows the addresses=0A= contained in IPv6 source routing headers to be hidden from packet=0A= sniffing devices for the public portion of a path. This is in=0A= addition to the typical use of tunnel-mode encryption for the=0A= purposes of creating a private link. There is a considerable=0A= performance penalty for full encryption, due to the overhead and=0A= processing cost of adding an additional IPv6 header to each = datagram.=0A= In spite of its cost, full ESP encryption is particularly = valuable=0A= to create a security tunnel (steel pipe) between the firewalls of=0A= two remote sites (see Figure 12). The full datagram encryption=0A= in the tunnel ensures that the various headers and address fields=0A= of encrypted packets will not be visible as traffic traverses the=0A= public Internet. Within the tunnel, only the temporary = encapsulating=0A= address header is visible. Once through the tunnel and safely = within=0A= a firewall, the leading ESP headers are stripped off and the = packet=0A= is again visible, including any source routing headers required = to=0A= finish the path.=0A= =0A= ~~ ~~=0A= F~ ~F=0A= +--------+ i~ +--------------------+ ~i = +--------+=0A= | | r~ | | ~r | = |=0A= | Site 1 | e~ | Public Internet | ~e | Site 2 = |=0A= | | ---------------------------------------- | = |=0A= | <-------( - - - - - - ESP Steel Pipe - - - - - -()<-----<-- = |=0A= | | ---------------------------------------- | = |=0A= | | w~ | | ~w | = |=0A= | | a~ | | ~a | = |=0A= | | l~ +--------------------+ ~l | = |=0A= +--------+ l~ ~l = +--------+=0A= ~~ ~~=0A= =0A= Figure 12: Firewalls and Steel Pipe=0A= =0A= The encryption and authentication services of IPv6 together=0A= create the security solution often needed by business and = military=0A= applications. An authentication header is typically be carried=0A= inside an encrypted datagram, providing an additional layer of = data=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 29]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= integrity and verification of the sender's identification. In = other=0A= cases, the authentication header may be placed in front of the=0A= encrypted transport-mode portion of the packet. This approach is=0A= desirable when the authentication takes place before decryption = on=0A= the receiving end, which is the logical order in many cases. = Taken=0A= together, the authentication and encryption services of IPv6 = provide=0A= a robust, standardsbased security mechanism that will play a = decisive=0A= role in the continuing expansion of commerce and corporate = operations=0A= onto IP-based network fabrics.=0A= =0A= 2.10. The IPv6 Address Architecture=0A= =0A= Much of the discussion of IPv4 versus IPv6 focuses on the = relative=0A= size of the address fields of the two protocols (32 bits versus=0A= 128 bits). But an equally important difference is the relative=0A= abilities of IPv6 and IPv4 to provide a hierarchical address = space=0A= that facilitates efficient routing architectures. IPv4 was = initially=0A= designed with class A, class B, and class C addresses, which = divided=0A= address bits between network and host but did not create a = hierarchy=0A= that would allow a single highlevel address to represent many=0A= lowerlevel addresses. Hierarchical address systems work in much=0A= the same way as telephony country codes or area codes, which = allow=0A= long-haul phone switches to route calls efficiently to the = correct=0A= country or region using only a portion of the full phone number.=0A= =0A= As the Internet grew, the non-hierarchical nature of the original=0A= IPv4 address space proved inadequate. This problem has been = improved=0A= by use of CIDR (see section 1.2.1), but legacy address = assignments=0A= still hamper routing within the Internet. These legacy = assignments=0A= limit both local and global levels of internetworking. To combat=0A= IPv4 deficiencies at the local area network level, the subnetting=0A= technique has been developed to create a more manageable division = of=0A= large networks. Using subnets, a single network address can = stand=0A= for a number of physical networks, a technique that conserves = address=0A= space considerably. For example, a single Class B address can be=0A= used to access hundreds of physical networks, each of which = itself=0A= could have dozens or hundreds of individual hosts.=0A= =0A= At the level of large internet backbones and global routing, IPv4=0A= addresses can be more efficiently aggregated with supernetting, a=0A= form of hierarchical addressing. With supernetting, backbone = routers=0A= store a single address that represents the path to a number of = lower=0A= level networks. This can considerably reduce the size of routing=0A= tables in backbone routers, which increases backbone performance=0A= and lowers the amount of memory and number of route processors=0A= required. Subnetting and supernetting have been particularly = useful=0A= in extending the viability of the IPv4 Class C addresses. Both = of=0A= these techniques are made possible by associating addresses stored = in=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 30]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= routers to bit masks that indicate which bits in an address are = valid=0A= at the various levels of the hierarchy.=0A= =0A= The process of creating an IPv4 routing hierarchy was formalized=0A= in CIDR, as discussed in Section 1.2.1. For instance, CIDR = allows=0A= a number of (plentiful) Class C addresses to be summarized by a=0A= single prefix address, allowing Class C addresses to function in=0A= a similar way to hard-to-get Class A and Class B addresses. CIDR=0A= has extended the life of IPv4 and helped the Internet scale to = its=0A= current size, but it has not been implemented in a consistent way=0A= across the Internet and enterprise networks. Consequently, the = route=0A= table efficiencies and address space conservation advantages of = CIDR=0A= are not today fully realized, nor will they ever be fully = realized,=0A= due to the legacy nature of IPv4 networks and the difficulty of=0A= restructuring them. IPv4 will continue to waste a larger = proportion=0A= of its address space, and to burden routers with inefficient = routes=0A= and excessively large routing tables.=0A= =0A= At the departmental and workgroup level of internetworking, IPv4=0A= engenders a high administrative workload associated with = maintaining=0A= subnet bit masks and host addresses within the subnet structure,=0A= particularly where there are large, dynamic populations of end = users.=0A= When an end user is moved in the subnetting environment, careful=0A= attention must be paid to ensure that the host renumbering = process=0A= does not disrupt the ability of the user to make effective use of = the=0A= network. The complexities and pitfalls of current subnetting = methods=0A= can eventually make IPv4 less than viable in large organizations = that=0A= experience growth of internetwork user populations (especially at=0A= current rates of growth). IPv6, with its greater subnetting = space,=0A= makes the job of aggregating and administering networks much = easier=0A= and more flexible.=0A= =0A= 2.11. The IPv6 Address Hierarchy=0A= =0A= Motivated by the experience gained from IPv4, IPv6 designers made=0A= sure from the very beginning to provide a scalable address space = that=0A= can be partitioned into a efficient global routing hierarchy. At=0A= the top of this hierarchy, several international registries = assign=0A= blocks of addresses to top level aggregators (TLA). TLAs allocate=0A= blocks of addresses to Next Level Aggregators (NLA), which = represent=0A= large providers and global corporate networks. When an NLA is a=0A= provider, it further allocates its addresses to its subscribers.=0A= Routing is efficient because NLAs that are under the same TLA = will=0A= have addresses with a common TLA prefix. Subscribers with the = same=0A= provider have IP addresses with an NLA common prefix. See Figure = 13=0A= for an example of Aggregation-based Allocation Structures. = Although=0A= a number of allocation schemes are possible within IPv6's huge=0A= address space, an aggregation-based hierarchy is favored by IETF=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 31]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= +-----------+ +-----------+=0A= | Long-Haul | - - - - - - - - - - - - -| Long-Haul |=0A= | Provider | | Provider |=0A= +-----------+ +-----------+=0A= | \ /=0A= \--------\ /------------------/=0A= | +---------------+=0A= | Interexchange | - - - - - - ---> To other=0A= | | (TLA) | interexchanges=0A= +---------------+=0A= | /--------/ | \ \---------------\=0A= | / | \ \=0A= +-----------+ +--------+ \ +-----------+=0A= | Long-Haul | |Provider| \ | Long-Haul |=0A= | Provider | +--------+ | | Provider |=0A= +-----------+ | | +-----------+=0A= | | | | |=0A= +----------+ | | +----------+ +----------+=0A= |Subscriber| | | |Subscriber| | Provider |=0A= +----------+ | \ +----------+ +----------+=0A= +----------+ \ |=0A= |Subscriber| \ |=0A= +----------+ +----------+ +----------+=0A= |Subscriber| |Subscriber|=0A= +----------+ +----------+=0A= =0A= Figure 13: Aggregation-based Allocation Structures=0A= =0A= designers because it allows a choice between various allocation=0A= approaches. Provider allocation divides the hierarchy along lines = of=0A= large service providers, regardless of their location. = Geographic=0A= allocation divides the hierarchy strictly on the basis of the=0A= location of providers/subscribers (as does the telephony system=0A= of country and area codes). Both of these approaches have their=0A= drawbacks because large backbone networks often don't conform=0A= strictly to geographic or provider boundaries. Some large = networks,=0A= for instance, may connect to several ISPs; many large networks = span=0A= numerous countries and geographical regions.=0A= =0A= Aggregation-based allocation is based on the existence today of a=0A= limited number of highlevel exchange points, where large = long-haul=0A= service providers and telephone networks interconnect. The use=0A= of these exchange points to divide the IPv6 address hierarchy has=0A= a geographical component because exchanges are distributed around=0A= the globe. It also has a provider orientation because all large=0A= providers are represented at one or more exchange points.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 32]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= | 3| 13 | 8 | 24 | 16 | 64 bits = |=0A= = +--+-----+---+--------+--------+--------------------------------+=0A= |FP| TLA |RES| NLA | SLA | Interface ID = |=0A= | | ID | | ID | ID | = |=0A= = +--+-----+---+--------+--------+--------------------------------+=0A= <--Public Topology---> Site=0A= <-------->=0A= Topology=0A= <------Interface = Identifier----->=0A= =0A= Figure 14: Aggregation-based IPv6 Addresses=0A= =0A= As shown in Figure 14, the first 3 address bits indicate what = type=0A= of address follows (unicast, multicast, etc.). The next 13 bits=0A= are allocated to the various TLAs around the world. Eight bits = are=0A= reserved for future use, and the following 24 bits are allocated = to=0A= the next lower level of providers and subscribers.=0A= =0A= Next level aggregators can divide the NLA address field to create=0A= their own hierarchy, one that maps well to the current ISP = industry,=0A= in which smaller ISPs subscribe to higher level ISPs, and so on.=0A= This is accomplished by the further subdivision of the 32-bit=0A= NLA field (see Figure 15). Following the NLA ID are fields for=0A= =0A= <------------ 32 bits -----------> <--16 bits-> <---- 64 bits = ---->=0A= = +-------+-------------------------+------------+-------------------+=0A= | NLA 1 | Site | SLA | Interface ID = |=0A= = +-------+-------------------------+------------+-------------------+=0A= = +-------+-----------------+------------+-------------------+=0A= | NLA 2 | Site | SLA | Interface ID = |=0A= = +-------+-----------------+------------+-------------------+=0A= = +-----------------+------------+-------------------+=0A= | NLA 3 | Site | SLA | Interface ID = |=0A= = +-----------------+------------+-------------------+=0A= =0A= Figure 15: Subdividing the NLA Address Space=0A= =0A= subscriber site networking information: Site Level Aggregator = (SLA)=0A= and Interface ID. Typically, service providers supply subscribers=0A= with blocks of contiguous addresses, which are then used by=0A= individual organizations to create their own local address = hierarchy=0A= and identify subnets and hosts. The 16-bit SLA field supports up = to=0A= 65,535 individual subnets. The 64-bit Interface ID, which is = used=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 33]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= to identify an IPv6 interface on a network link, will typically = be=0A= derived from the installed MAC address. Large sites are expected = to=0A= get an entire SLA.=0A= =0A= Internet backbone routers must maintain 40,000 or more routes. = As=0A= the Internet continues to grow in size, IPv6's uniform = application=0A= of hierarchical routing will likely be the only viable method for=0A= keeping the size of backbone router tables under control. With = an=0A= aggregator-based address hierarchy, all of a subscriber's = internal=0A= network segments can be reached through one or more highlevel=0A= aggregation points. This allows backbone routers around the = globe=0A= to efficiently summarize the routes to a customer's networks with=0A= highlevel TLA address prefixes. Forwarding routes in the highest=0A= level backbones can be quickly calculated by looking only at the = TLA=0A= portion of the address. IPv6's large hierarchical address space=0A= also allows a more decentralized approach to IP address = allocation.=0A= Service providers can allocate addresses independently from = central=0A= authorities, encouraging global network growth and eliminating=0A= bureaucratic bottlenecks in the growth process.=0A= =0A= Aggregation-based addresses are just part of the total address=0A= space that has been defined for IPv6. Other address ranges have=0A= been assigned to multicasting and to nodes that only require=0A= unique addresses within a limited area (site-local and link-local=0A= addresses).=0A= =0A= Site-local and link-local addresses are available for private,=0A= internal use by all enterprises, and are not allocated by public=0A= registry authorities. Site-local addresses enable two separate=0A= domains to use the same non-unique addresses that never collide=0A= because site-local routing restrictions keep them apart. This = has=0A= an advantage: if an ISP changes, site local addresses can remain=0A= the same because they do not directly connect to the outside = world.=0A= Link local addresses operate only over a single link, and can be = used=0A= for temporary "bootstrapping" of network nodes before they receive = a=0A= globally unique address (more on this in section 2.12).=0A= =0A= 2.12. Host Address Autoconfiguration=0A= =0A= IPv6 has a large enough address architecture [17] to accommodate=0A= Internet expansion for many decades to come. Furthermore, IPv6 = hosts=0A= can have their addresses automatically configured and reconfigured = in=0A= a cost-effective and manageable way. Automatic address = configuration=0A= is necessary in hierarchical routing because it supports scalable=0A= (and thus cost-effective) numbering and renumbering of large=0A= populations of IP hosts. Even a small renumbering cost, if = incurred=0A= tens of thousands of times for every ISP connection, adds up to a=0A= major administrative headache. Conversely, scalable renumbering=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 34]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= techniques will enable business enterprises to shop for the best=0A= connectivity solutions with reduced renumbering costs of = reconnection=0A= to a new provider.=0A= =0A= Autoconfiguration capabilities are important regardless of which=0A= style of address allocation is in effect. Occasionally, it may = be=0A= necessary to renumber every host within an organization, as would=0A= be the case with a company that relocated its operations (with=0A= geographic addressing) or changed to another service provider = (with=0A= provider-based addressing). Configuration of IP addresses is a = fact=0A= of life at the workgroup and department levels of large networked=0A= organizations. IP addresses need to be configured for new hosts,=0A= for hosts that change location, and for hosts connected to = physical=0A= networks that receive address modification (e.g., a new prefix). = In=0A= addition to these traditional requirements for configuration, new=0A= requirements are emerging as large numbers of hosts become = mobile.=0A= These requirements for reduced static configuration of router=0A= addresses, route parameters, and server addresses, are basically = not=0A= met in any meaningful way for use with the existing IPv4 = installed=0A= base.=0A= =0A= The process of autoconfiguration under IPv6 starts with the = Neighbor=0A= Discovery (ND) protocol [25]. ND combines and refines the = services=0A= provided in the IPv4 environment by Address Resolution Protocol=0A= (ARP) [28], Internet Control Message Protocol (ICMP) [29], and = Router=0A= Advertisement [12]. Although it has a new name, ND is actually = just=0A= a set of complementary ICMPv6 [7] messages that allow IPv6 nodes = on=0A= the same link to discover link-layer addresses and to obtain and=0A= advertise various network parameters and reachability = information.=0A= In a typical scenario, a host starts the process of = autoconfiguration=0A= by creating a link-local address [34]. This address can be formed = by=0A= adding a generic local address prefix to a unique token = (typically=0A= derived from the host's IEEE LAN interface address [18]). Once = this=0A= address is formed, the host sends out an ND message to ensure = that=0A= the address is unique. If no ICMP Neighbor Soliciation message=0A= comes back, the address is presumed unique. If a message comes = back=0A= indicating that the link-local address is already in use, then a=0A= different token can be used (e.g., an administrative token, = manually=0A= generated, or a randomly generated token).=0A= =0A= Using the new link local address as a source address, the host = then=0A= sends out an ND router solicitation, or waits for a periodic = router=0A= advertisement. The solicitation is sent out using the IPv6 = multicast=0A= service. Unlike the broadcast ARPs of IPv4, IPv6 ND multicast=0A= solicitations are not necessarily processed by all nodes on the = link,=0A= which can conserve processing resources in hosts. IPv6 currently=0A= defines several permanent multicast groups for finding resources = on=0A= the local node or link, including an all-routers group, an = all-hosts=0A= group, and a DHCP server group. Routers respond to solicitation=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 35]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= messages from hosts with a router advertisement that contains,=0A= among other things, prefix information that indicates a valid = range=0A= of addresses for the subnet. The ND message exchange is shown in=0A= Figure 16. Routers also send unsolicited advertisements = periodically=0A= to local multicast groups.=0A= =0A= +---+ +---+=0A= | Y |---------------------| Z |=0A= +---+ +---+=0A= / \=0A= ----/ \-----=0A= / \=0A= +---+ ----- Router Solicitation ------> +-----+=0A= | X | | rtr |=3D=3D=3D=3DTo = Internet=0A= +---+ <----- Router Advertisement ----- +-----+=0A= \ /=0A= ---- -----=0A= \ /=0A= \ /=0A= +---+ +---+=0A= | W |---------------------| V |=0A= +---+ +---+=0A= =0A= Figure 16: Neighbor Discovery (ND) Router Message Exchange=0A= =0A= The router advertisement message controls whether hosts use = stateless=0A= or stateful autoconfiguration methods. In the case of stateful=0A= autoconfiguration, the host will contact a stateful address = server,=0A= which will assign an address from a manually administered list.=0A= DHCP [14] is the protocol of choice for autoconfiguration in IPv4=0A= networks and has been reformulated for the IPv6 environment [2, = 27].=0A= =0A= With the stateless approach [34], a host can automatically = configure=0A= its own IPv6 address without the help of a stateful address = server=0A= or any human intervention. The host uses the globally valid = address=0A= prefix information in the router advertisement message to create = its=0A= own IPv6 address. This process involves the concatenation of a = valid=0A= prefix with the host's link-layer address or a similar unique = token.=0A= As long as the token is unique on the link and the prefix = received=0A= from the router is correct, the newly configured IP address = should=0A= provide reachability for the host extending to the entire = enterprise=0A= and the Internet at large.=0A= =0A= The advantages of stateless autoconfiguration are many. For=0A= instance, if an enterprise changes service providers, the prefix=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 36]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= information from the new provider can be propagated to routers=0A= throughout the enterprise, and hence to all stateless = autoconfiguring=0A= hosts. Hypothetically, if all hosts in the enterprise use IPv6=0A= stateless autoconfiguration, the entire enterprise could be=0A= renumbered without the manual configuration of a single = non-router=0A= host. At a more modest level, workgroups with substantial=0A= move/change activity also benefit from stateless = autoconfiguration=0A= because hosts can receive a freshly configured and valid IP = number=0A= each time they connect and reconnect to the network.=0A= =0A= +-------+=0A= | Home |=0A= | Agent |\=0A= +-------+ \ +---------------------+=0A= \ | |=0A= ----------+ | +---+=0A= | | /------------------| X |=0A= ----------+ <----/ | +---+=0A= / | |=0A= / +---------------------+=0A= /=0A= +--------+/=0A= | Mobile |=0A= | Node |=0A= +--------+=0A= =0A= Figure 17: Forwarding IP Traffic for Mobile IPv6 Nodes=0A= =0A= Address autoconfiguration plays an essential role in the support=0A= for mobile nodes within IPv6. Each mobile node can configure an=0A= appropriate address, no matter which network it is attached to; = it=0A= uses this address as a kind of forwarding address (or, as it is=0A= called, a "care-of address"). Then, the mobile node can receive=0A= all of its data from its home network by asking a router (called = a=0A= "home agent") to forward packets to it at its care-of address. = This=0A= process is illustrated in figure 17. Better yet, the mobile node=0A= can also instruct any other node (e.g., node 'X' in the figure) = to=0A= forward data to its care-of address, so that the data never = traverses=0A= the home network. Although not shown by the figure, the mobile=0A= node is identified by its home address, even though it is = receiving=0A= packets sent to its care-of address. This is important so that = the=0A= mobile node can maintain its connections even when it is wireless=0A= and undergoing handoff operations during continued operation of = its=0A= network applications.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 37]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= To facilitate dynamic host renumbering, IPv6 has a built-in=0A= mechanism to create a graceful transition from old to new = addresses.=0A= Fundamental to this mechanism is the ability of IPv6 nodes to = support=0A= multiple addresses per interface. IPv6 addresses assigned to an=0A= interface can be identified as valid, deprecated, or invalid. In=0A= the renumbering process, an interface's IPv6 address would become=0A= deprecated when a new address was automatically assigned (e.g., = in=0A= the case of network renumbering). For a period of time after the = new=0A= (valid) address is configured, the deprecated address continues = to=0A= send and receive traffic. This allows sessions and = communications=0A= based on the older address to be finished gracefully. Eventually=0A= the deprecated address becomes invalid and the valid address is = used=0A= exclusively. Issuing multiple IP addresses allows renumbering to=0A= occur dynamically and transparently to end users and = applications.=0A= Besides simplifying host renumbering, IPv6 has work underway to = help=0A= with reconfiguring routers [8].=0A= =0A= The above described stateless autoconfiguration process is=0A= particularly suited to conventional IP/LAN environments with = 48-bit=0A= or 64-bit addressing [18] and native multicast services. Other=0A= network environments with different link characteristics may = require=0A= modified or alternative configuration techniques. For instance,=0A= current ATM networks do not inherently support multicast services=0A= or IEEE MAC addresses, due to the use of virtual circuits and=0A= telephony-style calling numbers. Multicasting solutions for ATM = are=0A= seen in the emerging Multicast Address Resolution Server (MARS) = [32]=0A= that is being developed for IPv4 multicast over ATM. Plans are = being=0A= devised to use MARS-style functionality to extend the IPv6 = Neighbor=0A= Discovery protocol across ATM networks. This would allow network=0A= renumbering and stateless autoconfiguration to take place = seamlessly=0A= in hybrid ATM/IPv6 fabrics.=0A= =0A= 2.13. Other Protocols and Services=0A= =0A= The preceding discussion focuses on some of the more innovative=0A= and radical changes that IPv6 brings to internetworking. In many=0A= other areas, protocols and services will operate much the same as=0A= they do in the current IPv4 regime. As the industry moves to = IPv6,=0A= PPP, DHCP and DNS servers are being modified to accommodate = 128-bit=0A= addresses, but in terms of basic functionality, there will be = little=0A= change. This is also generally true for interior and exterior=0A= routing protocols.=0A= =0A= For example, OSPF is being updated with full support for IPv6 = [6],=0A= allowing routers to be addressed with 128-bit addresses. The = 32-bit=0A= link-state records of current OSFP will be replaced by 128-bit=0A= records. In general, the OSPF IPv6 link-state database of = backbone=0A= routers will run in parallel with the database for IPv4 = topologies.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 38]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= In this sense, the two versions of OSPF will operate as "ships in = the=0A= night," just as the routing engines for IPv4, OSI and proprietary=0A= protocols may coexist in the same router without major = interaction.=0A= Given the limited nature of the OSPF IPv6 upgrade, those = engineers=0A= and administrators who are proficient in OSPF for IPv4 should have = no=0A= problems adapting to the new version. An updated version of RIP = is=0A= also available [22].=0A= =0A= As with the interior gateway protocols, RFC 2545 provides a=0A= IPv6-compatible version of the exterior gateway protocols that=0A= are used by routers to establish reachability across the Internet=0A= backbone between large enterprises, providers, and other = autonomous=0A= systems. Today's backbone routers use the Border Gateway = Protocol=0A= (BGP) to distribute CIDR-based routing information throughout the=0A= Internet. BGP is known by providers and enterprises and has a=0A= large installed base. Currently, work is underway to define BGP=0A= extensions to exchange reachability information based on the new = IPv6=0A= hierarchical address space.=0A= =0A= 3. Transition Scenarios=0A= =0A= Section 1 of this paper provided an overview of the major = transition=0A= mechanisms that are integral to the IPv6 design effort. These=0A= techniques include dual-stack IPv4 /IPv6 hosts and routers, = tunneling=0A= of IPv6 via IPv4, and a number of IPv6 services, including IPv6 = DNS,=0A= DHCP, MIBs, and so on. The flexibility and usefulness of the = IPv6=0A= transition mechanisms are best gauged through scenarios that = address=0A= real-world networking requirements.=0A= =0A= 3.1. First Scenario: No Need to NAT=0A= =0A= Take, for instance, the case of two large, network-dependent=0A= organizations that must interface operations due to a merger and=0A= acquisition (M&A), or a new business partnership. Suppose both=0A= of the enterprises have large IPv4-based networks that have grown=0A= from small beginnings. Both of the original enterprises have a=0A= substantial number of private IPv4 addresses that are not = necessarily=0A= unique within the current global IPv4 address space. Combining = these=0A= two non-unique address spaces could require costly renumbering = and=0A= restructuring of routers, host addresses, domains, areas, exterior=0A= routing protocols, and so on. This scenario is common in the = current=0A= business climate, not only for Merger and Acquisition (M&A) = projects,=0A= but also for large outsourcing and customer/supplier networking=0A= relationships, where many hosts from the parent, outsourcer,=0A= supplier, or partner must be integrated into one existing = enterprise=0A= address structure. For these situations, IPv6 offers a = convenient=0A= solution.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 39]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= -------------- --------------=0A= / \ / \=0A= | Enterprise | +----------+ | Enterprise |=0A= | A |-------| IPv6 rtr |-------| B |=0A= \ / +----------+ \ /=0A= -------------- --------------=0A= ^ |=0A= | |=0A= | v=0A= +-------+ +-------+=0A= |IPv4 + | IPv6 communication |IPv4 + |=0A= | IPv6| - - - - - - - - - - - - - > | IPv6|=0A= | Host | | Host |=0A= +-------+ +-------+=0A= =0A= Figure 18: IPv6 Unites Private Address Spaces=0A= =0A= The task of logically merging two enterprise networks into a = single=0A= autonomous domain can be expensive and disruptive. To avoid the=0A= cost and disruption of comprehensive renumbering, enterprises=0A= may be tempted to opt for the stopgap solution of a network=0A= address translator (NAT). In the M&A scenario, a NAT could allow=0A= the two enterprises to maintain their private addresses more or=0A= less unchanged. To accomplish this, a NAT must conduct address=0A= translation in real time for all packets that move between the = two=0A= organizations. Unfortunately, this solution introduces all the=0A= problems associated with NATs that were discussed in section = 1.2.2,=0A= including performance bottlenecks, lack of scalability, lack of=0A= standards, and lack of universal connectivity among all the nodes = in=0A= the new enterprise and the Internet.=0A= =0A= In contrast with NAT, IPv6 seamlessly integrates the two physical=0A= networks (see Figure 18). Suppose the two originally independent=0A= enterprises are known as Enterprise A and Enterprise B. The first=0A= step is to determine which hosts need access to both sides of the=0A= new organization. These hosts are outfitted with dual IPv4/IPv6=0A= stacks, which allow them to maintain connectivity to their = original=0A= IPv4 network while also participating in a new IPv6 logical=0A= network that will be created "on top" of the existing IPv4 = physical=0A= infrastructure.=0A= =0A= The accounting department of the combined enterprise will often = have=0A= financial applications on servers that will need to be accessed=0A= by accounting employees in both Enterprise A and Enterprise B.=0A= Both servers and clients will run IPv6, but they will also retain=0A= their IPv4 stacks. The IPv6 sessions of the accounting = department=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 40]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= will traverse the existing local and remote links as "just = another=0A= protocol," requiring no changes to the physical network. The = only=0A= requirement for IPv6 connectivity is that routers that are = adjacent=0A= to accounting department users must be upgraded to run IPv6. = Where=0A= end-to-end IPv6 connectivity can't be achieved, one of the = IPv4/IPv6=0A= tunneling techniques can be employed.=0A= =0A= As integration continues, other departments in the newly merged=0A= enterprises will also be given IPv4/IPv6 hosts. As new = departments=0A= and workgroups are added, they may be given dual-stack hosts, or = in=0A= some cases, IPv6-only hosts. Hosts that require communications = to=0A= the outside world via the Internet will likely receive dual stacks = to=0A= maintain compatibility with IPv4 nodes exterior to the = enterprise.=0A= But in some cases, hosts that only require access to internal = servers=0A= and specific outside partners may be able to achieve connectivity=0A= with IPv6-only hosts. A migration to IPv6 presents the = opportunity=0A= for a fresh start in terms of address allocation and routing = protocol=0A= structure. IPv6 hosts and routers can immediately take advantage=0A= of IPv6 features such as stateless autoconfiguration, encryption,=0A= authentication, and so on.=0A= =0A= 3.2. Second Scenario: IPv6 from the Edges to the Core=0A= =0A= For corporate users, connectivity requirements typically focus=0A= primarily on access to local e-mail, WWW, database, and = applications=0A= servers. In this case, it may be best to initially upgrade only=0A= isolated workgroups and departments to IPv6, with backbone router=0A= upgrades implemented at a slower rate. IPv6 protocol development = is=0A= more complete for "edge" routing than for highlevel backbone = routing,=0A= so this is an excellent way for enterprises to gracefully = transition=0A= into IPv6. As shown in Figure 19, independent workgroups can = upgrade=0A= their clients and servers to dual-stack IPv4/IPv6 hosts or = IPv6-only=0A= hosts. This creates "islands" of IPv6 functionality.=0A= =0A= As enterprise-scale routing protocols such as OSPF and BGP for = IPv6=0A= mature, the core backbone IPv6 connections can be deployed. = After=0A= the first few IPv6 routers are in place, it may be desirable to=0A= connect IPv6 islands together with router-to-router tunnels. In=0A= this case, one or more routers in each island would be configured=0A= as tunnel endpoints. As illustrated in section 1, in figure 4,=0A= when hosts use full IPv6 128-bit addressing, tunnels are manually=0A= configured so that the routers participating in tunnels know the=0A= address of the endpoints of the tunnel. With IPv4-compatible = IPv6=0A= addresses, automatic, nonconfigured tunneling is possible.=0A= =0A= Routing protocols treat tunnels as a single IPv6 hop, even if=0A= the tunnel is comprised of many IPv4 hops across a number of=0A= different media. IPv6 routers running OSPF can propagate = link-state=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 41]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= IPv6 "Island" IPv6 "Island"=0A= -------------------- --------------------=0A= | | | |=0A= | Dual Stack Hosts | | Dual Stack Hosts |=0A= | +---+ +---+ | | +---+ +---+ |=0A= | | | | | | | | | | | |=0A= | +---+ +---+ | | +---+ +---+ |=0A= | | | | | | | |=0A= | \ / | | \ / |=0A= | +-------+ | | +-------+ |=0A= | | Dual | | | | Dual | |=0A= | | Stack | | | | Stack | |=0A= | | Router| | | | Router| |=0A= | +-------+ | | +-------+ |=0A= | | | |=0A= -------------------- --------------------=0A= \ /=0A= \ /=0A= +------+ +------+=0A= IPv4 | IPv4 |-------------------| IPv4 | IPv4=0A= Hosts | rtr | | rtr | Hosts=0A= +---+ +------+ IPv4 +------+ +---+=0A= | X |-\ / \ infrastructure / \ /-| W |=0A= +---+ \ / \-------\ /--------/ \ / +---+=0A= \ / \ / \ /=0A= +---+ \ +-----+ +-----+ +-----+ / +---+=0A= | Y |------| rtr |----------| rtr |---------| rtr |------| Z |=0A= +---+ +-----+ +-----+ +-----+ +---+=0A= =0A= Figure 19: Islands of IPv6=0A= =0A= reachability advertisements through tunnels, just as they would=0A= across conventional point-to-point links. In the IPv6 = environment,=0A= OSPF can ensure that each tunnel is weighted properly within the=0A= topology. Routers generally make packet-forwarding decisions in = the=0A= tunneling environment in the same way as in the IPv6-only = network.=0A= The underlying IPv4 connections are essentially transparent to = IPv6=0A= routing protocols.=0A= =0A= 3.3. Other mechanisms=0A= =0A= Additional mechanisms for transition or for IPv4/IPv6 coexistence=0A= are also under discussion. For example, IPv4 multicast can be = used=0A= to support neighbor discovery by isolated IPv6 nodes [5]. There = are=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 42]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= several proposals on how to support transactions between = IPv4-only=0A= nodes and IPv6 nodes that do not have IPv4-compatible addresses.=0A= =0A= IETF members are putting intense effort into transition, as well=0A= as the basic IPv6 protocol specification. The combination of=0A= tunnels, compatible addresses, and dual-stack nodes gives network=0A= administrators the range of flexibility and interoperability they=0A= need to deploy IPv6. Transition services allow organizations=0A= depending upon current IPv4 networks to take advantage of the = more=0A= technical IPv6 features.=0A= =0A= 4. Security Considerations=0A= =0A= Sections 1.2.4, 2.8, and 2.9 of this paper emphasize the security=0A= benefits that IPv6 offers. By adopting IPv6, the Internet and = the=0A= enterprise-specific applications will be much better able to = satisfy=0A= their security needs by making use of standardized network = features.=0A= Expediting the deployment for IPv6 will bring these security = features=0A= into service sooner. Furthermore, the Internet will be able to=0A= avoid the security pitfalls made more likely by the deployment of=0A= NAT devices, as discussed in Section 1.2.2, and arising from any=0A= applications using IPv4 source routing (see section 2.5).=0A= =0A= 5. Acknowledgments=0A= =0A= This work is derived from a Bay Networks white paper on IPv6=0A= (published in 1997) that was co-authored by Steve King, Ruth Fax,=0A= Dimitri Haskin, Wenken Ling, and Tom Meehan of Bay Networks. = Thanks=0A= to Steve Deering and Bob Hinden for their many efforts as chairs = of=0A= the IPng working group. Thanks to Matt Crawford and Thomas = Narten=0A= for their additional detailed comments.=0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (1998). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph=0A= are included on all such copies and derivative works. However,=0A= this document itself may not be modified in any way, such as by=0A= removing the copyright notice or references to the Internet = Society=0A= or other Internet organizations, except as needed for the purpose=0A= of developing Internet standards in which case the procedures=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 43]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= for copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=0A= =0A= A. Myths=0A= =0A= Because of its potential for future dominance and the number of=0A= detailed technical choices that had to be made, the birth of IPv6=0A= has been attended by some controversy, and by a number of = somewhat=0A= misleading stories that can distract network owners who are in=0A= the process of crafting their forward-looking network strategy.=0A= Confusion is to be expected, considering the implications of=0A= migrating our global internetwork infrastructure to an updated=0A= protocol. But if the IPv6 myths are perpetuated indefinitely,=0A= there's a risk that the Internet will not be able to progress=0A= beyond a patched-up version of IPv4. In these appendices, we try = to=0A= counteract some of these myths.=0A= =0A= Myth #1: The only driving force behind IPv6 is address space=0A= depletion.=0A= =0A= Many of the discussions about a new Internet protocol focus on = the=0A= fact that we will sooner or later run out of globally unique = network=0A= layer addresses, due to IPv4's fixed 32-bit address space. The=0A= various address registries that assign blocks of IP addresses to=0A= large network service providers and network operators have become=0A= quite cautious about the way these addresses are handed out, = though=0A= most predictions for IPv4 address exhaustion target a time frame = that=0A= starts well into the next decade.=0A= =0A= With the long-haul in mind, IPv6 has been outfitted with a = 128-bit=0A= address space that should guarantee globally unique addresses for=0A= every conceivable variety of network device for the foreseeable=0A= future (i.e., decades). IPv6 has 16 byte addresses, or=0A= =0A= 340,282,366,920,938,463,463,374,607,431,768,211,456=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 44]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= addresses (over a third of a duodecillion of them, in fact). The=0A= number of addresses gets a lot of attention but it is only one of=0A= many important issues that IPv6 designers have tackled. Other = IPv6=0A= capabilities have been developed in direct response to current=0A= business requirements for more scalable network architectures,=0A= mandatory security and data integrity, extended = quality-of-service=0A= (QoS), autoconfiguration, and more efficient network route=0A= aggregation at the global backbone level. These features are all=0A= specified with IPv6 in a way that would be difficult to realize = as=0A= effectively in IPv4.=0A= =0A= Myth #2: Extensions to IPv4 can replicate IPv6 functionality.=0A= =0A= There have been multiple efforts to extend the life of IPv4=0A= incrementally with evolutionary changes to the protocol standards = and=0A= various proprietary techniques. One such example is the = development=0A= of network address translators (NAT) that preserve IPv4 address = space=0A= by intercepting traffic and converting private intra-enterprise=0A= addresses into one or a few globally unique Internet addresses.=0A= Other examples include the various QoS and security enhancements = to=0A= IPv4, which are in general scaled-back or identical to mechanisms=0A= specified in IPv6.=0A= =0A= We do not know how long IPv4's life can be extended by these=0A= techniques. What is certain is that the widespread introduction=0A= of NAT devices negatively affects the end-to-end viability of=0A= emerging Internet applications; in practice only a limited set of=0A= well-known applications can be correctly handled by NAT devices = or=0A= by application level gateways associated with them. In = particular=0A= NAT devices prevent the deployment of end-to-end IPv4 security.=0A= Furthermore, the development of new and innovative Internet=0A= applications is burdened with the design constraints posed by=0A= NATs [16]. Since NAT is strictly unnecessary for IPv6, standard=0A= end-to-end IPv6 security can be deployed, and a future enlivened=0A= by new lightweight and more fully functional applications can be=0A= envisioned. NAT translation is also known to create great = difficulty=0A= in the construction of Virtual Private Networks (VPNs), since it=0A= makes address space administration difficult and interferes with=0A= standard security mechanisms.=0A= =0A= NAT also only works in a "flat universe" for a site accessing the=0A= global Internet - even moderately-sized enterprises are not flat=0A= internally, with nested multi-party relationships. Realistic NAT=0A= deployment solutions would have to include routing via multiple=0A= ingress/egress NATs for load balancing, multi-NAT-hop routes and=0A= so on - all this would create in miniature the v4 (or in fact v6)=0A= architecture, since it is solving the same problem, but piecewise = and=0A= badly.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 45]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= It is hard to compare the costs of converting to IPv6 with those = of=0A= remaining with IPv4 and its upgrades. Every network manager will=0A= have to make this comparison; but staying with IPv4 has been = likened=0A= to the situation of a lobster in a pot of water, as the = temperature=0A= slowly increases - at first, it feels comfortable.=0A= =0A= Myth #3: IPv6 support for a large diversity of network devices = is=0A= not an end-user or business concern.=0A= =0A= Over the next few years, conventional computers on the Internet = will=0A= be joined by a myriad of new devices, including palmtop personal=0A= data assistants (PDA), hybrid mobile phone technology with data=0A= processing capabilities, smart set-top boxes with integrated Web=0A= browsers, and embedded network components in equipment ranging = from=0A= office copy machines to kitchen appliances. Some of the new = devices=0A= requiring IP addresses and connectivity will be = consumer-oriented,=0A= but many will become integral to the information management = functions=0A= of corporations and institutions of all sizes. These new devices=0A= require features not fully understood by most protocol designers=0A= during the initial growth of the IPv4 Internet.=0A= =0A= IPv6's 128-bit address space will allow businesses to deploy a = huge=0A= array of new desktop, mobile, and embedded network devices in a=0A= cost-effective, manageable way. Further, IPv6's = autoconfiguration=0A= features will make it feasible for large numbers of devices to = attach=0A= dynamically to the network, without incurring unsupportable costs = for=0A= the administration for an ever-increasing number of adds, moves, = and=0A= changes.=0A= =0A= The business requirement for IPv6 will be driven by end-user=0A= applications. Applications for mobile nodes, electronic = commerce,=0A= and those needing specialized routing features will be easier=0A= to design and implement using IPv6, especially as compared to=0A= IPv4 patched by NAT. To remain competitive in the coming era of=0A= highdensity networking, businesses should exploit IPv6 to create = a=0A= highly scalable address space and robust autoconfiguration = services=0A= that will remain viable in the face of an explosion of end-user=0A= networking needs.=0A= =0A= Myth #4: IPv6 is primarily relevant to backbone routers, not=0A= end-user applications.=0A= =0A= It is true that IPv6 address aggregation allows efficient = multitiered=0A= routing hierarchies that prevent the uncontrolled growth of = backbone=0A= router tables. But many of the advanced features of IPv6 also=0A= bring direct benefits to end-user applications at the workgroup=0A= and departmental levels. For instance, applications will have=0A= available the mandatory IPv6 encryption and authentication = services=0A= as an integral part of the IP stack. For mobile business users=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 46]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= and changing organizations, IPv6 autoconfiguration will allow the=0A= efficient assignment of IP addresses without the delays and cost=0A= associated with manual address administration or even traditional=0A= DHCP, which takes place in many current IP networks. IPv6 is = very=0A= much both an end-user concern and a business concern. This = concern=0A= will become increasingly important as QoS flows and QoS routing=0A= become important architectural components of the Internet.=0A= =0A= Myth #5: Asynchronous Transfer Mode (ATM) cell switching will = negate=0A= the need for IPv6.=0A= =0A= ATM and other switching methods offer interesting technology for=0A= present and future internetworks, but ATM is, by itself, not a=0A= replacement for packet routing Internet architecture. ATM is = better=0A= understood as a link-layer technology over a non-broadcast = multiple=0A= access (NBMA) medium. It gives some isolation properties, and=0A= offers the promise for offering improved Quality of Service (QoS)=0A= connections for applications that need it. Even these = hypothetical=0A= advantages are not yet fully developed for ATM, and it is = possible=0A= that these advantages will be equally well available in future = IPv6=0A= networks not running over ATM.=0A= =0A= Fortunately, network owners do not have to make a choice between = ATM=0A= or IPv6 because the two protocols will continue to serve = different=0A= and complementary roles in corporate networking. Large networks=0A= will make use of both protocols. For many network designers, ATM = is=0A= a useful transmission medium for highspeed IPv6 backbone = networks.=0A= Standards and development work is being devoted to integrating = ATM=0A= and IPv6 environments. IPv6, like its predecessor IPv4, provides=0A= network layer services over all major link types, including ATM,=0A= Ethernet, Token Ring, ISDN, Frame Relay, and T1.=0A= =0A= Myth #6: IPv6 is something that only large telephone companies = or=0A= the government should worry about.=0A= =0A= Some Internet pundits have characterized IPv6 as a concern that's=0A= outside the corporate network and outside the current time frame.=0A= In reality, IPv6 is a standards track and mainstream solution=0A= for the operation and continued efficiency of day-to-day business=0A= activities. But the only way that IPv6 will take hold and succeed = is=0A= if businesses and institutions of all types come to terms with = the=0A= inadequacies of IPv4 and begin to lay plans for migration. In = the=0A= past few years, Internet protocols have enabled a whole new style = of=0A= distributed commerce that brings people together inside = enterprises=0A= and gives enterprises access to the entire world. In fact, the=0A= sustained and impressive growth of the Internet, which has = inspired=0A= the current engineering efforts for IPv6, is in large measure due = to=0A= the penetration of the World Wide Web to business and consumer = end=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 47]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= users. Offering services to such end users is of interest to = many=0A= more institutions than merely governments and telephone = companies.=0A= =0A= Myth #7: IPv6 requires extensive modifications to existing = operating=0A= systems, applications, and programming techniques.=0A= =0A= IPv6 obviously requires certain modifications to the network = protocol=0A= handling modules installed on the relevant computers. However, = this=0A= typically requires little or no change to the base operating = system.=0A= Simple and natural modifications, typically confined to fewer = than=0A= a dozen lines of the programs, can be made to enable applications=0A= to use IPv6 addresses directly. Since IPv6 reserves a part of = its=0A= address space for compatibility with IPv4 addresses, applications=0A= modified to handle IPv6 addresses can still communicate with = existing=0A= IPv4 clients and servers.=0A= =0A= Moreover, the transition strategies defined for IPv6 deployment=0A= within the IPv4 Internet should make the gradual adoption of IPv6 = a=0A= smooth process that allows existing applications to be converted = for=0A= native IPv6 operation in a gradual, controlled manner.=0A= =0A= Myth #8: Too Little, Too Soon=0A= =0A= IPv6 appears as an incremental enhancement to IPv4, and some=0A= people say that if we are going to go to all the trouble to = switch=0A= network-layer protocols, we really ought to go all out for some=0A= really futuristic feature-full new protocol. This argument = ignores=0A= the following simple facts:=0A= =0A= - The purpose of a network-layer protocol is to hook together=0A= networks, and=0A= =0A= - IPv6 builds on the amazing success of IP, by not forgetting = the=0A= successful parts, and by repairing the known faults. This is = far=0A= different than starting over again with something unknown and=0A= untested.=0A= =0A= Those who claim that it is too early for IPv6 ignore the facts = that=0A= existing solutions extending the life of IPv4 are clearly stopgap=0A= measures, and that one can put IPv6 into service now.=0A= =0A= Myth #9: Renumbering is fixed in IPv6=0A= =0A= Although IPv6 has gone a long way to enable more convenient=0A= renumbering operations, it is a mistake to say that renumbering = is=0A= a completely solved problem. IPv6 engineers are still = considering=0A= designs for renumbering routers, and for renumbering collections = of=0A= computers larger than a single network. Furthermore, = applications=0A= that have been ported from IPv4 to IPv6 do not automatically = become=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 48]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= more able to support renumbering. Some applications will require=0A= small design improvements in order to support renumbering. = Lastly,=0A= the biggest impediment to renumbering seems typically to be the=0A= institution of administrative practices that key information = directly=0A= on IP addresses instead of some more appropriate indexing method.=0A= These administrative practices require attention and adherence to=0A= more modern guidelines for Internet administration before the = problem=0A= of renumbering can be considered to be solved.=0A= =0A= Myth #10: Routing is fixed in IPv6=0A= =0A= IPv6 offers improvements for routing in a number of ways. It=0A= allows for allocation of IPv6 addresses in a way that is more=0A= favorable for aggregation than existing IPv4 allocations. It = allows=0A= for more streamlined packet forwarding than IPv4 routers can do,=0A= especially when IP options are used. IPv6's larger address space=0A= offers opportunities for more optimal network planning, since the=0A= constraints for planning out network connectivity have been = relaxed=0A= to such a great extent. Furthermore, since every IPv6 router can = be=0A= presumed to have security processing enabled, it is much easier = to=0A= institute the appropriate security measures for authentication = and=0A= keeping private data private.=0A= =0A= However, there are still many operational issues that need = attention.=0A= IPv6 routing protocols are largely adapted from almost identical=0A= IPv4 routing protocols, and thus inherit some of the same = problems.=0A= Improvements continue to be made to routing protocols to improve=0A= their stability, convergence time, and configurability. One of = the=0A= hardest problems is to make routing protocols more = human-friendly,=0A= so that it does not take a genius to make the routing fabric work=0A= reliably. There are remaining issues surrounding multi-homing = that=0A= have not been solved. All of these issues will continue to = receive=0A= the attention of engineers involved with the creation of IPv6. = The=0A= scoped addresses and native security are expected to make their=0A= solution much easier.=0A= =0A= References=0A= =0A= [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor=0A= Extensions. RFC 2132, March 1997.=0A= =0A= [2] J. Bound and C. Perkins. Dynamic Host Configuration = Protocol=0A= for IPv6. draft-ietf-dhc-dhcpv6-14.txt, February 1999. = (work=0A= in progress).=0A= =0A= [3] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. = Jamin.=0A= RFC 2205: Resource ReSerVation Protocol (RSVP) --- version = 1=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 49]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= functional specification, September 1997. Status: PROPOSED=0A= STANDARD.=0A= =0A= [4] B. Carpenter. RFC 1958: Architectural principles of the=0A= Internet, June 1996. Status: INFORMATIONAL.=0A= =0A= [5] B. Carpenter and C. Jung. Transmission of IPv6 over IPv4=0A= domains without explicit tunnels. Request for Comments=0A= (Proposed Standard) 2529, Internet Engineering Task Force, = March=0A= 1999.=0A= =0A= [6] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6.=0A= draft-ietf-ospf-ospfv6-07.txt, October 1999. (work in=0A= progress).=0A= =0A= [7] A. Conta and S. Deering. RFC 2463: Internet Control = Message=0A= Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)=0A= Specification, December 1998. Status: DRAFT STANDARD.=0A= =0A= [8] Matt Crawford. Router Renumbering for IPv6.=0A= draft-ietf-ipngwg-router-renum-07.txt, January 1999. (work = in=0A= progress).=0A= =0A= [9] S. Deering. Protocol Independent Multicast-Sparse Mode=0A= (PIM-SM): Protocol Specification. Request for Comments=0A= (Experimental) 2117, Internet Engineering Task Force, June = 1997.=0A= =0A= [10] S. Deering and R. Hinden. RFC 2460: Internet Protocol, = Version=0A= 6 (IPv6) specification, December 1998. Obsoletes RFC1883.=0A= Status: DRAFT STANDARD.=0A= =0A= [11] S. Deering, C. Partridge, and D. Waitzman. Distance Vector=0A= Multicast Routing Protocol. Request for Comments = (Experimental)=0A= 1075, Internet Engineering Task Force, November 1988.=0A= =0A= [12] Stephen E. Deering, Editor. ICMP Router Discovery Messages.=0A= RFC 1256, September 1991.=0A= =0A= [13] M. Degermark, B. Nordgren, and S. Pink. Header Compression = for=0A= IPv6, February 1999. Status: PROPOSED STANDARD.=0A= =0A= [14] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, = March=0A= 1997.=0A= =0A= [15] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless=0A= Inter-Domain Routing (CIDR): an Address Assignment and=0A= Aggregation Strategy. RFC 1519, September 1993.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 50]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= [16] T. Hain. Architectural implications of NAT.=0A= draft-iab-nat-implications-02.txt, October 1998. (work in=0A= progress).=0A= =0A= [17] R. Hinden and S. Deering. IP Version 6 Addressing = Architecture.=0A= RFC 1884, December 1995.=0A= =0A= [18] IEEE. Guidelines for 64-bit Global Identifier (EUI-64)=0A= Registration Authority, March 1997.=0A= http://standards.ieee.org/db/oui/tutorials/EUI64.html.=0A= =0A= [19] D. Johnson and S. Deering. Reserved IPv6 subnet anycast=0A= addresses. Request for Comments (Proposed Standard) 2526,=0A= Internet Engineering Task Force, March 1999.=0A= =0A= [20] D. Johnson and C. Perkins. Mobility Support in IPv6.=0A= draft-ietf-mobileip-ipv6-08.txt, June 1999. (work in = progress).=0A= =0A= [21] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: = Keyed-Hashing=0A= for Message Authentication. RFC 2104, February 1997.=0A= =0A= [22] G. Malkin and R. Minnear. RFC 2080: RIPng for IPv6, = January=0A= 1997. Status: PROPOSED STANDARD.=0A= =0A= [23] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for = IP=0A= version 6. RFC 1981, August 1996.=0A= =0A= [24] J. Moy. Multicast extensions to OSPF. Request for Comments=0A= (Proposed Standard) 1584, Internet Engineering Task Force, = March=0A= 1994.=0A= =0A= [25] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor=0A= discovery for IP Version 6 (IPv6), December 1998. Status:=0A= DRAFT STANDARD.=0A= =0A= [26] C. Partridge, T. Mendez, and W. Milliken. Host anycasting=0A= service. Request for Comments (Informational) 1546, = Internet=0A= Engineering Task Force, November 1993.=0A= =0A= [27] C. Perkins. Extensions for the Dynamic Host Configuration=0A= Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-11.txt, = February=0A= 1999. (work in progress).=0A= =0A= [28] David C. Plummer. An Ethernet Address Resolution Protocol:=0A= Or Converting Network Protocol Addresses to 48.bit Ethernet=0A= Addresses for Transmission on Ethernet Hardware. RFC 826,=0A= November 1982.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 51]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= [29] J. B. Postel, Editor. Internet Control Message Protocol. = RFC=0A= 792, September 1981.=0A= =0A= [30] Y. Rekhter and T. Li. An Architecture for IP Address = Allocation=0A= with CIDR. RFC 1518, September 1993.=0A= =0A= [31] P. Srisuresh and M. Holdrege. IP network address translator=0A= (NAT) terminology and considerations. Request for Comments=0A= (Informational) 2663, Internet Engineering Task Force, = August=0A= 1999.=0A= =0A= [32] R. Talpade and M. Ammar. RFC 2149: Multicast server=0A= architectures for MARS-based ATM multicasting, May 1997.=0A= Status: INFORMATIONAL.=0A= =0A= [33] S. Thomson and C. Huitema. DNS extensions to support IP = version=0A= 6. Request for Comments (Proposed Standard) 1886, Internet=0A= Engineering Task Force, January 1996.=0A= =0A= [34] S. Thomson and T. Narten. RFC 2462: IPv6 stateless address=0A= autoconfiguration, December 1998. Obsoletes RFC1971. = Status:=0A= DRAFT STANDARD.=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 52]=0A= =0A= Internet Draft The Case for IPv6 22 October = 1999=0A= =0A= Authors' and Editors' Addresses=0A= =0A= Original Authors:=0A= =0A= - Steve King, Bay Networks=0A= - Ruth Fax, Bay Networks=0A= - Dimitry Haskin, Bay Networks=0A= - Wenken Ling, Bay Networks=0A= - Tom Meehan, Bay Networks=0A= =0A= Questions about this memo can be directed to the editors:=0A= =0A= Robert Fink Charles E. Perkins=0A= Esnet R&D Communications Systems Lab=0A= Lawrence Berkeley Nat'l Laboratory Nokia Research Center=0A= 1 Cyclotron Road 313 Fairchild Drive=0A= Bldg. 50A, Room 3139=0A= Mail-Stop 50A-3111=0A= Berkeley, CA 94720 Mountain View, CA 94043=0A= USA USA=0A= =0A= phone: +1 510 486-5692 Phone: +1-650 625-2986=0A= fax: +1 510 486-4790 Fax: +1 650 691-2170=0A= e-mail: rlfink@lbl.gov EMail: = charliep@iprg.nokia.com=0A= = www.iprg.nokia.com/~charliep=0A= =0A= King, et.al. Expires 22 April 2000 [Page = 53]=0A= ------_=_NextPart_000_01C352CF.2A16EFC0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 26 12:26:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6QJQJ06024131; Sat, 26 Jul 2003 12:26:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6QJPxtF024130; Sat, 26 Jul 2003 12:25:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6QJPf06024115 for ; Sat, 26 Jul 2003 12:25:56 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6QJNDUu003519 for ; Sat, 26 Jul 2003 12:23:14 -0700 (PDT) Received: from rayen.face.ubiobio.cl (rayen.face.ubiobio.cl [146.83.194.131]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6QJN6Y1010632 for ; Sat, 26 Jul 2003 13:23:07 -0600 (MDT) Received: by rayen.face.ubiobio.cl (Postfix, from userid 500) id B61A01BE8D; Sat, 26 Jul 2003 15:20:38 -0400 (CLT) Received: from localhost (localhost [127.0.0.1]) by rayen.face.ubiobio.cl (Postfix) with ESMTP id B008A40A3 for ; Sat, 26 Jul 2003 15:20:38 -0400 (CLT) Date: Sat, 26 Jul 2003 15:20:38 -0400 (CLT) From: Leonardo Saavedra Henriquez X-X-Sender: leo@rayen.face.ubiobio.cl To: ipng@sunroof.eng.sun.com Subject: state-of-art SLs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All I would like to know what is state of Site-Local Adress? Are they deprecated? or will be they deprecated? TIA -- Leonardo Saavedra Henriquez mailtp:leo@ubiobio.cl -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 27 04:03:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6RB2e06010882; Sun, 27 Jul 2003 04:02:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6RB2Kf7010874; Sun, 27 Jul 2003 04:02:20 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6RB1i06010852 for ; Sun, 27 Jul 2003 04:01:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6RAxFUu027578 for ; Sun, 27 Jul 2003 03:59:15 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6RAx8ii025275 for ; Sun, 27 Jul 2003 03:59:09 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h6RAwuh00249; Sun, 27 Jul 2003 17:58:58 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h6RAwjs17679; Sun, 27 Jul 2003 17:58:46 +0700 (ICT) From: Robert Elz To: Leonardo Saavedra Henriquez cc: ipng@sunroof.eng.sun.com Subject: Re: state-of-art SLs In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Jul 2003 17:58:44 +0700 Message-ID: <5443.1059303524@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 26 Jul 2003 15:20:38 -0400 (CLT) From: Leonardo Saavedra Henriquez Message-ID: | I would like to know what is state of Site-Local Adress? | Are they deprecated? or will be they deprecated? They are still in the standards. They are still in (most) implementations. There are a bunch of people that believe that they have been deprecated (making a huge leap of faith that a vote in a working group translates into IETF action), but there are no documents even written yet, let alone published as RFCs that say that. The chances that SL addresses will simply be deprecated are something approaching zero. There is a more reasonable chance that some kind of alternative may replace them, one day. For now, just use SL addresses for any purpose where appropriate functionality is required. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 27 04:53:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6RBrL06011655; Sun, 27 Jul 2003 04:53:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6RBr1HT011651; Sun, 27 Jul 2003 04:53:01 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6RBqf06011644 for ; Sun, 27 Jul 2003 04:52:57 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6RBoDUu006129 for ; Sun, 27 Jul 2003 04:50:13 -0700 (PDT) Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6RBo056022638 for ; Sun, 27 Jul 2003 05:50:06 -0600 (MDT) Received: from lt38 ([10.4.1.42]) by galileo5.galileo.co.il (8.12.6/8.12.6) with SMTP id h6RClS5T028678 for ; Sun, 27 Jul 2003 14:47:29 +0200 (GMT-2) Message-ID: <016c01c3543d$ff717630$2a01040a@lt38> From: "Nir Arad" To: "IPng mailing list" Subject: IPv6 -> MAC multicast address mapping Date: Sun, 27 Jul 2003 14:52:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0169_01C3544E.C2786C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0169_01C3544E.C2786C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksDQoNClNob3VsZCBhIG5vZGUgKGEgcm91dGVyKSBjaGVjayB0aGUgdmFsaWRpdHkgb2YgdGhl IG1hcHBpbmcgb2YgSVB2NiBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBpbnRvIHRoZSBF dGhlcm5ldCBNQUMgbXVsdGljYXN0IGFkZHJlc3M/DQoNCkkgZGlkbid0IGZpbmQgdGhpcyByZXF1 aXJlbWVudCBhbnl3aGVyZSwgYW5kIHBlcmhhcHMgdGhlcmUgc2hvdWxkbid0IGJlIG9uZSwgYnV0 IEkgd2FudGVkIHRvIHByb3Zva2Ugc29tZSB0aG91Z2h0IG9uIHRoaXMgaXNzdWUuDQpDb3VsZCB0 aGVyZSBiZSBhIHNlY3VyaXR5IGlzc3VlPyBQZXJoYXBzIG90aGVyIGlzc3Vlcz8NCg0KUmVnYXJk cywNCg0KLS0gTmlyIEFyYWQNCg== ------=_NextPart_000_0169_01C3544E.C2786C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMTcwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5I aSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+U2hvdWxkJm5ic3A7YSBub2Rl IChhIHJvdXRlcikgY2hlY2sgdGhlIHZhbGlkaXR5IG9mIA0KdGhlIG1hcHBpbmcgb2YgSVB2NiBt dWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBpbnRvIHRoZSBFdGhlcm5ldCBNQUMgDQptdWx0 aWNhc3QgYWRkcmVzcz88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SSBkaWRu J3QgZmluZCB0aGlzIHJlcXVpcmVtZW50IGFueXdoZXJlLCBhbmQgDQpwZXJoYXBzIHRoZXJlIHNo b3VsZG4ndCBiZSBvbmUsIGJ1dCBJIHdhbnRlZCB0byBwcm92b2tlIHNvbWUgdGhvdWdodCBvbiB0 aGlzIA0KaXNzdWUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5D b3VsZCB0aGVyZSBiZSBhIHNlY3VyaXR5IGlzc3VlPyBQZXJoYXBzIG90aGVyIA0KaXNzdWVzPzwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5SZWdhcmRzLDwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPi0tIE5pciBB cmFkPEJSPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0169_01C3544E.C2786C00-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 00:23:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6S7MA06010057; Mon, 28 Jul 2003 00:22:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6S7Lon9010048; Mon, 28 Jul 2003 00:21:50 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6S7L206010035 for ; Mon, 28 Jul 2003 00:21:17 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6S7IWV7026570 for ; Mon, 28 Jul 2003 00:18:32 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6S7IPp4012235 for ; Mon, 28 Jul 2003 01:18:26 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6S7IJ77061372; Mon, 28 Jul 2003 09:18:19 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6S7IIOD281152; Mon, 28 Jul 2003 09:18:18 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA42096; Mon, 28 Jul 2003 09:18:18 +0200 Message-ID: <3F24CE3B.C8A310DB@zurich.ibm.com> Date: Mon, 28 Jul 2003 09:18:19 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Robert Elz CC: Leonardo Saavedra Henriquez , ipng@sunroof.eng.sun.com Subject: Re: state-of-art SLs References: <5443.1059303524@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, there will soon be a draft documenting the WG face to face consensus (which you don't happend to agree with) and that draft will of course be put before the WG for formal consensus determination. At the same time there is a combined draft being written on the requirements for the replacement, and a draft proposal for the replacement (draft-hinden-ipv6-global-local-addr-02.txt) was accepted as a WG item in the recent face to face meeting. So the chances that FEC0::/10 will be formally deprecated and replaced by something better are close to 100%. As a co-author of the intended deprecation draft, I will try to ensure that it doesn't destroy currently shipping software. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK Robert Elz wrote: > > Date: Sat, 26 Jul 2003 15:20:38 -0400 (CLT) > From: Leonardo Saavedra Henriquez > Message-ID: > > | I would like to know what is state of Site-Local Adress? > | Are they deprecated? or will be they deprecated? > > They are still in the standards. They are still in (most) implementations. > > There are a bunch of people that believe that they have been deprecated > (making a huge leap of faith that a vote in a working group translates > into IETF action), but there are no documents even written yet, let alone > published as RFCs that say that. > > The chances that SL addresses will simply be deprecated are something > approaching zero. There is a more reasonable chance that some kind of > alternative may replace them, one day. > > For now, just use SL addresses for any purpose where appropriate > functionality is required. > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 03:54:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SArJ06014727; Mon, 28 Jul 2003 03:53:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6SAqxb9014719; Mon, 28 Jul 2003 03:52:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SAqP06014706 for ; Mon, 28 Jul 2003 03:52:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6SAntUu024080 for ; Mon, 28 Jul 2003 03:49:55 -0700 (PDT) Received: from mordani.com (mordani.com [66.92.28.204]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6SAnn2h001435 for ; Mon, 28 Jul 2003 03:49:50 -0700 (PDT) Received: from moon (chirayu.chirayu.org [202.142.102.54]) by mordani.com (8.12.8/8.12.8) with ESMTP id h6SAfsj9009164; Mon, 28 Jul 2003 03:41:57 -0700 From: "Chirayu Patel" To: "'IPng mailing list'" Cc: "'Nir Arad'" Subject: RE: IPv6 -> MAC multicast address mapping Date: Mon, 28 Jul 2003 16:20:51 +0530 Message-ID: <000001c354f6$215459d0$010aa8c0@chirayu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <016c01c3543d$ff717630$2a01040a@lt38> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6SAqf06014711 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Nir, My thoughts... Add the validation check! It does not seem to be expensive. One scenario where is this check might be useful is to prevent identification of the OS running on the router; the assumption is that not checking the mapping is/will be atypical behavior. :-) CP -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nir Arad Sent: Sunday, July 27, 2003 6:23 PM To: IPng mailing list Subject: IPv6 -> MAC multicast address mapping Hi,   Should a node (a router) check the validity of the mapping of IPv6 multicast destination address into the Ethernet MAC multicast address?   I didn't find this requirement anywhere, and perhaps there shouldn't be one, but I wanted to provoke some thought on this issue. Could there be a security issue? Perhaps other issues?   Regards,   -- Nir Arad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 05:57:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SCuW06017019; Mon, 28 Jul 2003 05:56:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6SCuBBq017017; Mon, 28 Jul 2003 05:56:11 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SCtZ06016997 for ; Mon, 28 Jul 2003 05:55:52 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6SCr1Q24277; Mon, 28 Jul 2003 14:53:01 +0200 (MEST) Date: Mon, 28 Jul 2003 14:50:55 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: state-of-art SLs To: Leonardo Saavedra Henriquez Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is a revelant email. I haven't seen a different statement on WG consensus on this topic. Erik Date: Wed, 09 Apr 2003 15:11:04 -0700 From: "Bob Hinden & Margaret Wasserman" Subject: Consensus on Site-Local Addressing To: ipng@sunroof.eng.sun.com Hi All, Well, that was fun! :-) All told, there were over 200 responses to the consensus call on IPv6 site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 site-local unicast addressing. The final count (including the room and the mailing list) was: 155 YES, 56 NO (211 Total). There were also a significant number of the people on both sides of this issue that voiced (in their original responses, or in subsequent messages) a strong belief that we should investigate alternative mechanisms for local addressing and local access control. The chairs have read all of the messages on the list, and based on your considerable input, we have determined that the IPv6 WG does have rough consensus to deprecate the usage of IPv6 site-local unicast addressing AND to investigate alternative mechanisms for local addressing and local access control. In particular, the IPv6 WG will work to accomplish the following things in parallel: (1) Publish an informational document that explains the issues encountered with site-local addressing and our reasons for deprecating IPv6 site-local unicast addresses. This document will officially deprecate site-local addressing. (2) Remove site-local unicast addressing from the IPv6 scoped addressing architecture I-D, and publish the parts of the document on which we do have consensus (i.e., link local addresses, multicast, etc.). This will include a note that the IPv6 working group is investigating other forms of local IPv6 addressing and that the usage of any new forms of local addresses will be documented elsewhere. (3) Update the IPv6 addressing architecture to indicate that the usage of the FECO::/10 prefix for site-local addressing is deprecated. To maintain backward compatibility with existing implementations the prefix should be reserved and should not be allocated for other purposes. (4) Define and publish the requirements for a local addressing mechanism to provide: - Addresses for disconnected networks. - Addresses for intermittently connected networks. - Addresses that support merging of sites. - Stable local addresses for changing ISPs without disrupting local communication. Once we have consensus on the requirements, the IPv6 WG will work on solutions for local addressing that meet those requirements. (5) Define and publish the requirements for a local access control mechanism, then work on a solution that meets those requirements. Each of these new work items will need to be added to the IPv6 WG charter and will go through the normal IETF document processes. For (4) and (5) it is important to make the rest of the IETF community aware that the IPv6 WG is undertaking these tasks, so we will consider methods to invite wider review and discussion of these problems. IPv6 site-local addressing has been a contentious issue in the IPv6 WG for some time, and we are both glad to see the WG reach consensus on this issue. This will allow us to complete and publish the IPv6 scoped addressing architecture document, an important part of the IPv6 specification. We hope that people on all sides of this issue will respect the rough consensus of the WG, and will work with us to achieve the goals outlined above. Thanks to everyone who expressed an opinion during this discussion. Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 08:10:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SFAM06019991; Mon, 28 Jul 2003 08:10:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6SFA2Fv019990; Mon, 28 Jul 2003 08:10:02 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SF9Q06019975 for ; Mon, 28 Jul 2003 08:09:42 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6SF6uV7000148 for ; Mon, 28 Jul 2003 08:06:56 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6SF6nNS009695 for ; Mon, 28 Jul 2003 09:06:50 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04531; Mon, 28 Jul 2003 11:06:45 -0400 (EDT) Message-Id: <200307281506.LAA04531@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-park-ipv6-optidad-requirement-00.txt Date: Mon, 28 Jul 2003 11:06:45 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirement for Optimized DAD in IPv6 Mobility Author(s) : S. Park Filename : draft-park-ipv6-optidad-requirement-00.txt Pages : 5 Date : 2003-7-28 This document describes requirements how optimized DAD should be used for IPv6 mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-ipv6-optidad-requirement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-park-ipv6-optidad-requirement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-park-ipv6-optidad-requirement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-28111308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-park-ipv6-optidad-requirement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-park-ipv6-optidad-requirement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-28111308.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 12:15:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SJF406021857; Mon, 28 Jul 2003 12:15:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6SJEhv0021856; Mon, 28 Jul 2003 12:14:43 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SJDr06021849 for ; Mon, 28 Jul 2003 12:14:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6SJBNUu001808 for ; Mon, 28 Jul 2003 12:11:23 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6SJBHLR006886 for ; Mon, 28 Jul 2003 12:11:17 -0700 (PDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h6SJB19n003912; Mon, 28 Jul 2003 15:11:01 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h6SJB15T003911; Mon, 28 Jul 2003 15:11:01 -0400 (EDT) Date: Mon, 28 Jul 2003 15:11:01 -0400 (EDT) From: Scott Bradner Message-Id: <200307281911.h6SJB15T003911@newdev.harvard.edu> To: Erik.Nordmark@Sun.COM Subject: Re: state-of-art SLs Cc: ipng@sunroof.eng.sun.com In-Reply-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The chairs have read all of the messages on the list, and based on your > considerable input, we have determined that the IPv6 WG does have rough > consensus to deprecate the usage of IPv6 site-local unicast addressing AND > to investigate alternative mechanisms for local addressing and local access . control. humm - it is not all that often that we have said that 2/3 is rough consensus in the IETF - in my exterience if 1/3 is not in support then I would not claim consensus (even 6 grit) - 3/4 would be very rough indeed, 5/6 would be the mininum I would say was "rough consensus" just when does "rough consensus" faid out in this model? Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 14:00:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SKxa06022564; Mon, 28 Jul 2003 13:59:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6SKxEnB022555; Mon, 28 Jul 2003 13:59:14 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SKwd06022545 for ; Mon, 28 Jul 2003 13:58:55 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6SKu9V7009281 for ; Mon, 28 Jul 2003 13:56:09 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6SKu37h013005 for ; Mon, 28 Jul 2003 14:56:03 -0600 (MDT) Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h6SKu2C9007844 for ; Mon, 28 Jul 2003 13:56:03 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h6SKtx0U012495 for ; Mon, 28 Jul 2003 15:56:00 -0500 Received: from motorola.com (ma19-0008.e2.bcs.mot.com [10.14.10.58]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.2) id P19PN6KM; Tue, 29 Jul 2003 02:25:56 +0530 Message-ID: <3F258DD8.820CCC2A@motorola.com> Date: Mon, 28 Jul 2003 16:55:52 -0400 From: Bhaskar S Organization: Motorola Inc. X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: ipng@sunroof.eng.sun.com Subject: Re: state-of-art SLs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, The document mentioned below, has it been published? If yes please could you send me the link? Erik Nordmark wrote: > > Here is a revelant email. > I haven't seen a different statement on WG consensus on this topic. > > Erik > > > (1) Publish an informational document that explains the issues > encountered with site-local addressing and our reasons > for deprecating IPv6 site-local unicast addresses. This > document will officially deprecate site-local addressing. > -- Best Regards, Bhaskar S. 978-858-2896 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 15:02:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SM1l06023373; Mon, 28 Jul 2003 15:01:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6SM1RbM023372; Mon, 28 Jul 2003 15:01:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6SM0c06023364 for ; Mon, 28 Jul 2003 15:00:54 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6SLw4Uu001447 for ; Mon, 28 Jul 2003 14:58:04 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6SLvwHh019438 for ; Mon, 28 Jul 2003 15:57:59 -0600 (MDT) Received: from ala-mrwtemp.windriver.com ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA07931; Mon, 28 Jul 2003 14:57:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20030728165234.0412a1c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Jul 2003 16:58:35 -0400 To: Erik Nordmark From: Margaret Wasserman Subject: Re: state-of-art SLs Cc: Leonardo Saavedra Henriquez , ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks, Erik. Leonard, this statement represents the consensus of the WG, as determined both at the face-to-face meeting in San Francisco and on the mailing list in April. We are currently working to carry out the action plan described in this message, which does include the deprecation of site-local addresses. There is already a new version of the scoped addressing architecture that removes site-local addressing, and work is underway to produce the document that will officially deprecate the site-local prefix. Margaret At 02:50 PM 7/28/2003 +0200, Erik Nordmark wrote: >Here is a revelant email. >I haven't seen a different statement on WG consensus on this topic. > > Erik > >Date: Wed, 09 Apr 2003 15:11:04 -0700 >From: "Bob Hinden & Margaret Wasserman" >Subject: Consensus on Site-Local Addressing >To: ipng@sunroof.eng.sun.com > >Hi All, > >Well, that was fun! :-) > >All told, there were over 200 responses to the consensus call on IPv6 >site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 >site-local unicast addressing. The final count (including the room and the >mailing list) was: 155 YES, 56 NO (211 Total). > >There were also a significant number of the people on both sides of this >issue that voiced (in their original responses, or in subsequent messages) >a strong belief that we should investigate alternative mechanisms for local >addressing and local access control. > >The chairs have read all of the messages on the list, and based on your >considerable input, we have determined that the IPv6 WG does have rough >consensus to deprecate the usage of IPv6 site-local unicast addressing AND >to investigate alternative mechanisms for local addressing and local access >control. > >In particular, the IPv6 WG will work to accomplish the following things in >parallel: > > (1) Publish an informational document that explains the issues > encountered with site-local addressing and our reasons > for deprecating IPv6 site-local unicast addresses. This > document will officially deprecate site-local addressing. > > (2) Remove site-local unicast addressing from the IPv6 > scoped addressing architecture I-D, and publish the > parts of the document on which we do have consensus > (i.e., link local addresses, multicast, etc.). This > will include a note that the IPv6 working group is > investigating other forms of local IPv6 addressing and > that the usage of any new forms of local addresses will be > documented elsewhere. > > (3) Update the IPv6 addressing architecture to indicate that the > usage of the FECO::/10 prefix for site-local addressing is > deprecated. To maintain backward compatibility with existing > implementations the prefix should be reserved and should not > be allocated for other purposes. > > (4) Define and publish the requirements for a local addressing > mechanism to provide: > - Addresses for disconnected networks. > - Addresses for intermittently connected networks. > - Addresses that support merging of sites. > - Stable local addresses for changing ISPs without > disrupting local communication. > Once we have consensus on the requirements, the IPv6 > WG will work on solutions for local addressing that > meet those requirements. > > (5) Define and publish the requirements for a local access > control mechanism, then work on a solution that meets > those requirements. > >Each of these new work items will need to be added to the IPv6 WG charter >and will go through the normal IETF document processes. For (4) and (5) it >is important to make the rest of the IETF community aware that the IPv6 WG >is undertaking these tasks, so we will consider methods to invite wider >review and discussion of these problems. > >IPv6 site-local addressing has been a contentious issue in the IPv6 WG for >some time, and we are both glad to see the WG reach consensus on this >issue. This will allow us to complete and publish the IPv6 scoped >addressing architecture document, an important part of the IPv6 specification. > >We hope that people on all sides of this issue will respect the rough >consensus of the WG, and will work with us to achieve the goals outlined >above. > Thanks to everyone who expressed an opinion during this discussion. > >Bob Hinden & Margaret Wasserman >IPv6 WG Chairs > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 19:57:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6T2v106029969; Mon, 28 Jul 2003 19:57:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6T2ufeH029954; Mon, 28 Jul 2003 19:56:41 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6T2tr06029893 for ; Mon, 28 Jul 2003 19:56:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6T2rMV7011973 for ; Mon, 28 Jul 2003 19:53:22 -0700 (PDT) Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6T2rHLR024009 for ; Mon, 28 Jul 2003 19:53:17 -0700 (PDT) Subject: RE: state-of-art SLs Date: Mon, 28 Jul 2003 19:53:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: state-of-art SLs X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Index: AcNVfGntjM9hUVaUQpKK31IWcVmblwAAAzJA From: "Michel Py" To: "Bhaskar S" , "Erik Nordmark" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6T2u806029923 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bhaskar S wrote: > The document mentioned below, has it been published? > If yes please could you send me the link? Ditto. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 00:00:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6T70M06005757; Tue, 29 Jul 2003 00:00:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6T7012u005756; Tue, 29 Jul 2003 00:00:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6T6xh06005749 for ; Mon, 28 Jul 2003 23:59:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6T6vDV7005309 for ; Mon, 28 Jul 2003 23:57:13 -0700 (PDT) Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6T6v7T5023060 for ; Mon, 28 Jul 2003 23:57:07 -0700 (PDT) Received: from caper (caper [199.60.7.26]) by cs.sfu.ca (8.12.9/8.12.9) with SMTP id h6T6v67f003723 for ; Mon, 28 Jul 2003 23:57:06 -0700 (PDT) Message-ID: <012201c3559e$9f4e2c00$1a073cc7@fas.sfu.ca> From: "Nenad Laskovic" To: Subject: DiffServ field in IPv6 Date: Mon, 28 Jul 2003 23:57:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have founded in several rfc's (2474, 2780, 2553) that DiffServ codepoint field will be use instead of traffic class field of IPv6 and ToS field of IPv4. Is this change still accurate? thanks, Nenad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 01:58:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6T8vh06008254; Tue, 29 Jul 2003 01:57:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6T8vNni008246; Tue, 29 Jul 2003 01:57:23 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6T8v406008206 for ; Tue, 29 Jul 2003 01:57:19 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6T8sXV7000916 for ; Tue, 29 Jul 2003 01:54:34 -0700 (PDT) Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6T8sQHh005186 for ; Tue, 29 Jul 2003 02:54:27 -0600 (MDT) Received: from lt38 ([10.4.1.81]) by galileo5.galileo.co.il (8.12.6/8.12.6) with SMTP id h6T9pr5T018053 for ; Tue, 29 Jul 2003 11:51:53 +0200 (GMT-2) Message-ID: <03eb01c355b7$cd54f8e0$2a01040a@lt38> From: "Nir Arad" To: "'IPng mailing list'" References: <000001c354f6$215459d0$010aa8c0@chirayu.org> Subject: Re: IPv6 -> MAC multicast address mapping Date: Tue, 29 Jul 2003 11:57:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the reply, Chirayu. Indeed, this does not seem expensive (even for a hardware implementation...), but if it is agreed that this validation should take place, perhaps it should be documented in the "Node Requirements", or in RFC 2464 and the likes which mandate those mappings. Regards, -- Nir Arad ----- Original Message ----- From: "Chirayu Patel" To: "'IPng mailing list'" Cc: "'Nir Arad'" Sent: Monday, July 28, 2003 12:50 PM Subject: RE: IPv6 -> MAC multicast address mapping > Hi Nir, > > My thoughts... Add the validation check! It does not seem to be expensive. > One scenario where is this check might be useful is to prevent > identification of the OS running on the router; the assumption is that not > checking the mapping is/will be atypical behavior. :-) > > CP > > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] > On Behalf Of Nir Arad > Sent: Sunday, July 27, 2003 6:23 PM > To: IPng mailing list > Subject: IPv6 -> MAC multicast address mapping > > Hi, > > Should a node (a router) check the validity of the mapping of IPv6 multicast > destination address into the Ethernet MAC multicast address? > > I didn't find this requirement anywhere, and perhaps there shouldn't be one, > but I wanted to provoke some thought on this issue. > Could there be a security issue? Perhaps other issues? > > Regards, > > -- Nir Arad > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 02:00:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6T8xv06008386; Tue, 29 Jul 2003 02:00:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6T8xa8c008373; Tue, 29 Jul 2003 01:59:36 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6T8x306008338 for ; Tue, 29 Jul 2003 01:59:18 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6T8uNQ26242; Tue, 29 Jul 2003 10:56:23 +0200 (MEST) Date: Tue, 29 Jul 2003 10:54:13 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: state-of-art SLs To: Bhaskar S Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3F258DD8.820CCC2A@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The document mentioned below, has it been published? If yes > please could you send me the link? > > > > > (1) Publish an informational document that explains the issues > > encountered with site-local addressing and our reasons > > for deprecating IPv6 site-local unicast addresses. This > > document will officially deprecate site-local addressing. Hasn't been published. But this is the document that Brian Carpenter said he is a co-author of. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 05:19:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TCJX06012390; Tue, 29 Jul 2003 05:19:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TCJDxJ012382; Tue, 29 Jul 2003 05:19:13 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TCIs06012349 for ; Tue, 29 Jul 2003 05:19:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TCGPUu021386 for ; Tue, 29 Jul 2003 05:16:25 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6TCGJLR003393 for ; Tue, 29 Jul 2003 05:16:20 -0700 (PDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6TCGAGh100012 for ; Tue, 29 Jul 2003 14:16:15 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6TCG6hL193120 for ; Tue, 29 Jul 2003 14:16:07 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA21700 for ; Tue, 29 Jul 2003 14:16:05 +0200 Message-ID: <3F266587.53A9198E@zurich.ibm.com> Date: Tue, 29 Jul 2003 14:16:07 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: state-of-art SLs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When it has been drafted, it will be announced like any other draft. Brian (one of the "volunteered" co-authors) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK Michel Py wrote: > > > Bhaskar S wrote: > > The document mentioned below, has it been published? > > If yes please could you send me the link? > > Ditto. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 05:30:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TCTb06012628; Tue, 29 Jul 2003 05:29:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TCTHAG012624; Tue, 29 Jul 2003 05:29:17 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TCSi06012593 for ; Tue, 29 Jul 2003 05:28:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TCQFV7009628 for ; Tue, 29 Jul 2003 05:26:15 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6TCQ9LR007811 for ; Tue, 29 Jul 2003 05:26:09 -0700 (PDT) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.12.9/8.12.8) with SMTP id h6TCQ7RJ014159 for ; Tue, 29 Jul 2003 14:26:07 +0200 (MEST) Received: (from ignatios@newton.cs.uni-bonn.de) by newton.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb1 15Feb2003); Tue, 29 Jul 2003 14:25:55 CEST (sender ignatios@newton.cs.uni-bonn.de) Date: Tue, 29 Jul 2003 14:25:55 +0200 From: Ignatios Souvatzis Cc: IPng mailing list Subject: Re: IPv6 -> MAC multicast address mapping Message-ID: <20030729122555.GB21990@cs.uni-bonn.de> References: <016c01c3543d$ff717630$2a01040a@lt38> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline In-Reply-To: <016c01c3543d$ff717630$2a01040a@lt38> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Sun, Jul 27, 2003 at 02:52:54PM +0200, Nir Arad wrote: > Should a node (a router) check the validity of the mapping of IPv6 > multicast destination address into the Ethernet MAC multicast address? In a weak sense, they do this automatically, by=20 a) implementing a MAC multicast filter representing the subscribed IP multicast group list, thus only receiving correct packets b) checking for what IP group the received packets are, and discarding the= =20 wrong ones in one way or other. Now, this is only a very weak check, because: a1) most hardware multicast filters are leaking ab2) a node can subscribe to multiple groups, probably mapped to different MAC multicast addresses. Thus nodes subscribed to addresses A and B don't normally know if a message for group A was received at MAC(B). If I=20 understand correctly, this is your concern. I can't think of a way this is a security problem - can you point this out please? With the exception that a DOS might be mounted by sending packets to the wrong MAC address that are later discarded... But you'll have to stop them at the source, not at the receivers, to prevent the DOS. Regards, -is --NU0Ex4SbNnrxsi6C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPyZnzTCn4om+4LhpAQGa6QgAiFV8BbL5XQy/v8JFPkRymRTzBOlWxI68 QjrQE+U9z57xG6LTLOjkER5cunPm5qfEmX0WL36FEmofzTz5Ak3It42FZ5kc3Ttz Duc1lwnzvGEuBSyD2TX33RPfgRavzyQSd7ruJaHqBMGrlJO3ppMaGyy60vDtFe+p hhZoERVGV8H6vDzx2z4QWybhuq5MpniDYS5bHQMpamgLo3Y21/ehmwqSP54wIxcO NQOxB+4xmJMi+WgRFQJAYQ2gqFL8bJvqssEtENoWs3uJBthxYB+ksGTckFYeRuYu GUClOGyarAjohiFj3SF4v5XrqB+fgsDJja7lWZxkl9MoNAfbQfMlzA== =uzOX -----END PGP SIGNATURE----- --NU0Ex4SbNnrxsi6C-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 05:51:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TCok06013038; Tue, 29 Jul 2003 05:50:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TCoPX2013026; Tue, 29 Jul 2003 05:50:25 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TCnr06012991 for ; Tue, 29 Jul 2003 05:50:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TClNV7013658 for ; Tue, 29 Jul 2003 05:47:24 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6TClIT5026117 for ; Tue, 29 Jul 2003 05:47:18 -0700 (PDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6TClHc8248670; Tue, 29 Jul 2003 08:47:17 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-198-222.mts.ibm.com [9.65.198.222]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6TClFrx050648; Tue, 29 Jul 2003 06:47:16 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h6TCkES14632; Tue, 29 Jul 2003 08:46:14 -0400 Message-Id: <200307291246.h6TCkES14632@cichlid.adsl.duke.edu> To: "Dave Thaler" cc: ipng@sunroof.eng.sun.com Subject: Re: a concern on bridge-like nd-proxies In-Reply-To: Message from dthaler@windows.microsoft.com of "Wed, 16 Jul 2003 07:32:29 PDT." Date: Tue, 29 Jul 2003 08:46:13 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Dave Thaler" writes: > Currently the IPv6 charter has a goal: > Jul 03 Submit Proxy RA to IESG for Proposed Standard. To be clear, the charter also says: o Develop Proxy Router Advertisement solution for prefix delegation and publish. This enables a simple site border router to re-advertise downstream a prefix it hears on its upstream link. The Multi-Link subnet work will be used as the basis for this. Note: General multi-link subnet work will be done elsewhere in the IETF. I.e., the charter item is NOT "multi-link subnets". It is a rather specific subset of multi-link subnets geared (as I understand it) to the particular problem of wanting to have a /64 assigned to one (e.g., P2P link) also be bridged to an attached Ethernet on the other side of the router. It is not the full multi-link subnet solution. Currently, the full-blown multi-link subnet has no home in the IETF. IMO, finding such a home would likely require a BOF, where the community has a chance to understand just what the problem is, applicability, etc. I.e., Pekka raised some valid questions in this regard earlier in this thread. The multi-link subnet work also relates to the topic of zerouter, for which there was one BOF already. See http://internet.motlabs.com/mailman/listinfo/zerouter (and its archives) for more info. http://internet.motlabs.com/pipermail/zerouter/2003-July/000262.html might also be relevant. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 07:40:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TEdl06015772; Tue, 29 Jul 2003 07:39:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TEdRGP015754; Tue, 29 Jul 2003 07:39:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TEcd06015702 for ; Tue, 29 Jul 2003 07:38:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TEa9Uu020997 for ; Tue, 29 Jul 2003 07:36:09 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6TEZvTS022756 for ; Tue, 29 Jul 2003 07:35:58 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h6TEZkK12522; Tue, 29 Jul 2003 21:35:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h6TEZYs08497; Tue, 29 Jul 2003 21:35:39 +0700 (ICT) From: Robert Elz To: Scott Bradner cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: state-of-art SLs In-Reply-To: <200307281911.h6SJB15T003911@newdev.harvard.edu> References: <200307281911.h6SJB15T003911@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Jul 2003 21:35:34 +0700 Message-ID: <8568.1059489334@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 28 Jul 2003 15:11:01 -0400 (EDT) From: Scott Bradner Message-ID: <200307281911.h6SJB15T003911@newdev.harvard.edu> | humm - it is not all that often that we have said that 2/3 is rough | consensus in the IETF Well said. In another place, not all that far away, at another time, also not all that far away, where there was an issue that was dividing the working group concerned, and where there was a search for a consensus, the chair (very wisely, and correctly, IMNSHO) eventually said... | The FOO_BAR issue has to some extent polarized the working group into folks | that are "for" FOO_BAR and folks that are "against" FOO_BAR. | Fortunately, the polarization is not strong and for the most part amicable. | But ultimately, this polarization puts the WG chairs in a nearly impossible | situation. | Consensus doesn't mean majority rule, nor even super majority, in fact, any | sense of voting is undesirable. The fact that we have folks supporting or | not supporting FOO_BAR is a symptom that I think we've lost the way to | consensus. The decision was, that even though there were more people supporting a proposed change to an existing spec (actually in this case, just an existing I-D that had not gone as far as RFC publication, and hence "IETF as a whole" approval) than were opposed to it, there was no consensus to make the change, and the change was not made. That's what should be the position in this WG as well. At the minute however, it really doesn't matter much, as nothing has actually been done (Brian claims that eventually a draft will appear, which I expect will then get debated). Working groups claiming to have made a decision (even when the WG actually has made a decision) means just about nothing to the IETF process overall. Only publication of RFCs after IETF consensus after IETF last call achieves that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 08:17:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TFGq06017316; Tue, 29 Jul 2003 08:17:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TFGWgM017312; Tue, 29 Jul 2003 08:16:32 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TFFi06017302 for ; Tue, 29 Jul 2003 08:15:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TFDFUu000966 for ; Tue, 29 Jul 2003 08:13:15 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6TFDATS014463 for ; Tue, 29 Jul 2003 08:13:10 -0700 (PDT) Received: from ala-mrwtemp.windriver.com ([147.11.233.57]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA07147; Tue, 29 Jul 2003 08:12:38 -0700 (PDT) Message-Id: <5.1.0.14.2.20030729090944.0416bdd8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jul 2003 09:11:30 -0400 To: Bhaskar S From: Margaret Wasserman Subject: Re: state-of-art SLs Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: <3F258DD8.820CCC2A@motorola.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bhaskar, This document has not yet been published... Christian Huitema and Brian Carpenter have agreed to write it, and Christian did discuss its proposed contents in Vienna. We are hoping that a first draft will be available soon. Margaret At 04:55 PM 7/28/2003 -0400, Bhaskar S wrote: >Hi Erik, > >The document mentioned below, has it been published? If yes >please could you send me the link? > >Erik Nordmark wrote: > > > > Here is a revelant email. > > I haven't seen a different statement on WG consensus on this topic. > > > > Erik > > > > > > (1) Publish an informational document that explains the issues > > encountered with site-local addressing and our reasons > > for deprecating IPv6 site-local unicast addresses. This > > document will officially deprecate site-local addressing. > > > >-- >Best Regards, > >Bhaskar S. > >978-858-2896 (o) >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 08:38:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TFbZ06017829; Tue, 29 Jul 2003 08:37:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TFbF4C017824; Tue, 29 Jul 2003 08:37:15 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TFaf06017816 for ; Tue, 29 Jul 2003 08:36:56 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TFYCV7022672 for ; Tue, 29 Jul 2003 08:34:12 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6TFY66l005564 for ; Tue, 29 Jul 2003 09:34:07 -0600 (MDT) Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h6TFY6SD000121 for ; Tue, 29 Jul 2003 08:34:06 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h6TFY4l2031866 for ; Tue, 29 Jul 2003 10:34:06 -0500 Received: from motorola.com (ma19-0008.e2.bcs.mot.com [10.14.10.58]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.2) id P19P3KDJ; Tue, 29 Jul 2003 21:03:53 +0530 Message-ID: <3F2693DD.5952D85F@motorola.com> Date: Tue, 29 Jul 2003 11:33:49 -0400 From: Bhaskar S Organization: Motorola Inc. X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: ipng@sunroof.eng.sun.com Subject: Re: state-of-art SLs References: <5.1.0.14.2.20030729090944.0416bdd8@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Margaret, I did not mean it as a negative statement. :-) Margaret Wasserman wrote: > > Hi Bhaskar, > > This document has not yet been published... Christian Huitema > and Brian Carpenter have agreed to write it, and Christian > did discuss its proposed contents in Vienna. We are hoping > that a first draft will be available soon. > > Margaret > -- Best Regards, Bhaskar S. 978-858-2896 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 09:04:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TG4Y06018420; Tue, 29 Jul 2003 09:04:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TG4EH0018391; Tue, 29 Jul 2003 09:04:14 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TG3f06018372 for ; Tue, 29 Jul 2003 09:03:56 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TG1BV7002652 for ; Tue, 29 Jul 2003 09:01:11 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6TG11pO020831 for ; Tue, 29 Jul 2003 10:01:01 -0600 (MDT) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.12.9/8.12.8) with SMTP id h6TG0xRJ020608 for ; Tue, 29 Jul 2003 18:01:00 +0200 (MEST) Received: (from ignatios@newton.cs.uni-bonn.de) by newton.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb1 15Feb2003); Tue, 29 Jul 2003 18:00:48 CEST (sender ignatios@newton.cs.uni-bonn.de) Date: Tue, 29 Jul 2003 18:00:48 +0200 From: Ignatios Souvatzis To: IPng mailing list Subject: Re: IPv6 -> MAC multicast address mapping Message-ID: <20030729160048.GC26253@cs.uni-bonn.de> References: <016c01c3543d$ff717630$2a01040a@lt38> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="uXxzq0nDebZQVNAZ" Content-Disposition: inline In-Reply-To: <016c01c3543d$ff717630$2a01040a@lt38> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 27, 2003 at 02:52:54PM +0200, Nir Arad wrote: > Should a node (a router) check the validity of the mapping of IPv6 > multicast destination address into the Ethernet MAC multicast address? > Could there be a security issue? Exactly my question. To be exact: Assume the receiving node R had subscribed to IPv6 multicast groups A and B. Assume that the corresponding MAC groups are a =3D mac(A) and b =3D mac(B). Also, let C be an IPv6 multicast group with a =3D mac(C), and D be an IPv6 multicast group with mac(D) !=3D a and mac(D) !=3D b.=20 To make things more interesting, most multicast filters accept a pretty=20 large equivalence class of multicast MACs - so let E be an IPv6 multicast group with (e =3D mac(A)) !=3D a and e !=3D b, but where R receives at laye= r 2 e if it is configured to receive a. I observe: - Your proposal obviously can't protect R against receiving packets=20 addressed to C, and has to filter against them on layer 3 (actually, naturally it will do this as it will have no consumer for them). - For similar reasons, it will already block/ignore, at layer 3, all E packets. So the only case that your proposal makes a difference is when a rogue sender S sends a packet for B to the MAC address a, which is accepted on layer 2 because R also wants to receive A, and which is later accepted on L3 because R wants to accept B in the first place. * Is there any security threat here? Of course, you can construct a DOS, but you would need to block this at the sender, not after the first hop. * Also, if S sends out packets with the wrong MAC address, most receivers will NOT receive them. Harm is done to the sender, not the receiver. A=20 diagnostic tool should be around to detect this, so that S's software can be fixed - but should be add additional code to check for this everywhere, hurting all nodes for all L2-received packets, while wrongly L2'd packets are dropped anyway later? I think not. Regards, -is --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPyaaLTCn4om+4LhpAQGI3wgAgsL+lWOFRvYgYu0BoKd76Cnne1lzxc81 1zhKqdke6P3bA5Weugl9zGctX5qNNH7HgzvFKytxDgRbzeuVlFdVf2eNo8LhFXso 9/O7j/015QQHK7ol93aFA2IHEvNso3bF9fg2BulHWYtAaOboqnPLTvuP9kxbP7QD OxHZ5VhURixC1NSRYV6hsCVGnOW3AKwQfwmMBMUv0dUlBzlMhyL4rjbVH0Z6Zk3P wOatGUf4HwAr4WT5JhLR9Uu/EoQqT1gnyC+BWWKC5NZaGwLPHAWmWnfREEtUYpU3 AzBjWk+THDJK7AVPbs4Jl7mcN+107PMtCt04yNEEMFKSb6ogpsrsJQ== =Y+zT -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 13:27:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TKR406026415; Tue, 29 Jul 2003 13:27:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TKQi2w026406; Tue, 29 Jul 2003 13:26:44 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TKQB06026367 for ; Tue, 29 Jul 2003 13:26:26 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TKNfUu015290 for ; Tue, 29 Jul 2003 13:23:41 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6TKNaIJ023642 for ; Tue, 29 Jul 2003 14:23:36 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 29 Jul 2003 13:23:35 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 29 Jul 2003 13:23:35 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jul 2003 13:23:37 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jul 2003 13:23:35 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jul 2003 13:23:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 -> MAC multicast address mapping Date: Tue, 29 Jul 2003 13:23:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 -> MAC multicast address mapping Thread-Index: AcNV/fGf/ui4uXVhTE6yTC3JTjkgvwAEF/sg From: "Christian Huitema" To: "Ignatios Souvatzis" Cc: "IPng mailing list" X-OriginalArrivalTime: 29 Jul 2003 20:23:27.0576 (UTC) FILETIME=[44D42D80:01C3560F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6TKQQ06026374 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I can't think of a way this is a security problem - can you point this out > please? With the exception that a DOS might be mounted by sending packets > to the wrong MAC address that are later discarded... But you'll have to > stop them at the source, not at the receivers, to prevent the DOS. There is a class of attacks based on mismatches between MAC and IP addressing. For example, if a node is a member of an IP group, it is possible to send it a packet where the MAC destination is the unicast MAC address of the node, while the IP destination is the group address. Or vice versa, send a packet where the MAC destination is a multicast address, but the IP destination is a unicast address. Hackers can use the first technique to disrupt the operation of multicast groups, and the second one to mount some forms of denial of service attacks. These attacks require that the attacker be connected on the same link as a target, but there are cases such as public access wireless where this isn't much of a mitigation. (University dorms are also a great place for such attacks.) -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 15:51:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TMpF06001274; Tue, 29 Jul 2003 15:51:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6TMotCS001269; Tue, 29 Jul 2003 15:50:55 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6TMoM06001230 for ; Tue, 29 Jul 2003 15:50:37 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TMlqUu009175 for ; Tue, 29 Jul 2003 15:47:52 -0700 (PDT) Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6TMllNN016690 for ; Tue, 29 Jul 2003 16:47:47 -0600 (MDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6TMlapp024960; Tue, 29 Jul 2003 15:47:37 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com ([128.107.176.199]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT33958; Tue, 29 Jul 2003 15:42:37 -0700 (PDT) Message-Id: <5.2.0.9.2.20030729154553.038fc328@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Jul 2003 15:46:00 -0700 To: "Nenad Laskovic" From: Fred Baker Subject: Re: DiffServ field in IPv6 Cc: In-Reply-To: <012201c3559e$9f4e2c00$1a073cc7@fas.sfu.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:57 PM 7/28/2003 -0700, Nenad Laskovic wrote: >I have founded in several rfc's (2474, 2780, 2553) that DiffServ codepoint >field will be use instead of traffic class field of IPv6 and ToS field of >IPv4. Is this change still accurate? yes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 17:08:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6U07R06003724; Tue, 29 Jul 2003 17:07:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6U077dK003719; Tue, 29 Jul 2003 17:07:07 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6U06Y06003692 for ; Tue, 29 Jul 2003 17:06:49 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6U044Uu004843 for ; Tue, 29 Jul 2003 17:04:05 -0700 (PDT) Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6U03xpO009385 for ; Tue, 29 Jul 2003 18:03:59 -0600 (MDT) Received: from caper (caper [199.60.7.26]) by cs.sfu.ca (8.12.9/8.12.9) with SMTP id h6U03rml023225; Tue, 29 Jul 2003 17:03:53 -0700 (PDT) Message-ID: <004c01c3562e$10348e70$1a073cc7@fas.sfu.ca> From: "Nenad Laskovic" To: "Fred Baker" Cc: References: <5.2.0.9.2.20030729154553.038fc328@mira-sjc5-b.cisco.com> Subject: Re: DiffServ field Date: Tue, 29 Jul 2003 16:54:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know is use of DiffServ field supported in some equipment and networks? > At 11:57 PM 7/28/2003 -0700, Nenad Laskovic wrote: > >I have founded in several rfc's (2474, 2780, 2553) that DiffServ codepoint > >field will be use instead of traffic class field of IPv6 and ToS field of > >IPv4. Is this change still accurate? > > yes. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 17:18:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6U0Hf06003962; Tue, 29 Jul 2003 17:17:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6U0HLuV003948; Tue, 29 Jul 2003 17:17:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6U0Gm06003904 for ; Tue, 29 Jul 2003 17:17:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6U0EJV7028902 for ; Tue, 29 Jul 2003 17:14:19 -0700 (PDT) Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6U0EDTU000071 for ; Tue, 29 Jul 2003 17:14:13 -0700 (PDT) Received: from caper (caper [199.60.7.26]) by cs.sfu.ca (8.12.9/8.12.9) with SMTP id h6U0E7ml024058; Tue, 29 Jul 2003 17:14:08 -0700 (PDT) Message-ID: <005401c3562f$7e825c30$1a073cc7@fas.sfu.ca> From: "Nenad Laskovic" To: "Fred Baker" Cc: References: <5.2.0.9.2.20030729154553.038fc328@mira-sjc5-b.cisco.com> Subject: Re: DiffServ field Date: Tue, 29 Jul 2003 17:14:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you Fred. Does anyone know is use of DiffServ field supported in some equipment and networks? > At 11:57 PM 7/28/2003 -0700, Nenad Laskovic wrote: > >I have founded in several rfc's (2474, 2780, 2553) that DiffServ codepoint > >field will be use instead of traffic class field of IPv6 and ToS field of > >IPv4. Is this change still accurate? > > yes. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 17:23:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6U0N306004102; Tue, 29 Jul 2003 17:23:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6U0MhGU004101; Tue, 29 Jul 2003 17:22:43 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6U0MA06004093 for ; Tue, 29 Jul 2003 17:22:25 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6U0JfV7000382 for ; Tue, 29 Jul 2003 17:19:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6U0JZpO015355 for ; Tue, 29 Jul 2003 18:19:35 -0600 (MDT) Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 17:22:19 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6U0JXLH021183; Tue, 29 Jul 2003 17:19:33 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com ([128.107.176.199]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT46359; Tue, 29 Jul 2003 17:14:37 -0700 (PDT) Message-Id: <5.2.0.9.2.20030729171829.036f5b98@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Jul 2003 17:19:22 -0700 To: "Nenad Laskovic" From: Fred Baker Subject: Re: DiffServ field Cc: In-Reply-To: <004c01c3562e$10348e70$1a073cc7@fas.sfu.ca> References: <5.2.0.9.2.20030729154553.038fc328@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:54 PM 7/29/2003 -0700, Nenad Laskovic wrote: >Does anyone know is use of DiffServ field supported in some equipment and >networks? It is supported in some equipment. I wouldn't be able to tell you how networks configure their equipment; they generally view this as NDA information. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 23:14:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6U6EX06014554; Tue, 29 Jul 2003 23:14:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6U6ECnP014513; Tue, 29 Jul 2003 23:14:12 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6U6Ds06014490 for ; Tue, 29 Jul 2003 23:14:09 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6U6BOUu024850 for ; Tue, 29 Jul 2003 23:11:24 -0700 (PDT) Received: from mail.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6U6BHNN024687 for ; Wed, 30 Jul 2003 00:11:19 -0600 (MDT) Received: from lt38 ([10.4.1.81]) by mail.galileo.co.il (8.12.6/8.12.6) with SMTP id h6U78j6D006559 for ; Wed, 30 Jul 2003 09:08:45 +0200 (GMT-2) Message-ID: <051c01c3566a$2d283e00$2a01040a@lt38> From: "Nir Arad" To: "IPng mailing list" References: Subject: Re: IPv6 -> MAC multicast address mapping Date: Wed, 30 Jul 2003 09:14:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for all the replies - the check goes in. >From a MIB perspective, I guess those should count as "ipv6IfStatsInHdrErrors". Regards, -- Nir Arad ----- Original Message ----- From: "Christian Huitema" To: "Ignatios Souvatzis" Cc: "IPng mailing list" Sent: Tuesday, July 29, 2003 10:23 PM Subject: RE: IPv6 -> MAC multicast address mapping > > I can't think of a way this is a security problem - can you point this > out > > please? With the exception that a DOS might be mounted by sending > packets > > to the wrong MAC address that are later discarded... But you'll have > to > > stop them at the source, not at the receivers, to prevent the DOS. > > There is a class of attacks based on mismatches between MAC and IP > addressing. For example, if a node is a member of an IP group, it is > possible to send it a packet where the MAC destination is the unicast > MAC address of the node, while the IP destination is the group address. > Or vice versa, send a packet where the MAC destination is a multicast > address, but the IP destination is a unicast address. Hackers can use > the first technique to disrupt the operation of multicast groups, and > the second one to mount some forms of denial of service attacks. These > attacks require that the attacker be connected on the same link as a > target, but there are cases such as public access wireless where this > isn't much of a mitigation. (University dorms are also a great place for > such attacks.) > > -- Christian Huitema > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 04:51:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6UBoo06023390; Wed, 30 Jul 2003 04:51:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6UBoUTd023383; Wed, 30 Jul 2003 04:50:30 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6UBnf06023331 for ; Wed, 30 Jul 2003 04:49:57 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6UBl1Q18536; Wed, 30 Jul 2003 13:47:01 +0200 (MEST) Date: Wed, 30 Jul 2003 13:44:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Same global address on Multiple Interface of an IP6 node To: Roy Brabson Cc: suvendum@future.futsoft.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Redundancy. If one interface goes down, traffic will automatically switch > to the another interface without disrupting existing connections. I think there is some confusion between the conceptual descrption of IPv6 (using terms like "interface" and "link" as per RFC 2460) and how one can actually build a system using e.g. Ethernet cards. At the conceptual level a global unicast address can only be assigned to one interface in the Internet. But since the "interface" is an abstraction that is provided to IP there is nothing to prevent an implementation whicb uses multiple Ethernet cards attached to the same or different Ethernet switches as long as this is transparent to IP. An example of such an approach is IEEE 802.3ad which provides what looks like a single aggregate, with a single MAC address, on top of multiple Ethernet cards. (If you read the IEEE 802 specs be aware that the definition of "link" is subtle but completely different between those specs and RFC 2460.) So far so good. There might be cases where you want to use a slightly different implementation technique where the abstraction has multiple MAC addresses; for instance one per participating Ethernet card. There isn't much in the RFCs to guide such an approach, but as long as it interoperates with other implementations it would be ok. There is a subtle part of RFC 2461 which tries to make this easier - the ability to omit the source link-layer address option in router advertisements be able build routers which give different link-layer addresses (for the same IP address) to different hosts using unicast neighbor advertisements. But details on how to build such a "load balance across multiple MAC addresses" thing for a router or for a host are left as a detail for the reader :-) But if you are only concerned about redundancy and not load spreading across the Ethernet cards life is probably simpler. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 08:40:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6UFdR06029852; Wed, 30 Jul 2003 08:39:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6UFd695029836; Wed, 30 Jul 2003 08:39:06 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6UFcI06029808 for ; Wed, 30 Jul 2003 08:38:33 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6UFZmV7017840 for ; Wed, 30 Jul 2003 08:35:48 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6UFZgxL002789 for ; Wed, 30 Jul 2003 09:35:42 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jul 2003 08:35:40 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Jul 2003 08:35:41 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jul 2003 08:35:35 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jul 2003 08:35:42 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jul 2003 08:35:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DiffServ field Date: Wed, 30 Jul 2003 08:35:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DiffServ field Thread-Index: AcNWYYVwP4xlCbt1Sjqwh0Ch+xX7xAATi5xQ From: "Christian Huitema" To: "Fred Baker" , "Nenad Laskovic" Cc: X-OriginalArrivalTime: 30 Jul 2003 15:35:20.0770 (UTC) FILETIME=[2F80AA20:01C356B0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6UFcY06029823 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Does anyone know is use of DiffServ field supported in some equipment and > >networks? > > It is supported in some equipment. I wouldn't be able to tell you how > networks configure their equipment; they generally view this as NDA > information. We have found some issues when trying to use the diffserv field in practical deployments. There are a number of routers in the network that were built and deployed before diffserv was widely accepted as a standard. Understandably, these routers implement the previous standard, i.e. the RFC 791 definition of the TOS bit. Specifically, the old routers look at the three precedence bits and treat it as a priority level. In practice, this restricts the number of diffserv code points that can be safely used. You don't want for example to define a code point for "less than best effort" in which the three precedence bits happen to mean "high priority" in the old routers... -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 10:31:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6UHV206002027; Wed, 30 Jul 2003 10:31:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6UHUg9i002025; Wed, 30 Jul 2003 10:30:42 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6UHUE06002003 for ; Wed, 30 Jul 2003 10:30:24 -0700 (PDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6UHRQtK019273; Wed, 30 Jul 2003 13:27:26 -0400 (EDT) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h6UHRQP1002159; Wed, 30 Jul 2003 13:27:26 -0400 (EDT) Message-Id: <200307301727.h6UHRQP1002159@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Erik Nordmark cc: samita.chakrabarti@Sun.COM, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: Re: comments on address selection API In-Reply-To: Message from Erik Nordmark of "Wed, 23 Jul 2003 09:28:27 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jul 2003 13:27:26 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have an additional comment on the draft relating to the four new AI_PREFER_* getaddrinfo() flags (new in version 1 of the draft). AI_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope */ AI_PREFER_SRC_LOWERSCOPE /* Prefer lower than largest scope */ AI_PREFER_SRC_TUNNEL /* Prefer address of tunnel interface */ AI_PREFER_SRC_NATIVE /* Prefer native IPv6 address */ I don't know if this is the right place to be defining these preferences. By defining these flags, wouldn't we be suggesting that the control of these two destination address selection rules (rules 7 and 8) belongs to application developers? Preferring larger scope destinations rather than smaller scope destinations seems like a situational run-time preference, and same with preferring tunnel output interfaces over native interfaces. My initial though when I saw these preferences was that we should be giving individuals running applications the control, not individuals writing applications. You could argue that applications could set these flags based on additional input from the environment, but that seems ugly since every application would need to be changed. Otherwise some applications would behave differently than others based on how or if they handle this environmental input. Instead, environmental input could be handled directly by the library that implements the address ordering mechanism. I'm deliberatly not using the term "environment variable" to stay OS neutral and to not directly suggest one method of implementation in this context. -Seb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 23:42:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6V6fG06025713; Wed, 30 Jul 2003 23:41:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6V6etQe025712; Wed, 30 Jul 2003 23:40:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6V6dr06025693 for ; Wed, 30 Jul 2003 23:40:08 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6V6bLV7009633 for ; Wed, 30 Jul 2003 23:37:21 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6V6bFVP020175 for ; Thu, 31 Jul 2003 00:37:16 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6V6assi101188; Thu, 31 Jul 2003 08:36:54 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6V6arkA240724; Thu, 31 Jul 2003 08:36:53 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA40826; Thu, 31 Jul 2003 08:36:52 +0200 Message-ID: <3F28B904.D5D1A422@zurich.ibm.com> Date: Thu, 31 Jul 2003 08:36:52 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Christian Huitema CC: Fred Baker , Nenad Laskovic , ipng@sunroof.eng.sun.com Subject: Re: DiffServ field References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk That's why some care was used in choosing the recommended code points in the various RFCs. If you use the default values, a router set up for precedence will behave reasonably. But indeed, an IPv4 network where some routers have legacy TOS behaviour and others have diffserv behaviour will not deliver perfect diffserv. We shouldn't have this problem for IPv6, where TOS behaviour was never defined. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK Christian Huitema wrote: > > > >Does anyone know is use of DiffServ field supported in some equipment > and > > >networks? > > > > It is supported in some equipment. I wouldn't be able to tell you how > > networks configure their equipment; they generally view this as NDA > > information. > > We have found some issues when trying to use the diffserv field in > practical deployments. There are a number of routers in the network that > were built and deployed before diffserv was widely accepted as a > standard. Understandably, these routers implement the previous standard, > i.e. the RFC 791 definition of the TOS bit. Specifically, the old > routers look at the three precedence bits and treat it as a priority > level. In practice, this restricts the number of diffserv code points > that can be safely used. You don't want for example to define a code > point for "less than best effort" in which the three precedence bits > happen to mean "high priority" in the old routers... > > -- Christian Huitema > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 31 06:51:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6VDpG06008084; Thu, 31 Jul 2003 06:51:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6VDou6e008073; Thu, 31 Jul 2003 06:50:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6VDoN06008031 for ; Thu, 31 Jul 2003 06:50:38 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6VDlpUu015269 for ; Thu, 31 Jul 2003 06:47:51 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6VDlWEV017624 for ; Thu, 31 Jul 2003 07:47:33 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h6VDiVH07845; Thu, 31 Jul 2003 20:44:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h6VDbve22196; Thu, 31 Jul 2003 20:38:18 +0700 (ICT) From: Robert Elz To: Sebastien Roy cc: Erik Nordmark , samita.chakrabarti@Sun.COM, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: comments on address selection API In-Reply-To: <200307301727.h6UHRQP1002159@strat.East.Sun.COM> References: <200307301727.h6UHRQP1002159@strat.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jul 2003 20:37:57 +0700 Message-ID: <11613.1059658677@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 30 Jul 2003 13:27:26 -0400 From: Sebastien Roy Message-ID: <200307301727.h6UHRQP1002159@strat.East.Sun.COM> | My initial though when I | saw these preferences was that we should be giving individuals running | applications the control, not individuals writing applications. There's no way to avoid that. The user (individual running the application) can only ever express as much control as the application allows - burying things in libraries only makes it more difficult for the application to override, it doesn't prevent it (even to the extent of the application ignoring the standard library routines, and doing things its own way if the libraries insist on doing things the application doesn't like). You seem to want to legislate in favour of intelligently written applications that do things in wise and meaningful fashions - that doesn't work at this level, all that can ever be done is to attempt to get the users to prefer to use applications that work in ways that make sense to them. Allowing applications to set flags to control the address choices from the library routines seems sensible to me - this doesn't mean that this needs to be the only input to the address selection choice that an implementation provides. And yes, usually you do want the application to pick what is the best default for it - "environmental controls" are usually much too crude a control for this purpose - that is, it isn't the case that every application should behave the same, for connections from host A to host B for some applications one address choice is better than another, for other applications the answer comes out exactly the other way around. When I, the user, know better, I'm going to want a way to override the application's preference - and if the application doesn't provide that, I'll either fix it, if I can, or perhaps work around it (add new names in the DNS that only provide a subset of addresses...) or if none of those is possible, just avoid using the application concerned. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 31 16:50:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6VNnR06023260; Thu, 31 Jul 2003 16:49:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h6VNn7qt023258; Thu, 31 Jul 2003 16:49:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (new-engmail1mpk [129.146.11.21]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h6VNmX06023251 for ; Thu, 31 Jul 2003 16:48:48 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6VNk1V7012989 for ; Thu, 31 Jul 2003 16:46:02 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6VNjjmR008759 for ; Thu, 31 Jul 2003 17:45:53 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Jul 2003 16:45:43 -0700 From: "Tony Hain" To: Cc: Subject: FW: AD response to Site-Local Appeal Date: Thu, 31 Jul 2003 16:44:19 -0700 Message-ID: <086101c357bd$a984e440$70144104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h6VNmn06023252 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IESG, Unfortunately it is necessary to bring this appeal to the IESG as the chairs & chartering AD's have not taken the ample opportunity to recognize the seriousness of the problem of allowing a chair to ask an ambiguous question, then decide what it means after the fact. As the video of the SF meeting ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 - 03202003 - INT ipv6.mpg (989MB) clearly shows, the overriding goal was declaring consensus, not on actually recognizing or achieving it. From comments on the mail list, the chair appears to have had a personal mission of getting SL removed from the scoped architecture document and progressing it without discussion of the one scope most widely deployed in the IPv4 network. This oversight will result in a serious degradation of the quality of the WG output. There was and still is no consensus in the WG about what 'deprecate site-local' means, just a declaration by the chair that consensus occurred. During the SF meeting multiple current & former IESG & IAB members felt the need to get clarity about the question being asked, and there was an explicit unanswered request by Dave Thaler asking for an indication what action implementations should take if elimination was selected. The best the chair offered was the response at 2:13:19 "I'll resay what I said earlier which is I had said we would say eliminate it or keep it and then we'd have multiple choices if we kept it but apparently if we eliminate it we will also have multiple choices about what exactly that means". In other words, the chair acknowledged the ambiguity of the question, but persisted in calling it despite the lack of anyone in the room to make an informed decision about the outcome of their choice. The question asked to the list was no clearer. The declaration of consensus must be overturned as an abuse of the process. This should be done soon as the whole event has created a state of confusion where network managers are questioning how they are supposed to deploy IPv6 without locally controlled address space. The subsequent discussion on the mail list identified multiple work items, which the WG should or is already undertaking, and those can be accomplished without the chairs calling further questions on the topic. In particular, a document identifying the requirements for local use address space is underway. Until the WG agrees on the requirements, there is no possibility for the group to evaluate the utility of the current SL or other approaches. Tony Hain ---- While waiting for the 989MB to download, jump to 24 Apr message below which contains excerpts from the SF video which highlight the confusion over the meaning of the question being asked. > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, July 16, 2003 8:07 AM > To: 'Thomas Narten' > Cc: 'ipng@sunroof.eng.sun.com' > Subject: RE: AD response to Site-Local Appeal > > > inline - > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Thomas Narten > > Sent: Wednesday, July 09, 2003 6:01 AM > > To: Tony Hain > > Cc: ipng@sunroof.eng.sun.com > > Subject: AD response to Site-Local Appeal > > > > > > [Note that this message is very long because it includes the > > cited email messages verbatim; we are not aware of an IPv6 WG > > mailing list archive that provide URL references for > > individual emails.] > > > > Tony, > > > > We have reviewed your appeal of the IPv6 WG chairs calling of > > consensus to deprecate site-local addresses from the IPv6 > > architecture. We believe they have acted properly, and > > indeed, have done an admirable job of moving the WG forward > > on a complex, subtle and divisive topic that has troubled the > > WG and the IETF as a whole for a long time. We find that the > > chairs have responded reasonably and appropriately to your > > appeal and agree with their response. Based on our review, we > > reject your appeal in its entirety. > > As I expected. I agree the chairs have moved the WG, but > 'forward' is not the direction. > > > > > Some specifics: > > > > Your appeal seems to center around the point that different > > people had different reasons for responding to the question > > of whether or not to deprecate SLs and that those reasons > > were different enough that it isn't appropriate to use those > > differing reasons to conclude a single outcome, namely to > > deprecate SLs. > > > > We disagree. The question asked by the chairs was not about > > the differing reasons, the question was specifically about > > SLs, and whether the WG wanted to deprecate them. That the > > question referred specifically to deprecating site locals > > (and not the reasons why one might do so) is obvious. It is > > common in the IETF when deciding technical issues for > > different people to have different reasons for coming to a > > particular conclusion, or to weigh tradeoffs differently. In > > the end, if there is consensus on the answer to a specific > > question, we have consensus, even if the reasons for reaching > > a particular outcome are not shared. > > Unfortunately this is a misinterpretation of my point. It is > not focused on 'different people had different reasons', > because we agree there will always be different perspectives > and opinions. The focus was that a significant number of > participants had the specific reason 'remove limited > scoping', and this is not something the IETF gets to decide. > It is an operational issue, and network managers will build > networks where addresses have limited routing scope. > > > > > In your response to the chairs [8], > > > > "Tony Hain" writes: > > > > > Margaret Wasserman wrote: > > > > (3) You do not believe that there is rough consensus to > > > > deprecate IPv6 site-local addressing, because people > > > > provided different reasons for why they believe that > > > > IPv6 site-local addressing should be deprecated. In > > > > particular, some people want to deprecate the particular > > > > model of site-local addressing defined in the scoped > > > > addressing architecture (ambiguous, scoped addresses), > > > > while others do not believe that we need a local > > > > addressing mechanism at all. > > > > > I was not objecting to 'different reasons'. The specific > > complaint is > > > that many of YES votes were for removing the architectural > > construct, > > > or need for applications to deal with addresses that are only > > > accessable over a limited scope. That is not in the > purview of the > > > IETF to decide, it is an operational decision of the > > network manager. > > > Those votes are not valid as a result. > > > > It is certainly within the purview of a WG (and/or IETF) to > > decide what it wants to work on. Given that the IETF defined > > a designated site-local prefix in RFC 1884 it can also choose > > to undo that definition. This doesn't remove the ability for > > network managers to do filtering, or remove their ability to > > allocate address ranges for any particular purpose including > > "local use". Moreover, if the WG does not want to work on > > defining a model that requires applications to deal with > > "addresses that are only accessible over a limited scope", it > > can certainly make such a choice. > > This response highlights the point that not even you know > what the meaning of the question was. If the group had been > asked explicitly about removing limited scope, I agree the > group gets to decide that. If the group had been explicitly > asked about removing ambiguity from the addresses used for > local scope, I agree the group gets to decide that. What the > group was asked was; > - Should we deprecate IPv6 site-local unicast addressing? > - > - Valid responses are: > - > - "YES -- Deprecate site-local unicast addressing". > - "NO -- Do not deprecate site-local unicast addressing". > with the additional 'guidance' from the chair for those in > the room in San Francisco that '... if we eliminate it we > will also have multiple choices about what exactly that means > ...' & '... may have to handwave ...'. It was only after the > fact that the chairs started providing interpretations as to > what the question might mean. > > > > > We also note that you seem to have a broader definition of > > "scoping" (and the requirements that must be met by the > > architecture to support such scoping) than many, and you > > appear to be choosing to view the decision to deprecate SLs > > as an attempt to outlaw (or eliminate) all forms of such > > scoping, including the ability of site operators to filter on > > arbitrary addresses (which you seem to include in your > > definition). This view is incorrect. The decision to > > deprecate SLs is just that. It is not a decision to outlaw > > all forms of scoping or to forbid operators from (say) > > filtering packets based on addresses. > > I am only reflecting the viewpoints of some votes for > deprecation. Those votes are the invalid ones, and must be removed. > > > > > > > Point (4): > > > > > > > > It is true that the IPv6 WG has not produced a WG document that > > > > analyzes the operational requirements for local addressing. > > > > However, we do not believe that this is a reason to > invalidate the > > > > IPv6 WG consensus to deprecate IPv6 site-local unicast > addressing. > > > > > You said it multiple times in SF yourself, the WG needs complete > > > documentation to do an appropriate analysis. You appear to > > be letting > > > your desire to 'be right' get in the way of your ability > to analyze > > > your own responses. I don't understand how can you > > objectively say 'we > > > don't need a document describing the need for X to decide that we > > > don't need X'? > > > > The key issue is whether the community believes it has enough > > information to make a decision and is ready to make a > > decision. When complex issues are being discussed it is > > important that sufficient information is available and that > > the issue has been thought through. In such cases it makes > > sense to try to get detailed documentation listing the pros > > and cons of the choices, e.g., as internet-drafts, or as part > > of email discussions. So while the advance availability of an > > internet-draft on deprecation would have been good, what > > matters in the end is whether the community believes it has > > enough information to make a decision. > > The key issue is the claim that we know that SL does not meet > the requirements, yet there is no document identifying the > requirements. The community could not make a collective > informed decision since there was no common understanding of > the requirements, or understanding of the outcome of the decision. > > > > > During the meeting (early on) one person suggested that there > > wasn't enough information on which to base a decision. But > > this claim didn't appear to resonate with others, either in > > the meeting or on the mailing list. If a large number of WG > > participants had agreed with the claim, one would have > > expected them to speak up. Hence one can infer that the WG > > felt that there was sufficient information to make a decision. > > Or that since the question was ambiguous, they had > independent expectations of the outcome. > > > > > In [6] you say: > > > > > >>> There is a vast difference between identifying > > direction of the > > > group and the actual yes/no to deprecate SL question that > > was asked. > > > In fact all other indications from the chairs were that the > > question > > > was NOT about measuring direction of the WG, but actually > > about their > > > intent to have local scoped addresses removed from the > > scoped address > > > architecture and other documents. > > > > The question asked was about a general direction for the WG > > to go in. The alternative to "direction" would have been a > > question about an existing document (such as an update to the > > addressing architecture doc to deprecate SLs) which was > > clearly not what was being asked. > > You are correct that the ambiguous question did not ask about > updates to specific documents. On the otherhand the chairs > summary outcome to the mail list (your reference [1]) > explicitly lists documents to be modified. > > > > > > In summary, the INT ADs do not agree with the points that you > > have raised in your appeal, and we do not agree to overturn > > the consensus of the IPv6 WG based on the issues that you > > have raised. We would also like to point out that while we > > disagree with your position on this particular issue, we do > > recognize the contributions you have made to the IPv6 effort > > and we realize that your appeal is motivated by your desire > > to do what you believe is the right thing for IPv6. We hope > > that you will accept our response and focus on working to > > define the local addressing problem and solutions in the IPv6 > > WG. It is important for the working group to move forward on > > this issue. > > It is important to move forward, but throwing something out > without understanding the real requirements for its > existence, or having a replacement is a step backward. > Although that is not the point here. The point is that the > chairs asked an ambiguous question, a significant number of > yes voters expressed opinions to remove limited scoping from > the architecture, and that opinion is not something the IETF > gets to decide. This invalidates the call for concensus. > > It is unfortunate but not surprising that this could not be > resolved at this level. > > Tony > > > > > Thomas Narten & Erik Nordmark > > Internet Area ADs > > > > > > References: > > > > [1] Message from chairs to list, announcing results of > consensus call. > > > > Return-Path: owner-ipng@sunroof.eng.sun.com > > Message-Id: > > <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> > > Date: Wed, 09 Apr 2003 15:11:04 -0700 > > To: ipng@sunroof.eng.sun.com > > From: Bob Hinden & Margaret Wasserman > > Subject: Consensus on Site-Local Addressing > > > > Hi All, > > > > Well, that was fun! :-) > > > > All told, there were over 200 responses to the consensus > call on IPv6 > > site-local addressing, approximately 3-to-1 in favor of > > deprecating IPv6 > > site-local unicast addressing. The final count (including > > the room and the > > mailing list) was: 155 YES, 56 NO (211 Total). > > > > There were also a significant number of the people on both > > sides of this > > issue that voiced (in their original responses, or in > > subsequent messages) > > a strong belief that we should investigate alternative > > mechanisms for local > > addressing and local access control. > > > > The chairs have read all of the messages on the list, and > > based on your > > considerable input, we have determined that the IPv6 WG does > > have rough > > consensus to deprecate the usage of IPv6 site-local unicast > > addressing AND > > to investigate alternative mechanisms for local addressing > > and local access > > control. > > > > In particular, the IPv6 WG will work to accomplish the > > following things in > > parallel: > > > > (1) Publish an informational document that explains the issues > > encountered with site-local addressing and our reasons > > for deprecating IPv6 site-local unicast addresses. This > > document will officially deprecate site-local addressing. > > > > (2) Remove site-local unicast addressing from the IPv6 > > scoped addressing architecture I-D, and publish the > > parts of the document on which we do have consensus > > (i.e., link local addresses, multicast, etc.). This > > will include a note that the IPv6 working group is > > investigating other forms of local IPv6 addressing and > > that the usage of any new forms of local addresses will be > > documented elsewhere. > > > > (3) Update the IPv6 addressing architecture to indicate that the > > usage of the FECO::/10 prefix for site-local addressing is > > deprecated. To maintain backward compatibility with existing > > implementations the prefix should be reserved and should not > > be allocated for other purposes. > > > > (4) Define and publish the requirements for a local addressing > > mechanism to provide: > > - Addresses for disconnected networks. > > - Addresses for intermittently connected networks. > > - Addresses that support merging of sites. > > - Stable local addresses for changing ISPs without > > disrupting local communication. > > Once we have consensus on the requirements, the IPv6 > > WG will work on solutions for local addressing that > > meet those requirements. > > > > (5) Define and publish the requirements for a local access > > control mechanism, then work on a solution that meets > > those requirements. > > > > Each of these new work items will need to be added to the > > IPv6 WG charter > > and will go through the normal IETF document processes. For > > (4) and (5) it > > is important to make the rest of the IETF community aware > > that the IPv6 WG > > is undertaking these tasks, so we will consider methods to > > invite wider > > review and discussion of these problems. > > > > IPv6 site-local addressing has been a contentious issue in > > the IPv6 WG for > > some time, and we are both glad to see the WG reach > consensus on this > > issue. This will allow us to complete and publish the IPv6 scoped > > addressing architecture document, an important part of the > > IPv6 specification. > > > > We hope that people on all sides of this issue will respect > the rough > > consensus of the WG, and will work with us to achieve the > > goals outlined above. > > > > Thanks to everyone who expressed an opinion during this discussion. > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG Chairs > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > [2] First message from Tony Hain appealing decision. > > > > Return-Path: owner-ipng@sunroof.eng.sun.com > > From: "Tony Hain" > > To: "'Thomas Narten'" , > > "'Erik Nordmark'" > > Cc: > > Subject: FW: Consensus on Site-Local Addressing > > Date: Wed, 9 Apr 2003 17:41:32 -0700 > > Message-Id: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> > > > > Thomas & Erik, > > > > Please consider this the second step in the appeal process, > > as I have already discussed these issues with the chairs on > > more than one occasion. > > > > 'we reject kings, presidents and voting...' > > The consensus measurement on the mail list was much more > > indicative of the real lack of it (60/40%), than what was > > effectively ballot stuffing by WG visitors without a complete > > context. There was a very short presentation in the apps open > > area, intended to raise concerns and incite involvement, were > > those in the apps area were agitated, then invited to the > > IPv6 WG session in SF to discuss the potential issues. The > > subsequent short discussion in the IPv6 WG showed there were > > issues to work through, and at least one question voiced > > about understanding the requirements. Rather than deal with > > the issues raised, the chairs decided to call an ambiguous > > question of yes/no for deprecation. > > > > While the chairs do in 2) recognize their interpretation of > > the consensus that the WG will investigate other forms of > > local addressing, there is no mention of ambiguity and the > > rest of the wording of 1) & 2) can be interpreted as local > > scope addressing is deprecated. The concern is that we will > > end up with a document lacking local scope addressing, and > > claims that we had consensus to remove local scope from the > > architecture. Many of those who bothered to state why they > > were expressing a yes opinion claimed ambiguity was the > > reason, while others were only interested in removing special > > handling for local scope addresses. Those are technically > > different issues, so they need different questions. What we > > have is an indication that many are unhappy with the status > > quo, but a lack of recognition that the call ended up > > combining yes opinions for removing ambiguity with yes > > opinions for removing local scope addresses from the > > architecture. From subsequent discussions with the chairs, it > > is clear that was not their intent, but never the less that > > is the result of the lack of clarity in this consensus call. > > > > '... we believe in rough consensus & running code' & from the > > Tao : 'running code wins' On several related mail threads > > there were many comments about running code, and at least > > Brian Zill & Brian Haberman said they collectively had host, > > application, and router implementations of the current SL > > running. Point 3) even acknowledges there are existing > > implementations. This consensus call intends to invalidate > > the running code, and all we have to replace it is a promise > > in 4) that if the group can ever agree that operational > > requirements of the site network manager are worth solving, > > we might start to work on solutions, subject to appropriate > > charter updates. This whole discussion is based on the > > argument that some developers couldn't create running code > > for an arguably bogus scenario where topology locators are > > blindly passed outside their scope of relevance. Bias was > > given to the opinions of those with a lack of running code, > > at the expense of, and with the specific intent of > > invalidating the code that exists. > > > > There were also claims in the meeting and mail threads that > > we have analyzed site local as currently defined, and it > > doesn't meet the requirements. At the same time, there is a > > recognition by many of the same people that we need to > > develop a complete set of requirements. It should be obvious > > that the analysis is flawed if the complete set of > > requirements are not understood first. To that end, and in > > the spirit of making progress, > > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > > editor on 4/8, and is offered as an attempt to document the > > requirements for address space with a local scope of > > relevance. It is clearly incomplete, and largely based on my > > previous email on the subject. > > > > While I contest the claim that the Yes/No opinions expressed > > measured consensus for a consistent interpretation of what > > 'deprecate site local addresses' means, I do believe that a > > set of work items for the group were identified. It is also > > clear that we can add new work to a group at any time, > > without the need to remove existing items first. I agree with > > the chairs that items 4) & 5) are valid outcomes of the > > subsequent discussion, though one thing that their > > interpretation of the result does not make clear is the > > meaning of 'accomplish the following things in parallel:'. In > > talking to the chairs it appears the intent is to start the > > work at the same time, but we need to avoid invalid > > transition states, so parallel needs to mean that all 5 are > > to be forwarded to the IESG at one time. In particular, > > without solutions to the requirements in hand, any documents > > for 1) & 3) that intend to deprecate the only local use > > address space will simply create chaos, and might need to be > > rescinded if the complete set of requirements shows a need > > with no other technical approach. > > > > In short, I do not believe the consensus call measured the > > opinions that were consistent the chairs interpretation of > > the question, so the claimed results are invalid. I do > > believe that the effort identified work items 4) & 5), with > > the potential that 1) & 3) might follow if there are no > > outstanding requirements for ambiguous address space. I > > question the wisdom of 2), but will reserve judgment until > > the complete text identifying further work is spelled out. In > > any case, I hope this appeal can be dealt with at this level, > > and that the overall effort results in an expedited charter > > update. It is imperative that new approaches exist prior to > > removal of the current, and there is a very real danger that > > the current destructive energy will dissipate in the face of > > the hard work of creating replacements. > > > > Tony > > > > > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bob Hinden & > > > Margaret Wasserman > > > Sent: Wednesday, April 09, 2003 3:11 PM > > > To: ipng@sunroof.eng.sun.com > > > Subject: Consensus on Site-Local Addressing > > > > > > > > > Hi All, > > > > > > Well, that was fun! :-) > > > > > > All told, there were over 200 responses to the consensus > > call on IPv6 > > > site-local addressing, approximately 3-to-1 in favor of > > > deprecating IPv6 > > > site-local unicast addressing. The final count (including > > > the room and the > > > mailing list) was: 155 YES, 56 NO (211 Total). > > > > > > There were also a significant number of the people on > both sides of > > > this issue that voiced (in their original responses, or in > > > subsequent messages) > > > a strong belief that we should investigate alternative > > > mechanisms for local > > > addressing and local access control. > > > > > > The chairs have read all of the messages on the list, and > based on > > > your considerable input, we have determined that the IPv6 WG does > > > have rough > > > consensus to deprecate the usage of IPv6 site-local unicast > > > addressing AND > > > to investigate alternative mechanisms for local addressing > > > and local access > > > control. > > > > > > In particular, the IPv6 WG will work to accomplish the following > > > things in > > > parallel: > > > > > > (1) Publish an informational document that explains the issues > > > encountered with site-local addressing and our reasons > > > for deprecating IPv6 site-local unicast addresses. This > > > document will officially deprecate site-local addressing. > > > > > > (2) Remove site-local unicast addressing from the IPv6 > > > scoped addressing architecture I-D, and publish the > > > parts of the document on which we do have consensus > > > (i.e., link local addresses, multicast, etc.). This > > > will include a note that the IPv6 working group is > > > investigating other forms of local IPv6 addressing and > > > that the usage of any new forms of local addresses will be > > > documented elsewhere. > > > > > > (3) Update the IPv6 addressing architecture to > indicate that the > > > usage of the FECO::/10 prefix for site-local addressing is > > > deprecated. To maintain backward compatibility > with existing > > > implementations the prefix should be reserved and > should not > > > be allocated for other purposes. > > > > > > (4) Define and publish the requirements for a local addressing > > > mechanism to provide: > > > - Addresses for disconnected networks. > > > - Addresses for intermittently connected networks. > > > - Addresses that support merging of sites. > > > - Stable local addresses for changing ISPs without > > > disrupting local communication. > > > Once we have consensus on the requirements, the IPv6 > > > WG will work on solutions for local addressing that > > > meet those requirements. > > > > > > (5) Define and publish the requirements for a local access > > > control mechanism, then work on a solution that meets > > > those requirements. > > > > > > Each of these new work items will need to be added to the IPv6 WG > > > charter and will go through the normal IETF document > processes. For > > > (4) and (5) it > > > is important to make the rest of the IETF community aware > > > that the IPv6 WG > > > is undertaking these tasks, so we will consider methods to > > > invite wider > > > review and discussion of these problems. > > > > > > IPv6 site-local addressing has been a contentious issue > in the IPv6 > > > WG for some time, and we are both glad to see the WG reach > > consensus on this > > > issue. This will allow us to complete and publish the IPv6 scoped > > > addressing architecture document, an important part of the > > > IPv6 specification. > > > > > > We hope that people on all sides of this issue will respect > > the rough > > > consensus of the WG, and will work with us to achieve the > > > goals outlined above. > > > > > > Thanks to everyone who expressed an opinion during this > discussion. > > > > > > Bob Hinden & Margaret Wasserman > > > IPv6 WG Chairs > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > [3] Note from Tony Hain indicating he will followup with > chairs first. > > > > > > Return-Path: owner-ipng@sunroof.eng.sun.com > > From: "Tony Hain" > > To: "'Thomas Narten'" > > Cc: "'Erik Nordmark'" , > > > > Subject: RE: FW: Consensus on Site-Local Addressing > > Date: Thu, 10 Apr 2003 10:04:41 -0700 > > Message-Id: <0f9101c2ff83$46f11ac0$ee1a4104@eagleswings> > > > > Thomas Narten wrote: > > > Tony, > > > > > > > Please consider this the second step in the appeal process, > > > as I have > > > > already discussed these issues with the chairs on more than one > > > > occasion. > > > > > > Discussing general issues with the chairs is not the same > as finding > > > disagreement with a specific action that the chairs have taken. I > > > suspect you have done the former, but not the latter. If you feel > > > that the chairs have erred, and that they have taken an > action that > > > isn't supported by the processes as outlined in RFC 2026 (and RFC > > > 2418), an appeal might be warranted. To file an appeal, > the process > > > is outlined in RFC 2026. Start with the chairs, use RFC > 2026/2418 as > > > a guide for what are appropriate grounds for an appeal, > and be clear > > > about what action (or inaction) you specifically have issue > > > with and want reconsidered. Suggesting what remedy you > > > believe is appropriate would also be useful. > > > > Well I did specifically discuss a disagreement with the > > action of the chairs in calling the ambiguous question, but I > > will accept this deferral and redirect the current appeal > > comment to the chairs. > > > > Tony > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > [4] Note from chairs to Tony Hain requesting clarification > > > > Message-Id: <5.1.0.14.2.20030411094553.040e3040@mail.windriver.com> > > Date: Fri, 11 Apr 2003 10:16:09 -0400 > > To: Tony Hain > > From: Margaret Wasserman > > Subject: Your Appeal Regarding Site-Local Deprecation (Was: > Consensus > > on Site-Local Addressing) > > Cc: Bob Hinden , Thomas Narten > > , > > Erik Nordmark , ipng@sunroof.eng.sun.com > > > > > > Hi Tony, > > > > Based on your messages below, we understand that you are > > attempting to start an appeal regarding the IPv6 WG's > > decision to deprecate IPv6 site-local unicast addressing. > > However, it is not entirely clear to us what action (or > > inaction) you are appealing and on what grounds. We > > understand that you disagree with the WGs decision to > > deprecate IPv6 site-local unicast addressing without first > > defining an alternative local addressing mechanism, but that > > is not, in itself, grounds for an appeal. > > > > In order for us to consider this appeal, you should follow > > the appeals process outlined in section 6.5.4 of RFC 2026. > > Your appeal should include a "detailed and specific > > description of the facts of the dispute". In particular, you > > should make it clear exactly what action (or inaction) you > > are appealing. > > > > You must also indicate what grounds you have for appealing > > that action (or inaction). There are two possible grounds > > for appeal of a WG action, listed in RFC 2026, section 6.5.1: > > > > (a) [your] own views have not been adequately considered > > by the Working Group, or > > (b) the Working Group has made an incorrect technical choice > > which places the quality and/or integrity of the Working > > Group's product(s) in significant jeopardy. > > > > It might also be possible to raise a process appeal if you > > believe that the chairs violated the process for session > > management described in section 3.3 of RFC 2418. > > > > Please explicitly state what you are appealing and explain > > your grounds for appeal. You should also supply any > > information necessary to explain and support your position. > > Once we have this information, we will carefully consider > > your appeal and provide a written reply. > > > > We understand that your appeal is motivated by your desire to > > do the right thing for IPv6, and we will make every attempt > > to deal with it fairly and promptly. > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG Chairs > > > > > > >Reply-To: > > >From: "Tony Hain" > > >To: "'Bob Hinden'" , > > > "'Margaret Wasserman'" > > >Cc: > > >Subject: FW: Consensus on Site-Local Addressing > > >Date: Thu, 10 Apr 2003 10:31:47 -0700 > > >X-Mailer: Microsoft Outlook, Build 10.0.4510 > > >Importance: Normal > > >X-MIME-Autoconverted: from quoted-printable to 8bit by > > >sunroof.eng.sun.com > > >id h3AHY8mh023731 > > >Sender: owner-ipng@sunroof.eng.sun.com > > > > > >Bob & Margaret, > > > > > >As I noted to Thomas a few moments ago, I have already > > raised concerns > > >about the initial action of calling the ambiguous question. > > I believe > > >his response indicates I also need to raise a concern with > you about > > >this specific action of declaring consensus. As the content > > of the note > > >below indicates, there can be no consensus because the > > question was not > > >clear. At best, this activity shows a desire to change the > > status quo, > > >but it does not and can not indicate anything else. The consensus > > >declaration must be voided. > > > > > >As I note below, steps 4) & 5) indicate work that the group > > believes we > > >should take on. *If* the result of that work leaves us with > > no further > > >use for the current definition for an ambiguous address > > space, then in > > >that context I believe steps 1) & 3) are appropriate. Until > > then they > > >are not, and are very likely to create chaos, particularly if done > > >before 4) delivers complete alternatives. > > > > > >You must void the declaration of consensus, and should > > recognize that > > >the original question was not clear. > > > > > >Tony > > > > > > > > > > -----Original Message----- > > > > From: owner-ipng@sunroof.eng.sun.com > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > > > > Sent: Wednesday, April 09, 2003 5:42 PM > > > > To: 'Thomas Narten'; 'Erik Nordmark' > > > > Cc: ipng@sunroof.eng.sun.com > > > > Subject: FW: Consensus on Site-Local Addressing > > > > > > > > > > > > Thomas & Erik, > > > > > > > > Please consider this the second step in the appeal process, as I > > > > have already discussed these issues with the chairs on > > more than one > > > > occasion. > > > > > > > > 'we reject kings, presidents and voting...' > > > > The consensus measurement on the mail list was much more > > indicative > > > > of the real lack of it (60/40%), than what was > effectively ballot > > > > stuffing by WG visitors without a complete context. There > > was a very > > > > short presentation in the apps open area, intended to > > raise concerns > > > > and incite involvement, were those in the apps area were > > agitated, > > > > then invited to the IPv6 WG session in SF to discuss the > > potential > > > > issues. The subsequent short discussion in the IPv6 WG > > showed there > > > > were issues to work through, and at least one question voiced > > > > about understanding the requirements. Rather than deal with the > > > > issues raised, the chairs decided to call an ambiguous > question of > > > > yes/no for deprecation. > > > > > > > > While the chairs do in 2) recognize their interpretation of the > > > > consensus that the WG will investigate other forms of local > > > > addressing, there is no mention of ambiguity and the > rest of the > > > > wording of 1) & 2) can be interpreted as local scope > > addressing is > > > > deprecated. The concern is that we will end up with a document > > > > lacking local scope addressing, and claims that we had > > consensus to > > > > remove local scope from the architecture. Many of those > > who bothered > > > > to state why they were expressing a yes opinion claimed > ambiguity > > > > was the reason, while others were only interested in removing > > > > special handling for local scope addresses. Those are > technically > > > > different issues, so they need different questions. What we > > > > have is an indication that many are unhappy with the status > > > > quo, but a lack of recognition that the call ended up > > > > combining yes opinions for removing ambiguity with yes > > > > opinions for removing local scope addresses from the > > > > architecture. From subsequent discussions with the chairs, it > > > > is clear that was not their intent, but never the less that > > > > is the result of the lack of clarity in this consensus call. > > > > > > > > '... we believe in rough consensus & running code' & from > > the Tao : > > > > 'running code wins' On several related mail threads there > > were many > > > > comments about running code, and at least Brian Zill & Brian > > > > Haberman said they collectively had host, application, > and router > > > > implementations of the current SL running. Point 3) even > > > > acknowledges there are existing implementations. This > > consensus call > > > > intends to invalidate the running code, and all we have > > to replace > > > > it is a promise in 4) that if the group can ever agree that > > > > operational requirements of the site network manager are worth > > > > solving, we might start to work on solutions, subject to > > appropriate > > > > charter updates. This whole discussion is based on the argument > > > > that some developers couldn't create running code for > an arguably > > > > bogus scenario where topology locators are blindly > passed outside > > > > their scope of relevance. Bias was given to the > opinions of those > > > > with a lack of running code, at the expense of, and with the > > > > specific intent of invalidating the code that exists. > > > > > > > > There were also claims in the meeting and mail threads > > that we have > > > > analyzed site local as currently defined, and it > doesn't meet the > > > > requirements. At the same time, there is a recognition > by many of > > > > the same people that we need to develop a complete set of > > > > requirements. It should be obvious that the analysis is > flawed if > > > > the complete set of requirements are not understood > > first. To that > > > > end, and in the spirit of making progress, > > > > draft-hain-ipv6-sitelocal-00.txt was processed by the > I-D editor > > > > on 4/8, and is offered as an attempt to document the > requirements > > > > for address space with a local scope of relevance. It > is clearly > > > > incomplete, and largely based on my previous email on > the subject. > > > > > > > > While I contest the claim that the Yes/No opinions expressed > > > > measured consensus for a consistent interpretation of what > > > > 'deprecate site local addresses' means, I do believe that > > a set of > > > > work items for the group were identified. It is also > > clear that we > > > > can add new work to a group at any time, without the need > > to remove > > > > existing items first. I agree with the chairs that items > > 4) & 5) are > > > > valid outcomes of the subsequent discussion, though one > > thing that > > > > their interpretation of the result does not make clear is the > > > > meaning of 'accomplish the following things in parallel:'. In > > > > talking to the chairs it appears the intent is to start > the work > > > > at the same time, but we need to avoid invalid > transition states, > > > > so parallel needs to mean that all 5 are to be forwarded to the > > > > IESG at one time. In particular, without solutions to the > > > > requirements in hand, any documents for 1) & 3) that intend to > > > > deprecate the only local use address space will simply create > > > > chaos, and might need to be rescinded if the complete set of > > > > requirements shows a need with no other technical approach. > > > > > > > > In short, I do not believe the consensus call measured > > the opinions > > > > that were consistent the chairs interpretation of the > > question, so > > > > the claimed results are invalid. I do believe that the effort > > > > identified work items 4) & 5), with the potential that 1) > > & 3) might > > > > follow if there are no outstanding requirements for ambiguous > > > > address space. I question the wisdom of 2), but will reserve > > > > judgment until the complete text identifying further work > > is spelled > > > > out. In any case, I hope this appeal can be dealt with at this > > > > level, and that the overall effort results in an > expedited charter > > > > update. It is imperative that new approaches exist prior to > > > > removal of the current, and there is a very real danger that > > > > the current destructive energy will dissipate in the face of > > > > the hard work of creating replacements. > > > > > > > > Tony > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > [5] Note from Tony Hain clarifying his appeal. > > > > From: "Tony Hain" > > To: "'Margaret Wasserman'" , "'Tony Hain'" > > > > Cc: "'Bob Hinden'" , > > "'Thomas Narten'" , > > "'Erik Nordmark'" , > > > > Subject: RE: Your Appeal Regarding Site-Local Deprecation > > (Was: Consensus on Site-Local Addressing) > > Date: Fri, 11 Apr 2003 10:07:44 -0700 > > Message-Id: <106f01c3004c$deceb8b0$ee1a4104@eagleswings> > > > > Margaret Wasserman wrote: > > > Hi Tony, > > > > > > Based on your messages below, we understand that you are > attempting > > > to start an appeal regarding the IPv6 WG's decision to deprecate > > > IPv6 site-local unicast addressing. > > > However, it is not entirely clear to us what action (or > > > inaction) you are appealing and on what grounds. > > > > What is not clear about? > > >> As the content of the note below indicates, there can > > >> be no consensus because the question was not clear. > > > > >>> Many of those who bothered to state why they were > expressing a yes > > >>> opinion claimed ambiguity was the reason, while others > were only > > >>> interested in removing special handling for local scope > addresses. > > >>> Those are technically different issues, so they need different > > >>> questions. > > > > >>> In short, I do not believe the consensus call measured the > > >>> opinions that were consistent the chairs interpretation of the > > >>> question, so the claimed results are invalid. > > > > > > > We > > > understand that you disagree with the WGs decision to > > > deprecate IPv6 site-local unicast addressing without first > > > defining an alternative local addressing mechanism, but that > > > is not, in itself, grounds for an appeal. > > > > I can't disagree because the WG did not reach a decision, > the chairs > > declared one. There were different interpretations of what > people were > > voting YES for, therefore there was no decision. The chairs > combined > > YES get rid of scoping, with YES get rid of ambiguity responses > > to arrive at > > a count. That does not constitute a WG decision. > > > > > > > > In order for us to consider this appeal, you should follow > > > the appeals process outlined in section 6.5.4 of RFC 2026. > > > Your appeal should include a "detailed and specific > > > description of the facts of the dispute". In particular, you > > > should make it clear exactly what action (or inaction) you > > > are appealing. > > > > >> You must void the declaration of consensus, and should > > >> recognize that the original question was not clear. > > > > The question asked was: > > Should we deprecate IPv6 site-local unicast addressing? > > > > The answers indicated that some interpreted that as deprecation of > > address scoping, while others interpreted it as remove the > ambiguity > > associated with the current definition of the FEC0::/10 > prefix. Those > > are technically different issues and require separate > questions, yet > > the chairs combined the disparate YES votes for each perspective > > into their > > own interpretation of what the original question meant. > This is not WG > > consensus. > > > > > > > > You must also indicate what grounds you have for appealing > > > that action (or inaction). There are two possible grounds > > > for appeal of a WG action, listed in RFC 2026, section 6.5.1: > > > > > > (a) [your] own views have not been adequately considered > > > by the Working Group, or > > > (b) the Working Group has made an incorrect > technical choice > > > which places the quality and/or integrity of > the Working > > > Group's product(s) in significant jeopardy. > > > > The working group was mislead by an ambiguous question from > > the chairs, > > and has not reached a consensus on anything other than more > work needs > > to be done. Some of the YES votes were for removal of > scopes from the > > architecture, and others were for removing ambiguous > > addresses as SL is > > currently defined. Those are technically different concepts > requiring > > different questions. The declaration of consensus by the chairs > > indicates an incorrect technical choice which places the > integrity of > > the WG product in significant jeopardy. > > > > > > > > > > It might also be possible to raise a process appeal if you > > > believe that the chairs violated the process for session > > > management described in section 3.3 of RFC 2418. > > > > Well since you brought it up, the agenda listed Limited Usage, and > > Moderate Usage as the topics of discussion. Then (someone that was > > there should verify this, but I have been told that) your > > presentation listed: > > Full > > Moderate > > Exclusive > > Limited > > No SLs > > and you started the presentation by saying that the first > one and the > > last one were not under consideration. Later you call an ambiguous > > question attempting to accomplish the last one. Is that > proper session > > management? If people are led to believe a topic will not be > > discussed, > > they are less likely to come prepared to discuss it, or stick > > around to > > make sure their views are heard during a discussion. I can only > > question, maybe others that were there will appeal based on > > mismanagement. > > > > > > > > Please explicitly state what you are appealing and explain > > > your grounds for appeal. You should also supply any > > > information necessary to explain and support your position. > > > Once we have this information, we will carefully consider > > > your appeal and provide a written reply. > > > > I believe I did this in the original note to Thomas & Erik, > which was > > included in the subsequent note of appeal to the chairs. I am > > appealing the declaration of consensus based on an > ambiguous question, > > where some > > responses indicate remove addresses with local scope while others > > indicate remove ambiguity of the address range. > > > > > > > > We understand that your appeal is motivated by your desire to > > > do the right thing for IPv6, and we will make every attempt > > > to deal with it fairly and promptly. > > > > >From my reading, this response does not indicate a desire for > > promptness. > > > > Tony > > > > > > > > Bob Hinden & Margaret Wasserman > > > IPv6 WG Chairs > > > > > > > > > >Reply-To: > > > >From: "Tony Hain" > > > >To: "'Bob Hinden'" , > > > > "'Margaret Wasserman'" > > > >Cc: > > > >Subject: FW: Consensus on Site-Local Addressing > > > >Date: Thu, 10 Apr 2003 10:31:47 -0700 > > > >X-Mailer: Microsoft Outlook, Build 10.0.4510 > > > >Importance: Normal > > > >X-MIME-Autoconverted: from quoted-printable to 8bit by > > > >sunroof.eng.sun.com > > > >id h3AHY8mh023731 > > > >Sender: owner-ipng@sunroof.eng.sun.com > > > > > > > >Bob & Margaret, > > > > > > > >As I noted to Thomas a few moments ago, I have already > > > raised concerns > > > >about the initial action of calling the ambiguous question. > > > I believe > > > >his response indicates I also need to raise a concern with > > you about > > > >this specific action of declaring consensus. As the content > > > of the note > > > >below indicates, there can be no consensus because the > > > question was not > > > >clear. At best, this activity shows a desire to change the > > > status quo, > > > >but it does not and can not indicate anything else. The consensus > > > >declaration must be voided. > > > > > > > >As I note below, steps 4) & 5) indicate work that the group > > > believes we > > > >should take on. *If* the result of that work leaves us with > > > no further > > > >use for the current definition for an ambiguous address > > > space, then in > > > >that context I believe steps 1) & 3) are appropriate. Until > > > then they > > > >are not, and are very likely to create chaos, > particularly if done > > > >before 4) delivers complete alternatives. > > > > > > > >You must void the declaration of consensus, and should > > > recognize that > > > >the original question was not clear. > > > > > > > >Tony > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > > > > > Sent: Wednesday, April 09, 2003 5:42 PM > > > > > To: 'Thomas Narten'; 'Erik Nordmark' > > > > > Cc: ipng@sunroof.eng.sun.com > > > > > Subject: FW: Consensus on Site-Local Addressing > > > > > > > > > > > > > > > Thomas & Erik, > > > > > > > > > > Please consider this the second step in the appeal > > process, as I > > > > > have already discussed these issues with the chairs on > > > more than one > > > > > occasion. > > > > > > > > > > 'we reject kings, presidents and voting...' > > > > > The consensus measurement on the mail list was much more > > > indicative > > > > > of the real lack of it (60/40%), than what was > > effectively ballot > > > > > stuffing by WG visitors without a complete context. There > > > was a very > > > > > short presentation in the apps open area, intended to > > > raise concerns > > > > > and incite involvement, were those in the apps area were > > > agitated, > > > > > then invited to the IPv6 WG session in SF to discuss the > > > potential > > > > > issues. The subsequent short discussion in the IPv6 WG > > > showed there > > > > > were issues to work through, and at least one question voiced > > > > > about understanding the requirements. Rather than > deal with the > > > > > issues raised, the chairs decided to call an > ambiguous question > > > > > of yes/no for deprecation. > > > > > > > > > > While the chairs do in 2) recognize their > interpretation of the > > > > > consensus that the WG will investigate other forms of local > > > > > addressing, there is no mention of ambiguity and the > > rest of the > > > > > wording of 1) & 2) can be interpreted as local scope > > > addressing is > > > > > deprecated. The concern is that we will end up with a document > > > > > lacking local scope addressing, and claims that we had > > > consensus to > > > > > remove local scope from the architecture. Many of those > > > who bothered > > > > > to state why they were expressing a yes opinion claimed > > ambiguity > > > > > was the reason, while others were only interested in removing > > > > > special handling for local scope addresses. Those are > > technically > > > > > different issues, so they need different questions. > What we have > > > > > is an indication that many are unhappy with the > status quo, but > > > > > a lack of recognition that the call ended up combining yes > > > > > opinions for removing ambiguity with yes opinions for > removing > > > > > local scope addresses from the architecture. From subsequent > > > > > discussions with the chairs, it is clear that was not their > > > > > intent, but never the less that is the result of the lack of > > > > > clarity in this consensus call. > > > > > > > > > > '... we believe in rough consensus & running code' & from > > > the Tao : > > > > > 'running code wins' On several related mail threads there > > > were many > > > > > comments about running code, and at least Brian Zill & Brian > > > > > Haberman said they collectively had host, application, > > and router > > > > > implementations of the current SL running. Point 3) even > > > > > acknowledges there are existing implementations. This > > > consensus call > > > > > intends to invalidate the running code, and all we have > > > to replace > > > > > it is a promise in 4) that if the group can ever agree that > > > > > operational requirements of the site network manager > are worth > > > > > solving, we might start to work on solutions, subject to > > > appropriate > > > > > charter updates. This whole discussion is based on > the argument > > > > > that some developers couldn't create running code for an > > > > > arguably bogus scenario where topology locators are blindly > > > > > passed outside their scope of relevance. Bias was > given to the > > > > > opinions of those with a lack of running code, at the expense > > > > > of, and with the specific intent of invalidating the > code that > > > > > exists. > > > > > > > > > > There were also claims in the meeting and mail threads > > > that we have > > > > > analyzed site local as currently defined, and it > > doesn't meet the > > > > > requirements. At the same time, there is a recognition > > by many of > > > > > the same people that we need to develop a complete set of > > > > > requirements. It should be obvious that the analysis is > > flawed if > > > > > the complete set of requirements are not understood > > > first. To that > > > > > end, and in the spirit of making progress, > > > > > draft-hain-ipv6-sitelocal-00.txt was processed by the > I-D editor > > > > > on 4/8, and is offered as an attempt to document the > > > > > requirements for address space with a local scope of > relevance. > > > > > It is clearly incomplete, and largely based on my > previous email > > > > > on the subject. > > > > > > > > > > While I contest the claim that the Yes/No opinions expressed > > > > > measured consensus for a consistent interpretation of what > > > > > 'deprecate site local addresses' means, I do believe that > > > a set of > > > > > work items for the group were identified. It is also > > > clear that we > > > > > can add new work to a group at any time, without the need > > > to remove > > > > > existing items first. I agree with the chairs that items > > > 4) & 5) are > > > > > valid outcomes of the subsequent discussion, though one > > > thing that > > > > > their interpretation of the result does not make clear is the > > > > > meaning of 'accomplish the following things in parallel:'. In > > > > > talking to the chairs it appears the intent is to > start the work > > > > > at the same time, but we need to avoid invalid transition > > > > > states, so parallel needs to mean that all 5 are to > be forwarded > > > > > to the IESG at one time. In particular, without > solutions to the > > > > > requirements in hand, any documents for 1) & 3) that > intend to > > > > > deprecate the only local use address space will simply create > > > > > chaos, and might need to be rescinded if the complete set of > > > > > requirements shows a need with no other technical approach. > > > > > > > > > > In short, I do not believe the consensus call measured > > > the opinions > > > > > that were consistent the chairs interpretation of the > > > question, so > > > > > the claimed results are invalid. I do believe that the effort > > > > > identified work items 4) & 5), with the potential that 1) > > > & 3) might > > > > > follow if there are no outstanding requirements for ambiguous > > > > > address space. I question the wisdom of 2), but will reserve > > > > > judgment until the complete text identifying further work > > > is spelled > > > > > out. In any case, I hope this appeal can be dealt with at this > > > > > level, and that the overall effort results in an > > expedited charter > > > > > update. It is imperative that new approaches exist prior to > > > > > removal of the current, and there is a very real > danger that the > > > > > current destructive energy will dissipate in the face of the > > > > > hard work of creating replacements. > > > > > > > > > > Tony > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > [6] More followup/clarification from Tony Hain > > > > From: "Tony Hain" > > To: "'Bob Hinden'" , > > "'Margaret Wasserman'" > > Cc: > > Subject: Appeal clarification ... > > Date: Thu, 24 Apr 2003 22:45:30 -0700 > > Message-Id: <047f01c30aed$e1f8ed20$261e4104@eagleswings> > > > > Everyone should check out the video at: > > ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 > > - 03202003 > > - INT ipv6.mpg ... Starting at 1:02:05. It is very > > instructional about > > how not to call a question. The claimed consensus was over > > (and I quote > > from the AD & chair 2:18:20) 'just to be clear, deprecate I > > assume means > > ...' ... '...we may have to handwave - wave our hands around that a > > little bit...'. > > > > In further discussion with the chairs, the appeal issue is > still not > > clear. This note attempts to make it clearer, and adds > documentation > > from the video of the SF session. > > > > Appeal: > > The chairs have asserted an incorrect technical choice which > > places the > > quality and/or integrity of the Working Group's products in > > significant > > jeopardy. > > > > The working group did not make a decision as some of the YES > > votes were > > for removal of local scopes from the architecture, some for > removal of > > the need for apps to recognize that local scopes exist, > > others were for > > removing ambiguous addresses as SL is currently defined, and > > others were > > for removing the threat of NAT. Those are technically different > > architectural concepts requiring different questions. In particular, > > local scope addresses are the result of an operational > choice, and not > > in the purview of the IETF to decide. The IETF can decide to > > set aside a > > well known prefix for that use or not, but removing the well-known > > prefix does not mean local scope addresses go away, or that > > applications > > are exempted from handling them correctly. It only means > that there is > > no consistent way to identify which addresses are local use. > > > > There is no document identifying the requirements and needs of the > > network operators, therefore no reasonable and complete evaluation > > could result in the conclusion that deprecation is an appropriate > > action. The > > chairs chose to ask an ambiguous question that the group clearly had > > different opinions about the meaning of, and shortly before > > the initial > > question was called there was an explicit statement about lack of > > clarity in the consequences of the alternatives. Forcing a YES/NO > > question for an end state rather than a process, without a > widespread > > understanding of the consequences and trade-offs, was an > inappropriate > > action by the chairs. > > > > The working group was mislead by an ambiguous question from > > the chairs. > > The asserted conclusion is invalid as the WG has not > reached consensus > > on anything other than more work needs to be done. > > > > > > Background: > > The entire open discussion in SF started off misled by a > > bogus technical > > assertion by the chair: > > 1:42:04 ... it is always going to be possible to implement > > wrong unless > > we get rid of whole concept of private addresses ... you will always > > have the possibility ... for leaking addresses if they exist in the > > architecture > > >>> Existence in the address architecture is not what creates > > the possibility for limited scope addresses to be leaked, that only > > allows identification of them. The thing the creates the > > possibility for > > leaking limited scope addresses outside their realm of > > applicability is > > the ignorance by the applications that the real network has limited > > scope addresses and they require appropriate handling. > > Removing any tag > > for the application to identify which addresses have limited > > scope only > > ensures that they will be leaked. > > > > > > There was no enumeration of the requirements for any > > solution, therefore > > no reasonable and complete evaluation that the current SL is > > inadequate. > > > > 1:06:49 MW - you can only document the cost/benefit analysis > > of a point > > that's understood > > > > 1:36:30 - 'Do we have enough information to decide' > > >>> on slide but not discussed > > >>> discussion about overriding need to reach consensus > > > > 1:39:00 - Pekka - Exclusive is just broken ... if we want ... > > >>> indicates need to understand requirements > > > > without further analysis, that requirement is met by > access prefix > > thing > > access prefix is less intrusive and easier to implement > > >>> where is the analysis that backs that up? > > > > 1:41:42 - Alain - ... if we want to avoid leaking ... > > >>> indicates need to understand requirements > > > > 1:50:05 - Erik - we don't have enough information to decide > yet, and > > part of what I am looking for is so what are the benefits of these > > things anyhow > > >>> indicates need to understand requirements > > > > 1:52:33 - look at benefits before we try to decide something > > - MW 'anything we are doing here should be a > cost/benefit tradeoff > > ... maybe we'll decide we need more information ... we need to > > do an intelligent cost/benefit analysis and have a > supportable reason > > for our choice > > > > 1:58:00 Leif - Erik's comments were first time I heard purported > > benefits - applications shouldn't have to worry about > topology that's > > a fundamental comparing the benefits with breaking fundamental > > assumption > > that apps shouldn't care about topology - its clear that you should > > eliminate SL > > >>> an informed conclusion after 5 1/2 minutes evaluation of a > > partial verbal list of requirements ??? How many others were > > in the same > > place? > > > > 2:11:39 Dave - I agree with Keith's attempt to clarify the > wording of > > the question people are arguing for the eliminate proposal > which there > > isn't any draft about ... > > > > > > In fact over the meeting it was clear that there was no common > > understanding about what 'deprecate' means even by the chairs, and > > this carried onto the list discussion: > > > > 2:09:24 MW - that would be eliminating it, you can always bring > > something back later someone can have a research group, but > if take it > > out of the specs, ** that is what eliminating it means ** 2:09:35 > > Keith - alternate proposal for a way forward - I don't > believe the bit > > patterns that are defined for SL will be allocated for some > other use > > so I don't think we are eliminating them entirely, but I want > > to know if we can get a sense of the group that > discouraging use of SL > > is the appropriate way to move forward - part 1 part 2 - > > identify the > > things that SL was supposed to solve and work out alternate > solutions > > for those > > 2:10:20 MW - instead of eliminate I think the right word would be > > deprecate because I agree that we are not going to suddenly > decide to > > use those bits for something else - I agree with you on that but > > discouraging ** is that deprecating? ** > > 2:10:35 Keith - deprecating in a sense, it also leaves the idea that > > until we find something else, you might have some usage of > SL but the > > plan is in the future to deprecate it > > > > 2:11:39 Dave - I agree with Keith's attempt to clarify the > wording of > > the question people are arguing for the eliminate proposal > which there > > isn't any draft about - this is a question to you to clarify the > > question - Erik made and Dino added - zero conf asked what > do routers > > do > > - do we want to enable a zero config thing - if so do you > > want to enable > > SL in a deprecated sense as Keith put it, for that or is the > > proposal to > > eliminate them and force zero config guys to not work > because we don't > > care about that, or to force them to use some other well > known prefix > > clarify which one of those is actually the proposal ? > > >>> questions never answered or even discussed > > > > 2:12:51 Christian - if we say that we are going to eliminate > > SL we have > > to actually eliminate it and ** that means ** that we have > to make it > > explicit that at some point in the future all implementations are > > supposed to discard any packets sent to the specific prefix > > > > 2:13:19 MW - I'll resay what I said earlier which is I had > > said we would > > say eliminate it or keep it and then we'd have multiple > choices if we > > kept it but apparently ** if we eliminate it we will also > > have multiple > > choices about what exactly that means ** > > >>> 'multiple choices' how does that indicate a clear meaning > > ??? > > > > 2:13:31 Erik - I think there area some details about what it > > means if we > > actually choose to eliminate ** I think that means ** that people at > > their leisure can go ahead and delete whatever code they have that > > currently recognizes FEC0 but they don't have to do it > > tomorrow, because > > we are not going to allocate this for any other purpose in the near > > future, but it means that you don't have to add any more > code, but you > > can at your leisure delete what you have > > > > 2:14:05 Brian - I got up to say that the question that you > > were going to > > ask is one that ** I would have difficulty answering because > > I wouldn't > > vote for keeping SL unless I knew which of the options we > > were going to > > go for ** > > >>> though voting against without understanding the consequences > > didn't appear to be a problem > > > > 2:16:09 Bound - IPv4 NAT is a national security problem, at > > least in the > > US so ** what I am hearing to day is we should stop it and > > not give any > > credence to help proliferate them ** > > >>> a belief that removing SL removes the threat of NAT ??? > > > > 2:16:45 Keith - ... ** the real trick is ** that applications > > shouldn't > > have to special case these things, Dns shouldn't have to > special case > > them, routing shouldn't; have to special case these things > > >>> in other words applications continue to ignore the reality > > of limited scope addresses, because without a well-known tag it is > > impossible to special case them > > > > 2:18:20 Thomas, just to be clear, ** deprecate I assume means ** > > somewhere to the left of the limited use model > > - MW Yes, somewhere to the left of limited, the bits > would somehow > > become deprecated but probably you wouldn't get to reuse > them and we > > would not want to invalidate existing implementations so we > may have > > to wave our hands around that a little bit to make sure we > do it right > > - Bob, Christian just added - and probably needed to be blackholed > > >>> 'somewhere to the left'; 'somehow be deprecated'; & '...may > > have to hand wave...' those are not clear indications of the > > meaning of > > the question or consequences of this action. > > > > 4/2 JB - Ambiguous addresses are a nightmare... > > >>> a common theme > > > > 4/5 MW - The proposal is to deprecate a prefix in the addressing > > architecture for which we have found no suitable use. > > >>> Translation - we refuse to acknowledge the uses in > shipping code, > > though we do acknowledge that there is shipping code which > uses them. > > > > 4/5 DL - I thought we were voting on something more > meaningful, i.e., > > site-locals themselves. Now I understand that site-locals do not > > exist as such and we were just voting on the deprecation of the > > prefix itself. > > > > 4/7 AW - I have come to the conclusion that the consensus > > call email on > > the list failed to adequately describe what a YES for deprecation > > actually entailed, and has pretty effectively shot itself > in the foot. > > > > 4/4 HA - Note: By "Deprecate Site-Local", ** I mean ** "Do > not require > > any application, host, router, protocol or IETF practice to have to > > make special > > consideration for the idea that an IPv6 unicast address > > outside of the > > link-local range can refer to two different hosts". > > > > 4/4 PF - So, when I say I want Site Local deprecated ** I > > mean ** I want > > routing and addressing separated, and given that separation, > > we have to > > work on > > solving the real problems we have with Internet today > > > > > > While there was no single clear statement about what > deprecate means > > (though many architecturally different assertions), there > was a clear > > overriding concern by the chairs that some conclusion be > reached, even > > a bad one: > > 2:07:43 Erik - call for comments for SL Bob - give us a > > second here > > MW - if we are going reach any conclusion we can't accept a sudden > > influx at mic > > 2:08:45 Bob - if you want to support SL independent of usage > > model come > > to the mic 2:15:22 Bob by the way... MW cut off> we have to cut off > > discussion with the people who are at the mic because we have > > to try to > > have some conclusion > > >>> where was the fire? If the question had not been called in > > SF, would the world have ended? Allowing 7 1/2 minutes for rebuttal > > comments to a discussion that was not on the agenda, there were no > > documents published, and people did not come to the meeting > > prepared to > > discuss is inappropriate in any case. Cutting off discussion just as > > people were getting their thoughts together to form reasonable > > statements about requirements is improper meeting management > > and biases > > any attempt to measure consensus. > > > > > > > > Despite the lack of agreement about exactly what deprecate > > means, there > > was a comment: > > 2:17:19 MW - lets see, just a sec ... we are going to call > a question > > and the question is going to be a yes no question do we want to > > deprecate SL addresses or do we not want to deprecate SL > > addresses - we > > realize that both of those answers no matter which answer you > > give there > > is more details that need to be worked out, but we are trying to get > > what is the direction, does the group want to go away from SL > > addressing, deprecate it work out how to get it out, does the > > group want > > to keep it and figure out what the right usage model is for > > it OK, this > > is a usage model issue. its is like do we want to support > usage of SL > > and come up with a usage model for it, or do we want to deprecate it > > > > which was not made to the mail list consensus call. > > > > >>> There is a vast difference between identifying > direction of the > > group and the actual yes/no to deprecate SL question that was asked. > > In fact all other indications from the chairs were that the > > question was > > NOT about measuring direction of the WG, but actually about > > their intent > > to have local scoped addresses removed from the scoped address > > architecture and other documents. > > > > >>> This drive for a decision despite multiple > statements (by the > > chairs no less), that a cost/benefit analysis can only be done with > > a complete set of requirements. Where is the supportable > > reason for the > > asserted choice to change the architecture? For that > matter, where is > > the requirements document that a supportable reason would be > > built from? > > > > > > > > In preparing the question, it should have been clear that > the chairs > > were not thinking this though clearly: 2:18:57 Perry when > you say it > > is a yes or no question, therefore it must > > be phrased differently than do we wish to deprecate them or > do we not > > wish to deprecate them > > - MW I am tired, did I actually say that? > > > > Yet seconds later: > > 2:19:20 MW Question - show of hands, how many people think that we > > should deprecate SL addressing? > > > > > > > > > > Keith's wording at 2:09:35 would have been an appropriate pair of > > questions for the chairs to ask (I acutally support part > 2), but the > > chairs chose to ask an ambiguous question that the group > (and even the > > chairs) clearly had different and inconsistent opinions about the > > meaning of. Shortly before the question was called there was an > > explicit statement about lack of clarity about the > consequences of the > > alternatives. The fact that many of the YES responses were > > about removal > > of local scope addresses invalidates the asserted conclusion. The > > existence of limited scope addresses are an architectural > > consequence of > > operational choices, and not in the purview of the IETF to decide. > > > > Tony > > > > > > PS: 2:14:05 Brian ... I also a comment that RFC 1597 is one > > of the worst > > end runs in the history of the IETF. > > >>> I am arguing that through an ambiguous question this > > desperate drive for a conclusion which intends to remove local scope > > addresses from the architecture superseded it. > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > [7] Chairs formal response to Tony Hain's appeal > > > > Message-Id: <5.1.0.14.2.20030428165715.046a3888@mail.windriver.com> > > Date: Mon, 28 Apr 2003 17:02:02 -0400 > > To: Tony Hain > > From: Margaret Wasserman > > Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: > > Consensus on Site-Local Addressing) > > Cc: ipng@sunroof.eng.sun.com, Thomas Narten , > > Erik Nordmark , Bob Hinden > > > > > > Hi Tony, > > > > We have considered your appeal regarding the IPv6 WG consensus to > > deprecate site-locals. Based on our analysis, we believe that your > > appeal makes the following points: > > > > (1) You believe that deprecating IPv6 site-local unicast > > addressing is an incorrect technical choice that places > > the work output of the IPv6 WG in jeopardy. > > > > (2) You believe that the question asked by the chairs > > was insufficiently clear to be understood properly > > by the WG. > > > > (3) You do not believe that there is rough consensus to > > deprecate IPv6 site-local addressing, because people > > provided different reasons for why they believe that > > IPv6 site-local addressing should be deprecated. In > > particular, some people want to deprecate the particular > > model of site-local addressing defined in the scoped > > addressing architecture (ambiguous, scoped addresses), > > while others do not believe that we need a local > > addressing mechanism at all. > > > > (4) You believe that it is invalid for the IPv6 WG to > > deprecate site-local addressing without publishing an > > IPv6 WG document that analyzes the operational requirements > > for local addressing. Without this analysis document, you > > believe that the IPv6 WG has made an uninformed choice. > > > > We will now respond to each of your points. > > > > -- > > > > Point (1): > > > > The chairs do not believe that deprecating IPv6 site-local > addressing > > is an incorrect technical decision that will place the work > output of > > the IPv6 WG in jeopardy. > > > > The consensus was to "deprecate" the usage of site-local addressing > > instead of simply removing it. This was done purposely to avoid > > interference with any current implementations or deployments that > > might use site-local addressing. In addition to the time > it will take > > to formally deprecate site-local addressing by publishing > an RFC, the > > WG understands that it will take some time after the publication > > of an RFC > > for implementations to change. The decision to deprecate site-local > > addressing, rather than simply removing it, was made to avoid harm > > to IPv6. > > > > In fact, we believe that the previous disagreement over the > usage of > > IPv6 site-local addressing was damaging to the WG, and that > our lack > > of consensus was delaying our work, particularly on the IPv6 scoped > > addressing architecture. The consensus to deprecate site-local > > addressing will allow us to move forward and complete our work. > > > > --- > > Point (2): > > > > The question was: > > > > "Should we deprecate IPv6 site-local unicast > > addressing?" Possible answers were YES or NO. > > > > The chairs believe that this question was sufficiently clear to be > > understood by the WG. This is supported by the following > > points: > > > > - Over 200 people responded to the question. > > > > - Many of the responses on the list (both YES and NO > > responses) included reasons or comments that > > followed from the question in a way that indicated > > that the responders understood the question. > > > > - There were only three requests for clarification of > > this consensus call on the mailing list, two of which > > were procedural. All of these requests were answered > > promptly by the chairs. > > > > - The chairs sent the consensus results to the list > > over two weeks ago, including a course of action for > > the deprecation of site-local addressing. There > > have been no objections from people who originally > > expressed YES opinions that the chairs' course of > > action fails to match their expectations. > > > > --- > > > > Point (3): > > > > The chairs do not believe that consensus on an issue is > invalidated by > > the fact that people have multiple reasons for coming to the same > > conclusion. We suspect that this happens in most WG > consensus calls, > > and this is not a reason to invalidate the consensus. > > > > All of the groups that you mentioned in your message agreed > that IPv6 > > site-local unicast addressing should be deprecated. They > may disagree > > on what we should do after deprecating site- local addressing, but > > that does not invalidate the consensus on this point. > > > > --- > > > > Point (4): > > > > It is true that the IPv6 WG has not produced a WG document that > > analyzes the operational requirements for local addressing. > However, > > we do not believe that this is a reason to invalidate the IPv6 WG > > consensus to deprecate IPv6 site-local unicast addressing. > > > > There has been considerable discussion and analysis of site- local > > addressing performed over the past year, including extensive > > discussions during three IETF sessions. There have also > been several > > drafts published on the subject, including one draft that > attempts to > > analyze the cost/benefit trade-offs of site-local addressing. > > > > This period of discussion has offered sufficient time for > anyone who > > has an operational need for any of the currently-defined > usage models > > of site-local addressing to document those requirements in an > > Internet-Draft and/or to discuss those requirements on the IPv6 > > mailing list. > > > > During our discussions, several operational benefits of site-local > > addressing have been raised on the IPv6 WG mailing list, including > > benefits for disconnected sites, intermittently- connected sites, > > renumbered sites, etc. We have also uncovered several issues and > > complexities caused by the current model of ambiguous, scoped > > site-local addressing, and we have determined that this particular > > model places burdens on other parts of the TCP/IP protocol suite, > > particularly routing protocols and applications. > > > > In a recent phone discussion and in your appeal clarification, you > > have indicated that the chairs should void responses from > people who > > do not think that the IPv6 WG should specify any type of local > > addressing mechanism, because you believe that those responders are > > uninformed about the operational conditions that require the use of > > local addressing. > > > > While operational necessity is certainly an appropriate argument to > > raise in support of your position that the IPv6 WG should > specify some > > mechanism for local addressing, the fact that you disagree with the > > reasons that some people offered for why they want to deprecate the > > current IPv6 site-local unicast addressing mechanism does not > > invalidate their contribution to this consensus call. > > > > It is the opinion of the chairs that the IPv6 WG did have > sufficient > > information to make an informed decision regarding whether > or not to > > deprecate IPv6 site-local unicast addressing. > > > > --- > > > > So, to summarize, the chairs do not agree with the points that you > > have raised in your appeal, and we do not agree to overturn the > > consensus of the IPv6 WG based on the issues that you have raised. > > > > Tony, while we disagree with your position on this > particular issue, > > we do respect your contributions to the IPv6 effort and we realize > > that your appeal is motivated by your desire to do the > right thing for > > IPv6. We hope that you will accept our response to your appeal and > > focus on working to define the local addressing problem and > solutions > > as we outlined in our email to the list. We think it is > important for > > the working group to move forward on this issue. > > > > Best Regards, > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG Chairs > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > [8] Tony Hain's reaction to the response from chairs. > > > > From: "Tony Hain" > > To: "'Margaret Wasserman'" , > > "'Bob Hinden'" > > Cc: , "'Thomas Narten'" > , > > "'Erik Nordmark'" > > Subject: RE: Your Appeal Regarding Site-Local Deprecation > > (Was: Consensus on Site-Local Addressing) > > Date: Mon, 28 Apr 2003 18:38:26 -0700 > > Message-ID: <066f01c30df0$07ae4740$261e4104@eagleswings> > > > > Margaret Wasserman wrote: > > > (3) You do not believe that there is rough consensus to > > > deprecate IPv6 site-local addressing, because people > > > provided different reasons for why they believe that > > > IPv6 site-local addressing should be deprecated. In > > > particular, some people want to deprecate the particular > > > model of site-local addressing defined in the scoped > > > addressing architecture (ambiguous, scoped addresses), > > > while others do not believe that we need a local > > > addressing mechanism at all. > > > > I was not objecting to 'different reasons'. The specific > complaint is > > that many of YES votes were for removing the architectural > construct, > > or need for applications to deal with addresses that are only > > accessable over a limited scope. That is not in the purview of the > > IETF to decide, > > it is an operational decision of the network manager. Those > votes are > > not valid as a result. > > > > > > > Point (1): > > > > > > The chairs do not believe that deprecating IPv6 site-local > > > addressing is an incorrect technical decision that will place > > > the work output of the IPv6 WG in jeopardy. > > > > > > The consensus was to "deprecate" the usage of site-local > > > addressing instead of simply removing it. > > > > By asking an ambiguous question, it is easy to insert your > > interpretation as the collective consensus. How convenient. SF > > question -- ... how many people think that we should deprecate SL > > addressing? Mail list question -- > > Should we deprecate IPv6 site-local unicast addressing? > > > > Neither of those mention 'usage'. In fact if you watch the > > video of SF, > > you will find that you spent much more time talking about > elimination > > than anything else. > > > > > This was done > > > purposely to avoid interference with any current > > > implementations or deployments that might use site-local > > > addressing. In addition to the time it will take to formally > > > deprecate site-local addressing by publishing an RFC, the WG > > > understands that it will take some time after the publication > > > of an RFC for implementations to change. The decision to > > > deprecate site-local addressing, rather than simply removing > > > it, was made to avoid harm to IPv6. > > > > There was no decision. You had an inconclusive discussion > with Keith, > > then later a vague discussion with Thomas about a 'hand > wave'. Neither > > of those even come close to a decision, let alone a WG > decision. Are > > we supposed to just say YES to any ambiguous question you > ask, so you > > can make up the content of the consensus later? > > > > > > > > In fact, we believe that the previous disagreement over the > > > usage of IPv6 site-local addressing was damaging to the WG, > > > and that our lack of consensus was delaying our work, > > > particularly on the IPv6 scoped addressing architecture. > > > > While you may believe that the disagreement over SL was > delaying the > > work, most of those disagreements stemmed from a lack of agreement > > over the fundamental requirements. Removing SL does not solve the > > basic problems that need to be addressed in the scoped addressing > > architecture. > > > > > The > > > consensus to deprecate site-local addressing will allow us to > > > move forward and complete our work. > > > > No it won't. A scoped address architecture document that > ignores the > > reality of addresses that are only reachable within a > limited part of > > the network is incomplete on its major point. It is > absolutely useless > > to pretend that we have a document that discusses a scoped > > architecture when the case for the majority of nodes in the > Internet > > is missing. > > > > > > > > --- > > > Point (2): > > > > > > The question was: > > > > > > "Should we deprecate IPv6 site-local unicast > > > addressing?" Possible answers were YES or NO. > > > > > > The chairs believe that this question was sufficiently > clear to be > > > understood by the WG. > > > > Clearly you didn't watch the video of the SF meeting. Why > > would Thomas, > > Keith, Dave, and Christian make a specific point of trying > to clarify > > the question if it was clear to begin with? Since the > question didn't > > change, it remained just as unclear as it started, and none of the > > 'somewhere to the left' & 'hand wave' comments were sent to > the list. > > > > > This is supported by the following > > > points: > > > > > > - Over 200 people responded to the question. > > > > > > - Many of the responses on the list (both YES and NO > > > responses) included reasons or comments that > > > followed from the question in a way that indicated > > > that the responders understood the question. > > > > I disagree. Many of the responses indicated what they meant > by saying > > yes, which is not the same as understanding the question. In fact, > > their need to explain what question they were answering is > an implicit > > statement of lack of clarity in the question. > > > > > > > > - There were only three requests for clarification of > > > this consensus call on the mailing list, two of which > > > were procedural. All of these requests were answered > > > promptly by the chairs. > > > > > > - The chairs sent the consensus results to the list > > > over two weeks ago, including a course of action for > > > the deprecation of site-local addressing. There > > > have been no objections from people who originally > > > expressed YES opinions that the chairs' course of > > > action fails to match their expectations. > > > > Why would there be? They all have their own > interpretations, so there > > won't be objections until the actual next steps begin. > > > > > > > > --- > > > > > > Point (3): > > > > > > The chairs do not believe that consensus on an issue is > > > invalidated by the fact that people have multiple reasons for > > > coming to the same conclusion. We suspect that this happens > > > in most WG consensus calls, and this is not a reason to > > > invalidate the consensus. > > > > You missed the point that many of those responses are for an > > architectural change that is not in the IETF's purview to > decide. See > > above. > > > > > > > > All of the groups that you mentioned in your message agreed > > > that IPv6 site-local unicast addressing should be deprecated. > > > > No, some of them believed this is about removing local scoped > > addresses > > from the architecture, or consideration by applications. That > > is not the > > same as 'usage' of a defined prefix. > > > > > They may disagree on what we should do after deprecating > > > site- local addressing, but that does not invalidate the > > > consensus on this point. > > > > There is a vast and architectural difference between removing > > addresses > > which are only reachable over a limited part of the > network, and usage > > of a specific prefix to identify those. You keep claiming > there is a > > consensus, but any objective observer of the SF video would > disagree. > > > > > > > > --- > > > > > > Point (4): > > > > > > It is true that the IPv6 WG has not produced a WG document > > > that analyzes the operational requirements for local > > > addressing. However, we do not believe that this is a reason > > > to invalidate the IPv6 WG consensus to deprecate IPv6 > > > site-local unicast addressing. > > > > You said it multiple times in SF yourself, the WG needs complete > > documentation to do an appropriate analysis. You appear to > be letting > > your desire to 'be right' get in the way of your ability to analyze > > your own responses. I don't understand how can you objectively say > > 'we don't > > need a document describing the need for X to decide that we > don't need > > X'? > > > > > > > > There has been considerable discussion and analysis of site- > > > local addressing performed over the past year, including > > > extensive discussions during three IETF sessions. There have > > > also been several drafts published on the subject, including > > > one draft that attempts to analyze the cost/benefit > > > trade-offs of site-local addressing. > > > > There have been personal drafts. The WG has not taken this on as a > > specific work item. > > > > > > > > This period of discussion has offered sufficient time for > > > anyone who has an operational need for any of the > > > currently-defined usage models of site-local addressing to > > > document those requirements in an Internet-Draft and/or to > > > discuss those requirements on the IPv6 mailing list. > > > > They have been discussed on the mail list to the point that > > people stop > > paying attention. This argument is disingenuous because there > > has never > > been a WG item about creating this document. In addition, I > > have offered > > a draft on the subject multiple times in the last month, > yet have not > > even received as much as a simple 'no thanks' from the chairs. > > > > > > > > During our discussions, several operational benefits of > > > site-local addressing have been raised on the IPv6 WG mailing > > > list, including benefits for disconnected sites, > > > intermittently- connected sites, renumbered sites, etc. We > > > have also uncovered several issues and complexities caused by > > > the current model of ambiguous, scoped site-local addressing, > > > and we have determined that this particular model places > > > burdens on other parts of the TCP/IP protocol suite, > > > particularly routing protocols and applications. > > > > Most of those difficulties will persist, because they are the > > result of > > inconsistent views of the network topology. There is nothing about > > deprecating SL that will change this. The only affect will be > > to make it > > harder to figure out when the burdens exist. > > > > > > > > In a recent phone discussion and in your appeal > > > clarification, you have indicated that the chairs should void > > > responses from people who do not think that the IPv6 WG > > > should specify any type of local addressing mechanism, > > > because you believe that those responders are uninformed > > > about the operational conditions that require the use of > > > local addressing. > > > > > > While operational necessity is certainly an appropriate > > > argument to raise in support of your position that the IPv6 > > > WG should specify some mechanism for local addressing, the > > > fact that you disagree with the reasons that some people > > > offered for why they want to deprecate the current IPv6 > > > site-local unicast addressing mechanism does not invalidate > > > their contribution to this consensus call. > > > > I am pointing out that their 'reason' is not in the purview > > of the IETF > > to decide, so their YES votes are not informed or valid. I am not > > objecting to their opinion, just the chair's interpretation > > of consensus > > is in error because it fails to discount the votes for an > > architectural > > point that is out of the IETF's control. > > > > > > > > It is the opinion of the chairs that the IPv6 WG did have > > > sufficient information to make an informed decision regarding > > > whether or not to deprecate IPv6 site-local unicast addressing. > > > > Even though a long-term member of the WG said right before > > the question > > that he did not have enough information to vote NO ... and another > > participant stated he had never heard the requirements before > > Erik gave > > a verbal partial list. How do these create 'an informed decision'? > > > > > > > > --- > > > > > > So, to summarize, the chairs do not agree with the points > > > that you have raised in your appeal, and we do not agree to > > > overturn the consensus of the IPv6 WG based on the issues > > > that you have raised. > > > > I am not surprised. > > > > > > > > Tony, while we disagree with your position on this particular > > > issue, we do respect your contributions to the IPv6 effort > > > and we realize that your appeal is motivated by your desire > > > to do the right thing for IPv6. We hope that you will accept > > > our response to your appeal and focus on working to define > > > the local addressing problem and solutions as we outlined in > > > our email to the list. We think it is important for the > > > working group to move forward on this issue. > > > > I will be escalating to Erik & Thomas, because I do believe > > that is the > > right and expeditious thing to do in this case. > > > > Tony > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > [9] Tony Hain's appeal to the INT ADs. > > > > From: "Tony Hain" > > To: "'Thomas Narten'" , > > "'Erik Nordmark'" > > Cc: , "'Bob Hinden'" > > , > > "'Margaret Wasserman'" > > Subject: RE: Your Appeal Regarding Site-Local Deprecation > > (Was: Consensus on Site-Local Addressing) > > Date: Mon, 28 Apr 2003 18:43:47 -0700 > > Message-ID: <067001c30df0$c7ae0ad0$261e4104@eagleswings> > > > > Thomas & Erik, > > > > I trust that you will take a more objective view of this, > because any > > outsider who needs to watch that video will be rolling in the isles > > with laughter at the absurdity of the process abuse in this case. > > At least 5 > > long-time IETF participants (including yourself) felt the > > need to state > > what they meant by 'deprecate SL'. One has to assume they > bothered to > > assert their interpretation because the YES/NO question was > unclear to > > them, or that their need to explain which question they > were answering > > is an implicit statement that the original question was > unclear. Even > > though the question never changed, none of the (amazingly vague) > > clarifying remarks in SF were sent to the list version of the > > consensus > > call. > > > > If a legal professional were to watch the proceedings here, > they would > > comment that the WG gave the chairs the freedom to interpret the > > meaning of the question any way they choose. In fact we > have examples > > of that already on the mail list and in this response. > > 3/30 chair email claimed > > > As part of deprecating site-local addressing, we > > > agreed in the meeting that, in addition to deprecating > > > site-local addressing in the addressing architecture > > > and removing it from other places (scoped addressing > > > architecture, address selection rules, etc.), a document > > > would be written that would do two things: > > > > > > - Explain why site-local addressing was deprecated > > > - Outline alternative means to address some of the > > > problems that could have been solved by > > > site-local addressing. > > > > That question was never asked of the room, and those > > statements were not > > made by the chairs in SF. How could there be an agreement? > > > > > The decision to deprecate site-local addressing, > > > rather than simply removing it, was made to avoid > > > harm to IPv6. > > > > There was nothing more to this than vague conversations > > between Margaret > > & Keith, and Margaret & Thomas. There was no decision by the > > WG, just a > > chair proclamation that one had occurred. We can't allow the > > WG process > > to degenerate to the point that a chair can call an ambiguous YES/NO > > question, then make up anything they choose to have it mean > later. In > > particular, when the chair explicitly states '... if we > > eliminate it we > > will also have multiple choices about what exactly that means > > ...', and > > '... may have to hand wave ...' there is not a clear > indication about > > what question is being asked. > > > > I put specific rebuttal comments to the chair's rejection in a list > > response to the chairs. In summary I believe the chairs > have declared > > a consensus when there really wasn't one due to the ambiguity of the > > question. Specifically the YES votes for removing addresses > with local > > scope from the architecture or consideration by > applications are void, > > as that is not something the IETF gets to decide. Had the > chairs asked > > Keith's original question about finding an alternate way > > forward through > > replacement technologies, we would not be going through > this process. > > > > As for a path forward, I would expect you to invalidate the > consensus, > > then have the WG stop the pronouncements that SL is dead, > and work on > > finding appropriate replacements. This effort must begin with > > identification of the requirements for addresses of local > scope, and > > under local network manager control. With requirements in hand, the > > scoped address architecture document needs to specifically > deal with > > handling mixed scope addresses, both between and for > simultaneous use > > on a singe node. That document in particular is hopelessly > gutted and > > meaningless without such a discussion. IF we get to the > point were all > > requirements are met by alternatives, the current SL > definition should > > appropriately be moved to historic. If not, it will likely > > end up in the > > corner case use that Keith was trying to achieve. Either way, > > the entire > > WG must decide exactly what happens. We must not allow the > 'ambiguous > > YES/NO question - chairs subsequently decide what it means', > > process to > > set a precedent. > > > > Tony > > > > > > > > > > Margaret Wasserman wrote: > > > Hi Tony, > > > > > > We have considered your appeal regarding the IPv6 WG > > > consensus to deprecate site-locals. Based on our analysis, > > > we believe that your appeal makes the following points: > > > > > > (1) You believe that deprecating IPv6 site-local unicast > > > addressing is an incorrect technical choice that places > > > the work output of the IPv6 WG in jeopardy. > > > > > > (2) You believe that the question asked by the chairs > > > was insufficiently clear to be understood properly > > > by the WG. > > > > > > (3) You do not believe that there is rough consensus to > > > deprecate IPv6 site-local addressing, because people > > > provided different reasons for why they believe that > > > IPv6 site-local addressing should be deprecated. In > > > particular, some people want to deprecate the particular > > > model of site-local addressing defined in the scoped > > > addressing architecture (ambiguous, scoped addresses), > > > while others do not believe that we need a local > > > addressing mechanism at all. > > > > > > (4) You believe that it is invalid for the IPv6 WG to > > > deprecate site-local addressing without publishing an > > > IPv6 WG document that analyzes the operational requirements > > > for local addressing. Without this analysis document, you > > > believe that the IPv6 WG has made an uninformed choice. > > > > > > We will now respond to each of your points. > > > > > > -- > > > > > > Point (1): > > > > > > The chairs do not believe that deprecating IPv6 site-local > > > addressing is an incorrect technical decision that will place > > > the work output of the IPv6 WG in jeopardy. > > > > > > The consensus was to "deprecate" the usage of site-local > > > addressing instead of simply removing it. This was done > > > purposely to avoid interference with any current > > > implementations or deployments that might use site-local > > > addressing. In addition to the time it will take to formally > > > deprecate site-local addressing by publishing an RFC, the WG > > > understands that it will take some time after the publication > > > of an RFC for implementations to change. The decision to > > > deprecate site-local addressing, rather than simply removing > > > it, was made to avoid harm to IPv6. > > > > > > In fact, we believe that the previous disagreement over the > > > usage of IPv6 site-local addressing was damaging to the WG, > > > and that our lack of consensus was delaying our work, > > > particularly on the IPv6 scoped addressing architecture. The > > > consensus to deprecate site-local addressing will allow us to > > > move forward and complete our work. > > > > > > --- > > > Point (2): > > > > > > The question was: > > > > > > "Should we deprecate IPv6 site-local unicast > > > addressing?" Possible answers were YES or NO. > > > > > > The chairs believe that this question was sufficiently > clear to be > > > understood by the WG. This is supported by the following > > > points: > > > > > > - Over 200 people responded to the question. > > > > > > - Many of the responses on the list (both YES and NO > > > responses) included reasons or comments that > > > followed from the question in a way that indicated > > > that the responders understood the question. > > > > > > - There were only three requests for clarification of > > > this consensus call on the mailing list, two of which > > > were procedural. All of these requests were answered > > > promptly by the chairs. > > > > > > - The chairs sent the consensus results to the list > > > over two weeks ago, including a course of action for > > > the deprecation of site-local addressing. There > > > have been no objections from people who originally > > > expressed YES opinions that the chairs' course of > > > action fails to match their expectations. > > > > > > --- > > > > > > Point (3): > > > > > > The chairs do not believe that consensus on an issue is > > > invalidated by the fact that people have multiple reasons for > > > coming to the same conclusion. We suspect that this happens > > > in most WG consensus calls, and this is not a reason to > > > invalidate the consensus. > > > > > > All of the groups that you mentioned in your message agreed > > > that IPv6 site-local unicast addressing should be deprecated. > > > They may disagree on what we should do after deprecating > > > site- local addressing, but that does not invalidate the > > > consensus on this point. > > > > > > --- > > > > > > Point (4): > > > > > > It is true that the IPv6 WG has not produced a WG document > > > that analyzes the operational requirements for local > > > addressing. However, we do not believe that this is a reason > > > to invalidate the IPv6 WG consensus to deprecate IPv6 > > > site-local unicast addressing. > > > > > > There has been considerable discussion and analysis of site- > > > local addressing performed over the past year, including > > > extensive discussions during three IETF sessions. There have > > > also been several drafts published on the subject, including > > > one draft that attempts to analyze the cost/benefit > > > trade-offs of site-local addressing. > > > > > > This period of discussion has offered sufficient time for > > > anyone who has an operational need for any of the > > > currently-defined usage models of site-local addressing to > > > document those requirements in an Internet-Draft and/or to > > > discuss those requirements on the IPv6 mailing list. > > > > > > During our discussions, several operational benefits of > > > site-local addressing have been raised on the IPv6 WG mailing > > > list, including benefits for disconnected sites, > > > intermittently- connected sites, renumbered sites, etc. We > > > have also uncovered several issues and complexities caused by > > > the current model of ambiguous, scoped site-local addressing, > > > and we have determined that this particular model places > > > burdens on other parts of the TCP/IP protocol suite, > > > particularly routing protocols and applications. > > > > > > In a recent phone discussion and in your appeal > > > clarification, you have indicated that the chairs should void > > > responses from people who do not think that the IPv6 WG > > > should specify any type of local addressing mechanism, > > > because you believe that those responders are uninformed > > > about the operational conditions that require the use of > > > local addressing. > > > > > > While operational necessity is certainly an appropriate > > > argument to raise in support of your position that the IPv6 > > > WG should specify some mechanism for local addressing, the > > > fact that you disagree with the reasons that some people > > > offered for why they want to deprecate the current IPv6 > > > site-local unicast addressing mechanism does not invalidate > > > their contribution to this consensus call. > > > > > > It is the opinion of the chairs that the IPv6 WG did have > > > sufficient information to make an informed decision regarding > > > whether or not to deprecate IPv6 site-local unicast addressing. > > > > > > --- > > > > > > So, to summarize, the chairs do not agree with the points > > > that you have raised in your appeal, and we do not agree to > > > overturn the consensus of the IPv6 WG based on the issues > > > that you have raised. > > > > > > Tony, while we disagree with your position on this particular > > > issue, we do respect your contributions to the IPv6 effort > > > and we realize that your appeal is motivated by your desire > > > to do the right thing for IPv6. We hope that you will accept > > > our response to your appeal and focus on working to define > > > the local addressing problem and solutions as we outlined in > > > our email to the list. We think it is important for the > > > working group to move forward on this issue. > > > > > > Best Regards, > > > > > > Bob Hinden & Margaret Wasserman > > > IPv6 WG Chairs > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------