From nobody Mon Aug 1 06:04:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA93212DC87 for ; Mon, 1 Aug 2016 06:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.808 X-Spam-Level: X-Spam-Status: No, score=-115.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxVpKBBhdZJC for ; Mon, 1 Aug 2016 06:04:07 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF03112D934 for ; Mon, 1 Aug 2016 06:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=483; q=dns/txt; s=iport; t=1470056434; x=1471266034; h=date:from:message-id:to:subject; bh=Se9nqAWGnkneXPzq5e4mbgCme29dW/WSDJerCX/Scf8=; b=N9mnQ4oJywRbI3aLXMZxh83KqCcjshH1dSZ7FOM7Dwlcx7fVQDiWKNAF bL4OU703mCbjS1GR7Jd4YZgUrX4MBqpALlBHupmp+TzVF5XaAFAKQwrRe w1i+6E75uZ0QzognXbfRvzwq8f/wtZjMwDmzYR122ySiLf3WoTcop/qsT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BkAwCDR59X/4kNJK1dg0WpQpEhgX2HT?= =?us-ascii?q?DgUAQEBAQEBAV0nQQ4BhUo0iREBoQqfPwEBCAEBAQEBIpADhQ8FjwuKKIE2jx4?= =?us-ascii?q?BjWmMMIN3HjaEGoRrg3gBAQE?= X-IronPort-AV: E=Sophos;i="5.28,455,1464652800"; d="scan'208";a="304564755" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2016 13:00:34 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u71D0XqM024375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Aug 2016 13:00:34 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u71D0XfR005964 for ; Mon, 1 Aug 2016 06:00:33 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u71D0XR2005963 for v6ops@ietf.org; Mon, 1 Aug 2016 06:00:33 -0700 Date: Mon, 1 Aug 2016 06:00:33 -0700 From: fred@cisco.com Message-Id: <201608011300.u71D0XR2005963@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 13:04:09 -0000 WG: Unupdated WG Document 2016-07-08 draft-ietf-v6ops-unique-ipv6-prefix-per-host 2016-02-16 draft-ietf-v6ops-dhcpv6-slaac-problem 2016-02-08 draft-ietf-v6ops-ula-usage-considerations Individual Submission: Unupdated 2016-06-27 draft-templin-v6ops-pdhost 2016-06-20 draft-anderson-v6ops-v4v6-xlat-prefix 2016-03-21 draft-ybai-v6ops-ipv6-for-openstack 2016-03-11 draft-gont-v6ops-ipv6-ehs-packet-drops 2016-02-27 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node From nobody Mon Aug 1 06:31:40 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AFF12DCDE for ; Mon, 1 Aug 2016 06:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQZgWiG-55SE for ; Mon, 1 Aug 2016 06:31:37 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2511B12DCF6 for ; Mon, 1 Aug 2016 06:17:33 -0700 (PDT) X-AuditID: 60721c4b-41bff700000014a4-1d-579f4bea0db8 Received: from VAADCEX09.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id D8.A0.05284.AEB4F975; Mon, 1 Aug 2016 09:17:31 -0400 (EDT) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX09.cable.comcast.com (147.191.102.76) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 1 Aug 2016 09:17:30 -0400 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 1 Aug 2016 09:17:30 -0400 From: "Brzozowski, John" To: "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] State of play Thread-Index: AQHR6/U4wQ9OJPIR6USkWMd27VT6f6A0Fi8A Date: Mon, 1 Aug 2016 13:17:30 +0000 Message-ID: <7F5058A6-C7E0-4921-9DE6-89E3F2DBD2BE@cable.comcast.com> References: <201608011300.u71D0XR2005963@irp-lnx1.cisco.com> In-Reply-To: <201608011300.u71D0XR2005963@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.9] Content-Type: text/plain; charset="utf-8" Content-ID: <8523AE57ABEB4F41A9B87BDCCCE9992A@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsWSUOxpofvae364wdFpghbv151hszh9bC+z A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWx985+loIJvBUd3/YyNjA+4eli5OSQEDCR eN7yjKmLkYtDSGAmk8ShV3vZQRJCAvsZJSb+todInGCUmL7tMRNIgk3ATGLLwdtARRwcIgIe ElNfS4GEhQWUJDY9/wdWIiKgLHHn1mZWCNtI4tjuF8wgNouAisSHC21gNq+Ai8SuZ8fZIHbZ SFxa9YMRxOYUsJWYMn8eWJxRQEzi+6k1YDOZBcQlbj2ZzwRxtIDEkj3nmSFsUYmXj/+B7RIV 0JP4c+ALVI2OxNnrTxghbAOJrUv3sUDYChLv/51iAzmfWUBTYv0ufYjxDhLPT51ghLAVJaZ0 P2SHOFNQ4uTMJ1Ct4hKHj+xgncAoNQvJRbMQJs1CMmkWkkmzkExawMi6ilGuLDExJTk3I7+0 xMBQLzkxKSdVLzk/NzmxuAREb2IERXGRjPcOxnU/3Q8xCnAwKvHw1jnMDxdiTSwrrsw9xCjB wawkwrvRCyjEm5JYWZValB9fVJqTWnyIUZqDRUmcV8pwYriQQHpiSWp2ampBahFMlomDU6qB UfFiTc3MNTqypSzqMz8lnn7LYphSE5+kfpBnm9HUej/bzMb3b2/NEDpyPiC/68Ol0y8EVJOW P5283P271jP9SJ3kw4ejua/OMenY90v3yXRZ3nKT0n/xRuUsS9a5i/lrnJXONhQ8lWYuvdXJ M+lDXqcmxzUT13MHFbWvK7pG/KhunKZjuTlJiaU4I9FQi7moOBEAFEuaMd4CAAA= Archived-At: Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 13:31:38 -0000 RnJlZCwNCg0KU28gd2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UsIHRoZSBiZWxvdyB3YXMgdXBkYXRl ZCBzaW5jZSB0aGUgb3JpZ2luYWwgSS1EIHdhcyBwb3N0ZWQuICBUaGlzIHZlcnNpb24sIC0wMSwg Y29udGFpbnMgb25seSBwcm90b2NvbCByZWxhdGVkIGl0ZW1zLiAgR3VudGVyIGFuZCBJIGhhdmUg YSAtMDIgcGxhbm5lZCB0aGF0IHdpbGwgaW5jb3Jwb3JhdGUgcmVtYWluaW5nIGNvbW1lbnRzLCBl ZGl0cywgZXRjLg0KDQoyMDE2LTA3LTA4CWRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N0DQoNCkpvaG4NCisxLTQ4NC05NjItMDA2MA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBGcmVkIEJha2VyIDxmcmVkQGNpc2NvLmNvbT4NCkRhdGU6IE1vbmRheSwgQXVndXN0IDEs IDIwMTYgYXQgMDk6MDANClRvOiB2Nm9wcyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbdjZv cHNdIFN0YXRlIG9mIHBsYXkNCg0KICAgIFdHOiBVbnVwZGF0ZWQgV0cgRG9jdW1lbnQNCiAgICAJ MjAxNi0wNy0wOAlkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0K ICAgIAkyMDE2LTAyLTE2CWRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0NCiAg ICAJMjAxNi0wMi0wOAlkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1jb25zaWRlcmF0aW9ucw0K ICAgIA0KICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbjogVW51cGRhdGVkIA0KICAgIAkyMDE2LTA2 LTI3CWRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0DQogICAgCTIwMTYtMDYtMjAJZHJhZnQtYW5k ZXJzb24tdjZvcHMtdjR2Ni14bGF0LXByZWZpeA0KICAgIAkyMDE2LTAzLTIxCWRyYWZ0LXliYWkt djZvcHMtaXB2Ni1mb3Itb3BlbnN0YWNrDQogICAgCTIwMTYtMDMtMTEJZHJhZnQtZ29udC12Nm9w cy1pcHY2LWVocy1wYWNrZXQtZHJvcHMNCiAgICAJMjAxNi0wMi0yNwlkcmFmdC1zbWl0aC12Nm9w cy1taXRpZ2F0ZS1ydHItZG9zLW1sZC1zbGN0ZC1ub2RlDQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICB2Nm9wcyBtYWlsaW5nIGxp c3QNCiAgICB2Nm9wc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCiAgICANCiAgICANCg0K From nobody Mon Aug 1 08:31:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79512DC7A for ; Mon, 1 Aug 2016 08:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.808 X-Spam-Level: X-Spam-Status: No, score=-115.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvyhPrn1d2J0 for ; Mon, 1 Aug 2016 08:31:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F369612DC84 for ; Mon, 1 Aug 2016 08:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2731; q=dns/txt; s=iport; t=1470065492; x=1471275092; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FjLXYiB5vhHBdSUumV8mVXPnXwur6CBWHu3UuLZ8j58=; b=bbo/+vSTw6cHX81Jigod2RD/HlQmBjlXq2I3242nV3eyRUUvYfrvK8q0 PXrFS3VjkLAXCdVlRBZ4ryQ9th1aqdd6fowstScjI9TVWuPueHLjDmNt7 wIPBTxfmX5TnjhllDt0rS8++SguyA4nQsCvWrWtNK4Suuk0H3R1rj0c9S A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgDKap9X/49dJa1aA4NFVnwGuQ6Bf?= =?us-ascii?q?SSFeQKBLjgUAQEBAQEBAV0nhF4BAQQBAQFsCwUHBAIBCBEDAQIBLicLHQgCBA4?= =?us-ascii?q?FDogbCA7AWQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4JBYgiCIJNhEcZASaCZYIvB?= =?us-ascii?q?ZkzAYM5gXCJVY8/jDCDdgEeNoN6bocWfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,455,1464652800"; d="asc'?scan'208";a="130919145" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 15:31:31 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u71FVVVK023020 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Aug 2016 15:31:31 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 1 Aug 2016 10:31:30 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 1 Aug 2016 10:31:30 -0500 From: "Fred Baker (fred)" To: "Brzozowski, John" Thread-Topic: [v6ops] State of play Thread-Index: AQHR7AnG+pz3YoE3oU2Qp/sPWbxqig== Date: Mon, 1 Aug 2016 15:31:30 +0000 Message-ID: References: <201608011300.u71D0XR2005963@irp-lnx1.cisco.com> <7F5058A6-C7E0-4921-9DE6-89E3F2DBD2BE@cable.comcast.com> In-Reply-To: <7F5058A6-C7E0-4921-9DE6-89E3F2DBD2BE@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_E639701F-0504-40AE-9234-1EA09ED7A550"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 15:31:42 -0000 --Apple-Mail=_E639701F-0504-40AE-9234-1EA09ED7A550 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks > On Aug 1, 2016, at 6:17 AM, Brzozowski, John = wrote: >=20 > Fred, >=20 > So we are on the same page, the below was updated since the original = I-D was posted. This version, -01, contains only protocol related = items. Gunter and I have a -02 planned that will incorporate remaining = comments, edits, etc. >=20 > 2016-07-08 draft-ietf-v6ops-unique-ipv6-prefix-per-host >=20 > John > +1-484-962-0060 >=20 > -----Original Message----- > From: v6ops on behalf of Fred Baker = > Date: Monday, August 1, 2016 at 09:00 > To: v6ops > Subject: [v6ops] State of play >=20 > WG: Unupdated WG Document > 2016-07-08 draft-ietf-v6ops-unique-ipv6-prefix-per-host > 2016-02-16 draft-ietf-v6ops-dhcpv6-slaac-problem > 2016-02-08 draft-ietf-v6ops-ula-usage-considerations >=20 > Individual Submission: Unupdated > 2016-06-27 draft-templin-v6ops-pdhost > 2016-06-20 draft-anderson-v6ops-v4v6-xlat-prefix > 2016-03-21 draft-ybai-v6ops-ipv6-for-openstack > 2016-03-11 draft-gont-v6ops-ipv6-ehs-packet-drops > 2016-02-27 = draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 --Apple-Mail=_E639701F-0504-40AE-9234-1EA09ED7A550 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV59rUEayAOS/EQ8MAQLLUxAAw7MDv7ZZPXXEMmlOduwCM/TJRHHl+6dv MHXhgizROseSXCN4sCx0LjKVcUd+k4xbVMettgsSOK9OywGrNvzzuthvnsdk6HEV tMdNJWflggVfF3XB1TE9+7J60SZEHIqf9aikmQAPIz0gkjwdzDzaoB+CqozUSsTq 0hbMbwVZSbNQzvJtCxx1pqEoVdccqvGN1M75z7lHn6506gPY0yWX8TgLatKM4350 zWz+SHaHLeYiqHNI3NJUZ+fAuO8k+3wqUKqsD2+CPh7tCceXg2QpXu08H5FuWEi7 1TNOtSuwy1r8KS6KQTAyZMPyJsPKCXGjz+crrk6V8ipA38clkanU/xIUtqtM5QaK rANWs5e6A483Vweve+OKmtSZf0sYtRJpu1Ry8xZ50ZCQWNgMUWGQnxKVtI7PSjku Ryl6oi8KCwf13VFOT3zcixQh8LKRCnsVfds5/XdMwZ8UAJIQAT9U4PLlOFz0HEWk ma4xl93zNxuGEFx7nEYNWp3rFJL/p/OXJkshqyT1q12QudYrrwbz1/W+lJzcrpfz VG4CL1lFVq9vM5gbAsmE7i76xreXcCMtt3FIbrc+SRFnSD6ub/hxdlqDOVPMYQqD GSP/jXWvS+4O5vWHPych+1pIQNjta7F5I3zArxWodpn716YtR/ZvPuZopv3rjH1C c0KeiZdN3zc= =oo5f -----END PGP SIGNATURE----- --Apple-Mail=_E639701F-0504-40AE-9234-1EA09ED7A550-- From nobody Thu Aug 4 14:45:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CC112D863 for ; Thu, 4 Aug 2016 14:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21gnGBQNCZsi for ; Thu, 4 Aug 2016 14:45:50 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25EF012D865 for ; Thu, 4 Aug 2016 14:45:50 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id 35so184352292uap.1 for ; Thu, 04 Aug 2016 14:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=qkyLrOxnAkt0L62P55mkaaOIcr/G4BWEtEqF5MjMIfI=; b=xyna2hDeG8QD+XTq4Bg4wqcyyaPyhbJkZWT56OTG1z0fZmAgyxB9F3IY15Dc09HDCU dDcY9G/Ulb2enMDrLNXjrRlIGMnwwnMi3pYP5KCwUC/A0krxjACbJt5smvJ7kSvmxv5i 5xqb3WvUjb/JKAnLl8lObjN/Q2kNirDwQfJu25K7KvIyku5zeiVR2dvMLRtkWpbsCZgZ 6fl1KHpoSTpdh1TWTTosT60MUJh2KVJDrcKviU+U37yCSoo9DRQV8u4ZfdFAnR/u5Q3Z Wd48e03DiLK9/dPNboajGRtcCkmBbKvL3MWsgMbFFf1MDLaG9Lc5Kmotzr9LvHeWukEH f+bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qkyLrOxnAkt0L62P55mkaaOIcr/G4BWEtEqF5MjMIfI=; b=Im8atv4RIzh9h6ew2Co6tSuptwFgvmbpz0u3ykYNo04ZM6+J62cOBbizjJLt9wNZWl CXuU9+7LoYA8v6yroyAtdy+MTQFUqmLw8T7UoLL1QOYPIxMoq13XBwjDjrNSucD5j9V5 ovikQjYd7aiCyycW9hADu6h3/8OwhVhxa91QlxvQmxtTbmLHhyE+GGK+Gp6A7q+QiCKQ 8U7UrBSzfUj8NRtAEpXcTTnWCKntt+exee9IKFUpnKK5IzLr2BRXCRsAbhnWrwOxhcln oRRQ0nCTkqbNiSsmQ8B0ido17mmx/2dHmSts5DvS+bHj7qPLfuCAyys+EBRPuPlOilvE UFHQ== X-Gm-Message-State: AEkoouu7LDK0c91CNxuapr9jwd5xM+ZK7Ac9xC++iqz4N3tK57mL0C+CXXIJH0SHteNfKpQNSlm/FQa91nHlpA== X-Received: by 10.159.39.36 with SMTP id a33mr38012222uaa.33.1470347148949; Thu, 04 Aug 2016 14:45:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.252.78 with HTTP; Thu, 4 Aug 2016 14:45:48 -0700 (PDT) From: suprita Date: Thu, 4 Aug 2016 14:45:48 -0700 Message-ID: To: v6ops@ietf.org Content-Type: multipart/mixed; boundary=94eb2c0480e2829ca1053945df26 Archived-At: Subject: [v6ops] Fwd: [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 21:45:53 -0000 --94eb2c0480e2829ca1053945df26 Content-Type: multipart/alternative; boundary=94eb2c0480e2829c9d053945df24 --94eb2c0480e2829c9d053945df24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Apologies for any cross-posting. Regards, Suprita ---------- Forwarded message ---------- From: Wim Degezelle Date: Thu, Aug 4, 2016 at 4:04 AM Subject: [Bp_ipv6] survey BPF IPv6 - GO ! To: bp_ipv6@intgovforum.org Hi All The questionnaire to collect the case studies for the BPF IPv6 is online. You can use the online google forms questionnaire (link below), the files attached ( .docs and .txt) or google doc . Online questionnaire: https://docs.google.com/forms/ d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D 0&w=3D1 We want to reach out to parties and companies that have successfully deployed IPv6 and contribute substantially to the high deployment rate in their region or country. To coordinate, we keep track of our activities and of who is reaching out to who on our brainstorming document . Please keep updating the table. Thank you for your cooperation, Kind Regards Wim _________________________ *Wim Degezelle* *Consultant IGF BPF IPv6* *Consultant IGF BPF on IXPs* [image: Google Forms] Having trouble viewing or submitting this form? FILL OUT IN GOOGLE FORMS I've invited you to fill out a form: IGF2016 - Best Practice Forum IPv6 - =E2=80=98Understanding the commercial = and economic incentives behind a successful IPv6 deployment=E2=80=99 IPv6 Best Practice Forum 2016 would like to call for contributions to understand the economic motivation for IPv6 deployment. IPv6 is a technical protocol but the decision to adopt IPv6 is not only a technical one, other economic factors play an important role. IPv6 adoption is on the rise - not only in the Global North, but also in a number of states in the southern hemisphere - and there appears to be little correlation to GDP and IPv6. On the other hand, little documentation exists that analyzes the commercial aspects of IPv6 adoption, especially not based on specific, positive cases of adoption. By compiling case studies on business cases and economic factors behind IPv6 adoption as a best practices document for the Internet Governance Forum (IGF) in 2016, it will provide an opportunity for a wide range of stakeholders to understand IPv6, including those outside the technical community. The contributions will be discussed by participants of IGF IPv6 Best Practice Forum, and will be reflected in the output document where appropriate. The output document will be published on the IGF website after IGF2016, which will be held from 6-9 December 2016 in Guadalajara, Mexico. Additional References Scope and Goals of the BPF IPv6 2016: http://www.intgovforum.org/cms/documents/best-practice- forums/798-scope-and-goals-ipv6bpf2016 Join the BPF IPv6 2016 and sign-up to the bp_ipv6@intgovforum mailing list: http://mail.intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org [image: Captionless Image] Powered by [image: Google Forms] This content is neither created nor endorsed by Google. Report Abuse - Terms of Service - Additional Terms Create your own Google Form _______________________________________________ Bp_ipv6 mailing list Bp_ipv6@intgovforum.org http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org --94eb2c0480e2829c9d053945df24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies for any cross-posting.

Regard= s,
Suprita
---------- Forwarded mes= sage ----------
From: Wim Degezelle <wdegezelle@drmv.b= e>
Date: Thu, Aug 4, 2016 at 4:04 AM
Subject: [Bp_ipv6]= survey BPF IPv6 - GO !
To: b= p_ipv6@intgovforum.org


<= div>Hi All=C2=A0

The questionnaire to collect the = case studies for the BPF IPv6 is online.

You can u= se the online google forms questionnaire (link below), the files attached (= .docs and .txt) or=C2=A0google doc=C2=A0.

Online questionnaire: https:= //docs.google.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mjjx= _MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1

We want to reach out to parties and companies that have successfully de= ployed IPv6 and contribute substantially to the high deployment rate in the= ir region or country.

To coordinate, we keep track of ou= r activities and of who is reaching out to who on our=C2=A0brainstorming document. Please keep updating th= e table.

Thank you for your cooperation,

Kind Regards
Wim

_________= ________________


<= div>
=
Wim Dege= zelle
Consultant IGF BPF IPv6
Consultant IGF BPF on IXPs
<= /div>



3D"Google<= /tbody>
Having= trouble viewing or submitting this form?
<= /td>
FILL OUT IN GOOGLE FORMS
<= tbody>
I've invited you to f= ill out a form:
IGF2016 - Best Practice Forum IPv6 - = =E2=80=98Understanding the commercial and economic incentives behind a succ= essful IPv6 deployment=E2=80=99
IPv6 Best Practice Forum 20= 16 would like to call for contributions to understand the economic motivati= on for IPv6 deployment.

IPv6 is a technical protocol but the decisio= n to adopt IPv6 is not only a technical one, other economic factors play an= important role.

IPv6 adoption is on the rise - not only in the Glob= al North, but also in a number of states in the southern hemisphere - and t= here appears to be little correlation to GDP and IPv6. On the other hand, l= ittle documentation exists that analyzes the commercial aspects of IPv6 ado= ption, especially not based on specific, positive cases of adoption.
By compiling case studies on business cases and economic factors behind IP= v6 adoption as a best practices document for the Internet Governance Forum = (IGF) in 2016, it will provide an opportunity for a wide range of stakehold= ers to understand IPv6, including those outside the technical community. Th= e contributions will be discussed by participants of IGF IPv6 Best Practice= Forum, and will be reflected in the output document where appropriate. The= output document will be published on the IGF website after IGF2016, which = will be held from 6-9 December 2016 in Guadalajara, Mexico.

Addition= al References
Scope and Goals of the BPF IPv6 2016:
http://www.intgovforum.org/cms/docum= ents/best-practice-forums/798-scope-and-goals-ipv6bpf2016
Join the BPF IPv6 2016 and sign-up to the bp_ipv6@intgovforum mailing = list:
http://mail.intgovforum.org/mailman/l= istinfo/bp_ipv6_intgovforum.org

    3D"Captionless
Powered by
3D"Google
This conten= t is neither created nor endorsed by Google.
Report Abuse - Terms of S= ervice - A= dditional Terms
Create your own Google Form<= /td>


_______________________________________________
Bp_ipv6 mailing list
Bp_ipv6@intgovforum.org
http://intgovforum.org/mailman/l= istinfo/bp_ipv6_intgovforum.org


--94eb2c0480e2829c9d053945df24-- --94eb2c0480e2829ca1053945df26 Content-Type: text/plain; charset=US-ASCII; name="IGF2016-BPF_IPv6-CaseStudySurvey.txt" Content-Disposition: attachment; filename="IGF2016-BPF_IPv6-CaseStudySurvey.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: 657a03e572fd08f9_0.0.1.1 SUdGIDIwMTYgLSBCZXN0IFByYWN0aWNlIEZvcnVtIG9uIElQdjYNDQrigJhVbmRlcnN0YW5kaW5n IHRoZSBjb21tZXJjaWFsIGFuZCBlY29ub21pYyBpbmNlbnRpdmVzIGJlaGluZCBhIHN1Y2Nlc3Nm dWwgSVB2NiBkZXBsb3ltZW504oCZDQ0KDQ0KDQ0KQ2FsbCBmb3IgQ29udHJpYnV0aW9ucw0NCg0N Cg0NCklQdjYgQmVzdCBQcmFjdGljZSBGb3J1bSAyMDE2IHdvdWxkIGxpa2UgdG8gY2FsbCBmb3Ig Y29udHJpYnV0aW9ucyB0byB1bmRlcnN0YW5kIHRoZSBlY29ub21pYyBtb3RpdmF0aW9uIGZvciBJ UHY2IGRlcGxveW1lbnQuDQ0KDQ0KDQ0KSVB2NiBpcyBhIHRlY2huaWNhbCBwcm90b2NvbCBidXQg dGhlIGRlY2lzaW9uIHRvIGFkb3B0IElQdjYgaXMgbm90IG9ubHkgYSB0ZWNobmljYWwgb25lLCBv dGhlciBlY29ub21pYyBmYWN0b3JzIHBsYXkgYW4gaW1wb3J0YW50IHJvbGUuDQ0KDQ0KDQ0KSVB2 NiBhZG9wdGlvbiBpcyBvbiB0aGUgcmlzZSAtIG5vdCBvbmx5IGluIHRoZSBHbG9iYWwgTm9ydGgs IGJ1dCBhbHNvIGluIGEgbnVtYmVyIG9mIHN0YXRlcyBpbiB0aGUgc291dGhlcm4gaGVtaXNwaGVy ZSAtIGFuZCB0aGVyZSBhcHBlYXJzIHRvIGJlIGxpdHRsZSBjb3JyZWxhdGlvbiB0byBHRFAgYW5k IElQdjYuIE9uIHRoZSBvdGhlciBoYW5kLCBsaXR0bGUgZG9jdW1lbnRhdGlvbiBleGlzdHMgdGhh dCBhbmFseXplcyB0aGUgY29tbWVyY2lhbCBhc3BlY3RzIG9mIElQdjYgYWRvcHRpb24sIGVzcGVj aWFsbHkgbm90IGJhc2VkIG9uIHNwZWNpZmljLCBwb3NpdGl2ZSBjYXNlcyBvZiBhZG9wdGlvbi4N DQoNDQoNDQpCeSBjb21waWxpbmcgY2FzZSBzdHVkaWVzIG9uIGJ1c2luZXNzIGNhc2VzIGFuZCBl Y29ub21pYyBmYWN0b3JzIGJlaGluZCBJUHY2IGFkb3B0aW9uIGFzIGEgYmVzdCBwcmFjdGljZXMg ZG9jdW1lbnQgZm9yIHRoZSBJbnRlcm5ldCBHb3Zlcm5hbmNlIEZvcnVtIChJR0YpIGluIDIwMTYs IGl0IHdpbGwgcHJvdmlkZSBhbiBvcHBvcnR1bml0eSBmb3IgYSB3aWRlIHJhbmdlIG9mIHN0YWtl aG9sZGVycyB0byB1bmRlcnN0YW5kIElQdjYsIGluY2x1ZGluZyB0aG9zZSBvdXRzaWRlIHRoZSB0 ZWNobmljYWwgY29tbXVuaXR5LiBUaGUgY29udHJpYnV0aW9ucyB3aWxsIGJlIGRpc2N1c3NlZCBi eSBwYXJ0aWNpcGFudHMgb2YgSUdGIElQdjYgQmVzdCBQcmFjdGljZSBGb3J1bSwgYW5kIHdpbGwg YmUgcmVmbGVjdGVkIGluIHRoZSBvdXRwdXQgZG9jdW1lbnQgd2hlcmUgYXBwcm9wcmlhdGUuIFRo ZSBvdXRwdXQgZG9jdW1lbnQgd2lsbCBiZSBwdWJsaXNoZWQgb24gdGhlIElHRiB3ZWJzaXRlIGFm dGVyIElHRjIwMTYsIHdoaWNoIHdpbGwgYmUgaGVsZCBmcm9tIDYtOSBEZWNlbWJlciAyMDE2IGlu IEd1YWRhbGFqYXJhLCBNZXhpY28uDQ0KDQ0KDQ0KQWRkaXRpb25hbCBSZWZlcmVuY2VzDQ0KU2Nv cGUgYW5kIEdvYWxzIG9mIHRoZSBCUEYgSVB2NiAgMjAxNjogDQ0KaHR0cDovL3d3dy5pbnRnb3Zm b3J1bS5vcmcvY21zL2RvY3VtZW50cy9iZXN0LXByYWN0aWNlLWZvcnVtcy83OTgtc2NvcGUtYW5k LWdvYWxzLWlwdjZicGYyMDE2IA0NCg0NCg0NCkpvaW4gdGhlIEJQRiBJUHY2IDIwMTYgYW5kIHNp Z24tdXAgdG8gdGhlIGJwX2lwdjZAaW50Z292Zm9ydW0gbWFpbGluZyBsaXN0Og0NCmh0dHA6Ly9t YWlsLmludGdvdmZvcnVtLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JwX2lwdjZfaW50Z292Zm9ydW0u b3JnDQ0KDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGUgQlBGIElQdjYgYW5kIHRoaXMgcXVl c3Rpb25uYWlyZSwgcGxlYXNlIGNvbnRhY3QgV2ltIERlZ2V6ZWxsZSwgQ29uc3VsdGFudCBJR0Yg QlBGIG9uIElQdjYuIChlbWFpbCAgd2RlZ2V6ZWxsZSBhdCBkcm12LmJlKQ0NCg0NCl9fX19fX19f X19fX19fX18NDQoNDQoNDQpGb3IgZWFjaCBzZWN0aW9uIChleGNlcHQgc2VjdGlvbiAxKSB0aGVy ZSBpcyBvbmUga2V5IHF1ZXN0aW9uIHRoYXQgd2UgdXJnZSB5b3UgdG8gYW5zd2VyIGFzIGl0IGlz IGRpcmVjdGx5IGxpbmtlZCB0byB0aGUgY29tbWVyY2lhbCBhbmQgZWNvbm9taWMgaW5jZW50aXZl cy4NDQpXZSB3b3VsZCB3ZWxjb21lIGZ1cnRoZXIgZGV0YWlscyBhbmQgYmFja2dyb3VuZCBpbmZv cm1hdGlvbiAoaWYgeW914oCZcmUgYWJsZSB0byBkaXNjbG9zZSkgYXMgYW5zd2VycyBvbiB0aGUg Zm9sbG93IHVwIHF1ZXN0aW9ucy4gDQ0KDQ0KDQ0KDQ0KDQ0KMS4gR2VuZXJhbCBpbmZvcm1hdGlv bg0NCiAgICAgICAgIA0NCk5hbWUgb2YgT3JnYW5pc2F0aW9uIG9yIHByb2plY3QqOiANDQpDb3Vu dHJ5OiANDQpSZWdpb246DQoJKEFmcmljYSwgQXNpYSBQYWNpZmljLCBFdXJvcGUsIE1pZGRsZSBF YXN0LCBOb3J0aCBBbWVyaWNhLCBMYXRpbiBBbWVyaWNhICYgCQlDYXJpYmJlYW5zKSAgDQ0KQ29u dGFjdCBwZXJzb24gbmFtZS9lbWFpbCoqOg0NCg0NCg0NCiogbGVhdmUgYmxhbmsgaWYgeW91IHdh bnQgdG8gc3VibWl0IGFuIGFub255bWlzZWQgY2FzZXMgc3R1ZHkNDQoqKiBlbWFpbCB3aWxsIG5v dCBiZSBkaXNjbG9zZWQgcHVibGljbHkNDQoNDQoNDQpXaGF0IGlzIHRoZSBtb3N0IGFjY3VyYXRl IGRlc2NyaXB0aW9uIG9mIHlvdXIgYWN0aXZpdGllcyBhbmQgdGhlIG5ldHdvcmsgZm9yIHdoaWNo IHlvdSBkZXBsb3llZCBJUHY2PyBJZiBwb3NzaWJsZSwgcGxlYXNlIHByb3ZpZGUgc29tZSBicmll ZiBkZXRhaWxzIG9uIHlvdXIgSVB2NiBwbGFubmluZy4NDQphLiBDb3Jwb3JhdGUgbmV0d29yayBp bmZyYXN0cnVjdHVyZSAod2ViIHNlcnZlciwgbWFpbCBzZXJ2ZXIsIEludGVybmV0IGNvbm5lY3Rp dml0eSB0byBjb3Jwb3JhdGUgbmV0d29yayB1c2VycykNDQpiLiBTZXJ2aWNlIEluZnJhc3RydWN0 dXJlIChzcGVjaWZ5IHRoZSBzZXJ2aWNlIHlvdSBwcm92aWRlKQ0NCmMuIEN1c3RvbWVyIGJhc2Ug Zm9yIHNlcnZpY2UocykgeW91IHByb3ZpZGUgKHNwZWNpZnkgdGhlIHNlcnZpY2UgeW91IHByb3Zp ZGUpIA0NCmQuIE90aGVyIChwbGVhc2Ugc3BlY2lmeSkgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQ0KDQ0KCQ0NCg0NCl9fX19fX19fX19fX19fX18NDQoNDQoNDQoyLiAgICBNb3RpdmF0aW9u DQ0KS2V5IHF1ZXN0aW9uOiBXaGF0IHdhcyB0aGUgbW90aXZhdGlvbiBiZWhpbmQgdGhlIGRlY2lz aW9uIHRvIGRlcGxveSBJUHY2Pw0NCg0NCgkNDQoNDQpGb2xsb3cgdXAgcXVlc3Rpb25zDQ0KYS4g V2VyZSB0aGVyZSBleHRlcm5hbCBwYXJ0aWVzIGludm9sdmVkIChlZyBnb3Zlcm5tZW50IHByb2pl Y3Qgc3RpbXVsYXRpbmcgSVB2NiBkZXBsb3ltZW50LCByZXF1ZXN0IGZyb20gY2xpZW50cywg4oCm ICkNDQpiLiBEaWQgeW91IGZhY2UgYW55IGNoYWxsZW5nZXMgPyBJZiB5ZXMsIHdoYXQgd2VyZSB0 aGUgY2hhbGxlbmdlcyBhbmQgaG93IGRpZCB5b3Ugb3ZlcmNvbWU/IERvIHlvdSBzZWUgYW55IHJl bWFpbmluZyBpc3N1ZXMgd2hpY2ggbmVlZCB0byBiZSBhZGRyZXNzZWQ/DQ0KDQ0KCQ0NCg0NCjMu ICAgIEJ1c2luZXNzIGNhc2UNDQpLZXkgcXVlc3Rpb246ICBXaGF0IGFyZSB0aGUgZWNvbm9taWMg YW5kIGJ1c2luZXNzIGZhY3RvcnMgdGhhdCB5b3UgaGF2ZSB0YWtlbiBpbnRvIGNvbnNpZGVyYXRp b24/IChzaG9ydCwgbWlkLCBsb25nIHRlcm0pDQ0KDQ0KCQ0NCg0NCkZvbGxvdyB1cCBxdWVzdGlv bnMgDQ0KYS4gIEhvdyBkb2VzIHRoZSBJUHY2IGRlcGxveW1lbnQgZml0IGluIHlvdXIgbG9uZ2Vy IHRlcm0gc3RyYXRlZ3kgYW5kIGJ1c2luZXNzIG1vZGVsPw0NCmIuICBBbnkgZmluYW5jaWFsIGFu ZCBidXNpbmVzcyBhc3Nlc3NtZW50cyB3aGljaCB5b3UgY2FuIHNoYXJlID8gKCBlZyBjb3N0IHZz IGJlbmVmaXRzKQ0NCg0NCgkNDQoNDQo0LiBJUHY2IGRlcGxveW1lbnQ/DQ0KS2V5IHF1ZXN0aW9u OiBXaG8gdG9vayB0aGUgZGVjaXNpb24gYW5kIHdobyBlbHNlIGF0IHRoZSBtYW5hZ2VtZW50IGxl dmVsIHdhcyBpbnZvbHZlZD8gVGhlIHdobyBpbiB0aGlzIGNhc2UgY291bGQgYmUgYSBzcGVjaWZp YyBpbmRpdmlkdWFsLCBjb21taXR0ZWUsIGEgZGVwYXJ0bWVudCwgZXRjLg0NCiAgICAgICAgDQ0K CQ0NCg0NCkZvbGxvdyB1cCBxdWVzdGlvbnMgDQ0KYS4gIFdoZW4gZGlkIHlvdSBzdGFydCB0aGUg cGxhbm5pbmcgYW5kIGhvdyBsb25nIGRpZCBpdCB0YWtlPw0NCmIuICBXaGVuIGRpZCB5b3UgY29t cGxldGUgSVB2NiBkZXBsb3ltZW50Pw0NCmMuICBXaGF0IHdlcmUgeW91ciBnb2FscyBhbmQgd2hh dCBoYXZlIHlvdSByZWFjaGVkP+KAnQ0NCg0NCg0KCQ0NCg0NCjUuICBFeHBlcmllbmNlcyBhbmQg bGVzc29ucyBsZWFybmVkDQ0KS2V5IHF1ZXN0aW9uOiBXaGF0IGlzIHRoZSBtYWluIGxlc3NvbiBs ZWFybmVkIGFuZCB5b3VyIG1lc3NhZ2Ugb24gdGhlIGNvbW1lcmNpYWwgYW5kIGVjb25vbWljIGlu Y2VudGl2ZXMgYmVoaW5kIGEgc3VjY2Vzc2Z1bCBJUHY2IGRlcGxveW1lbnQ/DQ0KICAgICAgICAN DQoNCgkNDQpGb2xsb3cgdXAgcXVlc3Rpb25zICANDQphLiBEaWQgeW91ciBvcmdhbmlzYXRpb24g ZXhwZXJpZW5jZSBhbnkgZmluYW5jaWFsL2J1c2luZXNzIGltcGFjdCB3aGVuIHlvdXIgb3JnYW5p c2F0aW9uIGRlcGxveWVkIElQdjYsIGluY2x1ZGluZyBiZW5lZml0IHRvIGN1c3RvbWVycz8NDQpi LiBJcyB0aGVyZSBhbnl0aGluZyB0aGF0IHlvdXIgY29tcGFueSBjb3VsZCBoYXZlIGRvbmUgZGlm ZmVyZW50IGluIHRoZSBwbGFubmluZyB0aGF0IG1pZ2h0IGhhdmUgc2F2ZWQgbW9uZXk/DQ0KYy4g SXMgdGhlcmUgYW55dGhpbmcgdGhhdCB5b3VyIGNvbXBhbnkgY291bGQgaGF2ZSBkb25lIGRpZmZl cmVudCBpbiB0aGUgcGxhbm5pbmcgdGhhdCB3b3VsZCBpbXByb3ZlIHRoZSBkZXBsb3ltZW50Pw0N Cg0NCg0NCg0KCSAgICAgICAgICAgICAgICAgDQ0KNi4gIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24N DQpQbGVhc2Ugc2hhcmUgYW55IG90aGVyIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uIChSZWZlcmVu Y2UgVVJMIHRvIHlvdXIgSVB2NiBzZXJ2aWNlLCB2aWRlb3MsIHByZXNlbnRhdGlvbnMgYWJvdXQg eW91ciBzZXJ2aWNlLCBhbmQgYW55IG90aGVyIGluZm9ybWF0aW9uIHdvdWxkIGJlIHNlcnZlIGFz IGhlbHBmdWwgcmVmZXJlbmNlKQ== --94eb2c0480e2829ca1053945df26 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="IGF2016-BPF_IPv6-CaseStudySurvey.docx" Content-Disposition: attachment; filename="IGF2016-BPF_IPv6-CaseStudySurvey.docx" Content-Transfer-Encoding: base64 X-Attachment-Id: 657a03e572fd08f9_0.0.1.3 UEsDBBQABgAIAAAAIQDrhSgkjgEAAMEFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lMtOwzAQRfdI/EPkLUpcWCCEmnbBYwmVKGJtnEliiB/ymD7+nnHTRoBKUyhsIiXOvffMJDPD8UI3 yQw8KmtydpoNWAJG2kKZKmeP09v0giUYhClEYw3kbAnIxqPjo+F06QATUhvMWR2Cu+QcZQ1aYGYd GDoprdci0K2vuBPyVVTAzwaDcy6tCWBCGqIHGw2voRRvTUhuFvS4JSE5S67a92JUzoRzjZIiECiP p3yrzkODO4QzU3yhS9dkGSlX5lgrhyffJ7y46kuA0rGyFwdVhLqnbnpVQDIRPtwJTeh8bn3BCyvf NJWd7a5tC6ItSyWh00c3560ERPpMusm6Ey2U2aB/y4Fh2QD+PUXru2f8kwr1TVmCpP+jvx8a01h0 1kZ80PanQQjUpH1CPv+1aV/Tce3cizCH54d/o/hg3gtS0jhNxXMDe3T8h83orHshAq0I4Kvr6cEc K5tdkTQZE28d0srxvyh7sxuiOqWRc+CDgm47bBuxLpH21cH1QVyIBRRbsvlqAY/eAQAA//8DAFBL AwQUAAYACAAAACEAwmCa8/QAAABOAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySwUoDMRCG74Lv EObenW0FEWm2FxF6E6kPMCTT3aW7SUhGbd/eQVRcWGuPSWa++eYn681xHMwb59LHYGFZ1WA4uOj7 0Fp42T0u7sAUoeBpiIEtnLjAprm+Wj/zQKJNpetTMUoJxUInku4Ri+t4pFLFxEFf9jGPJHrMLSZy B2oZV3V9i/k3A5oJ02y9hbz1SzC7U9LJ/7Pjft87fojudeQgMyNwWqFkyi2LhfeYPfqvxkqVAedt Vpfb/L0pjizkSQhdzLxIWXPK0muyP0Lq8qTX5bPinNDN5ULT5efi4aNw8OzPK1FK30Y4+QXNBwAA AP//AwBQSwMEFAAGAAgAAAAhANvC0IuzAQAA+gUAABwACAF3b3JkL19yZWxzL2RvY3VtZW50Lnht bC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFRNb9swDL0P6H8wdLcV Z1vSDnV6WQv0sMuWocdCliVbq74gsknz78e4Tes0TYYBvhggJfM9PlLv8urJ2WylEpjgK1YWE5Yp L0NjfFux38ub/JxlgMI3wgavKrZRwK4WZ58ufyorkH6CzkTIqIqHinWI8RvnIDvlBBQhKk8nOiQn kMLU8ijkg2gVn04mM56GNdhir2Z221Qs3TafWbbcREL+d+2gtZHqe5CPTnn8AIKDQqTOgGqK1Cqs 2C5TEE/GP6bwZUwKa1X/OmAxSJ4i8nVMIh2pmqzxD29ivEi8Xq8L47ENK5rco+vnJh3w5kVZ4LUC zGMSEknwvL8FfH5xnoOkmee0LnkbhIXcxNWsjno6KWc7mB+hoWleP6FKXhzVfHt9tLEfb9UJYw96 3Sad8NwaoG3RgdfxftvI/TtR/q+j+ZgdGUePaIdfMacaI3ifLIs/sT22yfSYx1NVB49LUdsBj9fU qS2+GJMEktMMCPQh77/lKQ7lmBwAN5Zs8c1T+vgU/PQIvDMyBQgaCxkcf/azrY/N962SPyPeGeyu tVYSD8AHRzsefM+xF38BAAD//wMAUEsDBBQABgAIAAAAIQBwkchEmxoAAJ+cAAARAAAAd29yZC9k b2N1bWVudC54bWzcXdty20aTvt+qfQeULrbslCzhDJIb00uCoH/vOvlVclK5TIHgkEQMAggAipav 8hi7F3u7D5Yn2a8HBwIgKIISaClxJTYJAoOenp4+fN0z8/27L2tPuGNR7Ab+2wvpSrwQmO8Ec9df vr34+afpm96FECe2P7e9wGdvL+5ZfPFu+K//8v12MA+czZr5iYAm/HiwDZ23F6skCQfX17GzYms7 vlq7ThTEwSK5coL1dbBYuA673gbR/FoWJZF/CqPAYXGM95m2f2fHF1lz66Bda2vbyRuWRbF3vbZd v2hjn6IgZD7oXQTR2k7iqyBa4ono8yZ8AwpDO3Fnrucm96BP1Itm7t5ebCJ/kPXqTdEremYAAgZ3 ay+/GWQfvjflwCD9J38i2utoA5HpI5OM5Zy864h5IDjw45Ub7vj22NbAj1VO0oMdLnV2G0rq3vsK 9rQZ9ElkbzH2+Yu34V5zDcyYpw+tvZQPJFA7Maq3KIktRoSaKGhoQ0L1nTklZeHbPo41O0nahpiC T5lQ76NgExa9Ct2ntfbB/1y0RZrgBMpEnU/1ctfikxrY0xWfVnbILoS1M/iw9IPInnmgCBwXSCIv htBOM9v5vAQD/LmwHTiBF2CaTfmfi2v+ezC/p39DAY8NQjuyP8zfXmjjkaL3e9CCdDVhXxK6amR/ cHUATTm/fXshiqapGHK/uHSD9kVRMURZkYuLE7awN15S+oW/8ibi/3xK7j2GJu9s7+0FerG2PTEl 7jcnv+xAwbKIrl6D1vTBKCej8k5qMkpvmKW3Z9+S4Yf3UwEKVxfeCGMWJ8JNZDsJVLEwDaLNWgh8 4cPNnU5vSPh7QB69bZ89siEpqiJRB//i7NkOXC4G8dec00rG+/irGVevgRcFK//8479/9uewl2QT obiEZMUEmIE1ixzX9gRcFZgT+AG0oOD6NHzuHYuFGVu5+MkW4o1D9m6x8TjThTkLveCe7Oiff/xP myHoQ/QsE8ap6yHIBLqNhOay2Cwl0lTsa5oxesEkqqosTiXpDCRmGqANF7eDjue5aXueANdGMAM/ idzZhnsHLYRKsUxLNcfmCx4xcazL/Yk+7p7EE0Ysl3sohIM6GOoWyrRR0XIdvA023lzw3M9MSALB yYcMOmM3ZPQLLFemZriOKZTKOoBG4X4fH2r+sp0SuWox2rqkTCZyD579y1UhY1Meycq0exLPM9pu DNWeMGfluxhRAd5oEsDpEDAF+ejNmeNSiEUDa8+DMEmVPx7zgwQG2LuvPI9Q61IIYFqinTFZwGYH USyEno2bfcFdh0EEK5QIUeCxNuMuqRNDlHpK90ztznQYumTKotE9iecZdz6WNK4YSRpdOAORGzM4 WsW4uunl914wg2T8iDFbXXK5sL04gIuAgfc36xmGOlhQqJ3AW8ieiYMNyYAvIJp24xAfqWVyMegy E+wwZDZEAkI1Y1ApSQJ/0gmiPDCkH95PbvgTpCeuhH+mxKSitUJLl/ljeTSfahb2xY0TNLyyEzxt e/dfQRX1ruzqxCFzcBPI5koo58WlwOgXeEOQamLDzI7ZnNjDLwMDuBTCIHbJMYL+i9EymsifbiXI pjZRTdXqXko6E2RVVjVRsf4KCmx8T6MaAveAO0vjASnczF0aFh+CCmgG/mo2UBX3NtdImW9bEQLB Jo04o2gjzKKNWMhljBsukqYPFNz4LBHeB8CgfBv+chaTvELM8prmAdnMS8FNhK0L5waK9c6dQ/J9 IQhJ/218oDW8PRt34JfI9pcsm0qf2SrwyIrW7ClRijZ9x0M/uQ8foNeYbIjtYJVB2E6Vk8Dzl1wJ P3H5L5tpThOm3tyNnU1MUj67FxBLIrhyQ6jmdHIg+uK8aYi9LvnczJuJ2MLDlEIzmQIASSEsSMG3 bT7toyCMXKiKlKi924hVICvczDw3XqWTj/MbpGzZDHMPLFyA9wLYnHJ4u3KdVcpkPLli8FEWUbAW 9Dd9YcIcxjUUd2BA2/uNDUDQ/g1R86XwA5SFE7SZt7o5Vsd96SXPW92UrbEhn8ET7twAjeZz6NAA 2lm4ZQvYA8yeuIX7pxmKNtUmz4txtPKkCQoexKHtANwJIxaz6I5dDD85gAT5vHkfwIbSXCfZHt9M hUrvgWBEQbCwogi+enIfopFlZK8/JZifKcxCP3A8Zw9IyZx4rn3aNGr586NNNvdmUCW6OaJWTVmV TEvq3uDpmtYbmRwxy9Cl8BAstRuyFZgZwVx8FqKBC3ws+jDXeBMFQ0uI10EeZ5gKx+ZwE0fBJEnT TDNl5Sa/SMkBj9FFkFAgMRn+uN1ur1w/WQZ3CHw3a47oO+v4OteZ8TUZoTe5EXrD74qvjX7vTUyC 9AYm7c2SBOmNG97ps3BBSq4y5nhr0WOOsuVdatNLnh7ZF+I2ow4/WDV76hlC3s7cHGWsqGNt+ryA 4E4wC/lrmND/GWRGlRQFt8fcmpFHE7tL/80mJC+BNMks/JVE4T9KYiUA2ef+EexpMqhLRwNSaoiK OhGNMyjZrmas/lwzlli5N2Xp4tr2r4m/rr8IrrNB+LU0CDS366wvTUwSg33IWtHkiWYak+5VZ2eT SNd7uiQZNTxGs6b9nsYhyl3SIRv8XAGlYl67WEo6VH+5IX21Lz5kYMkL3g4g4TCSskpSy7/cbiiv Ym+SILNuWQJiCrCKQHI7dlyklX5y10gL4zuz42QUu3Z2SfiRbYXbAONKP65Gfly+2UEOiD9Zuo1j 8hWLsHv5DqqXG6D69FpuIA6qhFL3M0sS5Z05THzV8jTbcaRShHUQMbjuMDFIphIqgP9y1ySNjnjo Dqzg9w2MEu7wbTcC1BN6eDkF134ClKdqGxrcGMTRnnfYj+mgj8Nf3HVlqh2i4pDj0wENzXx+CcyZ sCX7yrwag5A1K9yTk4Vq6LFac3vOKx/1Hb+f9LZLShHESE0SfkjpQTKKkFaS0mokh0xqEHymGgku cJjH5PFxDeHba2iHX98HY+RaUwWR3wsyizv5nI7wteRqfzPxeNqgvDo2JvWA4kmDgpIZty5Ue1JA b+xGCJrnVy0eOTTvz6t9tvN0hn3TSdHMDwEIaE0Kupfl4Txa313N6irgacL7ukJ2s3ck91TJsrQa IqOoPU22RLq6cz0ydye/VPGw84sl16Mz70hUdRkekgpiOq456IxE1RKV3nh0Bh/zBNDoydlkP7gh vKTi7GSVVlBr4cD1yT8krDP5CaWCkqqIMAP0dVz9+rH6FdUy+c1UnTMAyrsKABmgrmakwsHlQ0s/ MOBZdFntSYYi9ScUoIQD1OBQkaHz5e2Fohq6LmsXgnP/9qIn9ukzWRfctFgAOLXSW1FNA8IS/jdV 5VwIM/o7vRO4wE0kkA0DmpJaMHdtL5koXf0Wog5tzmIHD7nLhRcsA34tfdD58e59ZIeASadQwewm wmV7AHVMl0h3oAYSjm+tLOp49RqUvo+eFk1N7MQWNtF+tdbxpkLXSTYRILLv8WmA/zOy8OkRhFVb 8+9uXHAubRq8yJgI5rZmIhoc0JPUDpB8wixveQnjHbtlsfsVzgQfpWu6sfI+wNjhFKA2sYk+A3ci QBqDCDkyaGTtQRw5t5CB9HMSscRZ0eUFHsuuX+Om/Af+jl2z9MaYA2D24MsiWtOTKLkUIHToIaSN E2aTMD4kiXhD/nSIEqH3DAA6fQCdII2Psn33MSYicWt+C73M8+najgz+EV/5jZmQkWSUv+NzMS3p 86CYrRQG8SsNAbHRl2TVMtGtZ9SnDyurZlulWroqydMzVD6doGWJtGNVeDNyEFLAOYRmIfF8cEBg PFTROkPO+wQD95gBUZDKsUTj5YN/WaRPFX80EOn4HQBmKY5nNlJhMWYsxfCv2BeHoWAj/y69ppie An1KkLIjzmFJtLL3zkBFXn14BOL+zO4LpIAoL6oz0Ync5ar4YdTyKZ1FT+DebhnsDZKm98GGIFDb j7fIDCKBi6wrOjkHROEkyOUT4o9cYoaSlisBEO0V9Um7oserCs00c4i+asGtgVJByNHfS4Z+QVUv r/LaMg9sYsJig6oP8HTOEoR4yIyDYaUC5TJk9Mpd0ECgGBQiRnXNxG/KL3vIUb/maXU+PiR8HFxa BJ4XbAXA1zmoFF9VhbKZ87IxHuu9/hlySieoHSKNpmMziajGNjRVP0MytjMSlYlm9ZV+DbvtsGA8 m+ccuy0pk8Zk3T+YTfUMMlkcKnpHdcWXZGN7nwqElyfZUierMGQ5ZlPGd0gqBqljt7rye4Eksjt5 cx+GdB347NTlXg05EfT1I3DfzEfa4UU7DEhKCTqss5KhdCW8Zz6LkMwuzYZWCkQTpwhXQUnH4eEx bpcq9nMxfkgvH7A3PyKWoBR2pasYGwrFyqnrI5hvidhk+M9oaftuzDHoVu3uAKVM3G73zMoB8gWY S9D6GyzEdzXoqHlO6xNN0VT1DN5OiQWNs6Ob8TKxpCSJ7lv1VREnmqQjkH3xsjm8ZUs4O9XM5oPS bJMfgyGG8n7ovlO8kVejRYTy2UuBUkjCDbJSvFbQ2qDaCUmSH9z5HObQgq65TOsohRGWXfAnKlLe LHhGfyJhNJ5XUcDx48i4xxZQmIbMFeiClOlHnnujKylfj0YZp3D2I1SBn3NL+Dd7Hf57hwqnmZKh aWMJwozBnayMziHd1kIHNb+oGbd9Xe/gA9anuYVqA81CpVsyypW1M5RUd63Nhkj48OQiSndiuI5k 3K95xuG776rTvrmn8sQSp3of4FvXdrYzX0we6aIhqWdwFzsejFPk+LuqGDbMHsoIHU7HlEhvfi0y j/ZdPfOw537QSzqeocLMs1FClsY7wpYykQh14s1sjbgTBb6ttMZTOm77gX+Pwno2b/Wqrruflr5T rfV95f3N808DQiT3zFqmpsNAg8fmKTTSogTwsDZtlrJmFfvd+aX7EUnVgz7wKV1LS6n58oe0Ppzi 93laku14bUZcnUqa2j9j4ivrZ6vQssF5bpZTwxrL8lR9ybACTMR4YppnWJvRmSnTx5bct6aj7q1t yR4ci5JyZxXrhJaAFZB/00/1TtvVwQAz4IjFrsILi/izK7vF2Ok1SF02DQ9FpBVl2iI2OSuNp4VJ p5GycpcrD/8DwU2rp7GGIynSDRnKPfyFIF7AuFSItg6wHsd2nE2EtSNpqtMN00o1jjpGp/IuHbdW hDRbAFCDdWBYx4DlRoSKEpVYEITtNT7zVT3pshRCptM1rlChVKP0TviwoEVksQuEtKifg9fCVwfF hLnOIpctCsQVHi8awXoXPExLKH0fEt0GoNan0/7E1M4H8HVld5OhfYWqrgiromhwcyYCTYsQMUcb nhoWXmH5D1IZWEgRXfKi5uJLsRYLuKFPuQ+Myj15ZFhQWGtzgwbiNuUl2rRnyLL8vGqM7FQ6GQ47 LclwdiV8AltoV4wPNZYBegMUAV5ANol1dA9JZCZurRhhKXoPK9ifVZ+3YkTzNHUgWps4wbyK+HJO PjczXryKX5fZIbw6xq+qZ9/sRuiTniVZvfFflWFzrLXlKZ9XWW1vxpTXwgN/Ktq3mS/YYkYfyf0z AA4n+C7HHINm0tWxaIzEc+zgcHbSDWskTfvGyw++Tiw9kHVromG5U/ez7PxD0pd1STbOQPoxD7m7 LBuZgyLLlsxE5zM2kPry+z3Pvp2cZcvSftHB8DUZylWPp0PnuBvXHbqxogMfIjAZ/lDshFJ56ID2 UftTZSy9fD+uGWQY/lepFqSK1z7IpGZz3p7LGTXk54OveeSVBhVblIikUUWxI022FQBdLW95kvru qefeYqzk8Wg00SYvOUDXlMm4jz3gTtec56iRlvsqYBeljTLMtFuuJErUHNN7rSEgdSwZxths46PU qKlknc9JIhbXKePpORZUP4KLD03gA9pgul/002JeobBaE9Xpy89HZ71uB4eU9RJC4F8qjHiIt8mQ yvjIS2cCVZljAxLsMEK7dwCMcP27wLsD3HB0DdAplRmsuoC1IZvDW2uRajiEfmEhPDrC9+XN6jKw nYu73tBWsVjkyfGP3XZhl0LEeNlYutmH47motT+ar22dcUqGl8Kff/yfUA2RG3pdSi81m2+9r09k Q3r5ontgXAAvTNw5j5OxbQ5tX3FfN8KNObdW+a1k6Kyw2xLDzjex8K4m/43NPkHAALxhE+hLYZuW jqYzSCgRQDDeChWJ86y/JJBUBflOmAScATFL+x9RboZwuC454cYx1taCOmxnc2ZO+Cythp2hO/M5 9idBgqfK/WZZlsY9WZ/KZwCDToi6iLTDlZeGZlkKFoa9DPdGnVpTU9NeiHujmAYWUIzagAHP5d6I WNaHDdIeMXxP9cC6C47JfSyCY20liXNsdfdF/pLQ9ZODYyXNJ0W5U1npJ0HwyVD5WwXH4/LGbRVF 2KyUVFMyRuNz7JPxTTzi5ji3EjTXrcxhWTjJ/dwOusE+KmP0kNuaUdcYktuZOS5WY/CVBrko5Bv2 8VUflMFYofJHSOzPDBtY+jzVgy06sGEerxx+d9z1be0IHqA5xkLQpNbxx/orB16BLJdLu1wGtM8f i9ZVV/TAXFCk0Wg8etEGWlIMZWw+Ij9Sivg7cxd0azoxpXEbhtVMYomaR+iJ5uGTjKk57o/awEc1 aipWITcV5yARzgyOD9BU2LKXvWohm1Utl87trUSq6tzm4VKUvmL0R48Q5TMM10OK90BoB8yhpsL+ qpblQAf/QcFcgKCKYN0agCAsaJFgVlxRY0OjJm8Z0JK+Rq6ZNHabVp8Qz6I2AvUSS9pTG4vyclO5 DubMaxPMKePRVBuLLz+vcGBwAUzUGPw3k94RkJaFS3sL5+dzFINsI2KPY8LKMsCAwxNOi9rj1o5P MoxX5JRVRelhBOwROqg+hk+Yes2e9KujbzgnDNrYnSfMeYfq4Gpiv/eOUzp0dxQzfSquO8PqSOja dmVXkqqKxjk2n+zMY1T6EwsnCT3C6Jfcsc6okSxTAsfoNKdj7ljNYyxR05n/augTRcJBCKdTcwaH qNlnk7Dv60QatUnxZYOUe9NPJbE7gImc7wJgYkZ8Ly/t3yXsiEfXTwaYsoLlqLGfKcCkXtW9p6pV aGa1pmpjSZPbRDMds7qU8D1W8fWQyWoOzE8rjG4Vf3wbtGcfd8GuwdgikXvHRdEDOZPbVSAwD/t6 ogCb10ngJI0l46k5j90xD2uednnGqiiczs9ms83PLCA6+N7HqALn5zs4fHMKSlsUR3LghjkqfufY LeCSH/KBw0QYKqttqrtGSpSovjxqMlu7Rc0yMcSmTXUQds8sH00Vqpraw4Y6z1t0/JQJk5TmRrNO EPtTS9OtNtbzqL3KFFbHq4AmWl9CyuZ0E7ZvUM9CoGaNxIna6gC4GgdbGrDzUI1Y08S+dy3Y+qJt wcmFHaUZ0UI1tmseU7Ra1dasQhtKbap6sHmKyiJqhieTNi7l+YaKSDu+9MGu69zDTkymt9syuJvM CFXM14K1wxQmqE1EOiMvPojptA9uffNFPxznofoEnhKg+4BgUQ6kaoGbR1UTe4Yl820bjgUKzz2q s7/xqKKcBMsqsMqphka2GULRmI5Mc9zGdj7vEHpYtnXL6BRINr+B4ziOmP2Zr4o8AOVhkc4JEyWb yq3W7mX1vlQox1fR8fNS+ETiVUA8jUj5RFCIk9/n7/78438rE7Z5MinjnjlRxEcEkftOQptVdC18 Mh6olYxNM+Gy2jOm8rQT76YLwpupFK2eqCNKb+Es1Fyc87C3mUrdGvX0Hj9I+5hGfUYq1clYnJit dnKqUdnSXTyfGKDk11R19Rkcke6gGpppBVSj9mTj69x3QiO4o+snQzXpptEPbKGZDLWXbjwr6vUh lzgZWl+w5Q/qenE6HFfZHnIeOPxBwL4vOHuxuvdJ8xzFrruSONKtFprkfCazhfbOYq7bypyjmdUM N5T0/EMczB5uFSw8CwTVHLfwdf81MWkEU1plZDMmtHX86yCZezQ/UoJ1WgzGI+lo5lQGzgEiS6dG PjP4bOH+Do43iuGB5Vuu1rganSh3Q7ivWEhd5COLYq3d1rk4vXNFO8UBoNs4mLjxYuM9xtnFOfd9 S9b+xuDxAY2lTSwcIC6frrFKvk9Vl3ULkOFoOEXut8p/1RyKEoHVX7olUJqq5kh8jMfzjQjU+tgd 2Oy12Ui0yqfbinnI5+43olpH7CCPeubpgtmS6jaOJM2ZY7DQKVbvkRCZqPU1afoXWJJLW6ucqvPb WSiMRMboAzH9CcBXs3HLVh1F9Yb2XIFTyh1wEOM322CYFe4r7HGplOe6KONx19jfGpsgEe7HzXVt rP4yXa1scVQ+oDwr/uC78WTbsMRtsC5Vneh9VWmjI6vGrq2O7Erb0P47tVE76lW1m2FdleefAq3h 9GheLAm4DCKbwJND7Tktl+PSSeAlSXKaheXY2ZwOkpi7OMQIp3jzekrKFxeINX92zXf64rfHKNuf YzMvn923kQJUAomTkfzyEU+sY3z5UlBXpIfl9CxikB4sAZWHvc744uVsYzRK0LcSBmwt2B+32ke0 5jbte0inzP5mPx25TBPFLY/I1ZeoyVTX06nBfjLqWG51lsA34I0sWf2RaLVJ9taoOYOr2Dx80si0 tN5zhJfdYYvE3wJb/E1cRctgNV9pyu90/WRsUT+2zjBz99oZry7dw6GO9NBojjP2sNE/NjrALnf5 OcUVy9s80kYfCW2z97wQIJF2LG5JhjfpYcpp3TUZ2oC2eKAl2nnXSyeMXAmvbukgOoJHhZ9vP5KL xa00zyxmO9xdCrStZIBF7zi1Loai5evjgKbOgk1m1Is7qfBr99LSm7IjgVB1RffCM4iFFfNCAnb4 UXhEQZvFacZUmk6tcZu0zok+XWd6VOxjKSm2FsMMOpbTeS4SVcXs6cbkDD7RE7hIR4zhaETEhFiF iWMzRWwwpBg8N1Y+PDnT9tzeLT99xf1bOmKzL3JVtsJnvaf0UkUULn+wqcUkCHEdZeGk1SJyJXdf Z0GCnR1339PDKfKbVzhUiOFEzPywiiDAopzi63KDOkF85RsDY3ouf9ysf7oPcQAWzlpE6QVaTQmB JqUT4+mweZzzuDvnIu3zkFTQLJjf8w84o3ND/szw/wUAAAD//wMAUEsDBAoAAAAAAAAAIQAd1FF6 pkEAAKZBAAAVAAAAd29yZC9tZWRpYS9pbWFnZTEuanBn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBD AAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcGBwcICQsJCAgKCAcHCg0KCgsMDAwMBwkO Dw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCABVAW0DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAA AAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKB kaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZn aGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT 1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6 goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9/KTYKWvlT9qf/gpPZ/D3wNInw/08+JfEOs6r J4e0Bypa3v72Mhbho1HzSxws6IWBAaRtoJ2sR3ZfluIxtVUsPG7/AAXq/vfom+hwZhmeGwNJ1cRK y/F+i67perS6n1SQM4/KmXl5Dp1q89xLFBDENzySMFVB6kngV86aP8Q0/Yk/Zy/4TT4t+J7vxN41 1tQ9yfNRmuLhgWSxtI1xFHEmTkqAv3nZsc1la98Kz8TvCcnj/wDaJ8TWVh4SjjW7tvCVrqHk6Jp8 f3kNzLGQ17KeMjcYyeFVh17I5QuZynP93flTSbc2t1BaX9XZd7NpHFLOHyqMIfvLczTaSgns5vW3 orvtdJs7zxD+378L9L1h9N0zWL/xdqUb+W1v4a0q51baw6gyQI0SkehcGsSz/wCCinh6/wDEmoaT H4B+LbX+lRxS3sA8MMZLWOUExu6B94DAEg47VleE/wBpLxB4j0lLP4I/BS6n8OxgJbarq5j8O6Y6 8gGOJl89k91j/CvEZvC/x78c/ta/FGLSJfCejeIp9J0htatdL1qe1DxbHEKw3b2zurbQ27CryRhq 93CZJhJc6rR5OVX96pG/xRWqirx369bHhYvPMXHkdKXPzO3u0pWtyyfutu0tV06X0PqbwF+3X8L/ AB5rsWkDX5NB1qVvLTT9fsLjSJ3b+6n2hEWQ+yM1evo6yoGUhlYZBByCK+Rr/wCOOkfDv4Wp4a/a J+GviLTtDtIhbnXtX2+KbO+JY7d9xbo0iuScKXjU9Oh64nw6+M0HwY+GN18Sfhh4iuvE3wd0+8kt dQ8Ma1fKbrTow4Am0+aZvNXggi1nO4gkKA2M8Vfh9TV8PFrWybalCT6JTjpd9n85Hbh+IXB8uIlG Wl2knGcV1bpy1sv5l8o2PtNHSQnaVYocHB+6fenFARXyj+0qda+Inwy0n42/AHxEya9GiyXFiP8A j38SW3Rraa3kwPtKEYAIEgwyZDbcdP8As0f8FCdC+OFj4Pj1SzbQb/xek9ra7mJh/tK22i5smyAy SAMrpu4dWxncpB8+eRV/q/1ml7yTaktpRa1aa7WTaa7O9rHowz3D/Wfq1X3W0nGW8Zp2Safe7Saf dWumj6HxzX5mfHz/AILS/EP4S/HPxj4YsfDHgyez8Pa1d6bbyz/aTJJHDM0as2JANxCjOABnNfpp X4EftmH/AIy++J//AGNep/8ApTJXFgaUKk2pnncWY6vhaEJ4eVm2fSh/4LzfE0n/AJFPwP8A983X /wAdr2n9gT/gqj41/ay/aOtPB2u6B4X0+xuLG5uzNYicTBogCAN7kYOeeK/Lmvqv/gjG239uzTD/ ANQa+/8AQUrvrYanGm2lqfI5Tn2Oq4uFOpNtNq/3n65+O/H+kfDLwZfa94g1O10jSdMhM91d3MgS OFB3JPqcADGSSAASQK/O79pH/gulfNq9zpvwu0G1WzicoNa1nLtP/tR24I2L1wzsxIxlFrzz/gsZ +1nqHxU+O1x8P7C8kh8M+C3EdxDG2Evb8qGd39RGG2KOx8z1r41HA/zxWWFwUeVSmeln/E9ZVHQw rcUtL9WfQOsf8FU/j5rl203/AAsK4s8n/V2ulWcaL9A0TH8zVzwt/wAFbPj14YuQX8Zx6vH/AM87 7S7VlbHbKRof1r5+8O+GtR8Ya1Dpuk6ffatqNySsNpZwNPPKQCTtRQWOACTgdAaj1bR7vQdWubHU LO5sb6zkMNxb3ELQywuOqsrAFT7EcV2+ypbWR8os0x6XtFOX3s/S79mD/guJpXizVrfSvihpEPhl 3+VdbsJGlss/9NYmBeIf7Slx67RnH3zo2sWut6fDeWdxBdWt0iywzQyB4pkYAqyMCQVOeCODmv50 P/1H6V+gn/BEr9rnUbfxbcfCTWbyS4sLqCS/0DzW3G0kQBprZM/wMmZFUcAo5GA2B5+KwUYrngfY 8PcT1KlRYfFO99n+h2H7bf8AwVp8d/syftL+IPBej+HvCd9p+kLbtFPeC485/MhSQ52yKvBbHAry of8ABer4nEf8ij4I/wC+br/47Xlv/BWf/k/fxv8A7ll+P+iRV85VvRwtOUE2jxcyz7H08VOnCbST fY+3/wDh/R8Tv+hS8Ef98Xf/AMdoP/Bef4nE/wDIpeB+v927/wDjtfEFI/3a2+qUf5Th/wBY8x/5 +P8AD/I/Xz/gmV/wUJ8U/tr+K/F1j4i0fQtMTw9bWtxA2nCUGUzNKp3eY7dPLGMep9q+tdUvf7N0 y5n27lgiaTaDjdgE9ff15r80P+CAfPxI+J3/AGDtN/8ARtzX6V+K/n8M3/8A17Sf+gmvIxMIxrcs dj9KyLFVq2XqrVd5a6nxh+zT/wAFjYv2i/2gvDvgRfh/NpLeILqa3F8daE/k+XDJNnYIBnIjIxuG M96+3Ayg9QPxr8Qv+CZhx/wUJ+HP/YRvO3/TjdVf/a++IHipv+CgfjLTNN8VeINN8zxUttbeXqEw htSzxhSIw23aGIOMYPTmt54OLlaHa54uD4kq08N7Wv7z5uVdD9rRMpPDLkdQDXiHxs/4KF/Cn9nb x5ceGfFfiKTTtZtYkuJIFspptqOMqdyoR0H4V+X/AIU8a+L/ANnT/gopDYDxjr2sXeleL00u8u57 pz/asTTCN/NQkr8yueOxPHTNZX/BTLwNqvgD9s3xrBrGtzeIJr66fVYJZQwNta3DvNDajczfLCjB B0BCjAWphglzpSZpieKan1d1KULSUrO5+3ej6tBr2k215BJvt7uJZo2xjcjAMDj6EVbSUOThgcel fld+3N8XPiD+zL+yr8JfhhD421e8vtYsLvVNV1mJnhuL63eVmgtdxZnVY0mCHB5ESdB8tfN994p8 V/s1zeAfFfhfx/qv9qeI9GXW5PJvHYWcpmlj8iVSzLICqKSHHcjAHJSwTkrpm1biqNKoqUoN2Sb1 7227n7xiRVXkgUnmqAOV9K/Lz/gqf8ftc+IH7OX7PXi2x1HUNFuvFOlXOoXkWn3ctuvmvBZMykqR kK7OAT/WvJv2FvH/AMQviB8U7VrvUfF2r+HvCfhzXIoZ3ed7exeWzuZRvl+75rPJwzHdgqBgAARH Btw57m9XiaEMT9XUG9E7+tv8z9m1kVm/h/Ol8xWXIIP41+En7L9544+L3inVtKtfiD4q0jyfDGo6 jNMNQmlaeOCDzPKAZvl37VUt1Clvofdv+CKnxp17Tv2hdZ0G41bUrvQ9S0Ke+ks57lpY0mhdCHUM SQxDOCcjIPOeCW8E1FtMywvFcatSMHBpSbV79j9ZJZFXqQPrTC6pjketfhzD8UvFX7ef7Ql5N4n8 caho0Go21/f2ha5Mdpp8cNvJLDAiB1VQdgTPUkliS1e6f8Eh/wBqLxp4s+IerfDDUfEeqXGma9ol 3PpMl3MbiXSbtFBBRid+3azEruxuQEAEk054JxjdsKHFVOrX9koNJtpO+7Xkfbcf/BSX4RSfF3/h Bl8Syt4m/to+H/s32CfH2wXH2Yx79u3/AFvy7s479K97R8j2r8CbD4b61/w2Kng4eI7qPxIvjg6I viJQxmW9/tAwfbgN2/d5n73G/dn+IHmv3i8IaTcaL4Y06zubpr64tLWKCW4cEGd1UBnOST8xGeSe ves8TQjTs0deQ5rVxjqKorcr6GyOlFFFcx9GFFFFABRRRQB8+/t0/tFy/DnwjrnhXR5fL1++8Hax rRlRsSWcMEaxoy/7TPISD28lvavkn9mnRv8AhdP/AAgfhrwLY/2fa+EPDyab4j8c3RCro8TM1xew acrcC5kMhV5+WQKMFQuT1X7a/inS9P8A2+W1PXNSmg8G6x8PdU0u6uYMF0RDPFPHGD1k8wAKP7zA 9KpeC9N8Qal+x9rfio6cvhSH4gyWfgLwJ4etvu6Np17cRxSStxlprjcWaVvmIUHOCAP1TLcJHC5b TUNJVOXV7c0rx2+04q+myV+a90n+UZli5YvM6jm7xp82i35Y8sr3+ypO2vxN25bWbXtXwli8OfEL w54k+Ofj+C3i8BaXplxpnhLT7uPzLew0KNSklwYzndLdYOMgsU8te+0eP+DvDy/s93Hhbx/8VfD2 rT/BmSSabwxpF5dSah/wr8yuXtjPb8mYyLjaTvMBYKMYzX0B+0T4Ms/E/j34OfBSxXyvDvmHW9Wt lGFl07TBH5UL/wCzJO0II/iCtXP/ABo8Z+FviR+0T4j1Lx/fWsHwq+CNrEktrcAtb6lrVxGWJeMA mUwwMqpGAfncnBIGPNweLctk+Sabsr3UE3CCh/flJu763u7qUk/TxuEUd2ueDSu7WdRpTm5/9O4x StHpbSzjFrc0nXPjR+0/ZLq2m39r8FfAUy77N5LWG+17UIMcSsH3Q2yMOQCC4HJxXkHw4+Fkuoft o/EbSLH46eKrHVLfR9KaLWRfWM02pSES7kaNozG6x9lA+Xcc9a+e/AP7XHw8134lXnhTxZqvxDs/ gLZXElxoegRXbt5ZYg+XcPF/pDW4O4pEHIQHHNR+EPjp8Gdf+O2rB/hZ4X0jwT4pjs9P0qbU5fsl ppH2eVxcXgkiXzVeRD/CQ28KGPJNfQUsgxWHVWEabjFx05acduaLs3J3nOyfNFtpdHsfO1eIMJiJ UZyqKUlLVyqSTvyyV0oRtCDbXLJJN6XW59N/tt6p8Z/hN+zp4g0vxnH4f+JngW+UQ3+uW1qtjf2d uw27p7dfkYq5R1khAw0YDKAc18ofCu20L9jT9q7RLTx0NQ8SfCe+uIdZ0i+JZdO1LdEpttT8pcpN 5QdlZeoOTj5QK0h+234V8MfGJ9Pvz4y+IHwe8Magbnw14ev70HEgVAJZ3lBknjV/MMcUrED5Se4r 3j9nPwt4L/aE+JfjP4bTXema98IPGdnPrnhKKG5IuPDdykqfaLWAOuYpQZXkwpK4Q43LnHVShVyz Byp4qnaEk3JxXJdO2qV/dqQWrSSi1dK7jc5Ks6WaY2FTCVP3kJJRUnz2avo3a8qU3ondyTs2kpWP WPjV8PtO+G3jj7ZY6hPafC742SJaahLp8uF0PW5cPZapbsvKCZgFYghTJ5TdWOflL9qXUvEnwt8L X/h3xfpNrp3j7QfFFt4o0fxVpQC6f4oubceVKzKvywXbQujOoA3mIZXJ3N9SfBb4bS+Of2Qvif8A BHVJZrm8+Ht5eaBp07HExgVRc6bLkdHCNCQR0K8dK8Y/aR1zUJvhD4L+Ld/px8T+AvH+iWcfj3Rl wZLG9iVIxqlsOscqONm9cAkIr5DDHj5JW5MSqM7StK19nLRODv3nBNNPSXLFaP3l7WeUfaYV1oXi nHmtuo62qJrtCbTTWseaTV17r+1v2fvjcnxU1Xxxos0iPqvgbxBPpFztGN0ZAlgf8Y3Ck92javxQ /bN/5O/+J/8A2Nep/wDpTJX6Mf8ABOHxMD+1R8e9dlu9+j+M/FUFlpEgB2Xcix3t0CM9/s5jPT+I V+c/7Zn/ACd98T/+xr1P/wBKZK+WxmBjhMwlShtaL+bim/ud0a5zmEsXlNKtPfnmvkpNL70kzzav qn/gjM2P26NM99Fvxx/upXytX1R/wRo/5Po0z0/sW/8A/QUrGv8AwpHzuS3+u0/VHgv7QOu/8JT+ 0D4/1QdNS8TandD2D3crAD2AIrkau+JpGm8T6o7cs97MzfUyMTVKtKXwI4sTJutJvuz7a/4IT6BB qf7T3ii9kQNNYeHmWNv7nmTxA/otcf8A8FnNHTSv25NRlSMJ9u0eymfaPvMFdM/XCAZ9q9B/4IJn /i/3jf8A7AMX/pQtcb/wWyjL/trt8pP/ABIbPnH+1LXDf/aX6H1sqSeQxa3ufI1et/sDeJpfCH7a 3wyvYW2Sf27DaF/RLgNbv+aSsPxryTDD+B/++TXe/srBk/ad+HbDzBjxHYnOMYxOp/pXVVa5GfN4 GE44iErfaX5nqH/BWY5/b28bf7ll/wCkkNfOVfRn/BWb/k/bxp/uWX/pJFXznRh/gXoPNv8AfKnq /wAzvv2WvhPp/wAd/wBorwh4O1S4vbPTvEN+LS4msmVbiNdjtlC6sucqOqsPav0ZH/BBT4WFjnxf 8S8f9fmn8f8AknXwf/wTrb/jOb4Yf9hj/wBoy1+6oIPvXn46tOM0ovofZcJZZhcRhpTrwTaf6Hz9 +xr/AME8vCX7E2t69feGdZ8Uaq/iGCC3uBq81vIsaws5XZ5UMeCfMbOc9B05z7l4q+XwzqP/AF6y f+gmr4biqes2X9p6ZcW+7Z9ojaLdjO3cpGcfj7V5vM5S5pH3kMNTo0fZUVZa2R+JX/BMv/lIV8Of +wjef+kF1R+1Xx/wUv8AFH/Y7Qf+joK9L8I/DX4Vf8E9v2u9E1zWPjK3irVfCV7cPeaTpPhN28t3 hmhMT3H2pkRk83kYYgoQQDyO48DfsfeBf2+/2lta+I3gr4x2Inm1uLXrnw/c+GnS+s0WSM7W3XKl lJTHmBNuXAx2PrupaXP0tY/M4YKcqH1VWc+e9rq9u54B8bW/42gav/2P8f8A6VR1v/8ABZg7f26N f/7BNj1H/TGvrTxz/wAEc7vxl+1Pd/ElfiNBax3fiFddGnf8I+ZGTEok8rzftQz93G7ZjnO2uj/b k/4JP2n7X/xYXxjYeMZPC+pS2kdrexS6X9vhuVjGEZcSxlDjg/ezgcDvl9Yp88XfSx3yyTGuhVjy 6uSa13R8uf8ABZgH+0/g238P/CJkAnoSDEf8Oe2a8n8ffDX4bfBf4KfCzW9R8MeJ/Eep+PtFm1O7 aHxNHpsdu8coQgJ9jlJDZ7sOgFfoB42/4JTQ/FP9ljwz4H8UeO9R1fxT4SnuX03xS9o7yLFK7EW7 wyTOWhVfLAUSgjyl2lRkHxzwt/wQu8Qat4i0uPxj8T11Dw3o6iCC3s7SUzi33l/KjMkhS3BZmb5Q wBYkAk5BDEQULXtYWMyXGTxDqRgndKz00elzy/8A4KMzWNx+xj+zFNpljcaVp0miXUlta3F19qkt 4zDZlQ0uxPMOCPm2LnPQV9Pf8E4LKO2/4JN3kiIFaa0195MD7zCW5TP5KB+Fdd+23/wTXg/as8F+ ANC0LxFbeCtM8AW81paQf2Ub5DC0cCRxqPOjKhFgA5LZz7c9v+zX+yJN8AP2RH+F0uvrqsjwahD/ AGmtj5A/0p5Xz5RkbO3zem4Z29qwlWi6Sin1PVw+VV4Y+dZr3XFL52X+R+U3/BObn4teIf8AsRdc P/kpXa/8EbQx/atuQvVvC98B9f3VfUn7N3/BGS6/Z+8XalqknxIt9XXUNAvtEWJfDzW7IbmHyvNJ +0vnb124GemRXRfsP/8ABKK4/Y6+NS+LZvH1v4kT+z5rA2a6GbPO/blt5uJOmzpt79RXRPE07NJ9 EePhMixsZUuaFrSbbutE7eZ+c/7BfwI0T9oz9ofw/wCEfEjXsOlX9pdSTG0lWKVWhtnlXazKwHzI P4Txmvfv+CTHivwH4g/bK0QaB4F8QaJqL6Xeyi6ufFI1GGJfK5zELKLrkAHzOM9DXsfxm/4InXUv xOv/ABJ8MfHp8IpqEssq2E8EiHTxKrCVYp4n3eWdzLsZThWI3EYFeufsCf8ABM7SP2KtR1DXL7Wf +Eo8Vahb/ZBdJa/ZoLKA7S0cal2OWZRliwyAoAGDlVcTCUb36GmX5FjKeIinFJRk25OzutND859N bZ/wVVGcY/4XAR/5XTX7gQPkfyr4M+N3/BFFviB8dNZ8b+F/iZeeFZ9X1SXW1jbSDcT2F3JMZ2ki mS4iZcSsWX5cr6kivtv4f6FdeEvBOkaZe6hLq15ptlDbT30ud926IFaRtzM2WILHLE89TXJiakZp cp7/AA/g6+FnVhVWkndM3VGDTqYrcdRTtwrlPpxaKazYo30AOopNwoBzQB+Z2v8Ah7Q/jrrXjvQ/ Gtw1mvwW8eaxrOqtkCa88N3s0lzLAnclpooU45AkTHWvQZPFfin4hfsofCvxdb2ulWGteLfiXaan p1neKy2FmjTNFYwsE52IkcIG3HTOK8o/bk8Gz+KfGHxD8d+EDIGvZbjwb430yHHnadci4UWly69f InjSJt/QNj1OPcPHF/8A25+zZ8SvCegDz7n9nnWtJvNMWJcZGnwWtw/uTviuT75xX65iWnSoTjs5 K6e0L2Uv/ApzUvONmtD8fwqcauIhLdRaTW87XcP/AAGnBx8pXT12b4o1j40eHf20IL3U7r4T2eu2 /gaWVZp2vU06KzS7JlYsSGDg7ST93aB3r5vsLW6/ajg8Yya/LpniDwlp3iHVPEeoS+G3nF3eahNa x29oYo2+Z4MoGBxhUjlyeQDxX7bH7R/xU8c/ETUbvxPvg0LWbG5sNFkXT1it7jSblo5gscoH7zcq Q7iSTlTwMmk/4JYfF6x+EX7XWnvrF5HY6Drem3mn6jJMcQKnlGVWk7ABowMngbj617mGyethsulj ly+0jBWUF2u3Z73tt2fc8LFZzQxOZRwEub2cp6ub6ysldbWvv3j2PIPBPhPS9Kv4W8aRa3p8dzaW 99p0Udvtj1JHdfmaQkFIGTd+8TJzjHSv0I/aH8V/Dr9oT/gmN4ju9B8Oad4G0zQJ9vhsajFHA149 s6Sv9k5DkyJ5iAkZbccg84820XwfpWkeIdE1L4heE/F2ofs02Oo6hN4SkbSzLLbJPJkfbEj/ANKW zDNI0S45yCQRgVwn7QPwDj/aA8cTaX8F/Ea618OvDFtE+n2WueKEiQSsN1w1kl04byokdA5bG1lc ZY4Fa43EUsfiqNSpJw9nLn5r+4rP4XslPbmTvy3lqzLA4erl+ErUqcVU9pHk5bfvHdfEt24b8slb mtF2R8nV9ZfsAP4k/wCE1+GUfgnWfBP/AAkb3+skW+om6aW0H2X5luEDhTGy8x+WASxbcTivK/Dv wlez+KelNqlro2v+DNH1CC0vNUsZ1m0824kDzedLEFdwq+am8gbtmVLJtz+if7LPgTwJqvxb8UfG bSPDuh+F/h14Z0x9G8M3MViltHexIwkvNSxgEgtGI43PO1X/AL5FdXFec06eEcOW90+zV2uVRa7u 97b2TOThHJatTFqfNZqS01TsmpOSfZctr7Xa7mN8HoPjrc/tMfFxdIv/AIWxavFLpSa1LcWV61m0 v2UlPKUSBsiIpuyeflxiuE1vxXN8Hv2Afg341v7FNa8MafqF9o/iewSM+VeaPfTTpLtXqMPHCU75 29OtevfC7xvcfDL9j/4l/GHU4ZoNU+I95d+INPtyv75opgttpkQHUuYhbgDvuHSuN+Ofhb/hF/hb 4X+BF6yBf+FUand3CBvkk1C3FtKJPweGcj/roa+DoVlPEqE4rljKKdla6p03Gpqu3N7vbQ/QK9Fx wrnCT5pRk1d3s6lVSp3T78vvLrqc18FdAg+F/wC1X8GvhF4a1D+17Hw/LqXjHVb5G3fbRcRPHZMx /wBm0Kf9/QO1fB37ZJz+138Tf+xq1L/0okr7k/YD8Jz/AAo+OnhibUvtF18QfiFYwMtlMAZfD3h2 1tlAkm6hJLh0gCp1CL25z8Oftktv/a8+Jx6Z8Vamcen+kyVyZ9pjYxT5rR+L+ZuUnJ+nM2l5LTSx 4tbXLOZq15u0f5UoxUV68qTfW711ueb19Uf8Eaf+T59N/wCwJf8A/oKV8r19Uf8ABGn/AJPn03/s CX//AKCleHX/AIZxZN/vtP1R8xa//wAjFqH/AF9zf+htVSrev/8AIxah/wBfc3/obVUrWl8COGv8 bPuX/ghJqEOmfHDx9dXEscNvB4ejkkkdtqxqJwSSegAGTX6GTftMfCi++ebxx4FlYjgvqlsWA9OW z/8Arr8yP+CS53XPxs/7ESf/ANmr49tYFNrH8ifcHb2rz54b2tZ6n2WDzyWBwFKKgpc1z9+P+Gj/ AIR7f+Rz8B/+DO1/+KqbTP2gPhbqepW9tZeLvBNxeTyrHbxQ6jbNI8hOFCgNknJ7V+Av2df7iflX e/sr24/4ac+Hnyp/yMdjzj/pulTLA2i3zG9Hi+U6kYeyWrS+9nqv/BWn/k/nxv1+7Y/+kkNfONfR v/BWY/8AGevjb/dsv/SSGvnKu7D/AMNeiPkc1/3yp6s0fCXi/VPh/wCJrPWdGvbjTtV02Tzra7gb bJA+CNynHXBNemf8PAfjag/5KZ4tx73I/Xj8a8gZwgJYhQO5qI6hCRjzk/77FXKNN/HYyoYnEU1a lJr0ufsr/wAEefi34m+M/wCy5qGq+K9bvvEGpQ+Ibm1S5u3DyLEsUBVM+gLMfxr6Y8cak+jeEtUu ojtls7OWZCRkBlRiCfyr5E/4ITuJP2PNVZTu/wCKovOQc/8ALG2r62+Jwz8PNe/7B9x/6Kavnatv av1P2XLpTll0ZS35T8RP2D/Aml/HD9sHw9pHiayGs6frDahNdW8zM32iT7LcSAsQQWbzMNwRz+Ne yf8ABNP9mT4t/Br9sjwjrWreBvFGj6Uq3FrqF3c2pSERPAww5zjBcIf94DjPNeJfsI+E9S8dftK6 bomj6nJour6vper2dlqEcjxtZTPptyqShoyHUqxDAqdwxkcivSf+Cdvx18ea/wDtt+CtK1bx5401 awku54p7e8167uLefbDL1jkkKkZAPIPb3r16sZOLttY/N8unTVWE6ifNzOzXy38j1T9qr/gpF8Wf iL+1zc/Df4XatbeHLS31keHbWQQQvNfXQkMbySyyqwRA+QFVegyckgVsf8E8f+CmvxB8S/tC2vw2 +JN3Brq6xNNZWl99nihuLG6iEhMbFAqyI3lkZI3ZI5IOB82fDzj/AIKoW5/6qjNx7f2pJ7D6fQCm fsdL5n/BSfwoOv8AxWE/H/A56h0YeztZaJM7KeZ4t4mNRzfvTcbdLaH0t+yx+3l8W9a/4KGx/Dzx p4s/tDQV1bU9Me0GmWcOWiWbyf3iRK/DIvRucc55qt/wTy/4KA/Ff9oX9qiS08R+Lvtngyw0vUNZ u7NdLs4cwRgCJfMSJZPlaRD94Z2ck5IPkP7T2qL+zP8A8FbPEGtjctvp2uwayCRw4uLOORv/AB+V x+FdH/wRr8GNLa/GDWfL3R6d4RNgr46NIHbH4iIflWcqMOTnt0R0UMwxX1tYbmd4yle7eqS29Ctr f/BS348/tM/FTXE8B65a+GNK02zvdXttPt7eHK2VsrSFpJZI3aSUxheBhSxwAByPoz/glT/wUa8T /tN+J9V8EeO3t9R1yw05tVstVgt0t2u4UljSRJUTCBwZoyNiqCu7IOMn8+P2NPhPq/xn+KX9g6L4 km8JzyaJeTz30W9i1skX76EqhBYOpIIzgjivpn/gkJ4W8E6T+12lxoHja+16+OgXgFrL4eksVMZa Al/MaVxxwMY5OeRiqrUaaht0RjlWY4yeIjNzdpNppvT5LyPOdI/4K+fHXQfE8s934sttWtovtEf2 OfSrKKMsUkSNmaOJX/duVfAb5tm05G6u5+NX/BST40+C/gz8INU03xoYL/xTod7f6pO2lWUjXMyX 80SthoiFwihQqADA6V4Z+wf4B0r4n/tv+BtC1yzj1HSL3VZ2uLSYBo5hHBPIqsOjLvQZByCMiveP +C4fhbTPBfxa+Hel6Pp9lpWm2ugTpBaWcC28MKm4PCooAUZJOAOpNNqlzxjymcMRjZYSriXVdk7L V73X6HK/FD/go5+0n4L0zwRq194ss9Pg1/SBqdiltYWji9jErxl7hfLxuYoflUhQu3GDmvpf9s3/ AIKdeJPhp+y98NNV8MWtlYeK/iVpf297iWESxaWiJEJTHGxILGSQBRJuAHUEjFfFP7Xw/wCLQ/AI /wDUiA/+TU1e9ftK/FLwR8OP2I/gFHrPgDS/G3im/wDDjDTJdTuZ4rXTYV8nzWZYmVn3MyADcoGM 54wVKlTfK+XqzXD5hiYQrRdVpcqabd97betzgrv/AIKOftHfBC+8La3rfiy31aw8U2Ca9aWN3Z2s kN5aNKyBW8uNXjJKMMIwIBB9h7z/AMFFv+ChHj/4feH/AIUa58PNd/4Ruw8c6CdXuIGsbW6bLiJl BaWNvuhyOMZPJr4Z+PEXimfR/Aep+JJbRbTV/D4n8P2NsmyPTdOFxMkcQXHALB2AJY4YZNex/t/8 /s2/syH+94FjP5x29V7KDnG6XU54Zlio0K0FOWiTV27rVbP5l74kf8FHf2kfDXhfwJrl94us7Cz8 Q6c99YPbadaE36xzyRPJcKYsBiVxsXC7dhwGya+mP2mv+Cn+v/Db9in4YeJ9HtLGHxt8TdPZxLJF uttPeFEFzKkZPzESyLsVtwGRuBxg/E/7U5/4x0/Z5/7Fa9/9LnrqP20v+TKP2VMj5f7E1sZ/7bWJ +nb9KmVKDcdFua0cyxVOnW99u0U9W3q7f5mrY/8ABSv9ov4Uaf4W8Z6t4mstf0Txd9pubOwvbO28 m7S2uGt5UYRIjw/OhA2sOxweRX1l+3f/AMFML74R/s2eA9b8CxQRa78S7T7bZzXiiZdLgVI2k+U/ K0gaVUG7K5BJBGBXjfwF8UfADwh+wV8Hrj4z6A+sXl02uppciWk0zRourXLSf6thjJKnn1rj/wDg rXqfhPWfh38A7vwNZmy8IXGi6k+kweUY/KgLWm0bWJPrwc8Go5ISqqPL39Dt+tYrD4GdSNXmbina 92r2uYdr/wAFIP2i/g1beEfFWs+J7TXdE8XwyahaWN5aW7RXUMU5hkRjHGjxHcpwVbuDg9K/V74G /FGz+Nnwg8OeLrJDDa+ItPhv0jlILReYgYoT6qSVPuK/F/xD8D7LTPgB8MfEfjX4l6lZad4ntL86 Bp0WkTaiumxQTqs6A+aoQGR1fCjByfSv1l/4J52mn6X+xf8AD630u/l1awh0wJDdvam2aZQ7cmMk lecjGT0rLFwiopxO/hjEYl1pU60m42TSbu+h4L+3z8DvE3wj+O//AAtb4ZQJqt9q2nsPFnhZ03pr 9lEVWSQR/wDLQBWQOF+dMo69684/Zq/amg8EeMfjz480+Jr3QdUvNJ8T3ljMoMjWE0skF3GR/wA9 IzNx6mMA4BNfdH7S3wRufjZ4A8jR9YuPDXizSJPt2g6zbn59PugpAJHIaNgSroQQyk5Br899T+Ku h+Cfib4k8O/HPwZL8NvGPinRrnw9qWv6LAW0rWo5l2x3UsCZXKShJRLD6HevZfv8gxUcfgHh6kee UUotL4+VSjLb7SsrJr3o7NWszxOIMNLL8wWJpy9nCTck38Cm4yjv9ltu7UrRlune6PetI8G/D7Tf Ber/AAa+JrWs3w1mtpfEvgHXJZjDGmmlTK8Ec/VZrUklQeWiZMhgCD8OwfsUSaj8RdPWXXZfBngL xXcyR+GPEviWwkgh1WLeVRXCf6mR+NqzeWHBBHUCvoX4S/FbQPEn7GNj4C+L1sl1oXhDWf8AhH7v W7J/OuNAMnz6bqcTrkPbnLxFgD/qxuDKzCvoTVPjFdfDbwS3hP48+H7Xxj8PtQhWK08aaZpwvdKv 7dgNn223jDNbvjGXRTGeGBXnb6NHHY3LKlSFG8pSk01da2+3TTTTnLSUo7u90mpJx82vgMDmlOnO raMYRTTs/dv9io07qEbOMZbK1m04tSy9X+H37QXwE+Fd34X0W6t/jD4SvdKextbyO5hsfEGjh4tg aNpf3Nwik5XcS+ABzgCvy98e/Afxh8LNa1Kz17wzq+l3WkRRT3omgybWOVtsTyMpKqHPAyeTX6v/ AA8/ZxW20qHUPgN8b9S0vw9LmSHSZZofEWlAHsnnFpY1HosgPbOOK8l1H9nb4m/Hj9pH4s+C9f8A FfgW5k1HQtGTW7g+Hp/KuoA80lv5Uf2geXKjqGLZIJC4AxycPZ/DBzquThbSUvdlCfxJe9FJxvZv 4d3a/Vi4j4enjIUVGNS+sYe9CcNYt+7JtTtdL4tle3RH5r6TfLpepwTvb293HFKkklvcZ8m4CkHY +CDtOMHBBweor7l8Dy3kKNY3V/4jH7LWo6nYQ6jdxJNJZWkixF3soGlxP/ZZuW2tPsAKqgJ5JafQ v+CVvhb9m74xxa58U/iD4Xl+H2kOk8VvNI0V7q0uMrC8I527uyFmcYAAzX0h8Tfilqfx5+G18LeK b4V/BG0tj/aviLVLYW1/q9mBgwWVqw3QRuOPMkUOQQETJyPTz7iLD4qVNYRc0HvN3SV7W5bq7qq3 u2Tavs9beZw/w3iMLGo8Y+Sa2grNtK9+ezSVJ3967SdtGtL5/wC0H8aNE8ca/c61Jtl+D3wNxq2o T2+PJ17Wol22tjDj76QFgzEZXzDGvJU7fnr47ftJa54f/ao8A+LLzSv+Ej8WyfD5Gi0eGEypPe6m sjx23ljlo0WTBHdY+TluWftT/GTRPiP+zz8PvAWl2tv8Pvhjq2oJqiRSKwmt/D9tuSO4nHLmW5kL SInLsY0J3Fia1Ph/4z8V/tc/HvWNR+BnhKTwnbaw4ttT+IWsxLPd2VkiiJILRW/dQAIFASINITyz DBYeXl+Xww1D2taFopTXvOyS0XvP+aT57qPM9IpaWZ6uYZjPFV/Y0al5Nwl7qu29/dX8sVyKLlyr WTet0fQP/BN39m698BXfivxv431L+3fipr862+tTl1kXSuFkNorJ8m8bk3hPlUqqDhK/LL9sv/k7 74nf9jVqf/pTJX7pfB74UaX8EvhzpvhrRxKbTTo8NNM5ea7lY7pJpGPLSO5LMT3Nfhd+2Yc/tffE /wD7GvU//SmSvhJ4+WMx1Su3o9tLWS2SXRdlrbbXc9riDARwWV0aCWqeut229W2+rvu+u9lsebV9 Uf8ABGn/AJPn03/sCX//AKClfK9fVH/BGj/k+jTP+wLfj/x1KWI/hs+VyT/fafqj5i1//kYtQ/6+ 5v8A0NqqVpeM7JtN8a61bN9631C4iYe6yuP6Vm1tS+BHBX+Nn2r/AMETfC0PjX4m/E3R7h5Ug1Xw r9lkeP7yJJLsYjryAcjg9K8q/wCCjf7H2h/sXfFfQvDehalqmp2+o6Mt/JLfFC4fzpI8LsUDGEH4 17P/AMEFpAP2gvGq920CM49hcLn+dVf+C8j7v2n/AAouef8AhGFP/k3PXBeX1rlPr5UKU8iVWS95 OyfzPiPOa7v9ln/k5n4e/wDYx2P/AKPSuEf71d3+yz/ycz8Pf+xjsf8A0eld0/hZ8pgv48PVHp// AAVkP/Gevjf/AHLL/wBJIa+dK+i/+Csv/J+3jX/dsv8A0khr50qKH8Nehtm3++VPVnsP/BPmwh1T 9tj4aW1xDDcQTavtkilQOjjypOqng/jX7cr8IvC2P+Rd0D/wXw//ABNfiZ/wTq/5Pn+F/wD2Gf8A 2jJX7rp+teZmMn7Reh+gcF0oSwsm11/RGfoXh6w8O2hg06ytLCFmLmO3hWJS3c4UAZ6c1Lq0EN3Y TRT7Wt3jZZQ/3SpHOfwzVpulZ/iw/wDFMaj/ANesvP8AwA150bto+0nZQa6H45+JP2SPG/7OXx+f XPhZ4z8FapBbXczaRq1v4h01ZbSGUPGI5op32hgjspYAqSMjBxt9O/YU/wCCdXxF+Gv7VPhLxez+ Hdd8J6VO73OraZq8N1GXa3YOgAbcxSRzGflySuRwcn5H/Z6+B037R3x90LwTa31vpdxr9zPEl5LC ZVhKRTTElQQTkRkcEda/TvRPEFh/wRy/YltbDX7pfFt/NrFwmnQ2EP2X7ZPMXmCkMW2KiIxZjnpj qQD6tdyilGO7PzPK8Ph61WWIqxcYRd730TVtLeZ4N+05/wAEz/i54C/azvviH8MbGx121n1r/hIL IfaI0msrppPNZJI5MBl8wswIJGCOhFdF/wAE7P8AgmL4+8E/tF2fxJ+JENro/wDZc019aWKTpNcX d1KrqXcR5WNF8xjySSdvA6jL0L/guh4y06903UvEHwy04eGdSlkSGa0upkkkEeBJ5bupWRk3KCML ywHGa+kP2pv+CjFr8Hf2WPCPxO8KaPB4n03xfdQQQw3dybMwrJFJI28qrEOpjKMuMBsjNZSddJQk t9D1cNSyiVSWKhJ+472ffvY8P/4Kgf8ABOv4i/tHftI2/ivwNpGn39jcaPb2128t/FbsJ4nlHRyC fkZBn2xXpv8AwSr/AGKfE37Nnwp8c2Pj7T7ax1DxVfJD9mhu0uFe0SDaCWQkDLSyjB5G33FcZ+z5 /wAFl7z48/FfwP4QXwRaabf+JNXe1v5f7QaaO2thGWjMfyKWkYq2c4AC988M/ZV/4LH61+0Z8fvD /g258A6ZpkOtfa993Fq8kzRGGznuRhTEoOTCF68bs9qlxr8vs2tjSjUyhYpYyMm5TbXW12ldbeZ4 vqf/AATN+PH7Knxc1HU/hta2Ov2VxBd2FlfQzwrMlpcK0eJY5Su2QJt5XIDKCMjIr3n/AIJWf8E3 fE/7MPirUvHHjc2dnrN1pzaXp+mW0yz/AGaF3jeSSV1G3efKRVCkgLuzgnAZ+yD/AMFdtY/ab/aK 0bwNdeBNM0e31U3Aa8i1aSZ4vKieQYQxLnOzHWsC7/4LY6/bfHC78IxfC5NUW11efS4l0/VJJLy7 KSPGuyLysFmKjjPGapuvNcllf9DKjHKaM/rCm7XaS10el7aHFfsUf8EzvjB8F/2w/CHi3xBoGnW2 haPfXM91PFqkMzKr288alUBLH5nXjHGTXqH/AAVi/Yc+I/7VHxW8Kar4M0i01Cx0rS5LW5aXUIrd kkM24ACRhnjv7Vyfwk/4Lm614o8RX+nax8NWubyeGT+yLXRLh5riW4UEpDKrj7pwcuoyuPumu9/Y M/4Kw6h+1P8AHL/hCPEnhaw0W41CGWfTrizuGkXMQLtHIH53bQSGHcHIHFJqspe0tsXQeU1KX1KE nabv21062PFv2if+CY3xh+IPw6+Emm6ToGnTXfhPwoNK1JTq0KrBcieR9qlmG4bWByK6z9rr/gm9 8R/iV+y18GrfRLGzuvEngDRpNM1PSzdort5giO6Nz8jbTGcjOTuBGSK/R9BkUqjaOOlYfW53T7Hr vhrCtSWvvJJ69rWt9x+QPjL/AIJh/tH/ABG8K+D49Q0XRbmPQNJ/sqytv7RgilsLZZZJESXJw7Eu TkFsAgHBGK9V/a0/4J0fFj4sfBT4IaNomiWN1f8AgrwsmlaukmpxIsE4SIFQWPzjKHlfT3r9KtmB QownpR9bldPQiPC+GScW2+ZJPXta35H5ZfHr/gmR8Y/HHwc+D2j6ZoFhNqHhHQrqy1RG1eFFhmku mlVQS2GypByOO1epfGT/AIJmeLfi7+wH8MvC4XT7H4hfDq2l2W01yPIuFlOZYBKuQGbZEQx4yuCQ CSPvs8e1ITil9ano+xrDhzCR5t/eST16K3+R+P8Apn/BND9on4raP4W8D61pOn6H4b8JvdLZXV3c wmKyW5m86dsRMzykuSVGPbI6j6w/bp/4Jkz/ABm/Z48EaD4HuLePWvhzam0sEvnMaajbsiLIjOAQ rs0auDwCcg4FfaGyjbt/xpyxU21LsFHhzCU6cqbu+ZWbb1stj8gW/wCCb/7R/wAXdL8I+DNb0XT9 L0DwaLi0066uruDyrKO4lEkzsY2Z5csFxgZwoHuf1P8AgN8J7T4H/B/w74RsJJZ7Xw/YRWSSyLta YouC5HYscsR711+QBRjFRUxEqmh0Zfk1HCScottvqySvF/2tP2ftc+Kehte+GD4b1DUYoys2heJr Bb7R9XUdAwI3wSjkCSMjOcMGAXb7RRV4TFVMPVVanuu+39f0tTvxeFhiaTo1Nn20f9f09D8tY9B8 WfDXVtX06+/ZKv4RrNq+k6nBoWtXs2nahAedmxGmhGG+dGQq6Nggg16H+yt4t+Lf7LelNa634eg0 H4REu/2b4ga/a2s2kIeSsDKGldf+mbRYJzjBJz9efHD9mDSfjSpuI9Y8T+E9Z27Bqfh/VJbKWQek iqfLlH++pI7Ec14Av/BGLwl4l8TpqHjLx3488YKjbvKu7wKW9i/LAf7pB56iv0GHEmX4vDuGNtG+ 6tUm7rrG9SyfZ38rWPzufDWY4TEKeCvK3wu9OCs91K1NNrured7nGXvxN+Av7QvjPVJvAfwp8Sav eWIE+p+IvD123haygIGTJLcma3UgAdZQCw6Kaxml+GllH/wkcWgfHdk1mZdKl1efxe9to9ysW7y1 OpGcIYslgjFguTwea9s+EH7El5r/AIvurfxfoem+F/hj4Vv2Twx4J0y5ElnqRXkajfup3XDsTkRy k4I+Ze7fT1/4fsNV0STTLmytLjTpovIktZIVaF48Y2lCMYx2xXFjM9w2FmqOHc5x0/5eN2Xa6dm9 rqKST0vLc7sFkOJxUHWxChCWv/LuKu+9mrpb2cm207tR2PhTQ/2hPgl+yz4r8jXvhPq3gbxdJEGs dV8SiTW4rgHoy36NcyFD/ej3CuN/aFf4x/tcatY61f8AhfSfiX8NbGUXNjongnxLE9hduD8rXTHb cs2OCPLG3kAKSSfePFP7C1/oXj6x8Lafpem+Mfgd4hmc6h4e1e5KyeD5MFhcWE2fNVC3AjRuC2Bt HIybP/gjD4L8M+I3vPDfjf4geG7aRtzW9nfqDj08zaD+eTXo0M2ymjNYpzftWtHLmmktrL3lOnL5 y7qTTPMxGUZvWg8KoL2Seqjywd97v3XCpH5R7SimrHjGleCvi18XPiYLlP2a/AOi6tqO1U1Hxjcy XcNoka7UWKCWYYSNOFSGLCgdOtfdn7Pvwa1D4V+GlbX9b/4SDxFcRqlxcRWyWdlaoORBa28YCRRA +29zgsxIGH/A/wDZp8L/AAAsXGjR6je6hcKEudU1W+kvr65HXBlkJ2r/ALCBVzzjNd/XyueZ99b/ AHNGKVNeTu//AAKUml5Jpd0fWZFkH1O9avJyqPzVl8oxgm/Npvswr8CP2zD/AMZffE//ALGvU/8A 0pkr996/Ab9s2VV/a8+KHK/8jXqff/p6krzct/iM8/jdN4aFu55xX1T/AMEZ13ft06Z/2Br/AP8A QUr5U89P7w/Ovqr/AIIwzB/27NKAYH/iT3/f/ZSvRxT/AHbPhclpv69Tv3R5Z+3P8Mrz4Q/tf/EL SbqHyVm1u51K1wuFa2upWuItvsFk2/VDXlVfr1/wVJ/4J8z/ALVvhm18U+FYrdfHHh6B41hkbYur 23LeQW6CRWyUY8fOwJAbI/JDxF4fvvCPiG80rVLK603UtPkMNzaXURint3HZkJ4/z16mMLWjOCXU 6c/yuphcRJuPuyd0z2r/AIJ5ftcWn7G3x7l8RarY3mo6LqWnSabeR2mDNFlkdHVSQGwyYwSMh+Mn ANb/AIKAftYW/wC2P+0A/iXT7G80/R7Gyj0/T4rojzmjRnYuwBIUszt8oJwByc5A8RZd+ffjpXY/ AX4GeIP2kPihp3hPw1aNcahfyKZZCD5NjBuAeeVsHaig59ScAZzitXCEZe1e5w08XialFYGPwt3S schXefss/wDJzPw9/wCxjsf/AEelYfxj+G158FPiz4i8Jai6te+Hr+SxkcDaJgh+WQA84dSrD2bi tr9liZT+058OxuX/AJGOx7/9N0pzknC6MsNSqQxMYyWqkl+J6j/wVkP/ABnt42/3LL/0khr50r6J /wCCsrqP29vG+Sv3LLv/ANOkVfOgnXj5l/Olh/gXoa5rCX1yp6s9p/4J1f8AJ8/wv/7DP/tGSv3W PP5V+E//AATpmU/tz/DDBX/kNev/AExkr92c4/KvKzH+Ij9C4JTWElfv+iEI3MaoeKuPDV//ANe0 n/oJrQBw1Z3ilGk8O6gqjczW8gUAZJOw4rz47o+wq6wfofgL8B/AHiX4q/HLRvD3g++bTfE+p3M0 en3C3b2hjZYpZG/ep8yfIjjI9cd6+l/+Ci3w08YfBn9j34GeGvHWoNqfiWxv9dkvLhr17wSF7nzI syv8zYilQc9MY7Vy3/BOP4LeM/Df7evw+v8AUvBvi7TdPg1G7aa6vNFubeCIGyuVBd2QKuWZRnPJ I9a+x/8Ags/+zX4k+OvwX8N6v4X0u71q+8I300t1ZWkXmTvbTRbXdEGS5V44squTtLHBxg+vUqpV YX7H5ngsum8ur1LPmu0lrrqnsfA/xq4/YP8AgN/1/wDicde322KvWfjlmT/gjD8IOp/4qWYDPpuv 8enFeIaivjT4u/DDwF8MtN8CeI59Q8G3WpOhisp2muDezRy4dSn7vYVYZY45B7Gvrn9s/wDZf8Vf DD/gl58K/A6aLqWta/pGsQ3GoW+lWcl40Ekkd1JIP3anKo0oTdjB2j1rSpJXin3OXC0KrhVmou3K lt10KH/BGT9j3wx8SdHm+KGsNqEuteG9caHTI47ny4ICkKMXZQMuW83GGJGAK+cP+CYCY/bm+H/0 1PP/AIKb2vvn/gip4K1jwP8Asta5a61o+raJcS+IZpVh1CyltJGTyIAGCuFJUkEZ6cEZr4E+CngL 4h/skftiaWD4D8Qa5r/hu5vLaPT47SYDUVlt57XzY3CEGMiUuHGQQO3SojU5qk1c3xWD9lhsLOMd LtvR3vobX/BKP/k/3wh/2/8A/pNNTP2fP+Upmj/9j1ef+jZ66X/gl38G/Gnhj9ubwlf6r4O8WaXZ oL0y3N5o1zb28Ra2lAzI8aqMk4HPJOPWk+AvwZ8ZWH/BTPS9TuPB3i230weNbmdr2bRbmO2SMyzE SGUoECnI+bOCCPUVbklJ+hz4ehUdKleL+N9PQ5r9gOPP/BTPwpnGP7e1Tg/9e15Vv/glV/ykR8Ke nm6j/wCk89bf7C/wY8ZaH/wUe8MalfeDvF1hpseuak73l1otzDbxq1tdgFpHTaFJIAO7kkY7VY/4 JkfBvxh4X/b68MahqfhDxZpmnxyX5e7vNHuYIIw0EwXc7oF5JABJ5JFFSSs/QeCw1SNSleP23+h+ xI4opsdOrxD9ZCiiigAoxRRQAUUUUAGM0UUUANz+8x7U6iigAooooAKKKKACiiigApGOBRRQA0sc VwWs/sy/DrWtXuLy+8B+Dr29vZWnnuJ9Gt5JZpGYlnZihLMSSSSckmiiq2ehk6cKmk1cjb9kv4XL /wA068Df+CG1/wDiKv8AhH4D+CPAOsJqGg+D/DOi3+woLmx0uCCZVPUBlQHB7+tFFPmbQU8LRUrq KOv27k5rzH49/scfDj9p2K3/AOE18NW2rzWqlILkSyQTwj2kjZW/XvRRRBtPQdWhTqw5aiujyPTP +CMXwI07UPPfQtZu1ByIZtaufLHt8rgkexJr3z4W/A7wf8EdJksvCPhvR/D1vIFaZbG1SI3JG7Bk YDc5GTgsSeTRRTnUk1qzjw+Bw9Kd6cEvkQ+JP2ePAXjPXbjU9Y8F+FdW1K5I866vNKgnmmx8g3Oy FjhVAGTwAB0AqKy/Zh+HGg38N7aeAvBttdWjCaGaLRbZJInX7rKwTII7Eciiis+eXc6vq1Hm5uVX 9Cx4l/Z38BeNdbk1HWPBXhTVdRuMCS6vNKgnmfaMDLspJx9ap/8ADJXwu/6J14G/8ENr/wDEUUVS nLuKWFot3cF9xPoH7N/w+8KaxDqOl+B/COnX9n+8gubXR7eGWE+qsqAqfcc13K/MaKKJGlOnGEfd Vh9FFFSWMEYD9Kcy7qKKAGiEClMYNFFArIBGBSeSuaKKAshREBSeX81FFAWQCIA5pfLUfwj8qKKA sh1FFFAwooooAKKKKACiiigAooooA//ZUEsDBBQABgAIAAAAIQAhWqKEIQcAANsdAAAVAAAAd29y ZC90aGVtZS90aGVtZTEueG1s7FlPbxtFFL8j8R1Gey+xEydNojpV7NgNtGmj2C3qcbw79k4zu7Oa GSfxDbVHJCREQRyoxI0DAiq1EpfyaQJFUKR+Bd7M7K534nGTlAAVNIfWO/t7b977vT/zZ69cPUoY OiBCUp42g/p7tQCRNOQRTUfN4Ha/e2k1QFLhNMKMp6QZTIgMrm68+84VvK5ikhAE8qlcx80gVipb X1iQIQxj+R7PSArvhlwkWMGjGC1EAh+C3oQtLNZqKwsJpmmAUpyA2lvDIQ0J6muVwUahvMPgMVVS D4RM9LRq4kgYbLRf1wg5kW0m0AFmzQDmifhhnxypADEsFbxoBjXzFyxsXFnA67kQU3NkK3Jd85fL 5QLR/qKZU4wG5aT1bmPt8lap3wCYmsV1Op12p17qMwAchuCptaWqs9FdrbcKnRWQ/Tmru11brjVc fEX/0ozNa61Wa3ktt8UqNSD7szGDX62tNDYXHbwBWfzyDL7R2my3Vxy8AVn8ygy+e3ltpeHiDShm NN2fQeuAdru59hIy5GzbC18F+Goth09RkA1ldukphjxV83Itwfe46AJAAxlWNEVqkpEhDiGL25jR gaB6ArxOcOWNHQrlzJCeC8lQ0Ew1gw8yDBUx1ffy2Xcvnz1Bx/efHt//8fjBg+P7P1hFjtQ2TkdV qRfffPrHo4/Q70++fvHwcz9eVvG/fP/xzz995gdC+UzNef7F41+fPn7+5Se/ffvQA98UeFCF92lC JLpJDtEeT8Axw4prORmI80n0Y0yrEpvpSOIU61k8+jsqdtA3J5hhD65FXAbvCGgfPuC18T3H4F4s xiqPt+PZ9ThxgDucsxYXXhau67kqNPfH6cg/uRhXcXsYH/jmbuPUiW9nnEHfpD6V7Zg4Zu4ynCo8 IilRSL/j+4R4+LpLqcPrDg0Fl3yo0F2KWph6KenTgZNNU6FtmkBcJj4DId4ONzt3UIszn9db5MBF QlVg5jG+T5hD4zU8VjjxqezjhFUJv4FV7DOyNxFhFdeRCiI9IoyjTkSk9MncEuBvJejXoXX4w77D JomLFIru+3TewJxXkVt8vx3jJPNhezSNq9j35T6kKEa7XPngO9ytEP0MccDp3HDfocQJ9+nd4DYd OSZNE0S/GQtPLK8R7uRvb8KGmJhWA03d6dUJTV/VuBPo27njF9e4oVU+/+qRx+43tWVvAgm+mtk+ 0ajn4U625zYXEX3zu/MWHqe7BApidol625zfNufgP9+c59XzxbfkaReGBq23THajbbbdydxd95Ay 1lMTRm5Is/GWsPZEXRjUcubEScpTWBbDT13JMIGDGwlsZJDg6kOq4l6MM9i01wOtZCRz1SOJMi7h sGiGvbo1Hjb+yh41l/UhxHYOidUOj+zwkh4uzhqlGmPVyBxoi4mWtIKzTrZ0OVcKvr3OZHVt1Jln qxvTTFN0Zitd1hSbQzlQXroGgyWbsKlBsBUCllfgzK+nhsMOZiTSvNsYFWExUfh7QpR7bR2JcURs iJzhCpt1E7sihWb80+7ZHDkfmyVrQNrpRpi0mJ8/ZyS5UDAlGQRPVhNLq7XFUnTYDNaWF5cDFOKs GQzhmAs/kwyCJvU2ELMR3BWFStisPbUWTZFOPV7zZ1Udbi7mFIxTxpmQagvL2MbQvMpDxVI9k7V/ cbmhk+1iHPA0k7NZsbQKKfKvWQGhdkNLhkMSqmqwKyOaO/uYd0I+VkT04ugQDdhY7GEIP3Cq/Ymo hNsKU9D6Aa7WNNvmldtb805TvdAyODuOWRbjvFvqq5mi4izc9JPSBvNUMQ9889punDu/K7riL8qV ahr/z1zRywFcHixFOgIh3OwKjHSlNAMuVMyhC2UxDbsC1n3TOyBb4HoWXgP5cL9s/hfkQP9va87q MGUNZ0C1R0dIUFhOVCwI2YW2ZLLvFGX1fOmxKlmuyGRUxVyZWbMH5ICwvu6BK7oHByiGVDfdJG8D Bncy/9znvIIGI71Hqdab08nKpdPWwD+9cbHFDE6d2Evo/C34L00sV/fp6mfljXixRlYd0S+mu6RG URXO4re2lk/1miacZQGurLW2Y814vLhcGAdRnPUYBsv9TAZXQEj/A+sfFSGzHyv0gtrne9BbEXx7 sPwhyOpLuqtBBukGaX8NYN9jB20yaVWW2nzno1krFusL3qiW854gW1t2lnifk+xyE+VO59TiRZKd M+xwbcfmUg2RPVmiMDQsziEmMOYrV/VDFB/cg0BvwZX/mNlPUzKDJ1MH2a4w2TXg0ST/yaRdcG3W 6TOMRrJ0jwwRjY6K80fJhC0h+3mk2CIbtBbTiVYKLvkODa5gjteidrUshRdPFy4lzMzQskthc5fm UwAfx/LGrY92gLdN1nqti6tgiqV/hbIzGO+nzHvyOStl9qD4ykC9BmXq6NWU5UwBebOJB583BYaj V8/0X1h0bKablN34EwAA//8DAFBLAwQUAAYACAAAACEAq7jr1H0DAADRBwAAEQAAAHdvcmQvc2V0 dGluZ3MueG1snFXbbtw2EH0v0H8Q9Ny1LrvedVTLgbOpWwd2a1TJB1AUpWXNG0hq5e3Xd0iKVly7 QdAnkWdmzgznpsv3T5wlR6INlaJOi7M8TYjAsqNiqNMvn29WF2liLBIdYlKQOj0Rk76/+vGHy6ky xFpQMwlQCFNxXKcHa1WVZQYfCEfmTCoiQNhLzZGFqx4yjvTjqFZYcoUsbSmj9pSVeb5NZxpZp6MW 1Uyx4hRraWRvnUkl+55iMn+ihf4ev8Hyo8QjJ8J6j5kmDGKQwhyoMpGN/182eOIhkhy/9YgjZ1Fv KvJvac7PnaTuni2+JzxnoLTExBgoEGfhuRxR8UxTbF4RPaf6DFKdBd+ZowLzIvenJXLDXtm/Ue1Q xTvaaqRDmaEBXBQcV7eDkBq1DJpqKjbpFXTU31LyZKqOCMhbYuwNtSncFdEYilan5TpPM6fYUaMY On1A+HHQchRdc0CKeBG8W/aNRZaApVGEMd/KmBEEfqdq0IhDE9ZpQAId6dHI7GfUNlaqGMGunL3h A9IIW6IbhTCw7aWwWrKo18nfpd1DQ2vId4gvtLeLNJyaMCpgIRCHBwd0bv972REX2ajpq5z+Z02c gc8TpA7ekEVPzicMc2fi4U8pbdTN8/1+vSvfhSCd2iJZ7/JyXb4l2Z6fX1zv35IsbOB/9sorNwgP +uoynG4gWQkPse4RbzVFyb0bFYiaV61+/EBFlLcEVgX5WtKMbRSuVkFgOGLsBgoSBb5K3PfER9J7 WnaP9LDwzhr6TbQj/adnLtdnRP8KPaWCt0kjdSs6gKO7YrOZ+aiwd5RH3IxtE60EtPtXImjQP47a EWZLeqbKwpYkLj93SAyxEkSsvjSuugQZe20oqtO/0OrTg7OGIjPduOVK7pFS0Iqg1w5FnTI6HGzh zCzcOliy/tIO5SwrvQxuTuYvCLvHgvZ8cArhCFrzYcHWEVsvGKyQoLdZsPOInS/YNmKw5KfqcIJ5 hqF8hGaPR4f3kjE5ke63CNbpKygkwQ/c9WhlHLoHiu0I0+dTZNwqgEZwEw1TICsPQJU9kBwr8gSr hHRutxhFO46e4MeXlztHPmvDbpGjfaHrZE5ZvUCTDlmoUOFr+8LYz+S/YoHFRTCF/m1OvF0WyE/h WYwa2xAFu8ZKDQnx4/2zlxWbqpP4FsYVTh4vtxf5bvvuF+94+Rdf/QMAAP//AwBQSwMEFAAGAAgA AAAhAKtinll5AQAAQgMAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbJRSwW7CMAy9T9o/VLlDWlZN qKJFQwhp0rTDYB+QpmkbLYmrJLRjXz/TAmNjBzjFtf1en/08m39qFbTCOgkmJdE4JIEwHAppqpS8 b1ajKQmcZ6ZgCoxIyU44Ms/u72Zd0ol8LbzHThcgi3GJ5impvW8SSh2vhWZuDI0wWCzBaubx01ZU M/uxbUYcdMO8zKWSfkcnYfhIDjT2GhYoS8nFEvhWC+N7PLVCISMYV8vGHdm6a9g6sEVjgQvncB6t Bj7NpDnRRPEFkZbcgoPSj3EYOiiieyqER2EfaUUCzZPnyoBlucINdlFMMlxfIVt3eIMukUVK4ukk fpiE07Cv51DslrLFWssUWkPovhuX9yJKf8yGp+ybrOp/0htoLnsX4D3oP3nUsyjs/h/+B2PQdIKN 7isleBoYNIzjEH3MQQF6xbYeBhnqTNltyPyXotuw9nzyW6C0N6Efegiz2fAOvsAr+DVrxZNb400o sZJKoAfYcnb52TcAAAD//wMAUEsDBBQABgAIAAAAIQAed0+xbQoAAMRZAAAaAAAAd29yZC9zdHls ZXNXaXRoRWZmZWN0cy54bWzsXNty2zgSfd+q/QeW3h3r4ltU40w5zmTGVZ5MJnJqnyEKslimCC4v Vpyv30YDhChSIBsirdrdsv1gEwL6NLobB02IzV9+/bEOvWeepIGIrgejd8OBxyNfLILo8Xrw/eHz ydXASzMWLVgoIn49eOHp4NcP//zHL5tpmr2EPPVAQJRON7F/PVhlWTw9PU39FV+z9N068BORimX2 zhfrU7FcBj4/3YhkcToejob4X5wIn6cpoN2y6JmlAy1uLWjS1swvBI+Hw6vTNQsiI6OukYh5BPou RbJmWfpOJI8wInnK4xPQMGZZMA/CIHsB/YYXRszz9SBPoqme1YmZlRwzBQWmz+uw6Axq2/sqC0zV n2JEUpvoHiXVkE/Cz9c8ylC904SHoLCI0lUQb+12qDSwx6pQqXHCpclu4tFZDc+Yh+L0TwnbgO8L 4E1cE7fHGAs1aB0qO8iA2oZRVeJoSPCIFGF0oKiwi1loUg6+zWGm2UbSJoYF2GVB/Z6IPDazioNu 0u6iJyNL8oCDZsMLXOrlqaVOAmpcMVuxmA+8tT+9e4xEwuYhaAQW92REDj4ANy2E/4kvWR5mqbxM vib6Ul/hn88iylJvM2WpH4B5bpKAwULeTDlLs5s0YKWm1U2Ulrv4MAPV/1SK8kUoEhj5zMLrwRB/ BvhB+rNoHY+LlluJiT2LtpBFj0Ubj06+z3a1ME3zYAFKsORkdiOFneLEir+lCcY704UrqWMaMx/W GuCEgfTg+BIoTl18y6UBWZ4JLRaHgPiyILisWBX4B9hoprYB+JQv74X/xBezDD4AO0jx0Pj97msS iAR49Xrw/r1unPF18EewWHC56xQdo1Ww4P9a8eh7yhfb9r8/I19rib7Io0ypL6cVpovffvg8llQI eBFbA/QXOQB9mZZwUKE82GqjGiqo2PjvAnKkvLYXZcWZ3Cc91L8RCGeddwYaS0OVJ4BynXSddBdx 1l3EeXcRGLzdbHHZXQvIjrp6RMVGKSrpTs2Er4KvbIfJ+4aQlSNqUdQ6ohY0rSNqMdI6ohYSrSNq EdA6oubw1hE1/7aOqLmzcYTPkLiqUTRBa5AW9kOQhbAXAr83Md2oI9XpzcX7yhL2mLB45cnNs6p2 E1nO8nlGUxXp9HCynGWJkClli0Vg75VL92BO/m0dr1gaQObdBtTR9A8yvfF+TwJIUVugzlXw1eaE qcjeLexryHy+EuGCJ94D/6E86jD+i/BmKq9oVa6jW++Dx1XmQeYnt9xWsAuL0e2WUPLvgxRt0LiY LixTaRNO8uGFJS7twv/kiyBfF6YhZCMXis8d3FyBQBWbTXQmXVRfXa2zkA6gTEFtF+5TQPkE/dXm 4i5f+piiv9qKDpRP0F9tXAfKx/ho9q8z03yCcxaPtLwundfurbz9WuZhsQZa6eHSeQUbCNoUnBex kU8iiUvnFbxDn96N78OdGyVOnX2x5VEHFGd3KBRcbPS5ODulQnsjhxk5O6iCNXbA6sa1DkDOpPuN PwfyZNl1M0CWNrlm63KeWCwAWxAph/47F1l7Dj22cB4V5S6C45KUezS0iWXlUdF0PKn9zsHH3TY+ B6BuO6ADULet0AHIEh/2nMfsiXSQ7pujA5YzLZtdDMOOzMyXzsxsgNy2gJ72TUL+ZVm99lio75sE FGcH1fdNAoqzdyp7mdk3CVi97ZsELMuuYfdRmVNdJuW8b5aBTCZAmFE/5E0A6oe8CUD9kDcBqDt5 t4P0R94ELGduMJxaJm8CEHZxudU3QGXyJgA5c4NiO31mVOx7KKX55rYH8iagODuoTt4EFGfv2Mib gIVdXCKhgmWojoDVD3kTgPohbwJQP+RNAOqHvAlA/ZA3Aag7ebeD9EfeBCxnbjCcWiZvApAzPRig MnkTgLCLCzfsJW9c9a9O3gQUZwfVyZuA4uydCqGaJJWA5eygCpYhbwIWdnEJBo2Fwe0yqX7ImzCj fsibANQPeROA+iFvAlB38m4H6Y+8CVjO3GA4tUzeBCBnejBAZfImADlzw17yxsX46uRNQHF2UJ28 CSjO3qkQquE5ApazgypYhrwJWBgvncmbAIRdDgVymVE/5E2YUT/kTQDqh7wJQN3Jux2kP/ImYDlz g+HUMnkTgJzpwQCVyZsA5MwNe8kb18irkzcBxdlBdfImoDh7p0KohrwJWM4OqmAZqiNg9UPeBCAM zM7kTQDCLgcA4SpycVM/5E2YUT/kTQDqTt7tIP2RNwHLmRsMp5bJmwDkTA8GqEzeBCBnbpDP2cLz ouTHU0eWIKA+Z1A81UAGHFucRAXUE/zGlzyBUkXe/nRIR8Bihg6IlvCgTvGjEE8e7cHuiSVAyFDB PAwEPtL9gk/plAoRJpcNlQQPf916f6gCmNo4DKndJ2+geqhcLoQFSbJwCPTMXmIo2YmLJ8ulNKga krVbugQIC03voCBIl/XIwbLOBzpiGZVuxu9tNSr8D4g4sAXKCNeTGWH9WFn8tswHEeYMipP+krVG CA71Z1BqNFSWiuAR6r0f6BqsJ87jL9AHBcmLeyjFSvFqW54151CfChY5G+L3UGyZcSgSHY01hg8P 3oOInIX6yWscLvJMlnXdP4cFPnZXNVzSBFACh5YwBWlnWl76c1uQptpgEPY+0IJjqwV1CdzRLDhR j4EfakEsZ2iw4GRPSZ9q62jBidWCExVnx7MgRB0ElLbglWMIon1qBvTLxZJnE/mrZlUqlrwqWrax Oca2jpZV1aH7VvfZkS07BmMeblm0WLNlL/CnsGPBCmM9z/KqV20dLXtujdnzY1sWWOxwy6J9qJbt aLMLq80u/qdshh6u2SzAjWlntW9jst1y/goyAh/2voaEQJelmSeFsSitmh5YatdQu23hZLFAdA3b 9qRD9duppIAm0N+SXWSyXqtBZ6znasxkPOyiIqCuIJRQo0ptGkJiNQ/Vpg//3EULmOFG11CrlGvx gylR8PktD8M/WSJtl4nY3jXkS5nhgKDREO9TK6LmIsvE2j4+wTIuqwAwa1kZdSknYbd3lK/nPNFF YdbEUd7f1VYbVK9huyUUqJa267aT1Pp5CqaZyay3mtgWSWQ1dFW7dBIRw2Sz6u6hKk+14nRfPYXQ OQOkYIi3L22FSenEuJadnu/JrVQbDDooOzUFqFWjmA+OapdJUz5fM4yFRYGETD4PBQM4gfLOrtra LWY4qyFGGS6fStiUyQzRy5yDof5NbD7C64NmwU9zv6YpFrpiDzgasff4/+Utks2Hb0a37zYQ166b Bcno6gjgLdL3bvGvZXR1avBm9KMaXR00vBn9qEZXZxBvRj+q0dXxxJvRj2p0db7xZvSjGv3yLWU8 fsp49Wb0Xo2+c3BiDjU+sjAUIsIXFVXv4vVn6i1G++7k9ZEbfgRflT2BvvgFXknoLRw5qpvoLsdu 8C5dedaGwofDyeVwXHxRpA87tl/16TcxqgNrebH/TYzm27uk8srK+9wPFgxeDgV32HjmqN9TWWuX 76vcbdRnBYWioz3fuKi29tODnZPahhOEqqWbXOhtfVHZP/ae+TZ51dGjdvfpQ6r/DieAW3BdpB/+ AwAA//8DAFBLAwQUAAYACAAAACEAfFDdHUYBAABhAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIE ASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJRS8MwEMffBb9DyXubdBtzlDYDHXty IDiZ+BaSWxds0pDEdfPTm3ZdreiDj8f978fvLsmXJ1VFR7BO1rpAaUJQBJrXQuqyQC/bdbxAkfNM C1bVGgp0BoeW9PYm5ybjtYUnWxuwXoKLAkm7jJsCHbw3GcaOH0Axl4SEDs19bRXzobQlNoy/sxLw hJA5VuCZYJ7hFhibgYh6pOAD0nzYqgMIjqECBdo7nCYp/s56sMr9OdB1Rkkl/dmEnXrdMVvwS3NI n5wcgk3TJM200wj+KX7dPD53q8ZSt7figGh7n4o5vwmn3EsQ92e6kypaQQmfUFWQ49+BdsbCUbZv QaddYihzwTv9jFtgHkQUhLKL/rWzmz6stmtEJySdx2QRk9k2JRm5ywh5y/E11c/TAah6w38TZwE6 Jl4BtDP++SnoFwAAAP//AwBQSwMEFAAGAAgAAAAhALtZPaLUCQAAYlYAAA8AAAB3b3JkL3N0eWxl cy54bWzsXF1z27YSfe/M/Q8cvSf6sq3EU6fjOE3rGTdNI2f6DJGQxTFJ6JJUHOfXd7EAIYoUyIVI a3rvKHlICAJ7gLOLAxDi8udfvseR942nWSiSq8H49Wjg8cQXQZg8XA2+3n989WbgZTlLAhaJhF8N nnk2+OXdf376+ekyy58jnnlgIMkuY/9qsMrz9eVwmPkrHrPstVjzBG4uRRqzHC7Th2HM0sfN+pUv 4jXLw0UYhfnzcDIaXQy0mZRiRSyXoc8/CH8T8yTH9sOUR2BRJNkqXGeFtSeKtSeRButU+DzLYNBx pOzFLEyMmfFZzVAc+qnIxDJ/DYMZqh4NpSloPh7h/+Jo4MX+5e1DIlK2iIC8p/HZ4B0wFwj/A1+y TZRn8jL9nOpLfYX/fBRJnnlPlyzzw/BqcJ2GDAw+XXKW5ddZyEpFq+skK1fxs+LmUJryRSRSaPmN RVeDEf4Z4I3sR1E6mRQlNxITaxZlEUseijKevPo63+2FKVqEAXSCpa/m19LYEAdW/Fsa4HpnuHAl +5itmQ/0A04UyjibzCAm1MWXjeSObXKhzWITMF82BJcVViEeIDrmKkjhLl/eCf+RB/McbgAP0jwU fr39nIYihUC8Grx9qwvnPA5/D4OAyzlRVExWYcD/XvHka8aDbflfHzHAtUVfbJJcdV8OK8qCX7/7 fC1DE/ASFgP0J9kAfZmVcLBDm3DbG1VQQcXC/xaQY+W1vSgrzuQs9rD/jUA46k1noIkkqjwAtOvU 12l3E2fdTZx3N4HB242LWfdegHZ39YiKjVJU0p2aC18FX5mH6duGkJUtalHU2qIWNK0tajHS2qIW Eq0tahHQ2qLm8NYWNf+2tqi5s7GFz1C4qlE0RTZIE/s+zCMu2zcK0Lij1OnFxfvMUvaQsvXKk4tn tdtNYjnfLHJaV1FODxfLeZ6K5KGVEVh75dQ9WJN/jdcrloWwE2qhftKR+nu5s/F+S8OgFepcBV9t TLgV2buEfY6Yz1ciCnjq3fPvyqMO7T8Jb672Fa2d6+jWu/BhlXvzFS65rWAXFtLtTCj7d2GGHDRO pgvLUNqMk3x4YYlLu/E/eBBu4oIawm7kQum5g5srENjFZorOpIvqs6t1FNIBlCGo5cJ9CGif0H+1 uLjblz6m9F8tRQfaJ/RfLVwH2sf4aPavs9J8gAdTjzS9Zs5z90Y+fi03UTEHWuVh5jyDDQRtCM6T 2NgnicTMeQbvyKd37fvw5EaJU2dfbHXUAcXZHQoFJxt9LM5Oqcje2GFEzg6qYE0csLpprQOQs+h+ 4d9Cee7luhigSpu9Zut0nloYgCWItIf+ayPy9j30xKJ5VJTbBI5LMu7R0KaWmUdF0/Gk1jsHH3db +ByAuq2ADkDdlkIHIEt82Pc8Zk2kg3RfHB2wnGXZrGIYdmRlnjkrswFyWwJ6WjcJ+y/L7LXHQn3d JKA4O6i+bhJQnL1TWcvMuknA6m3dJGBZVg27j8qa6jIo53WzDGR2AoQR9SPeBKB+xJsA1I94E4C6 i3c7SH/iTcBy1gajqWXxJgBhFZdHfQNUFm8CkLM2KLXTZ0bFuodWmh9uexBvAoqzg+riTUBx9o5N vAlYWMUlEipYRuoIWP2INwGoH/EmAPUj3gSgfsSbANSPeBOAuot3O0h/4k3ActYGo6ll8SYAOcuD ASqLNwEIq7how17xxln/4uJNQHF2UF28CSjO3qkIqtmkErCcHVTBMuJNwMIqLsGgsTC4XQbVj3gT RtSPeBOA+hFvAlA/4k0A6i7e7SD9iTcBy1kbjKaWxZsA5CwPBqgs3gQgZ23YK944GV9cvAkozg6q izcBxdk7FUE1OkfAcnZQBcuINwEL46WzeBOAsMqhQC4j6ke8CSPqR7wJQP2INwGou3i3g/Qn3gQs Z20wmloWbwKQszwYoLJ4E4CctWGveOMceXHxJqA4O6gu3gQUZ+9UBNWINwHL2UEVLCN1BKx+xJsA hIHZWbwJQFjlACCcRS5u6ke8CSPqR7wJQN3Fux2kP/EmYDlrg9HUsngTgJzlwQCVxZsA5KwN8j1b eF+U/Hrq2BIE1PcMircayIATi5OogHqAX/iSp5BIxdvfDukIWIzQAdESHtQhvhfi0aO92D21BAgZ KlxEocBXup/xLZ1SIsJ01pBJcP/njfe7SoCptcOQ2n3zBrKHyulCmJAkE4egn/nzGlJ21sWb5dIa ZA3J3C2dAoRpcLeQEKTTemRjmecDFTGNShfj77YaFf4PiNiwBcoY14MZY/5Y2fw2zQcRFgySk/6U uUYIDqlnkGo0Ukwl8Ar13hs6B+uR8/UnqIOG5MUdpGJleLVNz1pwSOgDRs5G+DsUW+YckvbG8B45 VvThxXswsWGRfvMaS8Uml2ldd9+iAh+rqxwuSQGkwCETJiHtTNvLfmwT0lQZNMLaBzI4sTKoU+CO xuBUvQZ+KIOYztDA4HRPSp8q68jg1MrgVMXA8RhU2QuawTeOIYj81Aj0y8mSZ1P5V42qlCz5pijZ xuYEyzoyq7JD983usyMzOwEyYaoeyCwy1szsBf4peCxUYaLHWZ71qqwjs+fWmD0/NrOgYoczi/xQ me3I2YWVs4v/Kc7QwzXOQr1clVKjtzHZzpy/gh2BD2tfw4ZAp6WZN4UxKa26PbDkrmHvtomTxQTR OWzbkw5VbyeTAoqg/5bdRS7ztRr6jPlcjTsZD6uoCKh3EFKosUttPYSN1SJSiz785zYJYISQro9z Q225gu9MmYL7NzyK/mCp5C4Xa3vViC/lDgcMjUf4nFoxtRB5LmJ7+xTTuKwGgNZyZ9SlHISd72QT L3gKedgNnH8S8vmuNtsgew3LLaFAZdret51Nrb/JgJq53PVWN7bFJrIauqpcOomIYXaz6umhak+V 4nBffAuhVzbYgiHevm0rDEpvjGu70/M9eytVBo0O2p2aBNQqKebGUXmZNu3na8Ts7Jm2KgoiZPbz kDCAAyiv7KqsnTGjWQ0xynD6VMKmLGaIXtYcDPUv4uk9fNxkHv4wz2taYqEq1oCjEXuN/1/dInE+ OpFuX20grl0XCxLp6gjgFOl7l/iXIl2dGpxIPyrp6qDhRPpRSVdnECfSj0q6Op44kX5U0tX5xon0 o5I+O20Zj79lfHMivVfSdw5OzKHGexZFQiT4oaLqU7y+p75itO9JXh+54S34qewR+os/4JWM3sCR o3qI7nLsBl/6lGdtaHw0ms5Gk+KHIn3Ysf2pT3+JUR1Yy4v9X2I0v96llU9W3m38MGDwcSh4wsYz R/2dylq5/F7lbqE+Kyg6Ot7zi4sqaz892DmpbThBqDLd5EJv64vK+rH3zLfJq44etbtPH1L9O5wA bsF5kb37BwAA//8DAFBLAwQUAAYACAAAACEAzhBROXECAACOCQAAEgAAAHdvcmQvZm9udFRhYmxl LnhtbNxVy27aQBTdV+o/WLMPHhtDEhQTAcFVpaqLKv2AYRjDqJ4Za2bAZUv2XXfRfELVRSt1k79B yja/0OsHhITSgFRSqWYBnPE9Mz7n3Ouz848icaZMG65kiLwaRg6TVA25HIXo/WV0dIIcY4kckkRJ FqIZM+i8/fLFWdaKlbTGgXppWoKGaGxt2nJdQ8dMEFNTKZOwGCstiIW/euQKoj9M0iOqREosH/CE 25nrY9xEFY3ehUXFMafsQtGJYNIW9a5mCTAqacY8NUu2bBe2TOlhqhVlxsAzi6TkE4TLFY0XbBAJ TrUyKrY1eBi3PJGbU0G5h4tfIkGOoK3XI6k0GSSgXeYFqF0J52QtSQSAHc1JUsApkcowD1amJAkR 9nEXN3EA38tPgNy8no6JNsyubsQlHBPBk9kSJROrSjzllo6X8JTAfnCacsnwESxMzACHqI8x9jtR hErEC1EPkOOToF4hPpypvE4rpL5CIDZwroKnuMUreQABnqqqOKZb5mZDhksumHHessx5pwSRWwTx QZA6boAoDRCljv+NIN5zCPJmQvmQOK809B7bIkeeD1yJkWfksHJ4sFenv5aPRg5UTkOG7vNRpAGQ P+SjW/DsmY8tMmBIw4PrkG1SbbRsivV4l42zjwwYF1naXYa7m693N9+dxfzHYv5zcXW1mH8rRHk0 EoL+XxsJ2F8fCc1O7zi6iLqPO8DznxgJMOVP97S8RxI+0HyL6VExAorUwyB4juw/ECLIs99bSXNv +g6zcV8hKtNvP3+6/XL9H9stwG2yxe584peTP38DHNruvMk37MbBb+zeYdQ9aXf1TjTtXwAAAP// AwBQSwMEFAAGAAgAAAAhALn0siGNAQAA2QIAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFJNb9swDL0P2H8wfG/kZunHCkbFkGzYYVmLxUnP gkTbwmRJkNii+fej4dbxsNtu5CP5+PgkuH/tXfGCKdvg1+XloioL9DoY69t1eai/XdyWRSbljXLB 47o8YS7v5ccP8JhCxEQWc8EUPq/LjijeCZF1h73KCy57rjQh9Yo4Ta0ITWM1boN+7tGTWFbVtcBX Qm/QXMSJsBwZ717of0lN0IO+fKxPkQVLqLGPThHKn4MctzCBehATCnUg5Wrbo1wyPCXwqFrMcgVi DOApJJPlzeoGxBjCplNJaWIH5Wp5zdMzAL7E6KxWxObKndUp5NBQsVPaegq5KwYOEPMuYHf2qJ+T pZOsQMxT+GE9q/l0BWKMWF5SbVKxy/LzoHHKYK+Vww17IBvlMoI4A7AJfVT+JLeHr792D8cH1vyG DBt+50Osw3Yw6230b3B28ZOlbh+VZlFXVcVqz7fPSrBni9DwJe+EZwC+8wMlN2zlWd+iee/5tzC4 eRx/qrxcLXghb5xhbMD0heQfAAAA//8DAFBLAQItABQABgAIAAAAIQDrhSgkjgEAAMEFAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAMJgmvP0AAAA TgIAAAsAAAAAAAAAAAAAAAAAxwMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhANvC0IuzAQAA +gUAABwAAAAAAAAAAAAAAAAA7AYAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAU AAYACAAAACEAcJHIRJsaAACfnAAAEQAAAAAAAAAAAAAAAADhCQAAd29yZC9kb2N1bWVudC54bWxQ SwECLQAKAAAAAAAAACEAHdRReqZBAACmQQAAFQAAAAAAAAAAAAAAAACrJAAAd29yZC9tZWRpYS9p bWFnZTEuanBnUEsBAi0AFAAGAAgAAAAhACFaooQhBwAA2x0AABUAAAAAAAAAAAAAAAAAhGYAAHdv cmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQCruOvUfQMAANEHAAARAAAAAAAAAAAA AAAAANhtAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCrYp5ZeQEAAEIDAAAUAAAA AAAAAAAAAAAAAIRxAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQAed0+xbQoA AMRZAAAaAAAAAAAAAAAAAAAAAC9zAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQA BgAIAAAAIQB8UN0dRgEAAGECAAARAAAAAAAAAAAAAAAAANR9AABkb2NQcm9wcy9jb3JlLnhtbFBL AQItABQABgAIAAAAIQC7WT2i1AkAAGJWAAAPAAAAAAAAAAAAAAAAAFGAAAB3b3JkL3N0eWxlcy54 bWxQSwECLQAUAAYACAAAACEAzhBROXECAACOCQAAEgAAAAAAAAAAAAAAAABSigAAd29yZC9mb250 VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhALn0siGNAQAA2QIAABAAAAAAAAAAAAAAAAAA84wAAGRv Y1Byb3BzL2FwcC54bWxQSwUGAAAAAA0ADQBMAwAAto8AAAAA --94eb2c0480e2829ca1053945df26-- From nobody Thu Aug 4 15:52:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08AE12B065 for ; Thu, 4 Aug 2016 15:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqgKqv9AKsEM for ; Thu, 4 Aug 2016 15:52:16 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7897812D093 for ; Thu, 4 Aug 2016 15:52:16 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id h186so90513941pfg.3 for ; Thu, 04 Aug 2016 15:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5ydfTviLOwhMcxoYU5sozIHlcX8JRhXBAjrMbtl8eCA=; b=mvL3RKh/N/ulytvBR5FO8blnbg7EcPL7sQ9AAgXWIhqW0XO8XB6d4sIFKPFVIOA24D Idb1CQEraGFGAbcpI8bdPlWwceSv1bm6tmbANALdyQhY18X0qL7r0c+UMaDLU5mpyjiR hauipvNWcKMSWlj8sluRjpqP4exqiLkNzyEJL5Vj9L3Z/AGjG82I7AG7O8G9MktmIyAb 9PCzbeXMg6mxdF5ol1Uri1ajNgBJ5ohilnUFc7LTpVc2UXOGyZVKowDs/Pq8cptd0kPi WA9uKFRlse/beCVxJTFoBNUnkIsnTDF7+YmNRYHUXV9NGFJqxQ/V+zxv+Vpyu9STEdCh XiMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5ydfTviLOwhMcxoYU5sozIHlcX8JRhXBAjrMbtl8eCA=; b=X3oCmCjwJNp1BfpEI7GioSJbxzEhgdMegZbFfaVSBBPM8eua0qCWqtHLI4MBapHiIR U/xhkw3DyuUIjzI1ZjpFCEESdBTWVcRmjBTcvR/o64ZUordDoPb5V5IuyWgqYXkWOYMR fObjXSWcAx8qtrAgPklVJtQpHTyMhwAjluTJSjI2B3rVAh30ozoJKRL69WUfLUJCND6t gGdSL/C0hTrdRdBslkar9aMKf/EHHnBAEU5MOYmZepM7yYRxcW6FmcC0O7nUmCV4kR9W 4mwK48BNkrkhfpkGEHVWmQRDfb2RoW6fIsZ8SfXUCGWBkfSkYNFbqjxQGlyUJUaX7QoO 6QZA== X-Gm-Message-State: AEkoouuHqMYPeX24Y+MJmYuTkXwu9nGbE44W/fpoWNAS8rx14tyIKf/4Wu6xJPC29cWGBw== X-Received: by 10.98.86.154 with SMTP id h26mr130463331pfj.22.1470351135945; Thu, 04 Aug 2016 15:52:15 -0700 (PDT) Received: from [192.168.178.23] ([118.148.114.58]) by smtp.gmail.com with ESMTPSA id n9sm22797935paz.13.2016.08.04.15.52.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Aug 2016 15:52:15 -0700 (PDT) To: suprita , v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> Date: Fri, 5 Aug 2016 10:52:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Fwd: [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 22:52:20 -0000 Does "IGF" in this context mean the so-called Internet Governance Forum? If so, what does IPv6 deployment have to do with *governance*? Regards Brian Carpenter On 05/08/2016 09:45, suprita wrote: > Apologies for any cross-posting. >=20 > Regards, > Suprita > ---------- Forwarded message ---------- > From: *Wim Degezelle* > > Date: Thu, Aug 4, 2016 at 4:04 AM > Subject: [Bp_ipv6] survey BPF IPv6 - GO ! > To: bp_ipv6@intgovforum.org >=20 >=20 > Hi All=20 >=20 > The questionnaire to collect the case studies for the BPF IPv6 is onlin= e. >=20 > You can use the online google forms questionnaire (link below), the fil= es attached ( .docs and .txt) or google doc > . >=20 > Online questionnaire: > https://docs.google.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mjjx= _MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1 > >=20 > We want to reach out to parties and companies that have successfully de= ployed IPv6 and contribute substantially to the high > deployment rate in their region or country. >=20 > To coordinate, we keep track of our activities and of who is reaching o= ut to who on our brainstorming document > . Please keep updating the table. >=20 > Thank you for your cooperation, >=20 > Kind Regards > Wim >=20 > _________________________ >=20 >=20 > *Wim Degezelle* > *Consultant IGF BPF IPv6* > *Consultant IGF BPF on IXPs* >=20 >=20 >=20 >> Google Forms >> >> Having trouble viewing or submitting this form? >> FILL OUT IN GOOGLE FORMS >> >> >> I've invited you to fill out a form: >> IGF2016 - Best Practice Forum IPv6 - =E2=80=98Understanding the commer= cial and economic incentives behind a successful IPv6 >> deployment=E2=80=99 >> >> IPv6 Best Practice Forum 2016 would like to call for contributions to = understand the economic motivation for IPv6 deployment. >> >> IPv6 is a technical protocol but the decision to adopt IPv6 is not onl= y a technical one, other economic factors play an >> important role. >> >> IPv6 adoption is on the rise - not only in the Global North, but also = in a number of states in the southern hemisphere - and >> there appears to be little correlation to GDP and IPv6. On the other h= and, little documentation exists that analyzes the >> commercial aspects of IPv6 adoption, especially not based on specific,= positive cases of adoption. >> >> By compiling case studies on business cases and economic factors behin= d IPv6 adoption as a best practices document for the >> Internet Governance Forum (IGF) in 2016, it will provide an opportunit= y for a wide range of stakeholders to understand IPv6, >> including those outside the technical community. The contributions wil= l be discussed by participants of IGF IPv6 Best Practice >> Forum, and will be reflected in the output document where appropriate.= The output document will be published on the IGF >> website after IGF2016, which will be held from 6-9 December 2016 in Gu= adalajara, Mexico. >> >> Additional References >> Scope and Goals of the BPF IPv6 2016: >> http://www.intgovforum.org/cms/documents/best-practice-forums/798-scop= e-and-goals-ipv6bpf2016 >> >> >> Join the BPF IPv6 2016 and sign-up to the bp_ipv6@intgovforum mailing = list: >> http://mail.intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org >> = >> >> >> Captionless Image >> >> Powered by >> Google Forms >> >> This content is neither created nor endorsed by Google. >> Report Abuse >> >> - Terms of Service - Additional T= erms >> >> Create your own Google Form >> >=20 >=20 > _______________________________________________ > Bp_ipv6 mailing list > Bp_ipv6@intgovforum.org > http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Aug 4 16:26:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE7C12D747 for ; Thu, 4 Aug 2016 16:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-9NO-9GdcIM for ; Thu, 4 Aug 2016 16:26:10 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC0712D531 for ; Thu, 4 Aug 2016 16:26:10 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id j59so185575429uaj.3 for ; Thu, 04 Aug 2016 16:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tn2NbfufzgszLKYsUFR7qz8Vuq1unsS3B7pwgZ0KMAs=; b=g0vKr2ZlukHDhDdKLake+NOLNtpzfe+LIGIS7CgfP+wB45UurRCChYmrxtqwtfgByC 2YpcnNnEni29Uk5IC3uZpSC5Fv2dFNMwxsdiBua14NqfVuXinEvYQ9l4JylftNymKCdA YMq6ADGidI0DVOZ7ANSOjRIlUUFNaczpmzYSoqVUt7cEUiYT/AlfYQU2qeqNXJuDab9o 3wdWnC6RIhVX2aE+0LHm03Bb22ge8WWeHrfm+IYV9dEaYqq5BQOSj0q3FMXizzz7YD8V LIYXge+vSEAsIvnA3JvUumUYJkCnX6h5lFNLi2eNYpV7L9vuNBzFFwry94XQH/ttcm7u k13w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tn2NbfufzgszLKYsUFR7qz8Vuq1unsS3B7pwgZ0KMAs=; b=HwynPApDTAemGYTzuG85AnWrs3HRD+2mMo9DbfvBcFzt+Xf8gl3jdS0HxU48DFcP+s DhDj68P5mYOM1XWKDMuOgkTn09vh7pqmv9FTwi1vUMSLT9FMHMHvRvU8ZcURK0aMOmt0 3s2aNipQb9a6Alnp9YZh4rzoer3oQdZK1mhiSAzAxyv7KQSVtKRz354JStJNsfJtBhg4 bUoez3+vYGDLXX6at80yZf+mPLUWjswD+6Noi/8ubIUH/uhpcXSq8FuqtBI/uGB3MNCF iY2BOFz78kAig1w8I22vy1tPiWZbcVhyX8vzrGvJGFKMb7GIt1o8bW6lLzl/vBdplq6P +hhQ== X-Gm-Message-State: AEkoouvuIQYAcXmtDipQ0JfTrSDHW0YmIq3nVVN3SklmvSBluj4HiMgE0cNhfBNn1NMupx1knv3plkqcmZX7sg== X-Received: by 10.159.39.3 with SMTP id a3mr39328636uaa.62.1470353169151; Thu, 04 Aug 2016 16:26:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.252.78 with HTTP; Thu, 4 Aug 2016 16:26:08 -0700 (PDT) In-Reply-To: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> References: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> From: suprita Date: Thu, 4 Aug 2016 16:26:08 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c1228ae577d1405394746ad Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 23:26:13 -0000 --94eb2c1228ae577d1405394746ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Brian, Yeah it is The Internet Governance Forum. IPv6 is one of the BPF (Best practices Forum) in IGF 2016. IGF mainy focuses on non-technical people and stakeholders. Since decision to implement IPv6 at times is taken by non-technical higher level executives it is equally important to understand the commercial and economic incentives behind a successful IPv6 deployment. >From the survey introduction : "By compiling case studies on business cases and economic factors behind IPv6 adoption as a best practices document for the Internet Governance Forum (IGF) in 2016, it will provide an opportunity for a wide range of stakeholders to understand IPv6, *including those outside the technical community*. The contributions will be discussed by participants of IGF IPv6 Best Practice Forum, and will be reflected in the output document where appropriate. The output document will be published on the IGF website after IGF2016, which will be held from 6-9 December 2016 in Guadalajara, Mexico." Thank you, Suprita On Thu, Aug 4, 2016 at 3:52 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Does "IGF" in this context mean the so-called Internet Governance Forum? > > If so, what does IPv6 deployment have to do with *governance*? > > Regards > Brian Carpenter > > On 05/08/2016 09:45, suprita wrote: > > Apologies for any cross-posting. > > > > Regards, > > Suprita > > ---------- Forwarded message ---------- > > From: *Wim Degezelle* > > > Date: Thu, Aug 4, 2016 at 4:04 AM > > Subject: [Bp_ipv6] survey BPF IPv6 - GO ! > > To: bp_ipv6@intgovforum.org > > > > > > Hi All > > > > The questionnaire to collect the case studies for the BPF IPv6 is onlin= e. > > > > You can use the online google forms questionnaire (link below), the > files attached ( .docs and .txt) or google doc > > HAvtv1V4uURNWJhFmRNL7NpJGgcoTEtWGHRP8/edit?usp=3Dsharing> . > > > > Online questionnaire: > > https://docs.google.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mjjx= _ > MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1 > > sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1> > > > > We want to reach out to parties and companies that have successfully > deployed IPv6 and contribute substantially to the high > > deployment rate in their region or country. > > > > To coordinate, we keep track of our activities and of who is reaching > out to who on our brainstorming document > > Cq0_ul7TlFJzIU/edit>. Please keep updating the table. > > > > Thank you for your cooperation, > > > > Kind Regards > > Wim > > > > _________________________ > > > > > > *Wim Degezelle* > > *Consultant IGF BPF IPv6* > > *Consultant IGF BPF on IXPs* > > > > > > > >> Google Forms > >> > >> Having trouble viewing or submitting this form? > >> FILL OUT IN GOOGLE FORMS > >> sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1&usp=3Dmail_form_link> > >> > >> I've invited you to fill out a form: > >> IGF2016 - Best Practice Forum IPv6 - =E2=80=98Understanding the commer= cial and > economic incentives behind a successful IPv6 > >> deployment=E2=80=99 > >> sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1&usp=3Dmail_form_link> > >> IPv6 Best Practice Forum 2016 would like to call for contributions to > understand the economic motivation for IPv6 deployment. > >> > >> IPv6 is a technical protocol but the decision to adopt IPv6 is not onl= y > a technical one, other economic factors play an > >> important role. > >> > >> IPv6 adoption is on the rise - not only in the Global North, but also > in a number of states in the southern hemisphere - and > >> there appears to be little correlation to GDP and IPv6. On the other > hand, little documentation exists that analyzes the > >> commercial aspects of IPv6 adoption, especially not based on specific, > positive cases of adoption. > >> > >> By compiling case studies on business cases and economic factors behin= d > IPv6 adoption as a best practices document for the > >> Internet Governance Forum (IGF) in 2016, it will provide an opportunit= y > for a wide range of stakeholders to understand IPv6, > >> including those outside the technical community. The contributions wil= l > be discussed by participants of IGF IPv6 Best Practice > >> Forum, and will be reflected in the output document where appropriate. > The output document will be published on the IGF > >> website after IGF2016, which will be held from 6-9 December 2016 in > Guadalajara, Mexico. > >> > >> Additional References > >> Scope and Goals of the BPF IPv6 2016: > >> http://www.intgovforum.org/cms/documents/best-practice- > forums/798-scope-and-goals-ipv6bpf2016 > >> forums/798-scope-and-goals-ipv6bpf2016> > >> > >> Join the BPF IPv6 2016 and sign-up to the bp_ipv6@intgovforum mailing > list: > >> http://mail.intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org > >> > >> > >> > >> Captionless Image > >> > >> Powered by > >> Google Forms > >> medium=3Dforms_logo&utm_campaign=3Dforms> > >> This content is neither created nor endorsed by Google. > >> Report Abuse > >> sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/reportabuse?source=3Dhttps:// > docs.google.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mjjx_ > MD8ad6uPy3KDOB27yA/viewform?sid%3D52d12258b02865a6%26c% > 3D0%26w%3D1%26token%3D7DFPVVYBAAA.XU5WkhCu4S1SbksCTdmn_Q. > KJEBRgA76zaco4I1cT3j9g> > >> - Terms of Service - Additional > Terms > >> > >> Create your own Google Form forms?usp=3Dmail_form_link> > >> > > > > > > _______________________________________________ > > Bp_ipv6 mailing list > > Bp_ipv6@intgovforum.org > > http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org < > http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org> > > > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > --94eb2c1228ae577d1405394746ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Brian,

Yeah it is The Internet Gov= ernance Forum.=C2=A0

IPv6 is one of the BPF (Best = practices Forum) in IGF 2016. IGF mainy focuses on non-technical people and= stakeholders. Since decision to implement IPv6 at times is taken by non-te= chnical higher level executives it is equally important to understand=C2=A0= the commercial and economic incentives behind a successful IPv6 deployment.=

From the survey introduction :

"By compiling cas= e studies on business cases and economic factors behind IPv6 adoption as a = best practices document for the Internet Governance Forum (IGF) in 2016, it= will provide an opportunity for a wide range of stakeholders to understand= IPv6, including those outside the technical community. The contribu= tions will be discussed by participants of IGF IPv6 Best Practice Forum, an= d will be reflected in the output document where appropriate. The output do= cument will be published on the IGF website after IGF2016, which will be he= ld from 6-9 December 2016 in Guadalajara, Mexico."

Thank you,
Suprita


On Thu, Aug 4, = 2016 at 3:52 PM, Brian E Carpenter <brian.e.carpenter@gmail.com<= /a>> wrote:
Does "IGF"= ; in this context mean the so-called Internet Governance Forum?

If so, what does IPv6 deployment have to do with *governance*?

Regards
=C2=A0 =C2=A0Brian Carpenter

On 05/08/2016 09:45, suprita wrote:
> Apologies for any cross-posting.
>
> Regards,
> Suprita
> ---------- Forwarded message ----------
> From: *Wim Degezelle* <wdegezelle@drmv.be <mailto:wdegezelle@drmv.be>>
> Date: Thu, Aug 4, 2016 at 4:04 AM
> Subject: [Bp_ipv6] survey BPF IPv6 - GO !
> To: bp_ipv6@intgovforum.org <mailto:bp_ipv6@intgovforum.org>
>
>
> Hi All
>
> The questionnaire to collect the case studies for the BPF IPv6 is onli= ne.
>
> You can use the online google forms questionnaire (link below), the fi= les attached ( .docs and .txt) or google doc
> <https://docs.google.com/document/d/1hzk0c_HAvtv1V4u= URNWJhFmRNL7NpJGgcoTEtWGHRP8/edit?usp=3Dsharing> .
>
> Online questionnaire:
> https://docs.google.com/forms/d/e/1FAIpQLSeBjXnyYW= ay2avYsPB_sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&= w=3D1
> <https://docs.google.com/forms/d/e/1FAIpQL= SeBjXnyYWay2avYsPB_sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1>
>
> We want to reach out to parties and companies that have successfully d= eployed IPv6 and contribute substantially to the high
> deployment rate in their region or country.
>
> To coordinate, we keep track of our activities and of who is reaching = out to who on our brainstorming document
> <= https://docs.google.com/document/d/1C7z8MRVBOmBsuWxpl8YivXZWFvksK= Cq0_ul7TlFJzIU/edit>. Please keep updating the table.
>
> Thank you for your cooperation,
>
> Kind Regards
> Wim
>
> _________________________
>
>
> *Wim Degezelle*
> *Consultant IGF BPF IPv6*
> *Consultant IGF BPF on IXPs*
>
>
>
>> Google Forms
>>
>> Having trouble viewing or submitting this form?
>> FILL OUT IN GOOGLE FORMS
>> <https://docs.go= ogle.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1&usp=3Dmail_form_link= >
>>
>> I've invited you to fill out a form:
>> IGF2016 - Best Practice Forum IPv6 - =E2=80=98Understanding the co= mmercial and economic incentives behind a successful IPv6
>> deployment=E2=80=99
>> <https://docs.go= ogle.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1&usp=3Dmail_form_link= >
>> IPv6 Best Practice Forum 2016 would like to call = for contributions to understand the economic motivation for IPv6 deployment= .
>>
>> IPv6 is a technical protocol but the decision to adopt IPv6 is not= only a technical one, other economic factors play an
>> important role.
>>
>> IPv6 adoption is on the rise - not only in the Global North, but a= lso in a number of states in the southern hemisphere - and
>> there appears to be little correlation to GDP and IPv6. On the oth= er hand, little documentation exists that analyzes the
>> commercial aspects of IPv6 adoption, especially not based on speci= fic, positive cases of adoption.
>>
>> By compiling case studies on business cases and economic factors b= ehind IPv6 adoption as a best practices document for the
>> Internet Governance Forum (IGF) in 2016, it will provide an opport= unity for a wide range of stakeholders to understand IPv6,
>> including those outside the technical community. The contributions= will be discussed by participants of IGF IPv6 Best Practice
>> Forum, and will be reflected in the output document where appropri= ate. The output document will be published on the IGF
>> website after IGF2016, which will be held from 6-9 December 2016 i= n Guadalajara, Mexico.
>>
>> Additional References
>> Scope and Goals of the BPF IPv6 2016:
>> http://www.intgovforum.org/cms/documents/best-practice-forums/7= 98-scope-and-goals-ipv6bpf2016
>> <http://www.intgovforum.org/cms/documents/best-practice-foru= ms/798-scope-and-goals-ipv6bpf2016>
>>
>> Join the BPF IPv6 2016 and sign-up to the bp_ipv6@intgovforum mail= ing list:
>> http://mail.intgovforum= .org/mailman/listinfo/bp_ipv6_intgovforum.org
>> <http://mail.= intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org><= br> >>
>>
>>=C2=A0 =C2=A0 =C2=A0Captionless Image
>>
>> Powered by
>> Google Forms
>>=C2=A0 <https://www.google.com/forms/about/?utm_so= urce=3Dproduct&utm_medium=3Dforms_logo&utm_campaign=3Dfor= ms>
>> This content is neither created nor endorsed by G= oogle.
>> Report Abuse
>> <https://docs.google.com/forms/d/e/1FAIpQLSeBjXnyYWay= 2avYsPB_sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/reportabuse?source=3D= https://docs.google.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_= sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?sid%3D52d12258b02865a6%26= c%3D0%26w%3D1%26token%3D7DFPVVYBAAA.XU5WkhCu4S1SbksCTdmn_Q.<= wbr>KJEBRgA76zaco4I1cT3j9g>
>> - Terms of Service <http://www.google.com/account= s/TOS> - Additional Terms <http://www.google.co= m/google-d-s/terms.html>
>>
>> Create your own Google Form <https://d= ocs.google.com/forms?usp=3Dmail_form_link>
>>
>
>
> _______________________________________________
> Bp_ipv6 mailing list
> Bp_ipv6@intgovforum.org= <mailto:Bp_ipv6@intgovforum.= org>
> http://intgovforum.org/mail= man/listinfo/bp_ipv6_intgovforum.org <http://intgovforum.org/mailman/listinfo/bp_ipv6_intg= ovforum.org>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=
>


--94eb2c1228ae577d1405394746ad-- From nobody Thu Aug 4 21:21:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851B912D14A for ; Thu, 4 Aug 2016 21:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etAroFKV0M5d for ; Thu, 4 Aug 2016 21:21:56 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1795212D0DC for ; Thu, 4 Aug 2016 21:21:56 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id fi15so89063373pac.1 for ; Thu, 04 Aug 2016 21:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+EwbN01ohk3eAVAEQZoMQBu3QyIVv4AFhrPrrKw4GLg=; b=WljG0j6Qgd+N3LBJKvCqjCR9M+lgenhN8B7+qN+hx9ETEH6Tmfh7X1yfAW/46iJi8r 2YYDQK1AHi2aexxPv2eypdLl6a0/kMpOOVorl+R/xC2R00Qr8Pm+ohzwQwKEIR89pMKv YIqnlsBczijABOJUndcpzCKL4ScqsfTRMamfO/d+eQo014qIE1VGUeLHHgDNxR2N2TV/ nuurBdrN56Si88Wd0rbTg9b7ghEW00TsXhpY1sbnn26zzASCqMN75RsezWg5gntc6DeR JQx6WRdBWcuBwaeb+/dzKBpIz3R7EaGXGXrldHuS20rqzLJSoAE8nfaDhxj/PnvbIgTJ rlMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+EwbN01ohk3eAVAEQZoMQBu3QyIVv4AFhrPrrKw4GLg=; b=B7uE1O/0FwitBKi4AYu7zDpc7pIqs3lq7+2mmWjquTMnNGNtDxGCjIFZ7K+6B6OzpP xvPSofpU2E0wK/k+4aF8d7QXTNTR7u3Qorq1j08trdG0U5XCL07BTjdh+asUUW9Kn/2J fOj529hE0bJtkfTjEJtEvWeNERkFTE9p838bkk8QTXreOHb+UZ5EGp6unVKhS/QU1YNB D3iKXN3SXDdavD1/1MdrFwtPuYZ+94/tRdZDOAOrFjiwF/bh6o2Vq3YIhpbHr4tFczmg r1ynVmKKgEj1aO7d6abmChBuh+aXkhOtQNZScTQTyRY1LrYAaX5DVn+uimUPCp0V9mE+ BY3g== X-Gm-Message-State: AEkooutf3SYwtuxnho3/TS4TEuFNud4mrgJ6ONuRHgechlGMis97ThiKHP8HaOzyN6/S0g== X-Received: by 10.66.83.6 with SMTP id m6mr5287198pay.80.1470370915501; Thu, 04 Aug 2016 21:21:55 -0700 (PDT) Received: from [192.168.178.23] ([118.148.68.61]) by smtp.gmail.com with ESMTPSA id c125sm23763831pfc.40.2016.08.04.21.21.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Aug 2016 21:21:54 -0700 (PDT) To: suprita References: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <74848250-58bb-c58c-7dca-f87dbe40a85f@gmail.com> Date: Fri, 5 Aug 2016 16:22:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 04:21:58 -0000 Hi Suprita, On 05/08/2016 11:26, suprita wrote: > Dear Brian, >=20 > Yeah it is The Internet Governance Forum. >=20 > IPv6 is one of the BPF (Best practices Forum) in IGF 2016. IGF mainy > focuses on non-technical people and stakeholders. Since decision to > implement IPv6 at times is taken by non-technical higher level executiv= es > it is equally important to understand the commercial and economic > incentives behind a successful IPv6 deployment. All true, and known for many years. But I still have no idea what this ha= s to do with "Internet governance." (This is substantially off-topic for this list so I will say no more.) Regards, Brian >=20 >>From the survey introduction : >=20 > "By compiling case studies on business cases and economic factors behin= d > IPv6 adoption as a best practices document for the Internet Governance > Forum (IGF) in 2016, it will provide an opportunity for a wide range of= > stakeholders to understand IPv6, *including those outside the technical= > community*. The contributions will be discussed by participants of IGF = IPv6 > Best Practice Forum, and will be reflected in the output document where= > appropriate. The output document will be published on the IGF website a= fter > IGF2016, which will be held from 6-9 December 2016 in Guadalajara, Mexi= co." >=20 > Thank you, > Suprita >=20 >=20 > On Thu, Aug 4, 2016 at 3:52 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> Does "IGF" in this context mean the so-called Internet Governance Foru= m? >> >> If so, what does IPv6 deployment have to do with *governance*? >> >> Regards >> Brian Carpenter >> >> On 05/08/2016 09:45, suprita wrote: >>> Apologies for any cross-posting. >>> >>> Regards, >>> Suprita >>> ---------- Forwarded message ---------- >>> From: *Wim Degezelle* = > >>> Date: Thu, Aug 4, 2016 at 4:04 AM >>> Subject: [Bp_ipv6] survey BPF IPv6 - GO ! >>> To: bp_ipv6@intgovforum.org >>> >>> >>> Hi All >>> >>> The questionnaire to collect the case studies for the BPF IPv6 is onl= ine. >>> >>> You can use the online google forms questionnaire (link below), the >> files attached ( .docs and .txt) or google doc >>> > HAvtv1V4uURNWJhFmRNL7NpJGgcoTEtWGHRP8/edit?usp=3Dsharing> . >>> >>> Online questionnaire: >>> https://docs.google.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mj= jx_ >> MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1 >>> > sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1> >>> >>> We want to reach out to parties and companies that have successfully >> deployed IPv6 and contribute substantially to the high >>> deployment rate in their region or country. >>> >>> To coordinate, we keep track of our activities and of who is reaching= >> out to who on our brainstorming document >>> > Cq0_ul7TlFJzIU/edit>. Please keep updating the table. >>> >>> Thank you for your cooperation, >>> >>> Kind Regards >>> Wim >>> >>> _________________________ >>> >>> >>> *Wim Degezelle* >>> *Consultant IGF BPF IPv6* >>> *Consultant IGF BPF on IXPs* >>> >>> >>> >>>> Google Forms >>>> >>>> Having trouble viewing or submitting this form? >>>> FILL OUT IN GOOGLE FORMS >>>> > sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1&usp=3Dmail_form_li= nk> >>>> >>>> I've invited you to fill out a form: >>>> IGF2016 - Best Practice Forum IPv6 - =E2=80=98Understanding the comm= ercial and >> economic incentives behind a successful IPv6 >>>> deployment=E2=80=99 >>>> > sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/viewform?c=3D0&w=3D1&usp=3Dmail_form_li= nk> >>>> IPv6 Best Practice Forum 2016 would like to call for contributions t= o >> understand the economic motivation for IPv6 deployment. >>>> >>>> IPv6 is a technical protocol but the decision to adopt IPv6 is not o= nly >> a technical one, other economic factors play an >>>> important role. >>>> >>>> IPv6 adoption is on the rise - not only in the Global North, but als= o >> in a number of states in the southern hemisphere - and >>>> there appears to be little correlation to GDP and IPv6. On the other= >> hand, little documentation exists that analyzes the >>>> commercial aspects of IPv6 adoption, especially not based on specifi= c, >> positive cases of adoption. >>>> >>>> By compiling case studies on business cases and economic factors beh= ind >> IPv6 adoption as a best practices document for the >>>> Internet Governance Forum (IGF) in 2016, it will provide an opportun= ity >> for a wide range of stakeholders to understand IPv6, >>>> including those outside the technical community. The contributions w= ill >> be discussed by participants of IGF IPv6 Best Practice >>>> Forum, and will be reflected in the output document where appropriat= e. >> The output document will be published on the IGF >>>> website after IGF2016, which will be held from 6-9 December 2016 in >> Guadalajara, Mexico. >>>> >>>> Additional References >>>> Scope and Goals of the BPF IPv6 2016: >>>> http://www.intgovforum.org/cms/documents/best-practice- >> forums/798-scope-and-goals-ipv6bpf2016 >>>> > forums/798-scope-and-goals-ipv6bpf2016> >>>> >>>> Join the BPF IPv6 2016 and sign-up to the bp_ipv6@intgovforum mailin= g >> list: >>>> http://mail.intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org= >>>> >>>> >>>> >>>> Captionless Image >>>> >>>> Powered by >>>> Google Forms >>>> > medium=3Dforms_logo&utm_campaign=3Dforms> >>>> This content is neither created nor endorsed by Google. >>>> Report Abuse >>>> > sm4Y_I_mjjx_MD8ad6uPy3KDOB27yA/reportabuse?source=3Dhttps:// >> docs.google.com/forms/d/e/1FAIpQLSeBjXnyYWay2avYsPB_sm4Y_I_mjjx_ >> MD8ad6uPy3KDOB27yA/viewform?sid%3D52d12258b02865a6%26c% >> 3D0%26w%3D1%26token%3D7DFPVVYBAAA.XU5WkhCu4S1SbksCTdmn_Q. >> KJEBRgA76zaco4I1cT3j9g> >>>> - Terms of Service - Additional= >> Terms >>>> >>>> Create your own Google Form > forms?usp=3Dmail_form_link> >>>> >>> >>> >>> _______________________________________________ >>> Bp_ipv6 mailing list >>> Bp_ipv6@intgovforum.org >>> http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org < >> http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org> >>> >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >=20 From nobody Fri Aug 5 07:25:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E7A12D88F for ; Fri, 5 Aug 2016 07:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gih.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-gwhRxz6cCM for ; Fri, 5 Aug 2016 07:25:40 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [194.33.63.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA49A12D885 for ; Fri, 5 Aug 2016 07:25:39 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id A8331320555; Fri, 5 Aug 2016 15:25:37 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=gih.co.uk; h=subject:to :references:cc:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=mahalo1; bh=fDC8SACRQ OBWg+7vOQT4a6Wd4Zs=; b=vARDIEfbKvcZbkvTmMiMk40VB93N+gkx3FrW5/DK1 BdgjLlKQnyMimjFyFzk7QoLgFt2ETr8qxkdPjt9SHDQFR43CgDN84hTkkgjyIosJ HwyVJ0yyab/A19ZdPXUbyiy2tmlVIEJJkQuwZjnHSMZFVn12CYfzeCibux3IMbbj ek= Received: from [192.168.1.19] (ANice-651-1-184-112.w83-197.abo.wanadoo.fr [83.197.120.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 07BE9320420; Fri, 5 Aug 2016 15:25:36 +0100 (BST) To: Brian E Carpenter , suprita References: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> <74848250-58bb-c58c-7dca-f87dbe40a85f@gmail.com> From: Olivier MJ Crepin-Leblond Message-ID: <250238e6-0311-388f-01c2-0be8902de322@gih.com> Date: Fri, 5 Aug 2016 16:25:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <74848250-58bb-c58c-7dca-f87dbe40a85f@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 14:25:42 -0000 Dear Brian, On 05/08/2016 06:22, Brian E Carpenter wrote: > Hi Suprita, > > On 05/08/2016 11:26, suprita wrote: >> Dear Brian, >> >> Yeah it is The Internet Governance Forum. >> >> IPv6 is one of the BPF (Best practices Forum) in IGF 2016. IGF mainy >> focuses on non-technical people and stakeholders. Since decision to >> implement IPv6 at times is taken by non-technical higher level executives >> it is equally important to understand the commercial and economic >> incentives behind a successful IPv6 deployment. > All true, and known for many years. But I still have no idea what this has > to do with "Internet governance." > > (This is substantially off-topic for this list so I will say no more.) > Agreed a follow-up discussion is off-topic. I'll email you directly in response. In short: pretty much everything on the Internet is affected by governance. Kindest regards, Olivier From nobody Sat Aug 6 10:40:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90FB12D552 for ; Sat, 6 Aug 2016 10:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNcUNN8ZqXIv for ; Sat, 6 Aug 2016 10:40:19 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402A712D520 for ; Sat, 6 Aug 2016 10:40:18 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3C26860F91 for ; Sat, 6 Aug 2016 19:40:16 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 89F0460248; Sat, 6 Aug 2016 19:40:15 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 790713275D; Sat, 6 Aug 2016 19:40:15 +0200 (CEST) Date: Sat, 6 Aug 2016 19:40:15 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20160806174015.GY79185@Space.Net> References: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> <74848250-58bb-c58c-7dca-f87dbe40a85f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74848250-58bb-c58c-7dca-f87dbe40a85f@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 17:40:21 -0000 Hi, On Fri, Aug 05, 2016 at 04:22:01PM +1200, Brian E Carpenter wrote: > All true, and known for many years. But I still have no idea what this has > to do with "Internet governance." Isn't "tell people that successfully deploying IPv6 isn't hard, and they should really go home and do it NOW!" quite an important aspect of "* governance" - as in "telling people what to do"? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Aug 10 17:19:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C8912D0B3 for ; Wed, 10 Aug 2016 17:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.768 X-Spam-Level: X-Spam-Status: No, score=-115.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE_SYsLZqyv2 for ; Wed, 10 Aug 2016 17:19:20 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9721012B02C for ; Wed, 10 Aug 2016 17:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2478; q=dns/txt; s=iport; t=1470874760; x=1472084360; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OWzgXhFymIW4/ZTOdWj8qdnJnCgCP5yGg+SdwZkDbZ8=; b=F0UP5+jHfGjqkvPrE95BiRoA9o9ufjz1z3vZMuiwMO82NWuRm4z2nRfD 7lewi7Z+pWP2xF9A2wDnMQsf5rILJMG9JW4BwsH7F4GKMJYpQ1qvfq0Nj dPpB3TgiDEbAgG/lGIc9LUaiZ1qEBRwAuFfp61/wE2q0NVeVnxs2cUrpp Q=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgAVxKtX/5hdJa1dg0WBUge5I4F9h?= =?us-ascii?q?h0CgWE4FAEBAQEBAQFdJ4ReAQEEARhhBQsCAQgYLjIlAgQOBQ4NiA4IwjQBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEODogiCIJNh2yCLwWZPAGDOoFzg22Fd49DSItsg?= =?us-ascii?q?3cBHjaDem6GUn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,502,1464652800"; d="asc'?scan'208";a="309256897" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Aug 2016 00:19:19 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7B0JJEa024911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Aug 2016 00:19:19 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 Aug 2016 19:19:19 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Wed, 10 Aug 2016 19:19:19 -0500 From: "Fred Baker (fred)" To: Gert Doering Thread-Topic: [v6ops] [Bp_ipv6] survey BPF IPv6 - GO ! Thread-Index: AQHR82YAbFnJuPann0a0KfRgHOjzmA== Date: Thu, 11 Aug 2016 00:19:19 +0000 Message-ID: <938CB937-D94E-4266-AA4E-7B9914846BFE@cisco.com> References: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> <74848250-58bb-c58c-7dca-f87dbe40a85f@gmail.com> <20160806174015.GY79185@Space.Net> In-Reply-To: <20160806174015.GY79185@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_44185766-1741-43B3-A4F8-06DAF264DCBD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 00:19:22 -0000 --Apple-Mail=_44185766-1741-43B3-A4F8-06DAF264DCBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 6, 2016, at 10:40 AM, Gert Doering wrote: >=20 > Hi, >=20 > On Fri, Aug 05, 2016 at 04:22:01PM +1200, Brian E Carpenter wrote: >> All true, and known for many years. But I still have no idea what = this has >> to do with "Internet governance." >=20 > Isn't "tell people that successfully deploying IPv6 isn't hard, and = they > should really go home and do it NOW!" quite an important aspect of > "* governance" - as in "telling people what to do"? Speaking for myself, I suspect that telling people "do this" is a small = part of governance. The problem with doling out solutions is that folks = may validly disagree. I suspect that there are folk on *NOG that would = argue for telling people to pile up NATs, or to translate everything to = NCP, or something else. I'd think in terms of figuring out how to decide what the right thing to = do is, and to together make that change. For example, at an IGF in = Nairobi several years ago, the British Commonwealth governments had a = conversation about normalizing their laws in order to facilitate = criminal investigations that crossed borders. --Apple-Mail=_44185766-1741-43B3-A4F8-06DAF264DCBD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV6vEhkayAOS/EQ8MAQLl3w//ZPsB7daT3tt3xmpAl7fYtGXxmhCFWmbG XuztzGKTusFKLS5m6QWg1xPzLA7C7lXSDAOhO2PuibHwjTvmSd0+ROHWuPo0JVU7 cbIpb7uYAfwEkf4a9Mor9qmD3H3vzkGsp9zRglv6+99Dy1Hh9W3gOJkVp3mFZxoB ON7dAM5TMgcYsPbGFpCCFKDx9LF71HkNBUTnGzxBrG4200YnMejJlsB6X6lKiX0H nzt/eE3YM1DSy4ci5x0V8JvBuX1TKYzxUPZGW6Q0EWo8UD0UliyJsVWVrHdzd4xE xgEj9zraMVJOTQ/TX1Y1REVS0sXHpqOkyp15FbxXRvvd/WiEQ7BFJFjf7pXjao5z mTZ7DBG0pipup9BKYvlgXxZVoxGjJ1qh6FfbwfskB1UXdp/nXLdZNXW+kjFizUy9 7rN0LjgQpzEhL2dd38f66/71+oGQVm38hBeNOakrTmuOXA5g8CgTZEs8uob3+9Mu 2kMoLymHZtvkWPyMFq3ubzwjcsrzE9VV5ltBX3hEdUrv+p3vR1efo4UzOqaOwj4T hBwoBiQTNx0FvVRM1AeUxDmotbyPo2FTwny/OCMMOP6x47dmlAsfgdodKf2ivhF9 R0Rqzgx+e+uI6lSDQt+pibLNUM/DJOIb3joW8z2MtX+3+jufeNY8kRK9+u9nv1eZ KB+Pf6QAc7w= =79IU -----END PGP SIGNATURE----- --Apple-Mail=_44185766-1741-43B3-A4F8-06DAF264DCBD-- From nobody Wed Aug 10 17:37:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9EB12D54D for ; Wed, 10 Aug 2016 17:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpA_nXn7qrXW for ; Wed, 10 Aug 2016 17:37:15 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C4312B019 for ; Wed, 10 Aug 2016 17:37:15 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id k90so96821825uak.1 for ; Wed, 10 Aug 2016 17:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yx+aRzb/5RqGCmFqzey76Q8a/M7DTDxU9K/cOKDLUVg=; b=pf9keu7M2glUQPMtMdy414VaOFfB/qSjH4/fxbhK5L8TQzn93ioBip/oHpSotZXcM2 o8odWdmF6F3fXI2NaympoZDD3Pdf6PACB0s/Nqisvu2V1uKPgtxRc1o2d7pRM2pgSYUW QPiE6oFcjBAaEftlSnybPtUqlf7TMqLbHBX14qelc9ZDJQIJ3Ugt2TPwIiASLAtQx89V MuFADwA7duluO2J+nIp84FM+6bnZ5a/XMbMyAsHn56uw2Wr+xaDv5kCZE8tn4mkiJ7rQ u9VBREqK78T7bE/cnqp4RILGazmmbHlnkZRz9LMfjZqrEGHB/mJhtttJuLS2FEhqsla6 C03A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yx+aRzb/5RqGCmFqzey76Q8a/M7DTDxU9K/cOKDLUVg=; b=jPYyPq9Acb3Hbcim60bfWWkAucvp0oAckph9ol9KWok478HEivv6NA0VzSr18BNr7t S6ZG3i5IFum6KE8cZ6MsQkt7Ju4XRONSY3WlJdYvA9/G2jcegfXrYdMZcLLfkOi5S4w5 ZqwxFO/xNgHRKNC1TsolvwJJ8lNOP6zGV1A8HBC5or4eRA01gBHgjIlmDt7te8UdaZqj Jt9JfwfKBnfwThbACFaAofJ4QeBx8KNEPV3RDaRTGDxlBznVV+ZEvvmZdw/i75jzLWod ukkMA7U3KuCTqZW8mIv0d3Zh+ZpLle8XRm2zggiD/J8AvJjYO2jfHlgPi8bv2hRBcsJW MxEA== X-Gm-Message-State: AEkoousOVkDBEmvxrFW9CvXwKAlZfkhlaQz8Ies+2AVNBQDuzfyjAl9Rk75RDabdGLrC+SRfTgXGi02Kg3Y1rw== X-Received: by 10.31.149.132 with SMTP id x126mr3522711vkd.71.1470875834253; Wed, 10 Aug 2016 17:37:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.46.140 with HTTP; Wed, 10 Aug 2016 17:37:13 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:bc6d:cb91:9c11:8a08] In-Reply-To: <938CB937-D94E-4266-AA4E-7B9914846BFE@cisco.com> References: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> <74848250-58bb-c58c-7dca-f87dbe40a85f@gmail.com> <20160806174015.GY79185@Space.Net> <938CB937-D94E-4266-AA4E-7B9914846BFE@cisco.com> From: George Michaelson Date: Thu, 11 Aug 2016 10:37:13 +1000 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 00:37:18 -0000 If anyone thinks obfuscation of the SRC,DST tuples is a path to anonymity or necessary privacy against their own government, They're lost in the weeds. A talk I went to last year cogently explained how fingerprinting on things like your inter-packet arrival time, and basic HTTP header state info was sufficiently informative to cross-correlate people from around 20 interactions. I accept people *believe* this, and I accept at NOG people *say* this, but I suspect its just wrong. Belief that the volume of logs will work in your favour ignores scale: the scale of the log problem is already above trivial, finding *you* inside this is a compliance issue as Fred says, which won't go away just because you pushed the price up. (I'm not attacking Fred, or what he says. I think I'm arguing against this NAT argument surfacing as a first-class position with respect to governance) -G On Thu, Aug 11, 2016 at 10:19 AM, Fred Baker (fred) wrote: > >> On Aug 6, 2016, at 10:40 AM, Gert Doering wrote: >> >> Hi, >> >> On Fri, Aug 05, 2016 at 04:22:01PM +1200, Brian E Carpenter wrote: >>> All true, and known for many years. But I still have no idea what this = has >>> to do with "Internet governance." >> >> Isn't "tell people that successfully deploying IPv6 isn't hard, and they >> should really go home and do it NOW!" quite an important aspect of >> "* governance" - as in "telling people what to do"? > > Speaking for myself, I suspect that telling people "do this" is a small p= art of governance. The problem with doling out solutions is that folks may = validly disagree. I suspect that there are folk on *NOG that would argue fo= r telling people to pile up NATs, or to translate everything to NCP, or som= ething else. > > I'd think in terms of figuring out how to decide what the right thing to = do is, and to together make that change. For example, at an IGF in Nairobi = several years ago, the British Commonwealth governments had a conversation = about normalizing their laws in order to facilitate criminal investigations= that crossed borders. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Aug 10 17:54:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3AD12D83A for ; Wed, 10 Aug 2016 17:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.768 X-Spam-Level: X-Spam-Status: No, score=-115.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POc9b21HHAIw for ; Wed, 10 Aug 2016 17:54:19 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A7512D77E for ; Wed, 10 Aug 2016 17:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1985; q=dns/txt; s=iport; t=1470876859; x=1472086459; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y4jgC6hV/t1tlnSAq3gB8PJ2q2jr91Ov3Ml1KtnxmkQ=; b=LCHf2o+3Aa6d3omXfTO/yGceesjl0wt6Q2XIu/Lpf2QjDYy6lXkeXr0l WX47qEoBWKM5sy0U7L2+vRQFRfP8DqMwtkUmKHSikZBCah7JTauoudDT/ KTMa0zBLssPcAIJBLtV4KuW4YTCNc6/u+ezry4gag/n0WK+jDE3kyYk69 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFBQANzKtX/40NJK1dg0WBUge5I4F9h?= =?us-ascii?q?h0CgWI5EwEBAQEBAQFdJ4ReAQEEARhhBQsCAQgOCi4yJQIEDgUODYgOCMI7AQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDg6IIgiCTYdsgi8FmTwBgzqBc4lkgVWNbkiLb?= =?us-ascii?q?IN3ASADMYN6boZSfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,502,1464652800"; d="asc'?scan'208";a="309265188" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2016 00:54:18 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7B0sIjU026371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Aug 2016 00:54:18 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 Aug 2016 19:54:17 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Wed, 10 Aug 2016 19:54:17 -0500 From: "Fred Baker (fred)" To: George Michaelson Thread-Topic: [v6ops] [Bp_ipv6] survey BPF IPv6 - GO ! Thread-Index: AQHR82YAbFnJuPann0a0KfRgHOjzmA== Date: Thu, 11 Aug 2016 00:54:17 +0000 Message-ID: <301A5AEC-4279-40F8-9246-638761E87F43@cisco.com> References: <87302609-af46-522e-f23b-f660f98ddbbe@gmail.com> <74848250-58bb-c58c-7dca-f87dbe40a85f@gmail.com> <20160806174015.GY79185@Space.Net> <938CB937-D94E-4266-AA4E-7B9914846BFE@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_14B46A4F-C8E6-414E-ADD9-7604C2128B2C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] [Bp_ipv6] survey BPF IPv6 - GO ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 00:54:20 -0000 --Apple-Mail=_14B46A4F-C8E6-414E-ADD9-7604C2128B2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 10, 2016, at 5:37 PM, George Michaelson = wrote: >=20 > I'm not attacking Fred, or what he says. I think I'm arguing against > this NAT argument surfacing as a first-class position with respect to > governance And on the protocol of choice, I'm not at all sure you and I disagree. = I'm just not sure that mandating a specific solution - even if I agree = with it - is the right governance option. In a discussion of governance, = I'm far more interested in "how to govern" than "what rules to lay = down". I suspect that if we can work out how to govern, what rules make = sense will be a lot easier to arrive at. --Apple-Mail=_14B46A4F-C8E6-414E-ADD9-7604C2128B2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV6vMuEayAOS/EQ8MAQKKAQ/+K6MlpqEgzeNCLmlgGRsf9M9Sn/8tXmGb vK9KX0VrO3SUsRed/MhQhkB2mqKPWKmdG1tQhnsxmsxKYHeyDZMJzeO88jdDPyUS VdLo4NH2Mg3MiUtj2TE9VC3dEY/2WvXzpukUILyKkGentzx1tQU4rvjHnOUE47Sy y11Lw3uiWA/m9h3zIlm2gUR0q05ScD+qkw2NXlZ7IN+ikC+ef1Xycqmh7TUUf620 WIAgu4sy32e/CGxo56bR2Bo0LTth+YNQf5qjI9jAuEAgUlVglfg6HCaOrSUmREDx M020vKnJYYjiCr6nrboFuUO7wJl45cQvlJg9IllhDXcd9giXSn0690xRUWCtnh3j vI74ZwRrPpYalPP+Lkdr20TmsBg8Yzl3WcPshuuRibi3dJBH07fuytm1LgRV1gsj rwpttUMbjc6fh96kNw+pxfIRBYrHWRNl+j5dk36F+cwjK+6nKtotBSgX/PrrZqlf vaaeKRw0YO2knSR9Y04xL2zKIvOzHMTA00ZtuSjmzEUlEY2hhipPgAp5NThbw/wm RRhvFpzCRCvnsGL6Sbb0+Ef04ViBL/4TnKThLZEgEpqDdx9y5FvECUPcLVCJyY9u z03k4baKdBQC1runK1Q6eUwXOAkR37NXHAozZZ8F9BcdADjbyfbR/T1IiYfQfhrq MGIFniTPxkc= =OPyL -----END PGP SIGNATURE----- --Apple-Mail=_14B46A4F-C8E6-414E-ADD9-7604C2128B2C-- From nobody Mon Aug 15 02:26:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB93012B02B for ; Mon, 15 Aug 2016 02:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtXeboM0gNxh for ; Mon, 15 Aug 2016 02:26:39 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B95612D108 for ; Mon, 15 Aug 2016 02:26:39 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f65so80149226wmi.0 for ; Mon, 15 Aug 2016 02:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=DP9B+WfTDBvKUxD3kFKjvNlo2r6quPQ62sWvPcPqb1w=; b=MmmdXOgMWfsfEVUmJGOF+P7yoIgoJacVTPLXyfQjSxPiTIONI9E0VgrV2/a9aOFG5O WLc39DTnPYjQwShjMvTDYR1QYIaykgNqQMt01SQxXZVhKGOI/ADpeLOU9tJiGGa/v9m6 gqk+BB8psJ6WeDT/a5EvTkJPz550XWwBABWOuSqcQydxmYRAdAV0DIyvXVoN+rqkCjCN VHsZZabbDnLR8FmMScvOY4VbSjD/9911o426l2he5kMz8YhGR7O6VRI1x/gGsc9Zcgjp vVL/CgnGVOkyqWnVZHEvG7fSNRkI3PKG3gK9VO+VritLGYSbOj6FR4tN1DwRVI0UTUjN XhjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DP9B+WfTDBvKUxD3kFKjvNlo2r6quPQ62sWvPcPqb1w=; b=Ss9S3nTkBZbdIpXVZXIKbfJ/FPe0rTW0hCsTr0SyIPcqghmc8xEduFWRTmvP7bW6Ws u1C/TU6SXiupniOH5h+iXoxtHmmtDNd+TTiNhosXL4DdYBkfZfTGP3rceUVDXIYrErqG oAY3fyGJq0OO+pzVuW09EIo7/REIIg4fiqKGF5fWdM5x3wiNETZi85isfZo0nDYZsXMK +4+xItuy/9d64BxHXryJId7hEBY/Kh8wID94iRUjQl1WyuONXglfN1MxkllnBUhKK9/u Or+jTYOTre9O2Aj4AQXQrec2zGV0k3Z9iVycCYzegNgH5PSBDPZERjw6Nqo9meQJmpTV H7sw== X-Gm-Message-State: AEkooutAMRQ7CzEuYvJN8dm3n39g65wkboJB4XtI+rQ+6RhBg/C8mwQey3SZ5l7H/DGH8ElFUvwYX7sBq5Kbaw== X-Received: by 10.194.139.34 with SMTP id qv2mr30085505wjb.50.1471253197571; Mon, 15 Aug 2016 02:26:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.74.8 with HTTP; Mon, 15 Aug 2016 02:26:07 -0700 (PDT) From: Edwin Cordeiro Date: Mon, 15 Aug 2016 11:26:07 +0200 Message-ID: To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=bcaec5101e0b374ebe053a18d42b Archived-At: Subject: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 09:26:42 -0000 --bcaec5101e0b374ebe053a18d42b Content-Type: text/plain; charset=UTF-8 Document: draft-templin-v6ops-pdhost-02 Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Naveen K Lakshman (v6ops draft review team) Review Date: 15/aug/2016 Summary: The draft provides guidelines for a host that receives a prefix through DHCPv6-PD and want to use addresses from this prefix on its interface, specifically in an AERO [RFC 6706] environment Comments: The draft clearly specify how a host should behave when receiving a prefix delegation through DHCPv6-PD and want to use addresses from the received prefix on the interface it used to request the DHCP-PD. Unfortunately the draft fails to clarify where such behavior is needed and acceptable. Example of use cases would be a great improvement to provide such context. Another recommended improvement would be the inclusion of a diagram that should show how the proposed behavior differs from the current specification of IPv6 Prefix Options for DHCPv6 - RFC 3633 ( https://tools.ietf.org/html/rfc3633#section-5.1) The draft-templin-v6ops-pdhost-02 tries to sort an ambiguity of RFC 3633, that says "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router", but RFC 3633 doesn't specify if addresses from the prefix may be used in the receiving interface. We are not sure if the current specification from RFC 3633 allows or not the use of addresses from the received prefix delegation on the interface that received the prefix delegation. Recommendation: With a better introduction to the need for this document, we recommend it to be adopted as working group document, if operators say "we plan to use this proposal" BR, Edwin Cordeiro --bcaec5101e0b374ebe053a18d42b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Document: draft-templin-v6ops-pdhost-02<= /font>

Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Naveen = K Lakshman (v6ops draft review team)

Review Date: 15/aug/2016=

<= /font>
Summary: The draft provides guidelines for a host that receives a prefix t= hrough DHCPv6-PD and want to use addresses from this prefix on its interfac= e, specifically in an AERO [RFC 6706] environment

Comments: The draf= t clearly specify how a host should behave when receiving a prefix delegati= on through DHCPv6-PD and want to use addresses from the received prefix on = the interface it used to request the DHCP-PD. Unfortunately the draft fails= to clarify where such behavior is needed and acceptable. Example of use ca= ses would be a great improvement to provide such context.
Another recommen= ded improvement would be the inclusion of a diagram that should show how th= e proposed behavior differs from the current specification of IPv6 Prefix O= ptions for DHCPv6 - RFC 3633 (https://tools.ietf.org/html/rfc3633#s= ection-5.1)
The draft-templin-v6ops-pdhost-02 tries to sort an ambigui= ty of RFC 3633, that says "the requesting router MUST NOT assign any d= elegated prefixes or subnets from the delegated prefix(es) to the link thro= ugh which it received the DHCP message from the delegating router", bu= t RFC 3633 doesn't specify if addresses from the prefix may be used in = the receiving interface. We are not sure if the current specification from = RFC 3633 allows or not the use of addresses from the received prefix delega= tion on the interface that received the prefix delegation.

Recommend= ation: With a better introduction to the need for this document, we recomme= nd it to be adopted as working group document, if operators say "we pl= an to use this proposal"

BR,

Edwin Cordeiro
--bcaec5101e0b374ebe053a18d42b-- From nobody Mon Aug 15 03:06:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DCD12D124 for ; Mon, 15 Aug 2016 03:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoWhaVRsAhxf for ; Mon, 15 Aug 2016 03:06:21 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076CE12B037 for ; Mon, 15 Aug 2016 03:06:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 743D9A2; Mon, 15 Aug 2016 12:06:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1471255577; bh=y47O1kwACuaPFB1vEpCgXShOdFDtji/BJhldHKhA3Fs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Kk8TZps0x+i33MDuQWyrE7SZHOU35L/7CSaSMRKAT0etJqByY+Yo5EnP7vmHajIu3 7Myja1Rso7zejAu3TenUcLln9YYnxpgbnEG8Qly/NPRkliyYntaR9adxJp0i+EygBA aQ3Gpvx3ORB9i129V3pE0yqjmkK871XwAyuM7j3c= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6D8CFA1; Mon, 15 Aug 2016 12:06:17 +0200 (CEST) Date: Mon, 15 Aug 2016 12:06:17 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> Message-ID: References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 10:06:23 -0000 On Fri, 22 Jul 2016, Brian E Carpenter wrote: > Sure. But nobody ever proposed that - all the host can do is select a > source/destination address pair. That impacts where the packets flow but > doesn't touch routing policy itself. I never understood this claim, but I've heard it multiple times. In my world, the source address chosen, and what outgoing router is chosen, are two completely different things. It's only lately (past few years) with src/dst routing being mentioned, that this is now potentially changing. Example: R1 - H1 - R2 R1 is sending RAs with prio high. R2 is sending RAs with prio low. Host application chooses address from H1-R2 link. As far as I know, "all" hosts today will send out H1-R2 address sourced packet via R1. What am I missing? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Aug 15 05:13:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6876D12DC81 for ; Mon, 15 Aug 2016 05:13:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcODzpThW0ot for ; Mon, 15 Aug 2016 05:13:34 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 886F412D901 for ; Mon, 15 Aug 2016 05:13:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bZGll-0000DsC; Mon, 15 Aug 2016 14:13:29 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> In-reply-to: Your message of "Mon, 15 Aug 2016 12:06:17 +0200 (CEST) ." Date: Mon, 15 Aug 2016 14:13:27 +0200 Archived-At: Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 12:13:36 -0000 >It's only lately (past few years) with src/dst routing being mentioned, >that this is now potentially changing. > >Example: > >R1 - H1 - R2 > >R1 is sending RAs with prio high. R2 is sending RAs with prio low. Host >application chooses address from H1-R2 link. As far as I know, "all" hosts >today will send out H1-R2 address sourced packet via R1. > >What am I missing? I modified my stack to do full src/dst routing for the router part, but not the host part (i.e. hosts get told by routers where to send packets using redirects). In some deployment situations where routers don't talk to each other it makes sense for hosts to do src/dst routing as well. There are many IPv4 deployments where a NAT box transparently handles multiple upstreams that perform BCP38 ingress filtering. Obviously, you want to support multiple independent upstreams in IPv6 as well, preferably without having to introduce a single central routing box. So that leads to a model where hosts have to be aware of which default router to use for a particular source prefix. I don't see the issue here. With redirects, routers are still in full control of where packets go. Also in RAs, all routers can mark themselves as available for all prefixes. So it is a feature, that in my opinion hosts should implement, that makes it easiers to have multiple upstreams in an IPv6 enviroment, while still allowing routers to be in control of how hosts behave. From nobody Mon Aug 15 05:29:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B442712DA67 for ; Mon, 15 Aug 2016 05:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNoPYH1wvgtF for ; Mon, 15 Aug 2016 05:29:16 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD5712DA29 for ; Mon, 15 Aug 2016 05:29:16 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id u186so36174365ita.0 for ; Mon, 15 Aug 2016 05:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3DcHZqw1hYQmq38nfzAL+x06LB640w200KRi9n103+Q=; b=P6ljUGyg0hG7lSCjnPRp/U+QvQ0w/NhpXy36kgKPRAqYEwcqNsbo2sqQYuUi1k2oUH iHNErrZ4N9fzj2uVRBTbVFWgb+s6wCF8W2PWUrIAoq4L4gahIntkjD26hC0G1ipAxUl4 Z9AKpjIiq+ZMKdenSKWPSANeB4fppeEcpPFlsiqn902vWZb/4kLcxjyTX9+qHq3Qqgko WULO3B7tb6IKT6cnAuxgg3q6V1S4yTbZrFSGF2PsIqu1dtM9k+O4Z+PYXMTkt0NUKElK gMgfTTLvoe8+Bh70vFtKyJ8/HnIXk8W2uY26SYgABMys65+MRaQxolq+yJ9xcXUS9g43 97dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3DcHZqw1hYQmq38nfzAL+x06LB640w200KRi9n103+Q=; b=Mi+vaJ4JGN34PRp5BXIfUvR05+GGvs8iSfZKIMD0aZGpS3zXVbAyiCJrzxMBFOCTPQ MoTGFDn/faMVB+Shqr3GAvAtMHIu9Y0DLL7o0kpRHLKsOCn/cYdZUWgP+51f9eq1qHCi C8cLsP2OBi0et7y69CJaqxoC0xYO6vf2ITpB6U0V1xd62M8LUPclrIk6Ewwk9D/SASi0 dpqr/IAgRQNyVT0YL+Pd3hlcRtPULyvGhxrzTHFMsEY4G5V+68Q7cLRCpZOVSn14oE83 +zDh+hhwBFx8N/SPNgYSuSu+gcEV7EHCxotTwZtDjbp8FTEWUZBEdjztnEzil1TqnPBk aeqg== X-Gm-Message-State: AEkoouvYFidH8Vou2oTKcBx6hkfAnvksrBRFupDmrkToXgfXfA7s8ldu/iM3DwD8G1iU/wAFesX/m/qDTfkRs8ZC X-Received: by 10.36.9.196 with SMTP id 187mr11433573itm.82.1471264155645; Mon, 15 Aug 2016 05:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.26.72 with HTTP; Mon, 15 Aug 2016 05:28:55 -0700 (PDT) In-Reply-To: <20160721172033.GI79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> From: Lorenzo Colitti Date: Mon, 15 Aug 2016 21:28:55 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1143e2085e8f13053a1b614d Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 12:29:18 -0000 --001a1143e2085e8f13053a1b614d Content-Type: text/plain; charset=UTF-8 On Fri, Jul 22, 2016 at 2:20 AM, Gert Doering wrote: > In a fully controlled environment, you don't want the hosts to make > decisions (unless directed by configured policy). I just wanted to > point out that "enterprise" and "SOHO" are really totally different > problem spaces regarding multihoming and "who makes decisions?". A fully controlled environment is one where the enterprise controls the hosts. An environment where the enterprise controls the network but not the hosts is not a controlled environment. Which one are you talking about here? --001a1143e2085e8f13053a1b614d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 22, 2016 at 2:20 AM, Gert Doering <gert@space.net> wrot= e:
In a fully controlled environment, you= don't want the hosts to make
decisions (unless directed by configured policy).=C2=A0 I just wanted to point out that "enterprise" and "SOHO" are really total= ly different
problem spaces regarding multihoming and "who makes decisions?".<= /blockquote>

A fully controlled environment is one where= the enterprise controls the hosts.
An environment where the ente= rprise controls the network but not the hosts is not a controlled environme= nt.
Which one are you talking about here?
--001a1143e2085e8f13053a1b614d-- From nobody Mon Aug 15 09:04:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E62F12D0E0 for ; Mon, 15 Aug 2016 09:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.167 X-Spam-Level: X-Spam-Status: No, score=-8.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSL6lxIaXDBD for ; Mon, 15 Aug 2016 09:04:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6B712B05B for ; Mon, 15 Aug 2016 09:04:26 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7FG3qol025568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Aug 2016 09:03:54 -0700 (PDT) To: Mikael Abrahamsson , Brian E Carpenter References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> From: Joe Touch Message-ID: Date: Mon, 15 Aug 2016 09:03:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:04:28 -0000 On 8/15/2016 3:06 AM, Mikael Abrahamsson wrote: > Example: > > R1 - H1 - R2 > > R1 is sending RAs with prio high. R2 is sending RAs with prio low. > Host application chooses address from H1-R2 link. As far as I know, > "all" hosts today will send out H1-R2 address sourced packet via R1. > > What am I missing? I'm missing it too. In this case, H1 apps MUST be able to select the source address (either based on R1 or R2 RAs). Where the packet goes after that depends on the forwarding tables on H1, redirects from R1 and R2, etc. I.e., source IP MUST be application-selectable, but path might not. Joe From nobody Mon Aug 15 10:49:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E817812D1BD for ; Mon, 15 Aug 2016 10:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2diDXWd4WjxB for ; Mon, 15 Aug 2016 10:49:55 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1349128E19 for ; Mon, 15 Aug 2016 10:49:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7FHntOg017131; Mon, 15 Aug 2016 10:49:55 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7FHnr09017103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 15 Aug 2016 10:49:53 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 15 Aug 2016 10:49:52 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 15 Aug 2016 10:49:52 -0700 From: "Templin, Fred L" To: Edwin Cordeiro , IPv6 Ops WG Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9tcrwwccPUlJiEK61fgu5QfdmKBKRsFg Date: Mon, 15 Aug 2016 17:49:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_f573bcf518044805ae6031515fe32277XCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:49:58 -0000 --_000_f573bcf518044805ae6031515fe32277XCH150505nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRWR3aW4sDQoNClRoYW5rIHlvdSBmb3IgcG9zdGluZyB0aGlzIHJldmlldy4gU2VlIGJl bG93IGZvciBmb2xsb3ctdXAgZGlzY3Vzc2lvbiBmb3IgdGhlDQpwb2ludHMgeW91IGhhdmUgcmFp c2VkOg0KDQoNCsOYICBTdW1tYXJ5OiBUaGUgZHJhZnQgcHJvdmlkZXMgZ3VpZGVsaW5lcyBmb3Ig YSBob3N0IHRoYXQgcmVjZWl2ZXMgYSBwcmVmaXggdGhyb3VnaCBESENQdjYtUEQNCg0KWWVzLCB0 aGF0IGlzIGFjY3VyYXRlIGZvciB0aGUgZHJhZnQgaW4gaXRzIGN1cnJlbnQgZm9ybSwgYnV0IEkg d291bGQgbGlrZSB0byBjaGFuZ2UgdGhlDQpkcmFmdCB0byBzYXkgdGhhdCBpdCBhcHBsaWVzIHRv IHByZWZpeCBkZWxlZ2F0aW9ucyByZWNlaXZlZCB0aHJvdWdoIGFueSBtZWFucyBhbmQgbm90DQpq dXN0IERIQ1B2NiBQRC4gSXQgd291bGQgc2F5IHRoYXQgYSBwcmVmaXggZGVsZWdhdGlvbiBpbmNs dWRlcyBhIGNvbW11bmljYXRpb24gb2YNCnRoZSBwcmVmaXggZnJvbSB0aGUgbmV0d29yayB0byB0 aGUgaG9zdCwgYW5kIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHByZWZpeCBpbiB0aGUNCm5ldHdv cmsgcm91dGluZyBzeXN0ZW0uIERIQ1B2NiBQRCB3b3VsZCB0aGVuIGJlIGNpdGVkIGFzIG9ubHkg b25lIGV4YW1wbGUuDQoNCg0Kw5ggIGFuZCB3YW50IHRvIHVzZSBhZGRyZXNzZXMgZnJvbSB0aGlz IHByZWZpeCBvbiBpdHMgaW50ZXJmYWNlLCBzcGVjaWZpY2FsbHkgaW4gYW4gQUVSTyBbUkZDIDY3 MDZdIGVudmlyb25tZW50DQoNClRoZSBjb3JyZWN0IHJlZmVyZW5jZSBmb3IgQUVSTyBpcyDigJhk cmFmdC10ZW1wbGluLWFlcm9saW5r4oCZLiBCdXQsIHRoYXQgc2hvdWxkIGJlDQp1bmRlcnN0b29k IGFzIG9ubHkgb25lIGV4YW1wbGUg4oCTIHRoZSBzYW1lIHRlY2huaXF1ZXMgY2FuIGFwcGx5IHRv IGFueSBvdGhlcg0KbGluayB0eXBlcyBpbmNsdWRpbmcsIEV0aGVybmV0LCBXaWZpLCBldGMuDQoN Cg0Kw5ggIENvbW1lbnRzOiBUaGUgZHJhZnQgY2xlYXJseSBzcGVjaWZ5IGhvdyBhIGhvc3Qgc2hv dWxkIGJlaGF2ZSB3aGVuIHJlY2VpdmluZyBhIHByZWZpeCBkZWxlZ2F0aW9uDQoNCsOYICB0aHJv dWdoIERIQ1B2Ni1QRCBhbmQgd2FudCB0byB1c2UgYWRkcmVzc2VzIGZyb20gdGhlIHJlY2VpdmVk IHByZWZpeCBvbiB0aGUgaW50ZXJmYWNlIGl0IHVzZWQNCg0Kw5ggIHRvIHJlcXVlc3QgdGhlIERI Q1AtUEQuIFVuZm9ydHVuYXRlbHkgdGhlIGRyYWZ0IGZhaWxzIHRvIGNsYXJpZnkgd2hlcmUgc3Vj aCBiZWhhdmlvciBpcyBuZWVkZWQNCg0Kw5ggIGFuZCBhY2NlcHRhYmxlLiBFeGFtcGxlIG9mIHVz ZSBjYXNlcyB3b3VsZCBiZSBhIGdyZWF0IGltcHJvdmVtZW50IHRvIHByb3ZpZGUgc3VjaCBjb250 ZXh0Lg0KDQpIZXJlIGlzIHNvbWUgcHJvcG9zZWQgdGV4dDoNCg0KICAg4oCcVGhpcyBhcHByb2Fj aCBpcyBhcHBsaWNhYmxlIHRvIGEgd2lkZSB2YXJpZXR5IG9mIHVzZSBjYXNlcy4gIEZvciBleGFt cGxlLA0KICAgaXQgY2FuIGJlIHVzZWQgdG8gY29vcmRpbmF0ZSB0aGUgVmlydHVhbCBQcml2YXRl IE5ldHdvcmsgKFZQTikgbGlua3Mgb2YNCiAgIG1vYmlsZSBkZXZpY2VzIChlLmcuLCBjZWxscGhv bmVzLCB0YWJsZXRzLCBsYXB0b3AgY29tcHV0ZXJzLCBldGMuKQ0KICAgdGhhdCBjb25uZWN0IGlu dG8gYSBob21lIGVudGVycHJpc2UgbmV0d29yayB2aWEgcHVibGljIGFjY2Vzcw0KICAgbmV0d29y a3MuICBUaGUgYXBwcm9hY2ggY2FuIGFsc28gYmUgYXBwbGllZCB0byBhdmlhdGlvbiBhcHBsaWNh dGlvbnMNCiAgIGZvciBib3RoIG1hbm5lZCBhbmQgdW5tYW5uZWQgYWlyY3JhZnQgd2hlcmUgdGhl IGFpcmNyYWZ0IGlzIHRyZWF0ZWQNCiAgIGFzIGEgbW9iaWxlIGhvc3QuIFZhcmlvdXMgb3RoZXIg dXNlIGNhc2VzIGFyZSBhbHNvIGluIHNjb3BlLuKAnQ0KDQoNCsOYICBBbm90aGVyIHJlY29tbWVu ZGVkIGltcHJvdmVtZW50IHdvdWxkIGJlIHRoZSBpbmNsdXNpb24gb2YgYSBkaWFncmFtIHRoYXQg c2hvdWxkIHNob3cNCg0Kw5ggIGhvdyB0aGUgcHJvcG9zZWQgYmVoYXZpb3IgZGlmZmVycyBmcm9t IHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gb2YgSVB2NiBQcmVmaXggT3B0aW9ucyBmb3INCg0K w5ggIERIQ1B2NiAtIFJGQyAzNjMzIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYz MyNzZWN0aW9uLTUuMSkNCg0KSSB3b3VsZCBiZSBoYXBweSB0byBpbmNsdWRlIGEgZGlhZ3JhbS4g VGhhbmsgeW91IGZvciB0aGUgc3VnZ2VzdGlvbi4NCg0KDQrDmCAgVGhlIGRyYWZ0LXRlbXBsaW4t djZvcHMtcGRob3N0LTAyIHRyaWVzIHRvIHNvcnQgYW4gYW1iaWd1aXR5IG9mIFJGQyAzNjMzLCB0 aGF0IHNheXMNCg0Kw5ggICJ0aGUgcmVxdWVzdGluZyByb3V0ZXIgTVVTVCBOT1QgYXNzaWduIGFu eSBkZWxlZ2F0ZWQgcHJlZml4ZXMgb3Igc3VibmV0cyBmcm9tIHRoZQ0KDQrDmCAgZGVsZWdhdGVk IHByZWZpeChlcykgdG8gdGhlIGxpbmsgdGhyb3VnaCB3aGljaCBpdCByZWNlaXZlZCB0aGUgREhD UCBtZXNzYWdlIGZyb20gdGhlDQoNCsOYICBkZWxlZ2F0aW5nIHJvdXRlciIsIGJ1dCBSRkMgMzYz MyBkb2Vzbid0IHNwZWNpZnkgaWYgYWRkcmVzc2VzIGZyb20gdGhlIHByZWZpeCBtYXkgYmUNCg0K w5ggIHVzZWQgaW4gdGhlIHJlY2VpdmluZyBpbnRlcmZhY2UuIFdlIGFyZSBub3Qgc3VyZSBpZiB0 aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIGZyb20NCg0Kw5ggIFJGQyAzNjMzIGFsbG93cyBvciBu b3QgdGhlIHVzZSBvZiBhZGRyZXNzZXMgZnJvbSB0aGUgcmVjZWl2ZWQgcHJlZml4IGRlbGVnYXRp b24NCg0Kw5ggIG9uIHRoZSBpbnRlcmZhY2UgdGhhdCByZWNlaXZlZCB0aGUgcHJlZml4IGRlbGVn YXRpb24uDQoNClNob3VsZCB0aGlzIGRyYWZ0IHVwZGF0ZSBSRkMzNjMzIChpZiBhcHByb3ZlZCk/ DQoNClRoYW5rcyAtIEZyZWQNCg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFZHdpbiBDb3JkZWlybw0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMTUsIDIwMTYgMjoyNiBBTQ0KVG86IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4NClN1 YmplY3Q6IFt2Nm9wc10gUmV2aWV3IGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAyDQoNCkRv Y3VtZW50OiBkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0wMg0KDQpSZXZpZXdlcnM6IFJpY2Fy ZG8gUGVsYWV6LU5lZ3JvLCBFZHdpbiBDb3JkZWlybywgRnJlZCBCYWtlciwgTmF2ZWVuIEsgTGFr c2htYW4gKHY2b3BzIGRyYWZ0IHJldmlldyB0ZWFtKQ0KDQpSZXZpZXcgRGF0ZTogMTUvYXVnLzIw MTYNCg0KU3VtbWFyeTogVGhlIGRyYWZ0IHByb3ZpZGVzIGd1aWRlbGluZXMgZm9yIGEgaG9zdCB0 aGF0IHJlY2VpdmVzIGEgcHJlZml4IHRocm91Z2ggREhDUHY2LVBEIGFuZCB3YW50IHRvIHVzZSBh ZGRyZXNzZXMgZnJvbSB0aGlzIHByZWZpeCBvbiBpdHMgaW50ZXJmYWNlLCBzcGVjaWZpY2FsbHkg aW4gYW4gQUVSTyBbUkZDIDY3MDZdIGVudmlyb25tZW50DQoNCkNvbW1lbnRzOiBUaGUgZHJhZnQg Y2xlYXJseSBzcGVjaWZ5IGhvdyBhIGhvc3Qgc2hvdWxkIGJlaGF2ZSB3aGVuIHJlY2VpdmluZyBh IHByZWZpeCBkZWxlZ2F0aW9uIHRocm91Z2ggREhDUHY2LVBEIGFuZCB3YW50IHRvIHVzZSBhZGRy ZXNzZXMgZnJvbSB0aGUgcmVjZWl2ZWQgcHJlZml4IG9uIHRoZSBpbnRlcmZhY2UgaXQgdXNlZCB0 byByZXF1ZXN0IHRoZSBESENQLVBELiBVbmZvcnR1bmF0ZWx5IHRoZSBkcmFmdCBmYWlscyB0byBj bGFyaWZ5IHdoZXJlIHN1Y2ggYmVoYXZpb3IgaXMgbmVlZGVkIGFuZCBhY2NlcHRhYmxlLiBFeGFt cGxlIG9mIHVzZSBjYXNlcyB3b3VsZCBiZSBhIGdyZWF0IGltcHJvdmVtZW50IHRvIHByb3ZpZGUg c3VjaCBjb250ZXh0Lg0KQW5vdGhlciByZWNvbW1lbmRlZCBpbXByb3ZlbWVudCB3b3VsZCBiZSB0 aGUgaW5jbHVzaW9uIG9mIGEgZGlhZ3JhbSB0aGF0IHNob3VsZCBzaG93IGhvdyB0aGUgcHJvcG9z ZWQgYmVoYXZpb3IgZGlmZmVycyBmcm9tIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gb2YgSVB2 NiBQcmVmaXggT3B0aW9ucyBmb3IgREhDUHY2IC0gUkZDIDM2MzMgKGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmMzNjMzI3NlY3Rpb24tNS4xKQ0KVGhlIGRyYWZ0LXRlbXBsaW4tdjZvcHMt cGRob3N0LTAyIHRyaWVzIHRvIHNvcnQgYW4gYW1iaWd1aXR5IG9mIFJGQyAzNjMzLCB0aGF0IHNh eXMgInRoZSByZXF1ZXN0aW5nIHJvdXRlciBNVVNUIE5PVCBhc3NpZ24gYW55IGRlbGVnYXRlZCBw cmVmaXhlcyBvciBzdWJuZXRzIGZyb20gdGhlIGRlbGVnYXRlZCBwcmVmaXgoZXMpIHRvIHRoZSBs aW5rIHRocm91Z2ggd2hpY2ggaXQgcmVjZWl2ZWQgdGhlIERIQ1AgbWVzc2FnZSBmcm9tIHRoZSBk ZWxlZ2F0aW5nIHJvdXRlciIsIGJ1dCBSRkMgMzYzMyBkb2Vzbid0IHNwZWNpZnkgaWYgYWRkcmVz c2VzIGZyb20gdGhlIHByZWZpeCBtYXkgYmUgdXNlZCBpbiB0aGUgcmVjZWl2aW5nIGludGVyZmFj ZS4gV2UgYXJlIG5vdCBzdXJlIGlmIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gZnJvbSBSRkMg MzYzMyBhbGxvd3Mgb3Igbm90IHRoZSB1c2Ugb2YgYWRkcmVzc2VzIGZyb20gdGhlIHJlY2VpdmVk IHByZWZpeCBkZWxlZ2F0aW9uIG9uIHRoZSBpbnRlcmZhY2UgdGhhdCByZWNlaXZlZCB0aGUgcHJl Zml4IGRlbGVnYXRpb24uDQoNClJlY29tbWVuZGF0aW9uOiBXaXRoIGEgYmV0dGVyIGludHJvZHVj dGlvbiB0byB0aGUgbmVlZCBmb3IgdGhpcyBkb2N1bWVudCwgd2UgcmVjb21tZW5kIGl0IHRvIGJl IGFkb3B0ZWQgYXMgd29ya2luZyBncm91cCBkb2N1bWVudCwgaWYgb3BlcmF0b3JzIHNheSAid2Ug cGxhbiB0byB1c2UgdGhpcyBwcm9wb3NhbCINCg0KQlIsDQoNCkVkd2luIENvcmRlaXJvDQo= --_000_f573bcf518044805ae6031515fe32277XCH150505nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMjExODQzMzU7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02ODg3NDc2NjggMTc4MjQ3NDI4OCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SGVsbG8gRWR3aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHBvc3RpbmcgdGhpcyByZXZpZXcuIFNl ZSBiZWxvdyBmb3IgZm9sbG93LXVwIGRpc2N1c3Npb24gZm9yIHRoZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5wb2ludHMgeW91IGhhdmUgcmFpc2VkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlN1bW1hcnk6 IFRoZSBkcmFmdCBwcm92aWRlcyBndWlkZWxpbmVzIGZvciBhIGhvc3QgdGhhdCByZWNlaXZlcyBh IHByZWZpeCB0aHJvdWdoIERIQ1B2Ni1QRDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+WWVzLCB0aGF0IGlzIGFjY3VyYXRlIGZvciB0aGUgZHJhZnQgaW4gaXRzIGN1 cnJlbnQgZm9ybSwgYnV0IEkgd291bGQgbGlrZSB0byBjaGFuZ2UgdGhlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPmRyYWZ0IHRvIHNheSB0aGF0IGl0IGFwcGxpZXMgdG8gcHJlZml4IGRlbGVnYXRpb25zIHJl Y2VpdmVkIHRocm91Z2ggYW55IG1lYW5zIGFuZCBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+anVzdCBE SENQdjYgUEQuIEl0IHdvdWxkIHNheSB0aGF0IGEgcHJlZml4IGRlbGVnYXRpb24gaW5jbHVkZXMg YSBjb21tdW5pY2F0aW9uIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZSBwcmVmaXggZnJvbSB0aGUg bmV0d29yayB0byB0aGUgaG9zdCwgYW5kIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHByZWZpeCBp biB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bmV0d29yayByb3V0aW5nIHN5c3RlbS4gREhDUHY2IFBE IHdvdWxkIHRoZW4gYmUgY2l0ZWQgYXMgb25seSBvbmUgZXhhbXBsZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+YW5kIHdhbnQgdG8gdXNlIGFkZHJlc3NlcyBmcm9t IHRoaXMgcHJlZml4IG9uIGl0cyBpbnRlcmZhY2UsIHNwZWNpZmljYWxseSBpbiBhbiBBRVJPIFtS RkMgNjcwNl0gZW52aXJvbm1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgY29ycmVjdCByZWZlcmVuY2UgZm9yIEFFUk8g aXMg4oCYZHJhZnQtdGVtcGxpbi1hZXJvbGlua+KAmS4gQnV0LCB0aGF0IHNob3VsZCBiZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj51bmRlcnN0b29kIGFzIG9ubHkgb25lIGV4YW1wbGUg4oCTIHRoZSBzYW1l IHRlY2huaXF1ZXMgY2FuIGFwcGx5IHRvIGFueSBvdGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5saW5r IHR5cGVzIGluY2x1ZGluZywgRXRoZXJuZXQsIFdpZmksIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj5Db21tZW50czogVGhlIGRyYWZ0IGNsZWFybHkgc3BlY2lmeSBob3cgYSBob3N0IHNob3Vs ZCBiZWhhdmUgd2hlbiByZWNlaXZpbmcgYSBwcmVmaXggZGVsZWdhdGlvbjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+dGhyb3VnaCBESENQdjYt UEQgYW5kIHdhbnQgdG8gdXNlIGFkZHJlc3NlcyBmcm9tIHRoZSByZWNlaXZlZCBwcmVmaXggb24g dGhlIGludGVyZmFjZSBpdCB1c2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpX aW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmIj50byByZXF1ZXN0IHRoZSBESENQLVBELiBVbmZvcnR1bmF0ZWx5 IHRoZSBkcmFmdCBmYWlscyB0byBjbGFyaWZ5IHdoZXJlIHN1Y2ggYmVoYXZpb3IgaXMgbmVlZGVk PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5h bmQgYWNjZXB0YWJsZS4gRXhhbXBsZSBvZiB1c2UgY2FzZXMgd291bGQgYmUgYSBncmVhdCBpbXBy b3ZlbWVudCB0byBwcm92aWRlIHN1Y2ggY29udGV4dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkhlcmUgaXMgc29tZSBwcm9wb3NlZCB0ZXh0OjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IOKAnFRoaXMgYXBw cm9hY2ggaXMgYXBwbGljYWJsZSB0byBhIHdpZGUgdmFyaWV0eSBvZiB1c2UgY2FzZXMuJm5ic3A7 IEZvciBleGFtcGxlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgaXQgY2FuIGJlIHVz ZWQgdG8gY29vcmRpbmF0ZSB0aGUgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsgKFZQTikgbGlua3Mg b2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG1vYmlsZSBkZXZpY2VzIChlLmcuLCBj ZWxscGhvbmVzLCB0YWJsZXRzLCBsYXB0b3AgY29tcHV0ZXJzLCBldGMuKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsgdGhhdCBjb25uZWN0IGludG8gYSBob21lIGVudGVycHJpc2UgbmV0 d29yayB2aWEgcHVibGljIGFjY2VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbmV0 d29ya3MuJm5ic3A7IFRoZSBhcHByb2FjaCBjYW4gYWxzbyBiZSBhcHBsaWVkIHRvIGF2aWF0aW9u IGFwcGxpY2F0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZm9yIGJvdGggbWFu bmVkIGFuZCB1bm1hbm5lZCBhaXJjcmFmdCB3aGVyZSB0aGUgYWlyY3JhZnQgaXMgdHJlYXRlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgYXMgYSBtb2JpbGUgaG9zdC4gVmFyaW91cyBv dGhlciB1c2UgY2FzZXMgYXJlIGFsc28gaW4gc2NvcGUu4oCdPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+QW5vdGhlciByZWNvbW1lbmRlZCBpbXByb3ZlbWVudCB3b3VsZCBiZSB0aGUgaW5jbHVzaW9u IG9mIGEgZGlhZ3JhbSB0aGF0IHNob3VsZCBzaG93PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5ob3cgdGhlIHByb3Bvc2VkIGJlaGF2aW9yIGRp ZmZlcnMgZnJvbSB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIG9mIElQdjYgUHJlZml4IE9wdGlv bnMgZm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj5ESENQdjYgLSBSRkMgMzYzMyAoPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmMzNjMzI3NlY3Rpb24tNS4xIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzM2MzMjc2VjdGlvbi01LjE8L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPik8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgYmUgaGFwcHkgdG8g aW5jbHVkZSBhIGRpYWdyYW0uIFRoYW5rIHlvdSBmb3IgdGhlIHN1Z2dlc3Rpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+VGhlIGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAyIHRyaWVzIHRv IHNvcnQgYW4gYW1iaWd1aXR5IG9mIFJGQyAzNjMzLCB0aGF0IHNheXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90O3RoZSByZXF1ZXN0 aW5nIHJvdXRlciBNVVNUIE5PVCBhc3NpZ24gYW55IGRlbGVnYXRlZCBwcmVmaXhlcyBvciBzdWJu ZXRzIGZyb20gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3Mi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj5kZWxlZ2F0ZWQgcHJlZml4KGVzKSB0byB0aGUgbGluayB0aHJvdWdoIHdoaWNo IGl0IHJlY2VpdmVkIHRoZSBESENQIG1lc3NhZ2UgZnJvbSB0aGU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmRlbGVnYXRpbmcgcm91dGVyJnF1 b3Q7LCBidXQgUkZDIDM2MzMgZG9lc24ndCBzcGVjaWZ5IGlmIGFkZHJlc3NlcyBmcm9tIHRoZSBw cmVmaXggbWF5IGJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3Mi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj51c2VkIGluIHRoZSByZWNlaXZpbmcgaW50ZXJmYWNlLiBXZSBhcmUgbm90IHN1 cmUgaWYgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOY PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5SRkMgMzYzMyBhbGxvd3Mgb3Igbm90 IHRoZSB1c2Ugb2YgYWRkcmVzc2VzIGZyb20gdGhlIHJlY2VpdmVkIHByZWZpeCBkZWxlZ2F0aW9u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5v biB0aGUgaW50ZXJmYWNlIHRoYXQgcmVjZWl2ZWQgdGhlIHByZWZpeCBkZWxlZ2F0aW9uLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2hvdWxkIHRoaXMgZHJhZnQg dXBkYXRlIFJGQzM2MzMgKGlmIGFwcHJvdmVkKT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RWR3aW4gQ29yZGVpcm88YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBBdWd1c3QgMTUsIDIwMTYgMjoyNiBBTTxicj4NCjxiPlRvOjwvYj4gSVB2 NiBPcHMgV0cgJmx0O3Y2b3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbdjZv cHNdIFJldmlldyBkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0wMjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkRvY3Vt ZW50OiBkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0wMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+UmV2aWV3ZXJzOiBSaWNhcmRv IFBlbGFlei1OZWdybywgRWR3aW4gQ29yZGVpcm8sIEZyZWQgQmFrZXIsIE5hdmVlbiBLIExha3No bWFuICh2Nm9wcyBkcmFmdCByZXZpZXcgdGVhbSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlJldmlldyBEYXRlOiAxNS9hdWcvMjAx Njwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+U3VtbWFyeTogVGhlIGRyYWZ0IHByb3ZpZGVzIGd1aWRlbGluZXMgZm9yIGEgaG9zdCB0 aGF0IHJlY2VpdmVzIGEgcHJlZml4IHRocm91Z2ggREhDUHY2LVBEIGFuZCB3YW50IHRvIHVzZSBh ZGRyZXNzZXMgZnJvbSB0aGlzIHByZWZpeCBvbiBpdHMgaW50ZXJmYWNlLCBzcGVjaWZpY2FsbHkg aW4gYW4gQUVSTyBbUkZDIDY3MDZdIGVudmlyb25tZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Db21tZW50czogVGhlIGRyYWZ0 IGNsZWFybHkgc3BlY2lmeSBob3cgYSBob3N0IHNob3VsZCBiZWhhdmUgd2hlbiByZWNlaXZpbmcg YSBwcmVmaXggZGVsZWdhdGlvbiB0aHJvdWdoIERIQ1B2Ni1QRCBhbmQgd2FudCB0byB1c2UgYWRk cmVzc2VzIGZyb20gdGhlIHJlY2VpdmVkIHByZWZpeCBvbiB0aGUgaW50ZXJmYWNlIGl0IHVzZWQN CiB0byByZXF1ZXN0IHRoZSBESENQLVBELiBVbmZvcnR1bmF0ZWx5IHRoZSBkcmFmdCBmYWlscyB0 byBjbGFyaWZ5IHdoZXJlIHN1Y2ggYmVoYXZpb3IgaXMgbmVlZGVkIGFuZCBhY2NlcHRhYmxlLiBF eGFtcGxlIG9mIHVzZSBjYXNlcyB3b3VsZCBiZSBhIGdyZWF0IGltcHJvdmVtZW50IHRvIHByb3Zp ZGUgc3VjaCBjb250ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPkFub3RoZXIgcmVjb21tZW5kZWQgaW1wcm92ZW1lbnQgd291bGQg YmUgdGhlIGluY2x1c2lvbiBvZiBhIGRpYWdyYW0gdGhhdCBzaG91bGQgc2hvdyBob3cgdGhlIHBy b3Bvc2VkIGJlaGF2aW9yIGRpZmZlcnMgZnJvbSB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIG9m IElQdjYgUHJlZml4IE9wdGlvbnMgZm9yIERIQ1B2NiAtIFJGQw0KIDM2MzMgKDwvc3Bhbj48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYzMyNzZWN0aW9uLTUuMSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjMzI3NlY3Rpb24t NS4xPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZiI+VGhlIGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAyIHRyaWVz IHRvIHNvcnQgYW4gYW1iaWd1aXR5IG9mIFJGQyAzNjMzLCB0aGF0IHNheXMgJnF1b3Q7dGhlIHJl cXVlc3Rpbmcgcm91dGVyIE1VU1QgTk9UIGFzc2lnbiBhbnkgZGVsZWdhdGVkIHByZWZpeGVzIG9y IHN1Ym5ldHMgZnJvbSB0aGUgZGVsZWdhdGVkIHByZWZpeChlcykgdG8NCiB0aGUgbGluayB0aHJv dWdoIHdoaWNoIGl0IHJlY2VpdmVkIHRoZSBESENQIG1lc3NhZ2UgZnJvbSB0aGUgZGVsZWdhdGlu ZyByb3V0ZXImcXVvdDssIGJ1dCBSRkMgMzYzMyBkb2Vzbid0IHNwZWNpZnkgaWYgYWRkcmVzc2Vz IGZyb20gdGhlIHByZWZpeCBtYXkgYmUgdXNlZCBpbiB0aGUgcmVjZWl2aW5nIGludGVyZmFjZS4g V2UgYXJlIG5vdCBzdXJlIGlmIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gZnJvbSBSRkMgMzYz MyBhbGxvd3Mgb3Igbm90IHRoZQ0KIHVzZSBvZiBhZGRyZXNzZXMgZnJvbSB0aGUgcmVjZWl2ZWQg cHJlZml4IGRlbGVnYXRpb24gb24gdGhlIGludGVyZmFjZSB0aGF0IHJlY2VpdmVkIHRoZSBwcmVm aXggZGVsZWdhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPlJlY29tbWVuZGF0aW9uOiBXaXRoIGEgYmV0dGVyIGludHJvZHVj dGlvbiB0byB0aGUgbmVlZCBmb3IgdGhpcyBkb2N1bWVudCwgd2UgcmVjb21tZW5kIGl0IHRvIGJl IGFkb3B0ZWQgYXMgd29ya2luZyBncm91cCBkb2N1bWVudCwgaWYgb3BlcmF0b3JzIHNheSAmcXVv dDt3ZSBwbGFuIHRvIHVzZSB0aGlzIHByb3Bvc2FsJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5CUiw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFy PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZiI+RWR3aW4gQ29yZGVpcm88L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_f573bcf518044805ae6031515fe32277XCH150505nwnosboeingcom_-- From nobody Mon Aug 15 11:35:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E628A12D127 for ; Mon, 15 Aug 2016 11:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.847 X-Spam-Level: X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGWJp9Tyxgnr for ; Mon, 15 Aug 2016 11:35:48 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C712C12D09A for ; Mon, 15 Aug 2016 11:35:47 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EE262626E8 for ; Mon, 15 Aug 2016 20:35:45 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id AE70C60274; Mon, 15 Aug 2016 20:35:45 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 9D01712AFC; Mon, 15 Aug 2016 20:35:45 +0200 (CEST) Date: Mon, 15 Aug 2016 20:35:45 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160815183545.GU79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lp5aQHsetySuafUn" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 18:35:50 -0000 --lp5aQHsetySuafUn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Aug 15, 2016 at 09:28:55PM +0900, Lorenzo Colitti wrote: > On Fri, Jul 22, 2016 at 2:20 AM, Gert Doering wrote: >=20 > > In a fully controlled environment, you don't want the hosts to make > > decisions (unless directed by configured policy). I just wanted to > > point out that "enterprise" and "SOHO" are really totally different > > problem spaces regarding multihoming and "who makes decisions?". >=20 > A fully controlled environment is one where the enterprise controls the > hosts. > An environment where the enterprise controls the network but not the hosts > is not a controlled environment. > Which one are you talking about here? I think it was quite clear from the part that you did not quote what the distinction was about. "Decisions made by host / application" vs. "decisions made by the policy administrator". I'm not going to enter a hair-splitting contest on the wording of this. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --lp5aQHsetySuafUn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXsgt6AAoJEN9WwGXkzn/F69gQAIPMNI1nz/LZfiT9oZXaLdcp GPgqBMnb1u+XekXsuz3W9RG4H4pG5qYB7NfKBSG5QgX17Q8lkVV9dnYLNl8r6tEN evfA5C79LY45CSmyzWRygykOUG1Ur3uzOyqe0fK9jJtFR1mtyDHBmO6WQY20Abou w/yb/wFkxMGvXjuxKSSYR2NhjWepDa/Xx74bwc1JrGQnnxdg1/hGnTi5vI71NyfD PFO11CCeTKogeEa0zyc+LhbIVEMRxFc1uIEnb1KElhAo/TkjJy1oXrhavIXKQkSM TCYgShIo8GkzsiNpECu5UyEq/uRfCO9GC4Nbbzkn5fBRbiCGvB/467r9j0zLTHfw qyMUdMkSYdm5AxFf0xgL9y78KIzGyajVoA54qfNFmC2pcYIrec20OtHsRJnuXsdx x+tAf4cag6JCTpK57cX8Bm/T8Lvo51uwKu8czxXANzsNbjc/ORGEnCFx2gMMDd9K corjpmVKnVwenQDCsqsYSfOqWHvONrV4Ep7bRcPkLH0KRhP4C1ZE3/5pH0jMV6Ws d6UC5zndHTvPLVxMIqrosmf2k2RXvXXei020+M/DrHWkixqZ2tqKht44VKez/Ylw +LnGTa25krXKKOZ/zu9UNVWkfmn1ROC9EJHDqVZSrxHPair615l6/KIrFgkGGIGP nNElUOv4Y7t3knsytDgU =6MXM -----END PGP SIGNATURE----- --lp5aQHsetySuafUn-- From nobody Mon Aug 15 13:29:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5635912D151 for ; Mon, 15 Aug 2016 13:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkoetWH3Nmia for ; Mon, 15 Aug 2016 13:28:56 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61C812D0F9 for ; Mon, 15 Aug 2016 13:28:56 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id p64so19891699pfb.1 for ; Mon, 15 Aug 2016 13:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ucQHhvUwsojXt104aaDsErioWEou/BG68W3diUKT0xs=; b=hWX9Tocy/pPVuC857Ebk72oC2uEg+TSEM4V8PaTg919jYkU603JKcBR5yFaNgg3ppj FAhZg5qXbrYawAoPeQUNwlY0RcO0bPkuwsbB1BaDfUJZ5ZhJafcCEK8z++5B+EiQsF3j 65ShRixwrbNwBhkmYjVn5diQJi6CGgB2PrbEVTRo+jtx+wc3uatfFfaHgcUaFvZ0Vhsh NkRKdyfuLuD5ufqvPaYQAg5Rs9H/nnr8XY9UOGwvjCReeFPKqmm4XZlPiqW6UPtUG1us M72u+ON8Jv6DeHsa0FEoEQ5HPSQaa1BeTXodVVy36uJsWUn+gbFsze99YFGiKUUV4uaD rKOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ucQHhvUwsojXt104aaDsErioWEou/BG68W3diUKT0xs=; b=B6q6G6112wFw/bWyW9GnZKml5J21r/5EIf0eYfcoGbnOu47NShmgHYcApDEx+3ORqK L/C8KGRZOhFiHDzQfHjkTsp+4T1kVmgEY9rQ5V2lKTB4IynTEbNHPWC2pHFY4D4+XENn rhho2Jrkpnv8cQyyxOwRgeRdhgnJGB6yCkrbKn7DnBc0ow08762+SPJUlkTnNrGXSj1N OsC585vu8JyAAYZdY3XA/10VfM6qKjikO2Nl7Zi0EdUAe6EccIStOiFjVrxtAvkqhint C085K5ofLejTMWOYSMwuNcxJaEszkvCoSp4/lXm7gVSyaH7wkhsgJtHMEnhfcCdzEGwc QN4Q== X-Gm-Message-State: AEkoouslXph2/Kd0XCRqLdAmLJU0qkStcMsTEcT2fQftdDimcZC+bN0vRdJAMaFxsMHVcA== X-Received: by 10.98.86.154 with SMTP id h26mr57145487pfj.22.1471292936232; Mon, 15 Aug 2016 13:28:56 -0700 (PDT) Received: from ?IPv6:2406:e007:7d53:1:28cc:dc4c:9703:6781? ([2406:e007:7d53:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 89sm33448539pft.96.2016.08.15.13.28.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Aug 2016 13:28:55 -0700 (PDT) To: Joe Touch , Mikael Abrahamsson References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 16 Aug 2016 08:28:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 20:28:58 -0000 On 16/08/2016 04:03, Joe Touch wrote: > > > On 8/15/2016 3:06 AM, Mikael Abrahamsson wrote: >> Example: >> >> R1 - H1 - R2 >> >> R1 is sending RAs with prio high. R2 is sending RAs with prio low. >> Host application chooses address from H1-R2 link. As far as I know, >> "all" hosts today will send out H1-R2 address sourced packet via R1. >> >> What am I missing? > > I'm missing it too. > > In this case, H1 apps MUST be able to select the source address (either > based on R1 or R2 RAs). > > Where the packet goes after that depends on the forwarding tables on H1, > redirects from R1 and R2, etc. > > I.e., source IP MUST be application-selectable, but path might not. Hence https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host which is in IESG review. Brian From nobody Mon Aug 15 13:52:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB55D12D1B7 for ; Mon, 15 Aug 2016 13:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.767 X-Spam-Level: X-Spam-Status: No, score=-115.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp-6mN278btX for ; Mon, 15 Aug 2016 13:52:53 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1ADC12D18A for ; Mon, 15 Aug 2016 13:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6398; q=dns/txt; s=iport; t=1471294373; x=1472503973; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RDTSPtPWOcmdoLgk6RHo7Zjau2ioih4mCsgibGAzb7Y=; b=ALoJXSW7MGMIc13E7n7Xr4NKWbjIurGES5ZbEvuyP0pTx2E+rEFo5jjN yF02ITGx7Z91YTE0uVJHXtypY11qwadprvhkt0kPxsoD3xkS5egGSOvIV uvXmHmT16fY6/2UxBN2h8IIxn8JwxOws00loBsvtMYIj0PG60xDKU0Fel Q=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAwAJK7JX/5pdJa1egndOgVIHtDaFB?= =?us-ascii?q?4F9hh0CgVE4FAIBAQEBAQEBXieEXgEBBAF5BQsCAQgEFC4yJQIEDgUOiBsIvio?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEODogiCIJNh2yCLwWZPgGDO4FziWeBa41Yh?= =?us-ascii?q?mSFU4N3AR42g3puAYYkfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,526,1464652800"; d="asc'?scan'208,217";a="310301095" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2016 20:52:52 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7FKqqHt022985 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Aug 2016 20:52:52 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 15 Aug 2016 15:52:51 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 15 Aug 2016 15:52:51 -0500 From: "Fred Baker (fred)" To: Fred Templin Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9zb8nyZ+ZkYA30OlOUacO2gCKA== Date: Mon, 15 Aug 2016 20:52:51 +0000 Message-ID: <7BF3327C-0885-400B-A501-9DA964C7A9D2@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.56.114] Content-Type: multipart/signed; boundary="Apple-Mail=_6E09E34B-2570-47FD-9B3B-4DE72ECF33FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 20:52:55 -0000 --Apple-Mail=_6E09E34B-2570-47FD-9B3B-4DE72ECF33FF Content-Type: multipart/alternative; boundary="Apple-Mail=_46A2C012-930A-4250-BBAC-3F48F35EA32F" --Apple-Mail=_46A2C012-930A-4250-BBAC-3F48F35EA32F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 15, 2016, at 10:49 AM, Templin, Fred L = wrote: >=20 > Should this draft update RFC3633 (if approved)? That question belongs in 6man with support from DHC, which together = wrote RFC 3633. The first question I would ask, were I them, would be = whether the "ambiguity" regarding the application of a prefix to the = interface the prefix was received on holds water. For example, if the prefix is allocated using DHCP-PD or some similar = protocol, but the same prefix is allocated to every host on the LAN (for = some appropriate definition of that term) and each host then develops = some number of addresses on that interface in a manner reminiscent of = SLAAC, what is the significant difference between that and the prefix = being announced in an RA, whether multicast or multi-unicast as in an = NBMA network? If different prefixes are allocated to the various hosts = on that same LAN and the hosts create addresses from them in a manner = similar to SLAAC, is the router expected to intuit the addresses and = host route them, or does this presume an SDNish model in which the = router is told about the prefix allocations in some out-of-band = mechanism, and installs appropriate routing? At least one conceptual = question is that if a host can develop or be configured with one address = and routing be made to work, is there a real difference between that and = the host developing many addresses one at a time? What is the conceptual = difference between having one or more addresses from a prefix on an = interface, and having that prefix on the interface? But I'm looking for neither that answer nor discussion here. It's a = change to a protocol developed in another working group, and protocol = development is out of scope per the charter. --Apple-Mail=_46A2C012-930A-4250-BBAC-3F48F35EA32F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Aug 15, 2016, at 10:49 AM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

Should this draft update RFC3633 (if = approved)?

That = question belongs in 6man with support from DHC, which together wrote RFC = 3633. The first question I would ask, were I them, would be whether the = "ambiguity" regarding the application of a prefix to the interface the = prefix was received on holds water.

For example, if the prefix is allocated using = DHCP-PD or some similar protocol, but the same prefix is allocated to = every host on the LAN (for some appropriate definition of that term) and = each host then develops some number of addresses on that interface in a = manner reminiscent of SLAAC, what is the significant difference between = that and the prefix being announced in an RA, whether multicast or = multi-unicast as in an NBMA network? If different prefixes are allocated = to the various hosts on that same LAN and the hosts create addresses = from them in a manner similar to SLAAC, is the router expected to intuit = the addresses and host route them, or does this presume an SDNish model = in which the router is told about the prefix allocations in some = out-of-band mechanism, and installs appropriate routing? At least one = conceptual question is that if a host can develop or be configured with = one address and routing be made to work, is there a real difference = between that and the host developing many addresses one at a time? What = is the conceptual difference between having one or more addresses from a = prefix on an interface, and having that prefix on the = interface?

But I'm looking for = neither that answer nor discussion here. It's a change to a protocol = developed in another working group, and protocol development is out of = scope per the charter.
= --Apple-Mail=_46A2C012-930A-4250-BBAC-3F48F35EA32F-- --Apple-Mail=_6E09E34B-2570-47FD-9B3B-4DE72ECF33FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV7IrokayAOS/EQ8MAQIrQQ//Z4ua478ZXOl5xjzzZ1feSY1RBN0syn68 /OIojE11QHFcSfF0UY+S/34c+e5F3LuPNCJy2KIoIVnWVHsxVYrn5EtOenTUQ6ew n4W9QBC7d38ywTk8bdHJcTgmGKWVB3zeptSdJxMThqcsi15vjM4UmH9agVTcm6oN FVcKMi0PHeOU0HwM27rpANxS2CuQUfHBmidMFMko7dBN4kisd3srDX2d+Xm3E7Za vkVqce1RAQkom3C35hCAN1rCu8UlJPi55+p6OPYNT3sWHtrIj0a/mnfsBMelaM0q d/mAszkz+MmRvP6BE7CalQDCf7VMl+iOxH3ZAKzCGdKEf8th0/sBsz9Q4Qmw9Wn3 hjHHlyjO4Oy+c2woJrzRnsn5xdR8m/IxQP+MAhz/VkNOYIBnhaCuu+MxcoP69jGn qBjI30Jvr3zA0TsxNEixA5QO03MjPf8Gke3Akh3gxlzdTWmQywOvzhF+uYBdJnRR +cXMGBQmIp6ncxBZi0wTdGYY3GxlZzZ/FhIBrpluhc3vsnDCR6aPcFHvU0m5EohZ qagDr1kRyIaCuFAV0FTP6VOUubO3CQPnN2rZDx/I027M5Hsha1O8J0zpv/eyS1oA KwCRSO9AEIvvIGOufG6ahzeDui9fmliloX03XJSblXWzx/dBMLiJPCodjGLokccY 6z/9g711C7o= =K6SX -----END PGP SIGNATURE----- --Apple-Mail=_6E09E34B-2570-47FD-9B3B-4DE72ECF33FF-- From nobody Mon Aug 15 14:45:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F3E12B05E for ; Mon, 15 Aug 2016 14:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWUhobOYZwU5 for ; Mon, 15 Aug 2016 14:45:02 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8489812B020 for ; Mon, 15 Aug 2016 14:45:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7FLj2kK064961; Mon, 15 Aug 2016 14:45:02 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7FLiucl064787 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 15 Aug 2016 14:44:56 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 15 Aug 2016 14:44:55 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 15 Aug 2016 14:44:55 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9tcrwwccPUlJiEK61fgu5QfdmKBKRsFggACu4oD//40MsA== Date: Mon, 15 Aug 2016 21:44:55 +0000 Message-ID: References: <7BF3327C-0885-400B-A501-9DA964C7A9D2@cisco.com> In-Reply-To: <7BF3327C-0885-400B-A501-9DA964C7A9D2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_cfde88581fee4c41851453b436d30ecfXCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:45:05 -0000 --_000_cfde88581fee4c41851453b436d30ecfXCH150505nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fred, ? That question belongs in 6man with support from DHC, which together wrot= e RFC 3633. The first ? question I would ask, were I them, would be whether the "ambiguity" rega= rding the application of ? a prefix to the interface the prefix was received on holds water. I don't think we need to ask questions in other groups. ? For example, if the prefix is allocated using DHCP-PD or some similar pr= otocol, but the same prefix ? is allocated to every host on the LAN That would not be prefix delegation. Prefix delegation is when the prefix i= s given to a single requesting node for that node's exclusive use, and the routing = system is updated to associate the prefix with that single requesting node. The sa= me prefix is not announced to every host on the LAN, which would be an example of a shared prefix and is not the same thing as a prefix delegation. ? (for some appropriate definition of that term) and each host ? then develops some number of addresses on that interface in a manner rem= iniscent of SLAAC, The host can develop addresses to assign to the interface in any manner it = chooses (e.g., manual configuration). This document does not specific any new addre= ss configuration methods. ? what is the significant difference between that and the prefix being ann= ounced in an RA, whether ? multicast or multi-unicast as in an NBMA network? The significant difference is that the prefix is delegated for the requesti= ng node' own exclusive use and is not delegated or advertised to any other node. Tha= t is why the requesting node can avoid DAD and MLD on any addresses configured from the prefix. If the same prefix were multicast to multiple nodes on the= same link then DAD and MLD would be required. This becomes very important when the requesting node wishes to configure many addresses for itself out of th= e delegated prefix where the amount of DAD/MLD could become substantial if a shared prefix were used. ? If different prefixes are allocated to the various hosts on that same LA= N and the hosts create ? addresses from them in a manner similar to SLAAC, is the router expected= to intuit the ? addresses and host route them, or does this presume an SDNish model in w= hich the router ? is told about the prefix allocations in some out-of-band mechanism, and = installs appropriate ? routing? The delegating router simply injects the delegated prefix into the routing = system in some fashion, and does not have any requirement for tracking the address= es the requesting node may assign from the delegated prefix. ? At least one conceptual question is that if a host can develop or be con= figured with ? one address and routing be made to work, is there a real difference betw= een that and ? the host developing many addresses one at a time? What is the conceptual= difference ? between having one or more addresses from a prefix on an interface, and = having that ? prefix on the interface? The big difference is avoidance of DAD and MLD. ? But I'm looking for neither that answer nor discussion here. It's a chan= ge ? to a protocol developed in another working group, and protocol developme= nt ? is out of scope per the charter. There is no protocol change - this is operational guidance only. Thanks - Fred From: Fred Baker (fred) [mailto:fred@cisco.com] Sent: Monday, August 15, 2016 1:53 PM To: Templin, Fred L Cc: Edwin Cordeiro ; IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 On Aug 15, 2016, at 10:49 AM, Templin, Fred L > wrote: Should this draft update RFC3633 (if approved)? That question belongs in 6man with support from DHC, which together wrote R= FC 3633. The first question I would ask, were I them, would be whether the = "ambiguity" regarding the application of a prefix to the interface the pref= ix was received on holds water. For example, if the prefix is allocated using DHCP-PD or some similar proto= col, but the same prefix is allocated to every host on the LAN (for some ap= propriate definition of that term) and each host then develops some number = of addresses on that interface in a manner reminiscent of SLAAC, what is th= e significant difference between that and the prefix being announced in an = RA, whether multicast or multi-unicast as in an NBMA network? If different = prefixes are allocated to the various hosts on that same LAN and the hosts = create addresses from them in a manner similar to SLAAC, is the router expe= cted to intuit the addresses and host route them, or does this presume an S= DNish model in which the router is told about the prefix allocations in som= e out-of-band mechanism, and installs appropriate routing? At least one con= ceptual question is that if a host can develop or be configured with one ad= dress and routing be made to work, is there a real difference between that = and the host developing many addresses one at a time? What is the conceptua= l difference between having one or more addresses from a prefix on an inter= face, and having that prefix on the interface? But I'm looking for neither that answer nor discussion here. It's a change = to a protocol developed in another working group, and protocol development = is out of scope per the charter. --_000_cfde88581fee4c41851453b436d30ecfXCH150505nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fred,

 

Ø  That question belongs in 6man with support f= rom DHC, which together wrote RFC 3633. The first

Ø  question I would ask, were I them, would be = whether the "ambiguity" regarding the application of

Ø  a prefix to the interface the prefix was rec= eived on holds water.

 

I don’t think we need to ask qu= estions in other groups.

 

Ø  For example, if the prefix is allocated usin= g DHCP-PD or some similar protocol, but the same prefix=

Ø  is allocated to every host on the LAN

 

That would not be prefix delegation. = Prefix delegation is when the prefix is given

to a single requesting node for that = node’s exclusive use, and the routing system

is updated to associate the prefix wi= th that single requesting node. The same

prefix is not announced to every host= on the LAN, which would be an example

of a shared prefix and is not the sam= e thing as a prefix delegation.

 

Ø  (for some appropriate definition of that ter= m) and each host

Ø  then develops some number of addresses on th= at interface in a manner reminiscent of SLAAC,

 

The host can develop addresses to ass= ign to the interface in any manner it chooses

(e.g., manual configuration). This do= cument does not specific any new address

configuration methods.

 

Ø  what is the significant difference between t= hat and the prefix being announced in an RA, whether

Ø  multicast or multi-unicast as in an NBMA net= work?

 

The significant difference is that th= e prefix is delegated for the requesting node’

own exclusive use and is not delegate= d or advertised to any other node. That is

why the requesting node can avoid DAD= and MLD on any addresses configured

from the prefix. If the same prefix w= ere multicast to multiple nodes on the same

link then DAD and MLD would be requir= ed. This becomes very important when

the requesting node wishes to configu= re many addresses for itself out of the

delegated prefix where the amount of = DAD/MLD could become substantial

if a shared prefix were used.

 

Ø  If different prefixes are allocated to the v= arious hosts on that same LAN and the hosts create

Ø  addresses from them in a manner similar to S= LAAC, is the router expected to intuit the=

Ø  addresses and host route them, or does this = presume an SDNish model in which the router

Ø  is told about the prefix allocations in some= out-of-band mechanism, and installs appropriate<= /span>

Ø  routing?

 

The delegating router simply injects = the delegated prefix into the routing system

in some fashion, and does not have an= y requirement for tracking the addresses

the requesting node may assign from t= he delegated prefix.

 

Ø  At least one conceptual question is that if = a host can develop or be configured with

Ø  one address and routing be made to work, is = there a real difference between that and

Ø  the host developing many addresses one at a = time? What is the conceptual difference

Ø  between having one or more addresses from a = prefix on an interface, and having that

Ø  prefix on the interface?

 

The big difference is avoidance of DA= D and MLD.

 

Ø  But I'm looking for neither that answer nor = discussion here. It's a change

Ø  to a protocol developed in another working g= roup, and protocol development

Ø  is out of scope per the charter.<= /p>

 

There is no protocol change – t= his is operational guidance only.

 

Thanks - Fred

 

From: Fred Baker (fred) [mailto:fred= @cisco.com]
Sent: Monday, August 15, 2016 1:53 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: Edwin Cordeiro <edwinsc@gmail.com>; IPv6 Ops WG <v6ops@= ietf.org>
Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02=

 

 

On Aug 15, 2016, at 10:49 AM, Templin, Fred L <Fred.L.Templin@boeing.com>= ; wrote:

 

Should this draft update RFC3633 (if = approved)?

 

That question belongs in 6man with support from DHC,= which together wrote RFC 3633. The first question I would ask, were I them= , would be whether the "ambiguity" regarding the application of a= prefix to the interface the prefix was received on holds water.

 

For example, if the prefix is allocated using DHCP-P= D or some similar protocol, but the same prefix is allocated to every host = on the LAN (for some appropriate definition of that term) and each host the= n develops some number of addresses on that interface in a manner reminiscent of SLAAC, what is the significan= t difference between that and the prefix being announced in an RA, whether = multicast or multi-unicast as in an NBMA network? If different prefixes are= allocated to the various hosts on that same LAN and the hosts create addresses from them in a manner simi= lar to SLAAC, is the router expected to intuit the addresses and host route= them, or does this presume an SDNish model in which the router is told abo= ut the prefix allocations in some out-of-band mechanism, and installs appropriate routing? At least one conc= eptual question is that if a host can develop or be configured with one add= ress and routing be made to work, is there a real difference between that a= nd the host developing many addresses one at a time? What is the conceptual difference between having one or mor= e addresses from a prefix on an interface, and having that prefix on the in= terface?

 

But I'm looking for neither that answer nor discussi= on here. It's a change to a protocol developed in another working group, an= d protocol development is out of scope per the charter.

--_000_cfde88581fee4c41851453b436d30ecfXCH150505nwnosboeingcom_-- From nobody Mon Aug 15 14:50:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD26212D114 for ; Mon, 15 Aug 2016 14:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.767 X-Spam-Level: X-Spam-Status: No, score=-115.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCWQQ0i5ePNh for ; Mon, 15 Aug 2016 14:50:52 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C324212B020 for ; Mon, 15 Aug 2016 14:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3193; q=dns/txt; s=iport; t=1471297851; x=1472507451; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dxyPrR1LOjHsx1ADNKXAToN6N61R/8/mZYydmsFh0RQ=; b=XddT6MrClezc8cQt9x9l0U1fQKuy5jg5mgZhWApzuoXU77tRtjy57oCY M+d7Z9IZYfe/uvrBbstr8rWHe1zW/bCCThtz2vz5ExqWvP447QVoquaNk vhumxdC0tbcciTsjRytz8gOmciRGsmWkCAKf0HI9d/+YTW1yHE9poOXMH Y=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAwBgOLJX/5BdJa1egndOgVIHtDaFB?= =?us-ascii?q?4F9hh0CgVE4FAIBAQEBAQEBXieEXgEBBAEjVgULAgEIBAETKgICMiUCBA4FDog?= =?us-ascii?q?bCK4GkDEBAQEBAQEBAQEBAQEBAQEBAQEBAQEODogiCIJNh0Ergi8FmT4BgzuBc?= =?us-ascii?q?4lnj0OMN4N3AR42g3puAYYkfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,527,1464652800"; d="asc'?scan'208,217";a="138107574" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2016 21:50:50 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7FLooao004698 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Aug 2016 21:50:50 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 15 Aug 2016 16:50:50 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 15 Aug 2016 16:50:50 -0500 From: "Fred Baker (fred)" To: Fred Templin Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9zb9nyZ+ZkYA30OlOUacO2gCKA== Date: Mon, 15 Aug 2016 21:50:50 +0000 Message-ID: References: <7BF3327C-0885-400B-A501-9DA964C7A9D2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.56.114] Content-Type: multipart/signed; boundary="Apple-Mail=_7B2E4F01-F1E4-47D4-8551-76DFC9F46FF6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:50:54 -0000 --Apple-Mail=_7B2E4F01-F1E4-47D4-8551-76DFC9F46FF6 Content-Type: multipart/alternative; boundary="Apple-Mail=_398FDF80-CE51-4946-963E-7A39AE0CDFE5" --Apple-Mail=_398FDF80-CE51-4946-963E-7A39AE0CDFE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 15, 2016, at 2:44 PM, Templin, Fred L = wrote: >=20 > There is no protocol change =E2=80=93 this is operational guidance = only. Then there is no question of updating a protocol specification, is = there? --Apple-Mail=_398FDF80-CE51-4946-963E-7A39AE0CDFE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 15, 2016, at 2:44 PM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

There is no protocol change =E2=80=93 this = is operational guidance only.

Then there is no question of updating a protocol = specification, is there?
= --Apple-Mail=_398FDF80-CE51-4946-963E-7A39AE0CDFE5-- --Apple-Mail=_7B2E4F01-F1E4-47D4-8551-76DFC9F46FF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV7I5OEayAOS/EQ8MAQIyIg/+Lqjj5KlKy2lsjA/TaxF99sVQxo8fWXTx Nx+WqDJ2aPIfJLSl6GrTYjiAKXpWZGKCWCox3j463bQEdEDShz49WDzWKLwZJbem 5u1wYyL/VlPP+x6gpVWN1A5E19Q6keLe26AadBnJnxvH2SRztHRDeZBDuw7ERUA/ aeNICqLtaKa4W3bgpv4GILjXQaNtDdw2eLtmoSYloYXCcNKrrUbWldRjeUHGYgtg k8TMD4Cca9bQOHCF10QpCiM4MwL2XAnZf8pRrPT7i6s2jmOwSngpV5/oLF7m6+K/ stIWDwfRt6DW3sMwjTCTotFsfuWK5FdVuEaxobMHtiHhgUboFYwDIip7eEOcszw5 PyykZGBjkFAbKhojAE22xPKTpBlE/FaD0ICL6yfvklRSpFN4I8IJzBMH3gCqXTun 41SEWYTD1LMQEVLF5ZTgWWWr9iaa9xTaHec42QZreXI3GS6/641BlweewX97nTd1 Ib4k1Ouc4r6hKy2JdhbbhxRBe9XlIqUud5o3sj3TedJHE1eRCqJUf3q9ndYQdNhH SMReFv95f91Kb63mn6JBhxcti+krr4VJc2mGx1ogNWdYU1A8U43E0mU0vmRqIFUs RiI9CQxq8V7U+lusYdQIVUYSjOXTtyoksoCPBxz9Gg7+P+oLVzONskrs4gXatB3Y aurG0dUYV0g= =8MCc -----END PGP SIGNATURE----- --Apple-Mail=_7B2E4F01-F1E4-47D4-8551-76DFC9F46FF6-- From nobody Mon Aug 15 14:54:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB37712B020 for ; Mon, 15 Aug 2016 14:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEbb-26WpQ1T for ; Mon, 15 Aug 2016 14:54:50 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE8812D1B9 for ; Mon, 15 Aug 2016 14:54:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7FLsnNV014527; Mon, 15 Aug 2016 14:54:49 -0700 Received: from XCH15-05-03.nw.nos.boeing.com (xch15-05-03.nw.nos.boeing.com [137.137.100.66]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7FLsfCr014475 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 15 Aug 2016 14:54:41 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-03.nw.nos.boeing.com (2002:8989:6442::8989:6442) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 15 Aug 2016 14:54:40 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 15 Aug 2016 14:54:40 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9tcrwwccPUlJiEK61fgu5QfdmKBKRsFggACu4oD//40MsIAAgygA//+LezA= Date: Mon, 15 Aug 2016 21:54:40 +0000 Message-ID: <471f19d2caf841cf8f6055b3c652e1d9@XCH15-05-05.nw.nos.boeing.com> References: <7BF3327C-0885-400B-A501-9DA964C7A9D2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_471f19d2caf841cf8f6055b3c652e1d9XCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:54:52 -0000 --_000_471f19d2caf841cf8f6055b3c652e1d9XCH150505nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZW4gdGhlcmUgaXMgbm8gcXVlc3Rpb24gb2YgdXBkYXRpbmcgYSBwcm90b2NvbCBzcGVj aWZpY2F0aW9uLCBpcyB0aGVyZT8NCg0KWWVzLCB0aGF0IGlzIGNvcnJlY3QuDQoNClRoYW5rcyAt IEZyZWQNCg0KRnJvbTogRnJlZCBCYWtlciAoZnJlZCkgW21haWx0bzpmcmVkQGNpc2NvLmNvbV0N ClNlbnQ6IE1vbmRheSwgQXVndXN0IDE1LCAyMDE2IDI6NTEgUE0NClRvOiBUZW1wbGluLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogRWR3aW4gQ29yZGVpcm8gPGVkd2lu c2NAZ21haWwuY29tPjsgSVB2NiBPcHMgV0cgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt2Nm9wc10gUmV2aWV3IGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAyDQoNCg0KT24gQXVn IDE1LCAyMDE2LCBhdCAyOjQ0IFBNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCg0KVGhl cmUgaXMgbm8gcHJvdG9jb2wgY2hhbmdlIOKAkyB0aGlzIGlzIG9wZXJhdGlvbmFsIGd1aWRhbmNl IG9ubHkuDQoNClRoZW4gdGhlcmUgaXMgbm8gcXVlc3Rpb24gb2YgdXBkYXRpbmcgYSBwcm90b2Nv bCBzcGVjaWZpY2F0aW9uLCBpcyB0aGVyZT8NCg== --_000_471f19d2caf841cf8f6055b3c652e1d9XCH150505nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjkzNzIxMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTE2NTM3Mjc1OTIgLTkyODg3MTM4MiA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjU7DQoJbXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZW4gdGhlcmUgaXMg bm8gcXVlc3Rpb24gb2YgdXBkYXRpbmcgYSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uLCBpcyB0aGVy ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWVzLCB0aGF0IGlzIGNvcnJl Y3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBG cmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gRnJlZCBCYWtlciAoZnJlZCkgW21haWx0bzpmcmVkQGNpc2NvLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAxNSwgMjAxNiAyOjUxIFBNPGJyPg0K PGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBFZHdpbiBDb3JkZWlybyAmbHQ7ZWR3aW5zY0BnbWFpbC5jb20m Z3Q7OyBJUHY2IE9wcyBXRyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbdjZvcHNdIFJldmlldyBkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0wMjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAxNSwg MjAxNiwgYXQgMjo0NCBQTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIG5vIHByb3RvY29sIGNoYW5nZSDi gJMgdGhpcyBpcyBvcGVyYXRpb25hbCBndWlkYW5jZSBvbmx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZW4gdGhlcmUgaXMgbm8gcXVlc3Rpb24gb2YgdXBkYXRpbmcgYSBwcm90b2NvbCBzcGVjaWZp Y2F0aW9uLCBpcyB0aGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_471f19d2caf841cf8f6055b3c652e1d9XCH150505nwnosboeingcom_-- From nobody Mon Aug 15 16:45:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C9C12D627 for ; Mon, 15 Aug 2016 16:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fvprau5nNAqt for ; Mon, 15 Aug 2016 16:45:20 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C72D12D5A3 for ; Mon, 15 Aug 2016 16:45:19 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id f6so10622560ith.0 for ; Mon, 15 Aug 2016 16:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S0zla6TSEqTVsBfxgsQ09pdKqzOpIrJ61dgE+L8KTqM=; b=GKEXP85zoVnh2gOUCNOKuJ0LhV0zfCZ4veZya0xt0TjyIFVs2lFcYTNA+ju0ksIm2A pfA9DeQbvOVMEuuCQq8NqNu3yxR3ZXN93diiHB30Tem9qPbRhftpGGZ7nwDHREkQh33Z 78N1eAnGwXVMAzGvefuacb7yt+rZbHAJzFEi5qBEhV7vUnx6glibX7xpwXvq6TfSYrf8 kSucdf1KVvkwoeViUyMYvPbCnE1jyhDTjUwVVsFvPgxiN0yN3//rcs6upv6+c5fhu9WI /Ng40l9l4NveVrsIa/pasxAYxMdCybUZ1d7EQkRK1BR+VkLLsiukaQEwuMfY69DRp78p EJVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S0zla6TSEqTVsBfxgsQ09pdKqzOpIrJ61dgE+L8KTqM=; b=LsQ5uidhvagtVOvCNFMmrXDrtR0dKBYaFvlyymcCLTgo1UZWiqcK0Z4NlLcqJ2u4yB QANriEUm3AqxfWl3mpnPj0x9D4kBO9hCKD++Z6qcmXtmjGgWKv3HB+qHbugXtISy4YjG IMMq0+5ZVlB81hyDcMokuoDrjhMhO81YDXx+P7JBHhYOJvuXZbkLYTXwV/BhWu5QzmSW +e9yIXnbjTeVhaYE8Ho7wTydZiR5mDUpkYDJpacv5tZJWiidhKpOkxMPFK27bP43vq0t E1MxkrdIcynIchEmWIwAyS5xa52jIVUw9vieUNnD/aNbZZx6vTQmt9dlAv8tPvXgBcp/ BDBw== X-Gm-Message-State: AEkoouvOyveuMTPA0ChZIN513A9WtOCY83mxK5dIzTjKGfB3RhGRVPQrMYx3K0dIjlGteDCWvvic3ei8Xu56ubXX X-Received: by 10.36.14.20 with SMTP id 20mr2077187ite.88.1471304719121; Mon, 15 Aug 2016 16:45:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.26.72 with HTTP; Mon, 15 Aug 2016 16:44:58 -0700 (PDT) In-Reply-To: <20160815183545.GU79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> <20160815183545.GU79185@Space.Net> From: Lorenzo Colitti Date: Tue, 16 Aug 2016 08:44:58 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1143840e242221053a24d356 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 23:45:21 -0000 --001a1143840e242221053a24d356 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 16, 2016 at 3:35 AM, Gert Doering wrote: > > A fully controlled environment is one where the enterprise controls the > > hosts. > > An environment where the enterprise controls the network but not the > hosts > > is not a controlled environment. > > Which one are you talking about here? > > I think it was quite clear from the part that you did not quote what > the distinction was about. > > "Decisions made by host / application" vs. "decisions made by the policy > administrator". > So are you just saying that whatever mechanism we defined for apps to influence what path is taken by their traffic must include the ability for the host administrator to configure and disable it? Or are you saying something else? --001a1143840e242221053a24d356 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 16, 2016 at 3:35 AM, Gert Doering <gert@space.net> wrot= e:
> A fully co= ntrolled environment is one where the enterprise controls the
> hosts.
> An environment where the enterprise controls the network but not the h= osts
> is not a controlled environment.
> Which one are you talking about here?

I think it was quite clear from the part that you did not quote= what
the distinction was about.

"Decisions made by host / application" vs. "decisions made b= y the policy
administrator".

So are you just sa= ying that whatever mechanism we defined for apps to influence what path is = taken by their traffic must include the ability for the host administrator = to configure and disable it? Or are you saying something else?
<= /div>
--001a1143840e242221053a24d356-- From nobody Tue Aug 16 01:00:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE7412D0B0 for ; Tue, 16 Aug 2016 01:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkrEzsbgwl_p for ; Tue, 16 Aug 2016 01:00:22 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D1712D0DC for ; Tue, 16 Aug 2016 01:00:20 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id q128so128414462wma.1 for ; Tue, 16 Aug 2016 01:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jZETVIFNFFgoQtYy3tjNRQAYGcCIdDzE/Krrltan7cA=; b=JDX/KURW+CbDAuN/oXbMt9PmZoa2N8RlEdBCPZ0f48Le9oxmygsWpcx7Q7lFGdjK5z n3QszX8rc49UWXZDWg2IoiBygxyNAQttXqwvkY82eHwRIAblMGEA7Dxeb3PvF/CEZ9MO gWVYZIvCEk2DazM3V3WtNCw4KP3rKxz9ZZvPbap7iKhaSKaQXlTZODZCxiDoBJ4AA0sL It0hnfATn/LUojP+yhsNVfHKvgB4y4cnQq4fQBYteMhVBaszMs2CHt7Qboelz9lKeEFA H2ud2uQSkDG92nDgO061e5b2L76+LpGvs8FkoISWw4uszkRHzj41uqG6mgA6mbvLBQvc Q2tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jZETVIFNFFgoQtYy3tjNRQAYGcCIdDzE/Krrltan7cA=; b=ZPmkcIozFFLJCDu2r3ZnywrjloW4zVuKiPW4Pn8MHqEEbfIh9HM7YErZxLD7lshJ0y CyWEgjDrs2Z4AEms5Xym7pS7I4MAnV3GPegfPiOdQJ0X6jXPWZ5vN5lrab32n0YPQ6O1 3j6kReS1xRhG6goM3bKS4qKOTer1f9nK+TDddb7ccKagdHsXFQDU8s+P5qrpszPIJDOy 6Wge8ZUf0SVFnMcYBDNh746CJhBFzQje6cesRV0dXrFSbzGjsKlQexL6M86kC4X+XSux JOapR17arawZNcY4R3nJ/UEZPgUsPQoxpvDr0k1/JxeFyvoM32BIoyLMH+XhM5S+7to0 FoiQ== X-Gm-Message-State: AEkooutPGT3heOvcMwnPlDaxn1aqVvsKPv9ZKHDx+0mKhXyRxStW8OwPXs+q+AgFMBuVcW2BDKnLf78FRd277Q== X-Received: by 10.28.238.154 with SMTP id j26mr21570686wmi.94.1471334419330; Tue, 16 Aug 2016 01:00:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.74.8 with HTTP; Tue, 16 Aug 2016 00:59:48 -0700 (PDT) In-Reply-To: References: From: Edwin Cordeiro Date: Tue, 16 Aug 2016 09:59:48 +0200 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=001a1147284e68fc0e053a2bbde9 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 08:00:24 -0000 --001a1147284e68fc0e053a2bbde9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fred, Below additional comments to your replies: > =C3=98 Summary: The draft provides guidelines for a host that receives a > prefix through DHCPv6-PD > > > > Yes, that is accurate for the draft in its current form, but I would like > to change the > > draft to say that it applies to prefix delegations received through any > means and not > > just DHCPv6 PD. It would say that a prefix delegation includes a > communication of > > the prefix from the network to the host, and a representation of the > prefix in the > > network routing system. DHCPv6 PD would then be cited as only one example= . > > > > =C3=98 and want to use addresses from this prefix on its interface, > specifically in an AERO [RFC 6706] environment > > > > The correct reference for AERO is =E2=80=98draft-templin-aerolink=E2=80= =99. But, that > should be > > understood as only one example =E2=80=93 the same techniques can apply to= any other > > link types including, Ethernet, Wifi, etc. > > > =E2=80=8BSo please add some details of possible examples to provide a bette= r context for the need of this document.=E2=80=8B =C3=98 Comments: The draft clearly specify how a host should behave when > receiving a prefix delegation > > =C3=98 through DHCPv6-PD and want to use addresses from the received pre= fix > on the interface it used > > =C3=98 to request the DHCP-PD. Unfortunately the draft fails to clarify = where > such behavior is needed > > =C3=98 and acceptable. Example of use cases would be a great improvement= to > provide such context. > > > > Here is some proposed text: > > > > =E2=80=9CThis approach is applicable to a wide variety of use cases. = For > example, > > it can be used to coordinate the Virtual Private Network (VPN) links o= f > > mobile devices (e.g., cellphones, tablets, laptop computers, etc.) > > that connect into a home enterprise network via public access > > networks. The approach can also be applied to aviation applications > > for both manned and unmanned aircraft where the aircraft is treated > > as a mobile host. Various other use cases are also in scope.=E2=80=9D > > > =E2=80=8BThis example is helpful, but a better explanation of the use cases= would be better.=E2=80=8B =E2=80=8BThe other comments were addressed by Fred Baker and I have nothing= to add. Best Regards, Edwin Cordeiro=E2=80=8B > > > > > *From:* v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Edwin > Cordeiro > *Sent:* Monday, August 15, 2016 2:26 AM > *To:* IPv6 Ops WG > *Subject:* [v6ops] Review draft-templin-v6ops-pdhost-02 > > > > Document: draft-templin-v6ops-pdhost-02 > > > > Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Naveen K > Lakshman (v6ops draft review team) > > > > Review Date: 15/aug/2016 > > > > Summary: The draft provides guidelines for a host that receives a prefix > through DHCPv6-PD and want to use addresses from this prefix on its > interface, specifically in an AERO [RFC 6706] environment > > > > Comments: The draft clearly specify how a host should behave when > receiving a prefix delegation through DHCPv6-PD and want to use addresses > from the received prefix on the interface it used to request the DHCP-PD. > Unfortunately the draft fails to clarify where such behavior is needed an= d > acceptable. Example of use cases would be a great improvement to provide > such context. > > Another recommended improvement would be the inclusion of a diagram that > should show how the proposed behavior differs from the current > specification of IPv6 Prefix Options for DHCPv6 - RFC 3633 ( > https://tools.ietf.org/html/rfc3633#section-5.1) > > The draft-templin-v6ops-pdhost-02 tries to sort an ambiguity of RFC 3633, > that says "the requesting router MUST NOT assign any delegated prefixes o= r > subnets from the delegated prefix(es) to the link through which it receiv= ed > the DHCP message from the delegating router", but RFC 3633 doesn't specif= y > if addresses from the prefix may be used in the receiving interface. We a= re > not sure if the current specification from RFC 3633 allows or not the use > of addresses from the received prefix delegation on the interface that > received the prefix delegation. > > > > Recommendation: With a better introduction to the need for this document, > we recommend it to be adopted as working group document, if operators say > "we plan to use this proposal" > > > > BR, > > > Edwin Cordeiro > --001a1147284e68fc0e053a2bbde9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fred,

Below additional comments to your replies:=C2=A0

=C3=98=C2=A0 Summary: The draft provides guidelines for a host that receives= a prefix through DHCPv6-PD

=C2=A0

Yes, that is accurate for the draft i= n its current form, but I would like to change the

draft to say that it applies to prefi= x delegations received through any means and not

just DHCPv6 PD. It would say that a p= refix delegation includes a communication of

the prefix from the network to the ho= st, and a representation of the prefix in the

network routing system. DHCPv6 PD wou= ld then be cited as only one example.

=C2=A0

=C3=98=C2=A0 and want to use addresses from this prefix on its interface, sp= ecifically in an AERO [RFC 6706] environment

=C2=A0

The correct reference for AERO is =E2= =80=98draft-templin-aerolink=E2=80=99. But, that should be

understood as only one example =E2=80= =93 the same techniques can apply to any other

link types including, Ethernet, Wifi,= etc.

=C2=A0

<= /blockquote>
=E2=80=8BSo please add some details of possible exam= ples to provide a better context for the need of this document.=E2=80=8B

<= u>

=C3=98=C2=A0 Comments: The draft clearly specify how a host should behave wh= en receiving a prefix delegation

=C3=98=C2=A0 through DHCPv6-PD and want to use addresses from the received p= refix on the interface it used

=C3=98=C2=A0 to request the DHCP-PD. Unfortunately the draft fails to clarif= y where such behavior is needed

=C3=98=C2=A0 and acceptable. Example of use cases would be a great improveme= nt to provide such context.

=C2=A0

Here is some proposed text:=

=C2=A0

=C2=A0=C2=A0 =E2=80=9CThis approach i= s applicable to a wide variety of use cases.=C2=A0 For example,

=C2=A0=C2=A0 it can be used to coordi= nate the Virtual Private Network (VPN) links of

=C2=A0=C2=A0 mobile devices (e.g., ce= llphones, tablets, laptop computers, etc.)

=C2=A0=C2=A0 that connect into a home= enterprise network via public access

=C2=A0=C2=A0 networks.=C2=A0 The appr= oach can also be applied to aviation applications

=C2=A0=C2=A0 for both manned and unma= nned aircraft where the aircraft is treated

=C2=A0=C2=A0 as a mobile host. Variou= s other use cases are also in scope.=E2=80=9D

=C2=A0

<= /blockquote>
=E2=80=8BThis example is helpful= , but a better explanation of the use cases would be better.=E2=80=8B
= =C2=A0

=E2=80=8BThe other comments were addressed by Fred Baker and I have nothin= g to add.

Best Regards,
Edwin Cordeiro=E2=80=8B


=C2=A0

=C2=A0

From: v6ops [mailto:v6ops-bounces@ietf.org= ] On Behalf Of Edwin Cordeiro
Sent: Monday, August 15, 2016 2:26 AM
To: IPv6 Ops WG <v6ops@ietf.org>
Subject: [v6ops] Review draft-templin-v6ops-pdhost-02<= /span>

=C2=A0

Document: draft-templin-v6ops-pdhost-02

=C2=A0

Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Naveen = K Lakshman (v6ops draft review team)

=C2=A0

Review Date: 15/aug/2016

=C2=A0

Summary: The draft provides guidelines for a host that receives a pr= efix through DHCPv6-PD and want to use addresses from this prefix on its in= terface, specifically in an AERO [RFC 6706] environment

=C2=A0

Comments: The draft clearly specify how a host should behave when re= ceiving a prefix delegation through DHCPv6-PD and want to use addresses fro= m the received prefix on the interface it used to request the DHCP-PD. Unfortunately the draft fails to clarify where suc= h behavior is needed and acceptable. Example of use cases would be a great = improvement to provide such context.

Another recommended improvement would be the inclusion of a diagram = that should show how the proposed behavior differs from the current specifi= cation of IPv6 Prefix Options for DHCPv6 - RFC 3633 (https://tools.ietf.org/html/rfc3633#section-5.1)

The draft-templin-v6ops-pdhost-02 tries to sort an ambiguity of RFC = 3633, that says "the requesting router MUST NOT assign any delegated p= refixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating ro= uter", but RFC 3633 doesn't specify if addresses from the prefix m= ay be used in the receiving interface. We are not sure if the current speci= fication from RFC 3633 allows or not the use of addresses from the received prefix delegation on the interface that= received the prefix delegation.

=C2=A0

Recommendation: With a better introduction to the need for this docu= ment, we recommend it to be adopted as working group document, if operators= say "we plan to use this proposal"

=C2=A0

BR,


Edwin Cordeiro


--001a1147284e68fc0e053a2bbde9-- From nobody Tue Aug 16 02:57:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C588E12B051 for ; Tue, 16 Aug 2016 02:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.847 X-Spam-Level: X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdxLNg08E6uV for ; Tue, 16 Aug 2016 02:57:32 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F070126FDC for ; Tue, 16 Aug 2016 02:57:30 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 250F2626FF for ; Tue, 16 Aug 2016 11:57:29 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E9443602E3; Tue, 16 Aug 2016 11:57:28 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id D7FC9254C9; Tue, 16 Aug 2016 11:57:28 +0200 (CEST) Date: Tue, 16 Aug 2016 11:57:28 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160816095728.GZ79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> <20160815183545.GU79185@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2jPz0LUjoA9Rcgnr" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 09:57:33 -0000 --2jPz0LUjoA9Rcgnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Aug 16, 2016 at 08:44:58AM +0900, Lorenzo Colitti wrote: > So are you just saying that whatever mechanism we defined for apps to > influence what path is taken by their traffic must include the ability for > the host administrator to configure and disable it?=20 No. > Or are you saying something else? I'm saying that there are two fairly distinct types of networks, with different requirements. Giving a simple example: in the "managed enterprise network" case, in most cases, your machine would have ONE network interface, GUAs from ONE network prefix, and ONE (redundant) gateway. No need to influence anything= =20 on the host, because traffic will always go to the gateway, and all policy happens on routers and/or firewalls. In the homenet case, with addresses from multiple providers available=20 on the host, what the application does makes a difference. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --2jPz0LUjoA9Rcgnr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXsuOGAAoJEN9WwGXkzn/FTQ4P/0cmHKZrEzjoELjmnCJ4+lj8 yxklyzC4H5MtRHk6pK4BSTJdNUbXCeydknA5vRmsO9VKEU+HmRapRWtp5P1QU0qA TnaNIKaCkAnx7E169EK5aLFJn+TPor65ZyX2V2CMy7/wzqyIzbySb5Ptv3G7jDoR RPZslE//8Tpxg2CuurccgMcM/KrnEC1VMQ2K8sp2wz1/UkXSLL23yF7PCIO7kIwE YtraNrS6Lu7WJwxeoJjj6hGflGrFNL7cH916pyKS2M6VuyWS+QmmQWpSLn9v2ONo Br+hKoeQeofGyrgOEOCICbMlofc2oeKxji2cJqb4nGSHDWT4JHR3Ovbsagzhny6s hvjRkgCZc3p8ZbWVnROeBH2uskhl9oPFywZu3Jzd1tdqyCmQkHe2WfMmF3C/LdY6 7ICidduwE503XHoDmHrSAKomMbCU4OcUpQRY42GLsTqwRZc9jYafY4hoDReguB8e zb1EEBxX/QdQjhCOiwPL7aYbY3ZEZKBG4Frj37INQvfSl/X8BJ9aEsInmn/Kpcnp onenJXXSmnypSJGDDVo04P5xQo7QpOIptvdW31K+PZfarlxsleS+CsNh4DWXvhPA xS8td1MPHcHajDnw3/c7eexnqwHUogRqaS6ujQWsqUroaeU3gYwDFZTx4XTNP0R7 vK2crdl2GfIS3GeXzZri =0Hc0 -----END PGP SIGNATURE----- --2jPz0LUjoA9Rcgnr-- From nobody Tue Aug 16 05:12:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE1212D847 for ; Tue, 16 Aug 2016 05:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTf59qWuLEn8 for ; Tue, 16 Aug 2016 05:12:36 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FDF12DAEA for ; Tue, 16 Aug 2016 04:59:38 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id m101so104762209ioi.2 for ; Tue, 16 Aug 2016 04:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3Uk260xRcwoXJWmoPwwORJ4o2LFH+jE4FLez98mzA9o=; b=jHTtYvL1J0C9srDTjcPKreyefnx7NZM/M2k9bkQ3ae/hatRSMT6E5vmmuF60Bhe37l F5+yEI7np6EtI3W9hVNPf8MkEVA4KwZFzK3KWdndQbthxvog1T6oK1pI+jMYd3Qc9ozI phH4+ng8bBZHYiRL/xZQFeW7NkhAc5qjrsHbYNLOlLKB8GEBhpy7Vso1dLgYIWixfBgX hT3gqJHDDhsoWCoGp15AswBHNEQM7+P3ZTepZyyD2qHSvUHcwdC8DSdJVg7cUehqZCwH PLiKWssHpe6eAKY3+3zRppY6Irv40XPgWdRb3CjmrGsKH2d/6NJI24KPuwzx+UqSLCGn PqUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Uk260xRcwoXJWmoPwwORJ4o2LFH+jE4FLez98mzA9o=; b=KKKEu81vO+d0kUuNz5FpPPKHaMJfEnotPQCgkE4jqio5KPPdLDhoYYLB4zNbn7dAQ6 aFmR4thDUFOkeR81eHYl5kjhxb0zAdDu+ES+SI0myRk0wlKeCSiOMx4evnE/0fz94vkK gCUb+x/37wkDwnzfIPwFO7gY1fUSO5NoHn4td1RwIrUMNG+I41lg3p2opUr+0w+uA9tX WUCuKFRk+hnSQGkK6i6SFB6+98qRPBiJvsdWX3qZ/v63BHixCejBYK9yseoZTGFxgV6R CvJFLAb4iiEuMZcVk9LtnqAkHv/M6vnx/S3JQ7wbtBEdVDS1aWP60f76XPCSDPlUsscz orRg== X-Gm-Message-State: AEkooutKwcCyoEIAsQjbcofPK4aJ2T0WgM8sVobwQ5op6wHS/rxvsepeAQR/F5QrTLljO1VpHjpRRSCBzfF8DEwX X-Received: by 10.107.136.157 with SMTP id s29mr32056507ioi.141.1471348777316; Tue, 16 Aug 2016 04:59:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.26.72 with HTTP; Tue, 16 Aug 2016 04:59:16 -0700 (PDT) In-Reply-To: <20160816095728.GZ79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> <20160815183545.GU79185@Space.Net> <20160816095728.GZ79185@Space.Net> From: Lorenzo Colitti Date: Tue, 16 Aug 2016 20:59:16 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a113ea7f636d3af053a2f1504 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 12:12:37 -0000 --001a113ea7f636d3af053a2f1504 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 16, 2016 at 6:57 PM, Gert Doering wrote: > I'm saying that there are two fairly distinct types of networks, with > different requirements. > I don't think we can cleanly device all networks into to distinct types, and I think it would be unwise to design a solution that made such an assumption. Giving a simple example: in the "managed enterprise network" case, in > most cases, your machine would have ONE network interface, GUAs from ONE > network prefix, and ONE (redundant) gateway. No need to influence anything > on the host, because traffic will always go to the gateway, and all policy > happens on routers and/or firewalls. > That's the trivial case of a multihomed host with only one path. --001a113ea7f636d3af053a2f1504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 16, 2016 at 6:57 PM, Gert Doering <gert@space.net> wrot= e:
I'm saying that there are two fair= ly distinct types of networks, with
different requirements.

I don't thi= nk we can cleanly device all networks into to distinct types, and I think i= t would be unwise to design a solution that made such an assumption.
<= div>
Giving a simple example: in the "managed enterprise network" case= , in
most cases, your machine would have ONE network interface, GUAs from ONE network prefix, and ONE (redundant) gateway.=C2=A0 No need to influence any= thing
on the host, because traffic will always go to the gateway, and all policy<= br> happens on routers and/or firewalls.

Th= at's the trivial case of a multihomed host with only one path.
--001a113ea7f636d3af053a2f1504-- From nobody Tue Aug 16 05:49:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14B12D0EE for ; Tue, 16 Aug 2016 05:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.847 X-Spam-Level: X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBK14xwjZRQ2 for ; Tue, 16 Aug 2016 05:49:23 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BDB12D7CC for ; Tue, 16 Aug 2016 05:49:23 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2BFE06270A for ; Tue, 16 Aug 2016 14:49:21 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id DA1076066F; Tue, 16 Aug 2016 14:49:20 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id CA17A25B59; Tue, 16 Aug 2016 14:49:20 +0200 (CEST) Date: Tue, 16 Aug 2016 14:49:20 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160816124920.GB79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> <20160815183545.GU79185@Space.Net> <20160816095728.GZ79185@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C85/eofIbnBIyCwA" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 12:49:25 -0000 --C85/eofIbnBIyCwA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Aug 16, 2016 at 08:59:16PM +0900, Lorenzo Colitti wrote: > On Tue, Aug 16, 2016 at 6:57 PM, Gert Doering wrote: >=20 > > I'm saying that there are two fairly distinct types of networks, with > > different requirements. >=20 > I don't think we can cleanly device all networks into to distinct types, > and I think it would be unwise to design a solution that made such an > assumption. I'm not sure what the point of this thread is, especially referring to a mail sent by me in a specific context some weeks(!) ago. My experience in dealing with IETF is that there is quite a lot of people that have tunnel vision. =20 Networks differ, and while there are overlaps, you can't really dispute that the majority clearly belongs in exactly one of the two categories I've mentioned: - "no administrator on site, or no administrator at all" - SoHo / homenet - "network administrator on site, policy enforced by network devices" the whole point of mentioning the *TWO* categories of networks regularily is that those with the tunnel vision remember that there is a whole differe= nt world from what they think "a network should be" - namely, the other camp. > > Giving a simple example: in the "managed enterprise network" case, in > > most cases, your machine would have ONE network interface, GUAs from ONE > > network prefix, and ONE (redundant) gateway. No need to influence anyt= hing > > on the host, because traffic will always go to the gateway, and all pol= icy > > happens on routers and/or firewalls. >=20 > That's the trivial case of a multihomed host with only one path. Indeed, for the *host*, it's the trivial case - and that is part of my=20 point. A network can be multihomed in many different ways, and *some* of these variants are visible to the host, and would benefit from=20 intelligence in the host, while others look like single-homed networks to the host. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --C85/eofIbnBIyCwA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXswvNAAoJEN9WwGXkzn/FURAP/2U+jA8MD2xy4cPSoobtohJn lUgRTfRSEqIKv4PKL7VjUUAyeHrBqFPBgVpIcPFyekza00mT3NXLanw78pNrVpIj 4Bvff8UP3I9cXyQ85/YnLqu+RzBOIppXGBcLkyYcO4DYwMwPxqf+6d+FaqkDcX0u f+qw+EFU5sc/IfiFG/aKTPg34ttdaas/fLrCoaBNsZJhqwOKehAJVxmTwaMyQGTy BvMAvHYHws4TUl0YZyWUbcwthAa7uaUQ8AdGkbgXmLDc3kRGX/zASg3cZExWb5XO H+KEd4TyokaRhVx43d1cQ6FlqdHog/l1YVN1oJ0SXKaSdlj/XnjLTzzj9eCqKSbA Xrss2PTNjP554gRdL79818d2QOOwfXr8PQad0lKirWlVGdaT01HsjK/frDzK4e0Y aY6ny4Hgm2CTVdGM7Py9C1cLjFeZAB5Oz7PmvH/GgH/huc9zpXiJbYzIHub4DSPS b0wyJPfrm3vVxlhdAPMVF7BZqBXbrSJNOYAHCw/QHscqr8m7MZzPtvxZFPof2fs+ QY+uSaak4k9uPrrwm4mPiTFqBnWtMtkn1QBmp6z8QQ9gR41sBS2N4wsXCHVmgSN3 E2N0BOut6ga67p04x8r6vhj1XAK12qfyETsRq8rvUp4/VhdEPTOwLJdXcW6lhFHw q5wgt6ypKxSWtLSlUShd =O8V3 -----END PGP SIGNATURE----- --C85/eofIbnBIyCwA-- From nobody Tue Aug 16 23:56:06 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B000412B008; Tue, 16 Aug 2016 23:56:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147141696468.19931.9340539639502389015.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 23:56:04 -0700 Archived-At: Cc: v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com Subject: [v6ops] v6ops - New Meeting Session Request for IETF 97 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 06:56:04 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man aqm dnsop mtgvenue opsawg opsec ospf pcp rtgwg sunset4 tsvwg Second Priority: tsvarea intarea lmap softwire Special Requests: --------------------------------------------------------- From nobody Wed Aug 17 04:16:14 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F39C12D112; Wed, 17 Aug 2016 04:16:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147143257064.12259.1672979866324756903.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 04:16:10 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 11:16:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration Authors : Bing Liu Sheng Jiang Xiangyang Gong Wendong Wang Enno Rey Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-07.txt Pages : 23 Date : 2016-08-17 Abstract: The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating the availability of address auto-configuration mechanisms and other configuration such as DNS-related configuration. These are the M, O, and A flags, which by definition are advisory, not prescriptive. This document describes divergent host behaviors observed in popular operating systems. It also discusses operational problems that the divergent behaviors might cause. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 17 04:20:10 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7196812B051; Wed, 17 Aug 2016 04:20:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147143280746.12260.12636327637592587474.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 04:20:07 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-considerations-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 11:20:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Considerations For Using Unique Local Addresses Authors : Bing Liu Sheng Jiang Filename : draft-ietf-v6ops-ula-usage-considerations-01.txt Pages : 17 Date : 2016-08-17 Abstract: This document provides considerations for using IPv6 Unique Local Addresses (ULAs). Based on an analysis of different ULA usage scenarios, this document identifies use cases where ULA addresses are helpful as well as potential problems caused by using them, The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-considerations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ula-usage-considerations-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 18 14:23:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0D12D190 for ; Thu, 18 Aug 2016 14:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7oN3zBcZOgs for ; Thu, 18 Aug 2016 14:23:21 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DBE12D0FF for ; Thu, 18 Aug 2016 14:23:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7ILNK5Z038025; Thu, 18 Aug 2016 14:23:20 -0700 Received: from XCH15-05-03.nw.nos.boeing.com (xch15-05-03.nw.nos.boeing.com [137.137.100.66]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7ILNJ3Q038000 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2016 14:23:19 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-03.nw.nos.boeing.com (2002:8989:6442::8989:6442) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 18 Aug 2016 14:23:18 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 18 Aug 2016 14:23:18 -0700 From: "Templin, Fred L" To: Edwin Cordeiro Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9tcrwwccPUlJiEK61fgu5QfdmKBKRsFggAFpOgCAA4768A== Date: Thu, 18 Aug 2016 21:23:18 +0000 Message-ID: <396f327690d24cfa8f519488bfc28bdd@XCH15-05-05.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_396f327690d24cfa8f519488bfc28bddXCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 21:23:24 -0000 --_000_396f327690d24cfa8f519488bfc28bddXCH150505nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkEgbmV3IHZlcnNpb24gb2YgdGhpcyBkcmFmdCBpcyBub3cgYXZhaWxhYmxlIGJh c2VkIG9uIHJldmlldyBjb21tZW50cyByZWNlaXZlZC4NClRoZSBjb21tZW50cyBoYXZlIGdyZWF0 bHkgaW1wcm92ZWQgdGhlIGRvY3VtZW50LCB3aGljaCBub3cgYWxzbyBpbmNsdWRlcw0KZmlndXJl cyB0aGF0IGNsZWFybHkgaWxsdXN0cmF0ZSB0aGUgY29uY2VwdHMgZGVzY3JpYmVkOg0KDQpodHRw czovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0wNC50eHQNCg0K UGxlYXNlIHJldmlldyBhbmQgcG9zdCBjb21tZW50cy4NCg0KVGhhbmtzIOKAkyBGcmVkDQpmcmVk LmwudGVtcGxpbkBib2VpbmcuY29tDQoNCkZyb206IEVkd2luIENvcmRlaXJvIFttYWlsdG86ZWR3 aW5zY0BnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTYsIDIwMTYgMTowMCBBTQ0K VG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiBJUHY2 IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBSZXZpZXcgZHJh ZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QtMDINCg0KSGkgRnJlZCwNCg0KQmVsb3cgYWRkaXRpb25h bCBjb21tZW50cyB0byB5b3VyIHJlcGxpZXM6DQoNCj4gIFN1bW1hcnk6IFRoZSBkcmFmdCBwcm92 aWRlcyBndWlkZWxpbmVzIGZvciBhIGhvc3QgdGhhdCByZWNlaXZlcyBhIHByZWZpeCB0aHJvdWdo IERIQ1B2Ni1QRA0KDQpZZXMsIHRoYXQgaXMgYWNjdXJhdGUgZm9yIHRoZSBkcmFmdCBpbiBpdHMg Y3VycmVudCBmb3JtLCBidXQgSSB3b3VsZCBsaWtlIHRvIGNoYW5nZSB0aGUNCmRyYWZ0IHRvIHNh eSB0aGF0IGl0IGFwcGxpZXMgdG8gcHJlZml4IGRlbGVnYXRpb25zIHJlY2VpdmVkIHRocm91Z2gg YW55IG1lYW5zIGFuZCBub3QNCmp1c3QgREhDUHY2IFBELiBJdCB3b3VsZCBzYXkgdGhhdCBhIHBy ZWZpeCBkZWxlZ2F0aW9uIGluY2x1ZGVzIGEgY29tbXVuaWNhdGlvbiBvZg0KdGhlIHByZWZpeCBm cm9tIHRoZSBuZXR3b3JrIHRvIHRoZSBob3N0LCBhbmQgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUg cHJlZml4IGluIHRoZQ0KbmV0d29yayByb3V0aW5nIHN5c3RlbS4gREhDUHY2IFBEIHdvdWxkIHRo ZW4gYmUgY2l0ZWQgYXMgb25seSBvbmUgZXhhbXBsZS4NCg0KDQo+ICBhbmQgd2FudCB0byB1c2Ug YWRkcmVzc2VzIGZyb20gdGhpcyBwcmVmaXggb24gaXRzIGludGVyZmFjZSwgc3BlY2lmaWNhbGx5 IGluIGFuIEFFUk8gW1JGQyA2NzA2XSBlbnZpcm9ubWVudA0KDQpUaGUgY29ycmVjdCByZWZlcmVu Y2UgZm9yIEFFUk8gaXMg4oCYZHJhZnQtdGVtcGxpbi1hZXJvbGlua+KAmS4gQnV0LCB0aGF0IHNo b3VsZCBiZQ0KdW5kZXJzdG9vZCBhcyBvbmx5IG9uZSBleGFtcGxlIOKAkyB0aGUgc2FtZSB0ZWNo bmlxdWVzIGNhbiBhcHBseSB0byBhbnkgb3RoZXINCmxpbmsgdHlwZXMgaW5jbHVkaW5nLCBFdGhl cm5ldCwgV2lmaSwgZXRjLg0KDQrigItTbyBwbGVhc2UgYWRkIHNvbWUgZGV0YWlscyBvZiBwb3Nz aWJsZSBleGFtcGxlcyB0byBwcm92aWRlIGEgYmV0dGVyIGNvbnRleHQgZm9yIHRoZSBuZWVkIG9m IHRoaXMgZG9jdW1lbnQu4oCLDQoNCg0KPiAgQ29tbWVudHM6IFRoZSBkcmFmdCBjbGVhcmx5IHNw ZWNpZnkgaG93IGEgaG9zdCBzaG91bGQgYmVoYXZlIHdoZW4gcmVjZWl2aW5nIGEgcHJlZml4IGRl bGVnYXRpb24NCg0KPiAgdGhyb3VnaCBESENQdjYtUEQgYW5kIHdhbnQgdG8gdXNlIGFkZHJlc3Nl cyBmcm9tIHRoZSByZWNlaXZlZCBwcmVmaXggb24gdGhlIGludGVyZmFjZSBpdCB1c2VkDQoNCj4g IHRvIHJlcXVlc3QgdGhlIERIQ1AtUEQuIFVuZm9ydHVuYXRlbHkgdGhlIGRyYWZ0IGZhaWxzIHRv IGNsYXJpZnkgd2hlcmUgc3VjaCBiZWhhdmlvciBpcyBuZWVkZWQNCg0KPiAgYW5kIGFjY2VwdGFi bGUuIEV4YW1wbGUgb2YgdXNlIGNhc2VzIHdvdWxkIGJlIGEgZ3JlYXQgaW1wcm92ZW1lbnQgdG8g cHJvdmlkZSBzdWNoIGNvbnRleHQuDQoNCkhlcmUgaXMgc29tZSBwcm9wb3NlZCB0ZXh0Og0KDQog ICDigJxUaGlzIGFwcHJvYWNoIGlzIGFwcGxpY2FibGUgdG8gYSB3aWRlIHZhcmlldHkgb2YgdXNl IGNhc2VzLiAgRm9yIGV4YW1wbGUsDQogICBpdCBjYW4gYmUgdXNlZCB0byBjb29yZGluYXRlIHRo ZSBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayAoVlBOKSBsaW5rcyBvZg0KICAgbW9iaWxlIGRldmlj ZXMgKGUuZy4sIGNlbGxwaG9uZXMsIHRhYmxldHMsIGxhcHRvcCBjb21wdXRlcnMsIGV0Yy4pDQog ICB0aGF0IGNvbm5lY3QgaW50byBhIGhvbWUgZW50ZXJwcmlzZSBuZXR3b3JrIHZpYSBwdWJsaWMg YWNjZXNzDQogICBuZXR3b3Jrcy4gIFRoZSBhcHByb2FjaCBjYW4gYWxzbyBiZSBhcHBsaWVkIHRv IGF2aWF0aW9uIGFwcGxpY2F0aW9ucw0KICAgZm9yIGJvdGggbWFubmVkIGFuZCB1bm1hbm5lZCBh aXJjcmFmdCB3aGVyZSB0aGUgYWlyY3JhZnQgaXMgdHJlYXRlZA0KICAgYXMgYSBtb2JpbGUgaG9z dC4gVmFyaW91cyBvdGhlciB1c2UgY2FzZXMgYXJlIGFsc28gaW4gc2NvcGUu4oCdDQoNCuKAi1Ro aXMgZXhhbXBsZSBpcyBoZWxwZnVsLCBidXQgYSBiZXR0ZXIgZXhwbGFuYXRpb24gb2YgdGhlIHVz ZSBjYXNlcyB3b3VsZCBiZSBiZXR0ZXIu4oCLDQoNCg0K4oCLVGhlIG90aGVyIGNvbW1lbnRzIHdl cmUgYWRkcmVzc2VkIGJ5IEZyZWQgQmFrZXIgYW5kIEkgaGF2ZSBub3RoaW5nIHRvIGFkZC4NCg0K QmVzdCBSZWdhcmRzLA0KRWR3aW4gQ29yZGVpcm/igIsNCg0KDQoNCg0KDQpGcm9tOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgRWR3aW4gQ29yZGVpcm8NClNlbnQ6IE1vbmRheSwgQXVndXN0IDE1 LCAyMDE2IDI6MjYgQU0NClRvOiBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2 b3BzQGlldGYub3JnPj4NClN1YmplY3Q6IFt2Nm9wc10gUmV2aWV3IGRyYWZ0LXRlbXBsaW4tdjZv cHMtcGRob3N0LTAyDQoNCkRvY3VtZW50OiBkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0wMg0K DQpSZXZpZXdlcnM6IFJpY2FyZG8gUGVsYWV6LU5lZ3JvLCBFZHdpbiBDb3JkZWlybywgRnJlZCBC YWtlciwgTmF2ZWVuIEsgTGFrc2htYW4gKHY2b3BzIGRyYWZ0IHJldmlldyB0ZWFtKQ0KDQpSZXZp ZXcgRGF0ZTogMTUvYXVnLzIwMTYNCg0KU3VtbWFyeTogVGhlIGRyYWZ0IHByb3ZpZGVzIGd1aWRl bGluZXMgZm9yIGEgaG9zdCB0aGF0IHJlY2VpdmVzIGEgcHJlZml4IHRocm91Z2ggREhDUHY2LVBE IGFuZCB3YW50IHRvIHVzZSBhZGRyZXNzZXMgZnJvbSB0aGlzIHByZWZpeCBvbiBpdHMgaW50ZXJm YWNlLCBzcGVjaWZpY2FsbHkgaW4gYW4gQUVSTyBbUkZDIDY3MDZdIGVudmlyb25tZW50DQoNCkNv bW1lbnRzOiBUaGUgZHJhZnQgY2xlYXJseSBzcGVjaWZ5IGhvdyBhIGhvc3Qgc2hvdWxkIGJlaGF2 ZSB3aGVuIHJlY2VpdmluZyBhIHByZWZpeCBkZWxlZ2F0aW9uIHRocm91Z2ggREhDUHY2LVBEIGFu ZCB3YW50IHRvIHVzZSBhZGRyZXNzZXMgZnJvbSB0aGUgcmVjZWl2ZWQgcHJlZml4IG9uIHRoZSBp bnRlcmZhY2UgaXQgdXNlZCB0byByZXF1ZXN0IHRoZSBESENQLVBELiBVbmZvcnR1bmF0ZWx5IHRo ZSBkcmFmdCBmYWlscyB0byBjbGFyaWZ5IHdoZXJlIHN1Y2ggYmVoYXZpb3IgaXMgbmVlZGVkIGFu ZCBhY2NlcHRhYmxlLiBFeGFtcGxlIG9mIHVzZSBjYXNlcyB3b3VsZCBiZSBhIGdyZWF0IGltcHJv dmVtZW50IHRvIHByb3ZpZGUgc3VjaCBjb250ZXh0Lg0KQW5vdGhlciByZWNvbW1lbmRlZCBpbXBy b3ZlbWVudCB3b3VsZCBiZSB0aGUgaW5jbHVzaW9uIG9mIGEgZGlhZ3JhbSB0aGF0IHNob3VsZCBz aG93IGhvdyB0aGUgcHJvcG9zZWQgYmVoYXZpb3IgZGlmZmVycyBmcm9tIHRoZSBjdXJyZW50IHNw ZWNpZmljYXRpb24gb2YgSVB2NiBQcmVmaXggT3B0aW9ucyBmb3IgREhDUHY2IC0gUkZDIDM2MzMg KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjMzI3NlY3Rpb24tNS4xKQ0KVGhlIGRy YWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAyIHRyaWVzIHRvIHNvcnQgYW4gYW1iaWd1aXR5IG9m IFJGQyAzNjMzLCB0aGF0IHNheXMgInRoZSByZXF1ZXN0aW5nIHJvdXRlciBNVVNUIE5PVCBhc3Np Z24gYW55IGRlbGVnYXRlZCBwcmVmaXhlcyBvciBzdWJuZXRzIGZyb20gdGhlIGRlbGVnYXRlZCBw cmVmaXgoZXMpIHRvIHRoZSBsaW5rIHRocm91Z2ggd2hpY2ggaXQgcmVjZWl2ZWQgdGhlIERIQ1Ag bWVzc2FnZSBmcm9tIHRoZSBkZWxlZ2F0aW5nIHJvdXRlciIsIGJ1dCBSRkMgMzYzMyBkb2Vzbid0 IHNwZWNpZnkgaWYgYWRkcmVzc2VzIGZyb20gdGhlIHByZWZpeCBtYXkgYmUgdXNlZCBpbiB0aGUg cmVjZWl2aW5nIGludGVyZmFjZS4gV2UgYXJlIG5vdCBzdXJlIGlmIHRoZSBjdXJyZW50IHNwZWNp ZmljYXRpb24gZnJvbSBSRkMgMzYzMyBhbGxvd3Mgb3Igbm90IHRoZSB1c2Ugb2YgYWRkcmVzc2Vz IGZyb20gdGhlIHJlY2VpdmVkIHByZWZpeCBkZWxlZ2F0aW9uIG9uIHRoZSBpbnRlcmZhY2UgdGhh dCByZWNlaXZlZCB0aGUgcHJlZml4IGRlbGVnYXRpb24uDQoNClJlY29tbWVuZGF0aW9uOiBXaXRo IGEgYmV0dGVyIGludHJvZHVjdGlvbiB0byB0aGUgbmVlZCBmb3IgdGhpcyBkb2N1bWVudCwgd2Ug cmVjb21tZW5kIGl0IHRvIGJlIGFkb3B0ZWQgYXMgd29ya2luZyBncm91cCBkb2N1bWVudCwgaWYg b3BlcmF0b3JzIHNheSAid2UgcGxhbiB0byB1c2UgdGhpcyBwcm9wb3NhbCINCg0KQlIsDQoNCkVk d2luIENvcmRlaXJvDQoNCg== --_000_396f327690d24cfa8f519488bfc28bddXCH150505nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5BIG5ldyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgaXMgbm93IGF2YWlsYWJsZSBiYXNl ZCBvbiByZXZpZXcgY29tbWVudHMgcmVjZWl2ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjb21t ZW50cyBoYXZlIGdyZWF0bHkgaW1wcm92ZWQgdGhlIGRvY3VtZW50LCB3aGljaCBub3cgYWxzbyBp bmNsdWRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5maWd1cmVzIHRoYXQgY2xlYXJseSBpbGx1c3RyYXRl IHRoZSBjb25jZXB0cyBkZXNjcmliZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC10ZW1wbGlu LXY2b3BzLXBkaG9zdC0wNC50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRlbXBs aW4tdjZvcHMtcGRob3N0LTA0LnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlBsZWFzZSByZXZpZXcgYW5kIHBvc3QgY29tbWVudHMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Mg4oCTIEZyZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVkd2luIENvcmRl aXJvIFttYWlsdG86ZWR3aW5zY0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgQXVndXN0IDE2LCAyMDE2IDE6MDAgQU08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQg TCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElQdjYg T3BzIFdHICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2 Nm9wc10gUmV2aWV3IGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5IaSBGcmVkLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPkJlbG93IGFkZGl0aW9uYWwgY29tbWVudHMgdG8geW91ciByZXBsaWVzOjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsgPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+U3VtbWFyeTogVGhlIGRy YWZ0IHByb3ZpZGVzIGd1aWRlbGluZXMgZm9yIGEgaG9zdCB0aGF0IHJlY2VpdmVzIGEgcHJlZml4 IHRocm91Z2ggREhDUHY2LVBEPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+WWVzLCB0aGF0IGlzIGFjY3VyYXRlIGZvciB0aGUgZHJhZnQgaW4gaXRzIGN1cnJl bnQgZm9ybSwgYnV0IEkgd291bGQgbGlrZSB0byBjaGFuZ2UgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+ZHJhZnQgdG8gc2F5IHRoYXQgaXQgYXBwbGllcyB0byBwcmVmaXggZGVsZWdhdGlvbnMgcmVj ZWl2ZWQgdGhyb3VnaCBhbnkgbWVhbnMgYW5kIG5vdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmp1c3Qg REhDUHY2IFBELiBJdCB3b3VsZCBzYXkgdGhhdCBhIHByZWZpeCBkZWxlZ2F0aW9uIGluY2x1ZGVz IGEgY29tbXVuaWNhdGlvbiBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZSBwcmVmaXggZnJvbSB0 aGUgbmV0d29yayB0byB0aGUgaG9zdCwgYW5kIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHByZWZp eCBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5uZXR3b3JrIHJvdXRpbmcgc3lzdGVtLiBESENQ djYgUEQgd291bGQgdGhlbiBiZSBjaXRlZCBhcyBvbmx5IG9uZSBleGFtcGxlLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsgPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+YW5kIHdhbnQgdG8gdXNlIGFk ZHJlc3NlcyBmcm9tIHRoaXMgcHJlZml4IG9uIGl0cyBpbnRlcmZhY2UsIHNwZWNpZmljYWxseSBp biBhbiBBRVJPIFtSRkMgNjcwNl0gZW52aXJvbm1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGNvcnJlY3QgcmVm ZXJlbmNlIGZvciBBRVJPIGlzIOKAmGRyYWZ0LXRlbXBsaW4tYWVyb2xpbmvigJkuIEJ1dCwgdGhh dCBzaG91bGQgYmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj51bmRlcnN0b29kIGFzIG9ubHkgb25lIGV4 YW1wbGUg4oCTIHRoZSBzYW1lIHRlY2huaXF1ZXMgY2FuIGFwcGx5IHRvIGFueSBvdGhlcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPmxpbmsgdHlwZXMgaW5jbHVkaW5nLCBFdGhlcm5ldCwgV2lmaSwgZXRj Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAizwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj5TbyBwbGVhc2UgYWRkIHNvbWUgZGV0YWlscyBvZiBwb3NzaWJsZSBleGFtcGxlcyB0byBw cm92aWRlIGEgYmV0dGVyIGNvbnRleHQgZm9yIHRoZSBuZWVkIG9mIHRoaXMgZG9jdW1lbnQuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij7igIs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsgPC9zcGFu Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+Q29tbWVudHM6IFRoZSBkcmFmdCBjbGVhcmx5IHNwZWNpZnkgaG93IGEgaG9zdCBzaG91bGQg YmVoYXZlIHdoZW4gcmVjZWl2aW5nIGEgcHJlZml4IGRlbGVnYXRpb248L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsgPC9zcGFuPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+dGhyb3VnaCBESENQ djYtUEQgYW5kIHdhbnQgdG8gdXNlIGFkZHJlc3NlcyBmcm9tIHRoZSByZWNlaXZlZCBwcmVmaXgg b24gdGhlIGludGVyZmFjZSBpdCB1c2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+Jm5ic3A7IDwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPnRvIHJlcXVlc3QgdGhlIERIQ1AtUEQuIFVuZm9y dHVuYXRlbHkgdGhlIGRyYWZ0IGZhaWxzIHRvIGNsYXJpZnkgd2hlcmUgc3VjaCBiZWhhdmlvciBp cyBuZWVkZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJz cDsgPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+YW5kIGFjY2VwdGFibGUuIEV4YW1wbGUgb2YgdXNlIGNhc2VzIHdvdWxkIGJl IGEgZ3JlYXQgaW1wcm92ZW1lbnQgdG8gcHJvdmlkZSBzdWNoIGNvbnRleHQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGVyZSBpcyBzb21lIHByb3Bvc2Vk IHRleHQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IOKAnFRoaXMgYXBwcm9hY2ggaXMgYXBwbGljYWJsZSB0byBhIHdpZGUgdmFyaWV0 eSBvZiB1c2UgY2FzZXMuJm5ic3A7IEZvciBleGFtcGxlLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBpdCBjYW4gYmUgdXNlZCB0byBjb29yZGluYXRlIHRoZSBWaXJ0dWFsIFByaXZh dGUgTmV0d29yayAoVlBOKSBsaW5rcyBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyBtb2JpbGUgZGV2aWNlcyAoZS5nLiwgY2VsbHBob25lcywgdGFibGV0cywgbGFwdG9wIGNvbXB1 dGVycywgZXRjLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdGhhdCBjb25uZWN0 IGludG8gYSBob21lIGVudGVycHJpc2UgbmV0d29yayB2aWEgcHVibGljIGFjY2Vzczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBuZXR3b3Jrcy4mbmJzcDsgVGhlIGFwcHJvYWNoIGNh biBhbHNvIGJlIGFwcGxpZWQgdG8gYXZpYXRpb24gYXBwbGljYXRpb25zPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IGZvciBib3RoIG1hbm5lZCBhbmQgdW5tYW5uZWQgYWlyY3JhZnQg d2hlcmUgdGhlIGFpcmNyYWZ0IGlzIHRyZWF0ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgYXMgYSBtb2JpbGUgaG9zdC4gVmFyaW91cyBvdGhlciB1c2UgY2FzZXMgYXJlIGFsc28g aW4gc2NvcGUu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPuKAizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGV4YW1wbGUgaXMgaGVscGZ1bCwgYnV0IGEgYmV0 dGVyIGV4cGxhbmF0aW9uIG9mIHRoZSB1c2UgY2FzZXMgd291bGQgYmUgYmV0dGVyLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+4oCL PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAizwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgb3RoZXIgY29t bWVudHMgd2VyZSBhZGRyZXNzZWQgYnkgRnJlZCBCYWtlciBhbmQgSSBoYXZlIG5vdGhpbmcgdG8g YWRkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5FZHdpbiBDb3JkZWlybzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+4oCLPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiB2Nm9wcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkVkd2luIENvcmRlaXJvPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVn dXN0IDE1LCAyMDE2IDI6MjYgQU08YnI+DQo8Yj5Ubzo8L2I+IElQdjYgT3BzIFdHICZsdDs8YSBo cmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt2Nm9wc10gUmV2aWV3IGRyYWZ0LXRlbXBs aW4tdjZvcHMtcGRob3N0LTAyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+RG9jdW1lbnQ6 IGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTAyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+UmV2aWV3ZXJzOiBSaWNhcmRv IFBlbGFlei1OZWdybywgRWR3aW4gQ29yZGVpcm8sIEZyZWQgQmFrZXIsIE5hdmVlbiBLIExha3No bWFuICh2Nm9wcyBkcmFmdCByZXZpZXcgdGVhbSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5SZXZpZXcgRGF0ZTogMTUvYXVn LzIwMTY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5TdW1tYXJ5OiBUaGUgZHJhZnQgcHJvdmlkZXMgZ3VpZGVsaW5lcyBmb3Ig YSBob3N0IHRoYXQgcmVjZWl2ZXMgYSBwcmVmaXggdGhyb3VnaCBESENQdjYtUEQgYW5kIHdhbnQg dG8gdXNlIGFkZHJlc3NlcyBmcm9tIHRoaXMgcHJlZml4DQogb24gaXRzIGludGVyZmFjZSwgc3Bl Y2lmaWNhbGx5IGluIGFuIEFFUk8gW1JGQyA2NzA2XSBlbnZpcm9ubWVudDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkNvbW1l bnRzOiBUaGUgZHJhZnQgY2xlYXJseSBzcGVjaWZ5IGhvdyBhIGhvc3Qgc2hvdWxkIGJlaGF2ZSB3 aGVuIHJlY2VpdmluZyBhIHByZWZpeCBkZWxlZ2F0aW9uIHRocm91Z2ggREhDUHY2LVBEIGFuZCB3 YW50IHRvIHVzZQ0KIGFkZHJlc3NlcyBmcm9tIHRoZSByZWNlaXZlZCBwcmVmaXggb24gdGhlIGlu dGVyZmFjZSBpdCB1c2VkIHRvIHJlcXVlc3QgdGhlIERIQ1AtUEQuIFVuZm9ydHVuYXRlbHkgdGhl IGRyYWZ0IGZhaWxzIHRvIGNsYXJpZnkgd2hlcmUgc3VjaCBiZWhhdmlvciBpcyBuZWVkZWQgYW5k IGFjY2VwdGFibGUuIEV4YW1wbGUgb2YgdXNlIGNhc2VzIHdvdWxkIGJlIGEgZ3JlYXQgaW1wcm92 ZW1lbnQgdG8gcHJvdmlkZSBzdWNoIGNvbnRleHQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Bbm90aGVyIHJlY29tbWVuZGVkIGlt cHJvdmVtZW50IHdvdWxkIGJlIHRoZSBpbmNsdXNpb24gb2YgYSBkaWFncmFtIHRoYXQgc2hvdWxk IHNob3cgaG93IHRoZSBwcm9wb3NlZCBiZWhhdmlvciBkaWZmZXJzIGZyb20gdGhlIGN1cnJlbnQN CiBzcGVjaWZpY2F0aW9uIG9mIElQdjYgUHJlZml4IE9wdGlvbnMgZm9yIERIQ1B2NiAtIFJGQyAz NjMzICg8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM2MzMj c2VjdGlvbi01LjEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMzYzMyNzZWN0aW9uLTUuMTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGRyYWZ0LXRlbXBsaW4tdjZv cHMtcGRob3N0LTAyIHRyaWVzIHRvIHNvcnQgYW4gYW1iaWd1aXR5IG9mIFJGQyAzNjMzLCB0aGF0 IHNheXMgJnF1b3Q7dGhlIHJlcXVlc3Rpbmcgcm91dGVyIE1VU1QgTk9UIGFzc2lnbiBhbnkgZGVs ZWdhdGVkDQogcHJlZml4ZXMgb3Igc3VibmV0cyBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4KGVz KSB0byB0aGUgbGluayB0aHJvdWdoIHdoaWNoIGl0IHJlY2VpdmVkIHRoZSBESENQIG1lc3NhZ2Ug ZnJvbSB0aGUgZGVsZWdhdGluZyByb3V0ZXImcXVvdDssIGJ1dCBSRkMgMzYzMyBkb2Vzbid0IHNw ZWNpZnkgaWYgYWRkcmVzc2VzIGZyb20gdGhlIHByZWZpeCBtYXkgYmUgdXNlZCBpbiB0aGUgcmVj ZWl2aW5nIGludGVyZmFjZS4gV2UgYXJlIG5vdCBzdXJlIGlmIHRoZSBjdXJyZW50DQogc3BlY2lm aWNhdGlvbiBmcm9tIFJGQyAzNjMzIGFsbG93cyBvciBub3QgdGhlIHVzZSBvZiBhZGRyZXNzZXMg ZnJvbSB0aGUgcmVjZWl2ZWQgcHJlZml4IGRlbGVnYXRpb24gb24gdGhlIGludGVyZmFjZSB0aGF0 IHJlY2VpdmVkIHRoZSBwcmVmaXggZGVsZWdhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5SZWNvbW1lbmRhdGlvbjog V2l0aCBhIGJldHRlciBpbnRyb2R1Y3Rpb24gdG8gdGhlIG5lZWQgZm9yIHRoaXMgZG9jdW1lbnQs IHdlIHJlY29tbWVuZCBpdCB0byBiZSBhZG9wdGVkIGFzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQs DQogaWYgb3BlcmF0b3JzIHNheSAmcXVvdDt3ZSBwbGFuIHRvIHVzZSB0aGlzIHByb3Bvc2FsJnF1 b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+QlIsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5FZHdpbiBD b3JkZWlybzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_396f327690d24cfa8f519488bfc28bddXCH150505nwnosboeingcom_-- From nobody Fri Aug 19 02:53:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC2912D883 for ; Fri, 19 Aug 2016 02:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKmQD-yyrLGW for ; Fri, 19 Aug 2016 02:53:39 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60C412D87F for ; Fri, 19 Aug 2016 02:53:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1B7B3A2; Fri, 19 Aug 2016 11:53:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1471600416; bh=H9VYSOApujFROZSFI2ZtRGGTw9+eNB1c1V8o586rxOA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=D/gZt5kglDtrLPIk9ewcMBDTwx6/wXC+1Tqg96W+mGAhGcWpPPKAgcFyTqPrPeCmz 5HXB+a4WpgkWVOU04Bdk7QjIjtyVMsWuIzRky3YWYVjFwLeqDKgC5jsZ+PJOpsipEr cxFvHcD2q2O0VbtBLLDG9qRDBMar6meJpHxdT4lA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0D1F1A1; Fri, 19 Aug 2016 11:53:36 +0200 (CEST) Date: Fri, 19 Aug 2016 11:53:36 +0200 (CEST) From: Mikael Abrahamsson To: "Templin, Fred L" In-Reply-To: <396f327690d24cfa8f519488bfc28bdd@XCH15-05-05.nw.nos.boeing.com> Message-ID: References: <396f327690d24cfa8f519488bfc28bdd@XCH15-05-05.nw.nos.boeing.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 09:53:42 -0000 On Thu, 18 Aug 2016, Templin, Fred L wrote: > Hello, > > A new version of this draft is now available based on review comments received. > The comments have greatly improved the document, which now also includes > figures that clearly illustrate the concepts described: > > https://www.ietf.org/id/draft-templin-v6ops-pdhost-04.txt Re-reading as if I never read it before: 1. Intro " Hosts 'Hn' on a LAN interface subsequently receive addresses 'An' taken from 'P' via an address autoconfiguration service such as IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862]." If A=1 is used, I'd avoid using the term "receive addresses". "allocate addresse(s) for themselves" or similar term is more appropriate to make sure the reader understands the distinction. 4. "The node also configures a default route that points to a router on the WAN link." This sentence can in context confuse readers to believe that this default route is installed because of receiving a delegated prefix, when in fact this is done because the node received an RA. Right? 5. MLD/DAD Implications This is confusing. The node still has a LL which it needs to perform MLD/DAD for on the WAN interface, correct? Wouldn't it be better to just recommend not to put the delegated prefix addresses on the WAN interface at all, but exlusively use a virtual interface? On that virtual interface then MLD/DAD can be turned off. Otherwise the WAN interface needs to selectively support DAD/MLD for some addresses configured on it, and not for others. 6. Is the third paragraph really necessary? It describes no new functionality, the text seems to describe normal IPv6 operations. Seems it would only confuse the reader? 7. This paragraph would be simpler if we just avoid configuring the PD based addresses on the WAN interface. Summary: I am sympathetic to hosts requesting PD and then using it to assign itself addresses. I just think it would be cleaner if the weak host model was recommended and that the PD based addresses would only be configured on a virtual interface in case only the WAN interface exists. Also, calling it "WAN" interface is a bit confusing. What is a "WAN" interface on a host? I have no better suggestion for what to call it, WAN is short and "sweet" and using other names might just cause more confusion. The draft outlines what it means by WAN interface (good that you added the drawings) so it should be ok. The draft is DHCPv6 heavy and SLAAC light when it comes to text, it seems to talk more about DHCPv6 functions and glosses over things that are configured because of RAs etc. For someone not familiar with IPv6, they might draw the wrong conclusions on how IPv6 works regarding RA/DHCP interaction and what causes what. Perhaps there should be some more pointers to this, and if the text is DHCP verbose, then I think it needs to be equally verbose on SLAAC/RA. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Aug 21 15:54:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD4012D1E3; Sun, 21 Aug 2016 15:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTWFTz6TWBYh; Sun, 21 Aug 2016 15:54:11 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6159D12D567; Sun, 21 Aug 2016 15:54:10 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l203so129237813oib.1; Sun, 21 Aug 2016 15:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qV3Mm3ILIO609CQcL7zYGH3mByL49vZ9SUEET3sfIts=; b=NglRrGlVxKxsp0J6mVu4ZWZ770bwJn6TDyZLs9W1t7wyyoEAsCUTow5iHRqK2mjbw0 p/gi5o1mccOlCF4N6O+3dwV1Zz1G4t92GTvV+z6FDY4yzfZymHQNhBAvd61suALkeA3x 8m9P5lCcguK6Vk8ztlrSsjWnkhL+LLv1ZkMVAImeckyoUzlbVng8Isto6dI3TKEbuTFy Do6gftcd4Nm30iEzMO/Z44otExTJkN+eXA67dT6FT/Ue/fbR8conOb19CZW/Qb7hM5F/ AQ6GwOnbMaTIXjsl7FJo/KwoSkGEzq5J2Ver8MgDj/0GFxvRix0lO1zLulfqf099L21y T4/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qV3Mm3ILIO609CQcL7zYGH3mByL49vZ9SUEET3sfIts=; b=FeBza/9ffs/iOnijFAL7xK/26w096jl76k4dGdVsNAj9U6DkWoA6ujNAIKnx0Ltv1K ugbnRvNBLcngnDCHemWiIsV23HhWElYLW9zZXD1ixmy4hZ5IjpYrXgM2FZoDoZPobkrG mzMt+1fs5No405oz1HfMCv/TBTcAK1EQK0aiByHieg2AkT7QDeBso5Anjzam0Pk/FaIk WNha2e505KQaFXciQEmeo6OGf3VsD1GiH46aOUvcC9CuImkTWdzyM8onAfgzu2SQrxv6 kdSpuYtGnUOy2YdIui/JvKecsOO9z0qWHMpH/mPBiTbwILE9xhwhNaEAiCikvHqjggXl 43Fg== X-Gm-Message-State: AEkoousKePPK2j0Svuz4bWCyqRl8GQz5GJmkN//w0TAmv1JukIJWQqIuCtFSkkWg9S3Rxbau+GQyqcO1Xl/BQA== X-Received: by 10.202.45.4 with SMTP id t4mr10917956oit.34.1471820049813; Sun, 21 Aug 2016 15:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Sun, 21 Aug 2016 15:54:09 -0700 (PDT) In-Reply-To: References: From: Hemant Singh Date: Sun, 21 Aug 2016 18:54:09 -0400 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=001a1137b5043e176e053a9ccf25 Archived-At: Cc: IETF IPv6 Mailing List , v6ops@ietf.org, "v6ops-chairs@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 22:54:13 -0000 --001a1137b5043e176e053a9ccf25 Content-Type: text/plain; charset=UTF-8 Not quite. I am specifically comparing ND to ARP which has its own ethertype while ND does not. I am not proposing a new ethertype for crafted packets in attack vectors. Obviously there was no firewall in many deployments where this crafted ND packet went through or there was a firewall which did not catch the crafted packet. The new ethertype for ND and another uses. It can be used to to filter packets for a DAD or ND Proxy implementation. Hemant On Sun, Aug 21, 2016 at 3:03 PM, Philip Homburg wrote: > > > In the past, a device that filters out traffic that hosts should not > receive was called a 'firewall'. > > I guess it would be nice if every different type of a packet that a > firewall needs to recognize would get a different ether type, but I'm sure > that that's not going to happen. > > I think it is safe to assume that a firewall can scan TCP and UDP traffic > at wire speed, so it doesn't seem unreasonable to assume that the same can > be done for ND traffic. > > > --001a1137b5043e176e053a9ccf25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not quite.=C2=A0 I am specifically comparing ND to ARP whi= ch has its own ethertype while ND does not. =C2=A0 I am not proposing a new= ethertype for crafted packets in attack vectors. =C2=A0 Obviously there wa= s no firewall in many deployments where this crafted ND packet went through= or there was a firewall which did not catch the crafted packet.=C2=A0 The = new ethertype for ND and another uses.=C2=A0 It can be used to to filter pa= ckets for a DAD or ND Proxy implementation.

Hemant


On Sun, Au= g 21, 2016 at 3:03 PM, Philip Homburg <pch-v6ops-5@u-1.phicoh.com= > wrote:
<= br>
In the past, a device that filters out traffic that hosts should not=
receive was called a 'firewall'.

I guess it would be nice if every different type of a packet that a
firewall needs to recognize would get a different ether type, but I'm s= ure
that that's not going to happen.

I think it is safe to assume that a firewall can scan TCP and UDP traffic at wire speed, so it doesn't seem unreasonable to assume that the same = can
be done for ND traffic.



--001a1137b5043e176e053a9ccf25-- From nobody Sun Aug 21 16:41:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E16B127058; Sun, 21 Aug 2016 16:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV6iuLW43jdh; Sun, 21 Aug 2016 16:41:20 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F1C12D0F7; Sun, 21 Aug 2016 16:41:19 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id n59so161917521uan.2; Sun, 21 Aug 2016 16:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xK0qC6OS2BURv8wP50XYDQPrcAbS7zke2x7eVkTT57Y=; b=eGcI+Sl1gm41zQ3UEjxvILr1Ub92B0baYyPEWLf7V2Ig88f1D/OS9omki8yLteD8M2 bEV2rEeeiReYfv2emxlV2SzJh0daRl5lCWCXD4D/LyaJsueJljA4iVTlC2b6gyUALOXM wQseoEowK84eZkVj4lImJGKKsoWThe/HGk9HctwzHuO8V6eDerHyo7E/uuhehZexxlh7 otMD4rm0ZaEOVqSjmrRxD94v/WB1WAB/IgFteXvlKT7E3MZLVQUaVnlCyHYdlwkCXRf4 vciOuzLo3i0VauuBvTlgdW4vrghO+Q8coJWeAYgFfG1HwcVa/xcuGZg2AIdlKj29mrDu BxUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xK0qC6OS2BURv8wP50XYDQPrcAbS7zke2x7eVkTT57Y=; b=fv2UYgK3+m8w6qvCYKBS3oERuF/iF80Rq2KS3j9ye4Mfi8t/VlMdUw/yCqv3jCNdZo ciNv+ja3h06XWvrabBvl5EscNnqdrKtMwaWiVXBWLkoZld66CaNTd+XMrxrXpSoTmP7m M2618rnph0vIRWTxorvyNYVSVAL85ozEcHJvP7ERA8dZXYK3kkcMmgEVsnCMij0GKWML fwEFhEbAW75GgQHWJwb3B8USSfVJBeMaYvsaKPjyx92S73bEvgkmlB9nUzFLnfA/lBc2 UXlbvZPTQEQS6inHbSaIyNCY9smmaYJmIF1KHAAW1BDwcxlLsQUw+nsWiz5xhTbyyILV Vhmw== X-Gm-Message-State: AEkooutiJlfZzmNuGRnthLdIDDaCpYYhMN/2bkYPZy8tpsD7uV0opYiXOQnOd6sKXRVi8JWclGCFSK/kVvPuRg== X-Received: by 10.31.98.133 with SMTP id w127mr8539212vkb.29.1471822878891; Sun, 21 Aug 2016 16:41:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.165 with HTTP; Sun, 21 Aug 2016 16:40:48 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Mon, 22 Aug 2016 09:40:48 +1000 Message-ID: To: Hemant Singh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , "v6ops-chairs@ietf.org" , IETF IPv6 Mailing List , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 23:41:21 -0000 On 22 August 2016 at 08:54, Hemant Singh wrote: > Not quite. I am specifically comparing ND to ARP which has its own > ethertype while ND does not. I am not proposing a new ethertype for > crafted packets in attack vectors. Obviously there was no firewall in many > deployments where this crafted ND packet went through or there was a > firewall which did not catch the crafted packet. The new ethertype for ND > and another uses. It can be used to to filter packets for a DAD or ND Proxy > implementation. > Sort of seems to be a lot of effort to mitigate what is fundamentally a problem of not following very clear processing requirements in RFC4861 by the target node: "A node MUST silently discard any received Neighbor Solicitation messages that do not satisfy all of the following validity checks: - The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router." Writing more specifications to mitigate against people not completely following existing specifications only creates more new specifications they may not follow completely either. Does anyone have any insights into how multiple implementations might have missed or perhaps intentionally decided not to perform this validity check? It seems a bit unusual that two different commonly used implementations didn't do it (I just checked the Linux and FreeBSD source and they do perform the check.) In cases such as this, perhaps implementation checklists (perhaps as an RFC appendix) could assist either the implementer or a code reviewer in ensuring they've implemented things completely. Regards, Mark. > Hemant > > > On Sun, Aug 21, 2016 at 3:03 PM, Philip Homburg > wrote: >> >> >> >> In the past, a device that filters out traffic that hosts should not >> receive was called a 'firewall'. >> >> I guess it would be nice if every different type of a packet that a >> firewall needs to recognize would get a different ether type, but I'm sure >> that that's not going to happen. >> >> I think it is safe to assume that a firewall can scan TCP and UDP traffic >> at wire speed, so it doesn't seem unreasonable to assume that the same can >> be done for ND traffic. >> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Aug 21 19:05:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B5412B03A; Sun, 21 Aug 2016 19:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MNFGmrNSpUQ; Sun, 21 Aug 2016 19:04:59 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF15F120727; Sun, 21 Aug 2016 19:04:58 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id l203so132719964oib.1; Sun, 21 Aug 2016 19:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fGXGC0dEr9VLAQOCp0gCa/YsEvwfnQ5btYxjH1wuKb4=; b=N1J0t4kWAmQ6OcqrhaFaREOW0dlhFtJXecEpD9/YvBfnXGRnxq02amptSlpLToVW2I TYeNCCQ0SWsrdQ/giOrLeiaGj4rp/1ZPEOOnBRV23lU2/UjoUkxCrCMwwpynarp7Ldpz oOn0mFDI+Oml4YxlLeEP1aAY4VZY+TvtCVrs9jisMFp+XjDrP5+IFknWNM5UXvhhYm5p r1izPRTYWJ+OVCTKAjCcOzcNUuvx3nEJpfpPF6IqT3+CVnPGOKof6ZjcSXTbm5Vt9NHr k+em5mcKOvpwq1tpyR7OVrQ9S5e+iYOccTj6Nlym+YXTj5L6FgUWau787r5Nqch/DgC9 VNZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fGXGC0dEr9VLAQOCp0gCa/YsEvwfnQ5btYxjH1wuKb4=; b=IeMskv2wXLTfB5OHBQ6KfMjmJ0Wk/jKS/moex/iUp3dzanWweLJYx5GwfFrfJkdofa MFHSrAnHfYtyjDxDcWP4l929fqeiz3Zs6JGJ527sbG5Mw8Cm17cqVvOaiLlOrg6HqRST qJ9yIJJmmqZyrdTW3rJ9SLWu8iB2z75rhWr/DU14jzNiJACHHcKybORmp4fLjjWDw0ow GQKysGZQF7TkyGQ10qnkUq2CCodhU98czqfliE4/qNpjLa0xyEGjQsh2fFp50sN4c9up DvqCKplnceBAKVH40+t7sG517YzomVWVXf5cJC2Mp0/lvnflXVAKaIEpGPkKYdChM9HD MqeQ== X-Gm-Message-State: AEkoouvDH1HBHm70iio11WGewXXCeHbc6w8g+DdvpNjncOHIqoQaNT+SvielSQ1bUMVADDBKOcu86I0HetKipw== X-Received: by 10.202.91.66 with SMTP id p63mr10437586oib.55.1471831498299; Sun, 21 Aug 2016 19:04:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Sun, 21 Aug 2016 19:04:57 -0700 (PDT) In-Reply-To: References: From: Hemant Singh Date: Sun, 21 Aug 2016 22:04:57 -0400 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=001a113d54c0a02091053a9f795c Archived-At: Cc: v6ops list , "v6ops-chairs@ietf.org" , IETF IPv6 Mailing List , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 02:05:00 -0000 --001a113d54c0a02091053a9f795c Content-Type: text/plain; charset=UTF-8 Mark, It's been already discussed why some nodes missed it and I have also pointed out that RFC4861 spells out the requirement clearly. Thanks for the reminder again. The reason some nodes missed it because the nodes are high-end routers forwarding traffic at high rate such as 200 Gbps. Such a router's data plane has to perform DPI (Deep Packet Inspection) to catch this crafted ND packet and the router's data plane incurs the DPI cost on every forwarded packet. This is why some routers do not perform the check and forwarded the packet instead of dropping the packet. Another error happened that an end node receiving the packets did not drop it but decided to issue an address resolution, and thus the cpu the packets are punted to, got inundated. The end host should have checked the Hop Limit and dropped the packet. Regards, Hemant On Sun, Aug 21, 2016 at 7:40 PM, Mark Smith wrote: > > Sort of seems to be a lot of effort to mitigate what is fundamentally > a problem of not following very clear processing requirements in > RFC4861 by the target node: > > "A node MUST silently discard any received Neighbor Solicitation > messages that do not satisfy all of the following validity checks: > > - The IP Hop Limit field has a value of 255, i.e., the packet > could not possibly have been forwarded by a router." > > Writing more specifications to mitigate against people not completely > following existing specifications only creates more new specifications > they may not follow completely either. > > Does anyone have any insights into how multiple implementations might > have missed or perhaps intentionally decided not to perform this > validity check? It seems a bit unusual that two different commonly > used implementations didn't do it (I just checked the Linux and > FreeBSD source and they do perform the check.) > > In cases such as this, perhaps implementation checklists (perhaps as > an RFC appendix) could assist either the implementer or a code > reviewer in ensuring they've implemented things completely. > > Regards, > Mark. > > --001a113d54c0a02091053a9f795c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mark,

It's been already discussed w= hy some nodes missed it and I have also pointed out that RFC4861 spells out= the requirement clearly. =C2=A0 Thanks for the reminder again. =C2=A0

The reason some nodes missed it because the nodes are = high-end routers forwarding traffic at high rate such as 200 Gbps.=C2=A0 Su= ch a router's data plane has to perform DPI (Deep Packet Inspection) to= catch this crafted ND packet and the router's data plane incurs the DP= I cost on every forwarded packet.=C2=A0 This is why some routers do not per= form the check and forwarded the packet instead of dropping the packet. =C2= =A0

Another error happened that an end node receiv= ing the packets did not drop it but decided to issue an address resolution,= and thus the cpu the packets are punted to, got inundated.=C2=A0 The end h= ost should have checked the Hop Limit and dropped the packet.=C2=A0

Regards,

Hemant


On Sun, Aug 21, 201= 6 at 7:40 PM, Mark Smith <markzzzsmith@gmail.com> wrote= :

Sort of seems to be a lot of effort to mitigate what is fundamentall= y
a problem of not following very clear processing requirements in
RFC4861 by the target node:

"A node MUST silently discard any received Neighbor Solicitation
=C2=A0 =C2=A0messages that do not satisfy all of the following validity che= cks:

=C2=A0 =C2=A0 =C2=A0 - The IP Hop Limit field has a value of 255, i.e., the= packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 could not possibly have been forwarded by a rou= ter."

Writing more specifications to mitigate against people not completely
following existing specifications only creates more new specifications
they may not follow completely either.

Does anyone have any insights into how multiple implementations might
have missed or perhaps intentionally decided not to perform this
validity check? It seems a bit unusual that two different commonly
used implementations didn't do it (I just checked the Linux and
FreeBSD source and they do perform the check.)

In cases such as this, perhaps implementation checklists (perhaps as
an RFC appendix) could assist either the implementer or a code
reviewer in ensuring they've implemented things completely.

Regards,
Mark.

--001a113d54c0a02091053a9f795c-- From nobody Sun Aug 21 22:32:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E1312D113; Sun, 21 Aug 2016 22:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Hg4Fyjconpu; Sun, 21 Aug 2016 22:32:50 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC97E12B006; Sun, 21 Aug 2016 22:32:50 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id k90so170647353uak.1; Sun, 21 Aug 2016 22:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GjlCDU3o42llXOQfQq4+lScw4U6p5FkNci/2FY9ZbHQ=; b=ceHZzD4DVrvMo/uTqoxgnMZL3yIt8ukaH/ySWTJVkbhoEiGceptwRGOHTw2VQHchTn X4VqiwF0O9NoxqYMqeBXTjwMaQzWk1qw4UuqU8rIpDK1GrJ0AuRD5xYMZWxwvRfm6WsQ RlFj52vz9IzAjd/Codkl5JEArQQc5orQ9FuKhsBoju3e3VCIjY4Yp9bagfBBw7Ggitsd pJEs9WL0Hr0irTZEg2rOsXP2hGkSAFZ5QeG73aXz+qHoBi4uolRVkan4HzFGPCJZvNO/ oYIEqwbEDDUQDzyKN8h0CZ1SKr178TcoR6ShM60TRJEQzKwYVsvTcj/vFyM681OXYuq8 5FGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GjlCDU3o42llXOQfQq4+lScw4U6p5FkNci/2FY9ZbHQ=; b=aZC4Q7BBRVxH/cGmD/pdY0iy0KcImE2JlbuR5bIrW9iKyz+uJeATmf4Zz85hTGMEBV DjUhT/ioX65YMRLBmQPMIDHQ5RzEY4VJh/N1ktDc3QaLqSDzhUPtNJBPMeLc3xhOszL7 UZvfLQpMb9leO0XzuKux8fEt6EdqoHegv5O0hg4jTzEYHooHHhhL/bQ/tV7DVVJ2Zhwy bKZIRex4w86lVPRq9l5Q6gJdzoOaV0z+P2UWz4kuR+gPSYq+6Aendb2KWXUlEezXDLS8 8BqtSXXpKKGrS7f4JIk14Kcgglo6hAcTuRhk1FFoZarnp2Lq/s5Gmm5Z9HuD5KxW91YJ KokQ== X-Gm-Message-State: AEkoouukqBvitlzVoFrD8/LFcNBzVIhequ4qHOkmO+IHtFCg2R9MJ68doVlGOcV2c4XmxMrIFOB8FSP9btDaEg== X-Received: by 10.176.80.58 with SMTP id b55mr10352081uaa.118.1471843969655; Sun, 21 Aug 2016 22:32:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.165 with HTTP; Sun, 21 Aug 2016 22:32:19 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Mon, 22 Aug 2016 15:32:19 +1000 Message-ID: To: Hemant Singh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , "v6ops-chairs@ietf.org" , IETF IPv6 Mailing List , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 05:32:52 -0000 On 22 August 2016 at 12:04, Hemant Singh wrote: > Mark, > > It's been already discussed why some nodes missed it and I have also pointed > out that RFC4861 spells out the requirement clearly. Thanks for the > reminder again. > > The reason some nodes missed it because the nodes are high-end routers > forwarding traffic at high rate such as 200 Gbps. Such a router's data > plane has to perform DPI (Deep Packet Inspection) to catch this crafted ND > packet and the router's data plane incurs the DPI cost on every forwarded > packet. This is why some routers do not perform the check and forwarded the > packet instead of dropping the packet. > So this sort of issue has also popped up recently with forwarding of packets with link-local source and GUA destination addresses off-link - routers are purely forwarding based on destination address for performance reasons. It has also popped up with the HBH header - RFC2460bis is loosening the HBH processing requirement for routers, again for performance reasons. Forgetting for the moment about how Source Address Dependent Routing might change this whole space, perhaps we need to loosen the requirement that these sorts of checks must be performed at each and every hop. Instead, view them as checks to be performed either by the first hop router or by the last hop router where appropriate (e.g., how we view BCP38 checks), and allow them to be disabled on trusted router to router hops for performance, at the possible cost of occasionally forwarding packets that shouldn't be if they're originated within the network somehow (e.g., router control plane bug). (I've sort of been thinking this way a bit already, which is why I was thinking the HL==255 check is only to be performed by the receiving host, and the use of the term 'node' should have really been 'host' in RFC4861). Ideally it would be good if there was a way to automate whether to enable or them or not e.g., between a pair of routers, the link is known to be a true point-to-point link, or the set of neighbor cache entries exactly match the routing protocol neighbors, or all of the neighbors in the neighbor cache have the Router flag set. (or, as they seem to be being disabled by default now, it could be as simple as enabling them if there is at least one neighbor cache entry that doesn't have the Router flag set). > Another error happened that an end node receiving the packets did not drop > it but decided to issue an address resolution, and thus the cpu the packets > are punted to, got inundated. The end host should have checked the Hop > Limit and dropped the packet. > So in summary, the HL=255 check actually wasn't being performed in two different places, and if it had been being performed in one of them, it attack wouldn't have succeeded: - intermediate routers weren't performing it - the ND NS target hosts (control plane of the router implementations) weren't performing it either Regards, Mark. From nobody Mon Aug 22 01:35:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC9C12B00D; Mon, 22 Aug 2016 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8aIZZqk_RrP; Mon, 22 Aug 2016 01:35:52 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8DA12B00A; Mon, 22 Aug 2016 01:35:51 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 08:35:50 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 3C1069CC82; Mon, 22 Aug 2016 01:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=8HgVdbCZZXepeYSr+uq0bifZjdI=; b= s9Uji1Ax2lfq7E5OV5PoyE5TciVfczHm35sIIVuX0z8Mt/NIYLLuQ5mvyxYn80nb qoAwfErEKt4l49UVi2i9IxTv7Ebq32TX1H9qwN+M3geqaZ+X4FUG4cnpmGR9jRGS FQUILcnSEG2mRNHz330ill4eKPaRnZqL49Bfz5W4w74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=FP5gMyEECZ/TGKQD58I68Xgga3 8mqj0u/fIV+ZIiwxnQrIpWMnN/m8ASYAutb7GXuT7bH8UoJ3GUHH2vmVlzIgoZYJ 7ANDe01GFl8t/g+jRe2feQdYIE9tC5qBQh4ryFwZy5GwMQas8EEjs7Ul8eczKux4 JTaNtiesMg1kHwJBQ= Received: from h.hanazo.no (unknown [173.38.220.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id BF7C79CC81; Mon, 22 Aug 2016 01:35:48 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 32F7434B1969; Mon, 22 Aug 2016 10:35:48 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_20991388-CB14-427D-B696-95A3946359FB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Mon, 22 Aug 2016 10:35:47 +0200 Message-Id: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> References: To: Mark Smith X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG , "v6ops-chairs@ietf.org" , v6ops list , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 08:35:54 -0000 --Apple-Mail=_20991388-CB14-427D-B696-95A3946359FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, >> Not quite. I am specifically comparing ND to ARP which has its own >> ethertype while ND does not. I am not proposing a new ethertype for >> crafted packets in attack vectors. Obviously there was no firewall = in many >> deployments where this crafted ND packet went through or there was a >> firewall which did not catch the crafted packet. The new ethertype = for ND >> and another uses. It can be used to to filter packets for a DAD or = ND Proxy >> implementation. >>=20 >=20 > Sort of seems to be a lot of effort to mitigate what is fundamentally > a problem of not following very clear processing requirements in > RFC4861 by the target node: >=20 > "A node MUST silently discard any received Neighbor Solicitation > messages that do not satisfy all of the following validity checks: >=20 > - The IP Hop Limit field has a value of 255, i.e., the packet > could not possibly have been forwarded by a router." >=20 > Writing more specifications to mitigate against people not completely > following existing specifications only creates more new specifications > they may not follow completely either. >=20 > Does anyone have any insights into how multiple implementations might > have missed or perhaps intentionally decided not to perform this > validity check? It seems a bit unusual that two different commonly > used implementations didn't do it (I just checked the Linux and > FreeBSD source and they do perform the check.) >=20 > In cases such as this, perhaps implementation checklists (perhaps as > an RFC appendix) could assist either the implementer or a code > reviewer in ensuring they've implemented things completely. The issue isn't about the hop limit validation check not being done (it = is), it is about _where_ it is done. A packet is determined to be for the router itself, the hardware = forwarding plane then needs to decide if it should process the packet = itself, punt the packet to software or drop it. There might be orders of = magnitude difference in pps capability between software and hardware. Is there anything we can learn from this? We have to consider in protocol design how expensive it is to determine = if a forus() packet should be dropped or not. Looking deep into a packet to determine it is an ND packet and then do = the validity checks in hardware might not be optimal. Perhaps ND packets should have been limited to using link-local = addresses only. In-band signalling is fraught with dangers. Cheers, Ole --Apple-Mail=_20991388-CB14-427D-B696-95A3946359FB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXurljAAoJED4aXnjSQuKWuXQIAJZHBsnwuRbVUSp9njmNvFw7 AsADCdgFSnAaNJQl15dxSJr6Kkxa4CZIJsCzH1Wu6UhgEPvO4NWxyzXJ3/dLPfT9 +iu2aT87dy3aUUMEmqMmHEcIx/PbjoVB10vnp8Jw79SNw8o+glhGk8hk1mv1DdpQ bNeL3VUo4UkTuFTef1lbXZ1YXTUhd1Q6j2cfBcv7/gwN3rIGn74XpYJ8q3+t8XaN rWR7bN6UqyvFDrEXfVvk6gZ0ZodSg+zpfw7GCzh01bMUt7OpIufZcBR2NuUFjGhr RK/3jBmmhhWp5RK7ji1UEc1d3oOICz4gOHpkFXtrNR1/kj2abOM3E5w57MXl/00= =buaf -----END PGP SIGNATURE----- --Apple-Mail=_20991388-CB14-427D-B696-95A3946359FB-- From nobody Mon Aug 22 03:22:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7AA12D113 for ; Mon, 22 Aug 2016 03:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s8wb0Z2UwWH for ; Mon, 22 Aug 2016 03:22:03 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0988012B076 for ; Mon, 22 Aug 2016 03:22:03 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id n59so180153297uan.2 for ; Mon, 22 Aug 2016 03:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ah1eeINrI8Vx2JhMwNfwTIgb9JyikHNwhDSiDfqeG2I=; b=vJJ8Qkvt5TBqtYFpXtthZa7lMF5V+fjUXlHaoqHvd8LOcr4YbeKzBh7mpx7sl1nESA +6pcXSJHl7H3dDbvHXEBzbEAdqAqEy7fUgLSaOhtwZSGq2wt3pVAdqFofg9fQqFd2CEo KjGkc7LDuxmxUdNIj9rk0r02PMvpELxQMz5nrEPqJ3tzb/IkYtnHfZoChCCNuihlaOcV cGSKBypzXcc5o/dKYGF5OeN6UtrjJfVMo7qUzyb2Jo+pHb2N4sR17q+NQXy/du/U6JNn YKyAJdkEAgehZ/Ggj1UXMrhIqK/wphgIZGQI3iHaaH8h1jph/kvXJrMmvaUgvLm9INfS Y5cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ah1eeINrI8Vx2JhMwNfwTIgb9JyikHNwhDSiDfqeG2I=; b=LAsm+DXrC+vkKbVHYOIbZHgZOPJtuJnuGabTMeIsrahiT3UphIcmPYdWlo3M0G/hb6 rPxX4cpI057fubmzT5C6SUnZNqte573uJv53hbSePyfNAjls/gwJEleIpyyM6LZlVRWp QycRn1xhylJ6VuBzHx9DxZUSpwseSIlEp+KJrZEts4vxo3807Ult9TwukkAWsXUB7EDg cJ+FP/C2NlTngpdXI/mzX/WfVRGHIvnXaX827bl+8mGl58AeQGi94QxEt/waTiVKfHrq 7ExCKil6eehEeJCNTo7+xClEINgg/PMuuoUm78gMjuFZCQxs4Ez+Y4yV5kQ2or7JuDik M8yQ== X-Gm-Message-State: AEkoousOEAAdIE7eV7RGS8SsctDT/r0CD+iQMO+BE9AGn3Gmdz2aqoneD82qsH/W5gV5gQC0lQkWFxKWRG1H3g== X-Received: by 10.176.80.58 with SMTP id b55mr10842884uaa.118.1471861322124; Mon, 22 Aug 2016 03:22:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.165 with HTTP; Mon, 22 Aug 2016 03:22:01 -0700 (PDT) Received: by 10.176.1.165 with HTTP; Mon, 22 Aug 2016 03:22:01 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Mon, 22 Aug 2016 20:22:01 +1000 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=94eb2c18f73c43948c053aa66b7e Archived-At: Cc: v6ops list Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 10:22:04 -0000 --94eb2c18f73c43948c053aa66b7e Content-Type: text/plain; charset=UTF-8 On 22 Aug 2016 7:49 PM, "Philip Homburg" wrote: > > >Instead, view them as checks to be performed either by the first hop > >router or by the last hop router where appropriate (e.g., how we view > >BCP38 checks), and allow them to be disabled on trusted router to > >router hops for performance, at the possible cost of occasionally > >forwarding packets that shouldn't be if they're originated within the > >network somehow (e.g., router control plane bug). (I've sort of been > >thinking this way a bit already, which is why I was thinking the > >HL==255 check is only to be performed by the receiving host, and the > >use of the term 'node' should have really been 'host' in RFC4861). > > I'm confused. As far as I know, routers are not supposed to look at the HL field, > other than to decrement it and drop the packet when it reaches zero. > > Af for a receiving 'host', as far as I know, 'host' refers to a node that is not > router. Router are also involved in ND. So the proper requirement is that any > node that is the target of an ND (as opposed to just forwarding it) should > perform the HL check. > I've also been confused until I found that section 7.2.3, later than the HL==255 check section (7.1.1), is where the ND NS DA match check is performed. (If those sections were in opposite order it would be a bit more obvious what is happening). So yes, only the ND NS target performs the HL==255 check. > Given that processing a ND packet on a router already takes it out of the > fast path, adding the HL check shouldn't be a big deal. > > As long as the router is just forwarding the ND packet, it doesn't have to care > so it can use the fast path just fine. > So I think what has happened here is that the attack packets have been manufactured to be sent off-link, and the receiving implementations, when they were the target of the attack ND NS packet, didn't do the HL==255 check. > (Obviously it makes sense for firewalls to drop ND packets, but firewalls are > supposed to do deep packet inspection anyhow) > > Relating to a comment Ole made, I've wondered why ND didn't exclusively user link-locals for a while, but never got around to thinking about it. I think if it did, then nodes would have to maintain a binding between each non-LL address and the LL address to use to test it e.g. perform NUD. Probably possible, but more complex. Regards, Mark. --94eb2c18f73c43948c053aa66b7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 22 Aug 2016 7:49 PM, "Philip Homburg" <pch-v6ops-5@u-1.phicoh.com>= wrote:
>
> >Instead, view them as checks to be performed either by the first h= op
> >router or by the last hop router where appropriate (e.g., how we v= iew
> >BCP38 checks), and allow them to be disabled on trusted router to<= br> > >router hops for performance, at the possible cost of occasionally<= br> > >forwarding packets that shouldn't be if they're originated= within the
> >network somehow (e.g., router control plane bug). (I've sort o= f been
> >thinking this way a bit already, which is why I was thinking the > >HL=3D=3D255 check is only to be performed by the receiving host, a= nd the
> >use of the term 'node' should have really been 'host&#= 39; in RFC4861).
>
> I'm confused. As far as I know, routers are not supposed to look a= t the HL field,
> other than to decrement it and drop the packet when it reaches zero. >
> Af for a receiving 'host', as far as I know, 'host' re= fers to a node that is not
> router. Router are also involved in ND. So the proper requirement is t= hat any
> node that is the target of an ND (as opposed to just forwarding it) sh= ould
> perform the HL check.
>

I've also been confused until I found that section 7.2.3= , later than the HL=3D=3D255 check section (7.1.1), is where the ND NS DA m= atch check is performed. (If those sections were in opposite order it would= be a bit more obvious what is happening).

So yes, only the ND NS target performs the HL=3D=3D255 check= .

> Given that processing a ND packet on a router already t= akes it out of the
> fast path, adding the HL check shouldn't be a big deal.
>
> As long as the router is just forwarding the ND packet, it doesn't= have to care
> so it can use the fast path just fine.
>

So I think what has happened here is that the attack packets= have been manufactured to be sent off-link, and the receiving implementati= ons, when they were the target of the attack ND NS packet, didn't do th= e HL=3D=3D255 check.

> (Obviously it makes sense for firewalls to drop ND pack= ets, but firewalls are
> supposed to do deep packet inspection anyhow)
>
>

Relating to a comment Ole made, I've wondered why ND did= n't exclusively user link-locals for a while, but never got around to t= hinking about it. I think if it did, then nodes would have to maintain a bi= nding between each non-LL address and the LL address to use to test it e.g.= perform NUD. Probably possible, but more complex.

Regards,
Mark.

--94eb2c18f73c43948c053aa66b7e-- From nobody Mon Aug 22 05:33:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6FD12D190; Mon, 22 Aug 2016 05:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuKjcKoqKu4Y; Mon, 22 Aug 2016 05:33:26 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7893F12D197; Mon, 22 Aug 2016 05:33:07 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=48328 helo=envy) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1bboPX-0000tX-AU; Mon, 22 Aug 2016 14:33:03 +0200 Date: Mon, 22 Aug 2016 14:33:02 +0200 From: Tore Anderson To: otroan@employees.org Message-ID: <20160822143302.2da13b80@envy> In-Reply-To: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops-chairs@ietf.org" , v6ops list , 6man WG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 12:33:28 -0000 * otroan@employees.org > The issue isn't about the hop limit validation check not being done > (it is) Are you certain that it is? Both Cisco CSCuz66542 and Juniper JSA10749 describe how the crafted ND packets will be *processed* by the control plane - not dropped. Furthermore, both advisories go on to describe how successful exploitation might cause the device to stop handling *IPv6* traffic specifically - as opposed to impacting *all* traffic. While the advisories don't go into detail, this suggests to me that successful exploitation of the issue is dependent on the crafted packets actually being able to manipulate/overwhelm the IPv6 neighbour caches. That couldn't happen if the hop limit validation was done and the packet was dropped - even though this was done in software, by the control plane itself. > A packet is determined to be for the router itself, the hardware > forwarding plane then needs to decide if it should process the packet > itself, punt the packet to software or drop it. There might be orders > of magnitude difference in pps capability between software and > hardware. Sure. If you're able to bombard the control plane with packets, bypassing any hardware ACL, you're most likely going to be successful in taking down the box. However such an attack will not only impact IPv6 (it will offline everything), nor is there any reason to single out ICMPv6 ND packets as particularly problematic. That is: if you're able to saturate the link bandwith between the control plane and the forwarding plane and/or generate enough PPS to overwhelm the control plane's CPU (even though it's only going to drop the packets), then it doesn't really matter what the packets contain. So I think there's more to this story than a simple volumetric DoS attack against the control plane that's not being stopped by the hardware forwarding plane. Tore From nobody Mon Aug 22 05:39:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B9912D1AF for ; Mon, 22 Aug 2016 05:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sASYEWbgDA8B for ; Mon, 22 Aug 2016 05:39:53 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3163B12D126 for ; Mon, 22 Aug 2016 05:39:53 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0C63B606F6 for ; Mon, 22 Aug 2016 14:39:51 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 948F76010F; Mon, 22 Aug 2016 14:39:50 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 82BED306C3; Mon, 22 Aug 2016 14:39:50 +0200 (CEST) Date: Mon, 22 Aug 2016 14:39:50 +0200 From: Gert Doering To: otroan@employees.org Message-ID: <20160822123950.GW79185@Space.Net> References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4ih6EAWNdpxH16r3" Content-Disposition: inline In-Reply-To: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops-chairs@ietf.org" , v6ops list , 6man WG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 12:39:56 -0000 --4ih6EAWNdpxH16r3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Aug 22, 2016 at 10:35:47AM +0200, otroan@employees.org wrote: > Perhaps ND packets should have been limited to using link-local addresses= only. Indeed... (that's the conclusion I reached after building an ACL that permits only valid combinations of link-local, unspecified and GUA addresses for each external interface a router is connected to). ARP is not so bad, in retrospective. Can't be routed, can't be ACLed by too-strict IP ACLs, doesn't use multicast, ... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --4ih6EAWNdpxH16r3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXuvKTAAoJEN9WwGXkzn/F0XUQAJzLwS8cZPyncehb3tbyNDmB ri+G07VYxCPa0Ks8X3lokY8n6StgjJLonysEEN9eRYVPESiotir+AtHP5kR9U7wR iJUbpfxPbTwz8kOc1537FNUaeUQSLtv5YXwXHnXQEXl6mz7yKd0N5gJZ7J2zJIDZ 8iQB19/lo76dtE9ARZ505Akz706xDNCo3/ifUfVZ/I2MYIxXmK0Nw1d/4BMd5+BD D0RhZzcue3uo9IaVtSD5519FgWO0XP9Bzqrq+SXbAtSGVnO4W2Sf9FIClkQf97vq vdymu7DvuDl0epHODth2QkL8lLBuabZamSoIp5IhbaiNGIVglXhfrQy4uQGxvDuP iyHTplf8CkHLTIaOzIpqvQxror0uxtLeTcvuIg/6NGfwYJ7wV1vPuEvhD7mYrVlM F2fQj+SMoFUHPoNBvrbvs/2iyJtuqb7pfCEC9lwaCCZB/3pG5uwdnUh7MW4WrF8V Xh3xzZW1YE8f3cvD+4UcTU4VKNyel1tAtPNG4JnhzXqDGA3anJptJF9Yj4VTPGSY K2r/LfpEVkZF6vviDXfFjEC2VlafaYBVMqEjkux2jl6f3sUA+bibJURm80EwDYnj RAZgVlvD9zt4yYPsY7mFZ7u1mz1UQ1JWY7XRGuLZ6oOW60UI6BJ/wd1bGABlvbLU R6Lpy79YluG8qjdzrvsF =lrls -----END PGP SIGNATURE----- --4ih6EAWNdpxH16r3-- From nobody Mon Aug 22 06:36:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442E812D193; Mon, 22 Aug 2016 06:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_bc-0JiOBQW; Mon, 22 Aug 2016 06:36:04 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E98012D13B; Mon, 22 Aug 2016 06:36:04 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 13:36:03 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 188FC9CC4F; Mon, 22 Aug 2016 06:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=YEUXEbSaaHtcCdXhX46Jtbc91ow=; b= rJ2I14KI4dd/QWeQQG2bfJWC+92ddbuYOO2rtfq+zGUxQ85/O1KgcMXREh70rDLn lu8ERIPsOnUBQSLMsLdOsJfn5tdOglpm60Yrx7oSePj13E3X8CI9dAVPFd2VqtnA de1/CvH5qR77ZBpnXCV3RhzOgkc0Hz92Sl2ivD5g/oY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=ADeIFuWXfpPJwVrBNm6MnjzVRE nu+ybKr/Yz1ba55x2MdE29J78CAB7eK2ptVrFU4TqFxbybmlHADVbftw4eWi3S/c A3ADT41a2rPPwc1ogtjqxwM85n8Dvk/J3eG7zx/fphTg9T1F4015SgzvKnTuy2hZ fr8K3KdfQb1w1cHpo= Received: from h.hanazo.no (unknown [173.38.220.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id DAE4B9CC4E; Mon, 22 Aug 2016 06:36:01 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BE146352E44F; Mon, 22 Aug 2016 15:35:59 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B5A99C13-5E12-4691-BDFD-78A966113D62"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: <20160822143302.2da13b80@envy> Date: Mon, 22 Aug 2016 15:35:59 +0200 Message-Id: References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> <20160822143302.2da13b80@envy> To: Tore Anderson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "v6ops-chairs@ietf.org" , v6ops list , 6man WG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 13:36:06 -0000 --Apple-Mail=_B5A99C13-5E12-4691-BDFD-78A966113D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tore, > * otroan@employees.org >=20 >> The issue isn't about the hop limit validation check not being done >> (it is) >=20 > Are you certain that it is? Both Cisco CSCuz66542 and Juniper JSA10749 > describe how the crafted ND packets will be *processed* by the control > plane - not dropped. >=20 > Furthermore, both advisories go on to describe how successful > exploitation might cause the device to stop handling *IPv6* traffic > specifically - as opposed to impacting *all* traffic. >=20 > While the advisories don't go into detail, this suggests to me that > successful exploitation of the issue is dependent on the crafted > packets actually being able to manipulate/overwhelm the IPv6 neighbour > caches. That couldn't happen if the hop limit validation was done and > the packet was dropped - even though this was done in software, by the > control plane itself. you could explain that behaviour differently. the consequence of a massive stream of ND packets are that they will be = heavily throttled between hardware and software forwarding planes. that = will also impact legitimate ND packets, meaning that whatever entries = there are in the ND cache or the replies from address resolution will = not make it back to the ND process. cheers, Ole --Apple-Mail=_B5A99C13-5E12-4691-BDFD-78A966113D62 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXuv+/AAoJED4aXnjSQuKW0cYH/iZRpq045C2Y5UAMFwx36t1Z K4vGG/6D1gbdAVhsajZFyuKEi8zROc/PSPd9wRZfYPxSnZhzJ+1hSP4+65k+ckHf wbleNBvNvrFqrQ4hHHycCyGCIIm9vN90JHIUFqfQYFmPAxe1KAHbPzGRFxwfs/Ly 9OsN6XYlIxgns+wBbV5sXy6ElY+RGnhHdTrrH9u6bLAABHZIeQwY1WjEENIhthgI EZ9y1Ag4oHAC2Aa6m7YSE2ieadMXxiteZHDo+4/QJnuJ3Pqs4Oh1J3eMfS1Rhd+X Kf6Vr3PPaKIJRdJy726/DxCgAyfRpgAkHp9kEpdbbHL916Lbf0aI4oHpLTGlXRA= =I/tW -----END PGP SIGNATURE----- --Apple-Mail=_B5A99C13-5E12-4691-BDFD-78A966113D62-- From nobody Mon Aug 22 08:12:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C24212D792; Mon, 22 Aug 2016 08:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uEue5dK-_nV; Mon, 22 Aug 2016 08:12:00 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822F612D645; Mon, 22 Aug 2016 08:10:50 -0700 (PDT) Received: from [2a02:fe0:c420:314a::8b1] (port=54354 helo=envy) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1bbqsB-0005MU-6U; Mon, 22 Aug 2016 17:10:47 +0200 Date: Mon, 22 Aug 2016 17:10:46 +0200 From: Tore Anderson To: otroan@employees.org Message-ID: <20160822171046.3c62ffe7@envy> In-Reply-To: References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> <20160822143302.2da13b80@envy> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , v6ops list , "v6ops-chairs@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 15:12:03 -0000 * otroan@employees.org > Tore, > > > * otroan@employees.org > > > >> The issue isn't about the hop limit validation check not being done > >> (it is) > > > > Are you certain that it is? Both Cisco CSCuz66542 and Juniper > > JSA10749 describe how the crafted ND packets will be *processed* by > > the control plane - not dropped. > > > > Furthermore, both advisories go on to describe how successful > > exploitation might cause the device to stop handling *IPv6* traffic > > specifically - as opposed to impacting *all* traffic. > > > > While the advisories don't go into detail, this suggests to me that > > successful exploitation of the issue is dependent on the crafted > > packets actually being able to manipulate/overwhelm the IPv6 > > neighbour caches. That couldn't happen if the hop limit validation > > was done and the packet was dropped - even though this was done in > > software, by the control plane itself. > > you could explain that behaviour differently. > the consequence of a massive stream of ND packets are that they will > be heavily throttled between hardware and software forwarding planes. > that will also impact legitimate ND packets, meaning that whatever > entries there are in the ND cache or the replies from address > resolution will not make it back to the ND process. Sure, but that'd just be a variation on the simple volumetric DoS, nothing that would be unique to ND. That is: if you rate-limit FOO packets, and someone floods you with FOO packets, then legitimate FOO packets will be dropped and thus the operation of the FOO protocol will be impacted. (Replace FOO with ND, BGP, ARP, OSPF, etc.) This is common knowledge and does not justify security advisories being published for each possible value of FOO. Yet now we have one for ND. So I'm not really convinced that there isn't more to this, i.e., that the crafted ND packets in question are successfully tricking the control plane into doing actual work/processing (beyond dropping them). You didn't answer my question, by the way. Tore From nobody Mon Aug 22 10:39:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9CA12D7CA; Mon, 22 Aug 2016 10:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9km46KsgEvP; Mon, 22 Aug 2016 10:39:52 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD0F12D169; Mon, 22 Aug 2016 10:39:51 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 17:39:50 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 4B9939CC51; Mon, 22 Aug 2016 10:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=PcJYsXMG2xw7s62dIrPwPeFrGyc=; b= K3OE7q7xWSKUuXOxwCls/rOFq0wD+QW5t/WdVRNxKPhuOaH002V4pcNfatco0UHW xTSXibvmMEVgh0uWHbXSjFSOR6cmTpqkJFJoSwlpl8Ha8cNhCdwvVcPNls9Gu2mB dRbv6eVN5pDcaxmvM52IaVAQKMQXYjU0bq2W4IU0mZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=JBMaPtn/sIr+TrDFkhulWGamV9 b6rkY57rWk+CuS7F9oDHoFcCYKPWOnu203I9FQyAfFE1fH2I6QjtCe8Ru3jcKYQe aevXAyRGlxOh4+xB68xFf+/QhedGBvjA789mEhrJ45Dje8I6Q8+TGkcjjt3ZVBux 3DWobcVRIpwkbY5UU= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B98319CC4F; Mon, 22 Aug 2016 10:39:48 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C2E3A35322D7; Mon, 22 Aug 2016 19:39:42 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E105B5B0-9C9D-4877-9EFF-78A9632F1E71"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: <20160822171046.3c62ffe7@envy> Date: Mon, 22 Aug 2016 19:39:42 +0200 Message-Id: <5D8D4A35-1D8A-4D6D-A5CA-D0D2BF78CA8E@employees.org> References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> <20160822143302.2da13b80@envy> <20160822171046.3c62ffe7@envy> To: Tore Anderson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG , v6ops list , "v6ops-chairs@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 17:39:54 -0000 --Apple-Mail=_E105B5B0-9C9D-4877-9EFF-78A9632F1E71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tore, >>> * otroan@employees.org >>>=20 >>>> The issue isn't about the hop limit validation check not being done >>>> (it is) >>>=20 >>> Are you certain that it is? Both Cisco CSCuz66542 and Juniper >>> JSA10749 describe how the crafted ND packets will be *processed* by >>> the control plane - not dropped. >>>=20 >>> Furthermore, both advisories go on to describe how successful >>> exploitation might cause the device to stop handling *IPv6* traffic >>> specifically - as opposed to impacting *all* traffic. >>>=20 >>> While the advisories don't go into detail, this suggests to me that >>> successful exploitation of the issue is dependent on the crafted >>> packets actually being able to manipulate/overwhelm the IPv6 >>> neighbour caches. That couldn't happen if the hop limit validation >>> was done and the packet was dropped - even though this was done in >>> software, by the control plane itself. >>=20 >> you could explain that behaviour differently. >> the consequence of a massive stream of ND packets are that they will >> be heavily throttled between hardware and software forwarding planes. >> that will also impact legitimate ND packets, meaning that whatever >> entries there are in the ND cache or the replies from address >> resolution will not make it back to the ND process. >=20 > Sure, but that'd just be a variation on the simple volumetric DoS, > nothing that would be unique to ND. I believe that's largely correct. > That is: if you rate-limit FOO packets, and someone floods you with = FOO > packets, then legitimate FOO packets will be dropped and thus the > operation of the FOO protocol will be impacted. (Replace FOO with ND, > BGP, ARP, OSPF, etc.) >=20 > This is common knowledge and does not justify security advisories = being > published for each possible value of FOO. Yet now we have one for ND. > So I'm not really convinced that there isn't more to this, i.e., that > the crafted ND packets in question are successfully tricking the > control plane into doing actual work/processing (beyond dropping = them). Correct. I suppose with ND there is a relatively simple workaround that = can be hardcoded. One which may not apply to any generic protocol. > You didn't answer my question, by the way. if I'm certain? yes, I'm quite certain. with the reservation that I'm = not particularly familiar with XR code. Cheers, Ole --Apple-Mail=_E105B5B0-9C9D-4877-9EFF-78A9632F1E71 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXuzjeAAoJED4aXnjSQuKWcz8H/R51xf89AgCTrsPodS6sFATj mcUl+76xTyKmav+W4MLkp2WuRAXJ9kiUVMHxFJ9UE+bnDsmUYXjPm58Q4e2ME3cO 6n5DMolTrgjj8f0w+LiekgJE/14qNRgOcyN21LOGUNO4STiyTR4Lk70lb2hzpxAT 2MOY89Okg09EB1C/FUBaRqdYB+CMKh5trX08EX3AnmCPhPXBUDmrvA0BtzSykQpC 6dKX4NKujxrrWzz9PjaCGLVs5jUZoP5B6p/IMdB1/2c1mcjZL4+gyULD7op/8GDJ WLEQtgf/ccYb6Uaf9wnXVVyCtv4JPerLh8lSXNoe8K9Pi9ObU6WJMVFnQJ5eamo= =dzpE -----END PGP SIGNATURE----- --Apple-Mail=_E105B5B0-9C9D-4877-9EFF-78A9632F1E71-- From nobody Mon Aug 22 12:03:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B8912D0CD for ; Mon, 22 Aug 2016 12:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.069 X-Spam-Level: X-Spam-Status: No, score=-115.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbM6NpnL17Xd for ; Mon, 22 Aug 2016 12:03:19 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D1812D0A7 for ; Mon, 22 Aug 2016 12:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1934; q=dns/txt; s=iport; t=1471892599; x=1473102199; h=from:to:subject:date:message-id:mime-version; bh=ZoEgSuOpJRvtT5xlaBD4IVcSDcSPQia6+Ovl6lNZp9k=; b=LFH4sYhYbx0bEc7tkvT6Huxh0NX6Zegr3LihVlpsqrE0QK9FYhGbltLh FFEZ0kcIMUS0/mpJKc9yGtbHT3WPX7jLehrwj2RJ9oJMDj7uKUkx+xg67 b7v2Y6M3/FVFMb34KqIdineDuMLjmGC2xDvVM/noYLcbtwDUTLvSd4izv o=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABBgDCS7tX/5pdJa1dg0SBWaNilB2Bf?= =?us-ascii?q?YgDOhICAQEBAQEBAV4cC4RlgQsBgQAPGAQhiCOeAZ9pAQEBAQYBAQEBAQEBEg6?= =?us-ascii?q?IIwiKOYIvBZlIAYE4ggWBc4lugVeNeZA2ASUHKIN6hmx/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,561,1464652800"; d="asc'?scan'208";a="313168501" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 19:03:18 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7MJ3ITs031103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Aug 2016 19:03:18 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 14:03:18 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 14:03:17 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: Best wishes Thread-Index: AQHR/KfXzatPgWDlbkev9sVlqwPXow== Date: Mon, 22 Aug 2016 19:03:17 +0000 Message-ID: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_099C8ADC-CC7E-4555-B87D-77B7BA7F0B5F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:03:20 -0000 --Apple-Mail=_099C8ADC-CC7E-4555-B87D-77B7BA7F0B5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is perhaps abrupt... I am leaving Cisco and my next steps are at this point indeterminate. As = a result, I am backing away from IETF activity for the near, and perhaps = foreseeable, future. Let me take this opportunity to say to each of you = that this has been an interesting and productive activity for the past = decade, and I wish the IETF and its participants the best. You may see = automated emails from this address for a little while ("state of play", = new draft postings) until my termination date, but starting Thursday = (when I go on a pre-planned vacation), I won't be here. --Apple-Mail=_099C8ADC-CC7E-4555-B87D-77B7BA7F0B5F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV7tMdUayAOS/EQ8MAQL+IxAAmyCtdeiPOGbabU+UQJrCgSvipixjviY5 6GYYp5WKfTsDw9xtFZW83PQasp6TdDC9qneB4hmCkDtjjXqA2Ec+S12K5NAMC5aE 3zrfKYaWiMTSx4yfJL+jdwXVtLnaXyIs1AUs+WqO88sHVQaLlb22LNMXu4QT0Ynu RyB7KNVkYVsC2KWt4x1zs9GrrUhKA7iXcge593jVw60NKWm8P9lTdra5Nl1N6x+s SIOKPo2jDtzmEusd2BF6JsZr/XUOB8VET5Uy4TijD/7Ur4WvNRhTWk2J4r1dB0g2 iN0r5bZcHQDeFmi4b8mzX4ZlahvQtbIO7cyVQOfgN3bY5tYkyYS2oV6qGX4a4A+E c8DZF89MVzaaUNuV9QLeboQ312XZ13wN2ttgH0bhsIEhW89tJizKNQboN5o4c7W8 KpxdUXiOssKHcGO0VUigV3HeBcs9pmH6akdDGb1bUhRKfFtIpdbEfdbLoigKd9ZG fG5KIqgZxZOyYd8huXAqdI7FqGdIwlBIaLbCAxpHxs4hb2hVcdpqox9bEvX04K8D HwtPeISiS3Cai0DehWrHIKmh/iMWPDjjsE3VU4BPSu8E6BIrNH5oYz/DGVPGxIrx H7UUSFk5o3/z4nBU7nQM3yOnNYqq91xo/6CkYafHsfIDciuNpylYFg/3iWWyJLtU sGhqgdxqZlA= =uLcF -----END PGP SIGNATURE----- --Apple-Mail=_099C8ADC-CC7E-4555-B87D-77B7BA7F0B5F-- From nobody Mon Aug 22 12:07:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F78B12D13E for ; Mon, 22 Aug 2016 12:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utwr34nsg8BF for ; Mon, 22 Aug 2016 12:07:30 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A1E12D807 for ; Mon, 22 Aug 2016 12:07:30 -0700 (PDT) Received: from mbp.local ([IPv6:2601:647:4201:9e61:ec3e:e3ed:c827:28d4]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u7MJ7QAN011057 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 22 Aug 2016 19:07:26 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:ec3e:e3ed:c827:28d4] claimed to be mbp.local To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: joel jaeggli Message-ID: Date: Mon, 22 Aug 2016 12:07:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iAmBN7MDf2mSmomKQvRXJtHgfT6K3B9CP" Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:07:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iAmBN7MDf2mSmomKQvRXJtHgfT6K3B9CP Content-Type: multipart/mixed; boundary="VRLNU3oRMWw6Au8E8DGwTgjhWsHR5iqk8" From: joel jaeggli To: "Fred Baker (fred)" , "v6ops@ietf.org" Message-ID: Subject: Re: [v6ops] Best wishes References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> --VRLNU3oRMWw6Au8E8DGwTgjhWsHR5iqk8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fred, I would like to thank you very much for the time and effort that you've put into v6ops and so many other IETF activities. You were a significant mentor to myself and many other IETF participants. Thanks Joel On 8/22/16 12:03 PM, Fred Baker (fred) wrote: > This is perhaps abrupt... > > I am leaving Cisco and my next steps are at this point indeterminate. A= s a result, I am backing away from IETF activity for the near, and perhap= s foreseeable, future. Let me take this opportunity to say to each of you= that this has been an interesting and productive activity for the past d= ecade, and I wish the IETF and its participants the best. You may see aut= omated emails from this address for a little while ("state of play", new = draft postings) until my termination date, but starting Thursday (when I = go on a pre-planned vacation), I won't be here. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --VRLNU3oRMWw6Au8E8DGwTgjhWsHR5iqk8-- --iAmBN7MDf2mSmomKQvRXJtHgfT6K3B9CP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAle7TW4ACgkQ8AA1q7Z/VrKKtgCeP9i0tFNc7f3mBTntqneFNnT2 i98An1KocZpkdGDsLdJIXIHNAaMwH3cz =lJwK -----END PGP SIGNATURE----- --iAmBN7MDf2mSmomKQvRXJtHgfT6K3B9CP-- From nobody Mon Aug 22 12:10:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B388312D813 for ; Mon, 22 Aug 2016 12:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQDnLeD2JY64 for ; Mon, 22 Aug 2016 12:10:10 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7864112D820 for ; Mon, 22 Aug 2016 12:10:10 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 7424C1C1910 for ; Mon, 22 Aug 2016 14:10:09 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 141091C1181; Mon, 22 Aug 2016 14:10:09 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 01825128002; Mon, 22 Aug 2016 15:10:08 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by imsva1.bcbsm.com (Postfix) with ESMTP id E66F1128001; Mon, 22 Aug 2016 15:10:07 -0400 (EDT) Received: from PWN401EA120.ent.corp.bcbsm.com ([169.254.12.32]) by PWN401EA100.ent.corp.bcbsm.com ([10.64.80.217]) with mapi id 14.03.0301.000; Mon, 22 Aug 2016 15:10:08 -0400 From: "Ackermann, Michael" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: Best wishes Thread-Index: AQHR/KfXzatPgWDlbkev9sVlqwPXo6BVV7Mg Date: Mon, 22 Aug 2016 19:10:07 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0DB7B175@PWN401EA120.ent.corp.bcbsm.com> References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: d44cb7a2-0607-45af-bf47-3a154dba0dd1 X-VPM-MSG-ID: 14fa64d3-dfb2-4a44-884c-fac2dc0f0d8d X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:10:11 -0000 Fred My mind will currently not allow me to accept this as fact, but assuming = this is real............. I cannot imagine anyone that would be missed, more than you. Thanks for = ALL you have done & accomplished, in SO many ways. =20 You are someone I will always look up to and appreciate greatly=21 Thanks for being you=21 Mike -----Original Message----- From: v6ops =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Fred Baker = (fred) Sent: Monday, August 22, 2016 3:03 PM To: v6ops=40ietf.org Subject: =5Bv6ops=5D Best wishes This is perhaps abrupt... I am leaving Cisco and my next steps are at this point indeterminate. As a = result, I am backing away from IETF activity for the near, and perhaps = foreseeable, future. Let me take this opportunity to say to each of you = that this has been an interesting and productive activity for the past = decade, and I wish the IETF and its participants the best. You may see = automated emails from this address for a little while (=22state of = play=22, new draft postings) until my termination date, but starting = Thursday (when I go on a pre-planned vacation), I won't be here. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Mon Aug 22 12:20:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265B812D756 for ; Mon, 22 Aug 2016 12:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ergwhovE2UwE for ; Mon, 22 Aug 2016 12:20:50 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07F912D7E3 for ; Mon, 22 Aug 2016 12:20:49 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id f93so85251818lfi.2 for ; Mon, 22 Aug 2016 12:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=D07t+6uS/1nxn1l7fOrRmbF8seOhYPpw3f9r0RnBj4M=; b=uwKrSwD0AD+wLTVaG6CgdYQ7PQoCDSK6Fqa4snPVNUWN0r0+VQYCvFL/rdpbG+fMIh MaoAGMaYRcHLt4Qk1Xmmk6wlt85hiatINkvOltYzfmr82S3uTjiIczZb1rRFVMpDtBfJ MDoxNM+a4GvLn+piVEFY9yJMucFDDd4PNZg/diIYh6UaVHL3TiD5KcjqDQLT68xDfKWL rwnn+3Fz4+zai5gMAqTDKDoKT5I/nuKX32KX8QCAO+k213k+R1QNB9KKXS6IELjuT71Y 5DyE3hOschdCrFqOV78k/eta1IGVHjNRr9DBY2WT1o27k3pH+UFC+RLhEJY9sWP+cO3p xlPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=D07t+6uS/1nxn1l7fOrRmbF8seOhYPpw3f9r0RnBj4M=; b=QHo6cUL0dKCPc1OCLRLTznsxj/gN7A0LFS+ZCJBU12rlS3wjWYlHdFq0r4h7OzzFLT MhY2X3hlTIkdL/Smxy9jQl7xw09hjIOjcH/QdWq4ugZhe+j6QkHy6jcdMYOyy0U/q52i 7nb4MtaI/AK7cuFJGTIEG98PE6b+fbN9G1m9cLhu3QccOfYhAWQR71k5AC0iD14AOKgo 8z4iFmw8O7v3q5UMPJ2Xz2LssU9M2dD8zzeZkpEd4aBxdNmblBYUNTA+FVrSSASeqkkA PQ2MinT7gxuSlYO6nTcq5mjG+Dgyop6Q6LyT5nRJu0sD1UKgSuBqbZgI669bNgTiUIlX cLeA== X-Gm-Message-State: AEkoouv2TwrLTbPbMpU7MTzLTfrnhmiY0M7WIah4coc7GjLWcyCiS/HjI4c1LR/2Ey8ROA== X-Received: by 10.25.85.198 with SMTP id j189mr6629472lfb.31.1471893647611; Mon, 22 Aug 2016 12:20:47 -0700 (PDT) Received: from voyager2.local (093105179034.dynamic-ww-02.vectranet.pl. [93.105.179.34]) by smtp.googlemail.com with ESMTPSA id j198sm3977190lfg.18.2016.08.22.12.20.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Aug 2016 12:20:46 -0700 (PDT) To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: Tomek Mrugalski Message-ID: Date: Mon, 22 Aug 2016 21:22:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:20:52 -0000 On 22/08/16 21:03, Fred Baker (fred) wrote: > I am leaving Cisco and my next steps are at this point indeterminate. > As a result, I am backing away from IETF activity for the near, and > perhaps foreseeable, future. This is a sad news. Thank you a lot for all the good things you have done from the Internet over the years. Best of luck to you. Tomek From nobody Mon Aug 22 14:06:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8A12B026 for ; Mon, 22 Aug 2016 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOcuktRj5yb2 for ; Mon, 22 Aug 2016 14:06:21 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502C9127071 for ; Mon, 22 Aug 2016 14:06:21 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id l2so92121468qkf.3 for ; Mon, 22 Aug 2016 14:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xuTvO3Hp452PupC002p7RwP+d/Iv5U7U2+25xNXu7Ck=; b=bUT5w4AS/7LgTqFEOpSSRtqrWP2ilo/GSDMpMa+R71QvIxJbqHQYTzgZq6EOPAhw5p pJoP1j15Vn8ibMhoaY0oOohfDOjbaPnZRH7lQF6KZ245+jE49HddlEq8VHVivmG6w+iM 9Ho1DtbA/SVOuCUtUbPVasLyiajrQUbFK058Jbg9jR5HAk7XZeXDXUmYewLsVpdDNcfy iftEaqqAryER0HG4urk4wUTn3OQ/GsMf4NtjvLsKlwS/jNrN17xu13JAnjtnn+vkzifb LhjTO53JDeAADF9OclMxwidf4yewq3KIDZSPuVpW8g5f0456Ljt0Ui5nE9dWPQC/OvGq BqhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xuTvO3Hp452PupC002p7RwP+d/Iv5U7U2+25xNXu7Ck=; b=P170xbkZL3iJ1VyQGSjGdcS2Z2i8c5ld/XpCiwQZLA9lxCutCPf59lK14GBdR/goQo RU2dBx5IfVO4EKtdtxuptKd/lijdq0Cwx8jFHSvTGUGK3/1i9DD8aapqFV1tlA6kXuN7 +ZAk1zPsUx6LOdSdcokn4XCOspZspoO+4mAMHaOZQbjVeHKNlArGEtvAHNAhsBIQ3frJ sj5cspjT50fXcG7VQlbYQfXzjYN3UnpHKNpqZxj7ZD5kuiAwVDrKQB+4EokzDk65C0BO Bu6c2YrgNCb9X4GfAiHEN8Z/AycN+sA7mS8dwkN47OAciuASOFPOm9nQESKZ06F3gEu9 JJqg== X-Gm-Message-State: AEkoousNrxu6K7xmSuWdn1JcLdR7OiJyv41ihydARe81bL7RHj2xLSor/fuNe7KSbf8dQHhDDGUborkpfwxWJJqt X-Received: by 10.55.159.135 with SMTP id i129mr25882983qke.190.1471899980410; Mon, 22 Aug 2016 14:06:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.176.199 with HTTP; Mon, 22 Aug 2016 14:05:49 -0700 (PDT) In-Reply-To: References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: Warren Kumari Date: Mon, 22 Aug 2016 17:05:49 -0400 Message-ID: To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:06:23 -0000 On Mon, Aug 22, 2016 at 3:07 PM, joel jaeggli wrote: > Fred, > > I would like to thank you very much for the time and effort that you've > put into v6ops and so many other IETF activities. You were a significant > mentor to myself and many other IETF participants. Yup. Fred is a great mentor -- I know of a number of people who's first introduction to the IETF has been through him - in fact, I have someone who is just starting to participate now. She has an idea which Fred helped convert into a draft, and then encouraged her to submit, guided here through the process, etc. Fred is (obviously) active, but he also does a *huge* amount of behind the scenes work... Fred's impact on both the technical functioning, and more importantly culture and ethics of the IETF is huge - there have been many time when I've asked myself "What would Fred do here?", and then used that to guide my actions. W > Thanks > Joel > > > On 8/22/16 12:03 PM, Fred Baker (fred) wrote: >> This is perhaps abrupt... >> >> I am leaving Cisco and my next steps are at this point indeterminate. As= a result, I am backing away from IETF activity for the near, and perhaps f= oreseeable, future. Let me take this opportunity to say to each of you that= this has been an interesting and productive activity for the past decade, = and I wish the IETF and its participants the best. You may see automated em= ails from this address for a little while ("state of play", new draft posti= ngs) until my termination date, but starting Thursday (when I go on a pre-p= lanned vacation), I won't be here. >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Aug 22 14:18:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CA712D1A1 for ; Mon, 22 Aug 2016 14:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX1PPEwM-QF1 for ; Mon, 22 Aug 2016 14:18:33 -0700 (PDT) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFF512B05E for ; Mon, 22 Aug 2016 14:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1471900713; bh=Mtokq3OJcs5IaIbUOREnoDAdFUstT5+GLd50qerrR7w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=M12UJBdjP5xjpiNPNdqVYdivMUl6bH6Ctd41BYJqibsZ+LhgLFC6QZLLRWMgmt+CQ7ErBv/TL2SlfVlXoKH9Kus41kd2gi9HkFD9Rbs1PSleThnvSGe1+KoHTIz2HbPEl+sXxXv4sSIIvhv3jZVwiz0zmel7GCpJgOO5xpHcRU+KzUC+iCyVZuQgctKzsxlueTlk3r7pqbwOkcFfZa+IS+Q2+LOnfRmz0/bUBk9VDKHf8aYL0DsxlRSDtwwjJHY7tSa8fJ3xUAdg83acNHqEqjuNudwxMHpG61MBQRDaB+pvWVJpILuPBuruV/JGuR+OYbnG1HTylR9EbWAhb41oSA== Received: from [98.138.101.131] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 22 Aug 2016 21:18:33 -0000 Received: from [98.138.87.5] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 22 Aug 2016 21:18:33 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 22 Aug 2016 21:18:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 90299.28473.bm@omp1005.mail.ne1.yahoo.com X-YMail-OSG: WaqSJHMVM1lPCtB8CRcHQplDt4rSAXTIuZpuHTUPHxbCFiXVjMwfX.vNQ3wmv1M pabJypPZHaXfJmletnbpmRcZ4L5Q6sjE5AtaB.kF9SlcCwARKUNPFbHTVFhH.kKqrsC7nn5ZrHqv CNsVMXY1E4lJUpooKMwfOPpINPzRvbPiVkGDi84wGj_gRU.3BKAqRjrNly0jr.tfaIMc26TM2Rus PfVNNuJlebwZef6_.FxMaTTCeSSU3rhjKQb7EA06lE991KYhJWEUiU1Ax2R451UYy5WAn0ByWdM9 YHWK1FzctGncUAwSBfKZ09lHhUCju92jNZ7a.1Mdk39kH17UUcWdQZ1D15076IYipXF.EaeCJX5m MU1PbiXQBLS5TZljM5Gul6gFhbzdVmj1AVpBprfGKS90p4PYz2bJEatTBBL2WncwdZe8BoWUp72F Sc.jDrEKrQBttQs6w4L_TouMYHe3fA33pe5MU.2hmVhMA8L4tjb6MEDu3P8wv.H4uFVYl9l6UHR2 O3oiCRuAsiBKMgq1DBgMOkgcpUG4- Received: from jws10085.mail.ne1.yahoo.com by sendmailws109.mail.ne1.yahoo.com; Mon, 22 Aug 2016 21:18:32 +0000; 1471900712.538 Date: Mon, 22 Aug 2016 21:18:32 +0000 (UTC) From: To: Warren Kumari , joel jaeggli Message-ID: <208881112.473232.1471900712104@mail.yahoo.com> In-Reply-To: References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:18:36 -0000 On Mon, Aug 22, 2016 at 3:07 PM, joel jaeggli wrote: >> Fred, >> >> I would like to thank you very much for the time and effort that you've >> put into v6ops and so many other IETF activities. You were a significant >> mentor to myself and many other IETF participants. >Yup. Fred is a great mentor -- I know of a number of people who's >first introduction to the IETF has been through him - in fact, I have >someone who is just starting to participate now. She has an idea which >Fred helped convert into a draft, and then encouraged her to submit, >guided here through the process, etc. Fred is (obviously) active, but >he also does a *huge* amount of behind the scenes work... >Fred's impact on both the technical functioning, and more importantly >culture and ethics of the IETF is huge - there have been many time >when I've asked myself "What would Fred do here?", and then used that >to guide my actions. Fred, let me echo what Joel and Warren have said. I have seen you spend so much time with new people, taking them to dinner, sitting with them after their drafts were presented in a WG and talking about what happened, and so much more. You have always made yourself available both personally and by email. I know I have cried on your shoulder quite a few times over the years. Thank you, Fred, for what you have done for the IETF and the Internet. I have high hopes that you will be back and soon. Nalini > Thanks > Joel > > > On 8/22/16 12:03 PM, Fred Baker (fred) wrote: >> This is perhaps abrupt... >> >> I am leaving Cisco and my next steps are at this point indeterminate. As a result, I am backing away from IETF activity for the near, and perhaps foreseeable, future. Let me take this opportunity to say to each of you that this has been an interesting and productive activity for the past decade, and I wish the IETF and its participants the best. You may see automated emails from this address for a little while ("state of play", new draft postings) until my termination date, but starting Thursday (when I go on a pre-planned vacation), I won't be here. >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Aug 22 14:39:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3040F12D80F for ; Mon, 22 Aug 2016 14:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUd4Ht-UgorF for ; Mon, 22 Aug 2016 14:39:06 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6056612D594 for ; Mon, 22 Aug 2016 14:39:06 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id k90so213312558uak.1 for ; Mon, 22 Aug 2016 14:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=/yNr/yYTGdL/2XDU0VC7Ux7alTUOxpgHNC6sstdC7zk=; b=WnwyXc+GAHdMaKKZQDM/44245dkHEibcWLeTjhZSdOmF2Apeo4q7QDacsHFFoSj4/p HmAx+u+XiueBb08gOogav1WDck4nasAEUbsvpPtUEN96Ewfl5qBADaHhwpjWP8oV03SN 5At+LxCqiG8axm/WZoY+p1pKopSmtIUqgK8f4/pYxAW2UhqUevtzJtC4lUQhkp0uDgyl ptLnyEpt2KA24ryQ+P3YsPfM8jfJol7uXfe6YF7dwcY3+nUor78yIxcHVYoSfBnTGcDI jIK6Vyp8xjIRGO2Ks+4/czLIp0V5B7JykB2W82BrjLthlp22YiS1E+0gbUh6APjFEpvN RexQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=/yNr/yYTGdL/2XDU0VC7Ux7alTUOxpgHNC6sstdC7zk=; b=WGmXIDzWKKdjTiogAhamzgyP2zxWxvvLliGtpm9GbzH1F/KrIJRhXHnMDdqobfkyGp 3hTI7hR5/UZb9x1JHnPcTZB5YzkE2DDbcHzbQc8jox5K8pM5gyWBlpFqDF3XdwP2YzeE HFKTu+yS4rcgjKwzLJJjm/AJRtgPADdMppQ1Z1CzFo1d0Ls7p7qvkWim1hiGpP6TTvoN wnAEVnURBhQGcwkluSqqLPN7sbmZrPyatxKli1HmEwRvqa/nAihhfxYeLOHTdRLrUCKJ QrV1xl4Xebj6cIyuRFVf3zfHy6LgwHzoi2AkixB4e997S8MiAfBcMOP2GnSO6nXSPraY 6mlg== X-Gm-Message-State: AEkooutHw8TBgUwpa8o+pprdup4waqMFrFOk1O+ryxDnNMs0WGprDd/s2vIN9v9uNV2k7w== X-Received: by 10.176.82.171 with SMTP id v40mr10258576uav.14.1471901945391; Mon, 22 Aug 2016 14:39:05 -0700 (PDT) Received: from [192.168.1.104] ([200.113.205.242]) by smtp.googlemail.com with ESMTPSA id l2sm18195ual.19.2016.08.22.14.39.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Aug 2016 14:39:04 -0700 (PDT) To: v6ops@ietf.org References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: Alejandro Acosta Message-ID: Date: Mon, 22 Aug 2016 17:39:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Content-Type: multipart/alternative; boundary="------------2AF0D6A711EE2EA0EA5A073E" Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:39:08 -0000 This is a multi-part message in MIME format. --------------2AF0D6A711EE2EA0EA5A073E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Fred, Wow, this is some sort of hard to believe news. As a former fellow I can tell you we won't never forget the story you told to all of us during IETF 82. Thanks a lot for that. My best wishes for you. Regards, Alejandro Acosta, El 8/22/2016 a las 3:03 PM, Fred Baker (fred) escribió: > This is perhaps abrupt... > > I am leaving Cisco and my next steps are at this point indeterminate. As a result, I am backing away from IETF activity for the near, and perhaps foreseeable, future. Let me take this opportunity to say to each of you that this has been an interesting and productive activity for the past decade, and I wish the IETF and its participants the best. You may see automated emails from this address for a little while ("state of play", new draft postings) until my termination date, but starting Thursday (when I go on a pre-planned vacation), I won't be here. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------2AF0D6A711EE2EA0EA5A073E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Fred,
  Wow, this is some sort of hard to believe news.
  As a former fellow I can tell you we won't never forget the story you told to all of us during IETF 82. Thanks a lot for that.

  My best wishes for you.

Regards,
Alejandro Acosta,


El 8/22/2016 a las 3:03 PM, Fred Baker (fred) escribió:
This is perhaps abrupt...

I am leaving Cisco and my next steps are at this point indeterminate. As a result, I am backing away from IETF activity for the near, and perhaps foreseeable, future. Let me take this opportunity to say to each of you that this has been an interesting and productive activity for the past decade, and I wish the IETF and its participants the best. You may see automated emails from this address for a little while ("state of play", new draft postings) until my termination date, but starting Thursday (when I go on a pre-planned vacation), I won't be here.



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--------------2AF0D6A711EE2EA0EA5A073E-- From nobody Mon Aug 22 14:45:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB8F12D0CF for ; Mon, 22 Aug 2016 14:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL1lOLkZ8p5x for ; Mon, 22 Aug 2016 14:45:08 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF8112B039 for ; Mon, 22 Aug 2016 14:45:08 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id l203so171152334oib.1 for ; Mon, 22 Aug 2016 14:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DGliZMdeTeIhkWzduTxcaxw6lyCQQr5tcqnqPbkuQtE=; b=CZ/XNRK5pICIREhtGGXpWbRhMdHKuEoNbWXXkaFkUp6LfKVZ90g4JGvtIS657+501n kvMxX/NAIUDXGyq4HW7/w9vMicJyuVglmA3RD3GPw4Gsv06DKR0hKFUihKWKOlWZ1sY/ fWCWsrhEP35K5Td80wpguvAcnk/U30ROFv4hOVU1KhM1Im0pxI6PgfL4IzdjDHtfzcLl mzO2DOB3wNUFehM8zGCE29KDnKdEquV+RL46Y00xkIusjmkiR8b4ZojWrN0f1TN9XxRg Fhp/buxYwq1+TYpBAQR3cCXHV8jOi8n2Cc/VguACRuY8uw4y68TDhioH7k7+CghA1VDZ jTmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DGliZMdeTeIhkWzduTxcaxw6lyCQQr5tcqnqPbkuQtE=; b=lAiBAfgvrvp4ijdG+gy95ZhPksLxRLDYxmui+Xd1JFxgDkcivQQvGVBC4yop2nRww1 MgO/g6PUdMyyvxPLUV3uR0z21TXH4V2M7QV3XafVbz2928J3EeY8vOFxaxipHSqIhyE2 jnh56sj12KK04r0+TPSTbloMX4v3EU4RVif8vQpBVBpx/2NjnI3cVXRo4cKzJFg+lt1C M5Km7IgODdJ7UQ+QxyNH30jMtPCSTwYQA4dLU8aqdp4pPqwkqylQEIUY9FAvXuOnD7sa cMbZTCS3BZmYxxQW49wP372/kpPN3jdFr/O6ECy1xwA5IOFuRPqg+9T3Pk03yOYLLNXO 8x+A== X-Gm-Message-State: AEkoouuFgzjKCDGbpmuVvvR/5c7mcJ++/j8GS26+31/rojSm7Hz51jye42sfuWfLGq9DewzSWusXfLT8TVv4KA== X-Received: by 10.157.20.182 with SMTP id d51mr13640016ote.61.1471902307940; Mon, 22 Aug 2016 14:45:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Mon, 22 Aug 2016 14:45:07 -0700 (PDT) In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: Hemant Singh Date: Mon, 22 Aug 2016 17:45:07 -0400 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a11463c56357f0c053aaff6d4 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:45:11 -0000 --001a11463c56357f0c053aaff6d4 Content-Type: text/plain; charset=UTF-8 Fred, Wow, very sorry to hear the news. Best wishes to our fearless leader for v6ops and other IETF work. Hemant On Mon, Aug 22, 2016 at 3:03 PM, Fred Baker (fred) wrote: > This is perhaps abrupt... > > I am leaving Cisco and my next steps are at this point indeterminate. As a > result, I am backing away from IETF activity for the near, and perhaps > foreseeable, future. Let me take this opportunity to say to each of you > that this has been an interesting and productive activity for the past > decade, and I wish the IETF and its participants the best. You may see > automated emails from this address for a little while ("state of play", new > draft postings) until my termination date, but starting Thursday (when I go > on a pre-planned vacation), I won't be here. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11463c56357f0c053aaff6d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fred,

Wow, very sorry to hear the= news.=C2=A0

Best wishes to our fearless leader for v6op= s and other IETF work. =C2=A0

Hemant

On Mon, Aug 22, 201= 6 at 3:03 PM, Fred Baker (fred) <fred@cisco.com> wrote:
This is perhaps abrupt...

I am leaving Cisco and my next steps are at this point indeterminate. As a = result, I am backing away from IETF activity for the near, and perhaps fore= seeable, future. Let me take this opportunity to say to each of you that th= is has been an interesting and productive activity for the past decade, and= I wish the IETF and its participants the best. You may see automated email= s from this address for a little while ("state of play", new draf= t postings) until my termination date, but starting Thursday (when I go on = a pre-planned vacation), I won't be here.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--001a11463c56357f0c053aaff6d4-- From nobody Mon Aug 22 15:04:40 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9E912D1A9 for ; Mon, 22 Aug 2016 15:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVcZ0SBx0aA3 for ; Mon, 22 Aug 2016 15:04:37 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AFB12D144 for ; Mon, 22 Aug 2016 15:04:37 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u7MM3ZCT025860; Mon, 22 Aug 2016 18:04:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2507tjeshh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Aug 2016 18:04:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u7MM4XNl007674; Mon, 22 Aug 2016 18:04:34 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u7MM4Q0l007583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Aug 2016 18:04:27 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 22 Aug 2016 22:04:16 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.193]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0301.000; Mon, 22 Aug 2016 18:04:15 -0400 From: "STARK, BARBARA H" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: Best wishes Thread-Index: AQHR/KfXzatPgWDlbkev9sVlqwPXo6BViDhQ Date: Mon, 22 Aug 2016 22:04:15 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61142712453@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-22_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608220220 Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 22:04:38 -0000 Fred,=20 You're an amazing person. I'm so honored to have known you and had the chan= ce to work with you. Barbara > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred= ) > Sent: Monday, August 22, 2016 3:03 PM > To: v6ops@ietf.org > Subject: [v6ops] Best wishes >=20 > This is perhaps abrupt... >=20 > I am leaving Cisco and my next steps are at this point indeterminate. As = a > result, I am backing away from IETF activity for the near, and perhaps > foreseeable, future. Let me take this opportunity to say to each of you t= hat > this has been an interesting and productive activity for the past decade,= and I > wish the IETF and its participants the best. You may see automated emails > from this address for a little while ("state of play", new draft postings= ) until > my termination date, but starting Thursday (when I go on a pre-planned > vacation), I won't be here. From nobody Mon Aug 22 17:33:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7679312D1E4 for ; Mon, 22 Aug 2016 17:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACQ6wl6VRxXZ for ; Mon, 22 Aug 2016 17:33:24 -0700 (PDT) Received: from mgwkm01.jp.fujitsu.com (mgwkm01.jp.fujitsu.com [202.219.69.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D7712D1A9 for ; Mon, 22 Aug 2016 17:33:23 -0700 (PDT) Received: from kw-mxoi2.gw.nic.fujitsu.com (unknown [192.168.231.133]) by mgwkm01.jp.fujitsu.com with smtp id 7766_1101_ecb1e47e_2a9f_43a0_b175_f9fec67b3cfc; Tue, 23 Aug 2016 09:33:18 +0900 Received: from m3051.s.css.fujitsu.com (m3051.s.css.fujitsu.com [10.134.21.209]) by kw-mxoi2.gw.nic.fujitsu.com (Postfix) with ESMTP id F4236AC0114 for ; Tue, 23 Aug 2016 09:33:17 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v2.3.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20150624-1 X-SHieldMailCheckerMailID: f4e93941e37043d8bd5bd9e196b3957e To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: Naoki Matsuhira Message-ID: <57BB99C7.7040801@jp.fujitsu.com> Date: Tue, 23 Aug 2016 09:33:11 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 00:33:25 -0000 I'm really surprised. I was helped a lot of conversation with you. Perhaps, I think that many of the other people　were also helped. Thank you very much. Naoki. On 2016/08/23 4:03, Fred Baker (fred) wrote: > This is perhaps abrupt... > > I am leaving Cisco and my next steps are at this point indeterminate. As a result, I am backing away from IETF activity for the near, and perhaps foreseeable, future. Let me take this opportunity to say to each of you that this has been an interesting and productive activity for the past decade, and I wish the IETF and its participants the best. You may see automated emails from this address for a little while ("state of play", new draft postings) until my termination date, but starting Thursday (when I go on a pre-planned vacation), I won't be here. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Aug 22 19:47:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CF612D867 for ; Mon, 22 Aug 2016 19:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZILrvebxTHsz for ; Mon, 22 Aug 2016 19:47:16 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1176B12D107 for ; Mon, 22 Aug 2016 19:47:15 -0700 (PDT) X-AuditID: c618062d-597ff70000000a08-ad-57bbba4e0a18 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id B5.A2.02568.E4ABBB75; Tue, 23 Aug 2016 04:52:00 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0301.000; Mon, 22 Aug 2016 22:39:09 -0400 From: Suresh Krishnan To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] Best wishes Thread-Index: AQHR/KfXzatPgWDlbkev9sVlqwPXow== Date: Tue, 23 Aug 2016 02:38:55 +0000 Message-ID: References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXSPn27Art3hBl0XRC3erzvDZnH62F5m ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugStj+/YNLAVTOSp2TN7E1sB4gK2LkZNDQsBE 4t3cg4xdjFwcQgIbGCW6FqxggnCWM0ocvtzLDFLFBlS1YednJhBbRMBb4vaL1exdjBwcwgIK Eis76iHCihL/Vx1nBAmLCOhJ3F7hBRJmEVCVuNn6EWwKr4CvxMwHy8GmCAnYSCxpfg9mMwqI SXw/tQbMZhYQl7j1ZD4TxG0CEkv2nGeGsEUlXj7+xwphK0l8/D2fHaJeR2LB7k9sELa2xLKF r6F2CUqcnPmEZQKj8CwkY2chaZmFpGUWkpYFjCyrGDlKiwtyctONDDYxAkP7mASb7g7G+9M9 DzEKcDAq8fAusN0dLsSaWFZcmXuIUYKDWUmEd/8OoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe sUeK4UIC6YklqdmpqQWpRTBZJg5OqQZG68bNZX0THz0UjJAVUJUvZpt2+sicB5NP/lT9F8vK tEfpxNx/Vz676Kf97ZQp6z/RnsDDWtt83fKesrvOXMvq/K7tTNUP30WEZUaUMf77MietV3lR O6ttg1OqzHvxNK3y3oILG8uXdz5ynZvqpfRAINJt7s5G24Ulhht/lUq+PanAcK632laJpTgj 0VCLuag4EQCGmGK+aQIAAA== Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 02:47:17 -0000 Hi Fred,=0A= =0A= On 08/22/2016 03:03 PM, Fred Baker (fred) wrote:=0A= > This is perhaps abrupt...=0A= >=0A= > I am leaving Cisco and my next steps are at this point indeterminate. As = a result, I am backing away from IETF activity for the near, and perhaps fo= reseeable, future. Let me take this opportunity to say to each of you that = this has been an interesting and productive activity for the past decade, a= nd I wish the IETF and its participants the best. You may see automated ema= ils from this address for a little while ("state of play", new draft postin= gs) until my termination date, but starting Thursday (when I go on a pre-pl= anned vacation), I won't be here.=0A= =0A= That is terrible news. You have been a great mentor, leader and simply a = =0A= fantastic person. I have learned a lot from you and I am honored to have = =0A= known you and worked with you. You will be sorely missed. Hope our paths = =0A= cross again in the near future.=0A= =0A= Thanks again for everything=0A= Suresh=0A= =0A= From nobody Mon Aug 22 21:25:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939CC12D0A9 for ; Mon, 22 Aug 2016 21:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=126.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zeJxfeV0iJD for ; Mon, 22 Aug 2016 21:25:28 -0700 (PDT) Received: from m15-23.126.com (m15-23.126.com [220.181.15.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0117512B01C for ; Mon, 22 Aug 2016 21:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=aC2Kh 7UH1PeMfHlSqIXQNy0M4Bur89QGykOzxTEF7eo=; b=aLK0pBvpaaue7lWFpMzu7 Mgyzgkx1EPx2sY7OLqtHiJBBreF/vKC0PMmI6wB/t7HkJsbGHLcu97Kmf6Kwh2eZ pKgW8sLE/E77aZV4Hk9AbRzCrqAqr1tnMzRt8qMJX1uBDZaSq/DzwhejWI1PFsw3 VocpUoAERFAyNBz8SbvUEY= Received: from lilishan48$126.com ( [101.5.131.252] ) by ajax-webmail-wmsvr23 (Coremail) ; Tue, 23 Aug 2016 12:25:21 +0800 (CST) X-Originating-IP: [101.5.131.252] Date: Tue, 23 Aug 2016 12:25:21 +0800 (CST) From: "Lishan Li" To: "Fred Baker (fred)" X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160420(83524.8626) Copyright (c) 2002-2016 www.mailtech.cn 126com In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> X-CM-CTRLDATA: dLMgmWZvb3Rlcl9odG09MTI1MDo1Ng== Content-Type: multipart/alternative; boundary="----=_Part_81262_1076662385.1471926321912" MIME-Version: 1.0 Message-ID: <59948e7d.45d2.156b5a542f9.Coremail.lilishan48@126.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: F8qowAAXmrIy0LtXS3sSAA--.31834W X-CM-SenderInfo: 5olox2hkdqkma6rslhhfrp/1tbi6w7OwVUw14iE1AACsC X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 04:25:29 -0000 ------=_Part_81262_1076662385.1471926321912 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 RnJlZCBpcyBhIGdyZWF0IG1lbnRvci4gSGUgaXMgdGhlIGZpcnN0IG1hbiBJIGtuZXcgaW4gSUVU Ri4gSGUgaGVscGVkIGEgbG90IHRvIG1vZGlmeSBteSAKaWRlYSwgaGVscCBtZSB0byBtb2RpZnkg dGhlIGRyYWZ0LCBlbmNvdXJhZ2UgbWUgdG8gc3VibWl0IGl0LiBJIGhhdmUgbGVhcm5lZCBhIGxv dCBmcm9tIHlvdS4gCkl0IGlzIG15IGdyZWF0IGhvbm9yIHRvIGhhdmUga25vd24geW91IGFuZCB3 b3JrZWQgd2l0aCB5b3UuIEJlc3QgV2lzaGVzIHRvIHlvdS4KCgpUaGFua3MgYWdhaW4sCkxpc2hh bgpBdCAyMDE2LTA4LTIzIDAzOjAzOjE3LCAiRnJlZCBCYWtlciAoZnJlZCkiIDxmcmVkQGNpc2Nv LmNvbT4gd3JvdGU6Cj5UaGlzIGlzIHBlcmhhcHMgYWJydXB0Li4uCj4KPkkgYW0gbGVhdmluZyBD aXNjbyBhbmQgbXkgbmV4dCBzdGVwcyBhcmUgYXQgdGhpcyBwb2ludCBpbmRldGVybWluYXRlLiBB cyBhIHJlc3VsdCwgSSBhbSBiYWNraW5nIGF3YXkgZnJvbSBJRVRGIGFjdGl2aXR5IGZvciB0aGUg bmVhciwgYW5kIHBlcmhhcHMgZm9yZXNlZWFibGUsIGZ1dHVyZS4gTGV0IG1lIHRha2UgdGhpcyBv cHBvcnR1bml0eSB0byBzYXkgdG8gZWFjaCBvZiB5b3UgdGhhdCB0aGlzIGhhcyBiZWVuIGFuIGlu dGVyZXN0aW5nIGFuZCBwcm9kdWN0aXZlIGFjdGl2aXR5IGZvciB0aGUgcGFzdCBkZWNhZGUsIGFu ZCBJIHdpc2ggdGhlIElFVEYgYW5kIGl0cyBwYXJ0aWNpcGFudHMgdGhlIGJlc3QuIFlvdSBtYXkg c2VlIGF1dG9tYXRlZCBlbWFpbHMgZnJvbSB0aGlzIGFkZHJlc3MgZm9yIGEgbGl0dGxlIHdoaWxl ICgic3RhdGUgb2YgcGxheSIsIG5ldyBkcmFmdCBwb3N0aW5ncykgdW50aWwgbXkgdGVybWluYXRp b24gZGF0ZSwgYnV0IHN0YXJ0aW5nIFRodXJzZGF5ICh3aGVuIEkgZ28gb24gYSBwcmUtcGxhbm5l ZCB2YWNhdGlvbiksIEkgd29uJ3QgYmUgaGVyZS4K ------=_Part_81262_1076662385.1471926321912 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+RnJlZCBpcyBhIGdyZWF0IG1lbnRvci4gSGUgaXMgdGhl IGZpcnN0IG1hbiBJIGtuZXcgaW4gSUVURi4gSGUgaGVscGVkIGEgbG90IHRvIG1vZGlmeSBteSZu YnNwOzwvZGl2PjxkaXY+aWRlYSwgaGVscCBtZSB0byBtb2RpZnkgdGhlIGRyYWZ0LCBlbmNvdXJh Z2UgbWUgdG8gc3VibWl0IGl0LiZuYnNwOzxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS43OyI+ SSBoYXZlIGxlYXJuZWQgYSBsb3QgZnJvbSB5b3UuJm5ic3A7PC9zcGFuPjwvZGl2PjxkaXY+PHNw YW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjc7Ij5JdCBpcyBteSBncmVhdCBob25vciB0byBoYXZl IGtub3duIHlvdSBhbmQgd29ya2VkIHdpdGggeW91LiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i bGluZS1oZWlnaHQ6IDEuNzsiPkJlc3QgV2lzaGVzIHRvIHlvdS48L3NwYW4+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5UaGFua3MgYWdhaW4sPC9kaXY+PGRpdj5MaXNoYW48L2Rpdj48cHJlPkF0 IDIwMTYtMDgtMjMgMDM6MDM6MTcsICJGcmVkIEJha2VyIChmcmVkKSIgJmx0O2ZyZWRAY2lzY28u Y29tJmd0OyB3cm90ZToKJmd0O1RoaXMgaXMgcGVyaGFwcyBhYnJ1cHQuLi4KJmd0OwomZ3Q7SSBh bSBsZWF2aW5nIENpc2NvIGFuZCBteSBuZXh0IHN0ZXBzIGFyZSBhdCB0aGlzIHBvaW50IGluZGV0 ZXJtaW5hdGUuIEFzIGEgcmVzdWx0LCBJIGFtIGJhY2tpbmcgYXdheSBmcm9tIElFVEYgYWN0aXZp dHkgZm9yIHRoZSBuZWFyLCBhbmQgcGVyaGFwcyBmb3Jlc2VlYWJsZSwgZnV0dXJlLiBMZXQgbWUg dGFrZSB0aGlzIG9wcG9ydHVuaXR5IHRvIHNheSB0byBlYWNoIG9mIHlvdSB0aGF0IHRoaXMgaGFz IGJlZW4gYW4gaW50ZXJlc3RpbmcgYW5kIHByb2R1Y3RpdmUgYWN0aXZpdHkgZm9yIHRoZSBwYXN0 IGRlY2FkZSwgYW5kIEkgd2lzaCB0aGUgSUVURiBhbmQgaXRzIHBhcnRpY2lwYW50cyB0aGUgYmVz dC4gWW91IG1heSBzZWUgYXV0b21hdGVkIGVtYWlscyBmcm9tIHRoaXMgYWRkcmVzcyBmb3IgYSBs aXR0bGUgd2hpbGUgKCJzdGF0ZSBvZiBwbGF5IiwgbmV3IGRyYWZ0IHBvc3RpbmdzKSB1bnRpbCBt eSB0ZXJtaW5hdGlvbiBkYXRlLCBidXQgc3RhcnRpbmcgVGh1cnNkYXkgKHdoZW4gSSBnbyBvbiBh IHByZS1wbGFubmVkIHZhY2F0aW9uKSwgSSB3b24ndCBiZSBoZXJlLgo8L3ByZT48L2Rpdj48YnI+ PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNlZm9vdGVyIj48cD4mbmJzcDs8L3A+PC9zcGFuPg== ------=_Part_81262_1076662385.1471926321912-- From nobody Mon Aug 22 22:12:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB1C12D0B7 for ; Mon, 22 Aug 2016 22:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XltJh3pz742g for ; Mon, 22 Aug 2016 22:12:50 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1CD12D866 for ; Mon, 22 Aug 2016 22:12:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1719FA2; Tue, 23 Aug 2016 07:12:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1471929166; bh=iOuATEIOGVsRvWymApgC/mjVDyj0WUgb7D9m02N36qg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=1FGV41FxpuIGCXs9L+cTITTFetjqxY4uf9woRDK21SBS2U+2OKcak24pfM2nUf9B2 8+ZAFjyM+80pcLK3IbV1Rpw+pJh+c5GgUu0+FHIrxvYuT1WPbsHLdi8d+WCAMPYwjM YX35LB1uMUxCWKM2JMSK/wXj7DcrZg5tgmBWznnE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 10BC1A1; Tue, 23 Aug 2016 07:12:46 +0200 (CEST) Date: Tue, 23 Aug 2016 07:12:46 +0200 (CEST) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Message-ID: References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 05:12:53 -0000 On Mon, 22 Aug 2016, Fred Baker (fred) wrote: > I am leaving Cisco and my next steps are at this point indeterminate. As > a result, I am backing away from IETF activity for the near, and perhaps > foreseeable, future. Let me take this opportunity to say to each of you > that this has been an interesting and productive activity for the past > decade, and I wish the IETF and its participants the best. You may see > automated emails from this address for a little while ("state of play", > new draft postings) until my termination date, but starting Thursday > (when I go on a pre-planned vacation), I won't be here. This is sad news. Thanks a lot Fred for everything you've done, you've been extremely resourceful, kind, understanding, helpful and accomodating to me and a lot of other people. You will be greatly missed. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Aug 22 23:36:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEBE12B04D for ; Mon, 22 Aug 2016 23:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhIASEenVmro for ; Mon, 22 Aug 2016 23:36:13 -0700 (PDT) Received: from mail.kenet.or.ke (mail.kenet.or.ke [41.89.1.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A4C12B035 for ; Mon, 22 Aug 2016 23:36:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.kenet.or.ke (Postfix) with ESMTP id 198472202E9F; Tue, 23 Aug 2016 09:36:07 +0300 (EAT) Received: from mail.kenet.or.ke ([127.0.0.1]) by localhost (mail.kenet.or.ke [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZEXiY9QAmCc3; Tue, 23 Aug 2016 09:36:06 +0300 (EAT) Received: from localhost (localhost [127.0.0.1]) by mail.kenet.or.ke (Postfix) with ESMTP id 3CC412202FCA; Tue, 23 Aug 2016 09:36:06 +0300 (EAT) X-Virus-Scanned: amavisd-new at kenet.or.ke Received: from mail.kenet.or.ke ([127.0.0.1]) by localhost (mail.kenet.or.ke [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IJqf_6gk9Ycx; Tue, 23 Aug 2016 09:36:06 +0300 (EAT) Received: from mail.kenet.or.ke (mail.kenet.or.ke [41.89.1.213]) by mail.kenet.or.ke (Postfix) with ESMTP id 183912202E9F; Tue, 23 Aug 2016 09:36:06 +0300 (EAT) Date: Tue, 23 Aug 2016 09:36:05 +0300 (EAT) From: Joan Masai To: "Fred Baker (fred)" Message-ID: <246648216.5803236.1471934165690.JavaMail.zimbra@kenet.or.ke> In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5803235_595842927.1471934165688" X-Originating-IP: [197.136.2.126] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - FF47 (Linux)/8.6.0_GA_1194) Thread-Topic: Best wishes Thread-Index: AQHR/KfXzatPgWDlbkev9sVlqwPXo1YciaQq Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 06:36:16 -0000 ------=_Part_5803235_595842927.1471934165688 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit This is very sad. IETF 96 was my very first meeting to attend and Fred was my mentor. He made time to take us out to dinner and to show the ropes of IETF. Fred, you are an amazing leader and brilliant mind, but also a wonderful person. I will always look up to you. Best wishes Thanks again. --------- Joan From: "Fred Baker (fred)" To: v6ops@ietf.org Sent: Monday, August 22, 2016 10:03:17 PM Subject: [v6ops] Best wishes This is perhaps abrupt... I am leaving Cisco and my next steps are at this point indeterminate. As a result, I am backing away from IETF activity for the near, and perhaps foreseeable, future. Let me take this opportunity to say to each of you that this has been an interesting and productive activity for the past decade, and I wish the IETF and its participants the best. You may see automated emails from this address for a little while ("state of play", new draft postings) until my termination date, but starting Thursday (when I go on a pre-planned vacation), I won't be here. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_5803235_595842927.1471934165688 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This is very sad.

IETF 96 was my very first me= eting to attend and Fred was my mentor. He made time to take us out to dinn= er and to show the ropes of IETF.

<= /div>
Fred, you are an amazing leader and brilliant mind, but also a wo= nderful person. I will always look up to you. Best wishes

Thanks again.

---------
Joan

<= hr id=3D"zwchr">
From: "Fred Baker (fred)" <fred@cisco.com>= ;
To: v6ops@ietf.org
Sent: Monday, August 22, 2016 10:0= 3:17 PM
Subject: [v6ops] Best wishes

This is pe= rhaps abrupt...

I am leaving Cisco and my next steps are at this poi= nt indeterminate. As a result, I am backing away from IETF activity for the= near, and perhaps foreseeable, future. Let me take this opportunity to say= to each of you that this has been an interesting and productive activity f= or the past decade, and I wish the IETF and its participants the best. You = may see automated emails from this address for a little while ("state of pl= ay", new draft postings) until my termination date, but starting Thursday (= when I go on a pre-planned vacation), I won't be here.

_____________= __________________________________
v6ops mailing list
v6ops@ietf.org<= br>https://www.ietf.org/mailman/listinfo/v6ops

<= /body> ------=_Part_5803235_595842927.1471934165688-- From nobody Mon Aug 22 23:40:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BC012D758; Mon, 22 Aug 2016 23:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvm28mFqn_zS; Mon, 22 Aug 2016 23:40:27 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5BC12B04D; Mon, 22 Aug 2016 23:40:27 -0700 (PDT) Received: from [192.168.3.108] (214-173-16-190.fibertel.com.ar [190.16.173.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EB68280322; Tue, 23 Aug 2016 08:40:22 +0200 (CEST) To: otroan@employees.org, Mark Smith References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <2e84cd40-dcfd-d55d-1241-681d216e88b4@si6networks.com> Date: Tue, 23 Aug 2016 08:10:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops-chairs@ietf.org" , v6ops list , 6man WG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 06:40:29 -0000 On 08/22/2016 10:35 AM, otroan@employees.org wrote: [....] >> >> Sort of seems to be a lot of effort to mitigate what is >> fundamentally a problem of not following very clear processing >> requirements in RFC4861 by the target node: >> >> "A node MUST silently discard any received Neighbor Solicitation >> messages that do not satisfy all of the following validity checks: >> >> - The IP Hop Limit field has a value of 255, i.e., the packet could >> not possibly have been forwarded by a router." >> >> Writing more specifications to mitigate against people not >> completely following existing specifications only creates more new >> specifications they may not follow completely either. >> >> Does anyone have any insights into how multiple implementations >> might have missed or perhaps intentionally decided not to perform >> this validity check? It seems a bit unusual that two different >> commonly used implementations didn't do it (I just checked the >> Linux and FreeBSD source and they do perform the check.) >> >> In cases such as this, perhaps implementation checklists (perhaps >> as an RFC appendix) could assist either the implementer or a code >> reviewer in ensuring they've implemented things completely. > > The issue isn't about the hop limit validation check not being done > (it is), I would expect this to be the case. However, folks seem to have mentioned that this wasn't really the case? > it is about _where_ it is done. A packet is determined to be for the > router itself, the hardware forwarding plane then needs to decide if > it should process the packet itself, punt the packet to software or > drop it. There might be orders of magnitude difference in pps > capability between software and hardware. > > Is there anything we can learn from this? We have to consider in > protocol design how expensive it is to determine if a forus() packet > should be dropped or not. Looking deep into a packet to determine it > is an ND packet and then do the validity checks in hardware might not > be optimal. Perhaps ND packets should have been limited to using > link-local addresses only. If "deep" == "parsing the ICMPv6 header to figure out type/code and tell the packet type", then... isn't this essentially the same thing with EHs? That's kind of what all the debate about EHs is about... (FWIW, I do agree with all your statements above) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 23 01:37:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D14112D89F; Tue, 23 Aug 2016 01:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6JTsJnNgU53; Tue, 23 Aug 2016 01:37:19 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6608612D89C; Tue, 23 Aug 2016 01:37:19 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=52266 helo=envy) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1bc7Ct-0003xF-Mh; Tue, 23 Aug 2016 10:37:15 +0200 Date: Tue, 23 Aug 2016 10:37:15 +0200 From: Tore Anderson To: otroan@employees.org Message-ID: <20160823103715.0b0a4a07@envy> In-Reply-To: <5D8D4A35-1D8A-4D6D-A5CA-D0D2BF78CA8E@employees.org> References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> <20160822143302.2da13b80@envy> <20160822171046.3c62ffe7@envy> <5D8D4A35-1D8A-4D6D-A5CA-D0D2BF78CA8E@employees.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops-chairs@ietf.org" , v6ops list , 6man WG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 08:37:21 -0000 * otroan@employees.org > Tore, >=20 > >>> * otroan@employees.org > >>> =20 > >>>> The issue isn't about the hop limit validation check not being done > >>>> (it is) =20 > >>>=20 > >>> Are you certain that it is? Both Cisco CSCuz66542 and Juniper > >>> JSA10749 describe how the crafted ND packets will be *processed* by > >>> the control plane - not dropped. > >>>=20 > >>> Furthermore, both advisories go on to describe how successful > >>> exploitation might cause the device to stop handling *IPv6* traffic > >>> specifically - as opposed to impacting *all* traffic. > >>>=20 > >>> While the advisories don't go into detail, this suggests to me that > >>> successful exploitation of the issue is dependent on the crafted > >>> packets actually being able to manipulate/overwhelm the IPv6 > >>> neighbour caches. That couldn't happen if the hop limit validation > >>> was done and the packet was dropped - even though this was done in > >>> software, by the control plane itself. =20 > >>=20 > >> you could explain that behaviour differently. > >> the consequence of a massive stream of ND packets are that they will > >> be heavily throttled between hardware and software forwarding planes. > >> that will also impact legitimate ND packets, meaning that whatever > >> entries there are in the ND cache or the replies from address > >> resolution will not make it back to the ND process. =20 > >=20 > > Sure, but that'd just be a variation on the simple volumetric DoS, > > nothing that would be unique to ND. =20 >=20 > I believe that's largely correct. Ack. It seems the HL check is indeed being performed by JUNOS at least (12.3 and 13.3, MX and EX platforms). I tested this by artificially lowering the HL of the ICMPv6 packets generated by a directly attached Linux host, like so: $=C2=A0ip6tables -t mangle -I OUTPUT -p icmpv6 -m hl --hl-eq 255 -j HL --hl= -set 254 As one would expect with a compliant ND implementation, the host lost IPv6 connectivity as neighbour resolution no longer worked. So if all there is to this vulnerability is a simple volumetric DoS attack on the control plane I really wonder what all the fuss is about. Most operators are fully aware that *any* traffic from untrusted sources that is being allowed to reach the control plane is a potential DoS vector. Shockingly enough, IPv6 ND is no exception - news at 11. Tore From nobody Tue Aug 23 14:08:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF04312D178 for ; Tue, 23 Aug 2016 14:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIgFooi2YJB0 for ; Tue, 23 Aug 2016 14:08:17 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1284712D9FE for ; Tue, 23 Aug 2016 14:08:16 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B08FB60712 for ; Tue, 23 Aug 2016 23:08:14 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 4EA6260142; Tue, 23 Aug 2016 23:08:14 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 3C5023614C; Tue, 23 Aug 2016 23:08:14 +0200 (CEST) Date: Tue, 23 Aug 2016 23:08:14 +0200 From: Gert Doering To: Tore Anderson Message-ID: <20160823210814.GO79185@Space.Net> References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> <20160822143302.2da13b80@envy> <20160822171046.3c62ffe7@envy> <5D8D4A35-1D8A-4D6D-A5CA-D0D2BF78CA8E@employees.org> <20160823103715.0b0a4a07@envy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160823103715.0b0a4a07@envy> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: 6man WG , "v6ops-chairs@ietf.org" , v6ops list , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 21:08:19 -0000 Hi, On Tue, Aug 23, 2016 at 10:37:15AM +0200, Tore Anderson wrote: > So if all there is to this vulnerability is a simple volumetric DoS > attack on the control plane I really wonder what all the fuss is about. > Most operators are fully aware that *any* traffic from untrusted ^^^^^^^^^^^^^^^ Your optimism on the state of the Internet is amazing :-) - you should be reading IXP mailing lists for a reality check on the amazingly low level of understanding out there. > sources that is being allowed to reach the control plane is a potential > DoS vector. Shockingly enough, IPv6 ND is no exception - news at 11. Seriously - I blatantly assumed that IOS XR LPTS would "do the right thing here", namely, protect me from Joe Random's ND packets sent all over the Internet to my boxes. Now, if a peer at the local IXP turns out to be malicous or gets hacket, yes, this is an obvious attack angle - but "random packets from the Internet drowning out legitimate on-link IPv6 ND packets"? Well, for me, this came as a surprise. (Arguably, the hardware might not be able to look at TTL - but if it's smart enough to have a queue for IPv6 ND packets in the first place, why is it not smart enough to program proper source address filters there?) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Aug 23 15:14:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DCF12DBCD for ; Tue, 23 Aug 2016 15:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4bjjKRhBgh9 for ; Tue, 23 Aug 2016 15:14:48 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139A312DBBE for ; Tue, 23 Aug 2016 15:14:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7NMEl0Q049775; Tue, 23 Aug 2016 15:14:47 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7NMEiWS049743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2016 15:14:44 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 15:14:44 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 23 Aug 2016 15:14:44 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9tcrwwccPUlJiEK61fgu5QfdmKBKRsFggAFpOgCAA4768IABR9AAgAaWCcA= Date: Tue, 23 Aug 2016 22:14:44 +0000 Message-ID: <44886625fa094c77a6999b0020f23095@XCH15-05-05.nw.nos.boeing.com> References: <396f327690d24cfa8f519488bfc28bdd@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 22:14:52 -0000 Hi Mikael, Thank you for taking the time to review the document. Please see below for follow-ups: > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Friday, August 19, 2016 2:54 AM > To: Templin, Fred L > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 >=20 > On Thu, 18 Aug 2016, Templin, Fred L wrote: >=20 > > Hello, > > > > A new version of this draft is now available based on review comments r= eceived. > > The comments have greatly improved the document, which now also include= s > > figures that clearly illustrate the concepts described: > > > > https://www.ietf.org/id/draft-templin-v6ops-pdhost-04.txt >=20 > Re-reading as if I never read it before: >=20 > 1. Intro >=20 > " Hosts > 'Hn' on a LAN interface subsequently receive addresses 'An' taken > from 'P' via an address autoconfiguration service such as IPv6 > Stateless Address Autoconfiguration (SLAAC) [RFC4862]." >=20 > If A=3D1 is used, I'd avoid using the term "receive addresses". "allocate > addresse(s) for themselves" or similar term is more appropriate to make > sure the reader understands the distinction. How does this sound as a rewrite: "Hosts 'Hn' subsequently obtain one or more addresses 'An' for themselves via an address autoconfiguration service such as IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862]." > 4. >=20 > "The node also configures a default > route that points to a router on the WAN link." >=20 > This sentence can in context confuse readers to believe that this default > route is installed because of receiving a delegated prefix, when in fact > this is done because the node received an RA. Right? Default routes can be configured via manual config and/or from whatever form of autoconfiguration is appropriate for the link - of which RA is just one example. But, maybe it would be best to simply remove this sentence and remain silent on the subject of default routes? > 5. MLD/DAD Implications >=20 > This is confusing. The node still has a LL which it needs to perform > MLD/DAD for on the WAN interface, correct? No, it is the same for LL's if DupAddrDetectTransmits is 0 - no DAD/MLD. > Wouldn't it be better to just > recommend not to put the delegated prefix addresses on the WAN interface > at all, but exlusively use a virtual interface? On that virtual interface > then MLD/DAD can be turned off. Otherwise the WAN interface needs to > selectively support DAD/MLD for some addresses configured on it, and not > for others. The document is referring to the case where no DAD/MLD is needed for any addresses assigned to the interface -including LL, GUA, etc. > 6. >=20 > Is the third paragraph really necessary? It describes no new > functionality, the text seems to describe normal IPv6 operations. Seems i= t > would only confuse the reader? I don't mind removing the paragraph. But, in that case, I would still want to cite I-D.templin-aerolink as an example link where this is useful. > 7. >=20 > This paragraph would be simpler if we just avoid configuring the PD based > addresses on the WAN interface. > > Summary: >=20 > I am sympathetic to hosts requesting PD and then using it to assign itsel= f > addresses. I just think it would be cleaner if the weak host model was > recommended and that the PD based addresses would only be configured on a > virtual interface in case only the WAN interface exists. Some hosts may need to see ip_forwarding set to '1' if the addresses are assigned to a virtual interface (e.g., a loopback) instead of the WAN interface. Also, the MTU of the virtual interface would need to be somehow matched to the MTU of the WAN interface in order for TCP to correctly set its initial MSS, and that may be cumbersome in some cases. So, in my experience it is cleaner to assign the addresses to the WAN interface. I am currently doing this on Androids using AERO, and the applications seem to like it. > Also, calling it "WAN" interface is a bit confusing. What is a "WAN" > interface on a host? I have no better suggestion for what to call it, WAN > is short and "sweet" and using other names might just cause more > confusion. The draft outlines what it means by WAN interface (good that > you added the drawings) so it should be ok. OK. > The draft is DHCPv6 heavy and SLAAC light when it comes to text, it seems > to talk more about DHCPv6 functions and glosses over things that are > configured because of RAs etc. For someone not familiar with IPv6, they > might draw the wrong conclusions on how IPv6 works regarding RA/DHCP > interaction and what causes what. Perhaps there should be some more > pointers to this, and if the text is DHCP verbose, then I think it needs > to be equally verbose on SLAAC/RA. DHCPv6 PD is cited only as an example in the first paragraph of Section 1. Any other prefix delegation method is also in-scope. Other methods include manual configuration, and any other prefix delegation method that may one day be specified. If you have specific examples of where the text seems to be inferring DHCPv6 PD, I would be happy to make the text more generic so that it is clear that DHCPv6 PD is only an example. Thanks - Fred fred.l.templin@oboeing.com > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 23 15:22:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8312DB8F for ; Tue, 23 Aug 2016 15:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U73ybeAKWlJ2 for ; Tue, 23 Aug 2016 15:22:12 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B28912D1BE for ; Tue, 23 Aug 2016 15:22:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7NMMBkk015328; Tue, 23 Aug 2016 15:22:12 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7NMM4XE015260 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2016 15:22:04 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (137.137.100.80) by XCH15-05-06.nw.nos.boeing.com (137.137.100.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 15:22:03 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 23 Aug 2016 15:22:04 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: Best wishes Thread-Index: AQHR/KfXzatPgWDlbkev9sVlqwPXo6BXIBMw Date: Tue, 23 Aug 2016 22:22:04 +0000 Message-ID: <3b8f731d618c4e2d8fce4d5296c6dc81@XCH15-05-05.nw.nos.boeing.com> References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 22:22:13 -0000 Best regards, Fred T. > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred= ) > Sent: Monday, August 22, 2016 12:03 PM > To: v6ops@ietf.org > Subject: [v6ops] Best wishes >=20 > This is perhaps abrupt... >=20 > I am leaving Cisco and my next steps are at this point indeterminate. As = a result, I am backing away from IETF activity for the near, and > perhaps foreseeable, future. Let me take this opportunity to say to each = of you that this has been an interesting and productive > activity for the past decade, and I wish the IETF and its participants th= e best. You may see automated emails from this address for a > little while ("state of play", new draft postings) until my termination d= ate, but starting Thursday (when I go on a pre-planned > vacation), I won't be here. From nobody Tue Aug 23 15:28:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C0512DBB4 for ; Tue, 23 Aug 2016 15:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TALc55sBe-MW for ; Tue, 23 Aug 2016 15:28:09 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF48112DBB8 for ; Tue, 23 Aug 2016 15:28:08 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 97so269559346uav.3 for ; Tue, 23 Aug 2016 15:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZEUSc2UxVxXfiwMnYJr1Q19WjU1jxO90L6m/Ds24sbk=; b=xelQMBpnSgPtKmbNI8kJiOQiRCaw0AkjeKFDUUCG8Yc6Q3VwZNz2mycH6IK5yKQyb9 YXX09jIQ0IQ5SDSL+XnCIirrNQyUW3n7oyoenJePMGJZdkVOn0POFuXtbo/RYwyk1UXg fy+2iuMBTWfIiQkYQynludxVc3XtRIYQyWj/XMX2bFPZccfqkjTRFMqfhpGTZJIAZ3V1 rLs6N8NdSIPw17u6j0r278KZfiSz8TFi/deycYjON6nGdX2n4LQ9L9yvwNkXsBQSf41o 3DLG0+ZYrrPJZXn6gLgDqFtK3E9XarNAu255YuPftSJ21QFNLKRWRagS29wEunJqwDgO MQpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZEUSc2UxVxXfiwMnYJr1Q19WjU1jxO90L6m/Ds24sbk=; b=c5oXbColMIirmF8jAChEy6AH6p3/hVYGtXiNpisEWD0ppwoEN77i/mTk4FI8lfYj8t 1W172zeYGVRkBLJdwabgBM/w86Z1MRMOPGRP5vW5RxgdGg9aZiZ3LvMd/knCaDEmtMfF gs+nQwIDbtzEezOFo8d9EIEgcG4aWOFIx9qgvnRT09Hsrz/ftjrNuxITFZ0/cOTJ8sOn DHGqFEX4pVF643X+SjdyX5uRjC1IZyYkcmjohSBXOWbyV3u+4a0OPuDcQN8YO7ZouY2f P+DEtBp+buYj9sR/7R+TyuqWmIGvqhdHchNsIhGPNrDfZFLZZ8yi8awWelrzIM55U0FL bmPA== X-Gm-Message-State: AEkooutK3jZ/mzUEc1NiHltauuxHfj6q4FeFuuj6pYHPxStL7xqEHWwulEJbFa0bcOU0ZJYKKD/wl+4LOwoYNQ== X-Received: by 10.31.134.20 with SMTP id i20mr16555161vkd.21.1471991288075; Tue, 23 Aug 2016 15:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.252.141 with HTTP; Tue, 23 Aug 2016 15:28:07 -0700 (PDT) In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: suprita Date: Tue, 23 Aug 2016 15:28:07 -0700 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a11459e34d69a75053ac4adca Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 22:28:11 -0000 --001a11459e34d69a75053ac4adca Content-Type: text/plain; charset=UTF-8 Dear Fred, You have always been a true inspiration and motivation for me. Thanks for introducing me to IETF and all the encouragement every time I needed. I wish you the very best. Thank you and Best Regards, Suprita On Mon, Aug 22, 2016 at 12:03 PM, Fred Baker (fred) wrote: > This is perhaps abrupt... > > I am leaving Cisco and my next steps are at this point indeterminate. As a > result, I am backing away from IETF activity for the near, and perhaps > foreseeable, future. Let me take this opportunity to say to each of you > that this has been an interesting and productive activity for the past > decade, and I wish the IETF and its participants the best. You may see > automated emails from this address for a little while ("state of play", new > draft postings) until my termination date, but starting Thursday (when I go > on a pre-planned vacation), I won't be here. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11459e34d69a75053ac4adca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Fred,

You have always been a true = inspiration and motivation for me. Thanks for introducing me to IETF and al= l the encouragement every time I needed.

I wish yo= u the very best.

Thank you and Best Regards,
=
Suprita

On Mon, Aug 22, 2016 at 12:03 PM, Fred Baker (fred) <fred@cisco.com> wrote:
This is perhaps abrup= t...

I am leaving Cisco and my next steps are at this point indeterminate. As a = result, I am backing away from IETF activity for the near, and perhaps fore= seeable, future. Let me take this opportunity to say to each of you that th= is has been an interesting and productive activity for the past decade, and= I wish the IETF and its participants the best. You may see automated email= s from this address for a little while ("state of play", new draf= t postings) until my termination date, but starting Thursday (when I go on = a pre-planned vacation), I won't be here.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--001a11459e34d69a75053ac4adca-- From nobody Tue Aug 23 19:13:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAEC12D09E; Tue, 23 Aug 2016 19:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSEv5aB49SZV; Tue, 23 Aug 2016 19:13:45 -0700 (PDT) Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8612B02A; Tue, 23 Aug 2016 19:13:42 -0700 (PDT) Authentication-Results: smtp2.au.logicalis.com; spf=None smtp.mailfrom=gdaley@au.logicalis.com; spf=None smtp.helo=postmaster@sdcexchht.au.logicalis.com Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=10.18.196.63; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=10.18.196.63; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([10.18.196.63]) by smtp2.au.logicalis.com with ESMTP; 24 Aug 2016 12:13:18 +1000 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([100.64.20.45]) with mapi id 14.03.0279.002; Wed, 24 Aug 2016 12:13:18 +1000 From: Greg Daley To: 'Gert Doering' , Tore Anderson Thread-Topic: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) Thread-Index: AQHR+h5NxdCcf1UpP0Oj3kWb+inp7aBS1IyAgAE1gon//2T1AIAAlXmAgABCSQCAABGXgIAAGnsAgAApnQCAAPrFgIAA0dMAgAD1Q+A= Date: Wed, 24 Aug 2016 02:13:17 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D99282DC9E068@sdcexchms.au.logicalis.com> References: <8751AC02-956E-4CF3-AA69-139F205209C1@employees.org> <20160822143302.2da13b80@envy> <20160822171046.3c62ffe7@envy> <5D8D4A35-1D8A-4D6D-A5CA-D0D2BF78CA8E@employees.org> <20160823103715.0b0a4a07@envy> <20160823210814.GO79185@Space.Net> In-Reply-To: <20160823210814.GO79185@Space.Net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops-chairs@ietf.org" , v6ops list , 6man WG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 02:13:48 -0000 Hi Gert et al, While there's not an explicit vulnerability in the protocol which wasn't co= nsidered previously, some of the points raised indicate it is not obvious t= o operators how to provide protection from ND messages (amongst other ICMP)= ingressing or egressing your network. Is it worth providing some guidance steps? There's been some specific work done with ND-Shield (draft-gont-opsec-ipv6-= nd-shield-00) and ND Problems (RFC6583), as well as filtering rules for ICM= Pv6 (RFC4890) There is an explicit assumption in RFC 4890 S4.3.3 that the end device will= make the right decision and drop packets based on protocol behaviour (i.e.= pass ND traffic only with correct hop limits). I would recommend a change= to this behaviour to explicitly control traffic passing a network border. This would allow systems with bugs and are hard to patch (e.g. IoT) to oper= ate within a safer environment, even if they don't implement full ND checks= . If so, my guess is that sounds more like an operational WG approach rather = than 6man. Sincerely,=20 Greg Daley Solutions Architect Logicalis Australia Pty Ltd e gdaley@au.logicalis.com t +61 3 8532 4042 m +61 401 772 770 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Gert Doering > Sent: Wednesday, 24 August 2016 7:08 AM > To: Tore Anderson > Cc: 6man WG; v6ops-chairs@ietf.org; v6ops list; 6man-chairs@ietf.org > Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor > Discovery Crafted Packet Denial of Service Vulnerability) >=20 > Hi, >=20 > On Tue, Aug 23, 2016 at 10:37:15AM +0200, Tore Anderson wrote: > > So if all there is to this vulnerability is a simple volumetric DoS > > attack on the control plane I really wonder what all the fuss is about. > > Most operators are fully aware that *any* traffic from untrusted > ^^^^^^^^^^^^^^^ > Your optimism on the state of the Internet is amazing :-) - you should be > reading IXP mailing lists for a reality check on the amazingly low level = of > understanding out there. >=20 > > sources that is being allowed to reach the control plane is a > > potential DoS vector. Shockingly enough, IPv6 ND is no exception - news= at > 11. >=20 > Seriously - I blatantly assumed that IOS XR LPTS would "do the right thin= g > here", namely, protect me from Joe Random's ND packets sent all over the > Internet to my boxes. Now, if a peer at the local IXP turns out to be > malicous or gets hacket, yes, this is an obvious attack angle - but "rand= om > packets from the Internet drowning out legitimate on-link > IPv6 ND packets"? >=20 > Well, for me, this came as a surprise. >=20 > (Arguably, the hardware might not be able to look at TTL - but if it's sm= art > enough to have a queue for IPv6 ND packets in the first place, why is it = not > smart enough to program proper source address filters there?) >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Aug 24 02:29:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADDC12B00C; Wed, 24 Aug 2016 02:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqeuCUs_df_p; Wed, 24 Aug 2016 02:29:07 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444AA12B006; Wed, 24 Aug 2016 02:29:07 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id f6so23636718ith.0; Wed, 24 Aug 2016 02:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=LLU3AsMcpyw2DRUfsP0uDNLOwjXbgq3iY0G0Q1Zr6D4=; b=NxW36kEsmcIc1uKj+kKoHsMjeC3iJdbW4FuPrg/AU/MT5oSik/vjxVeWDDOtAZddvg 5GhfqNGuFXlPJnSs02fTpINt22jiq+B3tHKqwrddAabeBt29GmKIxFu70rGU40vBWQgF DBckeQSrCx2m/v8eT8Vnk9+2whmHO9Ihn4m0VCjZo0UAIEB51NB8e1TevhbIOiIxup1O Li0FWspAUIH1y5KDMDz0Hna9pip0VRplhL5QyP0a9Ov6WW5wremYu7FSqeGUTir54uu9 MhNi6oBh+TTeS02iujI2T3ZunfFCOPmNIHU4SxeEx/blLzBlogVZHKPFBNZiZgZKSD0j UuGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LLU3AsMcpyw2DRUfsP0uDNLOwjXbgq3iY0G0Q1Zr6D4=; b=K9gpErR0KIhXo63jsGQjylAp4gBULgIIAqZrEab0esuFjuunnma0hrqVWasimbDdba +vGaOHKB9Ll5/bXBM2FeKiELEhM5KWku/lp0Rn3cNUKk2IwKT3JBE+5b1Sko5UNq2U9X iGXSEbW1WGryZO8G4NyWzcIELEPFGxsPCXEQX8kdSgAc+oKYSAnn43osNcSNuc3ptxzN OEK7UfxC9i38A31FYs7q7mAdLhK0IJC/SEZ8mL3HaGGpa11X5nJvuEqzG5Ps4AshVMmQ 2H2FRqmgwZZ2lgH3IRWXsMtTiiUMoOI0+W01Bs3T95gYORYVJNFOGQxFFs7YMdwAYaZX oKcQ== X-Gm-Message-State: AEkoout0/pCqfbi13zc1ECbn0m1fsuamCXIsptWM0+tEGwxelsjYo2x0LyQDkJ2KkwAfuFR0Vhke9I/P65iGpw== X-Received: by 10.36.227.78 with SMTP id d75mr31618714ith.75.1472030946240; Wed, 24 Aug 2016 02:29:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.209 with HTTP; Wed, 24 Aug 2016 02:28:45 -0700 (PDT) From: Naveen Kottapalli Date: Wed, 24 Aug 2016 14:58:45 +0530 Message-ID: To: ipv6@ietf.org, v6ops@ietf.org Content-Type: multipart/alternative; boundary=94eb2c111de8a63141053acde9d7 Archived-At: Subject: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 09:29:08 -0000 --94eb2c111de8a63141053acde9d7 Content-Type: text/plain; charset=UTF-8 Hello, Can anyone tell if there is any SLAAC equivalent for *DHCPv6 Remote-Id / DHCP Option-82* option that can be used by a gateway to know the SSID, etc.,? Yours, Naveen. --94eb2c111de8a63141053acde9d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Can anyone tell if there=C2=A0is= any SLAAC equivalent for DHCPv6 Remote-Id / DHCP Option-82 option t= hat can be used by a gateway to know the SSID, etc.,?

<= div>Yours,
Naveen.
--94eb2c111de8a63141053acde9d7-- From nobody Wed Aug 24 02:52:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1548912D5A1 for ; Wed, 24 Aug 2016 02:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtBFlPReQOlZ for ; Wed, 24 Aug 2016 02:52:19 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A718812D567 for ; Wed, 24 Aug 2016 02:52:18 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id i5so18932120wmg.0 for ; Wed, 24 Aug 2016 02:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lUYCp3WNBZ3WBqdn///svIr/4PLc37WjP/ltyapMk2c=; b=Z/fUNdUOU0kzUxgmTS10OYZGym6gKPsT0sF9k5np22IKw/uUECrGkzBR03J8IH9Cl+ HxpaH6ABKfd+9jpJGDFYDYmirEzsSzPujEYB8iHeqMiqADLlFowg/QmVYAz4oe4tzfm+ Z6FsNOVARfd/5Y70xwJ3yaezEoByvTBgiRiO7hGmxHCs3nY10S6OGiYmTbwrlvndrDJY 21cOf1j0C9UgLtItEkxJ0b4emtO8dXAo4B1yxxgmAskECl6ZniRNjKRtxdLfFoaUkCxx HWkGH7OUGmjvSOAVnjWtjgqy5XvY2tnuAX0XJv8Z/YvcyXmgyihqlGCA+zI6rI3FX1bJ +IMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lUYCp3WNBZ3WBqdn///svIr/4PLc37WjP/ltyapMk2c=; b=mOCugNYpAEewxX1v1n5PZ4lttCVNnCJyw9q+rmz7B9wYdSNd8XvhU4Aj80JcCqi1nw vRtwACFf7CvI1yv5Xw12Eeyy3ZWwe1OnD8JY3gcQMcZPBtrlKEdPfCm5crF0aZb3BnJj jnoy7OVg8h4w3aynH2fAGB7ecPcbWL+4+EE5wBKDfWoFux7lQaV6RvxKS0TcmC+4m5q0 pZfEDZGAheMlH615WlALngifUwXwlH1ETenrpeavzcQbhv0PLIOwbpHJMsNYBN/d1x7U qDN3GnlIVpzmSCsyTiHdtvu1f32L6dJ3WNSoj4fKzdgrzlZIszkZMpTQIL75L6aRIO83 9aIw== X-Gm-Message-State: AEkoousi8VCosUSG3u40BKtqYXQDGi4IjSHvSIpnmvYlibldv21WhlOWXPNv9cVkwJswGwPkKLqVqzBK4XrUc8TR X-Received: by 10.194.96.205 with SMTP id du13mr1756938wjb.89.1472032336904; Wed, 24 Aug 2016 02:52:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.157.2 with HTTP; Wed, 24 Aug 2016 02:51:56 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Wed, 24 Aug 2016 18:51:56 +0900 Message-ID: To: Naveen Kottapalli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , IETF IPv6 Mailing List Subject: Re: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 09:52:24 -0000 On 24 August 2016 at 18:28, Naveen Kottapalli wrote: > Hello, > > Can anyone tell if there is any SLAAC equivalent for DHCPv6 Remote-Id / DHCP > Option-82 option that can be used by a gateway to know the SSID, etc.,? I'm guessing it's not what you want, but there is this: https://tools.ietf.org/html/rfc6788#section-4 From nobody Wed Aug 24 03:00:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFEA12D878; Wed, 24 Aug 2016 03:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-oT_1mt7KFG; Wed, 24 Aug 2016 03:00:16 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9E612D876; Wed, 24 Aug 2016 03:00:15 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id k90so19348748uak.1; Wed, 24 Aug 2016 03:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IVoaniLby5ViGhCrB0Cz58HkF2mpI2mxWoyXw/LxHG8=; b=Rw+Rw/fYSkYJcCJHCdWY/ewkVvG9cLiAVPvidB4CId9sLd0pMMO61jbYn+oaBxfUVW fPcPFFgCQ3G/FBu1+75pjCvEAtZSiNJMmm5G+1JlhjJ5DnghAGUGDJNZ2wXsmjehWDIU RWMtbwgwDh8/K9B16M/BCQY5P+raqnQDJdL6LWlW5BVnqehxgLmCQOq4OA7on6bUQFZz 6rX4DZlIuaQaSsmo3Xzafklssd7uJmkaQadNYeCVMDv+cIdVgfGYdXfg8/wuqQMx9KWU q038r4KQ/pQO7Fv5LGKOZbypoG54zoDR5HdEUxKdZ0ZC+2vc780zQ3FMRndnaM1JzLqq KeMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IVoaniLby5ViGhCrB0Cz58HkF2mpI2mxWoyXw/LxHG8=; b=g1kRAGpAf/6NnyPmokobmy+oCF8trEA5DzxtLUhHIITMITq7HY4urxHvsGjf/haPRh b7HphHZby1e6FEsBfu78nbaWaK/RS6nhIVM6iUfZm39XGhAZrxlbazCJVXKHiW1Lcuue TFN1+o/eio8EXH/tfX6FlIeFZjM078SiiuPyIvRIteTF465AB8YDsHyDuVcsmZYUqa6M qJ1bDXtFkdGgF4QrSiTmsg4jh4Lk/E0aRIRcK3rxV2CFVA1sY3XiRgS1sXomkRgHtMGG 9RLOyqs/7mFQLCJM1PbQpb28xy6qXt3FIA5/tXkPLL9T4wdOZNkAkOr/pMvOtesLcghU xi8A== X-Gm-Message-State: AEkoouuhqr24vZlzxzUtfFFKGsaBe/HuAoMuS9BNWQXZrvWDZd7FrHeQulUzdFXCM/wCEjgKRkSvCGyRqvTrLw== X-Received: by 10.31.64.196 with SMTP id n187mr1176030vka.150.1472032814469; Wed, 24 Aug 2016 03:00:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.165 with HTTP; Wed, 24 Aug 2016 02:59:44 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Wed, 24 Aug 2016 19:59:44 +1000 Message-ID: To: Naveen Kottapalli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 10:00:21 -0000 Hi, On 24 August 2016 at 19:28, Naveen Kottapalli wrote: > Hello, > > Can anyone tell if there is any SLAAC equivalent for DHCPv6 Remote-Id / DHCP > Option-82 option that can be used by a gateway to know the SSID, etc.,? > No there isn't. SLAAC is not relayed through a router/gateway is like DHCPv4 is, so there is no point trying to add information on the way. SLAAC doesn't actually assign addresses to hosts either - all it does is provides the hosts on the link with information about what prefixes/subnets are present on the link, and hosts then generate their own addresses from within the prefix. In other words, if you're thinking IPv6 SLAAC is equivalent to IPv4 DHCP, they aren't, they're very different. The use of DHCPv4 to assign addresses could be described as a centralised database dependent host address assignment protocol/method, where hosts don't participate in the generation and selection of the addresses they end up using. They either take what they're given from the DHCPv4 server or don't have an address to use. The use of SLAAC for address assignment in IPv6 could be described as a distributed address assignment system that doesn't have a central database. Hosts are entirely responsible for the generation and validation of addresses that they use based on the prefix information supplied in RAs. Regards, Mark. > Yours, > Naveen. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Aug 24 03:29:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1098E12DB7E; Wed, 24 Aug 2016 03:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaGEqcgBgZKz; Wed, 24 Aug 2016 03:29:47 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D050C12DB83; Wed, 24 Aug 2016 03:29:46 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id n128so25737537ith.1; Wed, 24 Aug 2016 03:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h5RTlJvLcPcJOJhwZFaB3OiJzmzDToS3G0k45wN5MQo=; b=dxzH790tuD+0rXWhJx37Sg+RB/aHkdHiUlKcKLKJsasP5Fgw6EBrhKUXiopHfLO5ll VdeZorUhiGV8pXmdid792alI0uKdTCjYizb7MY/4/TeLSIXuqG0lfuePwidg3Mo3HU17 9ROG2gntrZDRyOTgJ4AnyWSyLJRzNyXysRA9kOVhdC86CoUaWz4Phi9F+kEFQ7pCHnXN Wx825i4d+LI1gz3Egud/m32P94g22BP/Ju9zMCFeak1qmgn0CeOC0gBnCV/jcNVZVSb1 3wbJ9MLjNru1ujAdF0QVEFpp9XAT0WBkxLWdkDcuLXHNJNnbJ2kzCz7TMMH54cyULwWL b64Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h5RTlJvLcPcJOJhwZFaB3OiJzmzDToS3G0k45wN5MQo=; b=Hy9fDMGQxo2G36BUCFBxrGKhg3q06rATBuc0HBKapLU0ZgXGslT/hRJ42noY+nz4EB AZMKPcNUtmPqVdk0+8FDgxhP9f2c8FKBB8ZBkx+ShYc7utGsrz1+TG6TpvJ93BfCp+Wl Ip3M5qMcq9Ggxxa6V212dwTJoUKYJkiTnpxjXzCYv0g+hgEit9sjo4zym1swV9ouIKLr jqwhyzLtoktc6nAPoFUX2EK2PrCuehOcBHUfXTKYNgsJGAuv7cd8xJj84LDLUTIjSE/+ N1SocFpqb33WKhZ+j+J5VL4GIs7MA8BuQUITcwM/nq4qAEFqOEMm1y+BAERcGtZPKog0 iC7g== X-Gm-Message-State: AEkoousBkP4vH5WqVoBu6H1NTwUGGH3FHZmf22rPGhS33wwB5WmNNT1dhs6nJJBWnIJ2HgVDJJwJOOCldOy64Q== X-Received: by 10.107.16.77 with SMTP id y74mr3122515ioi.161.1472034585189; Wed, 24 Aug 2016 03:29:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.209 with HTTP; Wed, 24 Aug 2016 03:29:24 -0700 (PDT) In-Reply-To: References: From: Naveen Kottapalli Date: Wed, 24 Aug 2016 15:59:24 +0530 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=001a113e811c8c2422053acec26a Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 10:29:49 -0000 --001a113e811c8c2422053acec26a Content-Type: text/plain; charset=UTF-8 Hello, If the AP is relaying the RS on a GRE tunnel to the gateway, can whatever Erik suggested be used to inject the information whatever am looking for? Yours, Naveen. On 24 August 2016 at 15:29, Mark Smith wrote: > Hi, > > On 24 August 2016 at 19:28, Naveen Kottapalli > wrote: > > Hello, > > > > Can anyone tell if there is any SLAAC equivalent for DHCPv6 Remote-Id / > DHCP > > Option-82 option that can be used by a gateway to know the SSID, etc.,? > > > > No there isn't. > > SLAAC is not relayed through a router/gateway is like DHCPv4 is, so > there is no point trying to add information on the way. > > SLAAC doesn't actually assign addresses to hosts either - all it does > is provides the hosts on the link with information about what > prefixes/subnets are present on the link, and hosts then generate > their own addresses from within the prefix. > > In other words, if you're thinking IPv6 SLAAC is equivalent to IPv4 > DHCP, they aren't, they're very different. > > The use of DHCPv4 to assign addresses could be described as a > centralised database dependent host address assignment > protocol/method, where hosts don't participate in the generation and > selection of the addresses they end up using. They either take what > they're given from the DHCPv4 server or don't have an address to use. > > The use of SLAAC for address assignment in IPv6 could be described as > a distributed address assignment system that doesn't have a central > database. Hosts are entirely responsible for the generation and > validation of addresses that they use based on the prefix information > supplied in RAs. > > Regards, > Mark. > > > > Yours, > > Naveen. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > --001a113e811c8c2422053acec26a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

If the AP is relaying the RS on = a GRE tunnel to the gateway, can whatever Erik suggested be used to inject = the information whatever am looking for?

Yours,
Naveen.

On 24 August 2016 at 15:29, Mark Smith <markzzzsmith@gmail.com> wrote:
Hi,

On 24 August 2016 at 19:28, Naveen Kottapalli <naveen.sarma@gmail.com> wrote:
> Hello,
>
> Can anyone tell if there is any SLAAC equivalent for DHCPv6 Remote-Id = / DHCP
> Option-82 option that can be used by a gateway to know the SSID, etc.,= ?
>

No there isn't.

SLAAC is not relayed through a router/gateway is like DHCPv4 is, so
there is no point trying to add information on the way.

SLAAC doesn't actually assign addresses to hosts either - all it does is provides the hosts on the link with information about what
prefixes/subnets are present on the link, and hosts then generate
their own addresses from within the prefix.

In other words, if you're thinking IPv6 SLAAC is equivalent to IPv4
DHCP, they aren't, they're very different.

The use of DHCPv4 to assign addresses could be described as a
centralised database dependent host address assignment
protocol/method, where hosts don't participate in the generation and selection of the addresses they end up using. They either take what
they're given from the DHCPv4 server or don't have an address to us= e.

The use of SLAAC for address assignment in IPv6 could be described as
a distributed address assignment system that doesn't have a central
database. Hosts are entirely responsible for the generation and
validation of addresses that they use based on the prefix information
supplied in RAs.

Regards,
Mark.


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

--001a113e811c8c2422053acec26a-- From nobody Wed Aug 24 03:59:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993F512DC26; Wed, 24 Aug 2016 03:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It4PoDMkEk5m; Wed, 24 Aug 2016 03:59:10 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBC312DBE4; Wed, 24 Aug 2016 03:59:10 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id k90so21402572uak.1; Wed, 24 Aug 2016 03:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IBw/cYkDOTs4+ZwtrYul8QWb4NAiMYw1q4oEWtmoOWg=; b=uGtEey4gKxDFxys1ZO/U9sbQBrMhPeyd25C0X7em9snNVBYjhpCiYq6F9s5cIMRdZn Lz700n6w3YnUUDdCe04WnIslBHBIksn8dzzmt8R2wgY/1jSWsYz+OoC+cHf2fCsljKkx z9kpAM/nDKEemKcmEN28grEpQ9XAmtWJB+I5qekKRj+EYG5gg6OtJEV2PAfhbyeajfex OhCsDckOdW5G2aOyP5YMwwodfgHWbPQ98sVshkqAaeSnlrr4TLFlAO1UMxMoFEOCYXCQ PMIodGx4g1RHakY+M+WH2q2te2WtIkdAs2IqLaOkuvTIfEFNWvAQhbH8V0VwVkTqgiL5 I4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IBw/cYkDOTs4+ZwtrYul8QWb4NAiMYw1q4oEWtmoOWg=; b=U3S1WTfdBpYRQCPX4ObQD4ORFm21sbW2PMsxdU5+i1Xxun8SniO1fc5m9zcUJh9OHh NoE+Xj48VDIvEEl208cy9qUpvURfU6XIexyKD82PXtHGlEsjwP9PYr9Xxx4jdnC0z9C9 ZrjL3g1Un0xVI2dhUa/cYhK8fP1ctuomAMtS3FzXYDDwwIWB9AHkSkbEmYY/eKVM+6qR uRqfLA6wZsT/IDfxxeynLSk7p2CzvLdv0qlaNyUE83VNQjMVxSYz2B7Mlqon2VNpnNsr HSpjtvZ8rxZ6nf90EsurIDlD2GqplVhVeSCoeJrn3bpOKezivQiE4bLInt14cA6G8Eos voaA== X-Gm-Message-State: AE9vXwPBf7c2R66j+TyBpmyYnauNCpOhGgzVQDYnSrvTsLytMMnzELCG+RcVOmsewX86I/k3wxPhC+42uLUz2w== X-Received: by 10.159.41.230 with SMTP id s93mr1105987uas.67.1472036349159; Wed, 24 Aug 2016 03:59:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.165 with HTTP; Wed, 24 Aug 2016 03:58:38 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Wed, 24 Aug 2016 20:58:38 +1000 Message-ID: To: Naveen Kottapalli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 10:59:11 -0000 On 24 August 2016 at 20:29, Naveen Kottapalli wrote: > Hello, > > If the AP is relaying the RS on a GRE tunnel to the gateway, can whatever > Erik suggested be used to inject the information whatever am looking for? > Possibly (I'd forgotten about that method) if the AP supported it. Regards, Mark. > Yours, > Naveen. > > On 24 August 2016 at 15:29, Mark Smith wrote: >> >> Hi, >> >> On 24 August 2016 at 19:28, Naveen Kottapalli >> wrote: >> > Hello, >> > >> > Can anyone tell if there is any SLAAC equivalent for DHCPv6 Remote-Id / >> > DHCP >> > Option-82 option that can be used by a gateway to know the SSID, etc.,? >> > >> >> No there isn't. >> >> SLAAC is not relayed through a router/gateway is like DHCPv4 is, so >> there is no point trying to add information on the way. >> >> SLAAC doesn't actually assign addresses to hosts either - all it does >> is provides the hosts on the link with information about what >> prefixes/subnets are present on the link, and hosts then generate >> their own addresses from within the prefix. >> >> In other words, if you're thinking IPv6 SLAAC is equivalent to IPv4 >> DHCP, they aren't, they're very different. >> >> The use of DHCPv4 to assign addresses could be described as a >> centralised database dependent host address assignment >> protocol/method, where hosts don't participate in the generation and >> selection of the addresses they end up using. They either take what >> they're given from the DHCPv4 server or don't have an address to use. >> >> The use of SLAAC for address assignment in IPv6 could be described as >> a distributed address assignment system that doesn't have a central >> database. Hosts are entirely responsible for the generation and >> validation of addresses that they use based on the prefix information >> supplied in RAs. >> >> Regards, >> Mark. >> >> >> > Yours, >> > Naveen. >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> > > > From nobody Wed Aug 24 04:38:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA93812DCA2 for ; Wed, 24 Aug 2016 04:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek2QD0S_gPSY for ; Wed, 24 Aug 2016 04:38:44 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C7012DC99 for ; Wed, 24 Aug 2016 04:38:43 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id q128so197815276wma.1 for ; Wed, 24 Aug 2016 04:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pBt7Mn6drpq0AuxBcO8ILnv3xT5hcbpcmho2sMhXi38=; b=ogQdSPJA/tcRu2y9ugOwicke4t7rU4Gtu/zYjjmAHQD098qmQvgQ5j4h+NlurnRyla jUXIjhTgQX21fXpKAjwhVoOa19iTYLLyhmdLvqqMuRtkV2wuDox+9CE06fZ/3ml/iGgS sd1AKR7WZ6v1lpwfoql9dsmOYMg2F78ueHDPdzLsD5IsXNawQj3VV8RKbS/MMIu27Jrq wL9GnpEwIvmsMwj29LPM1VNYmHkJEpbQG7L3X/I0uHl9iA1spGwlK+u2dSkPKORRzrie vXQFY1gszM9JPs4nhcMb0024yzy36Nvn35OiJBoaZuFtLZDT8kXxDeFpQFYOPCMgFAh3 d8vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pBt7Mn6drpq0AuxBcO8ILnv3xT5hcbpcmho2sMhXi38=; b=RqrWLYakHR+sqh4ETHQR7gkP+qJUb1BwF0F5rdytHyCDM8S6QasALbS/t8MU8GlkSS r9PJp2+eJ056alQq3midHuat//tS6IiZimKto07SOcWUZZymgc6akYQHj6Ii3Z5eVfxJ tUbsbpdhsAHBhmb6hswnYiPSoS8oJ1Vhxtgj0WGct12w6J07oUeWMZQlozFSLV6cYihS RjY6h5K2eFH7d6QHe+mWFMtpdhbB3J6N+4F8VDAexUvzxdCOSyV2QsdJiuuATCuu9kMs mZoNj0OvCYzjvGCPF6C3Za28Gavj8V+e3dn++/eLVj9wDv3CyLPBF/x2NHB3W9QAVTzc XRQw== X-Gm-Message-State: AEkoouuMzP4ji3OCWvW5DN+FEMl+KmhQj/nE0te8ZHkkXJH5OpcaTOylBqRAivqIf4Dgp1iy/S35YouRE+iBbRH9 X-Received: by 10.194.96.205 with SMTP id du13mr2177871wjb.89.1472038722226; Wed, 24 Aug 2016 04:38:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.157.2 with HTTP; Wed, 24 Aug 2016 04:38:21 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Wed, 24 Aug 2016 20:38:21 +0900 Message-ID: To: Mark Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 11:38:47 -0000 On 24 August 2016 at 19:58, Mark Smith wrote: > On 24 August 2016 at 20:29, Naveen Kottapalli wrote: >> Hello, >> >> If the AP is relaying the RS on a GRE tunnel to the gateway, can whatever >> Erik suggested be used to inject the information whatever am looking for? >> > > Possibly (I'd forgotten about that method) if the AP supported it. Yeah, definitely a question for your vendor. > > > Regards, > Mark. > > >> Yours, >> Naveen. >> >> On 24 August 2016 at 15:29, Mark Smith wrote: >>> >>> Hi, >>> >>> On 24 August 2016 at 19:28, Naveen Kottapalli >>> wrote: >>> > Hello, >>> > >>> > Can anyone tell if there is any SLAAC equivalent for DHCPv6 Remote-Id / >>> > DHCP >>> > Option-82 option that can be used by a gateway to know the SSID, etc.,? >>> > >>> >>> No there isn't. >>> >>> SLAAC is not relayed through a router/gateway is like DHCPv4 is, so >>> there is no point trying to add information on the way. >>> >>> SLAAC doesn't actually assign addresses to hosts either - all it does >>> is provides the hosts on the link with information about what >>> prefixes/subnets are present on the link, and hosts then generate >>> their own addresses from within the prefix. >>> >>> In other words, if you're thinking IPv6 SLAAC is equivalent to IPv4 >>> DHCP, they aren't, they're very different. >>> >>> The use of DHCPv4 to assign addresses could be described as a >>> centralised database dependent host address assignment >>> protocol/method, where hosts don't participate in the generation and >>> selection of the addresses they end up using. They either take what >>> they're given from the DHCPv4 server or don't have an address to use. >>> >>> The use of SLAAC for address assignment in IPv6 could be described as >>> a distributed address assignment system that doesn't have a central >>> database. Hosts are entirely responsible for the generation and >>> validation of addresses that they use based on the prefix information >>> supplied in RAs. >>> >>> Regards, >>> Mark. >>> >>> >>> > Yours, >>> > Naveen. >>> > >>> > -------------------------------------------------------------------- >>> > IETF IPv6 working group mailing list >>> > ipv6@ietf.org >>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> > -------------------------------------------------------------------- >>> > >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 25 06:57:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1805312D82D; Thu, 25 Aug 2016 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8FZPTDsPKP7; Thu, 25 Aug 2016 06:57:39 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F6D12D13A; Thu, 25 Aug 2016 06:57:38 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id f6so90975737ith.0; Thu, 25 Aug 2016 06:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=9iUnhmz7AVLMre1ZZhc3C9w8jzBB4eOWx9HfsbSoHjw=; b=gh3nl8U4Usv3FLvMcL77TgYM2stM9sxh2agFYjZ5vKxEPDJb4C5NHbrAgTiN7pxZ0Q TiHDeijmdnXHWmYNUrIy2bNrxaPyokPXa8z4Z5Zx5KaLbYYWCGhKgiKpVtO7VrQy2yW5 psEbLipIQwBSPX585cp+c4tqE9Nn2d5sE5BPfeLYQaEScDSvU0VSYBrY9kHjFRajlh6D 8MTinGflKaDPVbRfCFYdZaZsCIrpdoGsI0dH8FyOLk+n95bMn8/ImRNMaAaKWhrcjIE2 2TtJjmrfL9gnGIp4JRiBzNxdWrxXbfVhQCSYr5HgHQXoCJtuVAGliRW+LhPDSVpRwyLR 3A5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9iUnhmz7AVLMre1ZZhc3C9w8jzBB4eOWx9HfsbSoHjw=; b=Z1Sc3wLxRYIBVMhPylgi3A/j7So+oleOZMQS0PHnbOytifhjlyCH2QocyhGRlN3t7u rlYt3+ra17kpSdKCxDjQAy6bAiazFGHGQ+sISb5POXBxe5xksXbCpNaxXW2dl3x3jf5S tn/PevcKHEhInkzL9CPImJ2gyfe2DsiOVrEMoIpxdy+dQxL7K30YVBsbtLRhxwPRwddC O6eWvHrz9EzLcwCmEOKJL6YztER8boWbcWyo+dFSlg6g/9f41nYA8nQ9exiBY/JE05cF f7/cEZErfQtemCFYJyjM9YOSgbmsj36SqrZVj916OudB5tRYfSFfsO4q7hoNHz+jCPHi LASg== X-Gm-Message-State: AEkooutDwrXCVoWH6ym+qCIDxTybTUd4IFwVuNySC5wom3CiVT7dusrMDTse3HmE0NKR8F2kkjROQT8pJLDReQ== X-Received: by 10.107.150.83 with SMTP id y80mr10662583iod.113.1472133457812; Thu, 25 Aug 2016 06:57:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.130.2 with HTTP; Thu, 25 Aug 2016 06:57:17 -0700 (PDT) From: Naveen Kottapalli Date: Thu, 25 Aug 2016 19:27:17 +0530 Message-ID: To: v6ops list , 6man WG Content-Type: multipart/alternative; boundary=001a11405feed0a148053ae5c76a Archived-At: Subject: [v6ops] v6 gateway data forwarding behaviour X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 13:57:40 -0000 --001a11405feed0a148053ae5c76a Content-Type: text/plain; charset=UTF-8 Hello, Assuming that the node is given a prefix in RA by the gateway, does the gateway need to know the complete address being used by node for data forwarding? Yours, Naveen. --001a11405feed0a148053ae5c76a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Assuming that the node is g= iven a prefix in RA by the gateway, does the gateway need to know the compl= ete address being used by node for data forwarding?

Yours,
Naveen.
--001a11405feed0a148053ae5c76a-- From nobody Thu Aug 25 08:40:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9A12D0E2 for ; Thu, 25 Aug 2016 08:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9y2IiHnrgpU for ; Thu, 25 Aug 2016 08:40:23 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1C312D838 for ; Thu, 25 Aug 2016 08:40:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7PFeGno060338; Thu, 25 Aug 2016 08:40:16 -0700 Received: from XCH15-05-03.nw.nos.boeing.com (xch15-05-03.nw.nos.boeing.com [137.137.100.66]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7PFe8GW060280 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 08:40:09 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-03.nw.nos.boeing.com (2002:8989:6442::8989:6442) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 25 Aug 2016 08:40:08 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 25 Aug 2016 08:40:08 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9tcrwwccPUlJiEK61fgu5QfdmKBKRsFggAFpOgCAA4768IABR9AAgAaWCcCAAsBxMA== Date: Thu, 25 Aug 2016 15:40:08 +0000 Message-ID: <6a75801ec93d416983a5a7e639f62c74@XCH15-05-05.nw.nos.boeing.com> References: <396f327690d24cfa8f519488bfc28bdd@XCH15-05-05.nw.nos.boeing.com> <44886625fa094c77a6999b0020f23095@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: <44886625fa094c77a6999b0020f23095@XCH15-05-05.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:40:25 -0000 Hi, Correcting myself from my last message: > > Summary: > > > > I am sympathetic to hosts requesting PD and then using it to assign its= elf > > addresses. I just think it would be cleaner if the weak host model was > > recommended and that the PD based addresses would only be configured on= a > > virtual interface in case only the WAN interface exists. >=20 > Some hosts may need to see ip_forwarding set to '1' if the addresses > are assigned to a virtual interface (e.g., a loopback) instead of the > WAN interface. Also, the MTU of the virtual interface would need > to be somehow matched to the MTU of the WAN interface in order > for TCP to correctly set its initial MSS, and that may be cumbersome > in some cases. I tested, and it works fine if the addresses are assigned to a loopback (weak ES), and there is no need to set ip_forwarding. Also, applications see the WAN interface as the outgoing interface so I do not believe there are any MTU issues. What I observed is that an IPv6 address assigned to the WAN interface is preferred if there is also an IPv6 address assigned to the loopback interface. When there is no IPv6 address on the WAN interface, then the loopback IPv6 address is used. So, either or both address assignment methods will work. But, I do not think we need to say which is preferred. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Tuesday, August 23, 2016 3:15 PM > To: Mikael Abrahamsson > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 >=20 > Hi Mikael, >=20 > Thank you for taking the time to review the document. Please see below > for follow-ups: >=20 > > -----Original Message----- > > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > Sent: Friday, August 19, 2016 2:54 AM > > To: Templin, Fred L > > Cc: IPv6 Ops WG > > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 > > > > On Thu, 18 Aug 2016, Templin, Fred L wrote: > > > > > Hello, > > > > > > A new version of this draft is now available based on review comments= received. > > > The comments have greatly improved the document, which now also inclu= des > > > figures that clearly illustrate the concepts described: > > > > > > https://www.ietf.org/id/draft-templin-v6ops-pdhost-04.txt > > > > Re-reading as if I never read it before: > > > > 1. Intro > > > > " Hosts > > 'Hn' on a LAN interface subsequently receive addresses 'An' taken > > from 'P' via an address autoconfiguration service such as IPv6 > > Stateless Address Autoconfiguration (SLAAC) [RFC4862]." > > > > If A=3D1 is used, I'd avoid using the term "receive addresses". "alloca= te > > addresse(s) for themselves" or similar term is more appropriate to make > > sure the reader understands the distinction. >=20 > How does this sound as a rewrite: >=20 > "Hosts 'Hn' subsequently obtain one or more addresses 'An' for themselv= es > via an address autoconfiguration service such as IPv6 Stateless Addre= ss > Autoconfiguration (SLAAC) [RFC4862]." >=20 > > 4. > > > > "The node also configures a default > > route that points to a router on the WAN link." > > > > This sentence can in context confuse readers to believe that this defau= lt > > route is installed because of receiving a delegated prefix, when in fac= t > > this is done because the node received an RA. Right? >=20 > Default routes can be configured via manual config and/or from whatever > form of autoconfiguration is appropriate for the link - of which RA is ju= st > one example. But, maybe it would be best to simply remove this sentence > and remain silent on the subject of default routes? >=20 > > 5. MLD/DAD Implications > > > > This is confusing. The node still has a LL which it needs to perform > > MLD/DAD for on the WAN interface, correct? >=20 > No, it is the same for LL's if DupAddrDetectTransmits is 0 - no DAD/MLD. >=20 > > Wouldn't it be better to just > > recommend not to put the delegated prefix addresses on the WAN interfac= e > > at all, but exlusively use a virtual interface? On that virtual interfa= ce > > then MLD/DAD can be turned off. Otherwise the WAN interface needs to > > selectively support DAD/MLD for some addresses configured on it, and no= t > > for others. >=20 > The document is referring to the case where no DAD/MLD is needed for any > addresses assigned to the interface -including LL, GUA, etc. >=20 > > 6. > > > > Is the third paragraph really necessary? It describes no new > > functionality, the text seems to describe normal IPv6 operations. Seems= it > > would only confuse the reader? >=20 > I don't mind removing the paragraph. But, in that case, I would still wan= t > to cite I-D.templin-aerolink as an example link where this is useful. >=20 > > 7. > > > > This paragraph would be simpler if we just avoid configuring the PD bas= ed > > addresses on the WAN interface. > > > > Summary: > > > > I am sympathetic to hosts requesting PD and then using it to assign its= elf > > addresses. I just think it would be cleaner if the weak host model was > > recommended and that the PD based addresses would only be configured on= a > > virtual interface in case only the WAN interface exists. >=20 > Some hosts may need to see ip_forwarding set to '1' if the addresses > are assigned to a virtual interface (e.g., a loopback) instead of the > WAN interface. Also, the MTU of the virtual interface would need > to be somehow matched to the MTU of the WAN interface in order > for TCP to correctly set its initial MSS, and that may be cumbersome > in some cases. >=20 > So, in my experience it is cleaner to assign the addresses to the WAN > interface. I am currently doing this on Androids using AERO, and the > applications seem to like it. >=20 > > Also, calling it "WAN" interface is a bit confusing. What is a "WAN" > > interface on a host? I have no better suggestion for what to call it, W= AN > > is short and "sweet" and using other names might just cause more > > confusion. The draft outlines what it means by WAN interface (good that > > you added the drawings) so it should be ok. >=20 > OK. >=20 > > The draft is DHCPv6 heavy and SLAAC light when it comes to text, it see= ms > > to talk more about DHCPv6 functions and glosses over things that are > > configured because of RAs etc. For someone not familiar with IPv6, they > > might draw the wrong conclusions on how IPv6 works regarding RA/DHCP > > interaction and what causes what. Perhaps there should be some more > > pointers to this, and if the text is DHCP verbose, then I think it need= s > > to be equally verbose on SLAAC/RA. >=20 > DHCPv6 PD is cited only as an example in the first paragraph of Section 1= . > Any other prefix delegation method is also in-scope. Other methods > include manual configuration, and any other prefix delegation method > that may one day be specified. >=20 > If you have specific examples of where the text seems to be inferring > DHCPv6 PD, I would be happy to make the text more generic so that > it is clear that DHCPv6 PD is only an example. >=20 > Thanks - Fred > fred.l.templin@oboeing.com >=20 > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 25 09:13:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE7712D1D8 for ; Thu, 25 Aug 2016 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_jd_OIeyARk for ; Thu, 25 Aug 2016 09:13:04 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DDB12D603 for ; Thu, 25 Aug 2016 09:13:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7PGD3WA051341; Thu, 25 Aug 2016 09:13:03 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7PGD1oH051329 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 09:13:02 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 25 Aug 2016 09:13:01 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 25 Aug 2016 09:13:01 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9tcrwwccPUlJiEK61fgu5QfdmKBKRsFggAFpOgCAA4768IABR9AAgAaWCcCAAsBxMIAAC+lA Date: Thu, 25 Aug 2016 16:13:01 +0000 Message-ID: <4eacfed4a9ef44b69f5b411f4b1d7318@XCH15-05-05.nw.nos.boeing.com> References: <396f327690d24cfa8f519488bfc28bdd@XCH15-05-05.nw.nos.boeing.com> <44886625fa094c77a6999b0020f23095@XCH15-05-05.nw.nos.boeing.com> <6a75801ec93d416983a5a7e639f62c74@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: <6a75801ec93d416983a5a7e639f62c74@XCH15-05-05.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 16:13:06 -0000 > I tested, and it works fine if the addresses are assigned to a loopback > (weak ES), and there is no need to set ip_forwarding. Also, applications > see the WAN interface as the outgoing interface so I do not believe > there are any MTU issues. FYI, testing was on Ubuntu linux. I have not tested on other systems. Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Thursday, August 25, 2016 8:40 AM > To: Mikael Abrahamsson > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 >=20 > Hi, >=20 > Correcting myself from my last message: >=20 > > > Summary: > > > > > > I am sympathetic to hosts requesting PD and then using it to assign i= tself > > > addresses. I just think it would be cleaner if the weak host model wa= s > > > recommended and that the PD based addresses would only be configured = on a > > > virtual interface in case only the WAN interface exists. > > > > Some hosts may need to see ip_forwarding set to '1' if the addresses > > are assigned to a virtual interface (e.g., a loopback) instead of the > > WAN interface. Also, the MTU of the virtual interface would need > > to be somehow matched to the MTU of the WAN interface in order > > for TCP to correctly set its initial MSS, and that may be cumbersome > > in some cases. >=20 > I tested, and it works fine if the addresses are assigned to a loopback > (weak ES), and there is no need to set ip_forwarding. Also, applications > see the WAN interface as the outgoing interface so I do not believe > there are any MTU issues. >=20 > What I observed is that an IPv6 address assigned to the WAN interface > is preferred if there is also an IPv6 address assigned to the loopback > interface. When there is no IPv6 address on the WAN interface, then > the loopback IPv6 address is used. >=20 > So, either or both address assignment methods will work. But, I do > not think we need to say which is preferred. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >=20 > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred = L > > Sent: Tuesday, August 23, 2016 3:15 PM > > To: Mikael Abrahamsson > > Cc: IPv6 Ops WG > > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 > > > > Hi Mikael, > > > > Thank you for taking the time to review the document. Please see below > > for follow-ups: > > > > > -----Original Message----- > > > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > > Sent: Friday, August 19, 2016 2:54 AM > > > To: Templin, Fred L > > > Cc: IPv6 Ops WG > > > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 > > > > > > On Thu, 18 Aug 2016, Templin, Fred L wrote: > > > > > > > Hello, > > > > > > > > A new version of this draft is now available based on review commen= ts received. > > > > The comments have greatly improved the document, which now also inc= ludes > > > > figures that clearly illustrate the concepts described: > > > > > > > > https://www.ietf.org/id/draft-templin-v6ops-pdhost-04.txt > > > > > > Re-reading as if I never read it before: > > > > > > 1. Intro > > > > > > " Hosts > > > 'Hn' on a LAN interface subsequently receive addresses 'An' taken > > > from 'P' via an address autoconfiguration service such as IPv6 > > > Stateless Address Autoconfiguration (SLAAC) [RFC4862]." > > > > > > If A=3D1 is used, I'd avoid using the term "receive addresses". "allo= cate > > > addresse(s) for themselves" or similar term is more appropriate to ma= ke > > > sure the reader understands the distinction. > > > > How does this sound as a rewrite: > > > > "Hosts 'Hn' subsequently obtain one or more addresses 'An' for themse= lves > > via an address autoconfiguration service such as IPv6 Stateless Add= ress > > Autoconfiguration (SLAAC) [RFC4862]." > > > > > 4. > > > > > > "The node also configures a default > > > route that points to a router on the WAN link." > > > > > > This sentence can in context confuse readers to believe that this def= ault > > > route is installed because of receiving a delegated prefix, when in f= act > > > this is done because the node received an RA. Right? > > > > Default routes can be configured via manual config and/or from whatever > > form of autoconfiguration is appropriate for the link - of which RA is = just > > one example. But, maybe it would be best to simply remove this sentence > > and remain silent on the subject of default routes? > > > > > 5. MLD/DAD Implications > > > > > > This is confusing. The node still has a LL which it needs to perform > > > MLD/DAD for on the WAN interface, correct? > > > > No, it is the same for LL's if DupAddrDetectTransmits is 0 - no DAD/MLD= . > > > > > Wouldn't it be better to just > > > recommend not to put the delegated prefix addresses on the WAN interf= ace > > > at all, but exlusively use a virtual interface? On that virtual inter= face > > > then MLD/DAD can be turned off. Otherwise the WAN interface needs to > > > selectively support DAD/MLD for some addresses configured on it, and = not > > > for others. > > > > The document is referring to the case where no DAD/MLD is needed for an= y > > addresses assigned to the interface -including LL, GUA, etc. > > > > > 6. > > > > > > Is the third paragraph really necessary? It describes no new > > > functionality, the text seems to describe normal IPv6 operations. See= ms it > > > would only confuse the reader? > > > > I don't mind removing the paragraph. But, in that case, I would still w= ant > > to cite I-D.templin-aerolink as an example link where this is useful. > > > > > 7. > > > > > > This paragraph would be simpler if we just avoid configuring the PD b= ased > > > addresses on the WAN interface. > > > > > > Summary: > > > > > > I am sympathetic to hosts requesting PD and then using it to assign i= tself > > > addresses. I just think it would be cleaner if the weak host model wa= s > > > recommended and that the PD based addresses would only be configured = on a > > > virtual interface in case only the WAN interface exists. > > > > Some hosts may need to see ip_forwarding set to '1' if the addresses > > are assigned to a virtual interface (e.g., a loopback) instead of the > > WAN interface. Also, the MTU of the virtual interface would need > > to be somehow matched to the MTU of the WAN interface in order > > for TCP to correctly set its initial MSS, and that may be cumbersome > > in some cases. > > > > So, in my experience it is cleaner to assign the addresses to the WAN > > interface. I am currently doing this on Androids using AERO, and the > > applications seem to like it. > > > > > Also, calling it "WAN" interface is a bit confusing. What is a "WAN" > > > interface on a host? I have no better suggestion for what to call it,= WAN > > > is short and "sweet" and using other names might just cause more > > > confusion. The draft outlines what it means by WAN interface (good th= at > > > you added the drawings) so it should be ok. > > > > OK. > > > > > The draft is DHCPv6 heavy and SLAAC light when it comes to text, it s= eems > > > to talk more about DHCPv6 functions and glosses over things that are > > > configured because of RAs etc. For someone not familiar with IPv6, th= ey > > > might draw the wrong conclusions on how IPv6 works regarding RA/DHCP > > > interaction and what causes what. Perhaps there should be some more > > > pointers to this, and if the text is DHCP verbose, then I think it ne= eds > > > to be equally verbose on SLAAC/RA. > > > > DHCPv6 PD is cited only as an example in the first paragraph of Section= 1. > > Any other prefix delegation method is also in-scope. Other methods > > include manual configuration, and any other prefix delegation method > > that may one day be specified. > > > > If you have specific examples of where the text seems to be inferring > > DHCPv6 PD, I would be happy to make the text more generic so that > > it is clear that DHCPv6 PD is only an example. > > > > Thanks - Fred > > fred.l.templin@oboeing.com > > > > > -- > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 25 10:09:52 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA6012D18D for ; Thu, 25 Aug 2016 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBej106RbP_f for ; Thu, 25 Aug 2016 10:09:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB88F12B03A for ; Thu, 25 Aug 2016 10:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4729; q=dns/txt; s=iport; t=1472144989; x=1473354589; h=from:to:cc:subject:date:message-id:mime-version; bh=Ua52dmq9qM4/9pANRPQgNakJAD2UPYO27JEXqdd4MDk=; b=cKJRlT7HM0RW9bsJP7VgeWjij4NzosJGS8NprsSh1OZ0fvZu3bUOOGdl atBD47dqHhFaN0+Etsq/ylAT2CZG23bWNJyKRjXmDfrUVoEWn2InmRyHr cE1R4y3pyvUc2pDMuJwD7vQB25yorREQ43W5HcZ6HQGYnvO6aEiEfuSEE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAgDLJb9X/5BdJa1dgnYzAQEBAQEeg?= =?us-ascii?q?VKzFYUIgXyGHR6BPzgUAgEBAQEBAQFeJ4RiAQUjCkwSAQgEFCoCBDAnBA4FCIg?= =?us-ascii?q?qr3uPZwEBAQEBAQEBAQEBAQEBAQEBAQEeinuEV4JrgloFmUoBjx6BdIRdiQeMQ?= =?us-ascii?q?YN4AR42g31whwEBAQE?= X-IronPort-AV: E=Sophos;i="5.28,576,1464652800"; d="scan'208,217";a="139543679" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2016 17:09:49 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7PH9mDF000991 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Aug 2016 17:09:49 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 25 Aug 2016 12:09:48 -0500 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1210.000; Thu, 25 Aug 2016 12:09:48 -0500 From: "Toerless Eckert (eckert)" To: Gert Doering Thread-Topic: [v6ops] Letting apps select outbound path Thread-Index: AQHR/vN74EgLbgOeeUeyFGixGGkrgg== Date: Thu, 25 Aug 2016 17:09:48 +0000 Message-ID: <35d712d0db5b4336ac832468a956f0f9@XCH-RCD-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_35d712d0db5b4336ac832468a956f0f9XCHRCD003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 17:09:51 -0000 --_000_35d712d0db5b4336ac832468a956f0f9XCHRCD003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IGEgY29tcGxpY2F0aW9uLiBKdXN0IGFub3RoZXIgZXhhbXBsZSB3aGVyZSB0aGUgaG9zdCBp cyBtZWFudCB0byBtYWtlIHRoZSBkZWNpc2lvbiBhY2NvcmRpbmcgdG8gSVAgYXJjaC4gVHJ5aW5n IHRvIHVuZGVyc3RhbmQgd2hhdCBmdWxseSBjb250cm9sbGVkIHdvdWxkIG1lYW4gdG8geW91IGlu IHRoYXQgY2FzZS4NCg0KdHlwb3MgPSBzbWFydHBob25lDQoNCk9uIEp1bCAyMSwgMjAxNiAxMDox NSBQTSwgR2VydCBEb2VyaW5nIDxnZXJ0QHNwYWNlLm5ldD4gd3JvdGU6DQpIaSwNCg0KT24gVGh1 LCBKdWwgMjEsIDIwMTYgYXQgMDg6MDA6MTZQTSArMDAwMCwgVG9lcmxlc3MgRWNrZXJ0IChlY2tl cnQpIHdyb3RlOg0KPiBIb3N0IGhhcyAyIGFkZHJlc3NlcyA9PSBjb25maWd1cmVkIHBvbGljeS4N Cj4NCj4gSWYgeW91ciB3aGVyZSBhbiBlbnRlcnByaXNlIGFuZCB5b3VyIFNQIHJlY29tbWVuZGVk IHlvdSB0byBzZXQgZHNjcCBmb3IgdHJhZmZpYyBhY2NvcmRpbmcgdG8gdGhlIGFwcCByZXF1aXJl bWVudHMgdG8gZ2V0IGJlc3QgcmVzdWx0cy4gSG93IHdvdWxkIHlvdSBkbyB0aGF0ID8NCg0KUGxl YXNlIGRvIG5vdCBtaXggaW4gYXJiaXRyYXJ5IGNvbXBsaWNhdGlvbnMuICBUaGlzIHdhcyBhYm91 dCBhZGRyZXNzDQpzZWxlY3Rpb24sIGFuZCBhZGRyZXNzIHNlbGVjdGlvbiBpbmZsdWVuY2luZyBJ U1Agc2VsZWN0aW9uLg0KDQpHZXJ0IERvZXJpbmcNCiAgICAgICAgLS0gTmV0TWFzdGVyDQotLQ0K aGF2ZSB5b3UgZW5hYmxlZCBJUHY2IG9uIHNvbWV0aGluZyB0b2RheS4uLj8NCg0KU3BhY2VOZXQg QUcgICAgICAgICAgICAgICAgICAgICAgICBWb3JzdGFuZDogU2ViYXN0aWFuIHYuIEJvbWhhcmQN Ckpvc2VwaC1Eb2xsaW5nZXItQm9nZW4gMTQgICAgICAgICAgQXVmc2ljaHRzcmF0c3ZvcnMuOiBB LiBHcnVuZG5lci1DdWxlbWFubg0KRC04MDgwNyBNdWVuY2hlbiAgICAgICAgICAgICAgICAgICBI UkI6IDEzNjA1NSAoQUcgTXVlbmNoZW4pDQpUZWw6ICs0OSAoMCk4OS8zMjM1Ni00NDQgICAgICAg ICAgIFVTdC1JZE5yLjogREU4MTMxODUyNzkNCg== --_000_35d712d0db5b4336ac832468a956f0f9XCHRCD003ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pk5vdCBhIGNvbXBsaWNhdGlvbi4gSnVzdCBhbm90aGVyIGV4YW1wbGUgd2hlcmUgdGhlIGhvc3Qg aXMgbWVhbnQgdG8gbWFrZSB0aGUgZGVjaXNpb24gYWNjb3JkaW5nIHRvIElQIGFyY2guIFRyeWlu ZyB0byB1bmRlcnN0YW5kIHdoYXQgZnVsbHkgY29udHJvbGxlZCB3b3VsZCBtZWFuIHRvIHlvdSBp biB0aGF0IGNhc2UuPGJyPg0KPC9wPg0KPHAgZGlyPSJsdHIiPnR5cG9zID0gc21hcnRwaG9uZTwv cD4NCjxkaXYgY2xhc3M9InF1b3RlIj5PbiBKdWwgMjEsIDIwMTYgMTA6MTUgUE0sIEdlcnQgRG9l cmluZyAmbHQ7Z2VydEBzcGFjZS5uZXQmZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+ DQo8YmxvY2txdW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxtZXRhIG5hbWU9Ikdl bmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZl cnRlZCBmcm9tIHRleHQgLS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDog MXB0OyBwYWRkaW5nLWxlZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9 IC0tPjwvc3R5bGU+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+ DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPkhpLDxicj4NCjxicj4NCk9uIFRodSwgSnVsIDIxLCAy MDE2IGF0IDA4OjAwOjE2UE0gJiM0MzswMDAwLCBUb2VybGVzcyBFY2tlcnQgKGVja2VydCkgd3Jv dGU6PGJyPg0KJmd0OyBIb3N0IGhhcyAyIGFkZHJlc3NlcyA9PSBjb25maWd1cmVkIHBvbGljeS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgeW91ciB3aGVyZSBhbiBlbnRlcnByaXNlIGFuZCB5b3Vy IFNQIHJlY29tbWVuZGVkIHlvdSB0byBzZXQgZHNjcCBmb3IgdHJhZmZpYyBhY2NvcmRpbmcgdG8g dGhlIGFwcCByZXF1aXJlbWVudHMgdG8gZ2V0IGJlc3QgcmVzdWx0cy4gSG93IHdvdWxkIHlvdSBk byB0aGF0ID88YnI+DQo8YnI+DQpQbGVhc2UgZG8gbm90IG1peCBpbiBhcmJpdHJhcnkgY29tcGxp Y2F0aW9ucy4mbmJzcDsgVGhpcyB3YXMgYWJvdXQgYWRkcmVzczxicj4NCnNlbGVjdGlvbiwgYW5k IGFkZHJlc3Mgc2VsZWN0aW9uIGluZmx1ZW5jaW5nIElTUCBzZWxlY3Rpb24uPGJyPg0KPGJyPg0K R2VydCBEb2VyaW5nPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE5ldE1hc3Rlcjxicj4NCi0tIDxicj4NCmhhdmUgeW91IGVuYWJsZWQgSVB2NiBvbiBz b21ldGhpbmcgdG9kYXkuLi4/PGJyPg0KPGJyPg0KU3BhY2VOZXQgQUcmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVm9yc3RhbmQ6IFNlYmFzdGlhbiB2LiBCb21oYXJkPGJyPg0KSm9zZXBoLURvbGxp bmdlci1Cb2dlbiAxNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBdWZzaWNodHNyYXRzdm9ycy46IEEuIEdydW5kbmVyLUN1bGVtYW5uPGJyPg0K RC04MDgwNyBNdWVuY2hlbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBIUkI6IDEzNjA1NSAoQUcgTXVlbmNoZW4pPGJyPg0KVGVsOiAmIzQzOzQ5ICgw KTg5LzMyMzU2LTQ0NCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBVU3QtSWROci46IERFODEzMTg1Mjc5PGJyPg0KPC9kaXY+DQo8L3Nw YW4+PC9mb250PjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_35d712d0db5b4336ac832468a956f0f9XCHRCD003ciscocom_-- From nobody Thu Aug 25 16:15:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D632D12D664 for ; Thu, 25 Aug 2016 16:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBmuiL08PCjm for ; Thu, 25 Aug 2016 16:15:06 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2153312D649 for ; Thu, 25 Aug 2016 16:15:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7PNF5pp039929; Thu, 25 Aug 2016 16:15:05 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7PNF02d039762 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 16:15:00 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 25 Aug 2016 16:14:59 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 25 Aug 2016 16:15:00 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson Thread-Topic: [v6ops] Review draft-templin-v6ops-pdhost-02 Thread-Index: AQHR9tcrwwccPUlJiEK61fgu5QfdmKBKRsFggAFpOgCAA4768IABR9AAgAaWCcCAAsBxMIAAC+lAgABz2FA= Date: Thu, 25 Aug 2016 23:15:00 +0000 Message-ID: References: <396f327690d24cfa8f519488bfc28bdd@XCH15-05-05.nw.nos.boeing.com> <44886625fa094c77a6999b0020f23095@XCH15-05-05.nw.nos.boeing.com> <6a75801ec93d416983a5a7e639f62c74@XCH15-05-05.nw.nos.boeing.com> <4eacfed4a9ef44b69f5b411f4b1d7318@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: <4eacfed4a9ef44b69f5b411f4b1d7318@XCH15-05-05.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 23:15:12 -0000 Hi - I tested on Android and found the following: > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Thursday, August 25, 2016 9:13 AM > To: Mikael Abrahamsson > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 >=20 > > I tested, and it works fine if the addresses are assigned to a loopback > > (weak ES), and there is no need to set ip_forwarding. Also, applicatio= ns > > see the WAN interface as the outgoing interface so I do not believe > > there are any MTU issues. >=20 > FYI, testing was on Ubuntu linux. I have not tested on other systems. Assignment of IPv6 addresses to loopback interfaces is not allowed on non-rooted Android devices. However, IPv6 addresses can be assigned to VPN interfaces where the VPN interface is seen as the "WAN" interface. So, for Android at least, assignment to the WAN interface seems to be the only option. Thanks - Fred fred.l.templin@boeing.com > Thanks - Fred >=20 > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred = L > > Sent: Thursday, August 25, 2016 8:40 AM > > To: Mikael Abrahamsson > > Cc: IPv6 Ops WG > > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 > > > > Hi, > > > > Correcting myself from my last message: > > > > > > Summary: > > > > > > > > I am sympathetic to hosts requesting PD and then using it to assign= itself > > > > addresses. I just think it would be cleaner if the weak host model = was > > > > recommended and that the PD based addresses would only be configure= d on a > > > > virtual interface in case only the WAN interface exists. > > > > > > Some hosts may need to see ip_forwarding set to '1' if the addresses > > > are assigned to a virtual interface (e.g., a loopback) instead of the > > > WAN interface. Also, the MTU of the virtual interface would need > > > to be somehow matched to the MTU of the WAN interface in order > > > for TCP to correctly set its initial MSS, and that may be cumbersome > > > in some cases. > > > > I tested, and it works fine if the addresses are assigned to a loopback > > (weak ES), and there is no need to set ip_forwarding. Also, applicatio= ns > > see the WAN interface as the outgoing interface so I do not believe > > there are any MTU issues. > > > > What I observed is that an IPv6 address assigned to the WAN interface > > is preferred if there is also an IPv6 address assigned to the loopback > > interface. When there is no IPv6 address on the WAN interface, then > > the loopback IPv6 address is used. > > > > So, either or both address assignment methods will work. But, I do > > not think we need to say which is preferred. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fre= d L > > > Sent: Tuesday, August 23, 2016 3:15 PM > > > To: Mikael Abrahamsson > > > Cc: IPv6 Ops WG > > > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 > > > > > > Hi Mikael, > > > > > > Thank you for taking the time to review the document. Please see belo= w > > > for follow-ups: > > > > > > > -----Original Message----- > > > > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > > > Sent: Friday, August 19, 2016 2:54 AM > > > > To: Templin, Fred L > > > > Cc: IPv6 Ops WG > > > > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 > > > > > > > > On Thu, 18 Aug 2016, Templin, Fred L wrote: > > > > > > > > > Hello, > > > > > > > > > > A new version of this draft is now available based on review comm= ents received. > > > > > The comments have greatly improved the document, which now also i= ncludes > > > > > figures that clearly illustrate the concepts described: > > > > > > > > > > https://www.ietf.org/id/draft-templin-v6ops-pdhost-04.txt > > > > > > > > Re-reading as if I never read it before: > > > > > > > > 1. Intro > > > > > > > > " Hosts > > > > 'Hn' on a LAN interface subsequently receive addresses 'An' tak= en > > > > from 'P' via an address autoconfiguration service such as IPv6 > > > > Stateless Address Autoconfiguration (SLAAC) [RFC4862]." > > > > > > > > If A=3D1 is used, I'd avoid using the term "receive addresses". "al= locate > > > > addresse(s) for themselves" or similar term is more appropriate to = make > > > > sure the reader understands the distinction. > > > > > > How does this sound as a rewrite: > > > > > > "Hosts 'Hn' subsequently obtain one or more addresses 'An' for them= selves > > > via an address autoconfiguration service such as IPv6 Stateless A= ddress > > > Autoconfiguration (SLAAC) [RFC4862]." > > > > > > > 4. > > > > > > > > "The node also configures a default > > > > route that points to a router on the WAN link." > > > > > > > > This sentence can in context confuse readers to believe that this d= efault > > > > route is installed because of receiving a delegated prefix, when in= fact > > > > this is done because the node received an RA. Right? > > > > > > Default routes can be configured via manual config and/or from whatev= er > > > form of autoconfiguration is appropriate for the link - of which RA i= s just > > > one example. But, maybe it would be best to simply remove this senten= ce > > > and remain silent on the subject of default routes? > > > > > > > 5. MLD/DAD Implications > > > > > > > > This is confusing. The node still has a LL which it needs to perfor= m > > > > MLD/DAD for on the WAN interface, correct? > > > > > > No, it is the same for LL's if DupAddrDetectTransmits is 0 - no DAD/M= LD. > > > > > > > Wouldn't it be better to just > > > > recommend not to put the delegated prefix addresses on the WAN inte= rface > > > > at all, but exlusively use a virtual interface? On that virtual int= erface > > > > then MLD/DAD can be turned off. Otherwise the WAN interface needs t= o > > > > selectively support DAD/MLD for some addresses configured on it, an= d not > > > > for others. > > > > > > The document is referring to the case where no DAD/MLD is needed for = any > > > addresses assigned to the interface -including LL, GUA, etc. > > > > > > > 6. > > > > > > > > Is the third paragraph really necessary? It describes no new > > > > functionality, the text seems to describe normal IPv6 operations. S= eems it > > > > would only confuse the reader? > > > > > > I don't mind removing the paragraph. But, in that case, I would still= want > > > to cite I-D.templin-aerolink as an example link where this is useful. > > > > > > > 7. > > > > > > > > This paragraph would be simpler if we just avoid configuring the PD= based > > > > addresses on the WAN interface. > > > > > > > > Summary: > > > > > > > > I am sympathetic to hosts requesting PD and then using it to assign= itself > > > > addresses. I just think it would be cleaner if the weak host model = was > > > > recommended and that the PD based addresses would only be configure= d on a > > > > virtual interface in case only the WAN interface exists. > > > > > > Some hosts may need to see ip_forwarding set to '1' if the addresses > > > are assigned to a virtual interface (e.g., a loopback) instead of the > > > WAN interface. Also, the MTU of the virtual interface would need > > > to be somehow matched to the MTU of the WAN interface in order > > > for TCP to correctly set its initial MSS, and that may be cumbersome > > > in some cases. > > > > > > So, in my experience it is cleaner to assign the addresses to the WAN > > > interface. I am currently doing this on Androids using AERO, and the > > > applications seem to like it. > > > > > > > Also, calling it "WAN" interface is a bit confusing. What is a "WAN= " > > > > interface on a host? I have no better suggestion for what to call i= t, WAN > > > > is short and "sweet" and using other names might just cause more > > > > confusion. The draft outlines what it means by WAN interface (good = that > > > > you added the drawings) so it should be ok. > > > > > > OK. > > > > > > > The draft is DHCPv6 heavy and SLAAC light when it comes to text, it= seems > > > > to talk more about DHCPv6 functions and glosses over things that ar= e > > > > configured because of RAs etc. For someone not familiar with IPv6, = they > > > > might draw the wrong conclusions on how IPv6 works regarding RA/DHC= P > > > > interaction and what causes what. Perhaps there should be some more > > > > pointers to this, and if the text is DHCP verbose, then I think it = needs > > > > to be equally verbose on SLAAC/RA. > > > > > > DHCPv6 PD is cited only as an example in the first paragraph of Secti= on 1. > > > Any other prefix delegation method is also in-scope. Other methods > > > include manual configuration, and any other prefix delegation method > > > that may one day be specified. > > > > > > If you have specific examples of where the text seems to be inferring > > > DHCPv6 PD, I would be happy to make the text more generic so that > > > it is clear that DHCPv6 PD is only an example. > > > > > > Thanks - Fred > > > fred.l.templin@oboeing.com > > > > > > > -- > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 25 19:06:52 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B93A12D0AF for ; Thu, 25 Aug 2016 19:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_gOtZLAAC8T for ; Thu, 25 Aug 2016 19:06:46 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0493812D0E3 for ; Thu, 25 Aug 2016 19:06:44 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f65so260193771wmi.0 for ; Thu, 25 Aug 2016 19:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bf7NiAqFFBmbAYzkfntTRtSlDwAgvCUJkCSqvNy+X8o=; b=bWrtOvfVvsnJ4iDrmeoTHxwkirMExDhYS7XMFd/+pxsfHo8uugj5uA3ue8e9CQw9/n PKgKY5wXZ/L16vB5QkouoCxwkuGjt4Jt/yDo3+qZY6Oe5xImzJgG0RJQigfH6MWc/wjz mFMKQ9Xb/XVoGSPyAwyWyPXX/XGgnmwZ845wOjEh8cG3xz9CMWLH6lnx2arY+b8hShQG P0TlDTFwqTP9opw4UoQTCayRpn4r3bcioEWPcrGrYOMsChHuEX2q9EC7/pDSYJHDTBZj zgEaIfIDGWhAKffQUz+tGxJzZkPu+zGqspS+MWrTno3Bt3RjioDUlnQ5OH5umQCHu/QP m7KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bf7NiAqFFBmbAYzkfntTRtSlDwAgvCUJkCSqvNy+X8o=; b=BnE9jslMF6BWoSt0hgX+07iCpTmVRijumjUsAUoogf7FnksPO0llTHhFeQseRo1WrD nlI6RMLs1PM5/ga5yh81yBdN5SPWNcbz9ZV81ZB7VTRtIQ+qEGzPlBy9E88fOQNxntPn gxkZOIaIYXRbb2KZwIG3QKc/H+M7DrWhBL7dlWyk/SEo7lRxYEbJv+7J2cI4VyuNJCEh 3cjyfvSZ0k3/gDhyPlxkNAsOq5TBpGz43KqK+wDPOXVbLHd8wlMgEihFBmYWfWCVN8Uo S+8Hvy4ujn+9Ax6SxCLSfZ3t0F0qIXkmzEt4WYgeNTEHjxMY3mMt89/E094Y/MTMR7di yF3A== X-Gm-Message-State: AE9vXwP3N88CYiH3VbWo6dWhVBtqPy2b2dOKnoAk/hPrIIbSbN2M+md2Roi8UEtWSfemygJfYkiHlu9isT2vDKmn X-Received: by 10.28.113.135 with SMTP id d7mr658179wmi.43.1472177203341; Thu, 25 Aug 2016 19:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.157.2 with HTTP; Thu, 25 Aug 2016 19:06:22 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Fri, 26 Aug 2016 11:06:22 +0900 Message-ID: To: Naveen Kottapalli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] v6 gateway data forwarding behaviour X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 02:06:47 -0000 On 25 August 2016 at 22:57, Naveen Kottapalli wrote: > Hello, > > Assuming that the node is given a prefix in RA by the gateway, does the > gateway need to know the complete address being used by node for data > forwarding? If the RA PIO is 2001:db8:1:2::/64 and the gateway receives a packet destined to 2001:db8:1:2::f00 which is not in its neighbor cache it should attempt Neighbor Discovery to find out where to send the packet. Did you have some more exotic network configuration in mind? From nobody Thu Aug 25 20:46:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596CE12D09A; Thu, 25 Aug 2016 20:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo39tgMeuEkp; Thu, 25 Aug 2016 20:46:02 -0700 (PDT) Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id C4E80127071; Thu, 25 Aug 2016 20:45:59 -0700 (PDT) Authentication-Results: smtp2.au.logicalis.com; spf=None smtp.mailfrom=gdaley@au.logicalis.com; spf=None smtp.helo=postmaster@sdcexchht.au.logicalis.com Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=10.18.196.63; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=10.18.196.63; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([10.18.196.63]) by smtp2.au.logicalis.com with ESMTP; 26 Aug 2016 13:45:42 +1000 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([100.64.20.45]) with mapi id 14.03.0279.002; Fri, 26 Aug 2016 13:45:41 +1000 From: Greg Daley To: Naveen Kottapalli Thread-Topic: v6 gateway data forwarding behaviour Thread-Index: AQHR/tjxjRRBpo+F80OHYqRfAvn6zaBamvCe Date: Fri, 26 Aug 2016 03:45:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] v6 gateway data forwarding behaviour X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 03:46:06 -0000 Hi Naveen, Not for reception from the local link. The router only needs ip address to = MAC mapping to deliver packets to devices on link (associated with the pref= ix) This is why it is called a neighbour cache, not a neighbour table Sincerely, Greg Daley Logicalis Australia Pty Ltd E gdaley@au.logicalis.com M +61 401 772 770 On Aug 25, 2016, at 11:59 PM, Naveen Kottapalli wr= ote: Hello, Assuming that the node is given a prefix in RA by the gateway, does the gat= eway need to know the complete address being used by node for data forwardi= ng? Yours, Naveen. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Fri Aug 26 01:00:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ED712D10C; Fri, 26 Aug 2016 01:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZhlRPiDqKeg; Fri, 26 Aug 2016 01:00:47 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D737A127077; Fri, 26 Aug 2016 01:00:46 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id e63so318283902ith.1; Fri, 26 Aug 2016 01:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k+HVP/f0C4w5lKGJxvEgyzvFufpsZMRoVciwGgyUBnk=; b=MZ2ctDYfRxYdeuJkqJyWKozzlNcCFggRC9httnjWKs4RLHWBboKlAzrhUf7IVJChkc j3KNu/DGToeQ6tUP+iqi8KtS/XtyQNdMQ+Jj5clMiYHP63TxAVI8I1G3ZdX69owgCiiX rwHrXKbtHp5Huv9k0BD+W4hjFkKz77UIbzIuW8TTSsryE9Xlz2+tsPVv7nHpBlWdhPgG lUpc11xooseiRyN0OYbLz7Cd8lQEuivm+kWf89qZGW5UH2u435qJgAWDst4W8iPGwFVB f0P9seynLz7+ppzX8hyZQm8eaIL4bgkgCqLE75g4PFLfLBFdnEJllrZlKhhhp1p4tP40 yqSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k+HVP/f0C4w5lKGJxvEgyzvFufpsZMRoVciwGgyUBnk=; b=YqfXhP9DhCpESOLOPpRt7YM1/mDXTPC4YRWQI4vqy1YzVbmtxWIgoGpvLBbwyGa/a9 2ddowcLVt6E0g8Acjy6p/q82wm27Z5GUVU/V+ijoG4NK7u0uuqyqsPvHJeDXwMaLbeZ0 mavg/Aqi4UT/HRp5ukOkd8OhXjcnxYKHcg22BQA8em3H4b1Gin1g4tvEMq6ygSHjXXc5 ddZsN+kEopERRhY1GaUKiFQhQ0d25YaDSdwY3YfIe60GzCiYtvjkBlqhVtsLsQmP+jQl LsM7edTTHTScAfEBAOBy0UdSDinPZ/qICJiXZbFNzKlHnwkG3BC1Fe9LVPbTtDjUbO1W I2Og== X-Gm-Message-State: AE9vXwNSd51m0Vh8ZC6QW8oEEe7GAXuPYSCMlsCtQGyfm+khr2vjhHfE9n70Sc5B0KJggZWFyjSlvdh2WKaOrQ== X-Received: by 10.107.16.77 with SMTP id y74mr2221357ioi.161.1472198446203; Fri, 26 Aug 2016 01:00:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.209 with HTTP; Fri, 26 Aug 2016 01:00:25 -0700 (PDT) In-Reply-To: References: From: Naveen Kottapalli Date: Fri, 26 Aug 2016 13:30:25 +0530 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=001a113e811c6cc73f053af4e989 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] v6 gateway data forwarding behaviour X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 08:00:48 -0000 --001a113e811c6cc73f053af4e989 Content-Type: text/plain; charset=UTF-8 No, no special configuration is planned. I was wondering that for data forwarding does the router need to know the complete 128-bit address of the client after prefix assignment or not. Yours, Naveen. On 26 August 2016 at 07:36, Erik Kline wrote: > On 25 August 2016 at 22:57, Naveen Kottapalli > wrote: > > Hello, > > > > Assuming that the node is given a prefix in RA by the gateway, does the > > gateway need to know the complete address being used by node for data > > forwarding? > > If the RA PIO is 2001:db8:1:2::/64 and the gateway receives a packet > destined to 2001:db8:1:2::f00 which is not in its neighbor cache it > should attempt Neighbor Discovery to find out where to send the > packet. > > Did you have some more exotic network configuration in mind? > --001a113e811c6cc73f053af4e989 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, no special configuration is planned.=C2=A0 I was wonde= ring that for data forwarding does the router need to know the complete 128= -bit address of the client after prefix assignment or not.

Yours,
Naveen.

On 26 August 2016 at 07:36, Erik Kline <ek@goog= le.com> wrote:
On 25 August 2016 at 22:57, Naveen Kottapalli <naveen.sarma@gmail.com> wrote:
> Hello,
>
> Assuming that the node is given a prefix in RA by the gateway, does th= e
> gateway need to know the complete address being used by node for data<= br> > forwarding?

If the RA PIO is 2001:db8:1:2::/64 and the gateway receives a packet=
destined to 2001:db8:1:2::f00 which is not in its neighbor cache it
should attempt Neighbor Discovery to find out where to send the
packet.

Did you have some more exotic network configuration in mind?

--001a113e811c6cc73f053af4e989-- From nobody Fri Aug 26 01:07:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2D212D0E4; Fri, 26 Aug 2016 01:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePzyfYaAzCns; Fri, 26 Aug 2016 01:07:33 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787DD12D0DA; Fri, 26 Aug 2016 01:07:33 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id d65so13170420ith.0; Fri, 26 Aug 2016 01:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=esJHDANWqet66ToAPIcyMa8JiyCmLP4b3zTGxB1M3Ms=; b=D4SkE+6d3la3352BxyfRXnnhPoOEeXdeNi8HpC/uTv5kwRH6fY0Yt6L881lu6FDYNO /xwX5k0nKNmVReLekZ+YMpGObqCAiCkz19Z/aB+4DTU5WVb+couqpjesTuyNAnYzEBPO N22crFTq2SXp9YEAO+Ont1QZKjBS5A4PhA8T9VLQkeEHE+YKvfT6MZGn4AytOI+oZ2z2 LR1YU5RCdQJSVGMidqR/aT+JnBDbQczhfs7LilK3YP6G/YnlORtc3R49xE8jW+vBmt3V p37q6EuSk+tgaA+La1uUu1sAqr0zf5JmecEB8IZnLrWhGi/Tpcyohm5ixEkPWrta1YUy Mk4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=esJHDANWqet66ToAPIcyMa8JiyCmLP4b3zTGxB1M3Ms=; b=Kvix6FzfdqHjLsDl4GlWPJ5Iyq0mst7zjgEcG9OZKHbdfeT2zpEZJD4cCDhcV7PvXG MMEDqrzIX4m/4PbxU6q6tHoi2tFWdRlvb37vNk/hH0FHeA+tzLO9r2/zQvW41Hgfe8SC zVoXzvSKKwFMm1MmyZil5cGTm4p3QJeIu3fkd/t2bFk5S95JUSi1DeB5cJq9bF8YgmHa Sy0fxdyG6ctZysb6mYMJksVT8mjo/RQXUQFDL7wwMSwqNLWm5lMGxmGn/HtYtqul3fAq Buyw5gH/blWTZ10h0y2nxrt8XnkkdPZUSo6jaHGutW38mawphv0YffcP5CNwMXsbtSJN ZlLw== X-Gm-Message-State: AEkooutizyXDFd8mxeJ8+8W14AFmv3TWraitw9WRYXVP+hVzCrFPnp90gNhh9hldEZl9Y2vd5reVItwspjw52A== X-Received: by 10.36.95.202 with SMTP id r193mr10753393itb.48.1472198852862; Fri, 26 Aug 2016 01:07:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.209 with HTTP; Fri, 26 Aug 2016 01:07:12 -0700 (PDT) In-Reply-To: References: From: Naveen Kottapalli Date: Fri, 26 Aug 2016 13:37:12 +0530 Message-ID: To: Greg Daley Content-Type: multipart/alternative; boundary=001a1144c0d6a9ea74053af501b8 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] v6 gateway data forwarding behaviour X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 08:07:35 -0000 --001a1144c0d6a9ea74053af501b8 Content-Type: text/plain; charset=UTF-8 Thanks Greg! Yours, Naveen. On 26 August 2016 at 09:15, Greg Daley wrote: > Hi Naveen, > > Not for reception from the local link. The router only needs ip address to > MAC mapping to deliver packets to devices on link (associated with the > prefix) > > This is why it is called a neighbour cache, not a neighbour table > > Sincerely, > > Greg Daley > Logicalis Australia Pty Ltd > E gdaley@au.logicalis.com > M +61 401 772 770 > > On Aug 25, 2016, at 11:59 PM, Naveen Kottapalli > wrote: > > Hello, > > Assuming that the node is given a prefix in RA by the gateway, does the > gateway need to know the complete address being used by node for data > forwarding? > > Yours, > Naveen. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a1144c0d6a9ea74053af501b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Greg!

Yours,
Naveen.

On 26 August 2016 at 09:15, Greg Daley <gdaley@au.logicalis.com> wrote:
Hi Naveen,

Not for reception from the local link. The router only needs ip address to = MAC mapping to deliver packets to devices on link (associated with the pref= ix)

This is why it is called a neighbour cache, not a neighbour table

Sincerely,

Greg Daley
Logicalis Australia Pty Ltd
E gdaley@au.logicalis.com M +61 401 772 770

On Aug 25, 2016, at 11:59 PM, Naveen Kottapalli <naveen.sarma@gmail.com> wrote:

Hello,

Assuming that the node is given a prefix in RA by the gateway, does the gat= eway need to know the complete address being used by node for data forwardi= ng?

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

--001a1144c0d6a9ea74053af501b8-- From nobody Mon Aug 29 17:29:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAC512D11F for ; Mon, 29 Aug 2016 17:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbJLIp3SOTPs for ; Mon, 29 Aug 2016 17:29:39 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0527127A90 for ; Mon, 29 Aug 2016 17:29:39 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id p64so1392498pfb.1 for ; Mon, 29 Aug 2016 17:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:cc:from:subject:message-id:date:user-agent:mime-version; bh=GMXhLFJTKQY0uw6q+B3Rdito4JJGVnT4Ljaxj7Sk1gw=; b=McGThE62LMxmg0/iUMenmBXpf8UBVuVWvMwW7EAiaEpQSftTk8sSys55ttSYrvLRy8 Rdrcsn7HFicXyOdb3KMdooNqzn+n4HY2sQ82cKMyIAqT+645ujgAwLd09CW4n0OFyvCy hEjhfyouuCT9T8X6OW/woo6tBOH9SVO3Czf59xTw6y2+Dqjukq4rc3fTDv8f8G4X2Kko VTStZtrlf4eONAeDUGOD3v3f0TJVBaMPeD+Oqi5GctvlCmyflKTdnpba99Tr1BqOWLIf eq+p/YX8vqg4Eq69kPj5rLA8p+dCw9koRZMtlAKsQKf1dLzFcnVc2d8iSiNCt7pUV5CE kR8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version; bh=GMXhLFJTKQY0uw6q+B3Rdito4JJGVnT4Ljaxj7Sk1gw=; b=LQIkRY+hV9On3LmhJ+w+g/oltGNXVYUJMbNJincbY13sC4FCgzsHzIHAanWjne3T9h 6F7IQ/TBY7OGD5/wQOZO1LHZlh6vJ0nlQ5Wlk4Cd2Gviw+WLpFAs2xMX1el+mIex+gm1 WRCqfxAoB0vHkYsPy1UY9ORCPV3dCDl12xl1w5/pmQ8vn0tTaAmcrMDkjNZH0tlmfo0r eh6dP7XqqJ6PhQ/SxlHoAjGlZey81Ho+R+N3kCV91gLnSeC0qLYMvwuktnmPht4qwCY9 rvDOyFsj7tt+/PmUOuop92s6CIQibZBLdnwqBqZ6+Frlp7X2F8lbZkaAwDaRsTd+/dUu nZMQ== X-Gm-Message-State: AE9vXwPiDNGeyURRGoCwZE1SKU+3aOnaLotPXLh2/SFwuXycmChDzfbOHAWO2fONv7+Xng== X-Received: by 10.98.204.216 with SMTP id j85mr1295098pfk.147.1472516979224; Mon, 29 Aug 2016 17:29:39 -0700 (PDT) Received: from mbp-2.local ([2601:1c0:cb00:5d1a:20ee:f682:3290:f705]) by smtp.googlemail.com with ESMTPSA id o80sm51828346pfa.67.2016.08.29.17.29.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 17:29:38 -0700 (PDT) To: IPv6 Ops WG From: joel jaeggli Message-ID: <62cc2367-7f0d-648f-4027-b68412447826@gmail.com> Date: Mon, 29 Aug 2016 17:29:35 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BaaNHuLvu9tDokdwvSKF5N5wv2f6TDixa" Archived-At: Cc: V6ops Chairs Subject: [v6ops] Call of volunteers, V6ops chair. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 00:29:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BaaNHuLvu9tDokdwvSKF5N5wv2f6TDixa Content-Type: multipart/mixed; boundary="888M6fTaTTxN2bgEdaPJaXqA2n9AL3uLS" From: joel jaeggli To: IPv6 Ops WG Cc: V6ops Chairs Message-ID: <62cc2367-7f0d-648f-4027-b68412447826@gmail.com> Subject: Call of volunteers, V6ops chair. --888M6fTaTTxN2bgEdaPJaXqA2n9AL3uLS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, Seeing as we're down on manpower it is my intention to recruit an additional v6ops chair. To that end I am soliciting volunteers for the role. If you'd like to be in consideration for this role please let me know in the next week or so, so that we can consider the pool, get you on board in time to be ready for Seoul and proceed. If you are curious and had not previously considered it, check out the working group chairs wiki for an introduction, and / or contact me and we can discuss the role. Thanks joel --888M6fTaTTxN2bgEdaPJaXqA2n9AL3uLS-- --BaaNHuLvu9tDokdwvSKF5N5wv2f6TDixa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlfE03AACgkQ8AA1q7Z/VrIJgACfUFWqfnT4WkW8SK7xYHJbSmQ9 FA4Anj54yUqs7ghvYzFqiNQ2i+f8J/Zr =Hx1i -----END PGP SIGNATURE----- --BaaNHuLvu9tDokdwvSKF5N5wv2f6TDixa-- From nobody Tue Aug 30 03:36:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7C212B075 for ; Tue, 30 Aug 2016 03:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQro3HATNinA for ; Tue, 30 Aug 2016 03:36:33 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C401B12B071 for ; Tue, 30 Aug 2016 03:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3138; q=dns/txt; s=iport; t=1472553392; x=1473762992; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=a1h0YHiWAK0lEQCyukhTpAoKpMnFKdL+EgUCStJC/HU=; b=iJb+TgtkLDCKv+tDelkpDgXSB+2lEMjg1TSATqdXnDmft9JbENq+xTdX M6uz3P8SHdn2bDp/6pvM0YvZTgjUQ83lEne5Ww5rD8szHqVYJGldeNu+2 FlYVe3TI65pE1JSzgQTe+UczcpPsMJezoQwSe18X4EU4c1tC5hi7/h378 Y=; X-IronPort-AV: E=Sophos;i="5.30,255,1470700800"; d="scan'208,217";a="647330710" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2016 10:36:31 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u7UAaUMF030296; Tue, 30 Aug 2016 10:36:30 GMT To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: Benoit Claise Message-ID: Date: Tue, 30 Aug 2016 12:36:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> Content-Type: multipart/alternative; boundary="------------92EFFAA951A255B210BC8737" Archived-At: Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 10:36:35 -0000 This is a multi-part message in MIME format. --------------92EFFAA951A255B210BC8737 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Fred, Thank you very much for all your contributions at the IETF, and in the industry in industry in general. Not only technical contributions, but also mentoring contributions (to me in particular). You really made a difference and you can be proud of your achievements. Regards, Benoit > This is perhaps abrupt... > > I am leaving Cisco and my next steps are at this point indeterminate. As a result, I am backing away from IETF activity for the near, and perhaps foreseeable, future. Let me take this opportunity to say to each of you that this has been an interesting and productive activity for the past decade, and I wish the IETF and its participants the best. You may see automated emails from this address for a little while ("state of play", new draft postings) until my termination date, but starting Thursday (when I go on a pre-planned vacation), I won't be here. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------92EFFAA951A255B210BC8737 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Fred,

Thank you very much for all your contributions at the IETF, and in the industry in industry in general.
Not only technical contributions, but also mentoring contributions (to me in particular).
You really made a difference and you can be proud of your achievements.

Regards, Benoit
This is perhaps abrupt...

I am leaving Cisco and my next steps are at this point indeterminate. As a result, I am backing away from IETF activity for the near, and perhaps foreseeable, future. Let me take this opportunity to say to each of you that this has been an interesting and productive activity for the past decade, and I wish the IETF and its participants the best. You may see automated emails from this address for a little while ("state of play", new draft postings) until my termination date, but starting Thursday (when I go on a pre-planned vacation), I won't be here.



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--------------92EFFAA951A255B210BC8737-- From nobody Tue Aug 30 03:52:35 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D3212B069 for ; Tue, 30 Aug 2016 03:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joygV4B2PRwM for ; Tue, 30 Aug 2016 03:52:32 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF6412B05E for ; Tue, 30 Aug 2016 03:52:32 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id k90so25572448uak.1 for ; Tue, 30 Aug 2016 03:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+5eZnLCa8+I002eVrPPHwFWwsMPa5WU63vIPe9Bo2k8=; b=VoIB3BlRQfjikzceajC7N/iucvUTz/HsC8LvoSc3lUR1elmbdYCyekX4/pYINhvATQ Cd2R+MtIQNEOzJR3PErRoWlOb4Gn5AQjghaU4fpB8aA/a3dBJOHUxIKM3cjplbHCNQhA exGA/rk3195lV8ElmjWBcuJ7CfH9wUT3feDkKUzMQOT7xyVA4euSdNySwkq9Gte6MFwv 7B6wnau8ove7e0Hy7HM4JHbj8xtxVt+HE1ujOTtPBP6A+USzQ9wyyymlZsMgG/A14a7w /eJKKv3tq4HysdHVfKKtWjJGRohS1GarBj0EMvI4ZhDNd+pAIJUzDmh2trFUhQnvbCL/ mHSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+5eZnLCa8+I002eVrPPHwFWwsMPa5WU63vIPe9Bo2k8=; b=QwleF5s8ZXKEsLw2mBWsyCdWfIhvxvsWRTwm5q7PQaRw5koDBz5XZTrjhO2PfE4tGy MQIwaXCHanNM66alb1d8Ca4vK+zzTU5fv9CyDeBeaPpqLMo10+4mv8aFSTW+2blI1qWF 1RUgDTSTvH19T5tCw2WSw8Ws3P3UbejTcllbZHa+sCQg7KNXCj71ShGXKktjQ9NrxWk+ 50XJQ2JXkz/5g6QZ/tfjUaEM0WNEXmrX0XbTGkOs3BQqQbHezMiIFyE2nasXqsEHTIPF Up/+ApHw+8LS3nmyYw5k7KfSYYIPbr17lTGI0kWJmNgqBZCiZ3UtRNzqUn+uQY5FWCSJ jNvA== X-Gm-Message-State: AE9vXwPWJ3yZPfpan/GIE0eCuTzzbCz8e+LvLZHUkXV6EHNgzSed9QODPJHkj8ZAmmTB2sGpnvgZJtrbjEHRdA== X-Received: by 10.31.192.2 with SMTP id q2mr1409312vkf.44.1472554351260; Tue, 30 Aug 2016 03:52:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.165 with HTTP; Tue, 30 Aug 2016 03:52:30 -0700 (PDT) Received: by 10.176.1.165 with HTTP; Tue, 30 Aug 2016 03:52:30 -0700 (PDT) In-Reply-To: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> References: <97B21338-9362-4A97-85EB-0AA76D2EB91D@cisco.com> From: Mark Smith Date: Tue, 30 Aug 2016 20:52:30 +1000 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a113bf06c05315a053b47c780 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Best wishes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 10:52:34 -0000 --001a113bf06c05315a053b47c780 Content-Type: text/plain; charset=UTF-8 +1 to what everybody else has said. You've certainly very significantly helped make the Internet work better. (And please come back after a well earned break!) Best Regards, Mark. On 23 Aug 2016 5:03 AM, "Fred Baker (fred)" wrote: > This is perhaps abrupt... > > I am leaving Cisco and my next steps are at this point indeterminate. As a > result, I am backing away from IETF activity for the near, and perhaps > foreseeable, future. Let me take this opportunity to say to each of you > that this has been an interesting and productive activity for the past > decade, and I wish the IETF and its participants the best. You may see > automated emails from this address for a little while ("state of play", new > draft postings) until my termination date, but starting Thursday (when I go > on a pre-planned vacation), I won't be here. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a113bf06c05315a053b47c780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1 to what everybody else has said.

You've certainly very significantly helped make the Inte= rnet work better. (And please come back after a well earned break!)

Best Regards,
Mark.


On 23 Aug 2016 5:= 03 AM, "Fred Baker (fred)" <= fred@cisco.com> wrote:
This is perhaps abrupt...

I am leaving Cisco and my next steps are at this point indeterminate. As a = result, I am backing away from IETF activity for the near, and perhaps fore= seeable, future. Let me take this opportunity to say to each of you that th= is has been an interesting and productive activity for the past decade, and= I wish the IETF and its participants the best. You may see automated email= s from this address for a little while ("state of play", new draf= t postings) until my termination date, but starting Thursday (when I go on = a pre-planned vacation), I won't be here.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--001a113bf06c05315a053b47c780-- From nobody Wed Aug 31 03:59:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF9812DAC5; Wed, 31 Aug 2016 03:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5_-GwLksCyj; Wed, 31 Aug 2016 03:59:24 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D4612D16F; Wed, 31 Aug 2016 03:59:24 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id i184so4588345itf.1; Wed, 31 Aug 2016 03:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E6o8TVz0KASZ+UFr4jWzCyug4qCGMdelNCwbESB6cP0=; b=rGNiW4+wUFR4NVvg3L+W4jks2I0R1UeU9JqKh+X9L0x0jvFJ03UdXMjfxLdvmF+cUC JPIRBGtB/ghn8m1hSHmpW9PpHGTYOnUOQyOIcX+IAfM6Ym9vwTlganM+t/yIRpOQywql qcWMCNnTylLMvYt4rF27w3B+72BYp0oNLt9OLakNnALQ2Erzup3wqPsb1Uxr/56r7TQn a+X78jzStuImTZWTqNCnM5YFnk4r9UZ8kBTGr7E4B1LkHonuR1mgiBN/W+LYf2GQ7nI1 iAe3KeHQiYwCRBlTUlvzbqILUoSq3LUK/KpEuzJdx1UjRuIt5rICRX9L8yrhIPv88pmi 5L6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E6o8TVz0KASZ+UFr4jWzCyug4qCGMdelNCwbESB6cP0=; b=N7mneUe8Iw13bPlxYRYG84Dquu9ykUPEZIL1Ywuhhbjc6PYDgrKwTDs0tFKedwGQir i75ApgyERY0C0FkQA+ZvEE6nEcDTflyDva9lW591cwcVR5U5kZRWzQm6tmPzIJp7vGIR hVvUeDZJ/yw4ZKvGL2L/YcM5WLP3mFCMWu875klf2gDMxPBdXLoQEip0ZCSndtNGU9T+ RllhzJ5OhihODCdDHd2rpbUdiC7mJNmwHfdkn2Jx9xCzw5G5n/VSm9otA+Txq8pgSO7+ 0hkpGkt/LfoUj+djHZ7arpClZduYaB0LcM2NRFTRmEr6afhqbTxM1uY3Kqy7+m2EJJqM KuHQ== X-Gm-Message-State: AE9vXwPXVVnf0koxdxQVPngl3+AXsX4VpfnvzvTNhx27Ip2WWRodSLXr2RrKDqgHWAy6NWLEyloBdftoJ3NZLQ== X-Received: by 10.107.15.38 with SMTP id x38mr4723894ioi.74.1472641163637; Wed, 31 Aug 2016 03:59:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.209 with HTTP; Wed, 31 Aug 2016 03:59:03 -0700 (PDT) In-Reply-To: References: From: Naveen Kottapalli Date: Wed, 31 Aug 2016 16:29:03 +0530 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=001a113e9f5270bdf3053b5bfd41 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 10:59:26 -0000 --001a113e9f5270bdf3053b5bfd41 Content-Type: text/plain; charset=UTF-8 Hello, As per section 7 of RFC 6788, Line-Identification option is encoded in below format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LineIDLen | Line ID... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Line-Identification Option Layout Does the above layout mean that option type 0x8C will start at 2nd byte? Yours, Naveen. On 24 August 2016 at 17:08, Erik Kline wrote: > On 24 August 2016 at 19:58, Mark Smith wrote: > > On 24 August 2016 at 20:29, Naveen Kottapalli > wrote: > >> Hello, > >> > >> If the AP is relaying the RS on a GRE tunnel to the gateway, can > whatever > >> Erik suggested be used to inject the information whatever am looking > for? > >> > > > > Possibly (I'd forgotten about that method) if the AP supported it. > > Yeah, definitely a question for your vendor. > > > > > > > Regards, > > Mark. > > > > > >> Yours, > >> Naveen. > >> > >> On 24 August 2016 at 15:29, Mark Smith wrote: > >>> > >>> Hi, > >>> > >>> On 24 August 2016 at 19:28, Naveen Kottapalli > >>> wrote: > >>> > Hello, > >>> > > >>> > Can anyone tell if there is any SLAAC equivalent for DHCPv6 > Remote-Id / > >>> > DHCP > >>> > Option-82 option that can be used by a gateway to know the SSID, > etc.,? > >>> > > >>> > >>> No there isn't. > >>> > >>> SLAAC is not relayed through a router/gateway is like DHCPv4 is, so > >>> there is no point trying to add information on the way. > >>> > >>> SLAAC doesn't actually assign addresses to hosts either - all it does > >>> is provides the hosts on the link with information about what > >>> prefixes/subnets are present on the link, and hosts then generate > >>> their own addresses from within the prefix. > >>> > >>> In other words, if you're thinking IPv6 SLAAC is equivalent to IPv4 > >>> DHCP, they aren't, they're very different. > >>> > >>> The use of DHCPv4 to assign addresses could be described as a > >>> centralised database dependent host address assignment > >>> protocol/method, where hosts don't participate in the generation and > >>> selection of the addresses they end up using. They either take what > >>> they're given from the DHCPv4 server or don't have an address to use. > >>> > >>> The use of SLAAC for address assignment in IPv6 could be described as > >>> a distributed address assignment system that doesn't have a central > >>> database. Hosts are entirely responsible for the generation and > >>> validation of addresses that they use based on the prefix information > >>> supplied in RAs. > >>> > >>> Regards, > >>> Mark. > >>> > >>> > >>> > Yours, > >>> > Naveen. > >>> > > >>> > -------------------------------------------------------------------- > >>> > IETF IPv6 working group mailing list > >>> > ipv6@ietf.org > >>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> > -------------------------------------------------------------------- > >>> > > >> > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > --001a113e9f5270bdf3053b5bfd41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

As per section 7 of RFC 6788, Li= ne-Identification option is encoded in below format.

    0                   1                   2      =
             3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  | Option Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LineIDLen     |     Line ID...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: Line-Identification Option Layout

Does the above layout mean that option type= 0x8C will start at 2nd byte?

Yo= urs,
Naveen.

On 24 August 2016 at 17:08, Erik Kline <ek@goog= le.com> wrote:
On 24 August 2016 at 19:58, Mark Smith <markzzzsmith@gmail.com> wrote:
> On 24 August 2016 at 20:29, Naveen Kottapalli <naveen.sarma@gmail.com> wrote:
>> Hello,
>>
>> If the AP is relaying the RS on a GRE tunnel to the gateway, can w= hatever
>> Erik suggested be used to inject the information whatever am looki= ng for?
>>
>
> Possibly (I'd forgotten about that method) if the AP supported it.=

Yeah, definitely a question for your vendor.

>
>
> Regards,
> Mark.
>
>
>> Yours,
>> Naveen.
>>
>> On 24 August 2016 at 15:29, Mark Smith <markzzzsmith@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> On 24 August 2016 at 19:28, Naveen Kottapalli <naveen.sarma@gmail.com>
>>> wrote:
>>> > Hello,
>>> >
>>> > Can anyone tell if there is any SLAAC equivalent for DHCP= v6 Remote-Id /
>>> > DHCP
>>> > Option-82 option that can be used by a gateway to know th= e SSID, etc.,?
>>> >
>>>
>>> No there isn't.
>>>
>>> SLAAC is not relayed through a router/gateway is like DHCPv4 i= s, so
>>> there is no point trying to add information on the way.
>>>
>>> SLAAC doesn't actually assign addresses to hosts either - = all it does
>>> is provides the hosts on the link with information about what<= br> >>> prefixes/subnets are present on the link, and hosts then gener= ate
>>> their own addresses from within the prefix.
>>>
>>> In other words, if you're thinking IPv6 SLAAC is equivalen= t to IPv4
>>> DHCP, they aren't, they're very different.
>>>
>>> The use of DHCPv4 to assign addresses could be described as a<= br> >>> centralised database dependent host address assignment
>>> protocol/method, where hosts don't participate in the gene= ration and
>>> selection of the addresses they end up using. They either take= what
>>> they're given from the DHCPv4 server or don't have an = address to use.
>>>
>>> The use of SLAAC for address assignment in IPv6 could be descr= ibed as
>>> a distributed address assignment system that doesn't have = a central
>>> database. Hosts are entirely responsible for the generation an= d
>>> validation of addresses that they use based on the prefix info= rmation
>>> supplied in RAs.
>>>
>>> Regards,
>>> Mark.
>>>
>>>
>>> > Yours,
>>> > Naveen.
>>> >
>>> > ----------------------------------------------------= ----------------
>>> > IETF IPv6 working group mailing list
>>> > ipv6@ietf.org
>>> > Administrative Requests: https://www.iet= f.org/mailman/listinfo/ipv6
>>> > ----------------------------------------------------= ----------------
>>> >
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=

--001a113e9f5270bdf3053b5bfd41-- From nobody Wed Aug 31 05:46:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A1412DB4F; Wed, 31 Aug 2016 05:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAJqxJMHD_n6; Wed, 31 Aug 2016 05:46:27 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E471812DB47; Wed, 31 Aug 2016 05:46:26 -0700 (PDT) X-AuditID: c6180641-e87ff70000000a0b-cd-57c67d3d8abb Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id 3A.01.02571.D3D76C75; Wed, 31 Aug 2016 08:46:23 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0301.000; Wed, 31 Aug 2016 08:46:23 -0400 From: Suresh Krishnan To: Naveen Kottapalli , Erik Kline Thread-Topic: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? Thread-Index: AQHR/fwZayWIRqHvnkuo2orpk9hUEA== Date: Wed, 31 Aug 2016 12:46:21 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXSPt6597bFwg752E4vPt+exW7w8+57J 4t25LywWp4/tZXZg8dg56y67x4JNpR5LlvxkCmCO4rJJSc3JLEst0rdL4Mo48uQTY8EHnoon C5axNzAu4+xi5OSQEDCRWHa2iRHEFhLYwChx6QRbFyMXkL2cUeLtoTNMIAk2oKINOz+D2SIC XhLvdu1nA7GZBSwknk+ewQJiCwsESixe9o8VoiZIYs2RTewQtp7Ep8eXwWpYBFQlfv5vAYvz CvhKXJvQzgqxbDOzxM/2n2DNjAJiEt9PrWGCWCAucevJfCaISwUkluw5zwxhi0q8fAyxTEJA SeLj7/nsEPU6Egt2f4I6Tlti2cLXzBDLBCVOznzCMoFRZBaSsbOQtMxC0jILScsCRpZVjByl xQU5uelGhpsYgTFxTILNcQfj3l7PQ4wCHIxKPLxnbx0NF2JNLCuuzD3EKMHBrCTCu+nCsXAh 3pTEyqrUovz4otKc1OJDjNIcLErivPovFcOFBNITS1KzU1MLUotgskwcnFINjMs35zMohUxn 3uV3hCvO2HlekJZUhNHsm5buU4x9WLQCmOe9vfm3KoFhw0aOxZxVc7oKmWdwxzYbxN9ekBP4 kz/5Q6mSEFfbbVff93UnHC9pa36/022pmd6rN++Qz4k3ztvbH96qTl9xL3Of2eLQc19ennj0 8YLhlC9aUjl/5X24VlopSYZyK7EUZyQaajEXFScCAFIu0NiFAgAA Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 12:46:29 -0000 Hi Naveen,=0A= =0A= On 08/31/2016 06:59 AM, Naveen Kottapalli wrote:=0A= > Hello,=0A= >=0A= > As per section 7 of RFC 6788, Line-Identification option is encoded in be= low=0A= > format.=0A= >=0A= > 0 1 2 3=0A= > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= > | Option Type | Option Length |=0A= > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= > | LineIDLen | Line ID...=0A= > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= >=0A= > Figure 4: Line-Identification Option Layout=0A= >=0A= >=0A= > Does the above layout mean that option type 0x8C will start at 2nd byte?= =0A= =0A= The Option type 0x8c will be in the first byte (Byte 0) of the option. The = =0A= IPv6 ND option formats are shown like this along with a alignment requireme= nt =0A= to allow for proper encoding of multi-byte fields. In this particular case = =0A= there is no alignment required.=0A= =0A= As for your other question upthread, I do not know of any implementations i= n =0A= WiFi APs. This option was primarily for Broadband Forum networks and AFAIK = =0A= only BNGs and Access Nodes (e.g. DSLAMs) implemented it. If you are =0A= interested in using this for other purposes, please read Section 2 of the = =0A= document to check if the issues mentioned there apply to your specific =0A= deployment scenario.=0A= =0A= Thanks=0A= Suresh=0A= =0A= =0A= From nobody Wed Aug 31 06:16:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0212D1BB; Wed, 31 Aug 2016 06:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFWXFt0jE2EV; Wed, 31 Aug 2016 06:16:34 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F8012D4FB; Wed, 31 Aug 2016 06:16:31 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id e124so6830040ith.0; Wed, 31 Aug 2016 06:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/cEEWgCetWgX2t9ZaDasMEVTAPOsmK8vQkU+p7Go+sE=; b=lyNthF/WCay5vgcOCxt7eHaqrPGhqljKSQyjQ/73BOKx40k8PlkLXP+pVLIWDnOagt Zohp5v8O1J1Bk4TCaWr1HiHJrwJkoZMcip09s3cFwSx6jfLwf/9ftAsv5KTB/d+mt25M DBaieocM8IWvAfhsVUj4Nhpkjvi6A38TdYngjA/0yMJ5wpQcJw+Oxx5IuJFV19wR3fEn MKn65GvVp8795bz9QVY9nR4P+9R4mtcp8rmFOgpr6c9SLwdZcYDC3x2xvPT4PH1ASdG1 VEO3OXwnga04blUCFMFsTXHLYL5yhAVhQvwnqwAPcw7UlA2xXWHmupSqlzh4ILOBJV7N k+0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/cEEWgCetWgX2t9ZaDasMEVTAPOsmK8vQkU+p7Go+sE=; b=Nj0VbFXX1r/UiA86fh4JKMkfIa2qgjp+j0gqAOC8F4qlolLrUx/8Ofno8kqXjPcUPc I4PaZCJYGol6S4XZDHgoKn/S43LRM+eYJIPKvMP0iW8rd0GQ+JIjFFvocprSPZ7GPk2n fHfik/odkUyYfvbBu81LErz+9RDZo2LqCH9KeK/DK9+PWHV1H+O3GKGIYNUAdwUK8TKr s1kEYSEE4/0E+glYS7H6x1J2DC0nFsgzLq3+6/IRqDoC6/u3tCCzTby7wywkqY4P3miD CSsHzJwFEXREIGhOWclmTvjT2Qo/n63fHN+q3ubisAq9Et5h/Xx2HQbbqUYIMg/O0x8j ipdg== X-Gm-Message-State: AE9vXwOKT9faFNhv+ofUh8ofH1elo321HxDmyE9Eh5IZKN0TaFN3Ma7f5ZrLjzMfCtN3ThEzsvoDNZdpOE1OKg== X-Received: by 10.36.227.78 with SMTP id d75mr29598568ith.75.1472649390804; Wed, 31 Aug 2016 06:16:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.209 with HTTP; Wed, 31 Aug 2016 06:16:10 -0700 (PDT) In-Reply-To: References: From: Naveen Kottapalli Date: Wed, 31 Aug 2016 18:46:10 +0530 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=94eb2c111de8d1bf30053b5de793 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 13:16:36 -0000 --94eb2c111de8d1bf30053b5de793 Content-Type: text/plain; charset=UTF-8 Thanks Suresh. Will get back after exploring more. Yours, Naveen. On 31 August 2016 at 18:16, Suresh Krishnan wrote: > Hi Naveen, > > On 08/31/2016 06:59 AM, Naveen Kottapalli wrote: > > Hello, > > > > As per section 7 of RFC 6788, Line-Identification option is encoded in > below > > format. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Option Type | Option Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LineIDLen | Line ID... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 4: Line-Identification Option Layout > > > > > > Does the above layout mean that option type 0x8C will start at 2nd byte? > > The Option type 0x8c will be in the first byte (Byte 0) of the option. The > IPv6 ND option formats are shown like this along with a alignment > requirement > to allow for proper encoding of multi-byte fields. In this particular case > there is no alignment required. > > As for your other question upthread, I do not know of any implementations > in > WiFi APs. This option was primarily for Broadband Forum networks and AFAIK > only BNGs and Access Nodes (e.g. DSLAMs) implemented it. If you are > interested in using this for other purposes, please read Section 2 of the > document to check if the issues mentioned there apply to your specific > deployment scenario. > > Thanks > Suresh > > > --94eb2c111de8d1bf30053b5de793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Suresh.=C2=A0 Will get back after exploring more.

Yours,
Naveen.

On 31 August 2016 at 18:16, Suresh Krishnan = <suresh.krishnan@ericsson.com> wrote:
Hi Naveen,

On 08/31/2016 06:59 AM, Naveen Kottapalli wrote:
> Hello,
>
> As per section 7 of RFC 6788, Line-Identification option is encoded in= below
> format.
>
>=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A03
>=C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5= 6 7 8 9 0 1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 Option Type= =C2=A0 | Option Length |
>=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
>=C2=A0 =C2=A0 | LineIDLen=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0Line = ID...
>=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 4:= Line-Identification Option Layout
>
>
> Does the above layout mean that option type 0x8C will start at 2nd byt= e?

The Option type 0x8c will be in the first byte (Byte 0) of the optio= n. The
IPv6 ND option formats are shown like this along with a alignment requireme= nt
to allow for proper encoding of multi-byte fields. In this particular case<= br> there is no alignment required.

As for your other question upthread, I do not know of any implementations i= n
WiFi APs. This option was primarily for Broadband Forum networks and AFAIK<= br> only BNGs and Access Nodes (e.g. DSLAMs) implemented it. If you are
interested in using this for other purposes, please read Section 2 of the document to check if the issues mentioned there apply to your specific
deployment scenario.

Thanks
Suresh



--94eb2c111de8d1bf30053b5de793--