From nobody Thu Nov 1 05:19:24 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDDB1276D0 for ; Thu, 1 Nov 2018 05:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 Z0uQUOcI5bmN for ; Thu, 1 Nov 2018 05:19:20 -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 4726D124D68 for ; Thu, 1 Nov 2018 05:19:20 -0700 (PDT) Received: from [192.168.199.230] (d1-194-155-143-118-on-nets.com [118.143.155.194] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id wA1CJChM024803; Thu, 1 Nov 2018 12:19:18 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host d1-194-155-143-118-on-nets.com [118.143.155.194] (may be forged) claimed to be [192.168.199.230] From: Joel Jaeggli Message-Id: <66EDCD17-A1BA-4765-812C-231992FF1D60@bogus.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_21EF772F-109F-423B-A2AC-7336BFBE0B30" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Date: Thu, 1 Nov 2018 05:19:11 -0700 In-Reply-To: <38c6f05a-349a-2124-0052-aed032e450eb@nlogic.no> Cc: ipv6@ietf.org To: Ola Thoresen References: <3beca72e-19c5-10af-02e5-c21a90d77100@gmail.com> <20181019.223739.271916573.sthaug@nethelp.no> <82E7C4FD-AD73-4697-9FC6-F61FBCB50375@employees.org> <38c6f05a-349a-2124-0052-aed032e450eb@nlogic.no> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 12:19:22 -0000 --Apple-Mail=_21EF772F-109F-423B-A2AC-7336BFBE0B30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 20, 2018, at 10:34, Ola Thoresen > wrote: >=20 > On 20/10/2018 00:12, Ole Troan wrote: >=20 >>=20 >>=20 >> In my view, I don=E2=80=99t see much purpose in the bit unless it=E2=80= =99s prescriptive. As in the last category.=20 >>=20 >=20 > On this, we can agree. Having a flag as a "hint" does not make much = sense. You can't trust it, so you would STILL need to verify if the = flag is actually telling the truth, or if it is just set - either = malicious, or by mistake. =20 >=20 I can=E2=80=99t really trust (ND, RAs, ARP, DHCP, DHCPv6, MDNS). Lack of = trust here extends to most of the signals one might receive in the = process of bootstrapping. Of those signals some of them I accept because = as part of a faustian bargain I made when attaching to the network, I = actually need some of that information. The stuff that I don=E2=80=99t = have to accept in order to achieve basic functionality I ignore. As case in point all the operating systems I use allow me to specify my = own nameserver despite receiving such information via DHCP/DHCPv6, = doing so may come at the expense of some local funcationality but it=E2=80= =99s worth it as far as I=E2=80=99m concerned. >=20 > On the other hand, I do not see how this can be a hard requirement. = Or at least I can not see operating systems actually obyeing such a = flag. IF the client administrator has configured IPv4 dhcp client = settings, why should the OS trust a flag in an RA-packet more than the = OS-admins configuration? >=20 > Just look at the already defined flags "O" and "M" - which are not = even breaking the barrier between the IP-protocols. I know at least a = couple of implementations which will send a DHCPv6-request no matter = what the RA is signaling in its M and O-flags. And I know = implementations that will not automatically send dhcp-requests no matter = what flags are set in the RA-packets. =20 >=20 > We don't need even more flags that might or might not be ignored by = the operating systems. And which have a somewhat vague definition. >=20 And which is not absolutely necessary for bootstrapping. >=20 > We don't have a flag to tell the OS to not run DECnet, Appletalk or = IPX. We simply disable these on the clients. And even if we had such a = flag in DHCPv4 or RA, I - as an admin - would prefer the clients to not = rely on such a flag, but try to get some kind of network access on any = enabled network protocol in the client. >=20 >=20 >=20 > Rgds. >=20 > Ola (T) >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_21EF772F-109F-423B-A2AC-7336BFBE0B30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Oct 20, 2018, at 10:34, Ola Thoresen <ola@nlogic.no> = wrote:

=20 =20

On = 20/10/2018 00:12, Ole Troan wrote:



In my view, I don=E2=80=99t see much purpose in = the bit unless it=E2=80=99s prescriptive. As in the last category. 


On this, we can agree. Having a flag as = a "hint" does not make much sense.  You can't trust it, so you would STILL need to = verify if the flag is actually telling the truth, or if it is just set - either malicious, or by mistake. 

I can=E2=80=99t really trust = (ND, RAs, ARP, DHCP, DHCPv6, MDNS). Lack of trust here extends to most = of the signals one might receive in the process of bootstrapping. Of = those signals some of them I accept because as part of a faustian = bargain I made when attaching to the network, I actually need some of = that information. The stuff that I don=E2=80=99t have to accept in order = to achieve basic functionality I ignore.

As  case in point all the = operating systems I use allow me to specify my own nameserver despite = receiving such information  via DHCP/DHCPv6, doing so may come at = the expense of some local funcationality but it=E2=80=99s worth it as = far as I=E2=80=99m concerned.

On the = other hand, I do not see how this can be a hard requirement.  Or at least I can not see operating systems = actually obyeing such a flag.  IF the client administrator has = configured IPv4 dhcp client settings, why should the OS trust a flag in an RA-packet more than the OS-admins configuration?

Just look at the already defined flags "O" and "M" - which = are not even breaking the barrier between the IP-protocols.  I = know at least a couple of implementations which will send a DHCPv6-request no matter what the RA is signaling in its M and O-flags.  And = I know implementations that will not automatically send dhcp-requests no matter what flags are set in the = RA-packets.  

We don't need even more flags = that might or might not be ignored by the operating systems.  And which have a somewhat vague definition.

And which = is not absolutely necessary for bootstrapping.

We don't = have a flag to tell the OS to not run DECnet, Appletalk or IPX.  We simply disable these on the clients.  And = even if we had such a flag in DHCPv4 or RA, I - as an admin - would prefer the clients to not rely on such a flag, but try to get some kind of network access on any enabled network protocol in the = client.


Rgds.

Ola (T)


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

= --Apple-Mail=_21EF772F-109F-423B-A2AC-7336BFBE0B30-- From nobody Thu Nov 1 05:45:07 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8331276D0 for ; Thu, 1 Nov 2018 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.196 X-Spam-Level: *** X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 BOsZXZp0S9ze for ; Thu, 1 Nov 2018 05:45:02 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60095.outbound.protection.outlook.com [40.107.6.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4EA126DBF for ; Thu, 1 Nov 2018 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2m8ESyVhyFxonHQANS9eqhdcVQsiJNVwbMjBaadG5cg=; b=GlWZMuSeJ2T5yxjxxsnRXi2pblTPZZoyrscw7YtKPZPC000nmxUufHqOEVbUV3aCSl9hz1tRoPokLjsk8fJXr7X7/aw4FY+vXirWY8io8gp9Dtn+NRMZUdLqngfeop+HhMSLih5H+iiwYmPqjbwahPD25daTKB5x+j1kYCfjbYM= Received: from VI1PR07MB5022.eurprd07.prod.outlook.com (20.177.202.206) by VI1PR07MB3391.eurprd07.prod.outlook.com (10.175.244.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.16; Thu, 1 Nov 2018 12:44:59 +0000 Received: from VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::d929:3695:4655:d265]) by VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::d929:3695:4655:d265%4]) with mapi id 15.20.1294.022; Thu, 1 Nov 2018 12:44:59 +0000 From: tom petch To: David Farmer , Brian E Carpenter CC: 6man WG Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Thread-Topic: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Thread-Index: AQHUceCzy05o/wjGoUmAa33kfEyrmw== Date: Thu, 1 Nov 2018 12:44:59 +0000 Message-ID: <057701d471e0$8027ec20$4001a8c0@gateway.2wire.net> References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <2c63c54f-b6ee-b12e-bd72-cc6165b64f21@gmail.com> <105ad6b3-52a3-d0a3-0a02-b9a88b9d9e42@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: CWLP265CA0058.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:12::22) To VI1PR07MB5022.eurprd07.prod.outlook.com (2603:10a6:803:9b::14) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [86.128.101.213] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3391; 6:FgCFo7Gc30TSnLWNTRBBpUcgf8VolP2Jfx55XpyTIFSLK6bc+E3SnOvI92v+X3Hh0IpuE9/xqiOMRc1cNDnuDJov+ETqaUPhIABjQ7QrBfrtqHePy0gCc73KbIor6bS9Q0il+kUCxejVHNQSMeVYq7DQXPJZ379+NoiHEu6xc3RnO16rzPYXTztVluMkeJjchcjs3S+OfUW/LVCES2eJ7cb9lZAYZJele1lRgaip8JKnmck4rVPRBc6ZKKqJB4LNgTX/kkso234nyT53oqAa2mGQXUd+C8/3BU4E4Prk9+GaseEvL2BTyodhhqI/MqSQeE7w3YUjYzkoXnsGP3h+4pnpzb1A2siUhTvvwuylTM64N7Z1ogVR2J7qgb7ikMmr56ejian/Ki0fg4mp8x8WyevgD1sGpxFB3SUho6FXRNXXIYUtb8CzyC8bZueRMAPnQff+qikZKW8aqON12nPgUg==; 5:2q2AVdRrdpmNlb2Sqe08c2w3xT7KiAFEljr8sIy2B3GvZXVcOHQ3XGAae+2e/xvjcWcg/hcXXJos+heW71nnMn6O1lPBeX7Ubm1xm9Iz5jIF8J6KokH6iQPDfaShlNYXtffrz/INkdEiBTwd1YN4nxwEv/8BF6lzy1ZHVDRvIwo=; 7:1A75UGbtJl0tBaTnvGLt3l6D0P33pxL4/NYPYonmUmE0ys7I9i0b/qv5QLXMKgi7PluNJCcccqa0MfibMBESsAqdKSos7+scKb5VCLb+gFcCYlVtBrkOeLMlvPAY1HI90XexeAMzouv7wzIojsRMng== x-ms-office365-filtering-correlation-id: 5eb33356-bc3e-4c69-ea3e-08d63ff7d570 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB3391; x-ms-traffictypediagnostic: VI1PR07MB3391: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(163750095850)(85827821059158)(8104003914727); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB3391; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3391; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(39860400002)(376002)(346002)(189003)(199004)(13464003)(25786009)(84392002)(68736007)(86152003)(8936002)(6116002)(6306002)(2906002)(4326008)(486006)(9686003)(6512007)(229853002)(5660300001)(97736004)(3846002)(39060400002)(966005)(305945005)(14444005)(256004)(105586002)(186003)(53936002)(476003)(7736002)(4001150100001)(14454004)(2900100001)(106356001)(6246003)(71190400001)(66066001)(14496001)(478600001)(86362001)(2171002)(44736005)(6506007)(53546011)(6436002)(386003)(71200400001)(6486002)(102836004)(33896004)(8676002)(81156014)(52116002)(76176011)(81166006)(5250100002)(110136005)(26005)(6346003)(93886005)(99286004)(316002)(1556002)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3391; H:VI1PR07MB5022.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-microsoft-antispam-message-info: Hyy9hApoIzV/SFX3akUZD5dahbkaCrHsUtZe1cCT/Ixdl3VOMWnRlQQQjTT95Ms7URtY3JoUhSGlQbuvyPQpF+PNqFCEOTkQSG2os6dLOxSgc+menV+IxgPRYsCRy5IayK4OHaeBtZdx3Jw3qJL1YQdv47Gx0Cu3y5nVGyxmHrWPeQNkYaiffg2pzFeU8F/15e5qmG29+/Lu8Mv7issEphlltO1/DEJ9kCRRaPNKSJ64IKaedBs1SfIK2JedL0XA1hWRxgWwqUnAWxU4nfG1Fq4DXikqXMBqmiw+H57wZ4rA8sK1H+GvGZxpxBL8S23iAk/v8snT1ifLLiSUyx5OJEDo1IL5R0gBFF/Y2OSgaD8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5eb33356-bc3e-4c69-ea3e-08d63ff7d570 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2018 12:44:59.2204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3391 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 12:45:05 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: "David Farmer" Cc: "6man WG" Sent: Wednesday, October 31, 2018 7:45 PM > On 2018-11-01 04:53, David Farmer wrote: > > On Tue, Oct 30, 2018 at 7:28 PM Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 2018-10-31 10:42, Mark Smith wrote: ...... > > Regardless if this document is published and any misgivings anyone has, I > > think we need to have IANA allocate the code point to this purpose NOW! We > > asked to have running code, we now have some, it is extremely dangerous to > > have code out in the wild without some level of an official designation of > > the code point. > > > > I'm not sure of the procedure, but for all effective purposes if we expect > > there to be more running code we had better officially designate the code > > point. > > There is a procedure for requesting early allocation, and of course an allocation > can always be rescinded later. Whether there's any real practical risk is a > judgment call. RFC7120 .... 1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned. ... Up to you! The allocation times out after a year. Tom Petch > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Nov 1 08:51:32 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0B1252B7 for ; Thu, 1 Nov 2018 08:51:30 -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, 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 UBrCb3gDDjtb for ; Thu, 1 Nov 2018 08:51:29 -0700 (PDT) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE04F124BAA for ; Thu, 1 Nov 2018 08:51:28 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3E9A08D4A216; Thu, 1 Nov 2018 15:51:26 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1B0EFD1F89D; Thu, 1 Nov 2018 15:51:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id puGpRZWj16_Q; Thu, 1 Nov 2018 15:51:23 +0000 (UTC) Received: from [146.179.201.71] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 88704D1F89C; Thu, 1 Nov 2018 15:51:22 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Brian E Carpenter" Cc: "David Farmer" , "6man WG" Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Date: Thu, 01 Nov 2018 15:51:22 +0000 X-Mailer: MailMate (2.0BETAr6125) Message-ID: <9FCDA205-A6A9-4767-8C42-5D0E1E53F33A@lists.zabbadoz.net> In-Reply-To: <105ad6b3-52a3-d0a3-0a02-b9a88b9d9e42@gmail.com> References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <2c63c54f-b6ee-b12e-bd72-cc6165b64f21@gmail.com> <105ad6b3-52a3-d0a3-0a02-b9a88b9d9e42@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 15:51:31 -0000 On 31 Oct 2018, at 19:45, Brian E Carpenter wrote: >>>>> What OS vendor will go next? >>>>> >>>> >>>> IANA better allocate the bit first. >>> >>> Yes, that's an interesting chicken/egg issue since there is no >>> designated experimental/local use bit. But hard to avoid if people >>> want running code before Proposed Standard. >>> >> >> Regardless if this document is published and any misgivings anyone >> has, I >> think we need to have IANA allocate the code point to this purpose >> NOW! We >> asked to have running code, we now have some, it is extremely >> dangerous to >> have code out in the wild without some level of an official >> designation of >> the code point. >> >> I'm not sure of the procedure, but for all effective purposes if we >> expect >> there to be more running code we had better officially designate the >> code >> point. > > There is a procedure for requesting early allocation, and of course an > allocation > can always be rescinded later. Whether there's any real practical risk > is a > judgment call. I’d suggest finalise the draft and get the RFC out and not complicate matters by diverting energy to sort the bit out. If we sort the bit out it almost means that we want this draft to go out as an RFC, so get it out :-) /bz From nobody Thu Nov 1 10:06:22 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D131286D9 for ; Thu, 1 Nov 2018 10:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 WImVoJjotmRr for ; Thu, 1 Nov 2018 10:06:17 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 3BE211277BB for ; Thu, 1 Nov 2018 10:06:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wA1H6Fg7038731 for ; Thu, 1 Nov 2018 18:06:15 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8038E203610 for ; Thu, 1 Nov 2018 18:06:15 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7433B20360B for ; Thu, 1 Nov 2018 18:06:15 +0100 (CET) Received: from [10.8.68.90] ([10.8.68.90]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wA1H6EnQ027213 for ; Thu, 1 Nov 2018 18:06:14 +0100 Subject: Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: ipv6@ietf.org References: <3beca72e-19c5-10af-02e5-c21a90d77100@gmail.com> <20181019.223739.271916573.sthaug@nethelp.no> <82E7C4FD-AD73-4697-9FC6-F61FBCB50375@employees.org> <38c6f05a-349a-2124-0052-aed032e450eb@nlogic.no> <66EDCD17-A1BA-4765-812C-231992FF1D60@bogus.com> From: Alexandre Petrescu Message-ID: <6f961e2e-e1ca-d669-e206-43875a3858ee@gmail.com> Date: Thu, 1 Nov 2018 18:06:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <66EDCD17-A1BA-4765-812C-231992FF1D60@bogus.com> Content-Type: multipart/alternative; boundary="------------DBBCA1C34EEF4DF65C991959" Content-Language: fr Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 17:06:21 -0000 This is a multi-part message in MIME format. --------------DBBCA1C34EEF4DF65C991959 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 01/11/2018 à 13:19, Joel Jaeggli a écrit : > > >> On Oct 20, 2018, at 10:34, Ola Thoresen > > wrote: >> >> On 20/10/2018 00:12, Ole Troan wrote: >> >>> >>> >>> In my view, I don’t see much purpose in the bit unless it’s >>> prescriptive. As in the last category. >>> >> >> On this, we can agree. Having a flag as a "hint" does not make much >> sense.  You can't trust it, so you would STILL need to verify if the >> flag is actually telling the truth, or if it is just set - either >> malicious, or by mistake. >> > I can’t really trust (ND, RAs, ARP, DHCP, DHCPv6, MDNS). It should not be difficult to slightly secure the RA that contains the IPv6-only flag.  A check of the existing L2 address in NC for the GW of the default route, against the L2 source address of the L2 header of the RA containing IPv6-only flag, should add some insurance.  On cellular links, the reliance on SIM cards should be sufficient. Alex > Lack of trust here extends to most of the signals one might receive in > the process of bootstrapping. Of those signals some of them I accept > because as part of a faustian bargain I made when attaching to the > network, I actually need some of that information. The stuff that I > don’t have to accept in order to achieve basic functionality I ignore. > > As  case in point all the operating systems I use allow me to specify > my own nameserver despite receiving such information  via DHCP/DHCPv6, > doing so may come at the expense of some local funcationality but it’s > worth it as far as I’m concerned. >> >> On the other hand, I do not see how this can be a hard requirement.  >> Or at least I can not see operating systems actually obyeing such a >> flag. IF the client administrator has configured IPv4 dhcp client >> settings, why should the OS trust a flag in an RA-packet more than >> the OS-admins configuration? >> >> Just look at the already defined flags "O" and "M" - which are not >> even breaking the barrier between the IP-protocols.  I know at least >> a couple of implementations which will send a DHCPv6-request no >> matter what the RA is signaling in its M and O-flags.  And I know >> implementations that will not automatically send dhcp-requests no >> matter what flags are set in the RA-packets. >> >> We don't need even more flags that might or might not be ignored by >> the operating systems. And which have a somewhat vague definition. >> > And which is not absolutely necessary for bootstrapping. >> >> We don't have a flag to tell the OS to not run DECnet, Appletalk or >> IPX.  We simply disable these on the clients.  And even if we had >> such a flag in DHCPv4 or RA, I - as an admin - would prefer the >> clients to not rely on such a flag, but try to get some kind of >> network access on any enabled network protocol in the client. >> >> >> Rgds. >> >> Ola (T) >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --------------DBBCA1C34EEF4DF65C991959 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



Le 01/11/2018 à 13:19, Joel Jaeggli a écrit :


On Oct 20, 2018, at 10:34, Ola Thoresen <ola@nlogic.no> wrote:

On 20/10/2018 00:12, Ole Troan wrote:



In my view, I don’t see much purpose in the bit unless it’s prescriptive. As in the last category. 


On this, we can agree. Having a flag as a "hint" does not make much sense.  You can't trust it, so you would STILL need to verify if the flag is actually telling the truth, or if it is just set - either malicious, or by mistake. 

I can’t really trust (ND, RAs, ARP, DHCP, DHCPv6, MDNS).

It should not be difficult to slightly secure the RA that contains the IPv6-only flag.  A check of the existing L2 address in NC for the GW of the default route, against the L2 source address of the L2 header of the RA containing IPv6-only flag, should add some insurance.  On cellular links, the reliance on SIM cards should be sufficient.

Alex

Lack of trust here extends to most of the signals one might receive in the process of bootstrapping. Of those signals some of them I accept because as part of a faustian bargain I made when attaching to the network, I actually need some of that information. The stuff that I don’t have to accept in order to achieve basic functionality I ignore.

As  case in point all the operating systems I use allow me to specify my own nameserver despite receiving such information  via DHCP/DHCPv6, doing so may come at the expense of some local funcationality but it’s worth it as far as I’m concerned.

On the other hand, I do not see how this can be a hard requirement.  Or at least I can not see operating systems actually obyeing such a flag.  IF the client administrator has configured IPv4 dhcp client settings, why should the OS trust a flag in an RA-packet more than the OS-admins configuration?

Just look at the already defined flags "O" and "M" - which are not even breaking the barrier between the IP-protocols.  I know at least a couple of implementations which will send a DHCPv6-request no matter what the RA is signaling in its M and O-flags.  And I know implementations that will not automatically send dhcp-requests no matter what flags are set in the RA-packets.  

We don't need even more flags that might or might not be ignored by the operating systems.  And which have a somewhat vague definition.

And which is not absolutely necessary for bootstrapping.

We don't have a flag to tell the OS to not run DECnet, Appletalk or IPX.  We simply disable these on the clients.  And even if we had such a flag in DHCPv4 or RA, I - as an admin - would prefer the clients to not rely on such a flag, but try to get some kind of network access on any enabled network protocol in the client.


Rgds.

Ola (T)


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



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

--------------DBBCA1C34EEF4DF65C991959-- From nobody Thu Nov 1 11:43:56 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F22128A6E for ; Thu, 1 Nov 2018 11:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 GRQzxi9IIqxX for ; Thu, 1 Nov 2018 11:43:51 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 AF4C5129BBF for ; Thu, 1 Nov 2018 11:43:42 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA1Ihe7m013380 for ; Thu, 1 Nov 2018 11:43:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=Sd+++jTJYLCzztm01Ru56b1WU62YBnnPHoPiqRqKmZI=; b=T/VVqfZDoxCSBYDAQhkJLZRFlbQhvmi0om8Ey0riwp3qL0jZ1Qg9JFe7VIxCcdlqfac0 EKBwY7w/mjmLV4VQQcwgWBGBj9/70tQFYj9N0rcQhMkFdOjMc3sdGeROX2EdUhYFXnJX E0ntYYd2khT0HQDRX/VJjU72g8tEeQqMivYTXGeyji1bYiiNE5Sux0fEM5QhlptSLqgP GA1Yq2I0TxEWub2V5/RjmeRYfc8bd1dYrUVBnqm0zWFX0x2sFT/C/qvRck0W8CY2FC/Z Bh272Hhtk739+bO54J9STuP0qi9K49G5TJPW4zf9cHwhnO8anEdHKCQuzx7eKwTUPf1l 9A== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0049.outbound.protection.outlook.com [216.32.181.49]) by mx0b-00273201.pphosted.com with ESMTP id 2ng22r0h88-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 01 Nov 2018 11:43:39 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4726.namprd05.prod.outlook.com (52.135.233.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.13; Thu, 1 Nov 2018 18:43:37 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772%5]) with mapi id 15.20.1294.018; Thu, 1 Nov 2018 18:43:37 +0000 From: Ron Bonica To: IPv6 List Subject: draft-ietf-6man-segment-routing-header-15 Thread-Topic: draft-ietf-6man-segment-routing-header-15 Thread-Index: AdRyDvu4FzhF5rDiS9auJmSAqrSxPQ== Date: Thu, 1 Nov 2018 18:43:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.500.58 dlp-reaction: no-action x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4726; 6:GlZMwXwTFIPoN9Fu7syUGZ8JSJ0eILQ5QfoPPknt45xofh5vxkZSL2i5gdAuf4DW1YPeDuBZT45PiNeAu3HdJYj8xMRL+wizyilgJvc7A/9MMTTuj3G176tzIWhWj88BalIbqnkQFmeg0E/v8dJ7tErU5t2tDj5v8vPgGT/+sE3FtCjNH9k5xkG0UPBr7xdeDrjetkQ9sO//DSnuAAUftQuCNEBUnk2Z1kNhLqJpVu7hzy3Oi1pH187QpzA9MU+Yr+/AqgA2tVrYkggPvdbBQOlR2JXhsY/CAQcdLXfwHYSbhCZ8VMI9ZWGTTWGFiJg2mqkE4rtfuTZ5VeCyb7uT9DILQxZkNERh1XEKGcCB2LwVTRuQnziLhg6miViGjcAevEObkDjXud5ikMhDY6V0FKII6q1czH/mXRXU3K3p+ZTbXAzvaMYpTpLQ18+Phy4QVnT7fCfv2riFu9oe/0TbdQ==; 5:m3NI+yiCaSsf4VECdnjlLZPQbymMf/lyeJmKBk9RH3Xgt0p9rmOnTmR2D5DNIoReIN457DdbSpNp1GhWbA9jKZZvQRXT9ylO8WGpNiBczkHdb6T8SBTPhF6TTiK4KNJ0n4c/CSb1G8Qf4LkHjoUhgRyB8VES9gU4RIZGBa/Q6bM=; 7:T78VW6Xc/MmqasQWmsQZHGMq71wjQOWDt8c1Lumv25/hucIwwXy8vLeTVV6b+cN0CCd2KLoZnZgD4IAe8UbK53lPtuqJtCUrfKwafhn/DHta9+BJJ2bUIRdJKwxiMFAGkIaGfZOWpmy4i+Eu0UZs/g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4f5f3ea7-f224-44d3-372b-08d64029ef6a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4726; x-ms-traffictypediagnostic: BYAPR05MB4726: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB4726; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4726; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(39860400002)(396003)(366004)(189003)(199004)(51444003)(105586002)(316002)(8936002)(7736002)(305945005)(55016002)(2906002)(106356001)(81156014)(99286004)(81166006)(8676002)(53936002)(97736004)(86362001)(5250100002)(33656002)(476003)(6116002)(71200400001)(71190400001)(9686003)(3846002)(14444005)(486006)(256004)(6916009)(6506007)(25786009)(68736007)(26005)(102836004)(186003)(14454004)(66066001)(6436002)(478600001)(7696005)(5660300001)(74316002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4726; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: Fb/mgDp7AB83Qme+OlBdRNZcnGM9nliemorHDaJobRfa2JVd+7+EJo8Ki6A3t2suVOZmR0OeiIgxCRMge4Eqqpt8nQSab6jvI1BmZoTi0GvtnmESSXA02ZbW7eve5QLFGZSqmCtv5Esn0JwyWylZ6PizJg6ldMdSZK+w6kGiV38xAD3Kn3IELirDlDLLD1ROymzcK98vzbjnNObYQDfiQ4zj8jzv+H2dVgoCFVlm/MhD/MBIdXY9uMhIXjaq2RGATtLthYx2f93lC6ekta/MGcHjmSvI1ScVXpbOxKRjDwQutnYMuZF2eyleg1JGxhXreu2vR/odMe891wg2N/uZMOzEeA1Tpmagy9+LzIZ7qf8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 4f5f3ea7-f224-44d3-372b-08d64029ef6a X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2018 18:43:37.2735 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4726 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-01_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811010156 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 18:43:55 -0000 Folks, This version looks much better. Thanks for posting it.=20 The following are a few comments that I am sure can be fixed easily: Major Issues: - In Section 2.1.2.1, did you really mean to say that the HMAC is calculat= e over the Segments Left field? Given that Segments Left is mutable, what v= alue should be used? - In Section 4.3.1.2, there may be a sentence missing. Under what condition= s should the ICMP Parameter Problem message be sent? - RFC 4302 says, "As a new extension header or IPv4 option is created, it w= ill be defined in its own RFC and SHOULD include (in the Security Considera= tions section) directions for how it should be handled when calculating the= AH ICV." I think that this requirement can be satisfied with a very short section th= at contains three bullets lists. The bullet lists would say which SRH field= s are mutable, predictably mutable, and immutable. (These words are associa= ted with processing rule in RFC 4203.) Minor Issues: - The draft doesn't tell the reader what to do when the receive a non-zero = tag field. In fact, the document says, "The allocation and use of tag is ou= tside the scope of this document." I think that we need to either define the tag field or take it out of this = document. - Same argument for the Flags field. = Ron From nobody Thu Nov 1 12:57:27 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB7712D4E8 for ; Thu, 1 Nov 2018 12:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 irVaNucNB9DC for ; Thu, 1 Nov 2018 12:57:23 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 C6B76128BCC for ; Thu, 1 Nov 2018 12:57:23 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA1JtTI9004534 for ; Thu, 1 Nov 2018 12:57:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=iwGx2TQBOhEmXLa/+HgUPb2kVhQBhr6ark4R5giJ3no=; b=m8C5SSvxH2zHb42/zthx/CiE2kBHZ7E5EKLkwga8dGCOVhRc6AxE0/TS+OWWMg5jqCyN tsWlPuBgWalk8Nwt8FlX8M42CdDqYjwGKx91+q4KMWOlPIti1PviEvXg5iK6KF0Lvu9c sDvsQ8iO33SBx6cHlYNg94nGvmhR7PK/1cqno3XWb7CTgVQkKauf/ymZwJaHSEA0s7up DNYb0rGqVwMrUhadJiv7NOnFhBHTENCbN4/Y68h6DGNFtsK/sQdm22wjgBg41ajZHBZ+ 8hcZA1UX+5oERpa0C5UZ0vLO1dZoUXq8uXKzYZv1A/J99RuoTJ/5xTuLezMOwnEbJgGW UA== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0018.outbound.protection.outlook.com [207.46.163.18]) by mx0b-00273201.pphosted.com with ESMTP id 2ng22r0mry-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 01 Nov 2018 12:57:22 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB5559.namprd05.prod.outlook.com (20.177.186.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Thu, 1 Nov 2018 19:57:20 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772%5]) with mapi id 15.20.1294.018; Thu, 1 Nov 2018 19:57:19 +0000 From: Ron Bonica To: IPv6 List Subject: draft-herbert-ipv6-update-opts-00 Thread-Topic: draft-herbert-ipv6-update-opts-00 Thread-Index: AdRyFs8z8S8oZQxhQF2Avcuk85keIQ== Date: Thu, 1 Nov 2018 19:57:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.500.58 dlp-reaction: no-action x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5559; 6:VrMR8S4lnaEcwQqRJBjd1PrdsLJvEJQeJxPsQT2mYFsDPWvf99m486B1o+qfVDkSA5kd/Lt/4ex9bIk3SUS+EyNn/BOiWhU4dxBP87fZDNqlT2uIhe2SGGH57Dvs4wPJWFqekWQiDXRgNGcIdf4Mw3l//upqUbSOwAEnbCBEfeHcqz9p5k887aXBBPZ35FDATv2owPeq6aQMRvULqVMss9+vlpCVAyRFSgKS6vx5iZlHmAgT4QaG3ipzh3L5j9B1cB0TimKkvd1fA4LyRF+R4AwzTKSe3xjBpOmovtrOJ+3pficMOflNNcsn6KgkNoLinmOFFp2uH0nCG4Mhr9gCvj8noSC06XzIQWWYN0fT4y7BbGTHB0Dfy5sVii/d17ZiMWlgAoXk+yvZINaTndXKz8aJ8mKiGjpf8C/x2H0N6tNkKL/+BG6KGC2cN3iFgJZ2RYWGcr6yllZd6U4T5SsiJQ==; 5:PF9al4FeWYLIOFrWEL1XRW9Ke9NL7yjFo5heNFseQFRbmZk+Ob8VtZMDnr04NhIF0wbOYurhuPJ3wBQEzIisL0VFrNrKuhiUYTIxguEzYeEgldndFPIAj+CGXLSgst2Ndvf6r5W7tJ1Cg3XSJY0KUUMWDPTbjZKSFgwRNrFydkI=; 7:hx3yliMJIoKssJiGlqjKLsYwwI9sHKfYaf7IYlSOARG+Ed+cSXkDM7VTf72vT4tNwhV1Jw7R+fYIm9ceHpo1YmEb9hveDewq1D2UMpcBDmpury2dKn2jauFGPGI9skZCJNALuNbT/l90rnmZVhz9dA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 70b55f94-3514-43ba-cc88-08d640343b78 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5559; x-ms-traffictypediagnostic: BYAPR05MB5559: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB5559; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5559; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(376002)(39860400002)(366004)(346002)(51444003)(189003)(199004)(53936002)(9686003)(55016002)(6436002)(3846002)(6116002)(97736004)(14454004)(86362001)(6916009)(74316002)(305945005)(2900100001)(7736002)(106356001)(5250100002)(66066001)(5660300001)(26005)(15650500001)(99286004)(25786009)(7696005)(102836004)(478600001)(2906002)(186003)(476003)(316002)(71190400001)(105586002)(8676002)(81166006)(81156014)(8936002)(486006)(68736007)(71200400001)(256004)(33656002)(6506007)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5559; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: mFn/AEQDEM2krPokpab2gb5VRFJFrb/56uyPAJEsR02bvKieEnNl02MJFEJZwDSG06NOyd+ee4N1f9c4imWbDLiQ9ZBXyTiZ2IyNleUGjxe54UaO3sGoEyElJrIwAvbvb63rzAgI+CaRUA9tRTRFXk3gyCnIPDDT7ogNmKFlcn75hDQZJ7UugIrqcsdvFAfG5sprVwt5mVDiW2bYpTTyYCrZbARtv7iXAQg8I/eiEbAd1hKzDwVPV9P9Mq3wHX06YD6GWfFRcgNnbRRLz7VGyWkFK0fRaHRydXabZ3WOivDZGwwZlfkCsvPmhBvZKaekh28K5PLmlbI14mC32vhqTjYIEAdcLOPl2CM6lFRJdKc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 70b55f94-3514-43ba-cc88-08d640343b78 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2018 19:57:19.8812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5559 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-01_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=844 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811010166 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 19:57:26 -0000 Hi Tom, In your draft, you propose a rule forbidding updates to the Option type. Wh= ile I agree with this rule in the vast majority of cases, I would like to p= ropose an exception. An intermediate node MAY update an Option type if all = of the following conditions are true: - the new Option type, if recognized by the destination node, will cause th= e packet to be discarded - the new Option type, if not recognized by the destination node, will caus= e the packet to be discarded (i.e., The new Option type begins with 01, 10= , or 11) - the option data length is zero before the update - the option data length is zero after the update An optimization in draft-leddy-6man truncate can be preserved only if that = exception exists. If you like, we can do a deep dive into the details of th= at optimization. But I think that the exception requested above is narrow e= nough that we may not need to go there. Ron =20 From nobody Thu Nov 1 16:24:05 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A323E1271FF for ; Thu, 1 Nov 2018 16:24:03 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 ekeBJjDuD3Ri for ; Thu, 1 Nov 2018 16:24:01 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 89FAE12958B for ; Thu, 1 Nov 2018 16:24:01 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id d19so300113qkg.5 for ; Thu, 01 Nov 2018 16:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4ZxiLAJWly9VhjydGm9mzZwCNS28L7CTjr6dMLz5ufc=; b=YvXqsBjXVGd1uvr5DPkAUblqVX/Xtq1b3Kuixw7t7cSrS9ASaPIsVzwfnX17RfxChf Xd55EuGGj8IEiXHD4j336dhbDNU2GEFXGQvLEt334RDHgK/QuNXEAhy8hr/n0X5TQyuK wQOCZ6bNsF44viK7NWt3EaD7HS86ZvCi9fH4Uy/8hbdl+t9QkTFlborByj4inrL0HYna LWrZWCqYk6MWSWO9SZJzcBhqcRLkWiGCMLA/0OZJl282laAN2IJXuNuCNqJWChofY6Jw koYwCJLfkzgnb1Zzs+XLophF/AzVtn6fGWcVoSYrPjyCTswvHD3yc7HUjEf3qN1ZjfrV c5bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4ZxiLAJWly9VhjydGm9mzZwCNS28L7CTjr6dMLz5ufc=; b=nTpD1fYNQ38etG/xFNjd2N/B69w+93HovQsxkL4IJ8YC/14m74j7JG8SJhe2S4NRbp 8ivBzNypeBPeU2UI+n0H0eEhUUwvniJLKYb1nOe7pfGLPGU8cc/yNpbu8Gf3RP+CBsp/ /1C81E9/i6RMYLotV5lh2z1UrEmtSjCF1iPrEetcwYyzif+5ZAs9jNmj2dIJCXfbQsZ5 QvWjILdZw8F4tBVcyPhCTnGW+Z4DxPLn6BX7cbFpRyNvX5WObjDQnkloLXT3DoLLd8sf s62K2ZqikcpEVs7sLA084AbRDLq1BcMXH8/1Q2GF7GhjupXqCOcTKfFfWsRM6eYbQLE0 1bhA== X-Gm-Message-State: AGRZ1gK/NEfx5l6Gew7GPI8rH7hfGx0waCJrDhdFKS9sSEsBOZreech1 iCbJurQe6Ka+7TSHe2ksCpPlWhO9p2JyK3ZW4zim2n8Jvi4= X-Google-Smtp-Source: AJdET5fIGA/p6SjHesE7ILXfvMb7tK/ZR+bgbvrLE8vRBsbdGjdDhuMTRr1eQiK9aFTOQaKJw3IRQErQ147cp5FxNUU= X-Received: by 2002:a37:5bc1:: with SMTP id p184mr6315443qkb.121.1541114640525; Thu, 01 Nov 2018 16:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:2022:0:0:0:0:0 with HTTP; Thu, 1 Nov 2018 16:24:00 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 1 Nov 2018 16:24:00 -0700 Message-ID: Subject: Re: draft-herbert-ipv6-update-opts-00 To: Ron Bonica Cc: IPv6 List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 23:24:04 -0000 On Thu, Nov 1, 2018 at 12:57 PM, Ron Bonica wrote: > Hi Tom, > > In your draft, you propose a rule forbidding updates to the Option type. = While I agree with this rule in the vast majority of cases, I would like to= propose an exception. An intermediate node MAY update an Option type if al= l of the following conditions are true: > > - the new Option type, if recognized by the destination node, will cause = the packet to be discarded > - the new Option type, if not recognized by the destination node, will ca= use the packet to be discarded (i.e., The new Option type begins with 01, = 10, or 11) > - the option data length is zero before the update > - the option data length is zero after the update > > An optimization in draft-leddy-6man truncate can be preserved only if tha= t exception exists. If you like, we can do a deep dive into the details of = that optimization. But I think that the exception requested above is narrow= enough that we may not need to go there. Hi Ron, Personally, I am skeptical about truncating packets being robust and I don't think your exception would be the only one. It's possible that truncating packets has side effects. For instance, the draft states to: "Truncates the packet, so that its new length equals the MTU of the next-hop link." But what if the total length of extension headers of the packet are greater the new MTU? If an intermediate truncates EH that is equivalent to dropping EH and probably creates a mismatched length on final EH. Even worse, what if it's a segment routing header that is truncated in this process so that it renders the packet undeliverable. Also, if transport layer ports are truncated then packet would be blocked by FW. A couple of other questions related to the draft. It states: "When the destination node receives a packet that has been truncated, it sends an ICMP PTB message to the source node." But one of the reasons intermediate devices don't want send ICMP is "o A firewall on the path between the downstream router and the source node administratively blocks the ICMP PTB message." Why would sending an ICMP from the destination be more likely to succeed than sending from an intermediate node? I would think an ICMP sent from the intermediate node has the greater chance of success since it is closer to the source. Also, o The source address of the original packet (i.e., the packet that elicited the ICMP PTB message) was an anycast address. Therefore, the destination address of the lso, if ICMP PTB message is the same anycast address. How does the ICMP message sent from the destination host avoid a problem he= re? Tom > Ron > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Nov 1 22:53:21 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EDB127B92 for ; Thu, 1 Nov 2018 22:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 fluMiolBGc8N for ; Thu, 1 Nov 2018 22:53:17 -0700 (PDT) Received: from atl4mhob23.registeredsite.com (atl4mhob23.registeredsite.com [209.17.115.117]) by ietfa.amsl.com (Postfix) with ESMTP id 84FDD127332 for ; Thu, 1 Nov 2018 22:53:17 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob23.registeredsite.com (8.14.4/8.14.4) with ESMTP id wA25rDqe109156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Nov 2018 01:53:13 -0400 Received: (qmail 1532 invoked by uid 0); 2 Nov 2018 05:53:13 -0000 X-TCPREMOTEIP: 14.143.0.166 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?172.18.0.22?) (lee@asgard.org@14.143.0.166) by 0 with ESMTPA; 2 Nov 2018 05:53:13 -0000 Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> From: Lee Howard Message-ID: <272233d0-8661-9d3a-1252-024f0b674e1b@asgard.org> Date: Fri, 2 Nov 2018 11:23:09 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 05:53:20 -0000 On 11/1/18 1:13 AM, Brian E Carpenter wrote: > but I haven't seen any proposed text changes since > the current draft came out. https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm Lee From nobody Thu Nov 1 23:09:26 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0CF129C6A for ; Thu, 1 Nov 2018 23:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 ji6AHn6mdBL0 for ; Thu, 1 Nov 2018 23:09:20 -0700 (PDT) Received: from atl4mhob07.registeredsite.com (atl4mhob07.registeredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF9E127B92 for ; Thu, 1 Nov 2018 23:09:20 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob07.registeredsite.com (8.14.4/8.14.4) with ESMTP id wA269GuR029380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Nov 2018 02:09:17 -0400 Received: (qmail 4730 invoked by uid 0); 2 Nov 2018 06:09:16 -0000 X-TCPREMOTEIP: 14.143.0.166 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?172.18.0.22?) (lee@asgard.org@14.143.0.166) by 0 with ESMTPA; 2 Nov 2018 06:09:16 -0000 Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> From: Lee Howard Message-ID: <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> Date: Fri, 2 Nov 2018 11:39:12 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> Content-Type: multipart/alternative; boundary="------------3339D62D3997D7259EA70FBD" Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 06:09:23 -0000 This is a multi-part message in MIME format. --------------3339D62D3997D7259EA70FBD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/1/18 1:13 AM, Brian E Carpenter wrote: > On 2018-10-31 22:24, Nick Hilliard wrote: >> Job Snijders wrote on 30/10/2018 22:27: >>> Can you (or others running FreeBSD EXPERIMENTAL) share reports on how >>> this pans out in practise? >> Looking at the code, it acts by blocking outbound ipv4 frames from being >> transmitted on ethernet interfaces. This would mean - for example - >> that if there were a default route already configured on the receiving >> device, any userland code attempting to use ipv4 services would block >> until ARP times out for the default route (default 20 minutes on freebsd). >> >> The only part of the ipv6only discussion that was uncontroversial was >> implementation of the kernel processing side of this flag - there's very >> little to go wrong when toggling a single flag. >> >> The problem area is how to handle the interpretation of this flag in >> userland and in the kernel, which is a much more difficult problem. > It's a question, but I don't know why it's a problem. It isn't an interop > problem, because each host is an independent actor in this. And we now have > running code proof that legacy hosts aren't affected. So I'd say that from > a protocol spec point of view, it's actually a non-issue. Doesn't it mean that user space applications on a host that had/expected IPv4 would fail? I think I described my interop concern: https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm IPv4-only hosts, and dual-stack hosts that do not recognize the new    flag, may continue to attempt IPv4 operations If some devices require IPv4 and others disable IPv4, you have lost connectivity between systems on a local network. As written, this is not considered a misconfiguration by the administrator who sets the flag. >> This also disregards the issue of whether the flag was either necessary >> or a good idea to start with, and nearly 700 emails into this >> discussion, the WG seems to be hopelessly divided on these issues. > I'll leave that one to the WG chair who isn't a co-author. But I will > say that in my mind the issue is whether the feature is one that will > be valuable in 5, 10 or 20 years time rather than whether it's valuable > today. I've come into the camp that believes that in 10 or 20 years IPv4 will be disabled by default. When people post to stackoverflow complaining that their 10-20 year old devices are unreachable from their brand new devices, the response will be, "The old stuff might be using the old protocol, IPv4. Go into Control Panel, Networking, Protocols, select IPv4, click enable." If that's likely, then this flag is only useful in the interim 5 years. During that time, I would like to maximize connectivity. If a network administrator wants central control over IPv4/IPv6 enablement in hosts, there are better, more centralized tools for that. As a principle, host behavior should be managed by host management tools, and not by hints from a router. Lee --------------3339D62D3997D7259EA70FBD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/1/18 1:13 AM, Brian E Carpenter wrote:
On 2018-10-31 22:24, Nick Hilliard wrote:
Job Snijders wrote on 30/10/2018 22:27:
Can you (or others running FreeBSD EXPERIMENTAL) share reports on how
this pans out in practise?
Looking at the code, it acts by blocking outbound ipv4 frames from being 
transmitted on ethernet interfaces.  This would mean - for example - 
that if there were a default route already configured on the receiving 
device, any userland code attempting to use ipv4 services would block 
until ARP times out for the default route (default 20 minutes on freebsd).

The only part of the ipv6only discussion that was uncontroversial was 
implementation of the kernel processing side of this flag - there's very 
little to go wrong when toggling a single flag.

The problem area is how to handle the interpretation of this flag in 
userland and in the kernel, which is a much more difficult problem.
It's a question, but I don't know why it's a problem. It isn't an interop
problem, because each host is an independent actor in this. And we now have
running code proof that legacy hosts aren't affected. So I'd say that from
a protocol spec point of view, it's actually a non-issue.

Doesn't it mean that user space applications on a host that had/expected IPv4 would fail?

I think I described my interop concern: https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm

IPv4-only hosts, and dual-stack hosts 
that do not recognize the new
    flag, may continue to attempt IPv4 operations

If some devices require IPv4 and others disable IPv4, you have lost connectivity between systems on a local network. As written, this is not considered a misconfiguration by the administrator who sets the flag.




This also disregards the issue of whether the flag was either necessary 
or a good idea to start with, and nearly 700 emails into this 
discussion, the WG seems to be hopelessly divided on these issues.
I'll leave that one to the WG chair who isn't a co-author. But I will
say that in my mind the issue is whether the feature is one that will
be valuable in 5, 10 or 20 years time rather than whether it's valuable
today.

I've come into the camp that believes that in 10 or 20 years IPv4 will be disabled by default. When people post to stackoverflow complaining that their 10-20 year old devices are unreachable from their brand new devices, the response will be, "The old stuff might be using the old protocol, IPv4. Go into Control Panel, Networking, Protocols, select IPv4, click enable."

If that's likely, then this flag is only useful in the interim 5 years. During that time, I would like to maximize connectivity.

If a network administrator wants central control over IPv4/IPv6 enablement in hosts, there are better, more centralized tools for that. As a principle, host behavior should be managed by host management tools, and not by hints from a router.

Lee


--------------3339D62D3997D7259EA70FBD-- From nobody Fri Nov 2 02:19:54 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1467130934 for ; Fri, 2 Nov 2018 02:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 3jzAaN5Lu4K8 for ; Fri, 2 Nov 2018 02:19:50 -0700 (PDT) Received: from atl4mhob06.registeredsite.com (atl4mhob06.registeredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E26212DD85 for ; Fri, 2 Nov 2018 02:19:50 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob06.registeredsite.com (8.14.4/8.14.4) with ESMTP id wA29JlWn013739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Nov 2018 05:19:47 -0400 Received: (qmail 22325 invoked by uid 0); 2 Nov 2018 09:19:47 -0000 X-TCPREMOTEIP: 14.143.0.166 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?172.18.0.22?) (lee@asgard.org@14.143.0.166) by 0 with ESMTPA; 2 Nov 2018 09:19:45 -0000 Subject: Re: [Int-area] maprg session on Tue Nov 6, 1610-1810 To: ipv6@ietf.org References: <469F920C-974E-4DC6-AD8C-7931FDF71C6B@tik.ee.ethz.ch> <4724413F-DE32-4A41-9BD9-B880CD85FC29@tik.ee.ethz.ch> From: Lee Howard Message-ID: <6bfe27b6-6833-5fcd-b8cf-5f77ac94af0f@asgard.org> Date: Fri, 2 Nov 2018 14:49:42 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <4724413F-DE32-4A41-9BD9-B880CD85FC29@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 09:19:53 -0000 I can't come to the session since I won't be in Bangkok.  RGs don't usually put out notes. The meeting will be at 3:00am in my time zone, and I'm unlikely to get up at that hour for a 5-minute talk. Can I get a hint about what the privacy and security issues are? Thanks, Lee On 10/31/18 9:38 PM, Mirja Kühlewind wrote: > We don’t have one for this talk as it is only a 5 minutes heads up talk. Maybe Dave can provide you some more information. Or you just come to the session… > > Thanks! > Mirja > > > >> Am 31.10.2018 um 16:52 schrieb Bob Hinden : >> >> Mirja, >> >> I don’t see an abstract for "Privacy and Security Issues in IPv6 Deployment” talk on the agenda page you linked. Is that available? >> >> Bob >> >>> On Oct 31, 2018, at 5:09 AM, Mirja Kühlewind wrote: >>> >>> Hi int floks, >>> >>> we will have a short heads-up talk on Privacy and Security Issues in IPv6 Deployment. You might be aware of this work by Dave Plonka and Tobias Fiebig already. However, maybe it is still interesting you for to join! >>> >>> Here is a link to the rest of the agenda: >>> >>> https://datatracker.ietf.org/meeting/103/materials/agenda-103-maprg-03 >>> >>> The maprg session will take place on >>> >>> Tuesday, 6 November 2018, Afternoon Session II 1610-1810 >>> Room Name: Chitlada 1 >>> >>> See you there! >>> Mirja (maprg co-chair) >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Nov 2 03:05:50 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED0A12D4F2 for ; Fri, 2 Nov 2018 03:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 gXnrzm7FIfsE for ; Fri, 2 Nov 2018 03:05:46 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8451288BD for ; Fri, 2 Nov 2018 03:05:45 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6DF428D4A217; Fri, 2 Nov 2018 10:05:40 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A354BD1F865; Fri, 2 Nov 2018 10:05:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id KIu0qGfa_SWr; Fri, 2 Nov 2018 10:05:36 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AAE79D1F84D; Fri, 2 Nov 2018 10:05:35 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Lee Howard" Cc: ipv6@ietf.org Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Date: Fri, 02 Nov 2018 10:05:34 +0000 X-Mailer: MailMate (2.0BETAr6125) Message-ID: <07D3463F-963B-4BDA-9109-946824DF25E9@lists.zabbadoz.net> In-Reply-To: <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 10:05:49 -0000 On 2 Nov 2018, at 6:09, Lee Howard wrote: > Doesn't it mean that user space applications on a host that > had/expected IPv4 would fail? > > I think I described my interop concern: > https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm > > IPv4-only hosts, and dual-stack hosts > that do not recognize the new >    flag, may continue to attempt IPv4 operations > > If some devices require IPv4 and others disable IPv4, you have lost > connectivity between systems on a local network. As written, this is > not considered a misconfiguration by the administrator who sets the > flag. The draft says “ Dual stack hosts that have a good reason to use IPv4, for example for a specific IPv4 link-local service, can attempt to do so. Therefore respect of the IPv6-Only flag is recommended, not mandatory, for hosts. Administrators SHOULD only use this mechanism if they are certain that the link is IPv6-Only. For example, in cases where there is a need to continue to use IPv4, when there are intended to be IPv4-only hosts or IPv4 routers on the link, setting this flag to 1 is a configuration error.” And heck, if user space applications fail because v4 doesn’t work anymore, than they work based on an assumption (and have been for 20 years) and they’d better get fixed. Here’s how it goes: (a) network admin turns ipv6-only on, 98 of 100 hosts are fine; 2 hosts with their secret covert channel no longer talk for some obscure thing interacting on the local network only. (b) users panic looking at their “very important service” (e.g., their private chat protocol written out of boredom at the end of 1999). (c) admins shrug and move these two machines into a quarantine network where they can still talk ipv4 and will be (1) running forever until the hardware dies, (2) until someone fixes the software to use ipv6, (3) for the next 6 months until the vlan is decommissioned. The answer is: if that service is critical you will (A) be happy you found out about that problem if no one knew about it before and (B) you’ll do everything to fix it in a good way (and that could also be to disable that flag for another two weeks until everything is sorted). But you’ll fix that software. If it’s not relevant it goes into “collateral damage” and you are happy that the thing is gone from your network and your “network hygiene level just went form orange to green”. I’ve played these games for more than 8 years. And you have to play them a lot less these days compared to 2010. I guess it all depends how you arrive at the day to “turn the IPv6-Only flag on”. Ideally you have selective removed IPv4 from the network before so the flag more or less ends up to be just a “OK, this is IPv6-only so make sure it stays that way” for where you have critical services. But this is all “ops” and not 6man. >>> This also disregards the issue of whether the flag was either >>> necessary >>> or a good idea to start with, and nearly 700 emails into this >>> discussion, the WG seems to be hopelessly divided on these issues. >> I'll leave that one to the WG chair who isn't a co-author. But I will >> say that in my mind the issue is whether the feature is one that will >> be valuable in 5, 10 or 20 years time rather than whether it's >> valuable >> today. > > I've come into the camp that believes that in 10 or 20 years IPv4 will > be disabled by default. When people post to stackoverflow complaining > that their 10-20 year old devices are unreachable from their brand new > devices, the response will be, "The old stuff might be using the old > protocol, IPv4. Go into Control Panel, Networking, Protocols, select > IPv4, click enable." Very much like people posted “My token ring can’t talk to my ethernet?” Look in 10 years the IPv4-only Islands will be very much understood. People will be looking for “migrating” these to “something entirely new”. > If that's likely, then this flag is only useful in the interim 5 > years. During that time, I would like to maximize connectivity. The flag will still be useful in 127 years when people will do IPv9 and there’ll be people around who say “This IPv9 stuff I am not going to touch, keep this legacy IPv6 on until everyone else in the world has moved. Then I can go and look.” > If a network administrator wants central control over IPv4/IPv6 > enablement in hosts, there are better, more centralized tools for > that. As a principle, host behavior should be managed by host > management tools, and not by hints from a router. Or by hints from a central directory service? I guess it’s better I’ll remove your host entry from my dhcp server as well immediately then. And also stop answering ARP and RS for you. You can configure that using your host tools. /bz From nobody Fri Nov 2 07:36:04 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2036B1286E7 for ; Fri, 2 Nov 2018 07:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 K5W3KhwAXNIP for ; Fri, 2 Nov 2018 07:35:59 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 7F200123FFD for ; Fri, 2 Nov 2018 07:35:59 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA2EYw6Z016512; Fri, 2 Nov 2018 07:35:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=MA91qiY8rFHi8/8karbiQVp3PgYEG/NJUel2rxPqhZ0=; b=bJuGbhlJhOdO20Lr09IX/UKql2ktdaihiiTAcro2di/0oqKlQKgIJaRPkEZmGYWnbJEF kRi/Fd7mkhULvrLezvQkKurD7FbsFiZWpjklAO0wAJ0WRNHGXbz+Dpf+onEF7AedMjtP +QlEgG5vawj+0qzB5c9pmrZVugnV8t7lQdFMx3hjp0kqEO5sr1xsEYiROpTdgG0m4Ap5 ghJOosTiYmlbN3zq8/OZYmfOBGL3o5Y4sOs/+Af/IgQWyMr/EYu+0nHs5A0qWpAepZIa H9IQf4N6epTy1M3BzIdVXmgkTY9WVsWwKGwRKbja9Di/St/pDw2+UMuHYFUTdR3Blz4n Zw== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0079.outbound.protection.outlook.com [207.46.163.79]) by mx0b-00273201.pphosted.com with ESMTP id 2ngr3xg2rg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 02 Nov 2018 07:35:58 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB5064.namprd05.prod.outlook.com (20.177.230.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.16; Fri, 2 Nov 2018 14:35:55 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772%5]) with mapi id 15.20.1294.024; Fri, 2 Nov 2018 14:35:55 +0000 From: Ron Bonica To: Tom Herbert CC: IPv6 List , "Joel M. Halpern" Subject: RE: draft-herbert-ipv6-update-opts-00 Thread-Topic: draft-herbert-ipv6-update-opts-00 Thread-Index: AdRyFs8z8S8oZQxhQF2Avcuk85keIQAIyjMAAB7L6FA= Date: Fri, 2 Nov 2018 14:35:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.500.58 dlp-reaction: no-action x-mcafeedlp-tagged: True x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5064; 6:Dr7Sx7CnP4wYmZjsVOBJTgUBG5ZlXZEl7l7BGkOJvqQtTj/Nt35kujLnVSz3TZdDovsJeP0asYkq+obY1Abh3sPdZqHrNKrxGnhlkx54F16QczpaZ5z00t3aZhn2f3VgtaMi+s9FT/kTv9Ql1Ip7bnTOtrplefHWtG6/dHlq4pjrzBNUkD6jLXegH2C858bnltrMgtKaYlUByFEGqKRHKz57xTzSc6XDuI8WFmRwynGyQVcblCmzooQOsghzfS5/8s30ub0T1TdDEOAiGBlctvB+2ubFKduUguSsLDRqNKO3GLdOWvjnuW7JlJjZrM/lIkEJMXEeADs8GVE49ksxH7Jy7VBntf7M5G4vNR43sgX9lmMKoSTpCZdnHI8h8rY45UlrIOua88By2zx2Wf+XiLsYgvGAd5Tele2kYfsWjPcHltNgSiKxFnRilDZOYz2IzpZYyQiv2vZcGOIkZm54vg==; 5:h+BVfTd+9wlMfZkOwoExK9Ttlir1MsnLTYSaCmqnvTsp0fMqYDBEih5laiaWHEGm8EXMdFasAr3qxRAZ1DDlc9iqz9uDy2MLi5vDb4q/4g3KUOlEWn5GYkuHveUjasQ/7vWunnp21IqAugyZBakRYK/Ui1M6+sX/kJVvXwDUvsU=; 7:aGPr5J52GCYrmhQIj7qg0Fjf4eO/bMpCcfcu5TWyfDNcvA5PVDeCbFQOITs3rRywysSGkoc4zj0BS3TVCTHQxFVPvsp7Qgk76kGrS7SXm3d5lH2vbAtKDuizMa1FA1s0fkzRetTkrw+It7G9M6jrSg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6fc1a030-aed3-4cb9-5b5e-08d640d07f4a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5064; x-ms-traffictypediagnostic: BYAPR05MB5064: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB5064; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5064; x-forefront-prvs: 08444C7C87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(136003)(396003)(366004)(189003)(13464003)(199004)(51444003)(106356001)(6506007)(66066001)(19627235002)(14454004)(446003)(74316002)(54906003)(15650500001)(33656002)(11346002)(53546011)(99286004)(6436002)(6916009)(256004)(305945005)(14444005)(5660300001)(476003)(97736004)(486006)(966005)(76176011)(7736002)(68736007)(478600001)(8936002)(7696005)(6116002)(6246003)(86362001)(3846002)(575784001)(6306002)(316002)(9686003)(8676002)(2906002)(4326008)(25786009)(53936002)(105586002)(26005)(71200400001)(71190400001)(229853002)(55016002)(81156014)(81166006)(102836004)(186003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5064; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: PBifwwhl/Ma1y1XB+RXQARuZj3sY05yRQaT+c6GEWEb2CZYPAeeliYkQEFOTLsymPZ9Xq49tfB5mHAibK3FbslCuz/chGTGyBvPQOKMeq1ye/3OTmq+mlFHqUChDTG36IYh+R8ifByjmfDjntaT/9dShWnVU6ez4fv7SAw5OOYa3IhuSWwnf1bKgUQqEUdjrCIgTZNu6n5cR+KWEZo9g5k4+QhU72CnU+G2K99IKxaYtpaM2Rro8GShGwytQV0U/htbfpFBa1HrFpILny12utuCVFgCDM27M0BQwiNPdvEy/1dXReE7Zg89Hb2SGwA6owMmms6YIoIJp3lqz3W2A2xAgy5UeoI/NA6vqm7rUhLk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6fc1a030-aed3-4cb9-5b5e-08d640d07f4a X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 14:35:55.0487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5064 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811020133 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 14:36:02 -0000 SGkgVG9tLA0KDQpJIGNhbm5vdCBhcmd1ZSB0aGF0IHlvdXIgZHJhZnQgc2hvdWxkIGluY2x1ZGUg YW4gZXhjZXB0aW9uIGJlY2F1c2UgYSkgdGhlIHRydW5jYXRpb24gZHJhZnQgcmVsaWVzIG9uIGl0 IGFuZCBiKSB0aGUgdHJ1bmNhdGlvbiBkcmFmdCBpcyB3b25kZXJmdWwuIFRoZSBmaXJzdCBzdGF0 ZW1lbnQgaXMgbm90IHRydWUuIEkgY291bGQgcmVtb3ZlIGFuIG9wdGltaXphdGlvbiBmcm9tIHRo ZSB0cnVuY2F0aW9uIGRyYWZ0IHNvIHRoYXQgaXQgbm8gbG9uZ2VyIHJlbGllcyBvbiB0aGUgZXhj ZXB0aW9uLiBUaGUgc2Vjb25kIHN0YXRlbWVudCBpcyBzdGlsbCBhIHRvcGljIG9mIGRlYmF0ZS4N Cg0KSG93ZXZlciwgSSBjYW4gYXJndWUgdGhhdCB5b3VyIGRyYWZ0IHNob3VsZCBpbmNsdWRlIHRo aXMgZXhjZXB0aW9uIGJlY2F1c2Ugb3ZlcndyaXRpbmcgdGhlIE9wdGlvbiB0eXBlIGluIHRoaXMg b25lIHBhcnRpY3VsYXIgY29ybmVyIGNhc2UgY2F1c2VzIG5vIGhhcm0uIFVubGVzcyB5b3UgY2Fu IHNob3cgaG93IGl0IGNhdXNlcyBoYXJtLCB0aGUgYmxhbmtldCBydWxlIGlzIGRpZmZpY3VsdCB0 byBkZWZlbmQuDQoNCkluIGEgcHJpdmF0ZSBlbWFpbCwgSm9lbCBIYWxwZXJuICBjb3JyZWN0bHkg cG9pbnRzIG91dCB0aGF0IHRoZSBleGNlcHRpb24gIHNob3VsZCBiZSBzbGlnaHRseSBtb3JlIG5h cnJvdy4gT3ZlcndyaXRpbmcgc2hvdWxkIGJlIHBlcm1pdHRlZCBvbmx5IHdoZW4gYWxsIG9mIHRo ZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUgdHJ1ZToNCg0KLSB0aGUgbmV3IE9wdGlvbiB0eXBl LCBpZiByZWNvZ25pemVkIGJ5IHRoZSBkZXN0aW5hdGlvbiBub2RlLCB3aWxsIGNhdXNlIHRoZSBw YWNrZXQgdG8gYmUgZGlzY2FyZGVkDQotIHRoZSBuZXcgT3B0aW9uIHR5cGUsIGlmIG5vdCByZWNv Z25pemVkIGJ5IHRoZSBkZXN0aW5hdGlvbiBub2RlLCB3aWxsIGNhdXNlIHRoZSBwYWNrZXQgdG8g YmUgZGlzY2FyZGVkIChpLmUuLCAgVGhlIG5ldyBPcHRpb24gdHlwZSBiZWdpbnMgd2l0aCAwMSwg MTAsIG9yIDExKQ0KLSB0aGUgb3B0aW9uIGRhdGEgbGVuZ3RoIGlzIHplcm8gYmVmb3JlIHRoZSB1 cGRhdGUNCi0gdGhlIG9wdGlvbiBkYXRhIGxlbmd0aCBpcyB6ZXJvIGFmdGVyIHRoZSB1cGRhdGUN Ci0gdGhlIHBhY2tldCBkb2VzIG5vdCBjb250YWluIGFuIEF1dGhlbnRpY2F0aW9uIEhlYWRlciAo dGhpcyBpcyB0aGUgbmV3IHJlc3RyaWN0aW9uKQ0KDQpNb3N0IG9mIHlvdXIgY29tbWVudHMgYXJl IHNwZWNpZmljIHRvIHRoZSB0cnVuY2F0aW9uIGRyYWZ0LiBXaGlsZSBvdXIgZGlzY3Vzc2lvbiBt YXkgbm90IGJlIGFib3V0IHRoZSB0cnVuY2F0aW9uIGRyYWZ0LCBJIGhhdmUgYWRkcmVzc2VkIHlv dXIgY29tbWVudHMgaW5saW5lLCBiZWxvdy4uLi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29t Pg0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMSwgMjAxOCA3OjI0IFBNDQo+IFRvOiBSb24g Qm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KPiBDYzogSVB2NiBMaXN0IDxpcHY2QGlldGYu b3JnPg0KPiBTdWJqZWN0OiBSZTogZHJhZnQtaGVyYmVydC1pcHY2LXVwZGF0ZS1vcHRzLTAwDQo+ IA0KPiBPbiBUaHUsIE5vdiAxLCAyMDE4IGF0IDEyOjU3IFBNLCBSb24gQm9uaWNhIDxyYm9uaWNh QGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPiBIaSBUb20sDQo+ID4NCj4gPiBJbiB5b3VyIGRyYWZ0 LCB5b3UgcHJvcG9zZSBhIHJ1bGUgZm9yYmlkZGluZyB1cGRhdGVzIHRvIHRoZSBPcHRpb24gdHlw ZS4NCj4gV2hpbGUgSSBhZ3JlZSB3aXRoIHRoaXMgcnVsZSBpbiB0aGUgdmFzdCBtYWpvcml0eSBv ZiBjYXNlcywgSSB3b3VsZCBsaWtlIHRvDQo+IHByb3Bvc2UgYW4gZXhjZXB0aW9uLiBBbiBpbnRl cm1lZGlhdGUgbm9kZSBNQVkgdXBkYXRlIGFuIE9wdGlvbiB0eXBlIGlmIGFsbA0KPiBvZiB0aGUg Zm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIHRydWU6DQo+ID4NCj4gPiAtIHRoZSBuZXcgT3B0aW9u IHR5cGUsIGlmIHJlY29nbml6ZWQgYnkgdGhlIGRlc3RpbmF0aW9uIG5vZGUsIHdpbGwNCj4gPiBj YXVzZSB0aGUgcGFja2V0IHRvIGJlIGRpc2NhcmRlZA0KPiA+IC0gdGhlIG5ldyBPcHRpb24gdHlw ZSwgaWYgbm90IHJlY29nbml6ZWQgYnkgdGhlIGRlc3RpbmF0aW9uIG5vZGUsIHdpbGwNCj4gPiBj YXVzZSB0aGUgcGFja2V0IHRvIGJlIGRpc2NhcmRlZCAoaS5lLiwgIFRoZSBuZXcgT3B0aW9uIHR5 cGUgYmVnaW5zDQo+ID4gd2l0aCAwMSwgMTAsIG9yIDExKQ0KPiA+IC0gdGhlIG9wdGlvbiBkYXRh IGxlbmd0aCBpcyB6ZXJvIGJlZm9yZSB0aGUgdXBkYXRlDQo+ID4gLSB0aGUgb3B0aW9uIGRhdGEg bGVuZ3RoIGlzIHplcm8gYWZ0ZXIgdGhlIHVwZGF0ZQ0KPiA+DQo+ID4gQW4gb3B0aW1pemF0aW9u IGluIGRyYWZ0LWxlZGR5LTZtYW4gdHJ1bmNhdGUgY2FuIGJlIHByZXNlcnZlZCBvbmx5IGlmIHRo YXQNCj4gZXhjZXB0aW9uIGV4aXN0cy4gSWYgeW91IGxpa2UsIHdlIGNhbiBkbyBhIGRlZXAgZGl2 ZSBpbnRvIHRoZSBkZXRhaWxzIG9mIHRoYXQNCj4gb3B0aW1pemF0aW9uLiBCdXQgSSB0aGluayB0 aGF0IHRoZSBleGNlcHRpb24gcmVxdWVzdGVkIGFib3ZlIGlzIG5hcnJvdyBlbm91Z2gNCj4gdGhh dCB3ZSBtYXkgbm90IG5lZWQgdG8gZ28gdGhlcmUuDQo+IA0KPiBIaSBSb24sDQo+IA0KPiBQZXJz b25hbGx5LCBJIGFtIHNrZXB0aWNhbCBhYm91dCB0cnVuY2F0aW5nIHBhY2tldHMgYmVpbmcgcm9i dXN0IGFuZCBJIGRvbid0DQo+IHRoaW5rIHlvdXIgZXhjZXB0aW9uIHdvdWxkIGJlIHRoZSBvbmx5 IG9uZS4gSXQncyBwb3NzaWJsZSB0aGF0IHRydW5jYXRpbmcNCj4gcGFja2V0cyBoYXMgc2lkZSBl ZmZlY3RzLiBGb3IgaW5zdGFuY2UsIHRoZSBkcmFmdCBzdGF0ZXMNCj4gdG86DQo+IA0KPiAiVHJ1 bmNhdGVzIHRoZSBwYWNrZXQsIHNvIHRoYXQgaXRzIG5ldyBsZW5ndGggZXF1YWxzIHRoZSBNVFUg b2YgdGhlIG5leHQtaG9wDQo+IGxpbmsuIg0KDQpUaGlzIGlzIGFkZHJlc3NlZCBpbiBTZWN0aW9u IDcgb2YgdGhlIGRyYWZ0LiBTcGVjaWZpY2FsbHkuLi4uDQoNCiAgIEEgdHJ1bmNhdGVkIHBhY2tl dCBNVVNUIGNvbnRhaW4gdGhlIGJhc2ljIElQdjYgaGVhZGVyLCBhbGwgZXh0ZW5zaW9uDQogICBo ZWFkZXJzIGFuZCB0aGUgZmlyc3QgdXBwZXItbGF5ZXIgaGVhZGVyLiAgV2hlbiBhbiBpbnRlcm1l ZGlhdGUgbm9kZQ0KICAgY2Fubm90IGZvcndhcmQgYSBwYWNrZXQgZHVlIHRvIE1UVSBpc3N1ZXMs IGFuZCB0aGUgdG90YWwgbGVuZ3RoIG9mDQogICB0aGUgYmFzaWMgSVB2NiBoZWFkZXIsIGFsbCBl eHRlbnNpb24gaGVhZGVycywgYW5kIGZpcnN0IHVwcGVyLWxheWVyDQogICBoZWFkZXIgZXhjZWVk cyB0aGUgTVRVIG9mIHRoZSBuZXh0IGxpbmsgaW4gdGhlIHBhdGgsIHRoZSBpbnRlcm1lZGlhdGUN CiAgIG5vZGUgTVVTVCBkaXNjYXJkIHRoZSBwYWNrZXQgYW5kIHNlbmQgYW5kIElDTVAgUFRCIG1l c3NhZ2UgdG8gdGhlDQogICBzb3VyY2Ugbm9kZS4gIEl0IE1VU1QgTk9UIHRydW5jYXRlIHRoZSBw YWNrZXQuIg0KDQo+IA0KPiBCdXQgd2hhdCBpZiB0aGUgdG90YWwgbGVuZ3RoIG9mIGV4dGVuc2lv biBoZWFkZXJzIG9mIHRoZSBwYWNrZXQgYXJlIGdyZWF0ZXIgdGhlDQo+IG5ldyBNVFU/DQoNClRo ZSBvdmVyd3JpdGUgd2lsbCBub3QgY2hhbmdlIHRoZSB0b3RhbCBsZW5ndGggb2YgdGhlIGV4dGVu c2lvbiBoZWFkZXJzLiBUaGlzIGlzIGJlY2F1c2UgdGhlIGxlbmd0aCBvZiB0aGUgbmV3IE9wdGlv biBpcyBpZGVudGljYWwgdG8gdGhlIGxlbmd0aCBvZiB0aGUgb2xkIE9wdGlvbi4gU3BlY2lmaWNh bGx5LCBPcHRpb24gRGF0YSBMZW5ndGggZXF1YWxzIHplcm8uDQoNCiBJZiBhbiBpbnRlcm1lZGlh dGUgdHJ1bmNhdGVzIEVIIHRoYXQgaXMgZXF1aXZhbGVudCB0byBkcm9wcGluZyBFSA0KPiBhbmQg cHJvYmFibHkgY3JlYXRlcyBhIG1pc21hdGNoZWQgbGVuZ3RoIG9uIGZpbmFsIEVILiBFdmVuIHdv cnNlLCB3aGF0IGlmIGl0J3MNCj4gYSBzZWdtZW50IHJvdXRpbmcgaGVhZGVyIHRoYXQgaXMgdHJ1 bmNhdGVkIGluIHRoaXMgcHJvY2VzcyBzbyB0aGF0IGl0IHJlbmRlcnMgdGhlDQo+IHBhY2tldCB1 bmRlbGl2ZXJhYmxlLg0KDQpTZWUgdGhlIHRleHQgZnJvbSBTZWN0aW9uIDcsIHF1b3RlZCBhYm92 ZS4NCg0KPiBBbHNvLCBpZiB0cmFuc3BvcnQgbGF5ZXIgcG9ydHMgYXJlIHRydW5jYXRlZCB0aGVu IHBhY2tldCB3b3VsZCBiZSBibG9ja2VkIGJ5DQo+IEZXLg0KDQpTZWUgdGhlIHRleHQgZnJvbSBT ZWN0aW9uIDcsIHF1b3RlZCBhYm92ZS4NCg0KPiANCj4gQSBjb3VwbGUgb2Ygb3RoZXIgcXVlc3Rp b25zIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0LiBJdCBzdGF0ZXM6DQo+IA0KPiAiV2hlbiB0aGUgZGVz dGluYXRpb24gbm9kZSByZWNlaXZlcyBhIHBhY2tldCB0aGF0IGhhcyBiZWVuIHRydW5jYXRlZCwg aXQNCj4gc2VuZHMgYW4gSUNNUCBQVEIgbWVzc2FnZSB0byB0aGUgc291cmNlIG5vZGUuIg0KPiAN Cj4gQnV0IG9uZSBvZiB0aGUgcmVhc29ucyBpbnRlcm1lZGlhdGUgZGV2aWNlcyBkb24ndCB3YW50 IHNlbmQgSUNNUCBpcw0KPiANCj4gIm8gIEEgZmlyZXdhbGwgb24gdGhlIHBhdGggYmV0d2VlbiB0 aGUgZG93bnN0cmVhbSByb3V0ZXIgYW5kIHRoZSBzb3VyY2UNCj4gbm9kZSBhZG1pbmlzdHJhdGl2 ZWx5IGJsb2NrcyB0aGUgSUNNUCBQVEIgbWVzc2FnZS4iDQo+IA0KPiBXaHkgd291bGQgc2VuZGlu ZyBhbiBJQ01QIGZyb20gdGhlIGRlc3RpbmF0aW9uIGJlIG1vcmUgbGlrZWx5IHRvIHN1Y2NlZWQN Cj4gdGhhbiBzZW5kaW5nIGZyb20gYW4gaW50ZXJtZWRpYXRlIG5vZGU/IEkgd291bGQgdGhpbmsg YW4gSUNNUCBzZW50IGZyb20gdGhlDQo+IGludGVybWVkaWF0ZSBub2RlIGhhcyB0aGUgZ3JlYXRl ciBjaGFuY2Ugb2Ygc3VjY2VzcyBzaW5jZSBpdCBpcyBjbG9zZXIgdG8gdGhlDQo+IHNvdXJjZS4N Cg0KU2VjdGlvbiAzIG9mIHRoZSBkcmFmdCBzaXRlcyB0aGUgZm9sbG93aW5nIHJlYXNvbnM6DQoN CiAgIG8gIFRoZSBkZXN0aW5hdGlvbiBub2RlIGhhcyBhIHZpYWJsZSByb3V0ZSB0byB0aGUgc291 cmNlIG5vZGUsIGJ1dA0KICAgICAgdGhlIGludGVybWVkaWF0ZSBub2RlIGRvZXMgbm90Lg0KDQog ICBvICBUaGUgc291cmNlIG5vZGUgaXMgcHJvdGVjdGVkIGJ5IGEgZmlyZXdhbGwgdGhhdCBhZG1p bmlzdHJhdGl2ZWx5DQogICAgICBibG9ja3MgYWxsIHBhY2tldHMgZXhjZXB0IGZvciB0aG9zZSBm cm9tIHNwZWNpZmllZCBzdWJuZXR3b3Jrcy4NCiAgICAgIFRoZSBkZXN0aW5hdGlvbiBub2RlIHJl c2lkZXMgaW4gb25lIG9mIHRoZSBzcGVjaWZpZWQgc3VibmV0d29ya3MsDQogICAgICBidXQgdGhl IGludGVybWVkaWF0ZSBub2RlIGRvZXMgbm90Lg0KDQogICBvICBUaGUgc291cmNlIGFkZHJlc3Mg b2YgdGhlIG9yaWdpbmFsIHBhY2tldCAoaS5lLiwgdGhlIHBhY2tldCB0aGF0DQogICAgICBlbGlj aXRlZCB0aGUgSUNNUCBtZXNzYWdlKSB3YXMgYW4gYW55Y2FzdCBhZGRyZXNzLiAgVGhlcmVmb3Jl LCB0aGUNCiAgICAgIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIElDTVAgbWVzc2FnZSBpcyB0 aGUgc2FtZSBhbnljYXN0DQogICAgICBhZGRyZXNzLiAgSW4gdGhpcyBjYXNlLCBhbiBJQ01QIG1l c3NhZ2UgZnJvbSB0aGUgZGVzdGluYXRpb24gbm9kZQ0KICAgICAgaXMgbGlrZWx5IHRvIGJlIGRl bGl2ZXJlZCB0byB0aGUgY29ycmVjdCBhbnljYXN0IGluc3RhbmNlLiAgQnkNCiAgICAgIGNvbnRy YXN0LCBhbiBJQ01QIG1lc3NhZ2UgZnJvbSBhbiBpbnRlcm1lZGlhdGUgbm9kZSBpcyBsZXNzIGxp a2VseQ0KICAgICAgdG8gYmUgZGVsaXZlcmVkIHRvIHRoZSBjb3JyZWN0IGFueWNhc3QgaW5zdGFu Y2UuDQoNCg0KPiANCj4gQWxzbywNCj4gDQo+IG8gIFRoZSBzb3VyY2UgYWRkcmVzcyBvZiB0aGUg b3JpZ2luYWwgcGFja2V0IChpLmUuLCB0aGUgcGFja2V0IHRoYXQgZWxpY2l0ZWQgdGhlDQo+IElD TVAgUFRCIG1lc3NhZ2UpIHdhcyBhbiBhbnljYXN0IGFkZHJlc3MuICBUaGVyZWZvcmUsIHRoZSBk ZXN0aW5hdGlvbg0KPiBhZGRyZXNzIG9mIHRoZSBsc28sIGlmIElDTVAgUFRCIG1lc3NhZ2UgaXMg dGhlIHNhbWUgYW55Y2FzdCBhZGRyZXNzLg0KPiANCj4gSG93IGRvZXMgdGhlIElDTVAgbWVzc2Fn ZSBzZW50IGZyb20gdGhlIGRlc3RpbmF0aW9uIGhvc3QgYXZvaWQgYSBwcm9ibGVtDQo+IGhlcmU/ DQoNCkEgbW9yZSBjb21wbGV0ZSBkZXNjcmlwdGlvbiBvZiB0aGlzIHByb2JsZW0gY2FuIGJlIGZv dW5kIGluIFNlY3Rpb24gNC42LjIgb2YgZHJhZnQtaWV0Zi1pbnRhcmVhLWZyYWctZnJhZ2lsZS0w Mi4NCg0KPiANCj4gVG9tDQo+IA0KPiANCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+ IGlwdjZAaWV0Zi5vcmcNCj4gPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czoNCj4gPiBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsDQo+ID4gbWFuX2xpc3RpbmZvX2lwdjYmZD1Ed0lGYVEmYz1IQWtZdWg2M3JzdWhyNlNj YmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXem8NCj4gPiBDSSZyPUZjaDlGUTgyc2lyLUJvTHg4 NGhLdUt3bC0NCj4gQVdGMkVmcEhjQXdyRFRoS1A4Jm09T091cnRxbXhfS0h1UEFQbklFVg0KPiA+ DQo+IEFsWG9ucWNBeFpwelRkNDZkZXJpekpyUSZzPW14Wm9VWXhJbWg1R1hOQmRqMVN2WTM3TVZl Vl95aDJ5aE9oDQo+IGJpMnR3ZWRVDQo+ID4gJmU9DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Fri Nov 2 08:37:53 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DE3126BED for ; Fri, 2 Nov 2018 08:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 VnmQSeU0Say3 for ; Fri, 2 Nov 2018 08:37:49 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 55C6A1292AD for ; Fri, 2 Nov 2018 08:37:49 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id 131so3701437qkd.4 for ; Fri, 02 Nov 2018 08:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Eb5043GcgROOFzUx4ZhiuuaBtWyTygVoQLqLmApOFjo=; b=EkPUq9Rmvldd0lm5xby66/fZdjaBfT/xbixUQ7mBDsavOJGao3iN5wvIoVDUb44BYp 5b415bnNnVaDrjIcJTMfub0iBqlB93pZzde/0S5QTNz7sFjGs/mu5Wsoaz/kc4CzZZSl INp/8tKE0HTzeV7JQDfYFYB2qhDxnTKzsY7ryKuJhlrTjN6hh93zjZTD0swkyPZyj6l8 BW7GfL2k01cmlqxLwtvI3EhfTurM0Hn+FZBIuI0FAArNr7uEAKb0UWAAz+WO6HwlOf2O cWmKJY0nuZQf2Pm6NlmF+PgfUj8CxmCYJ2Acb7WgYvs3GTibSmMV5HhofemfdnJ7o/5c tqkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Eb5043GcgROOFzUx4ZhiuuaBtWyTygVoQLqLmApOFjo=; b=NHIRAulmnaliJ1oiEIUVjX+nbMqIsAK8FcAQordcB523np9bcH57PMp1Y92+rlFRg/ MagiAfhDjw+Lt7lSbxaCrpqqJjUrdot64oGjjJBuEAvmEvSWk9Arun8jzw4n1btkUJr4 U/4tMda/ADZXRolJSQPnBjGFqAzvhnbPhvLQkGMarP/a+s2eIuTq2xokeUYXDl89D9Ny QASuPxcPKSvIzwp4Q7cKrK6gwf7qffUISHib7Et5VpMoCFycwF6S5C4eFXkwLQxC0qRo GJWl2GaOMqvrvcv5DQ1GSi5YGKKZ617ooeY4+uXkEw110GR34r1QxFRYU2XqY3/wel3w pJ9w== X-Gm-Message-State: AGRZ1gIEZ/mwE9yeA0lmKCB/9f+rD1JsdIWSoMDY2zk897g0B1VDf3j4 lkSf3iUtTKuxFabrpiPlmWjRiHMDLM4ttyIh5p45JS5wWTc= X-Google-Smtp-Source: AJdET5cOZLfGnnKNs7CM/lzGJyjwL52hvyIhmhYLRLde7NTFqRTq4mHmnp0Ym0/lfWNQNR27iN8MpqiAzKiRGS/N9FU= X-Received: by 2002:a0c:f584:: with SMTP id k4mr11484428qvm.22.1541173068285; Fri, 02 Nov 2018 08:37:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:2022:0:0:0:0:0 with HTTP; Fri, 2 Nov 2018 08:37:47 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Fri, 2 Nov 2018 08:37:47 -0700 Message-ID: Subject: Re: draft-herbert-ipv6-update-opts-00 To: Ron Bonica Cc: IPv6 List , "Joel M. Halpern" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 15:37:53 -0000 On Fri, Nov 2, 2018 at 7:35 AM, Ron Bonica wrote: > Hi Tom, > > I cannot argue that your draft should include an exception because a) the= truncation draft relies on it and b) the truncation draft is wonderful. Th= e first statement is not true. I could remove an optimization from the trun= cation draft so that it no longer relies on the exception. The second state= ment is still a topic of debate. > > However, I can argue that your draft should include this exception becaus= e overwriting the Option type in this one particular corner case causes no = harm. Unless you can show how it causes harm, the blanket rule is difficult= to defend. > Ron, draft-herbert-ipv6-update-opts-00 is only clarifying RFC8200 in this instance. In RFC8200 there is no provision that allows changing Option Length or Option Type in flight. Option Data may change per: "The third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en route to the packet's final destination." Also, the truncation option is defined as a Destination option, but the draft states: "Router 2 examines the Destination Options header" RFC8200 does not allow intermediates nodes to examine Destination Options and definitely does not allow intermediate nodes to change destination options. The truncation options really should be Hop-by-Hop options. One other point, when an option is marked changeable the Option Data is treated as zero-value octets for authentication. If an Option Type is "changeable" wouldn't a similar consideration be needed for Option Type value to be zeroed for authenticating? Tom > In a private email, Joel Halpern correctly points out that the exception= should be slightly more narrow. Overwriting should be permitted only when= all of the following conditions are true: > > - the new Option type, if recognized by the destination node, will cause = the packet to be discarded > - the new Option type, if not recognized by the destination node, will ca= use the packet to be discarded (i.e., The new Option type begins with 01, = 10, or 11) > - the option data length is zero before the update > - the option data length is zero after the update > - the packet does not contain an Authentication Header (this is the new r= estriction) > > Most of your comments are specific to the truncation draft. While our dis= cussion may not be about the truncation draft, I have addressed your commen= ts inline, below.... > > Ron > >> -----Original Message----- >> From: Tom Herbert >> Sent: Thursday, November 1, 2018 7:24 PM >> To: Ron Bonica >> Cc: IPv6 List >> Subject: Re: draft-herbert-ipv6-update-opts-00 >> >> On Thu, Nov 1, 2018 at 12:57 PM, Ron Bonica wrote: >> > Hi Tom, >> > >> > In your draft, you propose a rule forbidding updates to the Option typ= e. >> While I agree with this rule in the vast majority of cases, I would like= to >> propose an exception. An intermediate node MAY update an Option type if = all >> of the following conditions are true: >> > >> > - the new Option type, if recognized by the destination node, will >> > cause the packet to be discarded >> > - the new Option type, if not recognized by the destination node, will >> > cause the packet to be discarded (i.e., The new Option type begins >> > with 01, 10, or 11) >> > - the option data length is zero before the update >> > - the option data length is zero after the update >> > >> > An optimization in draft-leddy-6man truncate can be preserved only if = that >> exception exists. If you like, we can do a deep dive into the details of= that >> optimization. But I think that the exception requested above is narrow e= nough >> that we may not need to go there. >> >> Hi Ron, >> >> Personally, I am skeptical about truncating packets being robust and I d= on't >> think your exception would be the only one. It's possible that truncatin= g >> packets has side effects. For instance, the draft states >> to: >> >> "Truncates the packet, so that its new length equals the MTU of the next= -hop >> link." > > This is addressed in Section 7 of the draft. Specifically.... > > A truncated packet MUST contain the basic IPv6 header, all extension > headers and the first upper-layer header. When an intermediate node > cannot forward a packet due to MTU issues, and the total length of > the basic IPv6 header, all extension headers, and first upper-layer > header exceeds the MTU of the next link in the path, the intermediate > node MUST discard the packet and send and ICMP PTB message to the > source node. It MUST NOT truncate the packet." > >> >> But what if the total length of extension headers of the packet are grea= ter the >> new MTU? > > The overwrite will not change the total length of the extension headers. = This is because the length of the new Option is identical to the length of = the old Option. Specifically, Option Data Length equals zero. > > If an intermediate truncates EH that is equivalent to dropping EH >> and probably creates a mismatched length on final EH. Even worse, what i= f it's >> a segment routing header that is truncated in this process so that it re= nders the >> packet undeliverable. > > See the text from Section 7, quoted above. > >> Also, if transport layer ports are truncated then packet would be blocke= d by >> FW. > > See the text from Section 7, quoted above. > >> >> A couple of other questions related to the draft. It states: >> >> "When the destination node receives a packet that has been truncated, it >> sends an ICMP PTB message to the source node." >> >> But one of the reasons intermediate devices don't want send ICMP is >> >> "o A firewall on the path between the downstream router and the source >> node administratively blocks the ICMP PTB message." >> >> Why would sending an ICMP from the destination be more likely to succeed >> than sending from an intermediate node? I would think an ICMP sent from = the >> intermediate node has the greater chance of success since it is closer t= o the >> source. > > Section 3 of the draft sites the following reasons: > > o The destination node has a viable route to the source node, but > the intermediate node does not. > > o The source node is protected by a firewall that administratively > blocks all packets except for those from specified subnetworks. > The destination node resides in one of the specified subnetworks, > but the intermediate node does not. > > o The source address of the original packet (i.e., the packet that > elicited the ICMP message) was an anycast address. Therefore, the > destination address of the ICMP message is the same anycast > address. In this case, an ICMP message from the destination node > is likely to be delivered to the correct anycast instance. By > contrast, an ICMP message from an intermediate node is less likely > to be delivered to the correct anycast instance. > > >> >> Also, >> >> o The source address of the original packet (i.e., the packet that elic= ited the >> ICMP PTB message) was an anycast address. Therefore, the destination >> address of the lso, if ICMP PTB message is the same anycast address. >> >> How does the ICMP message sent from the destination host avoid a problem >> here? > > A more complete description of this problem can be found in Section 4.6.2= of draft-ietf-intarea-frag-fragile-02. > >> >> Tom >> >> >> > Ron >> > >> > >> > >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il >> > man_listinfo_ipv6&d=3DDwIFaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- >> ndb3voDTXcWzo >> > CI&r=3DFch9FQ82sir-BoLx84hKuKwl- >> AWF2EfpHcAwrDThKP8&m=3DOOurtqmx_KHuPAPnIEV >> > >> AlXonqcAxZpzTd46derizJrQ&s=3DmxZoUYxImh5GXNBdj1SvY37MVeV_yh2yhOh >> bi2twedU >> > &e=3D >> > -------------------------------------------------------------------- From nobody Fri Nov 2 09:26:22 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8475A130DE4 for ; Fri, 2 Nov 2018 09:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.197 X-Spam-Level: *** X-Spam-Status: No, score=3.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 O8EzmLfsQOX2 for ; Fri, 2 Nov 2018 09:26:18 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0098.outbound.protection.outlook.com [104.47.1.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CBE130DDF for ; Fri, 2 Nov 2018 09:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dFXL+afkfCRPJ1TA5uVnUdV9xXGMyYS4NJor7FtA9GA=; b=V957eYLcM/qI0KdSciMYim4VzqNTLfwbAbfrT8UaMxHwoiaJGA4HvMdyClvYdicBPQE+le1FPFsmrv3n7/o8/L0ebHdES3WVisZ04bdbR9sYRcSMpE+qyldKiGifTBKOcGVNzHHf3wq4nFImUi0M+BOjo3kqIzohAHmLB0Wn78Y= Received: from VI1PR07MB5022.eurprd07.prod.outlook.com (20.177.202.206) by VI1PR07MB5743.eurprd07.prod.outlook.com (20.177.202.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.16; Fri, 2 Nov 2018 16:26:15 +0000 Received: from VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::d929:3695:4655:d265]) by VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::d929:3695:4655:d265%4]) with mapi id 15.20.1294.024; Fri, 2 Nov 2018 16:26:15 +0000 From: tom petch To: Joel Jaeggli CC: "ipv6@ietf.org" Subject: Re: registering tunnel types Thread-Topic: registering tunnel types Thread-Index: AQHUa7JQGt84fGh/gUCjkcGLMGYnDQ== Date: Fri, 2 Nov 2018 16:26:15 +0000 Message-ID: <013a01d472c8$9326b480$4001a8c0@gateway.2wire.net> References: <01a901d46bb2$26c23700$4001a8c0@gateway.2wire.net> <787AE7BB302AE849A7480A190F8B93302E039F88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <026701d47048$dfd7b900$4001a8c0@gateway.2wire.net> <2A649FB9-0696-40BC-BE4E-2CB5E4AA4F05@bogus.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0115.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::31) To VI1PR07MB5022.eurprd07.prod.outlook.com (2603:10a6:803:9b::14) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [86.128.101.213] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB5743; 6:YoQ0f4ZAlfc7McONGr0SHaIFJ001Mtbjcvfjo3ZSzVOF+8sTO1y/CApRtFP/+QWpwGwyZNkMgFCIxcwqbPr6xSG6GmG7SlSMApVfran9wfA5FKNq/Ol+sDiNxUHsoSqftx7TOXaSPc2BSbIz+jwTHI6EFctX0ZmBobKHQhJgoLO2W/dqDP7S+GASurUQXm5iqmPngVeRbe6t3EXEf7MGzUnMv0RR1O+9KdEV2DrdcKjupPu3ttgYy4c72MHB5rVEERORe2fKx5Iez/k0mLuKzkAf2qG3nSCl92j6F/MesaO5B42WbHSkeJbwvbaZDW2b2j3dlMFl807093/h94KmpNxpHX/oWolChmtxS+t9wGfS2SmIEVDALvR5qKpDLgCn+s5NzWn4Z7aY1tOMpVg6P9XGXybJoIAhmXXpFnR/Gco7dHHQhjgjXgPHuBnjQv/wMyJbU8p5Jf5ni7D75YiXyA==; 5:kBbbC6dp8yRq6e+nlM3i4FWQ6XVSKC9hM/93lbvScZnoh0dF0TnYOAGsONLblzOZDc29SBjoiwUgNn9b3xmkMWWQV8BvbAv4eGSqTljexRIzhdpFWRHQiUeCHPlojvg4cckwP0zVpjwNAKUibtheKKYU8sV19e3p5/wOMgjlhjY=; 7:SOpQbt7+zAWx7J1/lwWwD6uFNitZBgXVyJ2S7jRRFRcz8gnzEnN3zLJKGUGxaY2VofsyX1bsUncXIO8c21T68PpcJwc8B6qZMH5ufVgA8aerh8fiiCBiKQbT96rPoqkgMZLDWGXW4a18aLE2xHQoag== x-ms-office365-filtering-correlation-id: c7b0e542-8119-4ea3-bd14-08d640dfe965 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB5743; x-ms-traffictypediagnostic: VI1PR07MB5743: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(219612443155931)(178726229863574)(161740460382875)(18271650672692)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB5743; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB5743; x-forefront-prvs: 08444C7C87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(136003)(396003)(39860400002)(55784004)(189003)(51444003)(13464003)(199004)(106356001)(44736005)(71200400001)(68736007)(81156014)(99286004)(2906002)(6116002)(84392002)(1556002)(66574009)(966005)(3846002)(8676002)(3480700004)(71190400001)(14454004)(446003)(6436002)(81166006)(105586002)(8936002)(97736004)(14496001)(6486002)(256004)(7116003)(7736002)(86362001)(2900100001)(305945005)(52116002)(33896004)(9686003)(66066001)(6512007)(6306002)(6246003)(25786009)(478600001)(186003)(561944003)(93886005)(476003)(102836004)(26005)(229853002)(53546011)(76176011)(6506007)(316002)(4326008)(486006)(86152003)(6916009)(386003)(5660300001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5743; H:VI1PR07MB5022.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4VO7VpKntvcdu76etrEE56ji7KyZ1WqUeUoLje7rKn2NZAAfuOKQNwV0JhkccSxqpqhxftSn8/cegCoel97bMDjAFfhfO81jHfF4iAz6BRrTOKEB63JQM6Hev5QKLimrookzSiD6RK+AwV5yZEsj1ZTdSnaj3rWh1ckLVHPWgW/FGu/gCi2cmcFEelJbx1xPA5DxceVcYsRyCHRlmt3yQcrq0KrLXfTVwkpROH8y3/VPDqK8L5kF5CABy3TgJy6bnCyMoqkOvstf+6pEnFxKSsxkTn/b1p1cVIZv9N+UrbBuo1x0Io1xIuE0hp91XOd8n8dBvRI4uBCZtlCWS4BZNzIf1ZAohalzmDcCVThXqUE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9AD3C61E9DB95A40AEB5F36A2284E5F4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7b0e542-8119-4ea3-bd14-08d640dfe965 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 16:26:15.8808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5743 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 16:26:20 -0000 LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiSm9lbCBKYWVnZ2xpIiA8am9lbGph QGJvZ3VzLmNvbT4NClRvOiAidG9tIHBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbT4NCkNjOiA8 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IDxpcHY2QGlldGYub3JnPjsgIkFsZXhhbmRy ZQ0KUGV0cmVzY3UiIDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPg0KU2VudDogVHVlc2Rh eSwgT2N0b2JlciAzMCwgMjAxOCA4OjIzIFBNDQoNCj4gT24gT2N0IDMwLCAyMDE4LCBhdCAwNTow NywgdG9tIHBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPiB3cm90ZToNCj4+DQo+DQo+IEFsZXgN Cj4NCj4gSSBhZ3JlZSwgYXQgbGVhc3QgaW4gcGFydDsgdHVubmVscyBhbmQgaW50ZXJmYWNlcyBh cmUgZGlmZmVyZW50DQphbmltYWxzDQo+IGFuZCBpdCBpcyB1bmZvcnR1bmF0ZSB0aGF0IHRoZXkg d2VyZSBjb25mbGF0ZWQgaW4gU01JLg0KPg0KPiBJIHdhcyBzdXJwcmlzZWQgdGhhdCBORVRNT0Qg aGFkIG5vdCBwcm9kdWNlZCBhIFlBTkcgbW9kdWxlIGZvciB0dW5uZWxzDQo+IGJ1dCBpdCBzZWVt cyB0aGF0IHRoZXJlIGhhcyBiZWVuIG5vIG5lZWQgZm9yIHRoZSBwYXN0IGRlY2FkZS4gIFRoYXQN Cj4gc2FpZCwgSSB0aGluayB0aGF0IGl0IGlzIGEgZ29vZCBpZGVhIHRvIGhhdmUgb25lLiAgV2hl dGhlciBvciBub3QgaXQNCj4gc2hvdWxkIG1pcnJvciB0aGUgVHVubmVsIE1JQiBJIGZpbmQgbW9y ZSBkZWJhdGFibGUuDQoNCkl04oCZcyBub3QgZW50aXJlbHkgb2J2aW91cyB0byBtZSB0aGF0IG5l dHRlZCAvIG5ldGNvbmZpZyB3b3VsZCBiZSB3aGVyZQ0KdGhlIHR1bm5lbCBtb2RlbHMgd2VyZSBw cm9kdWNlZC4NCg0KVGhleSB0ZW5kIGlmIGZhY3QgdG8gYmUgcHJvZHVjZWQgYnkgdGhlIHR1bm5l bCBwcm90b2NvbCBtYWludGFpbmVycyBlLmcuDQpsM3NtL2wyc20vY2NhbXAgYW5kIHNvIG9uLiBU aGUgbWFuYWdlbWVudCB0b29scyBmb3IgYSBwcm9kdWN0IHRlbmQgdG8gYmUNCmRldmVsb3BlZCBp dHNlbGYgaW4gbXkgZXhwZXJpZW5jZS4NCg0KPHRwPg0KDQpKb2VsDQoNCk15IGNvbmNlcm4gaXMg dGhhdCBzb21ldGhpbmcgdGhhdCBjdXRzIGFjcm9zcyBhIG51bWJlciBvZiBJRVRGIFdHIHNob3Vs ZA0KZ2V0IGFkZXF1YXRlIHJldmlldy4gIFRoZSBZQU5HIGludGVyZmFjZSBtb2R1bGUgd2FzIG11 Y2ggZGlzY3Vzc2VkIGluDQp0aGUgbmV0bW9kIFdHLCB3aXRoIGFuIGV4aXN0aW5nIE1JQiBhcyBn dWlkYW5jZSwgYmVmb3JlIGJlY29taW5nIGFuIFJGQy4NCg0KVGhlIHByb3Bvc2VkIFlBTkcgdHVu bmVsIG1vZHVsZSwgd2hpY2ggYm9ycm93cyB0aGUgY29uY2VwdHMgb2YgdGhlDQppbnRlcmZhY2Ug bW9kdWxlLCB0aGF0IGFkZGl0aW9ucyBzaG91bGQgYmUgbWFkZSBieSB0aGUgVHVubmVsIE1JQg0K RGVzaWduYXRlZCBFeHBlcnQgdG8gYSByZWdpc3RyeSBhbmQgdGhlbiBwcm9wYWdhdGVkIHRvIHRo ZSBUdW5uZWwgTUlCDQphbmQgdGhlIFR1bm5lbCBZQU5HIG1vZHVsZSwgaGFzIG5vdCBiZWVuIGRp c2N1c3NlZCBpbiBhbnkgV0cuICBUaGUNCnByb3Bvc2FsLCBhcyBJIG1lbnRpb25lZCBiZWZvcmUs IGhhcyBiZWVuIGFkZGVkIHRvIHRoZSBJLUQgYWZ0ZXIgSUVURg0KTGFzdCBDYWxsIGhhcyBiZWVu IGNvbXBsZXRlZCBzbyBhcHBlYXJzIHRvIG1lIHRvIGJlIHRoZSB3b3JrIG9mIG9uZQ0KaW5kaXZp ZHVhbCwgd2l0aG91dCBhbnkgcmV2aWV3OyB0aGUgSS1EIGxpc3RzIHNldmVuIGVkaXRvcnMsIHNp eCBvZiB3aG9tDQphcHBlYXIgdG8gYmUgYWJzZW50LiAgVGhlV0cgbWFpbGluZyBsaXN0IHNlZW1z IGRldm9pZCBvZiBhbnkgZGlzY3Vzc2lvbi4NCg0KSSBiZWxpZXZlIHRoYXQgdGhlIElFVEYgc3Vj Y2VlZHMgYmVjYXVzZSBvZiBwZWVyIHJldmlldywgYW5kIEkgc3RydWdnbGUNCnRvIHNlZSB0aGF0 IGhlcmUuDQoNClRvbSBQZXRjaA0KDQo+IE15IG93biBob21ld29yayBjYW1lIGFjcm9zcyBvdGhl ciBJUCBpbiBJUCB2YXJpZXRpZXMgd2hpY2ggZG8gbm90DQo+IGFwcGVhci4NCj4NCj4gVG9tIFBl dGNoDQo+DQo+DQo+Pg0KPj4gQWxleA0KPj4NCj4+Pg0KPj4+IElmIHlvdSBuZWVkIGEgbmV3IHZh bHVlIG9yIGlmIHlvdSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgYSBnaXZlbg0KPiBpbnRlcmZhY2Ug dHVubmVsIHR5cGUsIHBsZWFzZSBmb2xsb3cgdGhlIGd1aWRlbGluZXMgaW4gdGhlIHVybCBjaXRl ZA0KPiBhYm92ZS4gQWxsIHRoaXMgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiBkcmFmdC1pZXRmLXNv ZnR3aXJlLXlhbmcuDQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4gTWVkDQo+Pj4NCj4+Pj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+IERlIDogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBBbGV4YW5kcmUNCj4gUGV0cmVzY3UNCj4+Pj4gRW52 b3nDqSA6IGpldWRpIDI1IG9jdG9icmUgMjAxOCAwOTo1NA0KPj4+PiDDgCA6IGlwdjZAaWV0Zi5v cmcNCj4+Pj4gT2JqZXQgOiBSZTogcmVnaXN0ZXJpbmcgdHVubmVsIHR5cGVzDQo+Pj4+DQo+Pj4+ IEFyZToNCj4+Pj4gLUlQdjYgaW4gVURQdjQgYW5kDQo+Pj4+IC1JUHY2IGluIElQdjYgYXMgdXNl ZCBieSBvcGVudnBuOw0KPj4+Pg0KPj4+PiBjb3ZlcmVkIGJ5IHRoZSBsaXN0IGJlbG93Pw0KPj4+ Pg0KPj4+PiBUaGVzZSBhcmUgYSBmZXcgdHVubmVsbGluZyBtZWNoYW5pc21zIEkgdXNlIHJvdXRp bmVseS4NCj4+Pj4NCj4+Pj4gRXhpc3RpbmcgaWRlbnRpdHkgNnRvZm91ciBzaG91bGQgYmUgZGVw cmVjYXRlZCwgaWYgdGhhdCBtZWFucyA2dG80LA0KPj4+PiB3aGljaCBpcyBkZXByZWNhdGVkLg0K Pj4+Pg0KPj4+PiBFeGlzdGluZyBpZGVudGl0eSBpcGh0dHBzIGhhcyBhIHZlcnNpb24gbnVtYmVy IGZvciBJUD8NCj4+Pj4NCj4+Pj4gQWxleA0KPj4+Pg0KPj4+PiBMZSAyNC8xMC8yMDE4IMOgIDE3 OjU3LCB0b20gcGV0Y2ggYSDDqWNyaXQgOg0KPj4+Pj4gZHJhZnQtaWV0Zi1zb2Z0d2lyZS15YW5n DQo+Pj4+PiBjb21wbGV0ZWQgSUVURiBMYXN0IENhbGwgdHdvIHdlZWtzIGFnbyBhbmQsIHNpbmNl IHRoZW4sIGhhcw0KPiBhY3F1aXJlZCBhDQo+Pj4+PiBZQU5HIG1vZHVsZSB0aGF0IGRlZmluZXMg dHVubmVsIHR5cGVzLCBhcyBsaXN0ZWQgYmVsb3cuICBJdCBpcw0KPiBpbnRlbmRlZA0KPj4+Pj4g dG8gYmUgYSBJQU5BLW1haW50YWluZWQgbW9kdWxlIGFuZCBzbyBjaGFuZ2VzIHRvIHRoZSBsaXN0 IG9mDQo+IHR1bm5lbHMNCj4+Pj4+IHdpbGwgbm90IHJlcXVpcmUgYSByZWlzc3VlIG9mIHRoZSBz b2Z0d2lyZXMgUkZDLXRvLWJlLiAgQXQgdGhlDQo+IHNhbWUNCj4+Pj4+IHRpbWUsIGdldHRpbmcg aXQgcmlnaHQgZmlyc3QgdGltZSBuZXZlciBkaWQgYW55IGhhcm0gc28gaWYgYW55b25lDQo+IGNh bg0KPj4+Pj4gdGhpbmsgb2YgYW55IG1pc3NpbmcsIG9yIGNhbiB0aGluayBvZiBvdGhlciBwbGFj ZXMgd2hlcmUgdGhlcmUNCj4gbWlnaHQgYmUNCj4+Pj4+IG90aGVyIHR1bm5lbHMgbHVya2luZywg bm93IHdvdWxkIGJlIGEgZ29vZCB0aW1lIHRvIG1lbnRpb24gaXQuDQo+Pj4+Pg0KPj4+Pj4gSXQg aXMgYmFzZWQgb24gUkZDNDA4NyBUdW5uZWwgTUlCICh3aGljaCBjcmVhdGVkIGFuIFNNSSBUZXh0 dWFsDQo+Pj4+PiBDb252ZW50aW9uIHRoYXQgd2VudCB1cCB0byBUZXJlZG8pIHNvIHR1bm5lbHMg ZnJvbSB0aGF0IHZpbnRhZ2UNCj4gYXJlDQo+Pj4+PiBsaWtlbHkgd2VsbCBjYXRlcmVkIGZvci4g IHNvZnR3aXJlcyBpcyBub3Qgd2hlcmUgSSB3b3VsZCBoYXZlDQo+IGZpcnN0DQo+Pj4+PiBsb29r ZWQgZm9yIHR1bm5lbCB0eXBlcywgYnV0IGl0IGhhcyBhIGNlcnRhaW4gbG9naWMgdG8gaXQuDQo+ Pj4+Pg0KPj4+Pj4gICAgICAgaWRlbnRpdHkgIG90aGVyDQo+Pj4+Pg0KPj4+Pj4gICAgICAgaWRl bnRpdHkgZGlyZWN0DQo+Pj4+Pg0KPj4+Pj4gICAgICAgaWRlbnRpdHkgZ3JlDQo+Pj4+Pg0KPj4+ Pj4gICAgICAgaWRlbnRpdHkgbWluaW1hbA0KPj4+Pj4NCj4+Pj4+ICAgICAgIGlkZW50aXR5IGwy dHANCj4+Pj4+DQo+Pj4+PiAgICAgICBpZGVudGl0eSBwcHRwDQo+Pj4+Pg0KPj4+Pj4gICAgICAg aWRlbnRpdHkgbDJmDQo+Pj4+Pg0KPj4+Pj4gICAgICAgaWRlbnRpdHkgdWRwDQo+Pj4+Pg0KPj4+ Pj4gICAgICAgaWRlbnRpdHkgYXRtcA0KPj4+Pj4NCj4+Pj4+ICAgICAgIGlkZW50aXR5IG1zZHAN Cj4+Pj4+DQo+Pj4+PiAgICAgICBpZGVudGl0eSBzaXh0b2ZvdXINCj4+Pj4+DQo+Pj4+PiAgICAg ICBpZGVudGl0eSBzaXhvdmVyZm91cg0KPj4+Pj4NCj4+Pj4+ICAgICAgIGlkZW50aXR5IGlzYXRh cA0KPj4+Pj4NCj4+Pj4+ICAgICAgIGlkZW50aXR5IHRlcmVkbw0KPj4+Pj4NCj4+Pj4+ICAgICAg IGlkZW50aXR5IGlwaHR0cHMNCj4+Pj4+DQo+Pj4+PiAgICAgICBpZGVudGl0eSBzb2Z0d2lyZW1l c2gNCj4+Pj4+DQo+Pj4+PiAgICAgICBpZGVudGl0eSBkc2xpdGUNCj4+Pj4+DQo+Pj4+PiAgICAg ICBpZGVudGl0eSAgYXBsdXNwDQo+Pj4+Pg0KPj4+Pj4gVG9tIFBldGNoDQo+Pj4+Pg0KPj4NCj4+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KLQ0KPj4+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+Pj4+PiBpcHY2QGlldGYub3JnDQo+Pj4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czoN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+Pg0KPj4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQotDQo+Pj4+Pg0KPj4+Pg0KPj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiBJRVRG IElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+Pj4gaXB2NkBpZXRmLm9yZw0KPj4+ PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHY2DQo+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4gaXB2NkBpZXRmLm9yZw0K Pj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElF VEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnIDxtYWls dG86aXB2NkBpZXRmLm9yZz4NCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXB2Nj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo= From nobody Fri Nov 2 10:50:33 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77305126DBF; Fri, 2 Nov 2018 10:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.969 X-Spam-Level: X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Z1dnJOIJoW0P; Fri, 2 Nov 2018 10:50:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B830C1276D0; Fri, 2 Nov 2018 10:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35184; q=dns/txt; s=iport; t=1541181028; x=1542390628; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dnDYcMB6UZeSqBsHBW/dew3KvjRP5TLCMndN71Pjpx8=; b=XXbde5+g8resTUxhCk2ad/hJPtzTwwo9fZ9lV1+Ou4JoTiYc9aPG5Em1 2t22SEm1FKLQtJe1oCGSXjf8M/2U8f0GrRVhNPGECS8dEj2qdNnq/TUPm yl1w37lC/rqO7zFZ9jtAS0f4d3kCCxzyfiHhe8cCniRlQhS2jxuc+GFvI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAACNjdxb/4UNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBVS+BZSgKg2yIGIwXmTkUgWYLAQGBd4J1Ahe?= =?us-ascii?q?DJyI0DQ0BAwEBAgEBAm0ohTsGGglEEhACAQg/AwICAjAUEQIEDgUbgwaBHmS?= =?us-ascii?q?nUIEuhTyEZItxF4FBP4ERJx+CTIRCcgKCTDGCJgKIZCABMoUmhieJUlQJAod?= =?us-ascii?q?uiRwYgVWPBoJulCkCERSBJh04gVVwFTsqAYJBgiMDF44ab4p4B4EngR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,456,1534809600"; d="scan'208,217";a="464554494" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2018 17:50:27 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id wA2HoRlT007630 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Nov 2018 17:50:27 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 2 Nov 2018 12:50:26 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Fri, 2 Nov 2018 12:50:26 -0500 From: "Darren Dukes (ddukes)" To: "Joel M. Halpern" CC: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" Subject: Re: SRv6 - SRH in encaps or base header - point 2 Thread-Topic: SRv6 - SRH in encaps or base header - point 2 Thread-Index: AQHUampMSmaiE2sUnkOZwbcZBqOzaaUyIfaAgAAQcoCABlqwgIAAA0oAgASXqgA= Date: Fri, 2 Nov 2018 17:50:26 +0000 Message-ID: <679B2EEF-4EE6-44BC-A9D7-17E70FF1133A@cisco.com> References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> <11918c9b-f0bb-4182-cdbe-9ed720b0a800@joelhalpern.com> In-Reply-To: <11918c9b-f0bb-4182-cdbe-9ed720b0a800@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.76.77] Content-Type: multipart/alternative; boundary="_000_679B2EEF4EE644BCA9D717E70FF1133Aciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 17:50:33 -0000 --_000_679B2EEF4EE644BCA9D717E70FF1133Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lbCwgRm9yIG91ciBsYXN0IHJlbWFpbmluZyBpdGVtIGluIHRoaXMgdGhyZWFkLCByZTogY29t bXVuaWNhdGlvbiBmcm9tIDEgdG8gOSBhbmQgOSB0byAxLg0KDQpMZXRzIGFkZCB0aGUgZm9sbG93 aW5nIHNpbmNlIHdlIGRvbuKAmXQgZGlzY3VzcyB0cmFmZmljIGZyb20gYSBob3N0IHdpdGhpbiB0 aGUgU1IgRG9tYWluIHRvIGEgaG9zdCBvdXRzaWRlIHRoZSBTUiBEb21haW4uDQoNCjxORVcgVEVY VD4NCjUuMy4zIEludGVyIFNSIERvbWFpbiBQYWNrZXQNCkhvc3QgOSBzZW5kcyBhIHBhY2tldCB0 byBob3N0IDEgKG91dHNpZGUgdGhlIFNSIERvbWFpbikgdmlhIGFuIFNSIFBvbGljeSA8UzYsUzM+ Lg0KSG9zdCA5IGVuY2Fwc3VsYXRlcyBhbiBpbm5lciBwYWNrZXQgZnJvbSA5IHRvIDEgaW4gYW4g b3V0ZXIgSVB2NiBoZWFkZXIgYW5kIGFkZHMgYW4gU1JIIGZvciB0aGUgU1IgUG9saWN5Lg0KDQog ICBQNzogKEE5LFM2KShTMyxTNjsgU0w9MSkoQTksQTEpDQoNCkEgaG9zdCBpbXBsZW1lbnRhdGlv biBNVVNUIHN1cHBvcnQgYWRkaXRpb24gb2YgdGhlIG91dGVyIElQdjYgZW5jYXBzdWxhdGlvbiB0 byBhdm9pZCBsZWFraW5nIFNJRHMgdG8gbm9kZXMgb3V0c2lkZSB0aGUgU1IgRG9tYWluLg0KDQpG b3IgcmV0dXJuIHRyYWZmaWMgdG8gQTksIGFuIG91dGVyIElQdjYgaGVhZGVyIG1heSBiZSBhcHBs aWVkIGJ5IHRoZSBTUiBEb21haW4gaW5ncmVzcyBub2RlLiAgVGhpcyBvdXRlciBJUHY2IGhlYWRl ciBtYXkgdGVybWluYXRlIGF0IG5vZGUgOSwgdGhlcmVmb3JlIGEgaG9zdCBpbXBsZW1lbnRhdGlv biBNVVNUIHN1cHBvcnQgZGVjYXBzdWxhdGlvbiBvZiBhbiBvdXRlciBJUHY2IGhlYWRlciBhbmQg cHJvY2Vzc2luZyBvZiB0aGUgaW5uZXIgaGVhZGVyLg0KPC9ORVcgVEVYVD4NCg0KRm9yIHRyYWZm aWMgZGVzdGluZWQgd2l0aGluIHRoZSBTUiBEb21haW4gaXTigJlzIHN0aWxsIHVwIHRvIHRoZSBo b3N0IG9yIGNvbnRyb2xsZXIgcHJvdmlkaW5nIHRoZSBTUiBQb2xpY3kgdG8gZGV0ZXJtaW5lIHdo ZXRoZXIgb3Igbm90IHRoZXkgbXVzdCBlbmNhcHN1bGF0ZSBpbiBhbiBvdXRlciBJUHY2IGhlYWRl ci4NCg0KRGFycmVuDQoNCk9uIE9jdCAzMCwgMjAxOCwgYXQgMzo0MiBQTSwgSm9lbCBNLiBIYWxw ZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3Jv dGU6DQoNCkkgYW0gbm90IHN1cmUgSSBhZ3JlZSB0aGF0IHRoZSBhbGxvd2FuY2UgZm9yIGhhbmRs aW5nIHRoZSBITUFDIGVsc2V3aGVyZSBpcyBzdHJhaWdodGZvcndhcmQuICBGb3IgZXhhbXBsZSwg SSB0aGluayB0aGUgcmFuZ2Ugb2YgaW1wbGVtZW50YXRpb24gc3RyYXRlZ2llcyBmb3IgYm9yZGVy IG5vZGVzIGFuZCB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoYXQgd2l0aCB0aGUgcmFuZ2Ugb2Ygb3Bl cmF0aW9uYWwgYW5kIGRlcGxveW1lbnQgc3RyYXRlZ2llcyBpcyBnb2luZyB0byBhY3R1YWxseSBt YWtlIGl0IGhhcmRlciB0byBnZXQgbXVsdGktdmVuZG9yIGRlcGxveW1lbnRzLiAgSGF2aW5nIHNh aWQgdGhhdCwgdGhlIGFwcHJvYWNoIGluIHRoZSBkb2N1bWVudCB3aWxsIHdvcmsuICBBbmQgSSBj YW4gbGl2ZSB3aXRoIGl0Lg0KDQpPbiB0aGUgY2hvaWNlIG9mIGVuY2FwcyBvciBub3QgZW5jYXBz IChmcm9tIG5vZGUgOSB0byBleHRlcm5hbCBub2RlIDEpIHRoZXJlIGFyZSB0d28gaXNzdWVzLg0K VGhlIGltcG9ydGFudCBpc3N1ZSBpcyB0aGF0IG5vZGUgOSBuZWVkcyB0byBiZSBhYmxlIHRvIGVu Y2Fwcy4gT3RoZXJ3aXNlIHRoZXJlIGlzIG5vIGRlY2lzaW9uIGF2YWlsYWJlLCBhbmQgdGhlIG5v ZGVzIHNvZnR3YXJlIGlzIGZvcmNpbmcgdGhlIG9wZXJhdG9yIHRvIGRpc2Nsb3NlLCBldmVuIGlm IHRoZXJlIHBvbGljeSBpcyBub3QgdG8gZG8gc28uIFRodXMsIEkgdGhpbmsgdGhlIG1pbmltdW0g cmVxdWlyZW1lbnQgaXMgdGhhdCB0aGUgZG9jdW1lbnQgbmVlZHMgdG8gY2xlYXJseSBzdGF0ZSB0 aGF0IG5vZGUgOSBuZWVkcyB0byBiZSBhYmxlIHRvIGhhbmRsZSBpbmNvbWluZyBlbmNhcHMgYW5k IG5lZWRzIHRvIGJlIGFibGUgdG8gZ2VuZXJhdGUgb3V0Z29pbmcgZW5jYXBzLg0KDQpUaGUgbGVz c2VyIGlzc3VlIGlzICJ3aHkgYm90aGVyPyIgIFdoeSBub3QgYWx3YXlzIGVuY2Fwcy4gIEdpdmVu IHRoYXQgdGhlIG5ldHdvcmsgaGFzIHRvIGhhdmUgYW4gTVRVIGJpZyBlbm91Z2ggdG8gaGFuZGxl IGFuIGVuY2FwcyBwYWNrZXQgKGR1ZSB0byBpbmNvbWluZyBwYWNrZXRzIGZyb20gb3V0IHRoZSBT UiBkb21haW4pLCB0aGVyZSBpcyBubyBNVFUgaXNzdWUgd2lodCB0aGUgZW5jYXBzLiAgQXMgc3Vj aCwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgcmVkdWNpbmcgdGhlIHNlY3VyaXR5IGFuZCByb2J1c3Ru ZXNzIG9mIHRoZSBzb2x1dGlvbiBpbiBleGNoYW5nZSBmb3Igc2F2aW5nIGEgZmV3IGJ5dGVzLiAg VGhhdCBhbG1vc3QgbmV2ZXIgdHVybnMgb3V0IHdlbGwuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiAx MC8zMC8xOCAzOjMwIFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykgd3JvdGU6DQpJIHRoaW5rIHdl 4oCZcmUgYWxtb3N0IGNvbmNsdWRlZCBzbyBvbmNlIG1vcmUgaW5saW5lIGF0IDxkZD48L2RkPg0K T24gT2N0IDI2LCAyMDE4LCBhdCAyOjI4IFBNLCBKb2VsIEhhbHBlcm4gPGptaEBqb2VsaGFscGVy bi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCg0KKHJlc2VuZGluZywg K3NwcmluZyBhcyByZXF1ZXN0ZWQpDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJlc3BvbnNlcy4gIEkg d2lsbCByZXNwb25kIGluIGxpbmUsIG1hcmtlZCA8am1oPjwvam1oPi4gIEkgZmVhciBpdCB3aWxs IHNob3J0bHkgZ2V0IHRvbyBkZWVwLCBidXQgdGhlIGNvbnRleHQgaXMgaW1wb3J0YW50Lg0KDQpJ IHdpbGwgcmVwaHJhc2UgaGVyZSBhbiBpc3N1ZSBmcm9tIGFub3RoZXIgdGhyZWFkIHRoYXQgSSBh aHZlIG5vdCBzZWVuIHlvdXIgY29tbWVudHMgb24uICBJZiBOb2RlIDkgaXMgc2VuZGluZyB0cmFm ZmljIHRvIE5vZGUgMSAoZm9yIGV4YW1wbGUsIHRoZSByZXZlcnNlIHRyYWZmaWMgZm9yIHRoZSB0 cmFmZmljIGZyb20gMSB0byA5IGluIHRoZSBleGFtcGxlcyBiZWxvdyksIGl0IHByZXN1bWFibHkg aGFzIGFuIFNSIFBvbGljeSB0byBiZSBhcHBsaWVkLiBUaGUgaXNzdWUgSSByYWlzZWQgYmVmb3Jl IGlzIHRoZSBsZWFrYWdlIGlzc3VlLiAgSWYgOSBwdXRzIHRoZSBTUkggaW4gaXRzIHBhY2tldCAo YXMgdGhlIGRvY3VtZW50IGN1cnJlbnRseSBtYW5kYXRlcyksIHRoZW4gaXQgd2lsbCBub3QgYmUg cG9zc2libGUgZm9yIDMgdG8gcmVtb3ZlIHRoZSBTUkguICBUaHVzLCB0aGUgU1JIIHdpbGwgbGVh ay4NCg0KU29tZSBoYXZlIGFyZ3VlZCB0aGF0IGlzIG5vdCBhIGJpZyBkZWFsLiAgSXQgc2VlbXMg dG8gbWF0dGVyIHRvIG1lLiAgQnV0IHRoZXJlIGlzIGFuIGFkZGl0aW9uYWwgcHJvYmxlbS4gIEEx IGlzIG5vdCBhIFNJRC4gIFRoZXJlZm9yZSwgOSBjYW4gbm90IHB1dCBBMSBpbnRvIHRoZSBTUkgu ICBJZiBpdCBjYW4gbm90IHB1dCBBMSBpbnRvIHRoZSBTUkgsIGFuZCBpdCBkb2VzIG5vdCBlbmNh cHN1bGF0ZSB0aGUgcGFja2V0LCB3aGVyZSBkb2VzIGl0IHB1dCBBMS4NCjxkZD4gTm9kZSA5IGhh cyBhIGNob2ljZSwgZW5jYXBzdWxhdGUgdG8gbm9kZSAzIG9yIG5vdC4NCklmIG5vZGUgOSBkb2Vz IG5vdCBlbmNhcHN1bGF0ZSwgaXQgd2lsbCBpbmZvcm0gdGhlIGRlc3RpbmF0aW9uIG9mIHRoZSBz ZWdtZW50cyBpbiB0aGUgU1JIIGFuZCBwb3NzaWJseSBsZWFrIHRoZW0gdG8gaW50ZXJtZWRpYXRl IG5vZGVzLg0KSWYgbm9kZSA5IGRvZXMgZW5jYXBzdWxhdGUsIG5vZGUgMyByZW1vdmVzIHRoZSBv dXRlciBoZWFkZXIgYW5kIG5vZGUgMSB3b3VsZCBub3QgbGVhcm4gdGhlIHNlZ21lbnQgbGlzdC4N CkkgdGhpbmsgaXRzIGNob2ljZSBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGluIHRoZSBkcmFmdC4g PC9kZD4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDEwLzI2LzE4IDE6MjkgUE0sIERhcnJlbiBEdWtl cyAoZGR1a2VzKSB3cm90ZToNCkhpIEpvZWwsIHlvdeKAmXZlIGRlc2NyaWJlZCBzZWN0aW9ucyB0 aXRsZWQg4oCcSW50cmEgU1IgRG9tYWluIFBhY2tldOKAnSwg4oCcVHJhbnNpdCBQYWNrZXQgVGhy b3VnaCBTUiBEb21haW7igJ0sIGFuZCAiU1IgU291cmNlIE5vZGVzIE5vdCBEaXJlY3RseSBDb25u ZWN0ZWTigJ0uDQpJ4oCZdmUgcGFyc2VkIHRoZW0gaW5saW5lIHRvIHRoZSBzZWN0aW9ucyBvZiB0 aGUgZHJhZnQgZGVmaW5pbmcgdGhlbSBhbmQgZ2l2ZW4gbW9yZSBjb250ZXh0IHdoZXJlIG5lZWRl ZC4NCk9uIE9jdCAyMiwgMjAxOCwgYXQgODo0OSBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9l bGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQoNClJlcGhy YXNpbmcgdXNpbmcgdGhlIGV4YW1wbGUgZnJvbSA1LjIuICBBc3N1bWluZyB0aGF0IDggYW5kIDkg YXJlIFNSIEhvc3RzIChub3QganVzdCBob3N0cyB3aXRoaW4gdGhlIGRvbWFpbiwgdGhleSBhcmUg Y2FwYWJsZSBvZiBhbmQgZXhwZWN0IHRvIGRlYWwgd2l0aCBTUkhzLCBhbmQgdGhlcmVmb3JlIGhh dmUgbG9jYWwgU0lEcywgLi4uKQ0KDQpGb3IgdHJhZmZpYyBmcm9tIDggdG8gOSB0aGF0IG5lZWRz IGFuIFNSSCwgdGhlIFNSSCBnb2VzIGluIHRoZSBJUHY2IGhlYWRlciBzZW50IG15IDggdG8gOS4g IFdoZW4gOSBwcm9jZXNzZXMgdGhlIHBhY2tldCwgaXQgc2VlbXMgdGhhdCBpdCBpcyB0aGUgbGFz dCBTSUQsIGZpZ3VyZXMgb3V0IHRoYXQgdGhlcmUgaXMgbm8gZW5jYXBzdWxhdGlvbiwgYW5kIHNl bmQgdGhlIFRDUCAvIFVEUCAvIFFVSUMgaW5mb3JtYXRpb24gdG8gaXRzIGludGVybmFsIHByb3Rv Y29scyBzdGFja3MuDQpZZXMsIHRoaXMgaXMgU2VjdGlvbiA1LjMuMSDigJxJbnRyYSBTUiBEb21h aW4gUGFja2V04oCdLg0KPGptaD5BZ3JlZWQgYXMgZmFyIGFzIGl0IGdvZXMuICBIb3dldmVyLCAg dGhlIGV4aXN0ZW5jZSBvZiBTOSBhbmQgQTkgcG9pbnRzIHRvIGEgcHJvYmxlbS4gIE5vZGUgOCBp cyB0cnlpbmcgdG8gcHV0IG9uIGFuIFNSSCBnb2luZyB0aHJvdWdoIFN4LCBTeSwgd2hhdGV2ZXIg Zm9yIHNvbWUgcmVhc29uLiAgSXQgY2FuJ3QgcHV0IEE5IGludG8gdGhlIFNSSCwgYXMgQUggaXMg bm90IGEgU0lELCBpdCBpcyBhbiBhZGRyZXNzLiAgSSBwcmVzdW1lIG5vZGUgOCBnb3QgUzkgZnJv bSB3aGF0ZXZlciBwcm92aWRlZCBoaW0gdGhlIFNSIFBvbGljeSB0aGF0IGl0IGlzIHVzaW5nLiAg RG9lcyBpdCBzaW1wbHkgdXNlIFM5IGFzIHRoZSBhZGRyZXNzIGZvciBub2RlIDksIHJhdGhlciB0 aGFuIEE5IHRoYXQgaXQgZ290IGZyb20gRE5TPyAgQW5kIGRvZXMgdGhlIFRDUCBzdGFjayBrbm93 IHRoYXQgdGhpcyBzdWJzdGl0dXRpb24gaXMgYmVpbmcgbWFkZT8gIChUaGlzIGlzIGFub3RoZXIg ZXhhbXBsZSBvZiBhIHByb2JsZW0gdGhhdCBnb2VzIGF3YXkgaWYgd2UgYWx3YXlzIGVuY2Fwc3Vs YXRlLikgPC9qbWg+DQo8ZGQ+U2VjdGlvbiA0LjMuMiBjb3ZlcnMgdGhlc2UgcXVlc3Rpb25zLCBp LmUuIEE5IGNhbiBiZSBwbGFjZWQgaW4gdGhlIFNSSCBhcyB0aGUgbGFzdCBzZWdtZW50LCBhbmQg dGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBob3cgaXTigJlzIGhhbmRsZWQuPC9kZD4NCg0KDQpGb3Ig dHJhZmZpYyBmcm9tIDEgdG8gOSwgd2hlcmUgMyBhZGRzIGFuIFNSSCwgdGhhdCBTUkggc3RpbGwg cHJlc3VtYWJseSBlbmRzIGF0IDkuICA5IFJlY2VpdmVzIHRoZSBJUCBwYWNrZXQuICBTZWVzIHRo YXQgaXQgaXMgYWRkcmVzc2VkIHRvIGl0c2VsZi4gIFNlZXMgdGhhdCB0aGUgU1JIIGlzIGZpbmlz aGVkLiAgQW5kIHRoZW4gbm90aWNlcyB0aGF0IHRoZSBuZXh0LWhlYWRlciBpcyBJUHY2LiAgVW53 cmFwcyB0aGUgaGVhZGVyLCBjaGVja3MgdGhhdCB0aGUgaW5uZXIgZGVzdGluYXRpb24gYWRkcmVz cyBpcyBhbHNvIGl0c2VsZiwgYW5kIHBhc3NlcyB0aGUgbWF0ZXJpYWwgY2FycmllZCBieSB0aGUg aW5uZXIgaGVhZGVyIHVwIHRvIHRoZSBhcHByb3ByaWF0ZSBzdGFjay4NClNvIG5vZGUgMSBzZW5k cyBhIHBhY2tldCB0byBub2RlIDkgKEExLEE5KQ0KSUYgdGhlcmUgaXMgc29tZSBzdGVlcmluZyBp bnRvIGFuIFNSIFBvbGljeSBhdCBub2RlIDMgdG8gcmVhY2ggbm9kZSA5LCB0aGlzIGlzIGlkZW50 aWNhbCB0byBzZWN0aW9uIDUuMy4yIOKAnFRyYW5zaXQgcGFja2V0IHRocm91Z2ggU1IgZG9tYWlu 4oCdLCBleGNlcHQgZm9yIGRlc3RpbmF0aW9uIG9mIEE5IHZpYSBub2RlIDkgIGluc3RlYWQgb2Yg QTIgdmlhIG5vZGUgNC4NCg0KDQpUaHVzLCA5IG5lZWRzIHRvIGJlIGFibGUgdG8gY2hlY2sgZm9y IGJvdGggY2FzZXMuICBXZSBhdCBsZWFzdCBuZWVkIHRvIHRlbGwgaW1wbGVtZW50b3JzIHRoYXQu DQpXZWxsLCA5IG5lZWRzIGEgU0lEIFM5IGFuZCBBZGRyZXNzIEE5LiAgVGhhdCBpcyBzaG93biBp biBTZWN0aW9uIDUuMSBTSUQgYW5kIGFkZHJlc3MgcmVwcmVzZW50YXRpb24uDQo8am1oPlNvLCBs ZXQgdXMgYXNzdW1lIHRoYXQgMyBoYXMgYW4gU1IgcG9saWN5IGl0IHdhbnRzIHRvIGFwcGx5IHRv IHRoZSB0cmFmZmljIGZyb20gQTEgdG8gQTkuICBJbiB0aGlzIGNhc2UsIHRoZSBTOSAvIEE5IGRp Y2hvdG9teSBpcyBub3QgYSBwcm9ibGVtLCBJIHRoaW5rLiAgTm9kZSAzIGVuY2Fwc3VhbHRlcyB0 aGUgcGFja2V0IGZyb20gQTEgdG8gQTksIHVzZXMgUzMgYXMgdGhlIHNvdXJjZSBhZGRyZXNzIG9m IHRoZSBlbmNhcHN1bGF0aW5nIGhlYWRlciwgYW5kIGVuZHMgdGhlIFNJRCBsaXN0IGluIHRoZSBT Ukggd2l0aCBTOS4gIFRoZSB1bnNwZWNpZmllZCBwYXJ0IGlzIHRoYXQgbm9kZSA5IG5lZWRzIHRv IGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgc3VjaCBwYWNrZXRzIGFuZCBkbyB0aGUgZG91YmxlIHBy b2Nlc3NpbmcuICBJdCBpcyByZWFzb25hYmxlIGRvdWJsZSBwcm9jZXNzaW5nLiAgTXkgb25seSBy ZXF1ZXN0IGhlcmUgaXMgdGhhdCB3ZSB0ZWxsIGZvbGtzIHRoZXkgbmVlZCB0byBzdXBwb3J0IGl0 LiA8L2ptaD4NCjxkZD5BY3R1YWxseSwgbm9kZSAzIHVzZXMgQTMgYXMgaXRzIHNvdXJjZSBhZGRy ZXNzLCBidXQgdGhhdOKAmXMgbWlub3IuDQpUaGUgZG91YmxlIHByb2Nlc3NpbmcgKGxvb2t1cCwg ZG8gZW5kIHByb2Nlc3NpbmcsIGRvIGFub3RoZXIgbG9va3VwKSBpcyBkb2N1bWVudGVkIGluIFNl Y3Rpb24gNC4zLg0KSXMgdGhlcmUgYSBuZWVkIGZvciBtb3JlIHRoYW4gd2hhdCBpcyBjdXJyZW50 bHkgc3BlY2lmaWVkPyA8L2RkPg0KDQpUaGVyZSBpcyBhIGZ1cnRoZXIgY29tcGxpY2F0aW9uLiAg OSBzZWVtcyB0byBuZWVkIHRvIGhhdmUgYW4gYWRkcmVzcyB0aGF0IGlzIGEgdmFsaWQgU0lELCBz byBpdCBjYW4gYmUgdGhlIGxhc3QgZW50cnkgaW4gdGhlIFNSSCBmcm9tIDggdG8gOS4NCkFzIGRl c2NyaWJlZCBpbiB0aGUgZHJhZnQsIFNlY3Rpb24gNS4xIGEgbm9kZSBrIGhhcyBhbiBhZGRyZXNz IEFrIGFuZCBTSUQgU2suICBTbyBub2RlIDkgaGFzIGEgdmFsaWQgU0lELg0KRm9yIHRyYWZmaWMg ZnJvbSA4IHRvIDksIEE5IGlzIHVzZWQgYXMgdGhlIGRlc3RpbmF0aW9uIGFzIHNob3duIGluIHNl Y3Rpb24gNS4zLjEsIDUuNCBhbmQgNS41Lg0KIEhvd2V2ZXIsIGlmIDEgd2VyZSB0byBzZW5kIHRo ZSBwYWNrZXQgdG8gdGhhdCBTSUQgZm9yIDksIHJvdXRlciAzIHdvdWxkIGJlIHJlcXVpcmVkIGJ5 IHRoZSBydWxlcyB3ZSBkaXNjdXNzZWQgaW4gdGhlIG90aGVyIHRocmVhZCB0byBkaXNjYXJkIHRo ZSBwYWNrZXQgYXMgaXQgaXMgbmVpdGhlciB0byBwcmVmaXggbm9yIGNvbnRhaW5zIGFuIEhBTUMu DQogQW5kIHNvbWVob3csIDggYW5kIDEgbmVlZCB0byBlYWNoIHBpY2sgdGhlIHJpZ2h0IGFkZHJl c3MgdG8gdXNlIGZvciA5LiAoc3BsaXQgRE5TIG1heWJlPykgIEFuZCAzIG5lZWRzIHRvIGJlIGFi bGUgdG8gZGVyaXZlIHRlaCBTSUQtZm9ybW4gYWRkcmVzcyBmb3IgOSBmcm9tIHRoZSBub24tU0lE IGZvcm0gb2YgdGhlIGFkZHJlc3Mgc28gdGhhdCBpdCAoMykgY2FuIGJ1aWxkIGEgcHJvcGVyIFNS SCB0byBnZXQgdGhlIHBhY2tldCB0byA5Lg0KPGptaD5JIGhhdmUgcmV0YWluZWQgeW91ciBhbnN3 ZXIgYmVsb3cgZm9yIGNvbnRleHQsIGJ1dCBJIHRoaW5rIHRoYXQgYW5zd2VycyB0aGUgd3Jvbmcg cXVlc3Rpb24uICBJIGJlbGlldmUgd2hhdCBpcyBpdG5lbmRlZCBpcyB0aGF0IG9ubHkgQTkgYXBw ZWFycyBpbiBETlMuICBTbyBOb2RlIDEgd2lsbCBzZWUgOSBhcyBBOSwgYW5kIHdpbGwgdXNlIHRo YXQuICBTOSB3aWxsIGFwcGVhciBpbiBTUiBQb2xpY2llcyBhYm91dCB0cmFmZmljIHRvIG5vZGUg OSwgYnV0IG5vdCBpbiBETlMuICBUaGF0IGlzIHdoYXQgd2UgbmVlZC4gIEkgd2lzaCBpdCB3ZXJl IGNsZWFyZXIgaW4gdGhlIHRleHQuIDwvam1oPg0KDQo8am1oPklmIG5vZGUgMjAgaXMgZ2VuZXJh dGluZyBTUkhzIHdpdGggSE1BQ3MsIHRoZW4gdGhpcyBpcyBsYXJnZWx5IHRoZSBzYW1lIGFzIHRo ZSBjYXNlIGZyb20gOCB0byA5LCBleGNlcHQgdGhhdCB3aG9tZXZlciBjcmVhdGVzIHRoZSBTUiBQ b2xpY3kgdGhhdCAyMCBpcyB1c2luZyBuZWVkcyB0byBhbHNvIG1ha2Ugc3VyZSB0aGF0IHdoYXRl dmVyIHRoZSBmaXJzdCBTSUQgaXMgaW4gdGVoIGxpc3QsIGl0IHByb2Nlc3NlcyBITUFDcyBhbmQg aXMgcmVjb2duaXphYmxlIHRvIG5vZGUgMyBhcyBkb2luZyBzdWNoIHByb2Nlc3NpbmcuIEkgYW0g Z3Vlc3NpbmcgdGhhdCB0aGUgcmVhc29uIGZvciBhbGxvd2luZyBpbnRlcm5hbCBub2RlcyB0byBk byB0aGUgcHJvY2Vzc2luZyBpcyB0byBtb3ZlIHRoZSB2ZXJpZmljYXRpb24gbG9hZCBvZmYgdGhl IGVkZ2Ugbm9kZXMuICBJdCBkb2VzIGNyZWF0ZSBzaWduaWZpY2FudCBhZGRpdGlvbmFsIGNvbmZp Z3VyYXRpb24gY29tcGxleGl0eS4gPC9qbWg+DQo8ZGQ+V2UgZGlkbuKAmXQgc2VlIGEgcmVhc29u IHRvIHJlc3RyaWN0IHRoZSBITUFDIHByb2Nlc3NpbmcgdG8gb25seSBlZGdlIG5vZGVzIHdoZW4g aXQgd2FzIHN0cmFpZ2h0IGZvcndhcmQgdG8gZGVmaW5lIGhvdyB0aGV5IGNvdWxkIGJlIHByb2Nl c3NlZCBhdCBub24tZWRnZSBub2Rlcy48L2RkPg0KDQpUaGlzIGlzIGluY29ycmVjdC4NClNlZSBT ZWN0aW9uIDYuMi4xIOKAnFNSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0bHkgQ29ubmVjdGVk4oCd IEkgd2lsbCBleHBhbmQgb24gdGhlIGV4YW1wbGUgZnJvbSB0aGF0IHNlY3Rpb24uDQpOb2RlIDIw IHNlbmRzIGEgcGFja2V0IHRvIEE5IHdpdGggU1IgUG9saWN5IDxINz4gYW5kIGFuIEhNQUMgcHJv dmlkZWQgdG8gbm9kZSAyMCBieSBzb21lIHlldCB0byBiZSBkZWZpbmVkIG1ldGhvZC4gIFJlc3Vs dGluZyBpbiBwYWNrZXQgc2VudCBmcm9tIG5vZGUgMjANCiAgUDogKEEyMCxINykoQTk7U0w9MSko cGF5bG9hZCkNClJlY2FsbCBIayBpcyBhIFNJRCBhdCBub2RlIGsgcmVxdWlyaW5nIEhNQUMgdmVy aWZpY2F0aW9uLCBhbmQgaXQgaXMgY292ZXJlZCBieSBQcmVmaXgtSC4NClByZWZpeC1IIGlzIF9u b3RfIHN1YmplY3QgdG8gaW5ncmVzcyBmaWx0ZXJpbmcgYXQgbm9kZSAzLg0KVGhlcmVmb3JlIHRo ZSBwYWNrZXQgUCBkZXN0aW5lZCB0byBINyBpcyBub3Qgc3ViamVjdCB0byBpbmdyZXNzIGZpbHRl cmluZyBhdCBub2RlIDMuDQpQIGlzIGZvcndhcmRlZCB0byBub2RlIDcsIHdoZXJlIEg3IGlzIHBy b2Nlc3NlZCBhbmQgdGhlIEhNQUMgdmVyaWZpZWQuDQpJZiB0aGUgSE1BQyBjYW4gbm90IGJlIHZl cmlmaWVkIHRoZSBwYWNrZXQgaXMgZHJvcHBlZCwgZWxzZSBpdCBpcyBmb3J3YXJkZWQgdG8gdGhl IG5leHQgc2VnbWVudCBhbmQgZGVzdGluYXRpb24sIEE5Lg0KRGFycmVuDQoNCllvdXJzLA0KSm9l bA0KDQpPbiAxMC8yMi8xOCA4OjA0IFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykgd3JvdGU6DQpp bmxpbmUuDQpPbiBPY3QgMjIsIDIwMTgsIGF0IDc6MjEgUE0sIEpvZWwgTS4gSGFscGVybiA8am1o QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0KLi4N CjIpIE5vdyBsZXQgdXMgbG9vayBhdCBwYWNrZXRzIGFycml2aW5nIGF0IGFuZCBhY3R1YWxseSBk ZXN0aW5lZCBmb3IgYW4gU1IgSG9zdCBpbiB0aGUgU1IgRG9tYWluIHdoZXJlIHRoYXQgcGFja2V0 IGhhcyBhbiBTUkguICBJZiB0aGUgcGFja2V0IGlzIGNvbWluZyBmcm9tIGFub3RoZXIgU1IgSG9z dCwgdGhlIFNSSCB3aWxsIGJlIGluIHRoZSBiYXNlIGhlYWRlciwgYW5kIHRoZSBob3N0IGNhbiBz aW1wbHkgY2hlY2sgaXQgZm9yIGFueSB2aW9sYXRpb25zLCBhbmQgY29udGludWUuICBCdXQsIGlm IHRoZSBwYWNrZXQgY2FtZSBmcm9tIG91dHNpZGUgdGhlIGRvbWFpbiwgdGhlbiBpdCB3aWxsIGhh dmUgYW4gZW5jYXBzdWxhdGluZyBTUnY2IGhlYWRlci4gIFNvIHRoZSBob3N0IGhhcyB0byBkZXRl Y3QgdGhpcyBjYXNlLCBjaGVjayBhbmQgdGhlbiBwZWFsIG9mZiB0aGUgZW5jYXBzdWxhdGluZyBo ZWFkZXIsIGFuZCB0aGVuIHByb2Nlc3MgdGhlIHJlY2VpdmVkIHBhY2tldC4gWWVzLCBpdCBjYW4g ZG8gc28uICBCdXQgbm90aGluZyBpbiB0ZWggZG9jdW1lbnQgdGVsbHMgaW1wbGVtZW50b3JzIHRo ZXkgaGF2ZSB0byBkZWFsIHdpdGggYm90aCBjYXNlcy4NCg0KQ2FuIHlvdSBiZSBtb3JlIHByZWNp c2UgaGVyZS4gIFBlcmhhcHMgdXNlIHRoZSBleGFtcGxlIGZyb20gc2VjdGlvbiA1LjIgb3IgNi4y LjE/DQouLg0KDQo= --_000_679B2EEF4EE644BCA9D717E70FF1133Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <144E67C1665CED4994A25E700C56964A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpKb2VsLCBGb3Igb3VyIGxhc3QgcmVtYWluaW5n IGl0ZW0gaW4gdGhpcyB0aHJlYWQsIDxiIGNsYXNzPSIiPnJlOiBjb21tdW5pY2F0aW9uIGZyb20g MSB0byA5IGFuZCA5IHRvIDEuPC9iPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+TGV0cyBhZGQgdGhlIGZvbGxvd2luZyBzaW5jZSB3ZSBkb27igJl0 IGRpc2N1c3MgdHJhZmZpYyBmcm9tIGEgaG9zdCB3aXRoaW4gdGhlIFNSIERvbWFpbiB0byBhIGhv c3Qgb3V0c2lkZSB0aGUgU1IgRG9tYWluLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmx0O05FVyBURVhUJmd0OzwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPjUuMy4z IEludGVyIFNSIERvbWFpbiBQYWNrZXQ8L2I+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5Ib3N0IDkgc2VuZHMgYSBwYWNrZXQgdG8gaG9zdCAxIChvdXRzaWRlIHRoZSBTUiBE b21haW4pIHZpYSBhbiBTUiBQb2xpY3kgJmx0O1M2LFMzJmd0Oy48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+SG9zdCA5IGVuY2Fwc3VsYXRlcyBhbiBpbm5lciBwYWNrZXQgZnJvbSA5IHRvIDEgaW4gYW4g b3V0ZXIgSVB2NiBoZWFkZXIgYW5kIGFkZHMgYW4gU1JIIGZvciB0aGUgU1IgUG9saWN5LjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwO1A3OiAoQTksUzYpKFMzLFM2OyBTTD0xKShBOSxBMSkmbmJzcDs8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkEgaG9zdCBp bXBsZW1lbnRhdGlvbiBNVVNUIHN1cHBvcnQgYWRkaXRpb24gb2YgdGhlIG91dGVyIElQdjYgZW5j YXBzdWxhdGlvbiB0byBhdm9pZCBsZWFraW5nIFNJRHMgdG8gbm9kZXMgb3V0c2lkZSB0aGUgU1Ig RG9tYWluLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Rm9yIHJldHVybiB0cmFmZmljIHRvIEE5LCBhbiBvdXRlciBJUHY2IGhlYWRlciBt YXkgYmUgYXBwbGllZCBieSB0aGUgU1IgRG9tYWluIGluZ3Jlc3Mgbm9kZS4gJm5ic3A7VGhpcyBv dXRlciBJUHY2IGhlYWRlciBtYXkgdGVybWluYXRlIGF0IG5vZGUgOSwgdGhlcmVmb3JlIGEgaG9z dCBpbXBsZW1lbnRhdGlvbiBNVVNUIHN1cHBvcnQgZGVjYXBzdWxhdGlvbiBvZiBhbiBvdXRlciBJ UHY2IGhlYWRlciBhbmQgcHJvY2Vzc2luZyBvZg0KIHRoZSBpbm5lciBoZWFkZXIuPC9kaXY+DQom bHQ7L05FVyBURVhUJmd0OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Rm9yIHRyYWZmaWMgZGVzdGluZWQgd2l0aGluIHRoZSBTUiBEb21h aW4gaXTigJlzIHN0aWxsIHVwIHRvIHRoZSBob3N0IG9yIGNvbnRyb2xsZXIgcHJvdmlkaW5nIHRo ZSBTUiBQb2xpY3kgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRoZXkgbXVzdCBlbmNhcHN1 bGF0ZSBpbiBhbiBvdXRlciBJUHY2IGhlYWRlci48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkRhcnJlbjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIE9jdCAzMCwgMjAxOCwgYXQgMzo0MiBQTSwgSm9lbCBNLiBIYWxw ZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgY2xhc3M9IiI+am1o QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkkgYW0g bm90IHN1cmUgSSBhZ3JlZSB0aGF0IHRoZSBhbGxvd2FuY2UgZm9yIGhhbmRsaW5nIHRoZSBITUFD IGVsc2V3aGVyZSBpcyBzdHJhaWdodGZvcndhcmQuICZuYnNwO0ZvciBleGFtcGxlLCBJIHRoaW5r IHRoZSByYW5nZSBvZiBpbXBsZW1lbnRhdGlvbiBzdHJhdGVnaWVzIGZvciBib3JkZXIgbm9kZXMg YW5kIHRoZSBpbnRlcnNlY3Rpb24gb2YgdGhhdCB3aXRoIHRoZSByYW5nZSBvZiBvcGVyYXRpb25h bCBhbmQgZGVwbG95bWVudA0KIHN0cmF0ZWdpZXMgaXMgZ29pbmcgdG8gYWN0dWFsbHkgbWFrZSBp dCBoYXJkZXIgdG8gZ2V0IG11bHRpLXZlbmRvciBkZXBsb3ltZW50cy4gJm5ic3A7SGF2aW5nIHNh aWQgdGhhdCwgdGhlIGFwcHJvYWNoIGluIHRoZSBkb2N1bWVudCB3aWxsIHdvcmsuICZuYnNwO0Fu ZCBJIGNhbiBsaXZlIHdpdGggaXQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gdGhl IGNob2ljZSBvZiBlbmNhcHMgb3Igbm90IGVuY2FwcyAoZnJvbSBub2RlIDkgdG8gZXh0ZXJuYWwg bm9kZSAxKSB0aGVyZSBhcmUgdHdvIGlzc3Vlcy48YnIgY2xhc3M9IiI+DQpUaGUgaW1wb3J0YW50 IGlzc3VlIGlzIHRoYXQgbm9kZSA5IG5lZWRzIHRvIGJlIGFibGUgdG8gZW5jYXBzLiBPdGhlcndp c2UgdGhlcmUgaXMgbm8gZGVjaXNpb24gYXZhaWxhYmUsIGFuZCB0aGUgbm9kZXMgc29mdHdhcmUg aXMgZm9yY2luZyB0aGUgb3BlcmF0b3IgdG8gZGlzY2xvc2UsIGV2ZW4gaWYgdGhlcmUgcG9saWN5 IGlzIG5vdCB0byBkbyBzby4gVGh1cywgSSB0aGluayB0aGUgbWluaW11bSByZXF1aXJlbWVudCBp cyB0aGF0IHRoZSBkb2N1bWVudA0KIG5lZWRzIHRvIGNsZWFybHkgc3RhdGUgdGhhdCBub2RlIDkg bmVlZHMgdG8gYmUgYWJsZSB0byBoYW5kbGUgaW5jb21pbmcgZW5jYXBzIGFuZCBuZWVkcyB0byBi ZSBhYmxlIHRvIGdlbmVyYXRlIG91dGdvaW5nIGVuY2Fwcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGUgbGVzc2VyIGlzc3VlIGlzICZxdW90O3doeSBib3RoZXI/JnF1b3Q7ICZuYnNw O1doeSBub3QgYWx3YXlzIGVuY2Fwcy4gJm5ic3A7R2l2ZW4gdGhhdCB0aGUgbmV0d29yayBoYXMg dG8gaGF2ZSBhbiBNVFUgYmlnIGVub3VnaCB0byBoYW5kbGUgYW4gZW5jYXBzIHBhY2tldCAoZHVl IHRvIGluY29taW5nIHBhY2tldHMgZnJvbSBvdXQgdGhlIFNSIGRvbWFpbiksIHRoZXJlIGlzIG5v IE1UVSBpc3N1ZSB3aWh0IHRoZSBlbmNhcHMuICZuYnNwO0FzIHN1Y2gsIHdlIGFyZSB0YWxraW5n IGFib3V0DQogcmVkdWNpbmcgdGhlIHNlY3VyaXR5IGFuZCByb2J1c3RuZXNzIG9mIHRoZSBzb2x1 dGlvbiBpbiBleGNoYW5nZSBmb3Igc2F2aW5nIGEgZmV3IGJ5dGVzLiAmbmJzcDtUaGF0IGFsbW9z dCBuZXZlciB0dXJucyBvdXQgd2VsbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpZb3Vy cyw8YnIgY2xhc3M9IiI+DQpKb2VsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gMTAv MzAvMTggMzozMCBQTSwgRGFycmVuIER1a2VzIChkZHVrZXMpIHdyb3RlOjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkkgdGhpbmsgd2XigJlyZSBhbG1vc3Qg Y29uY2x1ZGVkIHNvIG9uY2UgbW9yZSBpbmxpbmUgYXQgJmx0O2RkJmd0OyZsdDsvZGQmZ3Q7PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gT2N0IDI2LCAy MDE4LCBhdCAyOjI4IFBNLCBKb2VsIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tIiBjbGFzcz0iIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKHJlc2VuZGluZywgJiM0MztzcHJpbmcgYXMg cmVxdWVzdGVkKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rIHlvdSBmb3IgdGhl IHJlc3BvbnNlcy4gJm5ic3A7SSB3aWxsIHJlc3BvbmQgaW4gbGluZSwgbWFya2VkICZsdDtqbWgm Z3Q7Jmx0Oy9qbWgmZ3Q7LiAmbmJzcDtJIGZlYXIgaXQgd2lsbCBzaG9ydGx5IGdldCB0b28gZGVl cCwgYnV0IHRoZSBjb250ZXh0IGlzIGltcG9ydGFudC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpJIHdpbGwgcmVwaHJhc2UgaGVyZSBhbiBpc3N1ZSBmcm9tIGFub3RoZXIgdGhyZWFkIHRo YXQgSSBhaHZlIG5vdCBzZWVuIHlvdXIgY29tbWVudHMgb24uICZuYnNwO0lmIE5vZGUgOSBpcyBz ZW5kaW5nIHRyYWZmaWMgdG8gTm9kZSAxIChmb3IgZXhhbXBsZSwgdGhlIHJldmVyc2UgdHJhZmZp YyBmb3IgdGhlIHRyYWZmaWMgZnJvbSAxIHRvIDkgaW4gdGhlIGV4YW1wbGVzIGJlbG93KSwgaXQg cHJlc3VtYWJseSBoYXMgYW4gU1IgUG9saWN5IHRvIGJlIGFwcGxpZWQuDQogVGhlIGlzc3VlIEkg cmFpc2VkIGJlZm9yZSBpcyB0aGUgbGVha2FnZSBpc3N1ZS4gJm5ic3A7SWYgOSBwdXRzIHRoZSBT UkggaW4gaXRzIHBhY2tldCAoYXMgdGhlIGRvY3VtZW50IGN1cnJlbnRseSBtYW5kYXRlcyksIHRo ZW4gaXQgd2lsbCBub3QgYmUgcG9zc2libGUgZm9yIDMgdG8gcmVtb3ZlIHRoZSBTUkguICZuYnNw O1RodXMsIHRoZSBTUkggd2lsbCBsZWFrLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNv bWUgaGF2ZSBhcmd1ZWQgdGhhdCBpcyBub3QgYSBiaWcgZGVhbC4gJm5ic3A7SXQgc2VlbXMgdG8g bWF0dGVyIHRvIG1lLiAmbmJzcDtCdXQgdGhlcmUgaXMgYW4gYWRkaXRpb25hbCBwcm9ibGVtLiAm bmJzcDtBMSBpcyBub3QgYSBTSUQuICZuYnNwO1RoZXJlZm9yZSwgOSBjYW4gbm90IHB1dCBBMSBp bnRvIHRoZSBTUkguICZuYnNwO0lmIGl0IGNhbiBub3QgcHV0IEExIGludG8gdGhlIFNSSCwgYW5k IGl0IGRvZXMgbm90IGVuY2Fwc3VsYXRlIHRoZSBwYWNrZXQsIHdoZXJlIGRvZXMgaXQgcHV0DQog QTEuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KJmx0O2RkJmd0OyBOb2RlIDkgaGFzIGEg Y2hvaWNlLCBlbmNhcHN1bGF0ZSB0byBub2RlIDMgb3Igbm90LjxiciBjbGFzcz0iIj4NCklmIG5v ZGUgOSBkb2VzIG5vdCBlbmNhcHN1bGF0ZSwgaXQgd2lsbCBpbmZvcm0gdGhlIGRlc3RpbmF0aW9u IG9mIHRoZSBzZWdtZW50cyBpbiB0aGUgU1JIIGFuZCBwb3NzaWJseSBsZWFrIHRoZW0gdG8gaW50 ZXJtZWRpYXRlIG5vZGVzLjxiciBjbGFzcz0iIj4NCklmIG5vZGUgOSBkb2VzIGVuY2Fwc3VsYXRl LCBub2RlIDMgcmVtb3ZlcyB0aGUgb3V0ZXIgaGVhZGVyIGFuZCBub2RlIDEgd291bGQgbm90IGxl YXJuIHRoZSBzZWdtZW50IGxpc3QuPGJyIGNsYXNzPSIiPg0KSSB0aGluayBpdHMgY2hvaWNlIHNo b3VsZCBub3QgYmUgbWFuZGF0ZWQgaW4gdGhlIGRyYWZ0LiAmbHQ7L2RkJmd0OzxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCllvdXJz LDxiciBjbGFzcz0iIj4NCkpvZWw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAxMC8y Ni8xOCAxOjI5IFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykgd3JvdGU6PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SGkgSm9lbCwgeW914oCZdmUgZGVzY3Jp YmVkIHNlY3Rpb25zIHRpdGxlZCDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLCDigJxUcmFu c2l0IFBhY2tldCBUaHJvdWdoIFNSIERvbWFpbuKAnSwgYW5kICZxdW90O1NSIFNvdXJjZSBOb2Rl cyBOb3QgRGlyZWN0bHkgQ29ubmVjdGVk4oCdLjxiciBjbGFzcz0iIj4NCknigJl2ZSBwYXJzZWQg dGhlbSBpbmxpbmUgdG8gdGhlIHNlY3Rpb25zIG9mIHRoZSBkcmFmdCBkZWZpbmluZyB0aGVtIGFu ZCBnaXZlbiBtb3JlIGNvbnRleHQgd2hlcmUgbmVlZGVkLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIE9jdCAyMiwgMjAxOCwgYXQgODo0OSBQTSwgSm9l bCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgY2xh c3M9IiI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClJlcGhyYXNpbmcgdXNpbmcgdGhlIGV4YW1wbGUgZnJvbSA1LjIuICZuYnNw O0Fzc3VtaW5nIHRoYXQgOCBhbmQgOSBhcmUgU1IgSG9zdHMgKG5vdCBqdXN0IGhvc3RzIHdpdGhp biB0aGUgZG9tYWluLCB0aGV5IGFyZSBjYXBhYmxlIG9mIGFuZCBleHBlY3QgdG8gZGVhbCB3aXRo IFNSSHMsIGFuZCB0aGVyZWZvcmUgaGF2ZSBsb2NhbCBTSURzLCAuLi4pPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KRm9yIHRyYWZmaWMgZnJvbSA4IHRvIDkgdGhhdCBuZWVkcyBhbiBTUkgs IHRoZSBTUkggZ29lcyBpbiB0aGUgSVB2NiBoZWFkZXIgc2VudCBteSA4IHRvIDkuICZuYnNwO1do ZW4gOSBwcm9jZXNzZXMgdGhlIHBhY2tldCwgaXQgc2VlbXMgdGhhdCBpdCBpcyB0aGUgbGFzdCBT SUQsIGZpZ3VyZXMgb3V0IHRoYXQgdGhlcmUgaXMgbm8gZW5jYXBzdWxhdGlvbiwgYW5kIHNlbmQg dGhlIFRDUCAvIFVEUCAvIFFVSUMgaW5mb3JtYXRpb24gdG8gaXRzIGludGVybmFsDQogcHJvdG9j b2xzIHN0YWNrcy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpZZXMsIHRoaXMgaXMgU2Vj dGlvbiA1LjMuMSDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCiZsdDtqbWgmZ3Q7QWdyZWVkIGFzIGZhciBhcyBpdCBnb2VzLiAmbmJzcDtI b3dldmVyLCAmbmJzcDt0aGUgZXhpc3RlbmNlIG9mIFM5IGFuZCBBOSBwb2ludHMgdG8gYSBwcm9i bGVtLiAmbmJzcDtOb2RlIDggaXMgdHJ5aW5nIHRvIHB1dCBvbiBhbiBTUkggZ29pbmcgdGhyb3Vn aCBTeCwgU3ksIHdoYXRldmVyIGZvciBzb21lIHJlYXNvbi4gJm5ic3A7SXQgY2FuJ3QgcHV0IEE5 IGludG8gdGhlIFNSSCwgYXMgQUggaXMgbm90IGEgU0lELCBpdCBpcyBhbiBhZGRyZXNzLiAmbmJz cDtJIHByZXN1bWUgbm9kZQ0KIDggZ290IFM5IGZyb20gd2hhdGV2ZXIgcHJvdmlkZWQgaGltIHRo ZSBTUiBQb2xpY3kgdGhhdCBpdCBpcyB1c2luZy4gJm5ic3A7RG9lcyBpdCBzaW1wbHkgdXNlIFM5 IGFzIHRoZSBhZGRyZXNzIGZvciBub2RlIDksIHJhdGhlciB0aGFuIEE5IHRoYXQgaXQgZ290IGZy b20gRE5TPyAmbmJzcDtBbmQgZG9lcyB0aGUgVENQIHN0YWNrIGtub3cgdGhhdCB0aGlzIHN1YnN0 aXR1dGlvbiBpcyBiZWluZyBtYWRlPyAmbmJzcDsoVGhpcyBpcyBhbm90aGVyIGV4YW1wbGUgb2Yg YSBwcm9ibGVtDQogdGhhdCBnb2VzIGF3YXkgaWYgd2UgYWx3YXlzIGVuY2Fwc3VsYXRlLikgJmx0 Oy9qbWgmZ3Q7PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KJmx0O2RkJmd0O1NlY3Rpb24g NC4zLjIgY292ZXJzIHRoZXNlIHF1ZXN0aW9ucywgaS5lLiBBOSBjYW4gYmUgcGxhY2VkIGluIHRo ZSBTUkggYXMgdGhlIGxhc3Qgc2VnbWVudCwgYW5kIHRoaXMgc2VjdGlvbiBkZXNjcmliZXMgaG93 IGl04oCZcyBoYW5kbGVkLiZsdDsvZGQmZ3Q7PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQpGb3IgdHJhZmZpYyBmcm9tIDEgdG8gOSwgd2hlcmUgMyBhZGRzIGFuIFNSSCwgdGhhdCBTUkgg c3RpbGwgcHJlc3VtYWJseSBlbmRzIGF0IDkuICZuYnNwOzkgUmVjZWl2ZXMgdGhlIElQIHBhY2tl dC4gJm5ic3A7U2VlcyB0aGF0IGl0IGlzIGFkZHJlc3NlZCB0byBpdHNlbGYuICZuYnNwO1NlZXMg dGhhdCB0aGUgU1JIIGlzIGZpbmlzaGVkLiAmbmJzcDtBbmQgdGhlbiBub3RpY2VzIHRoYXQgdGhl IG5leHQtaGVhZGVyIGlzIElQdjYuICZuYnNwO1Vud3JhcHMgdGhlIGhlYWRlciwgY2hlY2tzIHRo YXQNCiB0aGUgaW5uZXIgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhbHNvIGl0c2VsZiwgYW5kIHBh c3NlcyB0aGUgbWF0ZXJpYWwgY2FycmllZCBieSB0aGUgaW5uZXIgaGVhZGVyIHVwIHRvIHRoZSBh cHByb3ByaWF0ZSBzdGFjay48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpTbyBub2RlIDEg c2VuZHMgYSBwYWNrZXQgdG8gbm9kZSA5IChBMSxBOSk8YnIgY2xhc3M9IiI+DQpJRiB0aGVyZSBp cyBzb21lIHN0ZWVyaW5nIGludG8gYW4gU1IgUG9saWN5IGF0IG5vZGUgMyB0byByZWFjaCBub2Rl IDksIHRoaXMgaXMgaWRlbnRpY2FsIHRvIHNlY3Rpb24gNS4zLjIg4oCcVHJhbnNpdCBwYWNrZXQg dGhyb3VnaCBTUiBkb21haW7igJ0sIGV4Y2VwdCBmb3IgZGVzdGluYXRpb24gb2YgQTkgdmlhIG5v ZGUgOSAmbmJzcDtpbnN0ZWFkIG9mIEEyIHZpYSBub2RlIDQuPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpUaHVzLCA5 IG5lZWRzIHRvIGJlIGFibGUgdG8gY2hlY2sgZm9yIGJvdGggY2FzZXMuICZuYnNwO1dlIGF0IGxl YXN0IG5lZWQgdG8gdGVsbCBpbXBsZW1lbnRvcnMgdGhhdC48YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr cXVvdGU+DQpXZWxsLCA5IG5lZWRzIGEgU0lEIFM5IGFuZCBBZGRyZXNzIEE5LiAmbmJzcDtUaGF0 IGlzIHNob3duIGluIFNlY3Rpb24gNS4xIFNJRCBhbmQgYWRkcmVzcyByZXByZXNlbnRhdGlvbi48 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQombHQ7am1oJmd0O1NvLCBsZXQgdXMgYXNzdW1l IHRoYXQgMyBoYXMgYW4gU1IgcG9saWN5IGl0IHdhbnRzIHRvIGFwcGx5IHRvIHRoZSB0cmFmZmlj IGZyb20gQTEgdG8gQTkuICZuYnNwO0luIHRoaXMgY2FzZSwgdGhlIFM5IC8gQTkgZGljaG90b215 IGlzIG5vdCBhIHByb2JsZW0sIEkgdGhpbmsuICZuYnNwO05vZGUgMyBlbmNhcHN1YWx0ZXMgdGhl IHBhY2tldCBmcm9tIEExIHRvIEE5LCB1c2VzIFMzIGFzIHRoZSBzb3VyY2UgYWRkcmVzcyBvZiB0 aGUgZW5jYXBzdWxhdGluZw0KIGhlYWRlciwgYW5kIGVuZHMgdGhlIFNJRCBsaXN0IGluIHRoZSBT Ukggd2l0aCBTOS4gJm5ic3A7VGhlIHVuc3BlY2lmaWVkIHBhcnQgaXMgdGhhdCBub2RlIDkgbmVl ZHMgdG8gYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBzdWNoIHBhY2tldHMgYW5kIGRvIHRoZSBkb3Vi bGUgcHJvY2Vzc2luZy4gJm5ic3A7SXQgaXMgcmVhc29uYWJsZSBkb3VibGUgcHJvY2Vzc2luZy4g Jm5ic3A7TXkgb25seSByZXF1ZXN0IGhlcmUgaXMgdGhhdCB3ZSB0ZWxsIGZvbGtzIHRoZXkgbmVl ZCB0bw0KIHN1cHBvcnQgaXQuICZsdDsvam1oJmd0OzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCiZsdDtkZCZndDtBY3R1YWxseSwgbm9kZSAzIHVzZXMgQTMgYXMgaXRzIHNvdXJjZSBhZGRy ZXNzLCBidXQgdGhhdOKAmXMgbWlub3IuPGJyIGNsYXNzPSIiPg0KVGhlIGRvdWJsZSBwcm9jZXNz aW5nIChsb29rdXAsIGRvIGVuZCBwcm9jZXNzaW5nLCBkbyBhbm90aGVyIGxvb2t1cCkgaXMgZG9j dW1lbnRlZCBpbiBTZWN0aW9uIDQuMy48YnIgY2xhc3M9IiI+DQpJcyB0aGVyZSBhIG5lZWQgZm9y IG1vcmUgdGhhbiB3aGF0IGlzIGN1cnJlbnRseSBzcGVjaWZpZWQ/ICZsdDsvZGQmZ3Q7PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NClRoZXJlIGlzIGEgZnVydGhlciBjb21wbGljYXRpb24uICZuYnNwOzkgc2Vl bXMgdG8gbmVlZCB0byBoYXZlIGFuIGFkZHJlc3MgdGhhdCBpcyBhIHZhbGlkIFNJRCwgc28gaXQg Y2FuIGJlIHRoZSBsYXN0IGVudHJ5IGluIHRoZSBTUkggZnJvbSA4IHRvIDkuPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KQXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCwgU2VjdGlvbiA1LjEg YSBub2RlIGsgaGFzIGFuIGFkZHJlc3MgQWsgYW5kIFNJRCBTay4gJm5ic3A7U28gbm9kZSA5IGhh cyBhIHZhbGlkIFNJRC48YnIgY2xhc3M9IiI+DQpGb3IgdHJhZmZpYyBmcm9tIDggdG8gOSwgQTkg aXMgdXNlZCBhcyB0aGUgZGVzdGluYXRpb24gYXMgc2hvd24gaW4gc2VjdGlvbiA1LjMuMSwgNS40 IGFuZCA1LjUuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ Jm5ic3A7SG93ZXZlciwgaWYgMSB3ZXJlIHRvIHNlbmQgdGhlIHBhY2tldCB0byB0aGF0IFNJRCBm b3IgOSwgcm91dGVyIDMgd291bGQgYmUgcmVxdWlyZWQgYnkgdGhlIHJ1bGVzIHdlIGRpc2N1c3Nl ZCBpbiB0aGUgb3RoZXIgdGhyZWFkIHRvIGRpc2NhcmQgdGhlIHBhY2tldCBhcyBpdCBpcyBuZWl0 aGVyIHRvIHByZWZpeCBub3IgY29udGFpbnMgYW4gSEFNQy48YnIgY2xhc3M9IiI+DQombmJzcDtB bmQgc29tZWhvdywgOCBhbmQgMSBuZWVkIHRvIGVhY2ggcGljayB0aGUgcmlnaHQgYWRkcmVzcyB0 byB1c2UgZm9yIDkuIChzcGxpdCBETlMgbWF5YmU/KSAmbmJzcDtBbmQgMyBuZWVkcyB0byBiZSBh YmxlIHRvIGRlcml2ZSB0ZWggU0lELWZvcm1uIGFkZHJlc3MgZm9yIDkgZnJvbSB0aGUgbm9uLVNJ RCBmb3JtIG9mIHRoZSBhZGRyZXNzIHNvIHRoYXQgaXQgKDMpIGNhbiBidWlsZCBhIHByb3BlciBT UkggdG8gZ2V0IHRoZSBwYWNrZXQgdG8gOS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQombHQ7am1oJmd0O0kgaGF2ZSByZXRhaW5lZCB5b3VyIGFuc3dlciBiZWxv dyBmb3IgY29udGV4dCwgYnV0IEkgdGhpbmsgdGhhdCBhbnN3ZXJzIHRoZSB3cm9uZyBxdWVzdGlv bi4gJm5ic3A7SSBiZWxpZXZlIHdoYXQgaXMgaXRuZW5kZWQgaXMgdGhhdCBvbmx5IEE5IGFwcGVh cnMgaW4gRE5TLiAmbmJzcDtTbyBOb2RlIDEgd2lsbCBzZWUgOSBhcyBBOSwgYW5kIHdpbGwgdXNl IHRoYXQuICZuYnNwO1M5IHdpbGwgYXBwZWFyIGluIFNSIFBvbGljaWVzIGFib3V0IHRyYWZmaWMg dG8gbm9kZQ0KIDksIGJ1dCBub3QgaW4gRE5TLiAmbmJzcDtUaGF0IGlzIHdoYXQgd2UgbmVlZC4g Jm5ic3A7SSB3aXNoIGl0IHdlcmUgY2xlYXJlciBpbiB0aGUgdGV4dC4gJmx0Oy9qbWgmZ3Q7PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmx0O2ptaCZndDtJZiBub2RlIDIwIGlzIGdlbmVy YXRpbmcgU1JIcyB3aXRoIEhNQUNzLCB0aGVuIHRoaXMgaXMgbGFyZ2VseSB0aGUgc2FtZSBhcyB0 aGUgY2FzZSBmcm9tIDggdG8gOSwgZXhjZXB0IHRoYXQgd2hvbWV2ZXIgY3JlYXRlcyB0aGUgU1Ig UG9saWN5IHRoYXQgMjAgaXMgdXNpbmcgbmVlZHMgdG8gYWxzbyBtYWtlIHN1cmUgdGhhdCB3aGF0 ZXZlciB0aGUgZmlyc3QgU0lEIGlzIGluIHRlaCBsaXN0LCBpdCBwcm9jZXNzZXMgSE1BQ3MgYW5k IGlzIHJlY29nbml6YWJsZQ0KIHRvIG5vZGUgMyBhcyBkb2luZyBzdWNoIHByb2Nlc3NpbmcuIEkg YW0gZ3Vlc3NpbmcgdGhhdCB0aGUgcmVhc29uIGZvciBhbGxvd2luZyBpbnRlcm5hbCBub2RlcyB0 byBkbyB0aGUgcHJvY2Vzc2luZyBpcyB0byBtb3ZlIHRoZSB2ZXJpZmljYXRpb24gbG9hZCBvZmYg dGhlIGVkZ2Ugbm9kZXMuICZuYnNwO0l0IGRvZXMgY3JlYXRlIHNpZ25pZmljYW50IGFkZGl0aW9u YWwgY29uZmlndXJhdGlvbiBjb21wbGV4aXR5LiAmbHQ7L2ptaCZndDs8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQombHQ7ZGQmZ3Q7V2UgZGlkbuKAmXQgc2VlIGEgcmVhc29uIHRvIHJlc3Ry aWN0IHRoZSBITUFDIHByb2Nlc3NpbmcgdG8gb25seSBlZGdlIG5vZGVzIHdoZW4gaXQgd2FzIHN0 cmFpZ2h0IGZvcndhcmQgdG8gZGVmaW5lIGhvdyB0aGV5IGNvdWxkIGJlIHByb2Nlc3NlZCBhdCBu b24tZWRnZSBub2Rlcy4mbHQ7L2RkJmd0OzxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPlRoaXMgaXMgaW5jb3JyZWN0LjxiciBjbGFzcz0iIj4NClNlZSBTZWN0aW9uIDYuMi4x IOKAnFNSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0bHkgQ29ubmVjdGVk4oCdIEkgd2lsbCBleHBh bmQgb24gdGhlIGV4YW1wbGUgZnJvbSB0aGF0IHNlY3Rpb24uPGJyIGNsYXNzPSIiPg0KTm9kZSAy MCBzZW5kcyBhIHBhY2tldCB0byBBOSB3aXRoIFNSIFBvbGljeSAmbHQ7SDcmZ3Q7IGFuZCBhbiBI TUFDIHByb3ZpZGVkIHRvIG5vZGUgMjAgYnkgc29tZSB5ZXQgdG8gYmUgZGVmaW5lZCBtZXRob2Qu ICZuYnNwO1Jlc3VsdGluZyBpbiBwYWNrZXQgc2VudCBmcm9tIG5vZGUgMjA8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDtQOiAoQTIwLEg3KShBOTtTTD0xKShwYXlsb2FkKTxiciBjbGFzcz0iIj4N ClJlY2FsbCBIayBpcyBhIFNJRCBhdCBub2RlIGsgcmVxdWlyaW5nIEhNQUMgdmVyaWZpY2F0aW9u LCBhbmQgaXQgaXMgY292ZXJlZCBieSBQcmVmaXgtSC48YnIgY2xhc3M9IiI+DQpQcmVmaXgtSCBp cyBfbm90XyBzdWJqZWN0IHRvIGluZ3Jlc3MgZmlsdGVyaW5nIGF0IG5vZGUgMy48YnIgY2xhc3M9 IiI+DQpUaGVyZWZvcmUgdGhlIHBhY2tldCBQIGRlc3RpbmVkIHRvIEg3IGlzIG5vdCBzdWJqZWN0 IHRvIGluZ3Jlc3MgZmlsdGVyaW5nIGF0IG5vZGUgMy48YnIgY2xhc3M9IiI+DQpQIGlzIGZvcndh cmRlZCB0byBub2RlIDcsIHdoZXJlIEg3IGlzIHByb2Nlc3NlZCBhbmQgdGhlIEhNQUMgdmVyaWZp ZWQuPGJyIGNsYXNzPSIiPg0KSWYgdGhlIEhNQUMgY2FuIG5vdCBiZSB2ZXJpZmllZCB0aGUgcGFj a2V0IGlzIGRyb3BwZWQsIGVsc2UgaXQgaXMgZm9yd2FyZGVkIHRvIHRoZSBuZXh0IHNlZ21lbnQg YW5kIGRlc3RpbmF0aW9uLCBBOS48YnIgY2xhc3M9IiI+DQpEYXJyZW48YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpZb3Vycyw8YnIg Y2xhc3M9IiI+DQpKb2VsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gMTAvMjIvMTgg ODowNCBQTSwgRGFycmVuIER1a2VzIChkZHVrZXMpIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmlubGluZS48YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBPY3QgMjIsIDIwMTgsIGF0IDc6MjEgUE0sIEpv ZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIGNs YXNzPSIiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQouLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ MikgTm93IGxldCB1cyBsb29rIGF0IHBhY2tldHMgYXJyaXZpbmcgYXQgYW5kIGFjdHVhbGx5IGRl c3RpbmVkIGZvciBhbiBTUiBIb3N0IGluIHRoZSBTUiBEb21haW4gd2hlcmUgdGhhdCBwYWNrZXQg aGFzIGFuIFNSSC4gJm5ic3A7SWYgdGhlIHBhY2tldCBpcyBjb21pbmcgZnJvbSBhbm90aGVyIFNS IEhvc3QsIHRoZSBTUkggd2lsbCBiZSBpbiB0aGUgYmFzZSBoZWFkZXIsIGFuZCB0aGUgaG9zdCBj YW4NCiBzaW1wbHkgY2hlY2sgaXQgZm9yIGFueSB2aW9sYXRpb25zLCBhbmQgY29udGludWUuICZu YnNwO0J1dCwgaWYgdGhlIHBhY2tldCBjYW1lIGZyb20gb3V0c2lkZSB0aGUgZG9tYWluLCB0aGVu IGl0IHdpbGwgaGF2ZSBhbiBlbmNhcHN1bGF0aW5nIFNSdjYgaGVhZGVyLiAmbmJzcDtTbyB0aGUg aG9zdCBoYXMgdG8gZGV0ZWN0IHRoaXMgY2FzZSwgY2hlY2sgYW5kIHRoZW4gcGVhbCBvZmYgdGhl IGVuY2Fwc3VsYXRpbmcgaGVhZGVyLCBhbmQgdGhlbiBwcm9jZXNzIHRoZQ0KIHJlY2VpdmVkIHBh Y2tldC4gWWVzLCBpdCBjYW4gZG8gc28uICZuYnNwO0J1dCBub3RoaW5nIGluIHRlaCBkb2N1bWVu dCB0ZWxscyBpbXBsZW1lbnRvcnMgdGhleSBoYXZlIHRvIGRlYWwgd2l0aCBib3RoIGNhc2VzLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCkNhbiB5b3UgYmUgbW9y ZSBwcmVjaXNlIGhlcmUuICZuYnNwO1BlcmhhcHMgdXNlIHRoZSBleGFtcGxlIGZyb20gc2VjdGlv biA1LjIgb3IgNi4yLjE/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KLi48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_679B2EEF4EE644BCA9D717E70FF1133Aciscocom_-- From nobody Fri Nov 2 11:40:17 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08D126BED; Fri, 2 Nov 2018 11:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Kcq7BhJOPvWI; Fri, 2 Nov 2018 11:40:11 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE61124C04; Fri, 2 Nov 2018 11:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18976; q=dns/txt; s=iport; t=1541184011; x=1542393611; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jk4L1RMC2/9rNGDA5utnvbz+46FLXh21852nHHsI82k=; b=A7FKz2oqaBWBQCX7AHNmCiNODS3PiHe9P6tt6PGTHrOtYC5Q3w51taEf BA7xAXKaLRn+63Ii8Shtw4YhFJmm9GSrSuinXpiRJF6rAqsZlm/Zg/Ukb MYyl7+N1FJGjRkxgvJW3qcSOW8nrC4hOtfWe60h3+cefiNvCCW2sSA/9A o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAMmdxb/4QNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBggRmfygKg2yUL4INlyyBegsBARgLhEk?= =?us-ascii?q?CF4MnIjYLDQEDAQECAQECbRwMhToBAQEBAgEBASERMwcLBQcEAgEIEQQBAQE?= =?us-ascii?q?CAiMDAgICJQsUAQgIAgQOBYMhAYF5CA+nS4EuihwFgQuKZheBQT+BEScfgky?= =?us-ascii?q?DGwEBgWEHMQKCSjGCJgKIZCEDgWuTY1QJAoduiRwYgVWEfYoJgm6UKQIRFIE?= =?us-ascii?q?mJAMugVVwFTsqAYJBgiYFEohchT5vAYp3B4EngR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,456,1534809600"; d="scan'208";a="195658101" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2018 18:40:09 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id wA2Ie9Et026773 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Nov 2018 18:40:09 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 2 Nov 2018 13:40:08 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Fri, 2 Nov 2018 13:40:08 -0500 From: "Darren Dukes (ddukes)" To: "Chengli (IP Technology Research)" CC: Joel Halpern , "spring@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Lizhenbin , Mach Chen Subject: Re: SRv6 - SRH in encaps or base header - point 2 Thread-Topic: SRv6 - SRH in encaps or base header - point 2 Thread-Index: AQHUampMSmaiE2sUnkOZwbcZBqOzaaUyIfaAgAAQcoCABlqwgIAAiTcAgAQfoYA= Date: Fri, 2 Nov 2018 18:40:08 +0000 Message-ID: References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.76.77] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 18:40:16 -0000 SGVsbG8gQ2hlbmcsIHRoYW5rcyBmb3IgdGhlIHJldmlldyEgIFBsZWFzZSBzZWUgaW5saW5lDQoN Cj4gT24gT2N0IDMwLCAyMDE4LCBhdCAxMTo0MSBQTSwgQ2hlbmdsaSAoSVAgVGVjaG5vbG9neSBS ZXNlYXJjaCkgPGNoZW5nbGkxM0BodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIERhcnJlbiwN Cj4gDQo+IEkgdGhpbmsgdGhlIHRleHQgb2YgZW5jYXBzdWxhdGluZyBtb2RlIGlzIGNsZWFyIGZv ciBtZS4gQnV0IEkgc3RpbGwgaGF2ZSBzb21lIHF1ZXN0aW9ucyBvZiB0aGUgaW5zZXJ0aW9uIG1v ZGUgLg0KPiANCj4gMS4xIDo8ZGQ+IE5vZGUgOSBoYXMgYSBjaG9pY2UsIGVuY2Fwc3VsYXRlIHRv IG5vZGUgMyBvciBub3QuIA0KPiBJZiBub2RlIDkgZG9lcyBub3QgZW5jYXBzdWxhdGUsIGl0IHdp bGwgaW5mb3JtIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgc2VnbWVudHMgaW4gdGhlIFNSSCBhbmQg cG9zc2libHkgbGVhayB0aGVtIHRvIGludGVybWVkaWF0ZSBub2Rlcy4NCj4gDQo+IElmIHRoZXJl IGlzIG5vdCBpbmRpY2F0b3IgdG8gbWFrZSBhIGNob2ljZSBvZiBlbmNhcHN1bGF0aW5nIG9yIG5v dCwgaG93IHRoZSBub2RlIHRvIG1ha2UgdGhlIGNob2ljZT8gTG9jYWwgcG9saWN5PyAgDQo+IE9y IG1ha2UgaXQgdGhlIHNhbWUgbGlrZSB0aGUgcmVjZWl2ZWQgcGFja2V0PyBFbmNhcHN1bGF0ZSBp ZiByZWNlaXZlZCBwYWNrZXQgZG9lcywgZWxzZSwgaW5zZXJ0Pw0KDQpBIGhvc3QgbmVlZHMgbWFu eSB0aGluZ3MgdG8gZGV0ZXJtaW5lIGhvdyB0byBhZGQgYW4gU1JIIHRvIGEgcGFja2V0IGl0IGlz IHNlbmRpbmcgdG8gYSBkZXN0aW5hdGlvbiwgYXQgbGVhc3QgaXQgbmVlZHMgdG8gbGVhcm4gU0lE cyBmb3Igbm9kZXMgYW5kIGhhdmUgc29tZSBsb2dpYyBpbiBwbGFjZSB0byBkZXRlcm1pbmUgaG93 IGFuZCB3aGVuIHRvIHVzZSBhIHBhcnRpY3VsYXIgc2VnbWVudCBsaXN04oCmIFRoYXQgaXMgd2Vs bCBiZXlvbmQgdGhpcyBkb2N1bWVudCBhbmQgdGhlcmUgaXMgYW5kIHdpbGwgYmUgbW9yZSBpbm5v dmF0aXZlIHdheXMgb2YgZGV0ZXJtaW5pbmcgd2hlbiB0byBhZGQgYSBTUkggdG8gYSBwYWNrZXQg c291cmNlZCBieSBhIG5vZGUuDQoNClRoZXJlZm9yZSBJ4oCZbGwgc2F5IHRoaXMgcXVlc3Rpb24g aXMgbm90IHdpdGhpbiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudCwgaXQgbmVlZHMgdG8gYmUgYW5z d2VyZWQgZm9yIHNwZWNpZmljIHVzZSBjYXNlcyBhbmQgYXBwbGljYXRpb25zIG9mIHRoZSBTUkgu DQoNClRoYXQgc2FpZCB0aGVyZSBpcyBvbmdvaW5nIHdvcmsgdG8gZGVmaW5lIGhvdyBhIG5vZGUg bWF5IGxlYXJuIGFuIFNSIFBvbGljeToNClBDRVAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtbmVnaS1wY2Utc2VnbWVudC1yb3V0aW5nLWlwdjYtMDMudHh0LCANCkJHUC1URSBodHRwczov L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5 LTA0LnR4dCwNCm9yIOKAnFNETuKAnSBtZXRob2RzIHdoZXJlIHNvbWUgb3V0c2lkZSBjb250cm9s bGVyIHNldHMgdXAgYSBzZWdtZW50IGxpc3QgdmlhIHNvbWUgUkVTVCwgQ0xJLCBuZXRjb25mL3lh bmcgaW50ZXJmYWNlIHRvIHNhdGlzZnkgc3BlY2lmaWMgdXNlIGNhc2VzLg0KDQpBbmQgd2hlbiB0 byB1c2UgaXQ6DQpCR1AgU1J2NiBzZXJ2aWNlcyBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFm dC1kYXdyYS1pZHItc3J2Ni12cG4tMDUudHh0DQoNCg0KPiANCj4gMS4yIDogSG93IHRvIGluZm9y bSB0aGUgZGVzdGluYXRpb24gb2YgdGhlIHNlZ21lbnRzIGluIHRoZSBTUkg/ICBBbnkgaW5kaWNh dG9yIGluIFNSSD8gT3IgdGhyb3VnaCBzaWduYWxpbmc/IA0KPiANCg0KDQpTYW1lIGFuc3dlciBh cyAxLjEuICANCg0KPiAyOiBDYW4gYSBub3JtYWwobm9uLVNJRCkgSVB2NiBhZGRyZXNzIGJlIGFk ZGVkIGludG8gU0lEIGxpc3Q/DQo+IA0KPiBJIHByZWZlciB5ZXMuDQo+IA0KPiBBcyBzZWN0aW9u IDQuMyBzYXlzLCBpdCBzZWVtcyBsaWtlIHdlIGNhbiBkbyB0aGF0Lg0KPiANCj4gICAiV2hlbiBh biBTUnY2LWNhcGFibGUgbm9kZSByZWNlaXZlcyBhbiBJUHY2IHBhY2tldCwgaXQgcGVyZm9ybXMg YQ0KPiAgIGxvbmdlc3QtcHJlZml4LW1hdGNoIGxvb2t1cCBvbiB0aGUgcGFja2V0cyBkZXN0aW5h dGlvbiBhZGRyZXNzLiAgVGhpcw0KPiAgIGxvb2t1cCBjYW4gcmV0dXJuIGFueSBvZiB0aGUgZm9s bG93aW5nOg0KPiANCj4gICAgICAgQSBGSUIgZW50cnkgdGhhdCByZXByZXNlbnRzIGEgbG9jYWxs eSBpbnN0YW50aWF0ZWQgU1J2NiBTSUQNCj4gICAgICAgQSBGSUIgZW50cnkgdGhhdCByZXByZXNl bnRzIGEgbG9jYWwgaW50ZXJmYWNlLCBub3QgbG9jYWxseQ0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBpbnN0YW50aWF0ZWQgYXMgYW4gU1J2NiBTSUQNCj4gICAgICAgQSBG SUIgZW50cnkgdGhhdCByZXByZXNlbnRzIGEgbm9uLWxvY2FsIHJvdXRlDQo+ICAgICAgIE5vIE1h dGNoDQo+ICAgICAgIg0KPiBBbHNvLCBpbiBzZWN0aW9uIDUsIHdlIGNhbiBzZWUgQTkgY2FuIGJl IGFkZGVkIGluIFNJRCBsaXN0IG9mIGEgU1IgcG9saWN5Lg0KPiANCj4gU28gZm9yIHRoZSBwYWNr ZXQgZnJvbSBBOSB0byBBMSwgdGhlIGFkZHJlc3Mgb2YgQTEgY2FuIGJlIGFkZGVkIGFzIHRoZSBs YXN0IGVudHJ5IG9mIFNJRCBsaXN0LCByaWdodD8gDQo+IA0KPiBJZiB5ZXMsIGFkZHJlc3Mgb2Yg QTEgaXMgbm90IGFuIGluc3RhbnRpYXRlZCBTSUQsIHNvIG5vdCBQU1AgZmxhdm9yIGNhbiBiZSBl bmFibGVkLiBTbyB0aGUgcGFja2V0IHdpbGwgYmUgc2VudCBvdXQgYnkgY2FycnlpbmcgdGhlIFNS SCBhZnRlciBBMSBpcyB1cGRhdGVkIHRvIHRoZSBJUHY2IERBLiANCj4gU1JIIHdpbGwgYmUgbGVh a2VkIHRvIG91dHNpZGUgb2YgdGhlIFNSIGRvbWFpbiwgd2hpY2ggd2lsbCBicmluZyBuZXcgc2Vj dXJpdHkgaXNzdWVzLiANCj4gDQoNClllcyBhcyB0aGUgbGFzdCBzZWdtZW50IGluIGEgc2VnbWVu dCBsaXN0LCBhbmQgYXMgUkZDODIwMCBzZWN0aW9uIDQuNCBkZXNjcmliZXMgUm91dGluZyBIZWFk ZXIgcHJvY2Vzc2luZyB3aGVuIHNlZ21lbnRzIGxlZnQgaXMgMC4NCg0KSXQgaXMgdXAgdG8gdGhl IHNwZWNpZmljIHVzZSBjYXNlIHRvIGRldGVybWluZSBpZiBpbmZvcm1pbmcgdGhlIGRlc3RpbmF0 aW9uIG9yIGludGVybWVkaWF0ZSBub2RlcyBvZiB0aGUgc2VnbWVudCBsaXN0IHVzZWQgdG8gcmVh Y2ggaXQgaXMgYSBzZWN1cml0eSByaXNrLiANCg0KQ2VydGFpbmx5IG9uIHRoZSBsYXJnZXIgaW50 ZXJuZXQgdGhpcyBpcyBhbiBpc3N1ZSB0aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQsIGJ1dCB3 aXRoaW4gYW4gZW50ZXJwcmlzZSBuZXR3b3JrIG9yIHdpdGhpbiBhIHNpbmdsZSBwcm92aWRlcnMg bmV0d29yayBjcm9zc2luZyBtdWx0aXBsZSBkb21haW5zLCBvciBldmVuIGJldHdlZW4gcHJvdmlk ZXJzIHRoZSBkaXNjbG9zdXJlIG1heSBiZSBhY2NlcHRhYmxlIG9yIGRlc2lyZWQuDQoNCj4gDQo+ IDM6IEZvciBzZWN0aW9uIDYuMiwNCj4gICBOb2RlcyBvdXRzaWRlIHRoZSBTUiBEb21haW4gY2Fu bm90IGJlIHRydXN0ZWQuICBTUiBEb21haW4gSW5ncmVzcw0KPiAgIHJvdXRlcnMgU0hPVUxEIGRp c2NhcmQgcGFja2V0cyBkZXN0aW5lZCB0byBTSURzIHdpdGhpbiB0aGUgU1IgRG9tYWluDQo+ICAg KHJlZ2FyZGxlc3Mgb2YgdGhlIHByZXNlbmNlIG9mIGFuIFNSSCkgdG8gYXZvaWQgYXR0YWNrcyBv biB0aGUgU1INCj4gICBEb21haW4gYXMgZGVzY3JpYmVkIGFuZCByZWZlcmVuY2VkIGluIFtSRkM1 MDk1XS4gDQo+IA0KPiAgIEFzIGFuIGFkZGl0aW9uYWwNCj4gICBsYXllciBvZiBwcm90ZWN0aW9u LCBTUiBTZWdtZW50IEVuZHBvaW50IG5vZGVzIFNIT1VMRCBkaXNjYXJkIHBhY2tldHMNCj4gICBk ZXN0aW5lZCB0byBsb2NhbCBTSURzIGZyb20gc291cmNlIGFkZHJlc3NlcyBub3QgcGFydCBvZiB0 aGUgU1INCj4gICBEb21haW4uDQo+IA0KPiBGb3IgYSBwYWNrZXQgZnJvbSBBMSB0byBBOSwgIHRo ZSBwYWNrZXQgaXMgKEExLCBBOSkuIE5vZGUzIHdpbGwgbm90IGRyb3AgdGhlIHBhY2tldCBzaW5j ZSB0aGUgZGVzdGluYXRpb24gaXMgQTkgbm90IFM5Lg0KPiANCj4gSWYgbm9kZSAzIGluc2VydCBh IFNSSCBpbiB0aGUgb3JpZ2luYWwgSVB2NiBwYWNrZXQsIHRoZW4gdGhlIHNvdXJjZSBBZGRyZXNz IHdpbGwgYmUgQTEuIEFuZCB0aGUgU0lEIGxpc3QgY2FuIGJlICA8QTksIFM2ID4uDQo+IEluIHRo aXMgY2FzZSwgdGhlIHBhY2tldCB3aWxsIGJlIGRyb3BwZWQgYnkgbm9kZSA2LCBzaW5jZSB0aGUg c291cmNlIGFkZHJlc3MgaXMgbm90IHBhcnQgb2YgdGhlIFNSIGRvbWFpbi4gIFtTZWN0aW9uIDYu Ml0sIHJpZ2h0Pw0KPiANCj4gSU1ITywgdGhlcmUgYXJlIHNvbWUgcHJvYmxlbXMgYWJvdXQgaW5z ZXJ0aW9uIG1vZGUuDQoNCkluIHRoZSBjb250ZXh0IG9mIHRoZSBTUkggZHJhZnQgd2UgZG8gbm90 IG1ha2UgYW55IG1lbnRpb24gb3IgdXNlIG9mIFNSSCBpbnNlcnRpb24uIEkuZS4gbm9kZSAzIGRv ZXMgbm90IGluc2VydCBhbiBTUkgsIGl0IGVuY2Fwc3VsYXRlcyBpbiBhbiBvdXRlciBJUHY2IGhl YWRlci4NCg0KRGFycmVuDQoNCj4gDQo+IFRoYW5rcywNCj4gQ2hlbmcNCj4gDQo+IA0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhcnJlbiBEdWtlcyAoZGR1a2VzKQ0KPiBTZW50 OiBXZWRuZXNkYXksIE9jdG9iZXIgMzEsIDIwMTggMzozMSBBTQ0KPiBUbzogSm9lbCBIYWxwZXJu IDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPiBDYzogc3ByaW5nQGlldGYub3JnOyA2bWFuQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBTUnY2IC0gU1JIIGluIGVuY2FwcyBvciBiYXNlIGhlYWRlciAt IHBvaW50IDINCj4gDQo+IEkgdGhpbmsgd2XigJlyZSBhbG1vc3QgY29uY2x1ZGVkIHNvIG9uY2Ug bW9yZSBpbmxpbmUgYXQgPGRkPjwvZGQ+DQo+IA0KPj4gT24gT2N0IDI2LCAyMDE4LCBhdCAyOjI4 IFBNLCBKb2VsIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4gDQo+PiAo cmVzZW5kaW5nLCArc3ByaW5nIGFzIHJlcXVlc3RlZCkNCj4+IA0KPj4gVGhhbmsgeW91IGZvciB0 aGUgcmVzcG9uc2VzLiAgSSB3aWxsIHJlc3BvbmQgaW4gbGluZSwgbWFya2VkIDxqbWg+PC9qbWg+ LiAgSSBmZWFyIGl0IHdpbGwgc2hvcnRseSBnZXQgdG9vIGRlZXAsIGJ1dCB0aGUgY29udGV4dCBp cyBpbXBvcnRhbnQuDQo+PiANCj4+IEkgd2lsbCByZXBocmFzZSBoZXJlIGFuIGlzc3VlIGZyb20g YW5vdGhlciB0aHJlYWQgdGhhdCBJIGFodmUgbm90IHNlZW4geW91ciBjb21tZW50cyBvbi4gIElm IE5vZGUgOSBpcyBzZW5kaW5nIHRyYWZmaWMgdG8gTm9kZSAxIChmb3IgZXhhbXBsZSwgdGhlIHJl dmVyc2UgdHJhZmZpYyBmb3IgdGhlIHRyYWZmaWMgZnJvbSAxIHRvIDkgaW4gdGhlIGV4YW1wbGVz IGJlbG93KSwgaXQgcHJlc3VtYWJseSBoYXMgYW4gU1IgUG9saWN5IHRvIGJlIGFwcGxpZWQuIFRo ZSBpc3N1ZSBJIHJhaXNlZCBiZWZvcmUgaXMgdGhlIGxlYWthZ2UgaXNzdWUuICBJZiA5IHB1dHMg dGhlIFNSSCBpbiBpdHMgcGFja2V0IChhcyB0aGUgZG9jdW1lbnQgY3VycmVudGx5IG1hbmRhdGVz KSwgdGhlbiBpdCB3aWxsIG5vdCBiZSBwb3NzaWJsZSBmb3IgMyB0byByZW1vdmUgdGhlIFNSSC4g IFRodXMsIHRoZSBTUkggd2lsbCBsZWFrLg0KPj4gDQo+PiBTb21lIGhhdmUgYXJndWVkIHRoYXQg aXMgbm90IGEgYmlnIGRlYWwuICBJdCBzZWVtcyB0byBtYXR0ZXIgdG8gbWUuICBCdXQgdGhlcmUg aXMgYW4gYWRkaXRpb25hbCBwcm9ibGVtLiAgQTEgaXMgbm90IGEgU0lELiAgVGhlcmVmb3JlLCA5 IGNhbiBub3QgcHV0IEExIGludG8gdGhlIFNSSC4gIElmIGl0IGNhbiBub3QgcHV0IEExIGludG8g dGhlIFNSSCwgYW5kIGl0IGRvZXMgbm90IGVuY2Fwc3VsYXRlIHRoZSBwYWNrZXQsIHdoZXJlIGRv ZXMgaXQgcHV0IEExLg0KPiANCj4gPGRkPiBOb2RlIDkgaGFzIGEgY2hvaWNlLCBlbmNhcHN1bGF0 ZSB0byBub2RlIDMgb3Igbm90LiANCj4gSWYgbm9kZSA5IGRvZXMgbm90IGVuY2Fwc3VsYXRlLCBp dCB3aWxsIGluZm9ybSB0aGUgZGVzdGluYXRpb24gb2YgdGhlIHNlZ21lbnRzIGluIHRoZSBTUkgg YW5kIHBvc3NpYmx5IGxlYWsgdGhlbSB0byBpbnRlcm1lZGlhdGUgbm9kZXMuDQo+IElmIG5vZGUg OSBkb2VzIGVuY2Fwc3VsYXRlLCBub2RlIDMgcmVtb3ZlcyB0aGUgb3V0ZXIgaGVhZGVyIGFuZCBu b2RlIDEgd291bGQgbm90IGxlYXJuIHRoZSBzZWdtZW50IGxpc3QuDQo+IEkgdGhpbmsgaXRzIGNo b2ljZSBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGluIHRoZSBkcmFmdC4gPC9kZD4NCj4gDQo+PiAN Cj4+IFlvdXJzLA0KPj4gSm9lbA0KPj4gDQo+PiBPbiAxMC8yNi8xOCAxOjI5IFBNLCBEYXJyZW4g RHVrZXMgKGRkdWtlcykgd3JvdGU6DQo+Pj4gSGkgSm9lbCwgeW914oCZdmUgZGVzY3JpYmVkIHNl Y3Rpb25zIHRpdGxlZCDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLCDigJxUcmFuc2l0IFBh Y2tldCBUaHJvdWdoIFNSIERvbWFpbuKAnSwgYW5kICJTUiBTb3VyY2UgTm9kZXMgTm90IERpcmVj dGx5IENvbm5lY3RlZOKAnS4NCj4+PiBJ4oCZdmUgcGFyc2VkIHRoZW0gaW5saW5lIHRvIHRoZSBz ZWN0aW9ucyBvZiB0aGUgZHJhZnQgZGVmaW5pbmcgdGhlbSBhbmQgZ2l2ZW4gbW9yZSBjb250ZXh0 IHdoZXJlIG5lZWRlZC4NCj4+Pj4gT24gT2N0IDIyLCAyMDE4LCBhdCA4OjQ5IFBNLCBKb2VsIE0u IEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gUmVwaHJh c2luZyB1c2luZyB0aGUgZXhhbXBsZSBmcm9tIDUuMi4gIEFzc3VtaW5nIHRoYXQgOCBhbmQgOSBh cmUgU1IgDQo+Pj4+IEhvc3RzIChub3QganVzdCBob3N0cyB3aXRoaW4gdGhlIGRvbWFpbiwgdGhl eSBhcmUgY2FwYWJsZSBvZiBhbmQgDQo+Pj4+IGV4cGVjdCB0byBkZWFsIHdpdGggU1JIcywgYW5k IHRoZXJlZm9yZSBoYXZlIGxvY2FsIFNJRHMsIC4uLikNCj4+Pj4gDQo+Pj4+IEZvciB0cmFmZmlj IGZyb20gOCB0byA5IHRoYXQgbmVlZHMgYW4gU1JILCB0aGUgU1JIIGdvZXMgaW4gdGhlIElQdjYg aGVhZGVyIHNlbnQgbXkgOCB0byA5LiAgV2hlbiA5IHByb2Nlc3NlcyB0aGUgcGFja2V0LCBpdCBz ZWVtcyB0aGF0IGl0IGlzIHRoZSBsYXN0IFNJRCwgZmlndXJlcyBvdXQgdGhhdCB0aGVyZSBpcyBu byBlbmNhcHN1bGF0aW9uLCBhbmQgc2VuZCB0aGUgVENQIC8gVURQIC8gUVVJQyBpbmZvcm1hdGlv biB0byBpdHMgaW50ZXJuYWwgcHJvdG9jb2xzIHN0YWNrcy4NCj4+PiBZZXMsIHRoaXMgaXMgU2Vj dGlvbiA1LjMuMSDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLg0KPj4gPGptaD5BZ3JlZWQg YXMgZmFyIGFzIGl0IGdvZXMuICBIb3dldmVyLCAgdGhlIGV4aXN0ZW5jZSBvZiBTOSBhbmQgQTkg DQo+PiBwb2ludHMgdG8gYSBwcm9ibGVtLiAgTm9kZSA4IGlzIHRyeWluZyB0byBwdXQgb24gYW4g U1JIIGdvaW5nIHRocm91Z2ggDQo+PiBTeCwgU3ksIHdoYXRldmVyIGZvciBzb21lIHJlYXNvbi4g IEl0IGNhbid0IHB1dCBBOSBpbnRvIHRoZSBTUkgsIGFzIEFIIA0KPj4gaXMgbm90IGEgU0lELCBp dCBpcyBhbiBhZGRyZXNzLiAgSSBwcmVzdW1lIG5vZGUgOCBnb3QgUzkgZnJvbSB3aGF0ZXZlciAN Cj4+IHByb3ZpZGVkIGhpbSB0aGUgU1IgUG9saWN5IHRoYXQgaXQgaXMgdXNpbmcuICBEb2VzIGl0 IHNpbXBseSB1c2UgUzkgYXMgDQo+PiB0aGUgYWRkcmVzcyBmb3Igbm9kZSA5LCByYXRoZXIgdGhh biBBOSB0aGF0IGl0IGdvdCBmcm9tIEROUz8gIEFuZCBkb2VzIA0KPj4gdGhlIFRDUCBzdGFjayBr bm93IHRoYXQgdGhpcyBzdWJzdGl0dXRpb24gaXMgYmVpbmcgbWFkZT8gIChUaGlzIGlzIA0KPj4g YW5vdGhlciBleGFtcGxlIG9mIGEgcHJvYmxlbSB0aGF0IGdvZXMgYXdheSBpZiB3ZSBhbHdheXMg ZW5jYXBzdWxhdGUuKSANCj4+IDwvam1oPg0KPiANCj4gPGRkPlNlY3Rpb24gNC4zLjIgY292ZXJz IHRoZXNlIHF1ZXN0aW9ucywgaS5lLiBBOSBjYW4gYmUgcGxhY2VkIGluIHRoZSBTUkggYXMgdGhl IGxhc3Qgc2VnbWVudCwgYW5kIHRoaXMgc2VjdGlvbiBkZXNjcmliZXMgaG93IGl04oCZcyBoYW5k bGVkLjwvZGQ+IA0KPiANCj4+IA0KPj4+PiANCj4+Pj4gRm9yIHRyYWZmaWMgZnJvbSAxIHRvIDks IHdoZXJlIDMgYWRkcyBhbiBTUkgsIHRoYXQgU1JIIHN0aWxsIHByZXN1bWFibHkgZW5kcyBhdCA5 LiAgOSBSZWNlaXZlcyB0aGUgSVAgcGFja2V0LiAgU2VlcyB0aGF0IGl0IGlzIGFkZHJlc3NlZCB0 byBpdHNlbGYuICBTZWVzIHRoYXQgdGhlIFNSSCBpcyBmaW5pc2hlZC4gIEFuZCB0aGVuIG5vdGlj ZXMgdGhhdCB0aGUgbmV4dC1oZWFkZXIgaXMgSVB2Ni4gIFVud3JhcHMgdGhlIGhlYWRlciwgY2hl Y2tzIHRoYXQgdGhlIGlubmVyIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYWxzbyBpdHNlbGYsIGFu ZCBwYXNzZXMgdGhlIG1hdGVyaWFsIGNhcnJpZWQgYnkgdGhlIGlubmVyIGhlYWRlciB1cCB0byB0 aGUgYXBwcm9wcmlhdGUgc3RhY2suDQo+Pj4gU28gbm9kZSAxIHNlbmRzIGEgcGFja2V0IHRvIG5v ZGUgOSAoQTEsQTkpIElGIHRoZXJlIGlzIHNvbWUgc3RlZXJpbmcgDQo+Pj4gaW50byBhbiBTUiBQ b2xpY3kgYXQgbm9kZSAzIHRvIHJlYWNoIG5vZGUgOSwgdGhpcyBpcyBpZGVudGljYWwgdG8gc2Vj dGlvbiA1LjMuMiDigJxUcmFuc2l0IHBhY2tldCB0aHJvdWdoIFNSIGRvbWFpbuKAnSwgZXhjZXB0 IGZvciBkZXN0aW5hdGlvbiBvZiBBOSB2aWEgbm9kZSA5ICBpbnN0ZWFkIG9mIEEyIHZpYSBub2Rl IDQuDQo+PiANCj4+Pj4gDQo+Pj4+IFRodXMsIDkgbmVlZHMgdG8gYmUgYWJsZSB0byBjaGVjayBm b3IgYm90aCBjYXNlcy4gIFdlIGF0IGxlYXN0IG5lZWQgdG8gdGVsbCBpbXBsZW1lbnRvcnMgdGhh dC4NCj4+PiBXZWxsLCA5IG5lZWRzIGEgU0lEIFM5IGFuZCBBZGRyZXNzIEE5LiAgVGhhdCBpcyBz aG93biBpbiBTZWN0aW9uIDUuMSBTSUQgYW5kIGFkZHJlc3MgcmVwcmVzZW50YXRpb24uDQo+PiA8 am1oPlNvLCBsZXQgdXMgYXNzdW1lIHRoYXQgMyBoYXMgYW4gU1IgcG9saWN5IGl0IHdhbnRzIHRv IGFwcGx5IHRvIA0KPj4gdGhlIHRyYWZmaWMgZnJvbSBBMSB0byBBOS4gIEluIHRoaXMgY2FzZSwg dGhlIFM5IC8gQTkgZGljaG90b215IGlzIG5vdCANCj4+IGEgcHJvYmxlbSwgSSB0aGluay4gIE5v ZGUgMyBlbmNhcHN1YWx0ZXMgdGhlIHBhY2tldCBmcm9tIEExIHRvIEE5LCANCj4+IHVzZXMgUzMg YXMgdGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBlbmNhcHN1bGF0aW5nIGhlYWRlciwgYW5kIGVu ZHMgDQo+PiB0aGUgU0lEIGxpc3QgaW4gdGhlIFNSSCB3aXRoIFM5LiAgVGhlIHVuc3BlY2lmaWVk IHBhcnQgaXMgdGhhdCBub2RlIDkgDQo+PiBuZWVkcyB0byBiZSBwcmVwYXJlZCB0byByZWNlaXZl IHN1Y2ggcGFja2V0cyBhbmQgZG8gdGhlIGRvdWJsZSANCj4+IHByb2Nlc3NpbmcuICBJdCBpcyBy ZWFzb25hYmxlIGRvdWJsZSBwcm9jZXNzaW5nLiAgTXkgb25seSByZXF1ZXN0IGhlcmUgDQo+PiBp cyB0aGF0IHdlIHRlbGwgZm9sa3MgdGhleSBuZWVkIHRvIHN1cHBvcnQgaXQuIDwvam1oPg0KPiAN Cj4gPGRkPkFjdHVhbGx5LCBub2RlIDMgdXNlcyBBMyBhcyBpdHMgc291cmNlIGFkZHJlc3MsIGJ1 dCB0aGF04oCZcyBtaW5vci4NCj4gVGhlIGRvdWJsZSBwcm9jZXNzaW5nIChsb29rdXAsIGRvIGVu ZCBwcm9jZXNzaW5nLCBkbyBhbm90aGVyIGxvb2t1cCkgaXMgZG9jdW1lbnRlZCBpbiBTZWN0aW9u IDQuMy4NCj4gSXMgdGhlcmUgYSBuZWVkIGZvciBtb3JlIHRoYW4gd2hhdCBpcyBjdXJyZW50bHkg c3BlY2lmaWVkPyA8L2RkPg0KPiANCj4+Pj4gDQo+Pj4+IFRoZXJlIGlzIGEgZnVydGhlciBjb21w bGljYXRpb24uICA5IHNlZW1zIHRvIG5lZWQgdG8gaGF2ZSBhbiBhZGRyZXNzIHRoYXQgaXMgYSB2 YWxpZCBTSUQsIHNvIGl0IGNhbiBiZSB0aGUgbGFzdCBlbnRyeSBpbiB0aGUgU1JIIGZyb20gOCB0 byA5Lg0KPj4+IEFzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQsIFNlY3Rpb24gNS4xIGEgbm9kZSBr IGhhcyBhbiBhZGRyZXNzIEFrIGFuZCBTSUQgU2suICBTbyBub2RlIDkgaGFzIGEgdmFsaWQgU0lE Lg0KPj4+IEZvciB0cmFmZmljIGZyb20gOCB0byA5LCBBOSBpcyB1c2VkIGFzIHRoZSBkZXN0aW5h dGlvbiBhcyBzaG93biBpbiBzZWN0aW9uIDUuMy4xLCA1LjQgYW5kIDUuNS4NCj4+Pj4gSG93ZXZl ciwgaWYgMSB3ZXJlIHRvIHNlbmQgdGhlIHBhY2tldCB0byB0aGF0IFNJRCBmb3IgOSwgcm91dGVy IDMgd291bGQgYmUgcmVxdWlyZWQgYnkgdGhlIHJ1bGVzIHdlIGRpc2N1c3NlZCBpbiB0aGUgb3Ro ZXIgdGhyZWFkIHRvIGRpc2NhcmQgdGhlIHBhY2tldCBhcyBpdCBpcyBuZWl0aGVyIHRvIHByZWZp eCBub3IgY29udGFpbnMgYW4gSEFNQy4NCj4+Pj4gQW5kIHNvbWVob3csIDggYW5kIDEgbmVlZCB0 byBlYWNoIHBpY2sgdGhlIHJpZ2h0IGFkZHJlc3MgdG8gdXNlIGZvciA5LiAoc3BsaXQgRE5TIG1h eWJlPykgIEFuZCAzIG5lZWRzIHRvIGJlIGFibGUgdG8gZGVyaXZlIHRlaCBTSUQtZm9ybW4gYWRk cmVzcyBmb3IgOSBmcm9tIHRoZSBub24tU0lEIGZvcm0gb2YgdGhlIGFkZHJlc3Mgc28gdGhhdCBp dCAoMykgY2FuIGJ1aWxkIGEgcHJvcGVyIFNSSCB0byBnZXQgdGhlIHBhY2tldCB0byA5Lg0KPj4g PGptaD5JIGhhdmUgcmV0YWluZWQgeW91ciBhbnN3ZXIgYmVsb3cgZm9yIGNvbnRleHQsIGJ1dCBJ IHRoaW5rIHRoYXQgDQo+PiBhbnN3ZXJzIHRoZSB3cm9uZyBxdWVzdGlvbi4gIEkgYmVsaWV2ZSB3 aGF0IGlzIGl0bmVuZGVkIGlzIHRoYXQgb25seSANCj4+IEE5IGFwcGVhcnMgaW4gRE5TLiAgU28g Tm9kZSAxIHdpbGwgc2VlIDkgYXMgQTksIGFuZCB3aWxsIHVzZSB0aGF0LiAgUzkgDQo+PiB3aWxs IGFwcGVhciBpbiBTUiBQb2xpY2llcyBhYm91dCB0cmFmZmljIHRvIG5vZGUgOSwgYnV0IG5vdCBp biBETlMuICANCj4+IFRoYXQgaXMgd2hhdCB3ZSBuZWVkLiAgSSB3aXNoIGl0IHdlcmUgY2xlYXJl ciBpbiB0aGUgdGV4dC4gPC9qbWg+DQo+PiANCj4+IDxqbWg+SWYgbm9kZSAyMCBpcyBnZW5lcmF0 aW5nIFNSSHMgd2l0aCBITUFDcywgdGhlbiB0aGlzIGlzIGxhcmdlbHkgDQo+PiB0aGUgc2FtZSBh cyB0aGUgY2FzZSBmcm9tIDggdG8gOSwgZXhjZXB0IHRoYXQgd2hvbWV2ZXIgY3JlYXRlcyB0aGUg U1IgDQo+PiBQb2xpY3kgdGhhdCAyMCBpcyB1c2luZyBuZWVkcyB0byBhbHNvIG1ha2Ugc3VyZSB0 aGF0IHdoYXRldmVyIHRoZSANCj4+IGZpcnN0IFNJRCBpcyBpbiB0ZWggbGlzdCwgaXQgcHJvY2Vz c2VzIEhNQUNzIGFuZCBpcyByZWNvZ25pemFibGUgdG8gDQo+PiBub2RlIDMgYXMgZG9pbmcgc3Vj aCBwcm9jZXNzaW5nLiBJIGFtIGd1ZXNzaW5nIHRoYXQgdGhlIHJlYXNvbiBmb3IgDQo+PiBhbGxv d2luZyBpbnRlcm5hbCBub2RlcyB0byBkbyB0aGUgcHJvY2Vzc2luZyBpcyB0byBtb3ZlIHRoZSAN Cj4+IHZlcmlmaWNhdGlvbiBsb2FkIG9mZiB0aGUgZWRnZSBub2Rlcy4gIEl0IGRvZXMgY3JlYXRl IHNpZ25pZmljYW50IA0KPj4gYWRkaXRpb25hbCBjb25maWd1cmF0aW9uIGNvbXBsZXhpdHkuIDwv am1oPg0KPiANCj4gPGRkPldlIGRpZG7igJl0IHNlZSBhIHJlYXNvbiB0byByZXN0cmljdCB0aGUg SE1BQyBwcm9jZXNzaW5nIHRvIG9ubHkgZWRnZSBub2RlcyB3aGVuIGl0IHdhcyBzdHJhaWdodCBm b3J3YXJkIHRvIGRlZmluZSBob3cgdGhleSBjb3VsZCBiZSBwcm9jZXNzZWQgYXQgbm9uLWVkZ2Ug bm9kZXMuPC9kZD4NCj4gDQo+PiANCj4+PiBUaGlzIGlzIGluY29ycmVjdC4NCj4+PiBTZWUgU2Vj dGlvbiA2LjIuMSDigJxTUiBTb3VyY2UgTm9kZXMgTm90IERpcmVjdGx5IENvbm5lY3RlZOKAnSBJ IHdpbGwgZXhwYW5kIG9uIHRoZSBleGFtcGxlIGZyb20gdGhhdCBzZWN0aW9uLg0KPj4+IE5vZGUg MjAgc2VuZHMgYSBwYWNrZXQgdG8gQTkgd2l0aCBTUiBQb2xpY3kgPEg3PiBhbmQgYW4gSE1BQyBw cm92aWRlZCB0byBub2RlIDIwIGJ5IHNvbWUgeWV0IHRvIGJlIGRlZmluZWQgbWV0aG9kLiAgUmVz dWx0aW5nIGluIHBhY2tldCBzZW50IGZyb20gbm9kZSAyMA0KPj4+ICBQOiAoQTIwLEg3KShBOTtT TD0xKShwYXlsb2FkKQ0KPj4+IFJlY2FsbCBIayBpcyBhIFNJRCBhdCBub2RlIGsgcmVxdWlyaW5n IEhNQUMgdmVyaWZpY2F0aW9uLCBhbmQgaXQgaXMgY292ZXJlZCBieSBQcmVmaXgtSC4NCj4+PiBQ cmVmaXgtSCBpcyBfbm90XyBzdWJqZWN0IHRvIGluZ3Jlc3MgZmlsdGVyaW5nIGF0IG5vZGUgMy4N Cj4+PiBUaGVyZWZvcmUgdGhlIHBhY2tldCBQIGRlc3RpbmVkIHRvIEg3IGlzIG5vdCBzdWJqZWN0 IHRvIGluZ3Jlc3MgZmlsdGVyaW5nIGF0IG5vZGUgMy4NCj4+PiBQIGlzIGZvcndhcmRlZCB0byBu b2RlIDcsIHdoZXJlIEg3IGlzIHByb2Nlc3NlZCBhbmQgdGhlIEhNQUMgdmVyaWZpZWQuDQo+Pj4g SWYgdGhlIEhNQUMgY2FuIG5vdCBiZSB2ZXJpZmllZCB0aGUgcGFja2V0IGlzIGRyb3BwZWQsIGVs c2UgaXQgaXMgZm9yd2FyZGVkIHRvIHRoZSBuZXh0IHNlZ21lbnQgYW5kIGRlc3RpbmF0aW9uLCBB OS4NCj4+PiBEYXJyZW4NCj4+Pj4gDQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+IA0KPj4+ PiBPbiAxMC8yMi8xOCA4OjA0IFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykgd3JvdGU6DQo+Pj4+ PiBpbmxpbmUuDQo+Pj4+Pj4gT24gT2N0IDIyLCAyMDE4LCBhdCA3OjIxIFBNLCBKb2VsIE0uIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4+PiAuLg0KPj4+Pj4+IDIpIE5v dyBsZXQgdXMgbG9vayBhdCBwYWNrZXRzIGFycml2aW5nIGF0IGFuZCBhY3R1YWxseSBkZXN0aW5l ZCBmb3IgYW4gU1IgSG9zdCBpbiB0aGUgU1IgRG9tYWluIHdoZXJlIHRoYXQgcGFja2V0IGhhcyBh biBTUkguICBJZiB0aGUgcGFja2V0IGlzIGNvbWluZyBmcm9tIGFub3RoZXIgU1IgSG9zdCwgdGhl IFNSSCB3aWxsIGJlIGluIHRoZSBiYXNlIGhlYWRlciwgYW5kIHRoZSBob3N0IGNhbiBzaW1wbHkg Y2hlY2sgaXQgZm9yIGFueSB2aW9sYXRpb25zLCBhbmQgY29udGludWUuICBCdXQsIGlmIHRoZSBw YWNrZXQgY2FtZSBmcm9tIG91dHNpZGUgdGhlIGRvbWFpbiwgdGhlbiBpdCB3aWxsIGhhdmUgYW4g ZW5jYXBzdWxhdGluZyBTUnY2IGhlYWRlci4gIFNvIHRoZSBob3N0IGhhcyB0byBkZXRlY3QgdGhp cyBjYXNlLCBjaGVjayBhbmQgdGhlbiBwZWFsIG9mZiB0aGUgZW5jYXBzdWxhdGluZyBoZWFkZXIs IGFuZCB0aGVuIHByb2Nlc3MgdGhlIHJlY2VpdmVkIHBhY2tldC4gWWVzLCBpdCBjYW4gZG8gc28u ICBCdXQgbm90aGluZyBpbiB0ZWggZG9jdW1lbnQgdGVsbHMgaW1wbGVtZW50b3JzIHRoZXkgaGF2 ZSB0byBkZWFsIHdpdGggYm90aCBjYXNlcy4NCj4+Pj4+PiANCj4+Pj4+IENhbiB5b3UgYmUgbW9y ZSBwcmVjaXNlIGhlcmUuICBQZXJoYXBzIHVzZSB0aGUgZXhhbXBsZSBmcm9tIHNlY3Rpb24gNS4y IG9yIDYuMi4xPw0KPj4+PiAuLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUg UmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQo= From nobody Fri Nov 2 12:12:58 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618421277BB for ; Fri, 2 Nov 2018 12:12:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 YYmFDjfBrh-E for ; Fri, 2 Nov 2018 12:12:53 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 2D565124C04 for ; Fri, 2 Nov 2018 12:12:53 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id i62-v6so1459001pfi.0 for ; Fri, 02 Nov 2018 12:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=8b84RKPTw7h6T4OkRiAVa3CpaXtWjgVqZJweYjXvW7A=; b=BSJCEe5EdApLklJrvzUKHLiyhwAs2Qwf3UyLjM9IF6x27iKz9ReMhN5B0L8MpRZUUr D4iEIweKFMgWUyCkEpvBipi3JjvYVc7C6VXfvn1URfseqq8HrZHRaMJ2RZqyAUkjNMRl pun+fO0Pee6wOxuFeJfULEsRGoMWRzlctFuff4lCf64+wYflWWM2PCQdb3EdqcMfAzgM qo4n5Ry4mk5I7yg6UAWqyq6V9azLl06BA4owqxQRF7QnLjXgbAJ/LnF4E1ZmBbU1rWaj VTu/yFi90mVUHSLKP58hdxJck76AYbZXziMPchQaI07n1wFdjFE6S5B5xJbQMNQW9awq tMMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8b84RKPTw7h6T4OkRiAVa3CpaXtWjgVqZJweYjXvW7A=; b=rgSh0mrGj9dVa5NRcWJhWDkEaieDs0H1QptP3sVqlDXgFjYb4vdVIM14iOLnXoiWjp lMkSaZzmiARMxB+UPsag3VJ7AGZeOlXQJ7Ah3kDTOy6dDDXOZE5n4jsbDLFDRKNCL6LX YY6odABXRZr9Eoby2tgowWe+7hzDfNiOojWpJ0+ihTpb5QasbVdghswkCJsEYtLcmqZ+ fUrU2Sed2dAIXvdZhRUySU1LEc/mh1J3r634CtNkOjvxMTxsIwh4QcLk+zqAq2O6AEzQ Kagy2LjA9QYbw++JhwNyHKkYSZB9Qnc0uPCZsRsQNLFzl7MjDdgD590n8milsOvpJ6UB ZZeA== X-Gm-Message-State: AGRZ1gLjLgDyhnbVSvZLI+wFCH/0XmSrM5ZCAUCnHddtT/DkfMzHUQm+ GVLa4MPz+2PJnkJtXGAKjLHM6L1n X-Google-Smtp-Source: AJdET5focKEkuO7dnKTMffTNdB78bVjhgTD4AJcJvpC9tM+ZLb81j+5auoTV8RbelDq/VJqsANAiWA== X-Received: by 2002:a63:ef0b:: with SMTP id u11-v6mr12020860pgh.283.1541185971921; Fri, 02 Nov 2018 12:12:51 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id s184-v6sm43100249pfb.46.2018.11.02.12.12.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 12:12:51 -0700 (PDT) Subject: Re: draft-herbert-ipv6-update-opts-00 To: ipv6@ietf.org References: From: Brian E Carpenter Message-ID: Date: Sat, 3 Nov 2018 08:12:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 19:12:57 -0000 On 2018-11-03 04:37, Tom Herbert wrote: > On Fri, Nov 2, 2018 at 7:35 AM, Ron Bonica wrote: >> Hi Tom, >> >> I cannot argue that your draft should include an exception because a) the truncation draft relies on it and b) the truncation draft is wonderful. The first statement is not true. I could remove an optimization from the truncation draft so that it no longer relies on the exception. The second statement is still a topic of debate. >> >> However, I can argue that your draft should include this exception because overwriting the Option type in this one particular corner case causes no harm. Unless you can show how it causes harm, the blanket rule is difficult to defend. >> > Ron, > > draft-herbert-ipv6-update-opts-00 is only clarifying RFC8200 in this > instance. In RFC8200 there is no provision that allows changing Option > Length or Option Type in flight. IPsec/AH relies on this. Allowing changes would therefore break IPsec/AH. RFC4302 Section 3.3.3.1.2.2. "Extension Headers Containing Options" Brian > Option Data may change per: > > "The third-highest-order bit of the Option Type specifies whether or > not the Option Data of that option can change en route to the packet's > final destination." > > Also, the truncation option is defined as a Destination option, but > the draft states: > > "Router 2 examines the Destination Options header" > > RFC8200 does not allow intermediates nodes to examine Destination > Options and definitely does not allow intermediate nodes to change > destination options. The truncation options really should be > Hop-by-Hop options. > > One other point, when an option is marked changeable the Option Data > is treated as zero-value octets for authentication. If an Option Type > is "changeable" wouldn't a similar consideration be needed for Option > Type value to be zeroed for authenticating? > > Tom > > > > > > > >> In a private email, Joel Halpern correctly points out that the exception should be slightly more narrow. Overwriting should be permitted only when all of the following conditions are true: >> >> - the new Option type, if recognized by the destination node, will cause the packet to be discarded >> - the new Option type, if not recognized by the destination node, will cause the packet to be discarded (i.e., The new Option type begins with 01, 10, or 11) >> - the option data length is zero before the update >> - the option data length is zero after the update >> - the packet does not contain an Authentication Header (this is the new restriction) >> >> Most of your comments are specific to the truncation draft. While our discussion may not be about the truncation draft, I have addressed your comments inline, below.... >> >> Ron >> >>> -----Original Message----- >>> From: Tom Herbert >>> Sent: Thursday, November 1, 2018 7:24 PM >>> To: Ron Bonica >>> Cc: IPv6 List >>> Subject: Re: draft-herbert-ipv6-update-opts-00 >>> >>> On Thu, Nov 1, 2018 at 12:57 PM, Ron Bonica wrote: >>>> Hi Tom, >>>> >>>> In your draft, you propose a rule forbidding updates to the Option type. >>> While I agree with this rule in the vast majority of cases, I would like to >>> propose an exception. An intermediate node MAY update an Option type if all >>> of the following conditions are true: >>>> >>>> - the new Option type, if recognized by the destination node, will >>>> cause the packet to be discarded >>>> - the new Option type, if not recognized by the destination node, will >>>> cause the packet to be discarded (i.e., The new Option type begins >>>> with 01, 10, or 11) >>>> - the option data length is zero before the update >>>> - the option data length is zero after the update >>>> >>>> An optimization in draft-leddy-6man truncate can be preserved only if that >>> exception exists. If you like, we can do a deep dive into the details of that >>> optimization. But I think that the exception requested above is narrow enough >>> that we may not need to go there. >>> >>> Hi Ron, >>> >>> Personally, I am skeptical about truncating packets being robust and I don't >>> think your exception would be the only one. It's possible that truncating >>> packets has side effects. For instance, the draft states >>> to: >>> >>> "Truncates the packet, so that its new length equals the MTU of the next-hop >>> link." >> >> This is addressed in Section 7 of the draft. Specifically.... >> >> A truncated packet MUST contain the basic IPv6 header, all extension >> headers and the first upper-layer header. When an intermediate node >> cannot forward a packet due to MTU issues, and the total length of >> the basic IPv6 header, all extension headers, and first upper-layer >> header exceeds the MTU of the next link in the path, the intermediate >> node MUST discard the packet and send and ICMP PTB message to the >> source node. It MUST NOT truncate the packet." >> >>> >>> But what if the total length of extension headers of the packet are greater the >>> new MTU? >> >> The overwrite will not change the total length of the extension headers. This is because the length of the new Option is identical to the length of the old Option. Specifically, Option Data Length equals zero. >> >> If an intermediate truncates EH that is equivalent to dropping EH >>> and probably creates a mismatched length on final EH. Even worse, what if it's >>> a segment routing header that is truncated in this process so that it renders the >>> packet undeliverable. >> >> See the text from Section 7, quoted above. >> >>> Also, if transport layer ports are truncated then packet would be blocked by >>> FW. >> >> See the text from Section 7, quoted above. >> >>> >>> A couple of other questions related to the draft. It states: >>> >>> "When the destination node receives a packet that has been truncated, it >>> sends an ICMP PTB message to the source node." >>> >>> But one of the reasons intermediate devices don't want send ICMP is >>> >>> "o A firewall on the path between the downstream router and the source >>> node administratively blocks the ICMP PTB message." >>> >>> Why would sending an ICMP from the destination be more likely to succeed >>> than sending from an intermediate node? I would think an ICMP sent from the >>> intermediate node has the greater chance of success since it is closer to the >>> source. >> >> Section 3 of the draft sites the following reasons: >> >> o The destination node has a viable route to the source node, but >> the intermediate node does not. >> >> o The source node is protected by a firewall that administratively >> blocks all packets except for those from specified subnetworks. >> The destination node resides in one of the specified subnetworks, >> but the intermediate node does not. >> >> o The source address of the original packet (i.e., the packet that >> elicited the ICMP message) was an anycast address. Therefore, the >> destination address of the ICMP message is the same anycast >> address. In this case, an ICMP message from the destination node >> is likely to be delivered to the correct anycast instance. By >> contrast, an ICMP message from an intermediate node is less likely >> to be delivered to the correct anycast instance. >> >> >>> >>> Also, >>> >>> o The source address of the original packet (i.e., the packet that elicited the >>> ICMP PTB message) was an anycast address. Therefore, the destination >>> address of the lso, if ICMP PTB message is the same anycast address. >>> >>> How does the ICMP message sent from the destination host avoid a problem >>> here? >> >> A more complete description of this problem can be found in Section 4.6.2 of draft-ietf-intarea-frag-fragile-02. >> >>> >>> Tom >>> >>> >>>> Ron >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail >>>> man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- >>> ndb3voDTXcWzo >>>> CI&r=Fch9FQ82sir-BoLx84hKuKwl- >>> AWF2EfpHcAwrDThKP8&m=OOurtqmx_KHuPAPnIEV >>>> >>> AlXonqcAxZpzTd46derizJrQ&s=mxZoUYxImh5GXNBdj1SvY37MVeV_yh2yhOh >>> bi2twedU >>>> &e= >>>> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Nov 2 12:20:35 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE608130E1E for ; Fri, 2 Nov 2018 12:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 c6S3Hwt1no3A for ; Fri, 2 Nov 2018 12:20:23 -0700 (PDT) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (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 1FEB9126BED for ; Fri, 2 Nov 2018 12:20:22 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id z17-v6so1391967pgv.3 for ; Fri, 02 Nov 2018 12:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FqzvqyXBW0Y19+YNgaKkjDvmCtdb6kW+i0jPJ3IA7ZQ=; b=R5hyOKrDKhxbkds8kcAPihuQ8RbXS/qh7O+0JO4RUSzx2AnGY8IbdVkgCCEFMUeqX5 1C8bRadgsesIy3vIJrLot37+spd5OEAffGUdldhFTW+dLFgXmX0QTn05t2xdg5m1YZ1N xVnSMB33hGFQm0DiPEevxtzgbtyEpk6ZzhXMoQNAle6ykvNAhrd2WRkygvEpeVlI8Wvq JKJK+v+dJv7iIABcDOYSvv1PnGSpZW6ShOod/7b5Uh9xvCdbxSlr8uhBdWnexUoVHdGL rdwOZ32OIOwOxBGoqQ95qRjs41KUvYGhDAG+DuaD5LtzixSAyfStavYx5OfcbCkEK0G4 xuDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FqzvqyXBW0Y19+YNgaKkjDvmCtdb6kW+i0jPJ3IA7ZQ=; b=dvEhwAICHcZISiV/UF1FdYWfRuI12VFjyoDVGc0I1iD+bE4Sdke0OKisOdsAxeOw+C bY805kCAYBMbAQOazxhvjuIrfizhFGiMJ2HaPznG17t8j3FtPQfWi60o3g3PZc3hVcQc 3xq+bJ2IcQ1OR140OoIYx8wsS6m7G8tmurRLhnYer+akdNQOkunzRGxgOiBOcAn2PArK XvNoPlX5nb4t9zXYGOGT3Jb2eaXkFHSBgh3PzGQmiodtgBy6Uj4XMVJLhgpXGDZATym9 h48tUz4FwvRIxreSeuNRJZgxM7uJ0TBH9pzXWIUQiPhWWJiiJ3uqYgswcN3CtiGzTH/O 8zFg== X-Gm-Message-State: AGRZ1gLM9m9d1F/gA7bVxZS6QAPFv5Ty+7gPNCkuUhTsTdkS04kjIj0V YMaKLFvZIQOZeoAF9twJNvSi5AIz X-Google-Smtp-Source: AJdET5fifqBzFPqcwPRonRXUD0RPNSWHLa86/xeXRlbsNVxMtU+l2pFoGfVZ+sGDg/ZdvQYWFYXBRg== X-Received: by 2002:a63:e04d:: with SMTP id n13-v6mr12223574pgj.426.1541186421194; Fri, 02 Nov 2018 12:20:21 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id m5-v6sm43336335pfc.188.2018.11.02.12.20.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 12:20:20 -0700 (PDT) Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Lee Howard , ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> From: Brian E Carpenter Message-ID: <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> Date: Sat, 3 Nov 2018 08:20:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 19:20:33 -0000 On 2018-11-02 19:09, Lee Howard wrote: >=20 > On 11/1/18 1:13 AM, Brian E Carpenter wrote: >> On 2018-10-31 22:24, Nick Hilliard wrote: >>> Job Snijders wrote on 30/10/2018 22:27: >>>> Can you (or others running FreeBSD EXPERIMENTAL) share reports on ho= w >>>> this pans out in practise? >>> Looking at the code, it acts by blocking outbound ipv4 frames from be= ing >>> transmitted on ethernet interfaces. This would mean - for example - >>> that if there were a default route already configured on the receivin= g >>> device, any userland code attempting to use ipv4 services would block= >>> until ARP times out for the default route (default 20 minutes on free= bsd). >>> >>> The only part of the ipv6only discussion that was uncontroversial was= >>> implementation of the kernel processing side of this flag - there's v= ery >>> little to go wrong when toggling a single flag. >>> >>> The problem area is how to handle the interpretation of this flag in >>> userland and in the kernel, which is a much more difficult problem. >> It's a question, but I don't know why it's a problem. It isn't an inte= rop >> problem, because each host is an independent actor in this. And we now= have >> running code proof that legacy hosts aren't affected. So I'd say that = from >> a protocol spec point of view, it's actually a non-issue. >=20 > Doesn't it mean that user space applications on a host that had/expecte= d=20 > IPv4 would fail? Well yes, but that is presumably the network administrator's intention, so I'm not sure I'd characterise it as am interop issue exactly, and it's= not an interop issues *involving the RA message itself*.=20 =20 > I think I described my interop concern:=20 > https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=3Dm&so=3Dfrm >=20 > IPv4-only hosts, and dual-stack hosts > that do not recognize the new > =C2=A0=C2=A0 flag, may continue to attempt IPv4 operations >=20 > If some devices require IPv4 and others disable IPv4, you have lost=20 > connectivity between systems on a local network. As written, this is no= t=20 > considered a misconfiguration by the administrator who sets the flag. Indeed not. The admin will presumably be happy at this result. I don't think we disagree about the effect, just about whether it's desirable. >>> This also disregards the issue of whether the flag was either necessa= ry >>> or a good idea to start with, and nearly 700 emails into this >>> discussion, the WG seems to be hopelessly divided on these issues. >> I'll leave that one to the WG chair who isn't a co-author. But I will >> say that in my mind the issue is whether the feature is one that will >> be valuable in 5, 10 or 20 years time rather than whether it's valuabl= e >> today. >=20 > I've come into the camp that believes that in 10 or 20 years IPv4 will = > be disabled by default. When people post to stackoverflow complaining=20 > that their 10-20 year old devices are unreachable from their brand new = > devices, the response will be, "The old stuff might be using the old=20 > protocol, IPv4. Go into Control Panel, Networking, Protocols, select=20 > IPv4, click enable." >=20 > If that's likely, then this flag is only useful in the interim 5 years.= =20 > During that time, I would like to maximize connectivity. >=20 > If a network administrator wants central control over IPv4/IPv6=20 > enablement in hosts, there are better, more centralized tools for that.= =20 > As a principle, host behavior should be managed by host management=20 > tools, and not by hints from a router. I'm not sure how that can work on a BYOD network. On a fully managed netw= ork, sure, we could "easily" invent a solution. Brian From nobody Fri Nov 2 12:22:45 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C542126BED for ; Fri, 2 Nov 2018 12:22:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qIugz-s02QU8 for ; Fri, 2 Nov 2018 12:22:34 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 F07491277BB for ; Fri, 2 Nov 2018 12:22:33 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id g21-v6so1452361pfi.7 for ; Fri, 02 Nov 2018 12:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4+YF8wX8+DR7Yml2qnkqRBTr4Pp1QQH49tjdvamTwh4=; b=uwhAcWdTfXsCYW6l+5qzxJT15eEH3vKfYL1e7xJRDdIKb4eZVRJ8pP3FjME5HUwWu0 t65QJsWwZ/4+P/Z6QJQerjQVm7+aQp0OkYfkuoTk0gWsf+reYdBKi5lb2u7gPI6wehN4 2PgM4QV8q1r2dbK+nJMPCvnc3+19mFT3NCxaf3PMqVqmQCxlmFHSRUgAhlOzsjaBu++c 4TkH+lUGvKAK4OuxlRz612Kah55HxiK7sPH/HrYKh3wrq58udynAUNlfEN6vqHRIXpyI TpmnzUDTzynrkt/7oQat4GAYJWHIsTLXMtvSWCgU2286OsR/oHVUl28EO+UbXbf1n5Ms NAPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4+YF8wX8+DR7Yml2qnkqRBTr4Pp1QQH49tjdvamTwh4=; b=maXrxRaIAqbCg03mFidtz331bT+UCPDxHx1cSo4d71py99XzyW3T0Dbz+OvGm2y1lz YerKIr17HcBvt7+uivr7+COAUBDfRpbWTqa6zBr2l3T+aSde0XkwVM0aiDCyYZC9SzLt aXICRX7jNP6lrQI7buEjAzSjiC8Hq1fsOU9QTwmoAqbu4ZvsmdyGxNg8BZL+ONsOZSZ8 SUztcc7qeq6UfVLEuo+cvwqSWVP/h4zZfBSK3VER/3VdSyChaAe7JnFpl2NlUHKR/yym DGA7b6nbYVN+fxQKimHpg4OBxBA/2JdIwqQTPjczyBgqqJNUFAJdO9iqUff61Q8LGpaR dOyw== X-Gm-Message-State: AGRZ1gIoQfObfPzxGbaG3QsynXaalWbVT3Opx0zUDqEBgtSfpvNfI4fa 1HKNUqROQPJ9XOQxoZ7LFfHIfvAQ X-Google-Smtp-Source: AJdET5emrH5gAC2CY2iDF48Uspm+J5uPuNjSMQaNpdof2LIJv3oGc/9IGNFeOnCthhDx955j8IoGiQ== X-Received: by 2002:a62:764e:: with SMTP id r75-v6mr12976609pfc.230.1541186553099; Fri, 02 Nov 2018 12:22:33 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id s184-v6sm43117288pfb.46.2018.11.02.12.22.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 12:22:32 -0700 (PDT) Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Lee Howard , ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <272233d0-8661-9d3a-1252-024f0b674e1b@asgard.org> From: Brian E Carpenter Message-ID: <6bb88d30-3412-5903-fc03-35cb965f55c8@gmail.com> Date: Sat, 3 Nov 2018 08:22:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <272233d0-8661-9d3a-1252-024f0b674e1b@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 19:22:37 -0000 On 2018-11-02 18:53, Lee Howard wrote: > > On 11/1/18 1:13 AM, Brian E Carpenter wrote: >> but I haven't seen any proposed text changes since >> the current draft came out. Lee, sorry, I still haven't processed your review. Brian > > > https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm > > > Lee > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . > From nobody Fri Nov 2 16:43:32 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA53127333 for ; Fri, 2 Nov 2018 16:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 bojnqgWvc4t8 for ; Fri, 2 Nov 2018 16:43:28 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 7A693126BED for ; Fri, 2 Nov 2018 16:43:28 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id n12so5710714qkh.11 for ; Fri, 02 Nov 2018 16:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tkieP3uZ9RifbKcNB7N2NXqKS1r6aW4EYaVXLGtwMeM=; b=ye/l2wrHbksFNJyqA7380bYFMf/VqjzbXDZzc4Me/vUuEN8gUoKTreeC5W0P8zHLSO 5J3rmvYu7YNuEIHVY45AD6JD8oYGQ1KjaAyVB1VW/YI1GyPRmnaWyV5EqNINvYJz9wQR UWNEOSlfv/2/YaCod3EzvmZ8xSp+/4H3Ud8rwd5uJvF3+PEuoa8IVvM1SZM7nY6QLEaY ZziwbW8yEmtXXkFZ2V5QAYcoweuN5ZoqkpEiBcEr60q+Vefg29FoA3WFvS9LPNFP/J05 xyYDz37EcvR1f0NkqYtg0+PpVUFGdSTf/18XyD3B1z4Zl2UAOuOJi4TdhhyLf1rmG22w v2FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tkieP3uZ9RifbKcNB7N2NXqKS1r6aW4EYaVXLGtwMeM=; b=r400Uqe1xR6lrHu+lvL4hs50RqtEfJhASVzN2xRCIF/LPOTbJi/69Rzaha8hFMMfb8 fuNEXrFVk7HWDiW7cbyV6gd6HgWFFmgwpoJcaVXI5/AOLUYbNOdHW1D2x6rDfI+YuBZ2 dNqICLAVqgtXQrEhraUsD0l7n2QpaYpsyIZrWRYLcJBWzUJACRivkrsmS59p7rxh6laP 7g+ILDhhVCQaLyWLFMXmcYAQJjW83xWqYhipU0MLslpLJX4VMx6W6xwPBDIkr5v6LWl2 iD1HPs0kCHiDIq/Ti/2ZpNsQ7MlhF1z1i+tJHVRz0s23qFkYXNR0TeGxXFIvFjFyzJER wXwQ== X-Gm-Message-State: AGRZ1gIxAyy7fcRn0+1bmPC8LDCaQeyBfHzI85xpteWo35tU0Ub1K1iK fWA/IUTj6Ndewmw2IrpXZDMd4NJOLxHR8UtyxRoyLw== X-Google-Smtp-Source: AJdET5emPnDCkozOe/9pclCyHERs/W3+Oay2rherATjv+8FV0ukEG3OnA5vID7OfcuDjd4fWVnYNagE0tzExsuqcyzM= X-Received: by 2002:a37:4f53:: with SMTP id d80-v6mr12862776qkb.323.1541202207350; Fri, 02 Nov 2018 16:43:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:2022:0:0:0:0:0 with HTTP; Fri, 2 Nov 2018 16:43:26 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Fri, 2 Nov 2018 16:43:26 -0700 Message-ID: Subject: Re: draft-herbert-ipv6-update-opts-00 To: Ron Bonica Cc: IPv6 List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 23:43:31 -0000 On Thu, Nov 1, 2018 at 12:57 PM, Ron Bonica wrote: > Hi Tom, > > In your draft, you propose a rule forbidding updates to the Option type. = While I agree with this rule in the vast majority of cases, I would like to= propose an exception. An intermediate node MAY update an Option type if al= l of the following conditions are true: > > - the new Option type, if recognized by the destination node, will cause = the packet to be discarded > - the new Option type, if not recognized by the destination node, will ca= use the packet to be discarded (i.e., The new Option type begins with 01, = 10, or 11) > - the option data length is zero before the update > - the option data length is zero after the update > > An optimization in draft-leddy-6man truncate can be preserved only if tha= t exception exists. If you like, we can do a deep dive into the details of = that optimization. But I think that the exception requested above is narrow= enough that we may not need to go there. > Hi Ron, I looked more closely at the draft. The part about changing the option type seems to be implied in: o Overwrites all instances of the Truncation Eligible option with a Truncated Packet option. It would be nice to have a more normative description that clearly specifies Option Type is being change in flight. A deep dive as to the details of the optimization would be also nice. I would presume your trying to keep the option to be a two octet value. If that's the only rationale, then I'm not sure the optimization is justified. For instance, for both HBH and Dest Opts EH the Hdr Ext Len is expressed in multiples of eight bytes. So if the Truncation option were the only option in the EH, four bytes of padding will still be required. AFAICT the savings by using a two byte option, as opposed to say four, is conditional on other options being present with fortuitous lengths. Tom > Ron > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Nov 2 19:13:37 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E104130E17 for ; Fri, 2 Nov 2018 19:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 5-DbzrMNL81t for ; Fri, 2 Nov 2018 19:13:34 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 563EB130E16 for ; Fri, 2 Nov 2018 19:13:34 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id j22-v6so1817797pfh.3 for ; Fri, 02 Nov 2018 19:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=94rdlEGvxNXibrxgF/pyjRTGs+CJoy94Gv3FCzzEAqg=; b=iRSkidjQNRbp9VQHD+/8gWZ2lBDXtDT0IeE/NBxFWWgkC/yK/Vzhu2kAkiArtSQQaq ivAFg6AHY1jjnZ/bX4NLAB2tzvY6w2dX2rgCgE07IOcvOMbOh9xIUKPQM9EzXDlEVpYK DkzGdtG/xtBj5Jf++OKtb5NHrTQe93WrlbOIOa5gyYfSRYDeBNZVTES/IL+8RXcD9q8k i6Ffqmyd6EpBs77WVMS2H2lgNc2pZ9F+bO7+aBP8M/BZQm2QY0gRYQJkcO7OfdJ8ux9k 1evXMBFFAm5MdyuSiOAgYAhG8yYGIIPcz++MwUA//Lm7lOGErh6J48mumIZUYPBqy6hG 2igA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=94rdlEGvxNXibrxgF/pyjRTGs+CJoy94Gv3FCzzEAqg=; b=nzSE/4fBeAZlisovF9dsIQ7a2Qccm3hYWP3FNKyg0jjo4BUC0YQf5qNWfjllx3ATNF 3QpTlS4V5+nYAUO2axWnnPsNoacS8MqCTB0AMv8IZVUwTea0EPkQQmCnVxtl2kP9cNlv NLThdYboASZEAjw9cUILre5sJKqP1/BONz5ltDDyDHFXbWkQu4jTBghqnqRAfpqqPwzF 1uKEecrnwgI4aQqzYhPbw6ws9h1JNXPt6gBRoLUXp/ORJelPn6yTfKDTNYAOxIO5hZAJ oz06CyvToGWHhikz0zCj89lCYFNkyUuD6U7nvsHUClFVPGxQGfUwwugKGxUK+iECfCij bRsA== X-Gm-Message-State: AGRZ1gIEZD7VTN/R8zWbTkRbT4OAnmxJfdnSosN+Jfi7Re3gt1+LWGcl WCncbbaRS2rnxKXpV70SIv4zSPqg X-Google-Smtp-Source: AJdET5c4Hdhh9emC5iwpjCEJCPzc7/6bC+3OXWDrVPCRjTtFhP14T886X0rB34vNNuTD1ojSABW2Ig== X-Received: by 2002:a62:5210:: with SMTP id g16-v6mr13921477pfb.256.1541211213308; Fri, 02 Nov 2018 19:13:33 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id i22-v6sm67572101pfj.82.2018.11.02.19.13.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 19:13:32 -0700 (PDT) Subject: Re: Running code, sending (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt) To: Alexandre Petrescu , ipv6@ietf.org References: <20181019.223739.271916573.sthaug@nethelp.no> <4f58643c-272e-507e-3282-c87befd42395@gmail.com> <0927741c-4e8e-fcf7-ddd6-3ba500ba4c3d@si6networks.com> <7B48A11D-31DE-443C-B73A-14642EA0A397@jisc.ac.uk> <7526af75-4359-6fc6-e39b-eb94024a04de@si6networks.com> <5E75F3CA-F1D2-4F4F-9CF7-EEEE59634C1E@gmail.com> <9B53019C-3506-4C9E-AFCF-D6125FA1A65B@gmail.com> <2DC241B3-310B-4A3A-BD4C-C0005FCE6155@consulintel.es> <20181024103057.GD924@hanna.meerval.net> <0219483d-8580-5e4a-8172-9401ef7c97b9@gmail.com> <89235e00-4514-da61-eb5a-366790c71165@gmail.com> From: Brian E Carpenter Message-ID: <1573afe8-c7a6-8808-f9e7-ce44eaea44ee@gmail.com> Date: Sat, 3 Nov 2018 15:13:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <89235e00-4514-da61-eb5a-366790c71165@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 02:13:36 -0000 fwiw I have reproduced Alex's test by installing scapy on a Linux box and using it to forge RAs as from my home gateway with the IPv6-only bit = set. Nothing breaks on the other hosts (Windows 10 and Android), which is as it should be, and Wireshark confirms that the packets are delivered and are excellent forgeries. Regards Brian On 2018-10-25 02:17, Alexandre Petrescu wrote: > correction: b.res=3D2 (instead of 1). >=20 > attached the packet capture >=20 >=20 > Le 24/10/2018 =C3=A0 14:43, Alexandre Petrescu a =C3=A9crit=C2=A0: >> Hi, >> >> Le 24/10/2018 =C3=A0 12:30, Job Snijders a =C3=A9crit : >> [...] >>> This is not discrimination. If authors don't have the capability to=20 >>> develop running code themselves, and also don't have access to >>> resources nor are able to convince others to implement a protocol >>> specification... the IETF's prime directive of interoperability can't= >>> be met anyway. >> >> On windows install python and scapy, then make an RA[*] and write >> b.res=3D1. This sets the 6th Reserved flag, now called 'IPv6-Only'. >> >> I just sent one, hoping sky wouldnt fall on my head :-) >> >> Alex >> [*] how to make an RA with scapy tool is described at >> https://samsclass.info/124/proj11/proj9xN-scapy-ra.html >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Sat Nov 3 00:00:00 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAD1127332; Fri, 2 Nov 2018 23:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 IawE70lojqCr; Fri, 2 Nov 2018 23:59:55 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 B5F18124BE5; Fri, 2 Nov 2018 23:59:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5FA271C02F4; Fri, 2 Nov 2018 23:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1541228395; bh=J2JadqoZuUbAbkunoJTt+293b6w8Asu4W5wUZeJ+4+0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OhCIzeyb21ro7u34iUhn2e+muTBjMFPe9vsHLTPgscgAu4cDdVoAuWIQFTYEtS1ll EaeZjA9uRsZ993+o6WQFVYs5uPePbHaOmgM3bXQZYVbZvhZ/bmznJNeb8qXamemlNY 68mWUv82y+Q5NwhScon5g3u3HVDt/2XNPqRVd7VE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [210.164.9.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4066B5A1706; Fri, 2 Nov 2018 23:59:54 -0700 (PDT) Subject: Re: SRv6 - SRH in encaps or base header - point 2 To: "Darren Dukes (ddukes)" Cc: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> <11918c9b-f0bb-4182-cdbe-9ed720b0a800@joelhalpern.com> <679B2EEF-4EE6-44BC-A9D7-17E70FF1133A@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Sat, 3 Nov 2018 15:59:52 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <679B2EEF-4EE6-44BC-A9D7-17E70FF1133A@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 06:59:59 -0000 Thank you. That does address my concern about those exchanges. Yours, Joel On 11/3/18 2:50 AM, Darren Dukes (ddukes) wrote: > Joel, For our last remaining item in this thread, *re: communication > from 1 to 9 and 9 to 1.* > > Lets add the following since we don’t discuss traffic from a host within > the SR Domain to a host outside the SR Domain. > > > *5.3.3 Inter SR Domain Packet* > Host 9 sends a packet to host 1 (outside the SR Domain) via an SR Policy > . > Host 9 encapsulates an inner packet from 9 to 1 in an outer IPv6 header > and adds an SRH for the SR Policy. > >    P7: (A9,S6)(S3,S6; SL=1)(A9,A1) > > A host implementation MUST support addition of the outer IPv6 > encapsulation to avoid leaking SIDs to nodes outside the SR Domain. > > For return traffic to A9, an outer IPv6 header may be applied by the SR > Domain ingress node.  This outer IPv6 header may terminate at node 9, > therefore a host implementation MUST support decapsulation of an outer > IPv6 header and processing of the inner header. > > > For traffic destined within the SR Domain it’s still up to the host or > controller providing the SR Policy to determine whether or not they must > encapsulate in an outer IPv6 header. > > Darren > >> On Oct 30, 2018, at 3:42 PM, Joel M. Halpern > > wrote: >> >> I am not sure I agree that the allowance for handling the HMAC >> elsewhere is straightforward.  For example, I think the range of >> implementation strategies for border nodes and the intersection of >> that with the range of operational and deployment strategies is going >> to actually make it harder to get multi-vendor deployments.  Having >> said that, the approach in the document will work.  And I can live >> with it. >> >> On the choice of encaps or not encaps (from node 9 to external node 1) >> there are two issues. >> The important issue is that node 9 needs to be able to encaps. >> Otherwise there is no decision availabe, and the nodes software is >> forcing the operator to disclose, even if there policy is not to do >> so. Thus, I think the minimum requirement is that the document needs >> to clearly state that node 9 needs to be able to handle incoming >> encaps and needs to be able to generate outgoing encaps. >> >> The lesser issue is "why bother?"  Why not always encaps.  Given that >> the network has to have an MTU big enough to handle an encaps packet >> (due to incoming packets from out the SR domain), there is no MTU >> issue wiht the encaps.  As such, we are talking about reducing the >> security and robustness of the solution in exchange for saving a few >> bytes.  That almost never turns out well. >> >> Yours, >> Joel >> >> On 10/30/18 3:30 PM, Darren Dukes (ddukes) wrote: >>> I think we’re almost concluded so once more inline at
>>>> On Oct 26, 2018, at 2:28 PM, Joel Halpern >>> > wrote: >>>> >>>> (resending, +spring as requested) >>>> >>>> Thank you for the responses.  I will respond in line, marked >>>> .  I fear it will shortly get too deep, but the context >>>> is important. >>>> >>>> I will rephrase here an issue from another thread that I ahve not >>>> seen your comments on.  If Node 9 is sending traffic to Node 1 (for >>>> example, the reverse traffic for the traffic from 1 to 9 in the >>>> examples below), it presumably has an SR Policy to be applied. The >>>> issue I raised before is the leakage issue.  If 9 puts the SRH in >>>> its packet (as the document currently mandates), then it will not be >>>> possible for 3 to remove the SRH.  Thus, the SRH will leak. >>>> >>>> Some have argued that is not a big deal.  It seems to matter to me. >>>>  But there is an additional problem.  A1 is not a SID.  Therefore, 9 >>>> can not put A1 into the SRH.  If it can not put A1 into the SRH, and >>>> it does not encapsulate the packet, where does it put A1. >>>
Node 9 has a choice, encapsulate to node 3 or not. >>> If node 9 does not encapsulate, it will inform the destination of the >>> segments in the SRH and possibly leak them to intermediate nodes. >>> If node 9 does encapsulate, node 3 removes the outer header and node >>> 1 would not learn the segment list. >>> I think its choice should not be mandated in the draft.
>>>> >>>> Yours, >>>> Joel >>>> >>>> On 10/26/18 1:29 PM, Darren Dukes (ddukes) wrote: >>>>> Hi Joel, you’ve described sections titled “Intra SR Domain Packet”, >>>>> “Transit Packet Through SR Domain”, and "SR Source Nodes Not >>>>> Directly Connected”. >>>>> I’ve parsed them inline to the sections of the draft defining them >>>>> and given more context where needed. >>>>>> On Oct 22, 2018, at 8:49 PM, Joel M. Halpern >>>>> > wrote: >>>>>> >>>>>> Rephrasing using the example from 5.2.  Assuming that 8 and 9 are >>>>>> SR Hosts (not just hosts within the domain, they are capable of >>>>>> and expect to deal with SRHs, and therefore have local SIDs, ...) >>>>>> >>>>>> For traffic from 8 to 9 that needs an SRH, the SRH goes in the >>>>>> IPv6 header sent my 8 to 9.  When 9 processes the packet, it seems >>>>>> that it is the last SID, figures out that there is no >>>>>> encapsulation, and send the TCP / UDP / QUIC information to its >>>>>> internal protocols stacks. >>>>> Yes, this is Section 5.3.1 “Intra SR Domain Packet”. >>>> Agreed as far as it goes.  However,  the existence of S9 and A9 >>>> points to a problem.  Node 8 is trying to put on an SRH going >>>> through Sx, Sy, whatever for some reason.  It can't put A9 into the >>>> SRH, as AH is not a SID, it is an address.  I presume node 8 got S9 >>>> from whatever provided him the SR Policy that it is using.  Does it >>>> simply use S9 as the address for node 9, rather than A9 that it got >>>> from DNS?  And does the TCP stack know that this substitution is >>>> being made?  (This is another example of a problem that goes away if >>>> we always encapsulate.) >>>
Section 4.3.2 covers these questions, i.e. A9 can be placed in >>> the SRH as the last segment, and this section describes how it’s >>> handled.
>>>> >>>>>> >>>>>> For traffic from 1 to 9, where 3 adds an SRH, that SRH still >>>>>> presumably ends at 9.  9 Receives the IP packet.  Sees that it is >>>>>> addressed to itself.  Sees that the SRH is finished.  And then >>>>>> notices that the next-header is IPv6.  Unwraps the header, checks >>>>>> that the inner destination address is also itself, and passes the >>>>>> material carried by the inner header up to the appropriate stack. >>>>> So node 1 sends a packet to node 9 (A1,A9) >>>>> IF there is some steering into an SR Policy at node 3 to reach node >>>>> 9, this is identical to section 5.3.2 “Transit packet through SR >>>>> domain”, except for destination of A9 via node 9  instead of A2 via >>>>> node 4. >>>> >>>>>> >>>>>> Thus, 9 needs to be able to check for both cases.  We at least >>>>>> need to tell implementors that. >>>>> Well, 9 needs a SID S9 and Address A9.  That is shown in Section >>>>> 5.1 SID and address representation. >>>> So, let us assume that 3 has an SR policy it wants to apply to >>>> the traffic from A1 to A9.  In this case, the S9 / A9 dichotomy is >>>> not a problem, I think.  Node 3 encapsualtes the packet from A1 to >>>> A9, uses S3 as the source address of the encapsulating header, and >>>> ends the SID list in the SRH with S9.  The unspecified part is that >>>> node 9 needs to be prepared to receive such packets and do the >>>> double processing.  It is reasonable double processing.  My only >>>> request here is that we tell folks they need to support it. >>>
Actually, node 3 uses A3 as its source address, but that’s minor. >>> The double processing (lookup, do end processing, do another lookup) >>> is documented in Section 4.3. >>> Is there a need for more than what is currently specified?
>>>>>> >>>>>> There is a further complication.  9 seems to need to have an >>>>>> address that is a valid SID, so it can be the last entry in the >>>>>> SRH from 8 to 9. >>>>> As described in the draft, Section 5.1 a node k has an address Ak >>>>> and SID Sk.  So node 9 has a valid SID. >>>>> For traffic from 8 to 9, A9 is used as the destination as shown in >>>>> section 5.3.1, 5.4 and 5.5. >>>>>>  However, if 1 were to send the packet to that SID for 9, router 3 >>>>>> would be required by the rules we discussed in the other thread to >>>>>> discard the packet as it is neither to prefix nor contains an HAMC. >>>>>>  And somehow, 8 and 1 need to each pick the right address to use >>>>>> for 9. (split DNS maybe?)  And 3 needs to be able to derive teh >>>>>> SID-formn address for 9 from the non-SID form of the address so >>>>>> that it (3) can build a proper SRH to get the packet to 9. >>>> I have retained your answer below for context, but I think that >>>> answers the wrong question.  I believe what is itnended is that only >>>> A9 appears in DNS.  So Node 1 will see 9 as A9, and will use that. >>>>  S9 will appear in SR Policies about traffic to node 9, but not in >>>> DNS.  That is what we need.  I wish it were clearer in the text. >>>> >>>> If node 20 is generating SRHs with HMACs, then this is largely >>>> the same as the case from 8 to 9, except that whomever creates the >>>> SR Policy that 20 is using needs to also make sure that whatever the >>>> first SID is in teh list, it processes HMACs and is recognizable to >>>> node 3 as doing such processing. I am guessing that the reason for >>>> allowing internal nodes to do the processing is to move the >>>> verification load off the edge nodes.  It does create significant >>>> additional configuration complexity. >>>
We didn’t see a reason to restrict the HMAC processing to only >>> edge nodes when it was straight forward to define how they could be >>> processed at non-edge nodes.
>>>> >>>>> This is incorrect. >>>>> See Section 6.2.1 “SR Source Nodes Not Directly Connected” I will >>>>> expand on the example from that section. >>>>> Node 20 sends a packet to A9 with SR Policy and an HMAC >>>>> provided to node 20 by some yet to be defined method.  Resulting in >>>>> packet sent from node 20 >>>>>   P: (A20,H7)(A9;SL=1)(payload) >>>>> Recall Hk is a SID at node k requiring HMAC verification, and it is >>>>> covered by Prefix-H. >>>>> Prefix-H is _not_ subject to ingress filtering at node 3. >>>>> Therefore the packet P destined to H7 is not subject to ingress >>>>> filtering at node 3. >>>>> P is forwarded to node 7, where H7 is processed and the HMAC verified. >>>>> If the HMAC can not be verified the packet is dropped, else it is >>>>> forwarded to the next segment and destination, A9. >>>>> Darren >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 10/22/18 8:04 PM, Darren Dukes (ddukes) wrote: >>>>>>> inline. >>>>>>>> On Oct 22, 2018, at 7:21 PM, Joel M. Halpern >>>>>>>> > wrote: >>>>>> .. >>>>>>>> 2) Now let us look at packets arriving at and actually destined >>>>>>>> for an SR Host in the SR Domain where that packet has an SRH. >>>>>>>>  If the packet is coming from another SR Host, the SRH will be >>>>>>>> in the base header, and the host can simply check it for any >>>>>>>> violations, and continue.  But, if the packet came from outside >>>>>>>> the domain, then it will have an encapsulating SRv6 header.  So >>>>>>>> the host has to detect this case, check and then peal off the >>>>>>>> encapsulating header, and then process the received packet. Yes, >>>>>>>> it can do so.  But nothing in teh document tells implementors >>>>>>>> they have to deal with both cases. >>>>>>>> >>>>>>> Can you be more precise here.  Perhaps use the example from >>>>>>> section 5.2 or 6.2.1? >>>>>> .. > From nobody Sat Nov 3 00:35:34 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F60128DFD for ; Sat, 3 Nov 2018 00:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 sLbfWtrXU8wo for ; Sat, 3 Nov 2018 00:35:30 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B46AA127332 for ; Sat, 3 Nov 2018 00:35:29 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id 74-v6so4096925wrb.13 for ; Sat, 03 Nov 2018 00:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CceGJyR9N+ZWnHId53ElJ+AhA1ZpvBVe9d20PpIqtp4=; b=WlKcnU4Sg1YI2ZYd7cqqNLlN2ypAYJa2Bpa0gaN5hfGPnLamc8twWONi/Nr9zvMa3I nvVtL/U8jw3o7xlmFe8oejYiD0EsE8YFDOjGO6HTbYylbfjAkB3zdgMDuA8ZEqDUISPm y56+WwzCvhqGjmwjQTG6eJkY4o0nDOmySF5SRH7fS6yNlrtxgaN98rcA58Tl1Qn8hnjN Hl+ekRuPmB9dMU5A8i9jGyq6ckILclmr9Sxw9r5kzuN4OEywtZsaFKFgXgrzRVzWwcQo Zq8uFKKl9pvrySxNOhK2EEiIcYJalCtTXg/TBuWS5LxR4VWw/EzSE51fcohEqTrxvbZf 5AXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CceGJyR9N+ZWnHId53ElJ+AhA1ZpvBVe9d20PpIqtp4=; b=X0mAbSYlxwCmkhf7pVPOd3s1mebyJ1JnxjRHOKIzSTYjZ8GLW+dXRxvPnUbC3/L74C PHbgR5sKHV72bx26sguQ5Uy0Dnmd3jkN1lrAWSBRTNddiAfvrH0tDkKV9IeJFAbLKZWz KbcECiKMxRCTw1dn4wX5NPH3tPRx9Z10bgZHwtAVv2vafumlBxZBAQlCHTA0cd+Cq5CJ YQKXGtz158Nu4nBa1gRuCDUn/jMSHgjaJXxt0SogxokM51TCpsEOfIZYvI6zE478fFQg TNMtQsAHfLVz9WYKK158bC2Zb8UxZD1YlDTrfyKhvzM3ZlbrD0soWRFsuYuNHaiArTkf q6hA== X-Gm-Message-State: AGRZ1gJ6eWArk8+oL2rAhSF66UqJbTIWeUTRY5KrZLhNbvo8bMOwkn2x ex+/bae4v9XNt89eb4/iQeI= X-Google-Smtp-Source: AJdET5c0e03I9qLpu9/aNtUJd4s3oLLbNUvhuR9iH6MIu+Hr+FsfCenntIko/1eDXd8VjIDBGbb1gw== X-Received: by 2002:a5d:4512:: with SMTP id s18-v6mr11989689wrq.86.1541230528198; Sat, 03 Nov 2018 00:35:28 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:51c1:d429:565e:1274? ([2001:67c:1232:144:51c1:d429:565e:1274]) by smtp.gmail.com with ESMTPSA id 82-v6sm44586145wms.17.2018.11.03.00.35.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Nov 2018 00:35:27 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_69571BF3-A4ED-4741-A084-E79DA5B22D27"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-herbert-ipv6-update-opts-00 Date: Sat, 3 Nov 2018 14:35:22 +0700 In-Reply-To: Cc: Bob Hinden , Ron Bonica , IPv6 List To: Tom Herbert References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 07:35:32 -0000 --Apple-Mail=_69571BF3-A4ED-4741-A084-E79DA5B22D27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, > On Nov 3, 2018, at 6:43 AM, Tom Herbert wrote: >=20 > On Thu, Nov 1, 2018 at 12:57 PM, Ron Bonica = wrote: >> Hi Tom, >>=20 >> In your draft, you propose a rule forbidding updates to the Option = type. While I agree with this rule in the vast majority of cases, I = would like to propose an exception. An intermediate node MAY update an = Option type if all of the following conditions are true: >>=20 >> - the new Option type, if recognized by the destination node, will = cause the packet to be discarded >> - the new Option type, if not recognized by the destination node, = will cause the packet to be discarded (i.e., The new Option type begins = with 01, 10, or 11) >> - the option data length is zero before the update >> - the option data length is zero after the update >>=20 >> An optimization in draft-leddy-6man truncate can be preserved only if = that exception exists. If you like, we can do a deep dive into the = details of that optimization. But I think that the exception requested = above is narrow enough that we may not need to go there. >>=20 > Hi Ron, >=20 > I looked more closely at the draft. The part about changing the option > type seems to be implied in: >=20 > o Overwrites all instances of the Truncation Eligible option with a > Truncated Packet option. >=20 > It would be nice to have a more normative description that clearly > specifies Option Type is being change in flight. >=20 > A deep dive as to the details of the optimization would be also nice. > I would presume your trying to keep the option to be a two octet > value. If that's the only rationale, then I'm not sure the > optimization is justified. For instance, for both HBH and Dest Opts EH > the Hdr Ext Len is expressed in multiples of eight bytes. So if the > Truncation option were the only option in the EH, four bytes of > padding will still be required. AFAICT the savings by using a two byte > option, as opposed to say four, is conditional on other options being > present with fortuitous lengths. =46rom my read of the truncation draft, I don=E2=80=99t understand why = rewriting the option type is necessary. It would simpler to have a = single option with a place to mark that the packet had been truncated in = the option. Seems like unneeded complexity and having a single option = would avoid any need to rewrite option types. Thanks, Bob >=20 > Tom >=20 >> Ron >>=20 >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_69571BF3-A4ED-4741-A084-E79DA5B22D27 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlvdT7oACgkQrut0EXfn u6jCkQgAi4jiF4zg8bszvHxT/y96WIpObeRX9EeWcxj3Fn0cBmLenUIzGzRn/vk3 bPwq6sF5UY/sFM9QmudJGHMJe970Sv9Cm6vQS4WlxrDIM2As+Qx/cIL7xEVYYPtr w0MknxwEKDGA2ox18RcD6CVQVaxkTi8BTyUIYn7nhdDUZjogibiP4mQcMJxI4bEr 0KmDxj/ejnX+OPwlZSale2Jd1RcrtwOjgulqKGmxvN5gFYYOkswz3ihAeDXDzwYz zh4E3TxTZ7p/++JK84yXBrngb9s1i0dAHJ51Uh40XgV9NkQvUUhbNxZ4RJttnqhI QDkq6hO7Kf0fKHWGCjULVZ2e6CsSDQ== =TP+w -----END PGP SIGNATURE----- --Apple-Mail=_69571BF3-A4ED-4741-A084-E79DA5B22D27-- From nobody Sat Nov 3 02:45:56 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA63312426A; Sat, 3 Nov 2018 02:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 VrxUJRTt_yCP; Sat, 3 Nov 2018 02:45:52 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 54B56124BAA; Sat, 3 Nov 2018 02:45:49 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id 74-v6so4294815wrb.13; Sat, 03 Nov 2018 02:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=ZYPKqTz5us624h/u+zL7/bsguZNEOhrwcGklKsSXU1k=; b=k7Kj1UETGCd5yxNWV6gaf0mgiXkO8dXk6URkLtjT5tkDZEchRPLuc6ZxD2TXZbw9Lh dKpdQm9B/8Twibsam137TjMHQFehLc4lSnE8NTP58xdVeA1NSr6J9JwRazV4K3b6g1S7 eYasZRQsNZImDaaQEvgUTsj/VP3z24f47+zKgBWGeD48mMhXYsvHIFzXEH+lBph/pSYv gT9J824kEdsMlUPwUPjXivqeJdxsExKHQcgXlpaelzrawt5w/TQrBfTTkrmGi6l1T+qG 16/ZPdt+q4bB37HscA33RcntL7IJmIPlp9RAFltJPe0gTnLAsbbdpBJS/1nYXDL7O4RL Xirg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=ZYPKqTz5us624h/u+zL7/bsguZNEOhrwcGklKsSXU1k=; b=mb1JJ5ygs0jsmY0WMfmxnb27Q/NITptgyELy4YLWTl19yn7KS3iZY3MLh9GLHMxFwG t6I5nntiCt4SDjFkJEw9WbwdO/6zbpInqQtKqHCuNQ7/WBPMLOQQ0nxShsWHFzUtUtOR UnRdecGIH7utaPd9HgBWCQk319gHD+kjGJQPZqwmkdOSfBxTpxfJTj0DCcMOjbBTJc16 HCuMULw4H6KNnTAg9QzgYJ3q1+6j4qXzXZyjhemwtqXLMiS7SAKhdCKXg/saUSGFfH36 cIgOYf+O/7MHeZXE26C+IzFST2Nzqcg2z/acYNoirlOgdSiRtAF/S/88ixQ0Et5krgnn +soA== X-Gm-Message-State: AGRZ1gI1fJh2TjEX7J9/kVP5o6QvuiVhef3gc7brrxpnZQrXlqsN2ErQ mmM4YQeajBSKEdQZa/q29rRxIn51 X-Google-Smtp-Source: AJdET5dm+1Mk3GomZVq9XcRNGThd1etssDSBFeWpKBGJwMF4mrzg1e6WuFRyYQTG4Lq1m0p270hF1w== X-Received: by 2002:adf:fac4:: with SMTP id a4-v6mr13707857wrs.202.1541238347432; Sat, 03 Nov 2018 02:45:47 -0700 (PDT) Received: from dhcp-9bb0.meeting.ietf.org (dhcp-9bb0.meeting.ietf.org. [31.133.155.176]) by smtp.gmail.com with ESMTPSA id v189-v6sm19751833wmd.40.2018.11.03.02.45.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Nov 2018 02:45:46 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_79AFB2DE-A974-4F22-BF8A-463D280AEBDE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Comments on Message-Id: <78F491E2-7CE1-4562-B5F3-775804A8CC54@gmail.com> Date: Sat, 3 Nov 2018 16:45:41 +0700 Cc: Bob Hinden , IPv6 List To: draft-leddy-6man-truncate.authors@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 09:45:55 -0000 --Apple-Mail=_79AFB2DE-A974-4F22-BF8A-463D280AEBDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I read the current version of this draft on the flight to Bangkok and = have some comments. First of all, I think this is a significant improvement from earlier = versions. It=E2=80=99s getting better. I am still unsure about the = mechanism proposed as tool to improve PMTU discovery, but we will have = that discussion in the 6man session. Comments below, these are both substantive and editorial. Bob General comments: I don=E2=80=99t see the need for two option assignments (Truncation = Eligible and Truncated Packet), IMHO it would be a lot simpler with one = option that has a data field that could indicate if the packet was = truncated. It would eliminate the need for rewriting the option type, = and make finding the option simpler. Many few error cases as well. I think the draft would be better if it just talked about routers, = instead of intermediate nodes and middle boxes. We have only defined = routers and host in IPv6. In several places the draft says =E2=80=9CAccording to [RFC8200]=E2=80=9D.= I think this would be better with something like =E2=80=9CAs specified = in [RFC8200]. Specific comments: Section 1 Introduction: In order to maintain a running estimate of the PMTU, IPv6 nodes can execute Path MTU Discovery (PMTUD) [RFC8201] procedures. The requirement in RFC8201 is =E2=80=9Cshould=E2=80=9D implement PMTUD. = This doc should say that. 4.1. The Truncation Eligible Option, I didn=E2=80=99t understand why: IPv6 packets that include the Fragment header MUST NOT include the Truncation Eligible option.=E2=80=9D Please explain the need for this. 4.2. The Truncated Packet Option: NOTE 2: According to [RFC8200], the third-highest-order bit (i.e., the "chg" bit) of the Option Type specifies whether Option Data of that option can change on route to the packet's destination. Because this option contains no Option Data, IANA can assign this Option Type without regard to the "chg" bit. I don=E2=80=99t think this work for an IANA assignment, it has to be = zero or one. I think you want it specified as unchangeable. 5. Reference Topology The figure in this section looks to be two wide to fit on a page. Needs = to be fixed. 6. Truncation Procedures Subsequently, the same upper-layer protocol on the Source Node causes the IP layer to emit another packet. This packet is identical to the first, except that the total packet length is 2000 bytes. Because the packet length is greater than the actual PMTU, this packet cannot be delivered without encountering an MTU issue. I found this confusing. The packet isn=E2=80=99t identical, as it (as = stated) has a different length, and I would assume different data in it. = I don=E2=80=99t understand this text, please clarify. The IP layer on the source node forwards the packet to Router 1. Router 1 forwards the packet to Router 2, but the Router 2 cannot forward the packet because its length exceeds the MTU of the next link in the path (i.e., 1500 bytes). Because an MTU issue has been encountered, Router 2 examines the Destination Options header, searching for either a Truncation Eligible option or a Truncated Packet option. (Normally, the Router 2 would ignore the Destination Options header). Is this going to happen in the fast path of a router? Please explain. 7. Additional Truncation Considerations A truncated packet MUST contain the basic IPv6 header, all extension headers and the first upper-layer header. When an intermediate node cannot forward a packet due to MTU issues, and the total length of the basic IPv6 header, all extension headers, and first upper-layer header exceeds the MTU of the next link in the path, the intermediate node MUST discard the packet and send and ICMP PTB message to the source node. It MUST NOT truncate the packet. I assume this is for a case with, for example, early link of 9000 = getting to a smaller link. Seems pretty unlikely to happen in practice = that the headers wouldn=E2=80=99t fit in the packet. Even a 1500 byte = packet. 9. Checksum Considerations When an intermediate node truncates a packet, it SHOULD update the upper-layer checksum, if possible. This is desirable because it increases the probability that the truncated packet will be delivered to the destination node. Saying SHOULD and using a modifier =E2=80=9Cif possible=E2=80=9D is odd. = It should either be a SHOULD or MAY. Middleboxes residing downstream of the intermediate node may attempt to validate the upper-layer checksum. If validation fails, they may discard the packet without sending an ICMP message. The doc needs to show some analysis that routers that look at = destination headers and validate transport checksums will pass these = packets with or without checksum recalculation. The Checksum part of = this proposal seems problematic to me. It=E2=80=99s a lot of work for = the router having to do the checksum recalculation and it=E2=80=99s not = clear if these truncated packets will make it to the destination host. 10. Invalid Packet Types This would get a lot simpler if there is only one option. o Send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the first invalid option. This needs text to say to not send too many of these. Otherwise it can = be used as an attack. 13. Extension Header Considerations The Hop-by-hop option can be examined by each node along the path to a packet's destination. Destination options are examined by the destination node only. However, [RFC2473] provides a precedent for intermediate nodes examining the Destination options on an exception basis. (See the Tunnel Encapsulation Limit.) That=E2=80=99s a very creative interpretation of RFC2473. RFC2473 is = discussing tunnel end points, effectively they are the source and = destination of the tunneled packet. That very different from what is = propose in this document. I don=E2=80=99t think RFC2473 can be used to = justify this. --Apple-Mail=_79AFB2DE-A974-4F22-BF8A-463D280AEBDE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlvdbkUACgkQrut0EXfn u6gdawf/SozGtOy+S7CRge/gJp3zWaghsNIF8iAUWi9UltcqkYhQYZZrad5Bin6k RknnR2Wsw1Tn2EI61SbcVoz2rdnz7IDsTVAleHBht7ObPSbBNYLM9J5I/ipnISTu M9e678qy3BO+lJqukN8mZgF6ekg4TlsCY5D0DPPpPgk3g4fnpP6dOgGS1b8KZk2G 0V0nvMM2t/Cut6+flDmrN6ucaV5gsckBpMSzIvzqtJYHSWINl4xwjorphhf1bkqX w8Jy+El8JuTpoNUOCS/8283VqD9w1aFGAuL/pLoTcrAXaBBmAWUs+wF3PVx9XWEB 1HZ0SLpRA0ljdGh3XHDDgibwv8EwUQ== =YldQ -----END PGP SIGNATURE----- --Apple-Mail=_79AFB2DE-A974-4F22-BF8A-463D280AEBDE-- From nobody Sat Nov 3 04:36:11 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FBD1288BD for ; Sat, 3 Nov 2018 04:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 EA505AA_AZwf for ; Sat, 3 Nov 2018 04:36:08 -0700 (PDT) Received: from atl4mhob03.registeredsite.com (atl4mhob03.registeredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id B7081124BAA for ; Sat, 3 Nov 2018 04:36:07 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob03.registeredsite.com (8.14.4/8.14.4) with ESMTP id wA3Ba3HQ019119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 3 Nov 2018 07:36:03 -0400 Received: (qmail 17354 invoked by uid 0); 3 Nov 2018 11:36:03 -0000 X-TCPREMOTEIP: 14.143.0.166 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?172.18.0.22?) (lee@asgard.org@14.143.0.166) by 0 with ESMTPA; 3 Nov 2018 11:36:03 -0000 Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Brian E Carpenter , ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> From: Lee Howard Message-ID: <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> Date: Sat, 3 Nov 2018 17:05:59 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 11:36:10 -0000 Sorry, I didn't trim because I think it's all context... On 11/3/18 12:50 AM, Brian E Carpenter wrote: > On 2018-11-02 19:09, Lee Howard wrote: >> On 11/1/18 1:13 AM, Brian E Carpenter wrote: >>> On 2018-10-31 22:24, Nick Hilliard wrote: >>>> Job Snijders wrote on 30/10/2018 22:27: >>>>> Can you (or others running FreeBSD EXPERIMENTAL) share reports on how >>>>> this pans out in practise? >>>> Looking at the code, it acts by blocking outbound ipv4 frames from being >>>> transmitted on ethernet interfaces. This would mean - for example - >>>> that if there were a default route already configured on the receiving >>>> device, any userland code attempting to use ipv4 services would block >>>> until ARP times out for the default route (default 20 minutes on freebsd). >>>> >>>> The only part of the ipv6only discussion that was uncontroversial was >>>> implementation of the kernel processing side of this flag - there's very >>>> little to go wrong when toggling a single flag. >>>> >>>> The problem area is how to handle the interpretation of this flag in >>>> userland and in the kernel, which is a much more difficult problem. >>> It's a question, but I don't know why it's a problem. It isn't an interop >>> problem, because each host is an independent actor in this. And we now have >>> running code proof that legacy hosts aren't affected. So I'd say that from >>> a protocol spec point of view, it's actually a non-issue. >> Doesn't it mean that user space applications on a host that had/expected >> IPv4 would fail? > Well yes, but that is presumably the network administrator's intention, > so I'm not sure I'd characterise it as am interop issue exactly, and it's > not an interop issues *involving the RA message itself*. > >> I think I described my interop concern: >> https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm >> >> IPv4-only hosts, and dual-stack hosts >> that do not recognize the new >>    flag, may continue to attempt IPv4 operations >> >> If some devices require IPv4 and others disable IPv4, you have lost >> connectivity between systems on a local network. As written, this is not >> considered a misconfiguration by the administrator who sets the flag. > Indeed not. The admin will presumably be happy at this result. > I don't think we disagree about the effect, just about whether > it's desirable. > >>>> This also disregards the issue of whether the flag was either necessary >>>> or a good idea to start with, and nearly 700 emails into this >>>> discussion, the WG seems to be hopelessly divided on these issues. >>> I'll leave that one to the WG chair who isn't a co-author. But I will >>> say that in my mind the issue is whether the feature is one that will >>> be valuable in 5, 10 or 20 years time rather than whether it's valuable >>> today. >> I've come into the camp that believes that in 10 or 20 years IPv4 will >> be disabled by default. When people post to stackoverflow complaining >> that their 10-20 year old devices are unreachable from their brand new >> devices, the response will be, "The old stuff might be using the old >> protocol, IPv4. Go into Control Panel, Networking, Protocols, select >> IPv4, click enable." >> >> If that's likely, then this flag is only useful in the interim 5 years. >> During that time, I would like to maximize connectivity. >> >> If a network administrator wants central control over IPv4/IPv6 >> enablement in hosts, there are better, more centralized tools for that. >> As a principle, host behavior should be managed by host management >> tools, and not by hints from a router. > I'm not sure how that can work on a BYOD network. On a fully managed network, > sure, we could "easily" invent a solution. Taken all-in-all, then, the use case for this flag is a network where the administrator: 1. does not know what's on the network, 2. expects that there are some applications using IPv4, 3. understands that IPv4 will continue to work locally, 3b. except for dual-stack hosts that honor the flag, 4. understands that applications may have already negotiated IPv4 connectivity, 5. desires to break communications for 3b and 4, and prevent IPv4 Internet access. It's not just that administrator accepts that 3b and 4 won't work, but as you said above, "The admin will presumably be happy with this result." This seems to me a very narrow application. Lee > > Brian > From nobody Sat Nov 3 04:40:31 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42F512870E for ; Sat, 3 Nov 2018 04:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 Qi2Gb3G87cH0 for ; Sat, 3 Nov 2018 04:40:28 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 B5F9F12008A for ; Sat, 3 Nov 2018 04:40:28 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id o19-v6so3235628iod.3 for ; Sat, 03 Nov 2018 04:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=LSALTN5b3ssMbRIFOxXtT/BFmKX7xcvaYIl7m3bp7VE=; b=pxTUY26mzd2qgXSUIa3LerMWRCvEwGniJrEUSq2W3Y9BGjlv1aggvMLD/d6I4tr6nC VM/dH6vkplMgpsn+Vo1w6lMEfQk3nFY3TG/sCWxGPFgZsqx9MT4/dgWVTcoZMUopLe33 oFT6evPW6RGQ0O799kY6I4BapmydiH3DC/jMiESsOpDTP6J+Mt/+CViBQUqBeAEU64Nw IoTHvwwsCAu6cta7yZkevDkfwP9E0AHGHT7Ono2J19LgfHM/bC39DRVBmxsNEfU1vbfL 1q2qLJVATA9bqEAZpQHA46wmjGfelJlMqDBmmzAZTliORR+YwFpX53WI9rTEEW6s3ojA C85w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=LSALTN5b3ssMbRIFOxXtT/BFmKX7xcvaYIl7m3bp7VE=; b=sGJqY8mlayBFdCOX/38fci8u3YnaHOt50SMMJmlOlcWF55LIeRZLDd/CXT+Nteb1TX eCOwvgyqktz9w5sU6kcPY9OXvdkFlHCgvxNFip6Xr3UrP9FbunoofhJDm4EHRlnVrDi9 8rC6BAeCQuemTxXBqOzJr+CQxNyDA7dVakvIVjGErZ6bp5cAlrM0hRa+ZRZAwUum4PAd OCMj+DJPKh85EfMIlrNMdEaZlIPuVlH73oMBjWOgCoFOHYX7kl0QpE9RASZm6hbQiPxs 34mbd9bl8fBxI17O+k7EKS5WrZpqJwtKDbEpvH45xd/niKRhbfShgLPiggw+hL6pUXZ2 Crpg== X-Gm-Message-State: AGRZ1gIeI84y3PkTDr5BIMnSOsaLiFpuFpNcDVCrZldoiRLrRrab76l3 qDRa20pjtjfubLPSyMyhf6nvVbh2SX/oGGqjGmd38Q== X-Google-Smtp-Source: AJdET5ebOXdvyh7Y9KGkSj8Hary+5koHG/MIM4S9AJ7y5mmTQWlwInZraLmNNyUux8Zz9NuvjTdjkSTKHWqVe1Ws3l0= X-Received: by 2002:a6b:918b:: with SMTP id t133-v6mr12300730iod.267.1541245227828; Sat, 03 Nov 2018 04:40:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:19c2:0:0:0:0:0 with HTTP; Sat, 3 Nov 2018 04:40:27 -0700 (PDT) Received: by 2002:a02:19c2:0:0:0:0:0 with HTTP; Sat, 3 Nov 2018 04:40:27 -0700 (PDT) In-Reply-To: References: From: bernice kibet Date: Sat, 3 Nov 2018 14:40:27 +0300 Message-ID: Subject: Ipv6 on WIMAX 16e To: ipv6@ietf.org Content-Type: multipart/alternative; boundary="000000000000510deb0579c11e1f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 11:40:30 -0000 --000000000000510deb0579c11e1f Content-Type: text/plain; charset="UTF-8" Hello, Any advise on ipv6 transition on WIMAX 16 e. P2P not up on WIMAX 16e but up on WIMAX 16d. Regards, Bernice Re --000000000000510deb0579c11e1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

Any advise on ipv6 transition on WIMAX 16 e. P2P not up on WIMAX 16e but u= p on WIMAX 16d.=C2=A0

Re= gards,=C2=A0
Bernice=C2=A0

Re
--000000000000510deb0579c11e1f-- From nobody Sat Nov 3 08:57:42 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF01286E7 for ; Sat, 3 Nov 2018 08:57: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 EmsI28QHutcs for ; Sat, 3 Nov 2018 08:57:39 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 85AE81277D2 for ; Sat, 3 Nov 2018 08:57:38 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id e4so7980580qkh.6 for ; Sat, 03 Nov 2018 08:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PN0EtFVtWe+xO0ti610yilIdZ9RP0ajNddZ3DoPH2Sc=; b=Kyy5xfnj5S72n8+0fx+0Aqaes30IF2ru2HlElbvvTjqmo0qDTuwpKOcBLGNiXv5qU9 jU8ErMqQYOiZdURABefL+eFWsZAYske6SujxonFauL9Jr/8IJ6eNOETadlPyAkoEOR0s MeQ8hbR+W8bAcBiwPZpj8hy+/LuXKRpyEFzDeMr1DQaI3fimKcJgC4v8T1gpCEmjH2OM ZY5jCoMzKOGJIhGops7CyZ1uV563LK68u/Fi4StflzZ7HrXCLO2KNsRTEuQgbLj8R+f0 +kxh9Y66m8v2LxxmoG12pdr9BKYc/gbZrn66SR9xPu0QVgY0kSGC5CWqONWSuLNbGWmu uzjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PN0EtFVtWe+xO0ti610yilIdZ9RP0ajNddZ3DoPH2Sc=; b=UVYA8/n4FWCGcXT22lzFYw8krcxHxAzFS5IYVG0IesvqUxQstLP9CETcY432kmu1gG +B+AGug4vmkxDtsXgLwkwnYWOu7JEjUdFFoJhf+irn6/8xkkHo6zk9myEFFkACNiBUwq yqwUVSrLSHaEKQTyeRfw+9Tz4thJGRF/oC7k8RfDqt6EtnQXrQwJRCnKB71zhuQCyCnl h0U034NLRwUonFsYXMNEHeaVvxwFcnzGnSpD9uoHZ/CNto2UoKgsjrAEeQ9v7jliwXIF U7UCPSv+aYUXTc0k1GdKSorhRe/Xea8sn1p9TbmiIAnnHTFr5DTR2Krmrw4Wa53j0Yry M6jQ== X-Gm-Message-State: AGRZ1gK82poKi2JrNmFEjbCCYl14zm1BBvxKYJuw8tAPcj2Aytlg2tDQ IQFR2I47LKpQxNkr/AQT6Im0kFmoMKvw/ItvLd1tIg== X-Google-Smtp-Source: AJdET5foq4lgMxL5FjpSsDjJtFnb0m6Lfvz04PL2tyPqK3Xh3Vp1pkxlI3ltU79yE0FggZi2maEIjNhhe4L1/ymFOYQ= X-Received: by 2002:aed:3c0c:: with SMTP id t12mr15296106qte.226.1541260657358; Sat, 03 Nov 2018 08:57:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:2022:0:0:0:0:0 with HTTP; Sat, 3 Nov 2018 08:57:36 -0700 (PDT) In-Reply-To: <78F491E2-7CE1-4562-B5F3-775804A8CC54@gmail.com> References: <78F491E2-7CE1-4562-B5F3-775804A8CC54@gmail.com> From: Tom Herbert Date: Sat, 3 Nov 2018 08:57:36 -0700 Message-ID: Subject: Re: Comments on To: Bob Hinden Cc: draft-leddy-6man-truncate.authors@ietf.org, IPv6 List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 15:57:42 -0000 On Sat, Nov 3, 2018 at 2:45 AM, Bob Hinden wrote: > Hi, > > I read the current version of this draft on the flight to Bangkok and hav= e some comments. > > First of all, I think this is a significant improvement from earlier vers= ions. It=E2=80=99s getting better. I am still unsure about the mechanis= m proposed as tool to improve PMTU discovery, but we will have that discuss= ion in the 6man session. > > Comments below, these are both substantive and editorial. > > Bob > > General comments: > > I don=E2=80=99t see the need for two option assignments (Truncation Eligi= ble and Truncated Packet), IMHO it would be a lot simpler with one option t= hat has a data field that could indicate if the packet was truncated. It w= ould eliminate the need for rewriting the option type, and make finding the= option simpler. Many few error cases as well. > > I think the draft would be better if it just talked about routers, instea= d of intermediate nodes and middle boxes. We have only defined routers and= host in IPv6. > > In several places the draft says =E2=80=9CAccording to [RFC8200]=E2=80=9D= . I think this would be better with something like =E2=80=9CAs specified i= n [RFC8200]. > > Specific comments: > > Section 1 Introduction: > > In order to maintain a running estimate of the PMTU, IPv6 nodes can > execute Path MTU Discovery (PMTUD) [RFC8201] procedures. > > The requirement in RFC8201 is =E2=80=9Cshould=E2=80=9D implement PMTUD. = This doc should say that. > > 4.1. The Truncation Eligible Option, I didn=E2=80=99t understand why: > > IPv6 packets that include the Fragment header MUST NOT include the > Truncation Eligible option.=E2=80=9D > > Please explain the need for this. > > 4.2. The Truncated Packet Option: > > NOTE 2: According to [RFC8200], the third-highest-order bit (i.e., > the "chg" bit) of the Option Type specifies whether Option Data of > that option can change on route to the packet's destination. Because > this option contains no Option Data, IANA can assign this Option Type > without regard to the "chg" bit. > > I don=E2=80=99t think this work for an IANA assignment, it has to be zero= or one. I think you want it specified as unchangeable. > > 5. Reference Topology > > The figure in this section looks to be two wide to fit on a page. Needs = to be fixed. > > 6. Truncation Procedures > > Subsequently, the same upper-layer protocol on the Source Node causes > the IP layer to emit another packet. This packet is identical to the > first, except that the total packet length is 2000 bytes. Because > the packet length is greater than the actual PMTU, this packet cannot > be delivered without encountering an MTU issue. > > I found this confusing. The packet isn=E2=80=99t identical, as it (as st= ated) has a different length, and I would assume different data in it. I = don=E2=80=99t understand this text, please clarify. > > The IP layer on the source node forwards the packet to Router 1. > Router 1 forwards the packet to Router 2, but the Router 2 cannot > forward the packet because its length exceeds the MTU of the next > link in the path (i.e., 1500 bytes). Because an MTU issue has been > encountered, Router 2 examines the Destination Options header, > searching for either a Truncation Eligible option or a Truncated > Packet option. (Normally, the Router 2 would ignore the Destination > Options header). > > Is this going to happen in the fast path of a router? Please explain. > > 7. Additional Truncation Considerations > > A truncated packet MUST contain the basic IPv6 header, all extension > headers and the first upper-layer header. When an intermediate node > cannot forward a packet due to MTU issues, and the total length of > the basic IPv6 header, all extension headers, and first upper-layer > header exceeds the MTU of the next link in the path, the intermediate > node MUST discard the packet and send and ICMP PTB message to the > source node. It MUST NOT truncate the packet. > > I assume this is for a case with, for example, early link of 9000 getting= to a smaller link. Seems pretty unlikely to happen in practice that the = headers wouldn=E2=80=99t fit in the packet. Even a 1500 byte packet. > > 9. Checksum Considerations > > When an intermediate node truncates a packet, it SHOULD update the > upper-layer checksum, if possible. This is desirable because it > increases the probability that the truncated packet will be delivered > to the destination node. > > Saying SHOULD and using a modifier =E2=80=9Cif possible=E2=80=9D is odd. = It should either be a SHOULD or MAY. > > Middleboxes residing downstream of the intermediate node may attempt > to validate the upper-layer checksum. If validation fails, they may > discard the packet without sending an ICMP message. > > The doc needs to show some analysis that routers that look at destination= headers and validate transport checksums will pass these packets with or w= ithout checksum recalculation. The Checksum part of this proposal seems p= roblematic to me. It=E2=80=99s a lot of work for the router having to do = the checksum recalculation and it=E2=80=99s not clear if these truncated pa= ckets will make it to the destination host. Not only that, after truncation the transport packet is corrupted. Fixing up the checksum to hide that corruption just so that the packet more deliverable is not correct and possibly dangerous. It is conceivable that some device somewhere might try to process the transport packet without regard to the extension headers. Be conservative in what you send... Tom > > 10. Invalid Packet Types > > This would get a lot simpler if there is only one option. > > o Send an ICMP Parameter Problem, Code 2, message to the packet's > Source Address, pointing to the first invalid option. > > This needs text to say to not send too many of these. Otherwise it can b= e used as an attack. > > 13. Extension Header Considerations > > The Hop-by-hop option can be examined by each node along the path to > a packet's destination. Destination options are examined by the > destination node only. However, [RFC2473] provides a precedent for > intermediate nodes examining the Destination options on an exception > basis. (See the Tunnel Encapsulation Limit.) > > That=E2=80=99s a very creative interpretation of RFC2473. RFC2473 is di= scussing tunnel end points, effectively they are the source and destination= of the tunneled packet. That very different from what is propose in this= document. I don=E2=80=99t think RFC2473 can be used to justify this. > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Nov 3 12:59:56 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A469D12872C for ; Sat, 3 Nov 2018 12:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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=plonka-us.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 QtCF5wfmxv96 for ; Sat, 3 Nov 2018 12:59:52 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 D996F1276D0 for <6man@ietf.org>; Sat, 3 Nov 2018 12:59:51 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id k9so4599971otl.10 for <6man@ietf.org>; Sat, 03 Nov 2018 12:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plonka-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xUtUyDb0BK+VnNV4FZBhgXOHlkCUNoA6Zu5U0ce5/oQ=; b=We9YgZqhzNOrIU4v2FjCkbtvoygq2WkQ0akQypvOZCfOYN7iZKEjwo68RBPpzjLCXC 8Zj65x21/aBFtl1o4pR7aFAE5CrjKgokPz057Ctv0munm3r/SxWQ24m8cCYy7PyHVQZd BoaXwx6DKMqQjdobijo+5XCF68lGDGMbvNvN1jb6i9FhegnAXdg3FPl7WQAYSikYtNqv pINTVn37s/rrH/rghjam1mrHj8tOuxmDln2Q7d/iknH8R6/fCVN31PTvSm8mXtfrd6cw j8J7a3QJQNHpfK1xlio3Byy2MHUsLDyo8sRY3ZHuJWF1fuuXSir80DaOQX6rT8+99UJA PAjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xUtUyDb0BK+VnNV4FZBhgXOHlkCUNoA6Zu5U0ce5/oQ=; b=D3rSMy8LLWAjA7mEdmjmhlDR5APpbW3+Bn5+1Gpxi5FScDsBF2woQ06Qrb04SfGuhE 6gfKIKQAhk6WO8udIIlkYXQz+VWil6AXrVE4LA2iofD3mNi2tpD7ECJDZHpEgKlcK0V1 /2fy8rsAZbcCvfk/dEe2BusIcGNgml5PRRK6+8GMz96P43K5eJVHeo3UGzIKxKRr1pMH 1U79aISigZKPBmc0bq31FZDyLepW01U+A3AoZYY/kD2BBVO0hYpUbcwknuKubTkCDS6Q 5QlfhORsZcxrzxD8TBbGEuln+KifDY8qp+/118aWuH/rsqYp07+9oiFiBup0didXz2bf 4fUg== X-Gm-Message-State: AGRZ1gIZ08tfXHqh7yJAUdc9f8hcqZIZxcM8RdPgC6MnzMW5WVmfwbfw cipVK4EzqYZSO2yQP4uPIvAAyi8/nKZba/I0uAZDKA== X-Google-Smtp-Source: AJdET5d6iYXylRdwnMJ1iJZTKSYzDE5UEZjS1soLWdf42VrHmnUE0UqwaHk0tEWDofp7sdAS1EVXFmCav9HYDf6rReY= X-Received: by 2002:a9d:60c2:: with SMTP id b2mr9142132otk.157.1541275191056; Sat, 03 Nov 2018 12:59:51 -0700 (PDT) MIME-Version: 1.0 References: <469F920C-974E-4DC6-AD8C-7931FDF71C6B@tik.ee.ethz.ch> <4724413F-DE32-4A41-9BD9-B880CD85FC29@tik.ee.ethz.ch> <8EAE1F42-2D56-4B36-B50D-A52B25ED36AF@gmail.com> In-Reply-To: <8EAE1F42-2D56-4B36-B50D-A52B25ED36AF@gmail.com> From: Dave Plonka Date: Sat, 3 Nov 2018 15:58:31 -0400 Message-ID: Subject: Re: [Int-area] maprg session on Tue Nov 6, 1610-1810 To: bob.hinden@gmail.com Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , 6man@ietf.org, int-area@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 19:59:55 -0000 Hi Bob, Tobias Fiebig and I proposed a 5 minute intro/heads-up about some work we're embarking on targeted for MAPRG, calling for participation and/or input from the community: We will write a draft on =E2=80=9CPrivacy & Security Issues in IPv6 Deployment=E2=80=9D that is a problem statement targeted to inform v6 IETF engineering and operations/BCP efforts, based on empirical measurements of IPv6 in operation today. Cases in point include address privacy, enumerating hosts using the reverse DNS, and IPv6 router addressing practices. For example, two recently published items of IPv6 measurement research (on IPv6 as deployed) - these will be linked in the MAPRG slides, and are merely examples of measuring existing deployment: Beverly et al. =E2=80=9CIn the IP of the Beholder: Strategies for Active IP= v6 Topology Discovery=E2=80=9D, ACM Internet Measurement Conference (IMC), Nov 2018 https://conferences.sigcomm.org/imc/2018/papers/imc18- final151.pdf Borgolte et al. =E2=80=9CEnumerating active IPv6 hosts for largescale secur= ity scans via DNSSEC-signed reverse zones=E2=80=9D, IEEE Symposium on Security and Privacy (Oakland), May 2018 https://homepage.tudelft.nl/2x09j/pdf/sp2018-dnssec-ipv6.pdf Thanks! Dave On Wed, Oct 31, 2018 at 12:16 PM Bob Hinden wrote: > > > > On Oct 31, 2018, at 9:08 AM, Mirja K=C3=BChlewind wrote: > > > > We don=E2=80=99t have one for this talk as it is only a 5 minutes heads= up talk. Maybe Dave can provide you some more information. Or you just com= e to the session=E2=80=A6 > > Or both :-) > > Bob > > > > > Thanks! > > Mirja > > > > > > > >> Am 31.10.2018 um 16:52 schrieb Bob Hinden : > >> > >> Mirja, > >> > >> I don=E2=80=99t see an abstract for "Privacy and Security Issues in IP= v6 Deployment=E2=80=9D talk on the agenda page you linked. Is that availab= le? > >> > >> Bob > >> > >>> On Oct 31, 2018, at 5:09 AM, Mirja K=C3=BChlewind wrote: > >>> > >>> Hi int floks, > >>> > >>> we will have a short heads-up talk on Privacy and Security Issues in = IPv6 Deployment. You might be aware of this work by Dave Plonka and Tobias = Fiebig already. However, maybe it is still interesting you for to join! > >>> > >>> Here is a link to the rest of the agenda: > >>> > >>> https://datatracker.ietf.org/meeting/103/materials/agenda-103-maprg-0= 3 > >>> > >>> The maprg session will take place on > >>> > >>> Tuesday, 6 November 2018, Afternoon Session II 1610-1810 > >>> Room Name: Chitlada 1 > >>> > >>> See you there! > >>> Mirja (maprg co-chair) > >>> _______________________________________________ > >>> Int-area mailing list > >>> Int-area@ietf.org > >>> https://www.ietf.org/mailman/listinfo/int-area > >> > > > --=20 dave@plonka.us http://www.cs.wisc.edu/~plonka/ From nobody Sat Nov 3 13:00:43 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B624128D0C for ; Sat, 3 Nov 2018 13:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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=plonka-us.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 tBCnI2iVuDEk for ; Sat, 3 Nov 2018 13:00:39 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 7092A12D4ED for ; Sat, 3 Nov 2018 13:00:38 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id f24so4632585otl.5 for ; Sat, 03 Nov 2018 13:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plonka-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=c4FKNH9PR4hNQe7chVoCpVnw5MtcO/vNROfA+uYu7hs=; b=V3dsufprgj9dkVfiX1FFbSbEBQw6XfOgPEVR8bUcv0laBUv0bU2BDF0+x75Due3CRa hPgMaN2Plv9SfzIyLaOruKlMq0SYW50a5we1dZVRNkWmfO0Djlave9uRVD83jsstNqMH onpNdro1FhdvGmfiOI2JsNTsYcGIswu5QxYIkuKxCxvyPiPWy1nyq/5/BrNliYxjGzTW HMrPxRpYrMyxjQngWfcw8Nga7HyMSOtCX4Me9zUNgRX56QpKaaJNkkTH/hMOXVVi8ZF2 5rNZUef/UVDucdZupHL0WK+fkxeIYvCGoLFMk3+xKfz3TnoG2LCwGH0TnbkqOUxhYZYP cs5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=c4FKNH9PR4hNQe7chVoCpVnw5MtcO/vNROfA+uYu7hs=; b=reUo6oeD53ZXZPDbkffnRyfcyDEdqBs/96lnxTyUDnycfCHZP54iyAElqGO3X4d7Fr gOOGqYM6OqeAWiplOKiBWGejwzEW74EQoTQ7vbymsfnQIL7lh8+kHD8N5r0G1PwVuU9K XuebW+PQgijyLjXMCrZHV3oYRxAERqZk2wRdDRep8oBPAByGECQmf/3II2jY0HND9a9W P6aqaQj7qmOwsTOZSCpEUbFVkGXzkTU+00HUok5XczGYL4mzFEGmVn25DuW0rb/6mqun 77AwYDMq/EgrICW6UJqWuvIHpoNgNuZ5WWsGzTtX5+qc6aHbZKNxr4F7igFsXKqEEytO ZDKQ== X-Gm-Message-State: AGRZ1gJXqeU8Mdodd2RkanciUcv2jgW5BW3iCLfAbIWRzlAYe36ppPH3 HbZhX0uZEt7g9DqOaUzKDOJTZUl4AElc9RR4EwV7wHA0RSY= X-Google-Smtp-Source: AJdET5fHlrj8FZLOOve1OmBTJqjUc3dR2OnUX4bVDva1nI2aThbVwZIlimUKt4Oe4gwsBx22Vxx886RM0JqU5A8Y2ZM= X-Received: by 2002:a9d:191f:: with SMTP id j31mr9578515ota.76.1541275237748; Sat, 03 Nov 2018 13:00:37 -0700 (PDT) MIME-Version: 1.0 References: <469F920C-974E-4DC6-AD8C-7931FDF71C6B@tik.ee.ethz.ch> <4724413F-DE32-4A41-9BD9-B880CD85FC29@tik.ee.ethz.ch> <6bfe27b6-6833-5fcd-b8cf-5f77ac94af0f@asgard.org> In-Reply-To: <6bfe27b6-6833-5fcd-b8cf-5f77ac94af0f@asgard.org> From: Dave Plonka Date: Sat, 3 Nov 2018 15:59:18 -0400 Message-ID: Subject: Re: [Int-area] maprg session on Tue Nov 6, 1610-1810 To: Lee Howard Cc: ipv6@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 20:00:42 -0000 Hi Lee, Tobias Fiebig and I proposed a 5 minute intro/heads-up about some work we're embarking on targeted for MAPRG, calling for participation and/or input from the community: We will write a draft on =E2=80=9CPrivacy & Security Issues in IPv6 Deployment=E2=80=9D that is a problem statement targeted to inform v6 IETF engineering and operations/BCP efforts, based on empirical measurements of IPv6 in operation today. Cases in point include address privacy, enumerating hosts using the reverse DNS, and IPv6 router addressing practices. For example, two recently published items of IPv6 measurement research (on IPv6 as deployed) - these will be linked in the MAPRG slides, and are merely examples of measuring existing deployment: Beverly et al. =E2=80=9CIn the IP of the Beholder: Strategies for Active IP= v6 Topology Discovery=E2=80=9D, ACM Internet Measurement Conference (IMC), Nov 2018 https://conferences.sigcomm.org/imc/2018/papers/imc18- final151.pdf Borgolte et al. =E2=80=9CEnumerating active IPv6 hosts for largescale secur= ity scans via DNSSEC-signed reverse zones=E2=80=9D, IEEE Symposium on Security and Privacy (Oakland), May 2018 https://homepage.tudelft.nl/2x09j/pdf/sp2018-dnssec-ipv6.pdf Thanks! Dave On Fri, Nov 2, 2018 at 5:19 AM Lee Howard wrote: > > I can't come to the session since I won't be in Bangkok. RGs don't > usually put out notes. The meeting will be at 3:00am in my time zone, > and I'm unlikely to get up at that hour for a 5-minute talk. > > Can I get a hint about what the privacy and security issues are? > > Thanks, > > Lee > > On 10/31/18 9:38 PM, Mirja K=C3=BChlewind wrote: > > We don=E2=80=99t have one for this talk as it is only a 5 minutes heads= up talk. Maybe Dave can provide you some more information. Or you just com= e to the session=E2=80=A6 > > > > Thanks! > > Mirja > > > > > > > >> Am 31.10.2018 um 16:52 schrieb Bob Hinden : > >> > >> Mirja, > >> > >> I don=E2=80=99t see an abstract for "Privacy and Security Issues in IP= v6 Deployment=E2=80=9D talk on the agenda page you linked. Is that availab= le? > >> > >> Bob > >> > >>> On Oct 31, 2018, at 5:09 AM, Mirja K=C3=BChlewind wrote: > >>> > >>> Hi int floks, > >>> > >>> we will have a short heads-up talk on Privacy and Security Issues in = IPv6 Deployment. You might be aware of this work by Dave Plonka and Tobias = Fiebig already. However, maybe it is still interesting you for to join! > >>> > >>> Here is a link to the rest of the agenda: > >>> > >>> https://datatracker.ietf.org/meeting/103/materials/agenda-103-maprg= -03 > >>> > >>> The maprg session will take place on > >>> > >>> Tuesday, 6 November 2018, Afternoon Session II 1610-1810 > >>> Room Name: Chitlada 1 > >>> > >>> See you there! > >>> Mirja (maprg co-chair) > >>> _______________________________________________ > >>> Int-area mailing list > >>> Int-area@ietf.org > >>> https://www.ietf.org/mailman/listinfo/int-area > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 dave@plonka.us http://www.cs.wisc.edu/~plonka/ From nobody Sat Nov 3 14:15:50 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057E6128766 for ; Sat, 3 Nov 2018 14:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 sB5OEeuqfWhU for ; Sat, 3 Nov 2018 14:15:46 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 ED20A126DBF for ; Sat, 3 Nov 2018 14:15:45 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id g7-v6so321841pfo.10 for ; Sat, 03 Nov 2018 14:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=7r7muLRXxyWuzyJiAZe3WBOTsN+YjHWcPSvyL31gzgE=; b=jpVn2rQFehA++dLRuMayD3GxsWtEeRV3k9M1I/Pacd3VsNzDvhc1Abm3Ebu6JMo/bn vefo4PICwL1k04POcggM3dapXPe7sChCNWx3LA9UO1nBB9MoZ6dmFXT2o/3+TRpUjk/b KhwLKD+qqe5EYRyrfPWNmn0W92s67c4LBibDMH+Z8EhyzCOrKlOvfobjT96HTE3sBLR2 c9PgNsB1Q8BzlSFQ36nDdFAiyUXP0pmqGZj6y/S3JhcRJrRC2A6Fk0arm2DPMxMoCFUh SGcByFemotcZbQmJsNTwJC3S5TRXnP2Wr9odbNpwfUMTrqAo+AOx4+AlNYVWUcAjkr3o lGdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7r7muLRXxyWuzyJiAZe3WBOTsN+YjHWcPSvyL31gzgE=; b=JjiPbwtcu+YpLKz+JQWyAfdnQDM4uK346+kH8PG6ZQ2j7TaGK20NnoP2M5WNWAb7xE 6pIAkGpGNaAYUrshMczvrJEV0AewZ9mBYi/Safw6oYp2sz2omtdNAUjrF5/xfdPiVd98 twz5npp8EME4jhMYZ0Yn11MUWKdIxuWJ7Ol8H3Fw4nL097S+DZtL4SRnyDs9nF1naXsH 29T+0P2kAG+WRJamQnQ1yXPcz5ZCkVd53e5aKS1/2rE+Lti6c9xJa4Az3oqIjcYS0aUi 4vkEY39PCYVi7utNZURrD/5MjOGc1Kk3ZHFzGUCNIudrDjZGFXW3PmueJAW4ljc7aUO1 LB+w== X-Gm-Message-State: AGRZ1gKZBvL8FJ2EWuqrevrysfJCEWZAANUjyhZ4DQqnMWJZ1tPtrSjJ YQb13aHQ4LwaWgEmS16HWcQU2NMs X-Google-Smtp-Source: AJdET5f9iqzPSmLVFDelA9lGLa+xDG+GZFcVG4cnriBQ5+Ex72SWFuUIPtSZs6q/PKpTWYQzvVEWpQ== X-Received: by 2002:a63:6643:: with SMTP id a64-v6mr12324277pgc.15.1541279745048; Sat, 03 Nov 2018 14:15:45 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id 11-v6sm40076587pfr.55.2018.11.03.14.15.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Nov 2018 14:15:44 -0700 (PDT) Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Lee Howard , ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> From: Brian E Carpenter Message-ID: Date: Sun, 4 Nov 2018 10:15:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 21:15:48 -0000 On 2018-11-04 00:35, Lee Howard wrote: > Sorry, I didn't trim because I think it's all context... >=20 > On 11/3/18 12:50 AM, Brian E Carpenter wrote: >> On 2018-11-02 19:09, Lee Howard wrote: >>> On 11/1/18 1:13 AM, Brian E Carpenter wrote: >>>> On 2018-10-31 22:24, Nick Hilliard wrote: >>>>> Job Snijders wrote on 30/10/2018 22:27: >>>>>> Can you (or others running FreeBSD EXPERIMENTAL) share reports on = how >>>>>> this pans out in practise? >>>>> Looking at the code, it acts by blocking outbound ipv4 frames from = being >>>>> transmitted on ethernet interfaces. This would mean - for example = - >>>>> that if there were a default route already configured on the receiv= ing >>>>> device, any userland code attempting to use ipv4 services would blo= ck >>>>> until ARP times out for the default route (default 20 minutes on fr= eebsd). >>>>> >>>>> The only part of the ipv6only discussion that was uncontroversial w= as >>>>> implementation of the kernel processing side of this flag - there's= very >>>>> little to go wrong when toggling a single flag. >>>>> >>>>> The problem area is how to handle the interpretation of this flag i= n >>>>> userland and in the kernel, which is a much more difficult problem.= >>>> It's a question, but I don't know why it's a problem. It isn't an in= terop >>>> problem, because each host is an independent actor in this. And we n= ow have >>>> running code proof that legacy hosts aren't affected. So I'd say tha= t from >>>> a protocol spec point of view, it's actually a non-issue. >>> Doesn't it mean that user space applications on a host that had/expec= ted >>> IPv4 would fail? >> Well yes, but that is presumably the network administrator's intention= , >> so I'm not sure I'd characterise it as am interop issue exactly, and i= t's >> not an interop issues *involving the RA message itself*. >> =20 >>> I think I described my interop concern: >>> https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=3Dm&so=3Dfrm >>> >>> IPv4-only hosts, and dual-stack hosts >>> that do not recognize the new >>> =C2=A0=C2=A0 flag, may continue to attempt IPv4 operations >>> >>> If some devices require IPv4 and others disable IPv4, you have lost >>> connectivity between systems on a local network. As written, this is = not >>> considered a misconfiguration by the administrator who sets the flag.= >> Indeed not. The admin will presumably be happy at this result. >> I don't think we disagree about the effect, just about whether >> it's desirable. >> >>>>> This also disregards the issue of whether the flag was either neces= sary >>>>> or a good idea to start with, and nearly 700 emails into this >>>>> discussion, the WG seems to be hopelessly divided on these issues. >>>> I'll leave that one to the WG chair who isn't a co-author. But I wil= l >>>> say that in my mind the issue is whether the feature is one that wil= l >>>> be valuable in 5, 10 or 20 years time rather than whether it's valua= ble >>>> today. >>> I've come into the camp that believes that in 10 or 20 years IPv4 wil= l >>> be disabled by default. When people post to stackoverflow complaining= >>> that their 10-20 year old devices are unreachable from their brand ne= w >>> devices, the response will be, "The old stuff might be using the old >>> protocol, IPv4. Go into Control Panel, Networking, Protocols, select >>> IPv4, click enable." >>> >>> If that's likely, then this flag is only useful in the interim 5 year= s. >>> During that time, I would like to maximize connectivity. >>> >>> If a network administrator wants central control over IPv4/IPv6 >>> enablement in hosts, there are better, more centralized tools for tha= t. >>> As a principle, host behavior should be managed by host management >>> tools, and not by hints from a router. >> I'm not sure how that can work on a BYOD network. On a fully managed n= etwork, >> sure, we could "easily" invent a solution. >=20 > Taken all-in-all, then, the use case for this flag is a network where=20 > the administrator: >=20 > 1. does not know what's on the network, May not know what's on the link, or does not have management access to some devices on the link, or does not have policy control over some devices on the link. There are many such networks. > 2. expects that there are some applications using IPv4, I don't see that. The admin has decided that there are no IPv4 services on the link - presumably no DHCPv4, no DNS over IPv4, no IPv4 routing. Whether or not some hosts contain IPv4 applications isn't necessarily known to the admin. > 3. understands that IPv4 will continue to work locally, 3b. except for = > dual-stack hosts that honor the flag, It might be fairer to say that the admin doesn't care whether IPv4 works locally, but has decided to announce to everybody that there are no IPv4 services on the link, knowing that only 3b hosts will understand the announcement. (The fact that RAs are universal, whereas other possible mechanisms such as DHCPv6 or NETCONF are not, is relevant here.) > 4. understands that applications may have already negotiated IPv4=20 > connectivity, Again - doesn't care. > 5. desires to break communications for 3b and 4,=20 Again - doesn't care. > and prevent IPv4=20 > Internet access. Yes, that's the primary decision. Of course, the assumption is that IPv6-only access to the Internet is necessary and sufficient. > It's not just that administrator accepts that 3b and 4 won't work, but = > as you said above, "The admin will presumably be happy with this result= =2E" Or doesn't care. > This seems to me a very narrow application. It's certainly directed at a specific (and future) phase of history, when= IPv6-only is viable and IPv4 has not yet faded into oblivion. How many links for how many years would be in that phase is an open question. As the draft recognizes, there are other mechanisms available too. What strikes me as unique about this mechanism is simply that *every* dual stack host receives and understands RAs; this is our only way of getting a bit to every single dual stack device. That's not narrow, IMHO. Brian From nobody Sat Nov 3 15:05:27 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FEB128C65 for ; Sat, 3 Nov 2018 15:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 9fqzHa_akW2j for ; Sat, 3 Nov 2018 15:05:23 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 0324B128766 for ; Sat, 3 Nov 2018 15:05:23 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id b9-v6so2608858pls.7 for ; Sat, 03 Nov 2018 15:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=sIe8TUqlBd7Lxk7lbIRg64XBM/fl6AzWgjv8vzqHNu4=; b=a8asm+hasnwnu93+Zvfc+DTqzDzExQQB6d6ale2MAkEaAd6p/ZIAAHfjWn+AUs/up8 LHLjNF0WF+l6IRXHWTImz/RtQoDv8QrqeKTOWSBvAdO6QyackSsExgx4OnN7a53lOVeJ VdwYbp+qRvwgShzdQXgONW1Up/IMQco0XkkuuXjAvNMF9mBygQmOrnVc0T5sKkJdaPEk G/AwsTqHROFB/x1SjUkU0gQz2Io2JnKBoan5qh+K3EiZne5N3agDj6oCCLQwFqzFcDVt w7gx1TLbShOs1KQOq/fqXkCtkOrydAZtCLFOTcDewyQIDRmVw14jXP94g/gHc/9LU1DL MhpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sIe8TUqlBd7Lxk7lbIRg64XBM/fl6AzWgjv8vzqHNu4=; b=D38oacHtBuFNc/5tgdrYNvRgec45xv8b7F559+qqk1uKqnAq3N1+qX34xu3YBVBBHp kJPHca0jFuI7TcR+kY8gsLajb8muHXQ+wJKWF2MhEYqocRgGXLZ5xf8tq5R85G4MEJt7 zt4oHDkAD0xoZ6QclvXrdjsLdG/8bJXAokKOkxZK+Alz9gIDgycQE/iFymVHtUmyz3go qu8epSqLxyOOhSo/YJUNsDtjgv5Tlmdqa3EWjl9ni4j21iGbAE6LFedYJnH6LPnsmaom nk+AtfkNkCVfFgyhT9boTPCMpsL7pVNbyDIkviVaqfPHndwQhZZvGbTekVjD4vcCagbY VxiQ== X-Gm-Message-State: AGRZ1gJYdNC0iHUXVwbOxgFYW3CITaUoiN6sYwHXo31awk2ulGgs6OBD O6Yn4l34ytEZsoG4UKOBj2WeU4Sl X-Google-Smtp-Source: AJdET5fJ06gjaui1t31+Xhj9diFjTiAhHyfFTU7qFyn/qGCEIQy5+liiZH3XiOBVOr5CHHacSo90QQ== X-Received: by 2002:a17:902:107:: with SMTP id 7-v6mr16815791plb.267.1541282722132; Sat, 03 Nov 2018 15:05:22 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id x13-v6sm79664601pge.13.2018.11.03.15.05.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Nov 2018 15:05:21 -0700 (PDT) Subject: Re: review of draft-ietf-6man-ipv6only-flag To: Lee Howard , ipv6@ietf.org References: <644c97f9-d92e-85b0-6a22-d980dd094fdf@asgard.org> From: Brian E Carpenter Message-ID: <7f68a211-5458-0139-9235-c243d71c2085@gmail.com> Date: Sun, 4 Nov 2018 11:05:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <644c97f9-d92e-85b0-6a22-d980dd094fdf@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 22:05:25 -0000 Finally getting to this message... On 2018-10-21 04:41, Lee Howard wrote: > Notes. . . >=20 > 1. Introduction >=20 > "The flag does not apply to o non-default IPv6 routers." The double neg= ative > is a bit awkward, and might be clearer as "The flag only applies to def= ault > routers." Ack >=20 > "That is, a link where there are no IPv4 routers and/or IPv4 services."= > Sentence fragment. Good device, that. Will be used more later. Ack. If we miss any, the RFC Editor would catch them. >=20 > Typo: 0x806 should be 0x0806 (ARP)=C2=A0 /g Ack. =20 > A version number is specified for Windows and no other OS; probably > unnecessary. Hmm. My observation is that the Windows default settings have evolved quite a bit; probably what we say is true of all Windows since #7, but having recently switched from 7 to 10 I've noticed subtle differences= =2E So my inclination is to stick to "Windows 10" to be sure we're accurate. > I agree that every general-compute OS supports dual-stack, but I'm not = sure > that most printers do, and I know that very few embedded OS devices (Io= T, > TVs, game consoles, etc.) do. s/printers/some printers/ >=20 > "Such traffic may drain battery power on wireless hosts that have no=20 > interest > in link-local IPv4" > Sounds like what you need there is a L2 message to the switch saying,=20 > "No IPv4 > here, thanks" Yes, as discussed later, L2 filtering has its place, but it doesn't stop hosts from trying IPv4. >=20 > "In managed networks..." > Well, managed networks generally have managed devices, on which IPv4=20 > could be > disabled by managers using whatever management tools they use to manage= > devices. Right, but we're distinguishing between managed *infrastructure* and mana= ged hosts. Needs a wording tweak or two. > Do all networks use ethertypes? Pass =20 > "this is an IPv6-Only link" > I've lost track of previous discussion of this draft; does the IPv6-onl= y=20 > flag > mean the router has no IPv6 on any other link, and therefore won't=20 > forward, or > that the local link has no IPv4-dependent hosts or services? It sounds = like > that latter, which may be a lot for a layer 3 router to assert about a = > layer > 2 domain. In other words, does it mean "I am an IPv6-only router" or "t= he > link on which this IPv6 multicast message is received has no IPv4"? It means "I, the administrator, assert that there's no IPv4 service of any kind on this interface to this link" (and of course it's only effective if all IPv6 default routers make the same assertion). I think that's unambiguous in the draft. > For a VLAN, IPv4 would only be disabled on VLANs on which the option wa= s > received, not every VLAN on the physical port? Good point. We need to clarify this. >=20 > Thinking about several objections I've seen, maybe it would make sense = to > consolidate the preferred mechanisms for disabling IPv4, rather than ha= ving > them spread throughout the introduction: > * Filter Ethertypes 0x0800 and 0x0806 > * Disable IPv4 on hosts You can't do that if the hosts are not managed (regardless of whether the network infrastructure is managed). > * Run a DHCP server that sends the DHCP option to disable IPv4 stateles= s > =C2=A0 auto-configuration [RFC2563] We are trying to make the text flow better in each version. > 3. Applicability Statements > "Dual stack hosts that have a good reason to use IPv4, for example for > =C2=A0=C2=A0 a specific IPv4 link-local service, can attempt to do so.= =C2=A0 " > Does that mean a service the host advertises over IPv4, or one that the= > host has seen advertisements for? If the host respects the flag, the it= > would not see future IPv4 LL advertisements, of course. >=20 > "Administrators SHOULD only use this mechanism if they are certain > =C2=A0=C2=A0 that the link is IPv6-Only." > That sounds like a MUST to me. If you do this when you are not sure > there is no IPv4, or when there is a need to use IPv4, you are breaking= > interoperability. If there are "valid reasons in particular circumstanc= es > to ignore" it, it's a SHOULD. There are no valid reasons to disable IPv= 4 > is IPv4 is still needed. I think you're right. > 4. IPv6-Only Definition > "beyond the scope of this document" > I think it's worth saying that a host that is capable of doing IPv4-IPv= 6 > translation (for instance, CLAT) or tunneling, in support of IPv4 > connectivity, SHOULD NOT disable its transition mechanism(s), but shoul= d > only send IPv6 on the local link. The IPv6 on the local link might incl= ude > tunneled or translated IPv4. I really think the text directly implies that. > "IPv6-Only provides no information about other network > =C2=A0=C2=A0 protocols than IP running directly over the link layer" > Well, earlier you suggested blocking Ethertype 0x0806 (ARP), and blocki= ng > ARP is one of the justifications for the flag. Later you're explicit ab= out > it. Yes, clearly ARP is included. > It might also be useful if it was used to block service advertisements > for IPv4 addresses. Sorry, what do you mean? >=20 > 5. IPv6-Only Flag > Again I think the SHOULDs are probably MUSTs, unless someone can give a= > reason it wouldn't be. Well, here we definitely intend SHOULD because it seems certain that some= host scenarios will vary from the norm. >=20 > 6. Router and Operational Considerations > "on an IPv6-Only link SHOULD" > I think this should is a MAY, since right at the beginning you said thi= s > flag was OPTIONAL. It's arguable. IMHO that OPTIONAL is generic - all IETF standards are optional, ultimately. But operationally, a SHOULD makes sense to me. =20 > However, I am very concerned about the use of MAY and OPTIONAL here; > RFC2119 says: > =C2=A0=C2=A0 An implementation which does not include a particular opt= ion MUST be > =C2=A0=C2=A0 prepared to interoperate with another implementation whic= h does > =C2=A0=C2=A0 include the option, though perhaps with reduced functiona= lity. In the > =C2=A0=C2=A0 same vein an implementation which does include a particul= ar option > =C2=A0=C2=A0 MUST be prepared to interoperate with another implementat= ion which > =C2=A0=C2=A0 does not include the option > I don't know how devices that do turn off IPv4 interoperate with dual-s= tack > devices that don't turn it off. If the dual stack devices try both v4 and v6, what's the problem? If they don't and the admin has decided to only support v6, why would the admin care? >=20 > typo: "routers interface" should be "router's interface" > For that matter, since earlier in the document it says: > =C2=A0=C2=A0 when there are intended to be IPv4-only > =C2=A0=C2=A0 hosts or IPv4 routers on the link, setting this flag to 1= is a > =C2=A0=C2=A0 configuration error. > Then instead of "MAY log a configuration error" I'd prefer: > =C2=A0 It is RECOMMENDED that routers report an error if the flag is s= et... Agreed. > 7. Host Behavior Considerations > "the flag with value 0, a dual stack host SHOULD NOT assume that > =C2=A0=C2=A0 the link is IPv6-Only." > I think that's a MUST NOT. But it could be, "MUST NOT unless the host h= as > been otherwise configured for IPv6-only." That could be interpreted as = a > SHOULD, but that's why I like qualifying SHOULDs. Agreed. > "at start-up" does this include "wake-up"? Or connection to a new netwo= rk? > Could be awkward for mobility. Ack > "have the flag set" means "set to 1" and not "set to 0"=C2=A0 /g Ack > "choose to" Do hosts make choices? Sounds anthropomorphic. My laptop certainly has a will of its own at times ;-) =20 > I hope this is useful. Yes, definitely, sorry it took some time to process. Regards Brian From nobody Sat Nov 3 16:15:53 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF7F129C6B for ; Sat, 3 Nov 2018 16:15:51 -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, 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 VI0w4pZ7pQmS for ; Sat, 3 Nov 2018 16:15:49 -0700 (PDT) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B92128766 for ; Sat, 3 Nov 2018 16:15:49 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 0A7708D4A216; Sat, 3 Nov 2018 23:15:46 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 997DED1F985; Sat, 3 Nov 2018 23:15:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id kY1AhnWVyf_0; Sat, 3 Nov 2018 23:15:43 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C2DB5D1F984; Sat, 3 Nov 2018 23:15:41 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Brian E Carpenter" Cc: "Lee Howard" , ipv6@ietf.org Subject: Re: review of draft-ietf-6man-ipv6only-flag Date: Sat, 03 Nov 2018 23:15:40 +0000 X-Mailer: MailMate (2.0BETAr6125) Message-ID: <3D8A98DF-D837-4EBE-BD4B-6B1513760878@lists.zabbadoz.net> In-Reply-To: <7f68a211-5458-0139-9235-c243d71c2085@gmail.com> References: <644c97f9-d92e-85b0-6a22-d980dd094fdf@asgard.org> <7f68a211-5458-0139-9235-c243d71c2085@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 23:15:52 -0000 On 3 Nov 2018, at 22:05, Brian E Carpenter wrote: >> Do all networks use ethertypes? > > Pass No, think of PPP. There you just don’t negotiate IPCP (or you do) depending on whether you are IPv6-Only or not. Just an example. >> For a VLAN, IPv4 would only be disabled on VLANs on which the option >> was >> received, not every VLAN on the physical port? > > Good point. We need to clarify this. If this is for L2/switch filtering, then yes, you might want to. Otherwise, you don’t as we are talking IPv6 and not 0x8100 or 0x88A8 (staying with ethertypes as that’s where VLANs are). Likewise you’d not filter it on an ATM link but on a VC/VP there. Be careful to not over-specify things. >> 3. Applicability Statements >> "Dual stack hosts that have a good reason to use IPv4, for example >> for >>    a specific IPv4 link-local service, can attempt to do so.  " >> Does that mean a service the host advertises over IPv4, or one that >> the >> host has seen advertisements for? If the host respects the flag, the >> it >> would not see future IPv4 LL advertisements, of course. >> >> "Administrators SHOULD only use this mechanism if they are certain >>    that the link is IPv6-Only." >> That sounds like a MUST to me. If you do this when you are not sure >> there is no IPv4, or when there is a need to use IPv4, you are >> breaking >> interoperability. If there are "valid reasons in particular >> circumstances >> to ignore" it, it's a SHOULD. There are no valid reasons to disable >> IPv4 >> is IPv4 is still needed. > > I think you're right. There could possibly be IPv4 left and you want to make it shut up and see what happens. We are allowed to break things (on purpose). As the draft also says “A possible subsidiary use of the IPv6-Only flag is using it to trigger IPv6-Only testing and validation on a link.” SHOULD. >> typo: "routers interface" should be "router's interface" >> For that matter, since earlier in the document it says: >>    when there are intended to be IPv4-only >>    hosts or IPv4 routers on the link, setting this flag to 1 is a >>    configuration error. >> Then instead of "MAY log a configuration error" I'd prefer: >>   It is RECOMMENDED that routers report an error if the flag is >> set... > > Agreed. As in the above example I can see cases where you want to turn the flag on and yet still have IPv4 on the link (yes, contrary to the draft), to not break IPv4-only or dual-stack hosts which do not understand/respect the flag, yet to see how much IPv4 you can get rid off which is actually no longer needed; that can be a very helpful “transition” phase for a network admin to narrow the remaining IPv4 down as well. Whether this is a configuration error in that case is questionable, certainly the link is not expected to be IPv6-only (yet) but could be that in a week it will be should there be no more IPv4 traffic. There’s just so many more use-cases beyond what the draft tries to accomplish as the “end-goal”. >> 7. Host Behavior Considerations >> "the flag with value 0, a dual stack host SHOULD NOT assume that >>    the link is IPv6-Only." >> I think that's a MUST NOT. But it could be, "MUST NOT unless the host >> has >> been otherwise configured for IPv6-only." That could be interpreted >> as a >> SHOULD, but that's why I like qualifying SHOULDs. > > Agreed. >> "at start-up" does this include "wake-up"? Or connection to a new >> network? >> Could be awkward for mobility. > > Ack Good point. “When attaching to a link a host MAY delay all IPv4 operations on that link until a ..” From nobody Sat Nov 3 23:13:42 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFD7130DEC; Sat, 3 Nov 2018 23:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 9OvjPeTHPaRD; Sat, 3 Nov 2018 23:13:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 45D46130DE5; Sat, 3 Nov 2018 23:13:35 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 2E7D6D9574455; Sun, 4 Nov 2018 06:13:32 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 4 Nov 2018 06:13:32 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.103]) by SJCEML703-CHM.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0415.000; Sat, 3 Nov 2018 23:13:30 -0700 From: Linda Dunbar To: tom petch , Joel Jaeggli , "idr@ietf.org" CC: "ipv6@ietf.org" , "int-area@ietf.org" Subject: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AdR0BGE++Z0BF4I3RCC8M7+3nc3iHQ== Date: Sun, 4 Nov 2018 06:13:29 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.170.160] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B18249Esjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 06:13:40 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B18249Esjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFyLWlkci1iZ3Atc2R3 YW4tb3ZlcmxheS1leHQvICBzcGVjaWZpZXMgYSBuZXcgQkdQIFNBRkkgKD03NCkgaW4gb3JkZXIg dG8gYWR2ZXJ0aXNlIGEgU0QtV0FOIGVkZ2Ugbm9kZeKAmXMgY2FwYWJpbGl0aWVzIGluIGVzdGFi bGlzaGluZyBTRC1XQU4gb3ZlcmxheSB0dW5uZWxzIHdpdGggb3RoZXIgU0QtV0FOIG5vZGVzIHRo cm91Z2ggdGhpcmQgcGFydHkgdW50cnVzdGVkIG5ldHdvcmtzLg0KDQpTaW5jZSBhIFNELVdBTiBl bmQgcG9pbnQgbWlnaHQgdXNlIElQdjYgcHJpdmF0ZSBhZGRyZXNzLCB3aGljaCBpcyB0cmFuc2xh dGVkIHRvIElQdjQgcHVibGljIGFkZHJlc3MgdmlhIE5BVCwgIHdhbnQgdG8gZ2V0IElQdjYgZ3Jv dXAgJiBJbnRlciBBcmVhIFdHIGZlZWRiYWNrIG9uIHRoZSBzdWJUTFYgcHJvcG9zZWQgaW4gdGhl IGRyYWZ0Og0KDQpFbmNhcHNFeHQgc3ViLVRMViBpcyBmb3IgZGVzY3JpYmluZyBhZGRpdGlvbmFs IGluZm9ybWF0aW9uIGFib3V0IHRoZSBTRC1XQU4gdHVubmVsIGVuZC1wb2ludHMsIHN1Y2ggYXMg TkFUIHByb3BlcnR5LiBBIFNELVdBTiBlZGdlIG5vZGUgY2FuIGlucXVpcmUgU1RVTiAoU2Vzc2lv biBUcmF2ZXJzYWwgb2YgVURQIFRocm91Z2ggTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9uIFJG QyAzNDg5KSBTZXJ2ZXIgdG8gZ2V0IHRoZSBOQVQgcHJvcGVydHksIHRoZSBwdWJsaWMgSVAgYWRk cmVzcyBhbmQgdGhlIFB1YmxpYyBQb3J0IG51bWJlciB0byBwYXNzIHRvIHBlZXJzLg0KDQogICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfEVuY2FwRXh0IFR5cGUgIHwgIEVuY2FwRXh0IHN1 YlRMViBMZW5ndGggICAgICAgfEl8T3xSfFJ8UnxSfFJ8UnwNCiAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIHwg TkFUIFR5cGUgICAgICB8ICBFbmNhcC1UeXBlICAgfFRyYW5zIG5ldHdvcmtJRHwgICAgIFJEIElE ICAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAgICAgICAgIFByaXZhdGUgIElQIEFk ZHJlc3MgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgMzItYml0cyBm b3IgSVB2NCwgMTI4LWJpdHMgZm9yIElwdjYNCiAgICAgICAgICAgICAgICAgICAgfn5+fn5+fn5+ fn5+DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAgICAgICAgIFByaXZhdGUgIFBvcnQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfCAgICAg ICAgICAgICAgICBQdWJsaWMgSVAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgIDMyLWJpdHMgZm9yIElQdjQsIDEyOC1iaXRzIGZvciBJcHY2DQogICAg ICAgICAgICAgICAgICAgIH5+fn5+fn5+fn5+fg0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfCAgICAgICAg ICAgICAgICBQdWJsaWMgUG9ydCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQpXaGVyZToNCm8gICAgICAgRW5jYXBFeHQgVHlwZTogaW5kaWNhdGUg aXQgaXMgdGhlIEVuY2FwRXh0IFN1YlRMVi4NCm8gICAgICAgRW5jYXBFeHQgc3ViVExWIExlbmd0 aDogdGhlIGxlbmd0aCBvZiB0aGUgc3ViVExWRS4NCm8gICAgICAgRmxhZ3M6DQpvICAgICAgIEkg Yml0OiBpZiBzZXQgdG8gMCwgaW5kaWNhdGUgdGhlIHByaXZhdGUgYWRkcmVzcyBpcyBJUHY0LiBJ ZiBzZXQgdG8gMSwgaXQgaW5kaWNhdGVzIHRoZSBwcml2YXRlIGFkZHJlc3MgaXMgSVB2Ni4NCm8g ICAgICAgTyBiaXQ6IGlmIHNldCB0byAwLCBpbmRpY2F0ZSB0aGUgcHVibGljIGFkZHJlc3MgaXMg SVB2NC4gSWYgc2V0IHRvIDEsIGl0IGluZGljYXRlcyB0aGUgcHVibGljIGFkZHJlc3MgaXMgSVB2 Ni4NCm8gICAgICAgUiBiaXRzOiByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gTXVzdCBiZSBzZXQg dG8gMCBub3cuDQoNCm8gICAgICAgTkFUIFR5cGXvvJp3aXRob3V0IE5BVDsgMToxIHN0YXRpYyBO QVQ7IEZ1bGwgQ29uZTsgUmVzdHJpY3RlZCBDb25lOyBQb3J0IFJlc3RyaWN0ZWQgQ29uZTsgb3Ig U3ltbWV0cmljDQpvICAgICAgIEVuY2FwIFR5cGXvvJpTRC1XQU4gdHVubmVsIGVuY2Fwc3VsYXRp b24gdHlwZXMsIHN1Y2ggYXMgSVBzZWMrR1JFLCBJUHNlYytWeExBTiwgSVBzZWMgd2l0aG91dCBH UkUsIEdSRSAod2hlbiB0dW5uZWwgaXMgb3ZlciBzZWN1cmUgdW5kZXJsYXkgbmV0d29yaykNCm8g ICAgICAgVHJhbnNwb3J0IE5ldHdvcmsgSUTvvJpDZW50cmFsIENvbnRyb2xsZXIgYXNzaWduIGEg Z2xvYmFsIHVuaXF1ZSBJRCB0byBlYWNoIHRyYW5zcG9ydCBuZXR3b3Jr77ybDQpvICAgICAgIFJE IElE77yaUm91dGluZyBEb21haW4gSUTvvIxOZWVkIHRvIGJlIGdsb2JhbCB1bmlxdWUuDQpvICAg ICAgIFByaXZhdGUgSVDvvJpUaGUgbG9jYWwgSVAgYWRkcmVzcyBvZiB0aGUgdHVubmVsIGVuZC1w b2ludO+8mw0KbyAgICAgICBQcml2YXRlIFBvcnTvvJp1c2VkIGJ5IFJlbW90ZSBTRC1XQU4gbm9k ZSBmb3IgZXN0YWJsaXNoaW5nIElQc2VjIHRvIHRoaXMgc3BlY2lmaWMgcG9ydC4NCm8gICAgICAg UHVibGljIElQ77yaVGhlIElQIGFkZHJlc3MgYWZ0ZXIgdGhlIE5BVC4NCm8gICAgICAgUHVibGlj IFBvcnTvvJpUaGUgUG9ydCBhZnRlciB0aGUgTkFULg0KDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2gg Zm9yIGZlZWRiYWNrLg0KDQpMaW5kYSBEdW5iYXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIHRvbSBwZXRjaA0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwMiwgMjAxOCAxMToyNiBQTQ0K VG86IEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT4NCkNjOiBpcHY2QGlldGYub3JnDQpT dWJqZWN0OiBSZTogcmVnaXN0ZXJpbmcgdHVubmVsIHR5cGVzDQoNCi0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KRnJvbTogIkpvZWwgSmFlZ2dsaSIgPGpvZWxqYUBib2d1cy5jb208bWFpbHRv OmpvZWxqYUBib2d1cy5jb20+Pg0KVG86ICJ0b20gcGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29t PG1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tPj4NCkNjOiA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+OyA8aXB2NkBpZXRm Lm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4+OyAiQWxleGFuZHJlIFBldHJlc2N1IiA8YWxleGFu ZHJlLnBldHJlc2N1QGdtYWlsLmNvbTxtYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNv bT4+DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDE4IDg6MjMgUE0NCg0KPiBPbiBPY3Qg MzAsIDIwMTgsIGF0IDA1OjA3LCB0b20gcGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRv OmlldGZjQGJ0Y29ubmVjdC5jb20+PiB3cm90ZToNCj4+DQo+DQo+IEFsZXgNCj4NCj4gSSBhZ3Jl ZSwgYXQgbGVhc3QgaW4gcGFydDsgdHVubmVscyBhbmQgaW50ZXJmYWNlcyBhcmUgZGlmZmVyZW50 DQphbmltYWxzDQo+IGFuZCBpdCBpcyB1bmZvcnR1bmF0ZSB0aGF0IHRoZXkgd2VyZSBjb25mbGF0 ZWQgaW4gU01JLg0KPg0KPiBJIHdhcyBzdXJwcmlzZWQgdGhhdCBORVRNT0QgaGFkIG5vdCBwcm9k dWNlZCBhIFlBTkcgbW9kdWxlIGZvciB0dW5uZWxzDQo+IGJ1dCBpdCBzZWVtcyB0aGF0IHRoZXJl IGhhcyBiZWVuIG5vIG5lZWQgZm9yIHRoZSBwYXN0IGRlY2FkZS4gIFRoYXQNCj4gc2FpZCwgSSB0 aGluayB0aGF0IGl0IGlzIGEgZ29vZCBpZGVhIHRvIGhhdmUgb25lLiAgV2hldGhlciBvciBub3Qg aXQNCj4gc2hvdWxkIG1pcnJvciB0aGUgVHVubmVsIE1JQiBJIGZpbmQgbW9yZSBkZWJhdGFibGUu DQoNCkl04oCZcyBub3QgZW50aXJlbHkgb2J2aW91cyB0byBtZSB0aGF0IG5ldHRlZCAvIG5ldGNv bmZpZyB3b3VsZCBiZSB3aGVyZSB0aGUgdHVubmVsIG1vZGVscyB3ZXJlIHByb2R1Y2VkLg0KDQpU aGV5IHRlbmQgaWYgZmFjdCB0byBiZSBwcm9kdWNlZCBieSB0aGUgdHVubmVsIHByb3RvY29sIG1h aW50YWluZXJzIGUuZy4NCmwzc20vbDJzbS9jY2FtcCBhbmQgc28gb24uIFRoZSBtYW5hZ2VtZW50 IHRvb2xzIGZvciBhIHByb2R1Y3QgdGVuZCB0byBiZSBkZXZlbG9wZWQgaXRzZWxmIGluIG15IGV4 cGVyaWVuY2UuDQoNCjx0cD4NCg0KSm9lbA0KDQpNeSBjb25jZXJuIGlzIHRoYXQgc29tZXRoaW5n IHRoYXQgY3V0cyBhY3Jvc3MgYSBudW1iZXIgb2YgSUVURiBXRyBzaG91bGQgZ2V0IGFkZXF1YXRl IHJldmlldy4gIFRoZSBZQU5HIGludGVyZmFjZSBtb2R1bGUgd2FzIG11Y2ggZGlzY3Vzc2VkIGlu IHRoZSBuZXRtb2QgV0csIHdpdGggYW4gZXhpc3RpbmcgTUlCIGFzIGd1aWRhbmNlLCBiZWZvcmUg YmVjb21pbmcgYW4gUkZDLg0KDQpUaGUgcHJvcG9zZWQgWUFORyB0dW5uZWwgbW9kdWxlLCB3aGlj aCBib3Jyb3dzIHRoZSBjb25jZXB0cyBvZiB0aGUgaW50ZXJmYWNlIG1vZHVsZSwgdGhhdCBhZGRp dGlvbnMgc2hvdWxkIGJlIG1hZGUgYnkgdGhlIFR1bm5lbCBNSUIgRGVzaWduYXRlZCBFeHBlcnQg dG8gYSByZWdpc3RyeSBhbmQgdGhlbiBwcm9wYWdhdGVkIHRvIHRoZSBUdW5uZWwgTUlCIGFuZCB0 aGUgVHVubmVsIFlBTkcgbW9kdWxlLCBoYXMgbm90IGJlZW4gZGlzY3Vzc2VkIGluIGFueSBXRy4g IFRoZSBwcm9wb3NhbCwgYXMgSSBtZW50aW9uZWQgYmVmb3JlLCBoYXMgYmVlbiBhZGRlZCB0byB0 aGUgSS1EIGFmdGVyIElFVEYgTGFzdCBDYWxsIGhhcyBiZWVuIGNvbXBsZXRlZCBzbyBhcHBlYXJz IHRvIG1lIHRvIGJlIHRoZSB3b3JrIG9mIG9uZSBpbmRpdmlkdWFsLCB3aXRob3V0IGFueSByZXZp ZXc7IHRoZSBJLUQgbGlzdHMgc2V2ZW4gZWRpdG9ycywgc2l4IG9mIHdob20gYXBwZWFyIHRvIGJl IGFic2VudC4gIFRoZVdHIG1haWxpbmcgbGlzdCBzZWVtcyBkZXZvaWQgb2YgYW55IGRpc2N1c3Np b24uDQoNCkkgYmVsaWV2ZSB0aGF0IHRoZSBJRVRGIHN1Y2NlZWRzIGJlY2F1c2Ugb2YgcGVlciBy ZXZpZXcsIGFuZCBJIHN0cnVnZ2xlIHRvIHNlZSB0aGF0IGhlcmUuDQoNClRvbSBQZXRjaA0KDQo+ IE15IG93biBob21ld29yayBjYW1lIGFjcm9zcyBvdGhlciBJUCBpbiBJUCB2YXJpZXRpZXMgd2hp Y2ggZG8gbm90DQo+IGFwcGVhci4NCj4NCj4gVG9tIFBldGNoDQo+DQo+DQo+Pg0KPj4gQWxleA0K Pj4NCj4+Pg0KPj4+IElmIHlvdSBuZWVkIGEgbmV3IHZhbHVlIG9yIGlmIHlvdSBoYXZlIGEgcXVl c3Rpb24gYWJvdXQgYSBnaXZlbg0KPiBpbnRlcmZhY2UgdHVubmVsIHR5cGUsIHBsZWFzZSBmb2xs b3cgdGhlIGd1aWRlbGluZXMgaW4gdGhlIHVybCBjaXRlZA0KPiBhYm92ZS4gQWxsIHRoaXMgaXMg b3V0IG9mIHRoZSBzY29wZSBvZiBkcmFmdC1pZXRmLXNvZnR3aXJlLXlhbmcuDQo+Pj4NCj4+PiBD aGVlcnMsDQo+Pj4gTWVkDQo+Pj4NCj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ Pj4+IERlIDogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBBbGV4YW5kcmUNCj4gUGV0cmVzY3UNCj4+Pj4gRW52b3nDqSA6IGpldWRpIDI1IG9jdG9icmUg MjAxOCAwOTo1NCDDgCA6IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+IE9iamV0 IDogUmU6DQo+Pj4+IHJlZ2lzdGVyaW5nIHR1bm5lbCB0eXBlcw0KPj4+Pg0KPj4+PiBBcmU6DQo+ Pj4+IC1JUHY2IGluIFVEUHY0IGFuZA0KPj4+PiAtSVB2NiBpbiBJUHY2IGFzIHVzZWQgYnkgb3Bl bnZwbjsNCj4+Pj4NCj4+Pj4gY292ZXJlZCBieSB0aGUgbGlzdCBiZWxvdz8NCj4+Pj4NCj4+Pj4g VGhlc2UgYXJlIGEgZmV3IHR1bm5lbGxpbmcgbWVjaGFuaXNtcyBJIHVzZSByb3V0aW5lbHkuDQo+ Pj4+DQo+Pj4+IEV4aXN0aW5nIGlkZW50aXR5IDZ0b2ZvdXIgc2hvdWxkIGJlIGRlcHJlY2F0ZWQs IGlmIHRoYXQgbWVhbnMgNnRvNCwNCj4+Pj4gd2hpY2ggaXMgZGVwcmVjYXRlZC4NCj4+Pj4NCj4+ Pj4gRXhpc3RpbmcgaWRlbnRpdHkgaXBodHRwcyBoYXMgYSB2ZXJzaW9uIG51bWJlciBmb3IgSVA/ DQo+Pj4+DQo+Pj4+IEFsZXgNCj4+Pj4NCj4+Pj4gTGUgMjQvMTAvMjAxOCDDoCAxNzo1NywgdG9t IHBldGNoIGEgw6ljcml0IDoNCj4+Pj4+IGRyYWZ0LWlldGYtc29mdHdpcmUteWFuZw0KPj4+Pj4g Y29tcGxldGVkIElFVEYgTGFzdCBDYWxsIHR3byB3ZWVrcyBhZ28gYW5kLCBzaW5jZSB0aGVuLCBo YXMNCj4gYWNxdWlyZWQgYQ0KPj4+Pj4gWUFORyBtb2R1bGUgdGhhdCBkZWZpbmVzIHR1bm5lbCB0 eXBlcywgYXMgbGlzdGVkIGJlbG93LiAgSXQgaXMNCj4gaW50ZW5kZWQNCj4+Pj4+IHRvIGJlIGEg SUFOQS1tYWludGFpbmVkIG1vZHVsZSBhbmQgc28gY2hhbmdlcyB0byB0aGUgbGlzdCBvZg0KPiB0 dW5uZWxzDQo+Pj4+PiB3aWxsIG5vdCByZXF1aXJlIGEgcmVpc3N1ZSBvZiB0aGUgc29mdHdpcmVz IFJGQy10by1iZS4gIEF0IHRoZQ0KPiBzYW1lDQo+Pj4+PiB0aW1lLCBnZXR0aW5nIGl0IHJpZ2h0 IGZpcnN0IHRpbWUgbmV2ZXIgZGlkIGFueSBoYXJtIHNvIGlmIGFueW9uZQ0KPiBjYW4NCj4+Pj4+ IHRoaW5rIG9mIGFueSBtaXNzaW5nLCBvciBjYW4gdGhpbmsgb2Ygb3RoZXIgcGxhY2VzIHdoZXJl IHRoZXJlDQo+IG1pZ2h0IGJlDQo+Pj4+PiBvdGhlciB0dW5uZWxzIGx1cmtpbmcsIG5vdyB3b3Vs ZCBiZSBhIGdvb2QgdGltZSB0byBtZW50aW9uIGl0Lg0KPj4+Pj4NCj4+Pj4+IEl0IGlzIGJhc2Vk IG9uIFJGQzQwODcgVHVubmVsIE1JQiAod2hpY2ggY3JlYXRlZCBhbiBTTUkgVGV4dHVhbA0KPj4+ Pj4gQ29udmVudGlvbiB0aGF0IHdlbnQgdXAgdG8gVGVyZWRvKSBzbyB0dW5uZWxzIGZyb20gdGhh dCB2aW50YWdlDQo+IGFyZQ0KPj4+Pj4gbGlrZWx5IHdlbGwgY2F0ZXJlZCBmb3IuICBzb2Z0d2ly ZXMgaXMgbm90IHdoZXJlIEkgd291bGQgaGF2ZQ0KPiBmaXJzdA0KPj4+Pj4gbG9va2VkIGZvciB0 dW5uZWwgdHlwZXMsIGJ1dCBpdCBoYXMgYSBjZXJ0YWluIGxvZ2ljIHRvIGl0Lg0KPj4+Pj4NCj4+ Pj4+ICAgICAgIGlkZW50aXR5ICBvdGhlcg0KPj4+Pj4NCj4+Pj4+ICAgICAgIGlkZW50aXR5IGRp cmVjdA0KPj4+Pj4NCj4+Pj4+ICAgICAgIGlkZW50aXR5IGdyZQ0KPj4+Pj4NCj4+Pj4+ICAgICAg IGlkZW50aXR5IG1pbmltYWwNCj4+Pj4+DQo+Pj4+PiAgICAgICBpZGVudGl0eSBsMnRwDQo+Pj4+ Pg0KPj4+Pj4gICAgICAgaWRlbnRpdHkgcHB0cA0KPj4+Pj4NCj4+Pj4+ICAgICAgIGlkZW50aXR5 IGwyZg0KPj4+Pj4NCj4+Pj4+ICAgICAgIGlkZW50aXR5IHVkcA0KPj4+Pj4NCj4+Pj4+ICAgICAg IGlkZW50aXR5IGF0bXANCj4+Pj4+DQo+Pj4+PiAgICAgICBpZGVudGl0eSBtc2RwDQo+Pj4+Pg0K Pj4+Pj4gICAgICAgaWRlbnRpdHkgc2l4dG9mb3VyDQo+Pj4+Pg0KPj4+Pj4gICAgICAgaWRlbnRp dHkgc2l4b3ZlcmZvdXINCj4+Pj4+DQo+Pj4+PiAgICAgICBpZGVudGl0eSBpc2F0YXANCj4+Pj4+ DQo+Pj4+PiAgICAgICBpZGVudGl0eSB0ZXJlZG8NCj4+Pj4+DQo+Pj4+PiAgICAgICBpZGVudGl0 eSBpcGh0dHBzDQo+Pj4+Pg0KPj4+Pj4gICAgICAgaWRlbnRpdHkgc29mdHdpcmVtZXNoDQo+Pj4+ Pg0KPj4+Pj4gICAgICAgaWRlbnRpdHkgZHNsaXRlDQo+Pj4+Pg0KPj4+Pj4gICAgICAgaWRlbnRp dHkgIGFwbHVzcA0KPj4+Pj4NCj4+Pj4+IFRvbSBQZXRjaA0KPj4+Pj4NCj4+DQo+Pj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCi0NCj4+Pj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2 QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPiBBZG1pbmlzdHJhdGl2ZQ0KPj4+Pj4gUmVx dWVzdHM6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4N Cj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KLQ0KPj4+Pj4NCj4+Pj4NCj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5vcmc8bWFp bHRvOmlwdjZAaWV0Zi5vcmc+IEFkbWluaXN0cmF0aXZlDQo+Pj4+IFJlcXVlc3RzOiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+DQo+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+PiBpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KPj4gQWRtaW5pc3Ry YXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Ng0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYu b3JnPiA8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCjxodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9y ZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F66B18249Esjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPg0KPGRpdj48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItaWRyLWJncC1zZHdhbi1vdmVybGF5LWV4 dC8iPjxmb250IGZhY2U9IkNhbGlicmkiIGNvbG9yPSIjMDU2M0MxIj48dT5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItaWRyLWJncC1zZHdhbi1vdmVybGF5LWV4 dC88L3U+PC9mb250PjwvYT48Zm9udCBmYWNlPSJDYWxpYnJpIj4gPC9mb250Pjxmb250IGZhY2U9 IkNhbGlicmkiPg0Kc3BlY2lmaWVzIGEgbmV3IEJHUCBTQUZJICg9NzQpIGluIG9yZGVyIHRvIGFk dmVydGlzZSBhIFNELVdBTiBlZGdlIG5vZGXigJlzIGNhcGFiaWxpdGllcyBpbiBlc3RhYmxpc2hp bmcgU0QtV0FOIG92ZXJsYXkgdHVubmVscyB3aXRoIG90aGVyIFNELVdBTiBub2RlcyB0aHJvdWdo IHRoaXJkIHBhcnR5IHVudHJ1c3RlZCBuZXR3b3Jrcy48L2ZvbnQ+PC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5TaW5jZSBhIFNELVdBTiBlbmQgcG9p bnQgbWlnaHQgdXNlIElQdjYgcHJpdmF0ZSBhZGRyZXNzLCB3aGljaCBpcyB0cmFuc2xhdGVkIHRv IElQdjQgcHVibGljIGFkZHJlc3MgdmlhIE5BVCwmbmJzcDsgd2FudCB0byBnZXQgSVB2NiBncm91 cCAmYW1wOyBJbnRlciBBcmVhIFdHIGZlZWRiYWNrIG9uIHRoZSBzdWJUTFYgcHJvcG9zZWQgaW4g dGhlIGRyYWZ0OjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5FbmNhcHNFeHQgc3ViLVRM ViBpcyBmb3IgZGVzY3JpYmluZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBTRC1X QU4gdHVubmVsIGVuZC1wb2ludHMsIHN1Y2ggYXMgTkFUIHByb3BlcnR5LiBBIFNELVdBTiBlZGdl IG5vZGUgY2FuIGlucXVpcmUgU1RVTiAoU2Vzc2lvbiBUcmF2ZXJzYWwgb2YgVURQIFRocm91Z2gg TmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9uIFJGQyAzNDg5KSBTZXJ2ZXINCnRvIGdldCB0aGUg TkFUIHByb3BlcnR5LCB0aGUgcHVibGljIElQIGFkZHJlc3MgYW5kIHRoZSBQdWJsaWMgUG9ydCBu dW1iZXIgdG8gcGFzcyB0byBwZWVycy4mbmJzcDsgPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDE8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4mbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5cHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfEVuY2FwRXh0IFR5cGUmbmJzcDsg fCZuYnNwOyBFbmNhcEV4dCBzdWJUTFYgTGVuZ3RoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHxJfE98UnxSfFJ8UnxSfFJ8PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OXB0OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTkFUIFR5cGUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBFbmNhcC1UeXBlJm5ic3A7Jm5ic3A7 IHxUcmFucyBuZXR3b3JrSUR8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJEIElEJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD b3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4mbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5cHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBQcml2YXRlJm5ic3A7IElQIEFkZHJlc3MmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCA8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 cHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMzItYml0cyBmb3IgSVB2NCwgMTI4LWJpdHMgZm9yIElwdjY8L3NwYW4+ PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfn5+fn5+fn5+fn5+PC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OXB0OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHJpdmF0ZSZuYnNwOyBQb3J0Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4m bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBQdWJsaWMgSVAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCA8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMzItYml0cyBmb3IgSVB2NCwgMTI4LWJpdHMgZm9yIElwdjY8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfn5+fn5+fn5+fn5+PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OXB0OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9z cGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHVibGljIFBvcnQmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5XaGVy ZTogPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5vJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVuY2FwRXh0IFR5cGU6IGluZGljYXRlIGl0IGlzIHRo ZSBFbmNhcEV4dCBTdWJUTFYuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp Ij5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVuY2FwRXh0IHN1YlRMViBM ZW5ndGg6IHRoZSBsZW5ndGggb2YgdGhlIHN1YlRMVkUuIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBG bGFnczo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPm8mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBiaXQ6IGlmIHNldCB0byAwLCBpbmRpY2F0ZSB0 aGUgcHJpdmF0ZSBhZGRyZXNzIGlzIElQdjQuIElmIHNldCB0byAxLCBpdCBpbmRpY2F0ZXMgdGhl IHByaXZhdGUgYWRkcmVzcyBpcyBJUHY2LiA8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmkiPm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTyBiaXQ6IGlm IHNldCB0byAwLCBpbmRpY2F0ZSB0aGUgcHVibGljIGFkZHJlc3MgaXMgSVB2NC4gSWYgc2V0IHRv IDEsIGl0IGluZGljYXRlcyB0aGUgcHVibGljIGFkZHJlc3MgaXMgSVB2Ni48L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgUiBiaXRzOiByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gTXVzdCBiZSBzZXQgdG8g MCBub3cuIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5vJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5BVCBUeXBlPGZvbnQgZmFjZT0iU2ltU3VuIj7vvJo8L2ZvbnQ+ d2l0aG91dCBOQVQ7IDE6MSBzdGF0aWMgTkFUOyBGdWxsIENvbmU7IFJlc3RyaWN0ZWQgQ29uZTsg UG9ydCBSZXN0cmljdGVkIENvbmU7IG9yIFN5bW1ldHJpYzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBF bmNhcCBUeXBlPGZvbnQgZmFjZT0iU2ltU3VuIj7vvJo8L2ZvbnQ+U0QtV0FOIHR1bm5lbCBlbmNh cHN1bGF0aW9uIHR5cGVzLCBzdWNoIGFzIElQc2VjJiM0MztHUkUsIElQc2VjJiM0MztWeExBTiwg SVBzZWMgd2l0aG91dCBHUkUsIEdSRSAod2hlbiB0dW5uZWwgaXMgb3ZlciBzZWN1cmUgdW5kZXJs YXkgbmV0d29yayk8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPm8mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVHJhbnNwb3J0IE5ldHdvcmsgSUQ8Zm9u dCBmYWNlPSJTaW1TdW4iPu+8mjwvZm9udD5DZW50cmFsIENvbnRyb2xsZXIgYXNzaWduIGEgZ2xv YmFsIHVuaXF1ZSBJRCB0byBlYWNoIHRyYW5zcG9ydCBuZXR3b3JrPGZvbnQgZmFjZT0iU2ltU3Vu Ij7vvJs8L2ZvbnQ+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5vJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJEIElEPGZvbnQgZmFjZT0iU2ltU3Vu Ij7vvJo8L2ZvbnQ+Um91dGluZyBEb21haW4gSUQ8Zm9udCBmYWNlPSJTaW1TdW4iPu+8jDwvZm9u dD5OZWVkIHRvIGJlIGdsb2JhbCB1bmlxdWUuIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSI+byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQcml2YXRl IElQPGZvbnQgZmFjZT0iU2ltU3VuIj7vvJo8L2ZvbnQ+VGhlIGxvY2FsIElQIGFkZHJlc3Mgb2Yg dGhlIHR1bm5lbCBlbmQtcG9pbnQ8Zm9udCBmYWNlPSJTaW1TdW4iPu+8mzwvZm9udD48L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgUHJpdmF0ZSBQb3J0PGZvbnQgZmFjZT0iU2ltU3VuIj7vvJo8L2ZvbnQ+ dXNlZCBieSBSZW1vdGUgU0QtV0FOIG5vZGUgZm9yIGVzdGFibGlzaGluZyBJUHNlYyB0byB0aGlz IHNwZWNpZmljIHBvcnQuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5v Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFB1YmxpYyBJUDxmb250IGZhY2U9 IlNpbVN1biI+77yaPC9mb250PlRoZSBJUCBhZGRyZXNzIGFmdGVyIHRoZSBOQVQuPC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFB1YmxpYyBQb3J0PGZvbnQgZmFjZT0iU2ltU3VuIj7vvJo8L2ZvbnQ+VGhl IFBvcnQgYWZ0ZXIgdGhlIE5BVC48L2ZvbnQ+PC9kaXY+DQo8YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjwvYT4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9IkNhbGlicmkiPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIGZlZWRiYWNrLiA8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+TGluZGEgRHVuYmFyPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCg0KRnJvbTogaXB2NiBbPGEgaHJlZj0ibWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiB0b20gcGV0Y2g8 YnI+DQoNClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMDIsIDIwMTggMTE6MjYgUE08YnI+DQoNClRv OiBKb2VsIEphZWdnbGkgJmx0O2pvZWxqYUBib2d1cy5jb20mZ3Q7PGJyPg0KDQpDYzogaXB2NkBp ZXRmLm9yZzxicj4NCg0KU3ViamVjdDogUmU6IHJlZ2lzdGVyaW5nIHR1bm5lbCB0eXBlczwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPkZyb206ICZxdW90O0pvZWwgSmFl Z2dsaSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZWxqYUBib2d1cy5jb20iPmpvZWxqYUBi b2d1cy5jb208L2E+Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ VG86ICZxdW90O3RvbSBwZXRjaCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZjQGJ0Y29u bmVjdC5jb20iPmlldGZjQGJ0Y29ubmVjdC5jb208L2E+Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Q2M6ICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8L2E+Jmd0Ozsg JnF1b3Q7QWxleGFuZHJlIFBldHJlc2N1JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFu ZHJlLnBldHJlc2N1QGdtYWlsLmNvbSI+YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbTwvYT4m Z3Q7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5TZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDMwLCAyMDE4IDg6MjMgUE08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ Jmd0OyBPbiBPY3QgMzAsIDIwMTgsIGF0IDA1OjA3LCB0b20gcGV0Y2ggJmx0OzxhIGhyZWY9Im1h aWx0bzppZXRmY0BidGNvbm5lY3QuY29tIj5pZXRmY0BidGNvbm5lY3QuY29tPC9hPiZndDsgd3Jv dGU6PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OzwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OzwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyBBbGV4PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDYWxpYnJpIj4mZ3Q7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj4mZ3Q7IEkgYWdyZWUsIGF0IGxlYXN0IGluIHBhcnQ7IHR1bm5lbHMgYW5kIGludGVyZmFj ZXMgYXJlIGRpZmZlcmVudDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ YW5pbWFsczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyBhbmQg aXQgaXMgdW5mb3J0dW5hdGUgdGhhdCB0aGV5IHdlcmUgY29uZmxhdGVkIGluIFNNSS48L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsgSSB3YXMgc3VycHJpc2VkIHRoYXQgTkVUTU9EIGhh ZCBub3QgcHJvZHVjZWQgYSBZQU5HIG1vZHVsZSBmb3IgdHVubmVscyA8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsgYnV0IGl0IHNlZW1zIHRoYXQgdGhlcmUgaGFz IGJlZW4gbm8gbmVlZCBmb3IgdGhlIHBhc3QgZGVjYWRlLiZuYnNwOyBUaGF0IDwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyBzYWlkLCBJIHRoaW5rIHRoYXQgaXQg aXMgYSBnb29kIGlkZWEgdG8gaGF2ZSBvbmUuJm5ic3A7IFdoZXRoZXIgb3Igbm90IGl0IDwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyBzaG91bGQgbWlycm9yIHRo ZSBUdW5uZWwgTUlCIEkgZmluZCBtb3JlIGRlYmF0YWJsZS48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSI+SXTigJlzIG5vdCBlbnRpcmVseSBvYnZpb3VzIHRvIG1lIHRoYXQgbmV0dGVkIC8g bmV0Y29uZmlnIHdvdWxkIGJlIHdoZXJlIHRoZSB0dW5uZWwgbW9kZWxzIHdlcmUgcHJvZHVjZWQu PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPlRoZXkgdGVuZCBpZiBmYWN0IHRvIGJlIHBy b2R1Y2VkIGJ5IHRoZSB0dW5uZWwgcHJvdG9jb2wgbWFpbnRhaW5lcnMgZS5nLjwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+bDNzbS9sMnNtL2NjYW1wIGFuZCBzbyBvbi4g VGhlIG1hbmFnZW1lbnQgdG9vbHMgZm9yIGEgcHJvZHVjdCB0ZW5kIHRvIGJlIGRldmVsb3BlZCBp dHNlbGYgaW4gbXkgZXhwZXJpZW5jZS48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmx0 O3RwJmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5Kb2VsPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9IkNhbGlicmkiPk15IGNvbmNlcm4gaXMgdGhhdCBzb21ldGhpbmcgdGhhdCBjdXRzIGFj cm9zcyBhIG51bWJlciBvZiBJRVRGIFdHIHNob3VsZCBnZXQgYWRlcXVhdGUgcmV2aWV3LiZuYnNw OyBUaGUgWUFORyBpbnRlcmZhY2UgbW9kdWxlIHdhcyBtdWNoIGRpc2N1c3NlZCBpbiB0aGUgbmV0 bW9kIFdHLCB3aXRoIGFuIGV4aXN0aW5nIE1JQiBhcyBndWlkYW5jZSwgYmVmb3JlIGJlY29taW5n IGFuIFJGQy48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+VGhlIHByb3Bvc2VkIFlBTkcg dHVubmVsIG1vZHVsZSwgd2hpY2ggYm9ycm93cyB0aGUgY29uY2VwdHMgb2YgdGhlIGludGVyZmFj ZSBtb2R1bGUsIHRoYXQgYWRkaXRpb25zIHNob3VsZCBiZSBtYWRlIGJ5IHRoZSBUdW5uZWwgTUlC IERlc2lnbmF0ZWQgRXhwZXJ0IHRvIGEgcmVnaXN0cnkgYW5kIHRoZW4gcHJvcGFnYXRlZCB0byB0 aGUgVHVubmVsIE1JQiBhbmQgdGhlIFR1bm5lbCBZQU5HIG1vZHVsZSwNCmhhcyBub3QgYmVlbiBk aXNjdXNzZWQgaW4gYW55IFdHLiZuYnNwOyBUaGUgcHJvcG9zYWwsIGFzIEkgbWVudGlvbmVkIGJl Zm9yZSwgaGFzIGJlZW4gYWRkZWQgdG8gdGhlIEktRCBhZnRlciBJRVRGIExhc3QgQ2FsbCBoYXMg YmVlbiBjb21wbGV0ZWQgc28gYXBwZWFycyB0byBtZSB0byBiZSB0aGUgd29yayBvZiBvbmUgaW5k aXZpZHVhbCwgd2l0aG91dCBhbnkgcmV2aWV3OyB0aGUgSS1EIGxpc3RzIHNldmVuIGVkaXRvcnMs IHNpeCBvZiB3aG9tIGFwcGVhcg0KdG8gYmUgYWJzZW50LiZuYnNwOyBUaGVXRyBtYWlsaW5nIGxp c3Qgc2VlbXMgZGV2b2lkIG9mIGFueSBkaXNjdXNzaW9uLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpIj5JIGJlbGlldmUgdGhhdCB0aGUgSUVURiBzdWNjZWVkcyBiZWNhdXNlIG9mIHBlZXIg cmV2aWV3LCBhbmQgSSBzdHJ1Z2dsZSB0byBzZWUgdGhhdCBoZXJlLjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpIj5Ub20gUGV0Y2g8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0 OyBNeSBvd24gaG9tZXdvcmsgY2FtZSBhY3Jvc3Mgb3RoZXIgSVAgaW4gSVAgdmFyaWV0aWVzIHdo aWNoIGRvIG5vdCA8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsg YXBwZWFyLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OzwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyBUb20gUGV0Y2g8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmkiPiZndDsmZ3Q7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp Ij4mZ3Q7Jmd0OyBBbGV4PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4m Z3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsm Z3Q7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsg SWYgeW91IG5lZWQgYSBuZXcgdmFsdWUgb3IgaWYgeW91IGhhdmUgYSBxdWVzdGlvbiBhYm91dCBh IGdpdmVuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7IGludGVy ZmFjZSB0dW5uZWwgdHlwZSwgcGxlYXNlIGZvbGxvdyB0aGUgZ3VpZGVsaW5lcyBpbiB0aGUgdXJs IGNpdGVkIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyBhYm92 ZS4gQWxsIHRoaXMgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiBkcmFmdC1pZXRmLXNvZnR3aXJlLXlh bmcuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDs8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyBDaGVl cnMsPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsg TWVkPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDs8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsg LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7IERlIDogaXB2NiBbPGEgaHJlZj0ibWFpbHRvOmlw djYtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZzwvYT5dIERl IGxhIHBhcnQgZGUgQWxleGFuZHJlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj4mZ3Q7IFBldHJlc2N1PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IEVudm95w6kgOiBqZXVkaSAyNSBvY3RvYnJlIDIwMTggMDk6NTQg w4AgOiA8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+aXB2NkBpZXRmLm9yZzwvYT4gT2Jq ZXQgOiBSZTogPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0 OyZndDsmZ3Q7IHJlZ2lzdGVyaW5nIHR1bm5lbCB0eXBlczwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyBBcmU6PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7IC1JUHY2IGluIFVEUHY0IGFu ZDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0 OyAtSVB2NiBpbiBJUHY2IGFzIHVzZWQgYnkgb3BlbnZwbjs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsgY292ZXJlZCBieSB0aGUgbGlzdCBi ZWxvdz88L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0 OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0 OyZndDsgVGhlc2UgYXJlIGEgZmV3IHR1bm5lbGxpbmcgbWVjaGFuaXNtcyBJIHVzZSByb3V0aW5l bHkuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsm Z3Q7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsm Z3Q7IEV4aXN0aW5nIGlkZW50aXR5IDZ0b2ZvdXIgc2hvdWxkIGJlIGRlcHJlY2F0ZWQsIGlmIHRo YXQgbWVhbnMgNnRvNCwgPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4m Z3Q7Jmd0OyZndDsmZ3Q7IHdoaWNoIGlzIGRlcHJlY2F0ZWQuPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7IEV4aXN0aW5nIGlkZW50aXR5IGlw aHR0cHMgaGFzIGEgdmVyc2lvbiBudW1iZXIgZm9yIElQPzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyBBbGV4PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7IExlIDI0LzEwLzIwMTggw6Ag MTc6NTcsIHRvbSBwZXRjaCBhIMOpY3JpdCA6PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1pZXRmLXNvZnR3aXJlLXlhbmc8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNvbXBsZXRlZCBJRVRGIExhc3QgQ2FsbCB0d28gd2Vla3MgYWdvIGFuZCwgc2luY2UgdGhl biwgaGFzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7IGFjcXVp cmVkIGE8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFlBTkcgbW9kdWxlIHRoYXQgZGVmaW5lcyB0dW5uZWwgdHlwZXMsIGFzIGxpc3Rl ZCBiZWxvdy4mbmJzcDsgSXQgaXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmkiPiZndDsgaW50ZW5kZWQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmki PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGJlIGEgSUFOQS1tYWludGFpbmVkIG1vZHVsZSBhbmQg c28gY2hhbmdlcyB0byB0aGUgbGlzdCBvZjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSI+Jmd0OyB0dW5uZWxzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aWxsIG5vdCByZXF1aXJlIGEgcmVpc3N1ZSBvZiB0 aGUgc29mdHdpcmVzIFJGQy10by1iZS4mbmJzcDsgQXQgdGhlPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7IHNhbWU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRpbWUsIGdldHRpbmcgaXQgcmlnaHQg Zmlyc3QgdGltZSBuZXZlciBkaWQgYW55IGhhcm0gc28gaWYgYW55b25lPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7IGNhbjwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhpbmsgb2YgYW55IG1pc3Np bmcsIG9yIGNhbiB0aGluayBvZiBvdGhlciBwbGFjZXMgd2hlcmUgdGhlcmU8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsgbWlnaHQgYmU8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG90aGVyIHR1bm5l bHMgbHVya2luZywgbm93IHdvdWxkIGJlIGEgZ29vZCB0aW1lIHRvIG1lbnRpb24gaXQuPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgSXQgaXMgYmFzZWQgb24gUkZDNDA4NyBUdW5uZWwgTUlCICh3aGljaCBjcmVhdGVkIGFuIFNN SSBUZXh0dWFsIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgQ29udmVudGlvbiB0aGF0IHdlbnQgdXAgdG8gVGVyZWRvKSBzbyB0dW5u ZWxzIGZyb20gdGhhdCB2aW50YWdlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj4mZ3Q7IGFyZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgbGlrZWx5IHdlbGwgY2F0ZXJlZCBmb3IuJm5ic3A7IHNvZnR3aXJl cyBpcyBub3Qgd2hlcmUgSSB3b3VsZCBoYXZlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj4mZ3Q7IGZpcnN0PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsb29rZWQgZm9yIHR1bm5lbCB0eXBlcywgYnV0IGl0 IGhhcyBhIGNlcnRhaW4gbG9naWMgdG8gaXQuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaWRlbnRpdHkmbmJzcDsgb3RoZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSBkaXJlY3Q8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSBncmU8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSBtaW5pbWFsPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRpdHkgbDJ0cDwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aXR5IHBwdHA8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSBsMmY8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSB1ZHA8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSBhdG1wPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRpdHkgbXNkcDwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aXR5IHNpeHRvZm91cjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aXR5IHNpeG92ZXJm b3VyPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRpdHkg aXNhdGFwPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRp dHkgdGVyZWRvPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRl bnRpdHkgaXBodHRwczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmki PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGlkZW50aXR5IHNvZnR3aXJlbWVzaDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGlkZW50aXR5IGRzbGl0ZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGlkZW50aXR5Jm5ic3A7IGFwbHVzcDwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvbSBQZXRjaDwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPi08L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCA8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9y ZyI+aXB2NkBpZXRmLm9yZzwvYT4gQWRtaW5pc3RyYXRpdmUgPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZXF1ZXN0czo8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpIj4mZ3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj4tPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ Jmd0OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7 Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ Jmd0OyZndDsmZ3Q7Jmd0OyBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgPGEg aHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8L2E+IEFkbWluaXN0cmF0 aXZlIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7 Jmd0OyBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+ PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OzwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0OzwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsmZ3Q7IElFVEYgSVB2NiB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSI+Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0 Zi5vcmc8L2E+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7Jmd0 OyBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHY2Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwdjY8L2E+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7 Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ Jmd0OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDs8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsgSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGlldGYub3JnPC9h PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPm1haWx0bzppcHY2QGlldGYub3Jn PC9hPiZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsgQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXB2NiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2PC9hPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmx0OzxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPiZndDs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PC9mb250PjwvZGl2Pg0KPGRpdj48 YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+aXB2NkBp ZXRmLm9yZzwvZm9udD48L2E+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPkFkbWlu aXN0cmF0aXZlIFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 NjwvYT48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PC9mb250PjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F66B18249Esjceml521mbschi_-- From nobody Sun Nov 4 18:27:26 2018 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EDA129C6B; Sun, 4 Nov 2018 18:27:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-ipv6only-flag-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipv6@ietf.org Message-ID: <154138484442.31986.13331336413231156093@ietfa.amsl.com> Date: Sun, 04 Nov 2018 18:27:24 -0800 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 02:27:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance WG of the IETF. Title : IPv6 Router Advertisement IPv6-Only Flag Authors : Robert M. Hinden Brian Carpenter Filename : draft-ietf-6man-ipv6only-flag-04.txt Pages : 14 Date : 2018-11-04 Abstract: This document specifies a Router Advertisement Flag to indicate to hosts that the administrator has configured the router to advertise that the link is IPv6-Only. This document updates RFC4861 and RFC5175. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6only-flag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-04 https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6only-flag-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6only-flag-04 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 Sun Nov 4 18:35:08 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11DC12F18C for ; Sun, 4 Nov 2018 18:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 UyrAvvHBIywG for ; Sun, 4 Nov 2018 18:35:04 -0800 (PST) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 D9B43129C6B for ; Sun, 4 Nov 2018 18:35:01 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id v24-v6so6733676wmh.3 for ; Sun, 04 Nov 2018 18:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=n1+UN5oaSdYDpTWsrHo2sg0+Z/KOaCubXLgCes4F8Rs=; b=O8YIMYa2H8DWjWDCmkaKR6D1gBDvAlmpGdbupmzvv9DDPkYYHM5t8ZBsMDdFRyFTZk sybeiWAI0yrU4nRLZj4LMdaYMDASyw59GhY7PulYwjyq7zJRcfsHiwKO9X7vDCZe4SYK G+IqfPCTdtwo/cz5a1UhAIjr23PqQ2TZbmn2GuAX62gM4p/4hAQBGrrkAmrm/WYBk/kg qdgTBwkg5cxgiKI7T/3AujtJx5DTgXP5P8Xqi919xIx0mjZ39iJ6ZfT3dFd0jyjwoMHS uLKWRPWasoxFame5yRjM5rH3KUh/WgrXC6K9pDyBZkunq8SGROWRzJwAwg8IT8SjfYh/ yjSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=n1+UN5oaSdYDpTWsrHo2sg0+Z/KOaCubXLgCes4F8Rs=; b=RCBr+gSSZgAHBpCCkEQy9ap1FH8DGdeKtsC6NkWkRvaz9oxxcigkJU1UyRBcyy2YJi JX6JfnFHD1zbqnDJ0Vq89SXiqHeYlvutn2lI+BOKz67+B/O7CC7GIrSHKXQZdCG7nZT3 9CHhrTp5P0HDnndq6Nhtmjc+v6X/uV1hGmiPi6v+yXfLJFoJGtyonXu3s2ObQ+WbEAPB TfskQS3IcrbHBUG7kYQWRAsKU948Eiw+lueW4h/T3JG8K/2p7CWoLKcwngIBJMX0plFg AOWzEmuDoFHQu9BbQbMW+VdW9fhgxaNdNhxycGVkv7kyy5YPXd+8HdQ2I1Tyw7ZxbFzq CwtQ== X-Gm-Message-State: AGRZ1gJ4y78pDMAtUGaqNMCpU2PBxqPN4bzTkbLeG4isi0MGKRmghRNI XvVWpMIJ2daxzrTRo5oPpyKnYqm3 X-Google-Smtp-Source: AJdET5c8ghwObLr1+BaPGC0iGtr5EJCtX8arla8pMEVZavbl8x2t1JlGrRMjyxeVL0Z1CTk2ru+//g== X-Received: by 2002:a1c:a5d6:: with SMTP id o205-v6mr4317819wme.89.1541385300100; Sun, 04 Nov 2018 18:35:00 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:c4bc:e17:8662:f61e? ([2001:67c:370:128:c4bc:e17:8662:f61e]) by smtp.gmail.com with ESMTPSA id f16-v6sm8369338wru.62.2018.11.04.18.34.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 18:34:59 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_46DEB14E-A3D3-4F2B-88D8-8D9292A0E1BC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: New Version of draft-ietf-6man-ipv6only-flag-04.txt Date: Mon, 5 Nov 2018 09:34:54 +0700 References: <154138484442.31986.13331336413231156093@ietfa.amsl.com> Cc: Bob Hinden , Brian Carpenter To: IPv6 List Message-Id: <90C82FD9-D9E3-414D-8976-88BE3432F505@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 02:35:07 -0000 --Apple-Mail=_46DEB14E-A3D3-4F2B-88D8-8D9292A0E1BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We submitted a new version of the IPv6 Router Advertisement IPv6-Only = Flag draft. Links below. Changes are: * Added text to Section 1 explaining why the mechanism is based on Router Advertisements. * Added text to Section 3 that for a VLAN, the IPv6-Only flag only applies to the specific VLAN on which it was received. * Changed Section 3 that administrators MUST only use this mechanism if they are certain that the link is IPv6-Only, instead of SHOULD. * Added ARP to Section 4 protocols that the IPv6-Only flag applies to. * Renamed the IPv6-Only flag label from "6" to "S". * Added pointers to Section 7.2.7 of RFC4861 in Section 6. * Added that RFC4861 is also updated by Section 6 for routers implementing this flag. * Changed Section 7 from SHOULD NOT to MUST NOT. * Added Appendix A on Implementations and Testing. * Many small clarifications based on IPv6 list discussion and editorial changes. The changes are based on the IPv6 list discussion and editorial changes = suggested off line. Thanks to Lee Howard for his detailed review and = all of the email discussion. Please review and comment. Thanks, Bob & Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-6man-ipv6only-flag-04.txt > Date: November 5, 2018 at 9:27:24 AM GMT+7 > To: > Cc: ipv6@ietf.org > Reply-To: ipv6@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance WG of the IETF. >=20 > Title : IPv6 Router Advertisement IPv6-Only Flag > Authors : Robert M. Hinden > Brian Carpenter > Filename : draft-ietf-6man-ipv6only-flag-04.txt > Pages : 14 > Date : 2018-11-04 >=20 > Abstract: > This document specifies a Router Advertisement Flag to indicate to > hosts that the administrator has configured the router to advertise > that the link is IPv6-Only. This document updates RFC4861 and > RFC5175. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6only-flag/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-04 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6only-flag-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6only-flag-04 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_46DEB14E-A3D3-4F2B-88D8-8D9292A0E1BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlvfrE4ACgkQrut0EXfn u6hzuQf+OSy3T8P50i6X68VoCn1VzDAVkqMSoWx4usU+N89KYN8pdn/suhWFJwWe lCEoH3wLDOmZ4sjhAE+Jb6lQIrtDyMixbESD5X1aKgxLfZ5ahcN/JU0Z7AfccTjk nVTQ02K3kH9ttJwswWbnxnfSEh6c2JfSvG3Oi2Z4pmOlSxbpT8fb/y1Usnd/IHhv +kXv2YDrW3GQlICkQcPIPPrbMvO5R60zTW7cd/W+3yRWawIu2h4LdFKoJWXRnhoJ qXWmduIsufnSFHK9pS3rZ481e3oj7yhJJSGN5vwYO+izue9D7DyTXKV90uvUEHHw zIfUd1xUOjMf+s+Du+Jzd4mHntu0ew== =rlzn -----END PGP SIGNATURE----- --Apple-Mail=_46DEB14E-A3D3-4F2B-88D8-8D9292A0E1BC-- From nobody Sun Nov 4 20:55:28 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51984128CF2; Sun, 4 Nov 2018 20:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 8eSXhUcdJ5DW; Sun, 4 Nov 2018 20:55:23 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 59057128B14; Sun, 4 Nov 2018 20:55:23 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5F87F88882329; Mon, 5 Nov 2018 04:55:20 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 04:55:21 +0000 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.70]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 12:55:11 +0800 From: "Chengli (Cheng Li)" To: "Darren Dukes (ddukes)" CC: Joel Halpern , "spring@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Lizhenbin , Mach Chen Subject: =?utf-8?B?562U5aSNOiBTUnY2IC0gU1JIIGluIGVuY2FwcyBvciBiYXNlIGhlYWRlciAt?= =?utf-8?Q?_point_2?= Thread-Topic: SRv6 - SRH in encaps or base header - point 2 Thread-Index: AQHUcIcsTbFeHZpwLku+NvhkEcQp5qU4pNnQgAOq8QCABFXpAA== Date: Mon, 5 Nov 2018 04:55:11 +0000 Message-ID: References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.175.168] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 04:55:26 -0000 c28gaG93IHRvIHVzZSBTUkggaW5zZXJ0aW9uPyBPdXQgb2Ygc2NvcGUgb2YgdGhpcyBkcmFmdD8N Cg0KQ2hlbmcNCg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IERhcnJlbiBE dWtlcyAoZGR1a2VzKSBbbWFpbHRvOmRkdWtlc0BjaXNjby5jb21dIA0K5Y+R6YCB5pe26Ze0OiAy MDE45bm0MTHmnIgz5pelIDI6NDANCuaUtuS7tuS6ujogQ2hlbmdsaSAoQ2hlbmcgTGkpIDxjaGVu Z2xpMTNAaHVhd2VpLmNvbT4NCuaKhOmAgTogSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4u Y29tPjsgc3ByaW5nQGlldGYub3JnOyA2bWFuQGlldGYub3JnOyBMaXpoZW5iaW4gPGxpemhlbmJp bkBodWF3ZWkuY29tPjsgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT4NCuS4u+mimDog UmU6IFNSdjYgLSBTUkggaW4gZW5jYXBzIG9yIGJhc2UgaGVhZGVyIC0gcG9pbnQgMg0KDQpIZWxs byBDaGVuZywgdGhhbmtzIGZvciB0aGUgcmV2aWV3ISAgUGxlYXNlIHNlZSBpbmxpbmUNCg0KPiBP biBPY3QgMzAsIDIwMTgsIGF0IDExOjQxIFBNLCBDaGVuZ2xpIChJUCBUZWNobm9sb2d5IFJlc2Vh cmNoKSA8Y2hlbmdsaTEzQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gSGkgRGFycmVuLA0KPiAN Cj4gSSB0aGluayB0aGUgdGV4dCBvZiBlbmNhcHN1bGF0aW5nIG1vZGUgaXMgY2xlYXIgZm9yIG1l LiBCdXQgSSBzdGlsbCBoYXZlIHNvbWUgcXVlc3Rpb25zIG9mIHRoZSBpbnNlcnRpb24gbW9kZSAu DQo+IA0KPiAxLjEgOjxkZD4gTm9kZSA5IGhhcyBhIGNob2ljZSwgZW5jYXBzdWxhdGUgdG8gbm9k ZSAzIG9yIG5vdC4gDQo+IElmIG5vZGUgOSBkb2VzIG5vdCBlbmNhcHN1bGF0ZSwgaXQgd2lsbCBp bmZvcm0gdGhlIGRlc3RpbmF0aW9uIG9mIHRoZSBzZWdtZW50cyBpbiB0aGUgU1JIIGFuZCBwb3Nz aWJseSBsZWFrIHRoZW0gdG8gaW50ZXJtZWRpYXRlIG5vZGVzLg0KPiANCj4gSWYgdGhlcmUgaXMg bm90IGluZGljYXRvciB0byBtYWtlIGEgY2hvaWNlIG9mIGVuY2Fwc3VsYXRpbmcgb3Igbm90LCBo b3cgdGhlIG5vZGUgdG8gbWFrZSB0aGUgY2hvaWNlPyBMb2NhbCBwb2xpY3k/ICANCj4gT3IgbWFr ZSBpdCB0aGUgc2FtZSBsaWtlIHRoZSByZWNlaXZlZCBwYWNrZXQ/IEVuY2Fwc3VsYXRlIGlmIHJl Y2VpdmVkIHBhY2tldCBkb2VzLCBlbHNlLCBpbnNlcnQ/DQoNCkEgaG9zdCBuZWVkcyBtYW55IHRo aW5ncyB0byBkZXRlcm1pbmUgaG93IHRvIGFkZCBhbiBTUkggdG8gYSBwYWNrZXQgaXQgaXMgc2Vu ZGluZyB0byBhIGRlc3RpbmF0aW9uLCBhdCBsZWFzdCBpdCBuZWVkcyB0byBsZWFybiBTSURzIGZv ciBub2RlcyBhbmQgaGF2ZSBzb21lIGxvZ2ljIGluIHBsYWNlIHRvIGRldGVybWluZSBob3cgYW5k IHdoZW4gdG8gdXNlIGEgcGFydGljdWxhciBzZWdtZW50IGxpc3TigKYgVGhhdCBpcyB3ZWxsIGJl eW9uZCB0aGlzIGRvY3VtZW50IGFuZCB0aGVyZSBpcyBhbmQgd2lsbCBiZSBtb3JlIGlubm92YXRp dmUgd2F5cyBvZiBkZXRlcm1pbmluZyB3aGVuIHRvIGFkZCBhIFNSSCB0byBhIHBhY2tldCBzb3Vy Y2VkIGJ5IGEgbm9kZS4NCg0KVGhlcmVmb3JlIEnigJlsbCBzYXkgdGhpcyBxdWVzdGlvbiBpcyBu b3Qgd2l0aGluIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LCBpdCBuZWVkcyB0byBiZSBhbnN3ZXJl ZCBmb3Igc3BlY2lmaWMgdXNlIGNhc2VzIGFuZCBhcHBsaWNhdGlvbnMgb2YgdGhlIFNSSC4NCg0K VGhhdCBzYWlkIHRoZXJlIGlzIG9uZ29pbmcgd29yayB0byBkZWZpbmUgaG93IGEgbm9kZSBtYXkg bGVhcm4gYW4gU1IgUG9saWN5Og0KUENFUCBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1u ZWdpLXBjZS1zZWdtZW50LXJvdXRpbmctaXB2Ni0wMy50eHQsDQpCR1AtVEUgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeS0wNC50 eHQsDQpvciDigJxTRE7igJ0gbWV0aG9kcyB3aGVyZSBzb21lIG91dHNpZGUgY29udHJvbGxlciBz ZXRzIHVwIGEgc2VnbWVudCBsaXN0IHZpYSBzb21lIFJFU1QsIENMSSwgbmV0Y29uZi95YW5nIGlu dGVyZmFjZSB0byBzYXRpc2Z5IHNwZWNpZmljIHVzZSBjYXNlcy4NCg0KQW5kIHdoZW4gdG8gdXNl IGl0Og0KQkdQIFNSdjYgc2VydmljZXMgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZGF3 cmEtaWRyLXNydjYtdnBuLTA1LnR4dA0KDQoNCj4gDQo+IDEuMiA6IEhvdyB0byBpbmZvcm0gdGhl IGRlc3RpbmF0aW9uIG9mIHRoZSBzZWdtZW50cyBpbiB0aGUgU1JIPyAgQW55IGluZGljYXRvciBp biBTUkg/IE9yIHRocm91Z2ggc2lnbmFsaW5nPyANCj4gDQoNCg0KU2FtZSBhbnN3ZXIgYXMgMS4x LiAgDQoNCj4gMjogQ2FuIGEgbm9ybWFsKG5vbi1TSUQpIElQdjYgYWRkcmVzcyBiZSBhZGRlZCBp bnRvIFNJRCBsaXN0Pw0KPiANCj4gSSBwcmVmZXIgeWVzLg0KPiANCj4gQXMgc2VjdGlvbiA0LjMg c2F5cywgaXQgc2VlbXMgbGlrZSB3ZSBjYW4gZG8gdGhhdC4NCj4gDQo+ICAgIldoZW4gYW4gU1J2 Ni1jYXBhYmxlIG5vZGUgcmVjZWl2ZXMgYW4gSVB2NiBwYWNrZXQsIGl0IHBlcmZvcm1zIGENCj4g ICBsb25nZXN0LXByZWZpeC1tYXRjaCBsb29rdXAgb24gdGhlIHBhY2tldHMgZGVzdGluYXRpb24g YWRkcmVzcy4gIFRoaXMNCj4gICBsb29rdXAgY2FuIHJldHVybiBhbnkgb2YgdGhlIGZvbGxvd2lu ZzoNCj4gDQo+ICAgICAgIEEgRklCIGVudHJ5IHRoYXQgcmVwcmVzZW50cyBhIGxvY2FsbHkgaW5z dGFudGlhdGVkIFNSdjYgU0lEDQo+ICAgICAgIEEgRklCIGVudHJ5IHRoYXQgcmVwcmVzZW50cyBh IGxvY2FsIGludGVyZmFjZSwgbm90IGxvY2FsbHkNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW5zdGFudGlhdGVkIGFzIGFuIFNSdjYgU0lEDQo+ICAgICAgIEEgRklCIGVu dHJ5IHRoYXQgcmVwcmVzZW50cyBhIG5vbi1sb2NhbCByb3V0ZQ0KPiAgICAgICBObyBNYXRjaA0K PiAgICAgICINCj4gQWxzbywgaW4gc2VjdGlvbiA1LCB3ZSBjYW4gc2VlIEE5IGNhbiBiZSBhZGRl ZCBpbiBTSUQgbGlzdCBvZiBhIFNSIHBvbGljeS4NCj4gDQo+IFNvIGZvciB0aGUgcGFja2V0IGZy b20gQTkgdG8gQTEsIHRoZSBhZGRyZXNzIG9mIEExIGNhbiBiZSBhZGRlZCBhcyB0aGUgbGFzdCBl bnRyeSBvZiBTSUQgbGlzdCwgcmlnaHQ/IA0KPiANCj4gSWYgeWVzLCBhZGRyZXNzIG9mIEExIGlz IG5vdCBhbiBpbnN0YW50aWF0ZWQgU0lELCBzbyBub3QgUFNQIGZsYXZvciBjYW4gYmUgZW5hYmxl ZC4gU28gdGhlIHBhY2tldCB3aWxsIGJlIHNlbnQgb3V0IGJ5IGNhcnJ5aW5nIHRoZSBTUkggYWZ0 ZXIgQTEgaXMgdXBkYXRlZCB0byB0aGUgSVB2NiBEQS4gDQo+IFNSSCB3aWxsIGJlIGxlYWtlZCB0 byBvdXRzaWRlIG9mIHRoZSBTUiBkb21haW4sIHdoaWNoIHdpbGwgYnJpbmcgbmV3IHNlY3VyaXR5 IGlzc3Vlcy4gDQo+IA0KDQpZZXMgYXMgdGhlIGxhc3Qgc2VnbWVudCBpbiBhIHNlZ21lbnQgbGlz dCwgYW5kIGFzIFJGQzgyMDAgc2VjdGlvbiA0LjQgZGVzY3JpYmVzIFJvdXRpbmcgSGVhZGVyIHBy b2Nlc3Npbmcgd2hlbiBzZWdtZW50cyBsZWZ0IGlzIDAuDQoNCkl0IGlzIHVwIHRvIHRoZSBzcGVj aWZpYyB1c2UgY2FzZSB0byBkZXRlcm1pbmUgaWYgaW5mb3JtaW5nIHRoZSBkZXN0aW5hdGlvbiBv ciBpbnRlcm1lZGlhdGUgbm9kZXMgb2YgdGhlIHNlZ21lbnQgbGlzdCB1c2VkIHRvIHJlYWNoIGl0 IGlzIGEgc2VjdXJpdHkgcmlzay4gDQoNCkNlcnRhaW5seSBvbiB0aGUgbGFyZ2VyIGludGVybmV0 IHRoaXMgaXMgYW4gaXNzdWUgdGhhdCBuZWVkcyB0byBiZSBjb25zaWRlcmVkLCBidXQgd2l0aGlu IGFuIGVudGVycHJpc2UgbmV0d29yayBvciB3aXRoaW4gYSBzaW5nbGUgcHJvdmlkZXJzIG5ldHdv cmsgY3Jvc3NpbmcgbXVsdGlwbGUgZG9tYWlucywgb3IgZXZlbiBiZXR3ZWVuIHByb3ZpZGVycyB0 aGUgZGlzY2xvc3VyZSBtYXkgYmUgYWNjZXB0YWJsZSBvciBkZXNpcmVkLg0KDQo+IA0KPiAzOiBG b3Igc2VjdGlvbiA2LjIsDQo+ICAgTm9kZXMgb3V0c2lkZSB0aGUgU1IgRG9tYWluIGNhbm5vdCBi ZSB0cnVzdGVkLiAgU1IgRG9tYWluIEluZ3Jlc3MNCj4gICByb3V0ZXJzIFNIT1VMRCBkaXNjYXJk IHBhY2tldHMgZGVzdGluZWQgdG8gU0lEcyB3aXRoaW4gdGhlIFNSIERvbWFpbg0KPiAgIChyZWdh cmRsZXNzIG9mIHRoZSBwcmVzZW5jZSBvZiBhbiBTUkgpIHRvIGF2b2lkIGF0dGFja3Mgb24gdGhl IFNSDQo+ICAgRG9tYWluIGFzIGRlc2NyaWJlZCBhbmQgcmVmZXJlbmNlZCBpbiBbUkZDNTA5NV0u IA0KPiANCj4gICBBcyBhbiBhZGRpdGlvbmFsDQo+ICAgbGF5ZXIgb2YgcHJvdGVjdGlvbiwgU1Ig U2VnbWVudCBFbmRwb2ludCBub2RlcyBTSE9VTEQgZGlzY2FyZCBwYWNrZXRzDQo+ICAgZGVzdGlu ZWQgdG8gbG9jYWwgU0lEcyBmcm9tIHNvdXJjZSBhZGRyZXNzZXMgbm90IHBhcnQgb2YgdGhlIFNS DQo+ICAgRG9tYWluLg0KPiANCj4gRm9yIGEgcGFja2V0IGZyb20gQTEgdG8gQTksICB0aGUgcGFj a2V0IGlzIChBMSwgQTkpLiBOb2RlMyB3aWxsIG5vdCBkcm9wIHRoZSBwYWNrZXQgc2luY2UgdGhl IGRlc3RpbmF0aW9uIGlzIEE5IG5vdCBTOS4NCj4gDQo+IElmIG5vZGUgMyBpbnNlcnQgYSBTUkgg aW4gdGhlIG9yaWdpbmFsIElQdjYgcGFja2V0LCB0aGVuIHRoZSBzb3VyY2UgQWRkcmVzcyB3aWxs IGJlIEExLiBBbmQgdGhlIFNJRCBsaXN0IGNhbiBiZSAgPEE5LCBTNiA+Lg0KPiBJbiB0aGlzIGNh c2UsIHRoZSBwYWNrZXQgd2lsbCBiZSBkcm9wcGVkIGJ5IG5vZGUgNiwgc2luY2UgdGhlIHNvdXJj ZSBhZGRyZXNzIGlzIG5vdCBwYXJ0IG9mIHRoZSBTUiBkb21haW4uICBbU2VjdGlvbiA2LjJdLCBy aWdodD8NCj4gDQo+IElNSE8sIHRoZXJlIGFyZSBzb21lIHByb2JsZW1zIGFib3V0IGluc2VydGlv biBtb2RlLg0KDQpJbiB0aGUgY29udGV4dCBvZiB0aGUgU1JIIGRyYWZ0IHdlIGRvIG5vdCBtYWtl IGFueSBtZW50aW9uIG9yIHVzZSBvZiBTUkggaW5zZXJ0aW9uLiBJLmUuIG5vZGUgMyBkb2VzIG5v dCBpbnNlcnQgYW4gU1JILCBpdCBlbmNhcHN1bGF0ZXMgaW4gYW4gb3V0ZXIgSVB2NiBoZWFkZXIu DQoNCkRhcnJlbg0KDQo+IA0KPiBUaGFua3MsDQo+IENoZW5nDQo+IA0KPiANCj4gDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXJyZW4gRHVrZXMgDQo+IChkZHVrZXMpDQo+IFNlbnQ6 IFdlZG5lc2RheSwgT2N0b2JlciAzMSwgMjAxOCAzOjMxIEFNDQo+IFRvOiBKb2VsIEhhbHBlcm4g PGptaEBqb2VsaGFscGVybi5jb20+DQo+IENjOiBzcHJpbmdAaWV0Zi5vcmc7IDZtYW5AaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFNSdjYgLSBTUkggaW4gZW5jYXBzIG9yIGJhc2UgaGVhZGVyIC0g cG9pbnQgMg0KPiANCj4gSSB0aGluayB3ZeKAmXJlIGFsbW9zdCBjb25jbHVkZWQgc28gb25jZSBt b3JlIGlubGluZSBhdCA8ZGQ+PC9kZD4NCj4gDQo+PiBPbiBPY3QgMjYsIDIwMTgsIGF0IDI6Mjgg UE0sIEpvZWwgSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+PiANCj4+IChy ZXNlbmRpbmcsICtzcHJpbmcgYXMgcmVxdWVzdGVkKQ0KPj4gDQo+PiBUaGFuayB5b3UgZm9yIHRo ZSByZXNwb25zZXMuICBJIHdpbGwgcmVzcG9uZCBpbiBsaW5lLCBtYXJrZWQgPGptaD48L2ptaD4u ICBJIGZlYXIgaXQgd2lsbCBzaG9ydGx5IGdldCB0b28gZGVlcCwgYnV0IHRoZSBjb250ZXh0IGlz IGltcG9ydGFudC4NCj4+IA0KPj4gSSB3aWxsIHJlcGhyYXNlIGhlcmUgYW4gaXNzdWUgZnJvbSBh bm90aGVyIHRocmVhZCB0aGF0IEkgYWh2ZSBub3Qgc2VlbiB5b3VyIGNvbW1lbnRzIG9uLiAgSWYg Tm9kZSA5IGlzIHNlbmRpbmcgdHJhZmZpYyB0byBOb2RlIDEgKGZvciBleGFtcGxlLCB0aGUgcmV2 ZXJzZSB0cmFmZmljIGZvciB0aGUgdHJhZmZpYyBmcm9tIDEgdG8gOSBpbiB0aGUgZXhhbXBsZXMg YmVsb3cpLCBpdCBwcmVzdW1hYmx5IGhhcyBhbiBTUiBQb2xpY3kgdG8gYmUgYXBwbGllZC4gVGhl IGlzc3VlIEkgcmFpc2VkIGJlZm9yZSBpcyB0aGUgbGVha2FnZSBpc3N1ZS4gIElmIDkgcHV0cyB0 aGUgU1JIIGluIGl0cyBwYWNrZXQgKGFzIHRoZSBkb2N1bWVudCBjdXJyZW50bHkgbWFuZGF0ZXMp LCB0aGVuIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIGZvciAzIHRvIHJlbW92ZSB0aGUgU1JILiAg VGh1cywgdGhlIFNSSCB3aWxsIGxlYWsuDQo+PiANCj4+IFNvbWUgaGF2ZSBhcmd1ZWQgdGhhdCBp cyBub3QgYSBiaWcgZGVhbC4gIEl0IHNlZW1zIHRvIG1hdHRlciB0byBtZS4gIEJ1dCB0aGVyZSBp cyBhbiBhZGRpdGlvbmFsIHByb2JsZW0uICBBMSBpcyBub3QgYSBTSUQuICBUaGVyZWZvcmUsIDkg Y2FuIG5vdCBwdXQgQTEgaW50byB0aGUgU1JILiAgSWYgaXQgY2FuIG5vdCBwdXQgQTEgaW50byB0 aGUgU1JILCBhbmQgaXQgZG9lcyBub3QgZW5jYXBzdWxhdGUgdGhlIHBhY2tldCwgd2hlcmUgZG9l cyBpdCBwdXQgQTEuDQo+IA0KPiA8ZGQ+IE5vZGUgOSBoYXMgYSBjaG9pY2UsIGVuY2Fwc3VsYXRl IHRvIG5vZGUgMyBvciBub3QuIA0KPiBJZiBub2RlIDkgZG9lcyBub3QgZW5jYXBzdWxhdGUsIGl0 IHdpbGwgaW5mb3JtIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgc2VnbWVudHMgaW4gdGhlIFNSSCBh bmQgcG9zc2libHkgbGVhayB0aGVtIHRvIGludGVybWVkaWF0ZSBub2Rlcy4NCj4gSWYgbm9kZSA5 IGRvZXMgZW5jYXBzdWxhdGUsIG5vZGUgMyByZW1vdmVzIHRoZSBvdXRlciBoZWFkZXIgYW5kIG5v ZGUgMSB3b3VsZCBub3QgbGVhcm4gdGhlIHNlZ21lbnQgbGlzdC4NCj4gSSB0aGluayBpdHMgY2hv aWNlIHNob3VsZCBub3QgYmUgbWFuZGF0ZWQgaW4gdGhlIGRyYWZ0LiA8L2RkPg0KPiANCj4+IA0K Pj4gWW91cnMsDQo+PiBKb2VsDQo+PiANCj4+IE9uIDEwLzI2LzE4IDE6MjkgUE0sIERhcnJlbiBE dWtlcyAoZGR1a2VzKSB3cm90ZToNCj4+PiBIaSBKb2VsLCB5b3XigJl2ZSBkZXNjcmliZWQgc2Vj dGlvbnMgdGl0bGVkIOKAnEludHJhIFNSIERvbWFpbiBQYWNrZXTigJ0sIOKAnFRyYW5zaXQgUGFj a2V0IFRocm91Z2ggU1IgRG9tYWlu4oCdLCBhbmQgIlNSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0 bHkgQ29ubmVjdGVk4oCdLg0KPj4+IEnigJl2ZSBwYXJzZWQgdGhlbSBpbmxpbmUgdG8gdGhlIHNl Y3Rpb25zIG9mIHRoZSBkcmFmdCBkZWZpbmluZyB0aGVtIGFuZCBnaXZlbiBtb3JlIGNvbnRleHQg d2hlcmUgbmVlZGVkLg0KPj4+PiBPbiBPY3QgMjIsIDIwMTgsIGF0IDg6NDkgUE0sIEpvZWwgTS4g SGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBSZXBocmFz aW5nIHVzaW5nIHRoZSBleGFtcGxlIGZyb20gNS4yLiAgQXNzdW1pbmcgdGhhdCA4IGFuZCA5IGFy ZSANCj4+Pj4gU1IgSG9zdHMgKG5vdCBqdXN0IGhvc3RzIHdpdGhpbiB0aGUgZG9tYWluLCB0aGV5 IGFyZSBjYXBhYmxlIG9mIGFuZCANCj4+Pj4gZXhwZWN0IHRvIGRlYWwgd2l0aCBTUkhzLCBhbmQg dGhlcmVmb3JlIGhhdmUgbG9jYWwgU0lEcywgLi4uKQ0KPj4+PiANCj4+Pj4gRm9yIHRyYWZmaWMg ZnJvbSA4IHRvIDkgdGhhdCBuZWVkcyBhbiBTUkgsIHRoZSBTUkggZ29lcyBpbiB0aGUgSVB2NiBo ZWFkZXIgc2VudCBteSA4IHRvIDkuICBXaGVuIDkgcHJvY2Vzc2VzIHRoZSBwYWNrZXQsIGl0IHNl ZW1zIHRoYXQgaXQgaXMgdGhlIGxhc3QgU0lELCBmaWd1cmVzIG91dCB0aGF0IHRoZXJlIGlzIG5v IGVuY2Fwc3VsYXRpb24sIGFuZCBzZW5kIHRoZSBUQ1AgLyBVRFAgLyBRVUlDIGluZm9ybWF0aW9u IHRvIGl0cyBpbnRlcm5hbCBwcm90b2NvbHMgc3RhY2tzLg0KPj4+IFllcywgdGhpcyBpcyBTZWN0 aW9uIDUuMy4xIOKAnEludHJhIFNSIERvbWFpbiBQYWNrZXTigJ0uDQo+PiA8am1oPkFncmVlZCBh cyBmYXIgYXMgaXQgZ29lcy4gIEhvd2V2ZXIsICB0aGUgZXhpc3RlbmNlIG9mIFM5IGFuZCBBOSAN Cj4+IHBvaW50cyB0byBhIHByb2JsZW0uICBOb2RlIDggaXMgdHJ5aW5nIHRvIHB1dCBvbiBhbiBT UkggZ29pbmcgdGhyb3VnaCANCj4+IFN4LCBTeSwgd2hhdGV2ZXIgZm9yIHNvbWUgcmVhc29uLiAg SXQgY2FuJ3QgcHV0IEE5IGludG8gdGhlIFNSSCwgYXMgDQo+PiBBSCBpcyBub3QgYSBTSUQsIGl0 IGlzIGFuIGFkZHJlc3MuICBJIHByZXN1bWUgbm9kZSA4IGdvdCBTOSBmcm9tIA0KPj4gd2hhdGV2 ZXIgcHJvdmlkZWQgaGltIHRoZSBTUiBQb2xpY3kgdGhhdCBpdCBpcyB1c2luZy4gIERvZXMgaXQg c2ltcGx5IA0KPj4gdXNlIFM5IGFzIHRoZSBhZGRyZXNzIGZvciBub2RlIDksIHJhdGhlciB0aGFu IEE5IHRoYXQgaXQgZ290IGZyb20gDQo+PiBETlM/ICBBbmQgZG9lcyB0aGUgVENQIHN0YWNrIGtu b3cgdGhhdCB0aGlzIHN1YnN0aXR1dGlvbiBpcyBiZWluZyANCj4+IG1hZGU/ICAoVGhpcyBpcyBh bm90aGVyIGV4YW1wbGUgb2YgYSBwcm9ibGVtIHRoYXQgZ29lcyBhd2F5IGlmIHdlIA0KPj4gYWx3 YXlzIGVuY2Fwc3VsYXRlLikgPC9qbWg+DQo+IA0KPiA8ZGQ+U2VjdGlvbiA0LjMuMiBjb3ZlcnMg dGhlc2UgcXVlc3Rpb25zLCBpLmUuIEE5IGNhbiBiZSBwbGFjZWQgaW4gdGhlIA0KPiBTUkggYXMg dGhlIGxhc3Qgc2VnbWVudCwgYW5kIHRoaXMgc2VjdGlvbiBkZXNjcmliZXMgaG93IGl04oCZcyAN Cj4gaGFuZGxlZC48L2RkPg0KPiANCj4+IA0KPj4+PiANCj4+Pj4gRm9yIHRyYWZmaWMgZnJvbSAx IHRvIDksIHdoZXJlIDMgYWRkcyBhbiBTUkgsIHRoYXQgU1JIIHN0aWxsIHByZXN1bWFibHkgZW5k cyBhdCA5LiAgOSBSZWNlaXZlcyB0aGUgSVAgcGFja2V0LiAgU2VlcyB0aGF0IGl0IGlzIGFkZHJl c3NlZCB0byBpdHNlbGYuICBTZWVzIHRoYXQgdGhlIFNSSCBpcyBmaW5pc2hlZC4gIEFuZCB0aGVu IG5vdGljZXMgdGhhdCB0aGUgbmV4dC1oZWFkZXIgaXMgSVB2Ni4gIFVud3JhcHMgdGhlIGhlYWRl ciwgY2hlY2tzIHRoYXQgdGhlIGlubmVyIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYWxzbyBpdHNl bGYsIGFuZCBwYXNzZXMgdGhlIG1hdGVyaWFsIGNhcnJpZWQgYnkgdGhlIGlubmVyIGhlYWRlciB1 cCB0byB0aGUgYXBwcm9wcmlhdGUgc3RhY2suDQo+Pj4gU28gbm9kZSAxIHNlbmRzIGEgcGFja2V0 IHRvIG5vZGUgOSAoQTEsQTkpIElGIHRoZXJlIGlzIHNvbWUgc3RlZXJpbmcgDQo+Pj4gaW50byBh biBTUiBQb2xpY3kgYXQgbm9kZSAzIHRvIHJlYWNoIG5vZGUgOSwgdGhpcyBpcyBpZGVudGljYWwg dG8gc2VjdGlvbiA1LjMuMiDigJxUcmFuc2l0IHBhY2tldCB0aHJvdWdoIFNSIGRvbWFpbuKAnSwg ZXhjZXB0IGZvciBkZXN0aW5hdGlvbiBvZiBBOSB2aWEgbm9kZSA5ICBpbnN0ZWFkIG9mIEEyIHZp YSBub2RlIDQuDQo+PiANCj4+Pj4gDQo+Pj4+IFRodXMsIDkgbmVlZHMgdG8gYmUgYWJsZSB0byBj aGVjayBmb3IgYm90aCBjYXNlcy4gIFdlIGF0IGxlYXN0IG5lZWQgdG8gdGVsbCBpbXBsZW1lbnRv cnMgdGhhdC4NCj4+PiBXZWxsLCA5IG5lZWRzIGEgU0lEIFM5IGFuZCBBZGRyZXNzIEE5LiAgVGhh dCBpcyBzaG93biBpbiBTZWN0aW9uIDUuMSBTSUQgYW5kIGFkZHJlc3MgcmVwcmVzZW50YXRpb24u DQo+PiA8am1oPlNvLCBsZXQgdXMgYXNzdW1lIHRoYXQgMyBoYXMgYW4gU1IgcG9saWN5IGl0IHdh bnRzIHRvIGFwcGx5IHRvIA0KPj4gdGhlIHRyYWZmaWMgZnJvbSBBMSB0byBBOS4gIEluIHRoaXMg Y2FzZSwgdGhlIFM5IC8gQTkgZGljaG90b215IGlzIA0KPj4gbm90IGEgcHJvYmxlbSwgSSB0aGlu ay4gIE5vZGUgMyBlbmNhcHN1YWx0ZXMgdGhlIHBhY2tldCBmcm9tIEExIHRvIA0KPj4gQTksIHVz ZXMgUzMgYXMgdGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBlbmNhcHN1bGF0aW5nIGhlYWRlciwg YW5kIA0KPj4gZW5kcyB0aGUgU0lEIGxpc3QgaW4gdGhlIFNSSCB3aXRoIFM5LiAgVGhlIHVuc3Bl Y2lmaWVkIHBhcnQgaXMgdGhhdCANCj4+IG5vZGUgOSBuZWVkcyB0byBiZSBwcmVwYXJlZCB0byBy ZWNlaXZlIHN1Y2ggcGFja2V0cyBhbmQgZG8gdGhlIGRvdWJsZSANCj4+IHByb2Nlc3NpbmcuICBJ dCBpcyByZWFzb25hYmxlIGRvdWJsZSBwcm9jZXNzaW5nLiAgTXkgb25seSByZXF1ZXN0IA0KPj4g aGVyZSBpcyB0aGF0IHdlIHRlbGwgZm9sa3MgdGhleSBuZWVkIHRvIHN1cHBvcnQgaXQuIDwvam1o Pg0KPiANCj4gPGRkPkFjdHVhbGx5LCBub2RlIDMgdXNlcyBBMyBhcyBpdHMgc291cmNlIGFkZHJl c3MsIGJ1dCB0aGF04oCZcyBtaW5vci4NCj4gVGhlIGRvdWJsZSBwcm9jZXNzaW5nIChsb29rdXAs IGRvIGVuZCBwcm9jZXNzaW5nLCBkbyBhbm90aGVyIGxvb2t1cCkgaXMgZG9jdW1lbnRlZCBpbiBT ZWN0aW9uIDQuMy4NCj4gSXMgdGhlcmUgYSBuZWVkIGZvciBtb3JlIHRoYW4gd2hhdCBpcyBjdXJy ZW50bHkgc3BlY2lmaWVkPyA8L2RkPg0KPiANCj4+Pj4gDQo+Pj4+IFRoZXJlIGlzIGEgZnVydGhl ciBjb21wbGljYXRpb24uICA5IHNlZW1zIHRvIG5lZWQgdG8gaGF2ZSBhbiBhZGRyZXNzIHRoYXQg aXMgYSB2YWxpZCBTSUQsIHNvIGl0IGNhbiBiZSB0aGUgbGFzdCBlbnRyeSBpbiB0aGUgU1JIIGZy b20gOCB0byA5Lg0KPj4+IEFzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQsIFNlY3Rpb24gNS4xIGEg bm9kZSBrIGhhcyBhbiBhZGRyZXNzIEFrIGFuZCBTSUQgU2suICBTbyBub2RlIDkgaGFzIGEgdmFs aWQgU0lELg0KPj4+IEZvciB0cmFmZmljIGZyb20gOCB0byA5LCBBOSBpcyB1c2VkIGFzIHRoZSBk ZXN0aW5hdGlvbiBhcyBzaG93biBpbiBzZWN0aW9uIDUuMy4xLCA1LjQgYW5kIDUuNS4NCj4+Pj4g SG93ZXZlciwgaWYgMSB3ZXJlIHRvIHNlbmQgdGhlIHBhY2tldCB0byB0aGF0IFNJRCBmb3IgOSwg cm91dGVyIDMgd291bGQgYmUgcmVxdWlyZWQgYnkgdGhlIHJ1bGVzIHdlIGRpc2N1c3NlZCBpbiB0 aGUgb3RoZXIgdGhyZWFkIHRvIGRpc2NhcmQgdGhlIHBhY2tldCBhcyBpdCBpcyBuZWl0aGVyIHRv IHByZWZpeCBub3IgY29udGFpbnMgYW4gSEFNQy4NCj4+Pj4gQW5kIHNvbWVob3csIDggYW5kIDEg bmVlZCB0byBlYWNoIHBpY2sgdGhlIHJpZ2h0IGFkZHJlc3MgdG8gdXNlIGZvciA5LiAoc3BsaXQg RE5TIG1heWJlPykgIEFuZCAzIG5lZWRzIHRvIGJlIGFibGUgdG8gZGVyaXZlIHRlaCBTSUQtZm9y bW4gYWRkcmVzcyBmb3IgOSBmcm9tIHRoZSBub24tU0lEIGZvcm0gb2YgdGhlIGFkZHJlc3Mgc28g dGhhdCBpdCAoMykgY2FuIGJ1aWxkIGEgcHJvcGVyIFNSSCB0byBnZXQgdGhlIHBhY2tldCB0byA5 Lg0KPj4gPGptaD5JIGhhdmUgcmV0YWluZWQgeW91ciBhbnN3ZXIgYmVsb3cgZm9yIGNvbnRleHQs IGJ1dCBJIHRoaW5rIHRoYXQgDQo+PiBhbnN3ZXJzIHRoZSB3cm9uZyBxdWVzdGlvbi4gIEkgYmVs aWV2ZSB3aGF0IGlzIGl0bmVuZGVkIGlzIHRoYXQgb25seQ0KPj4gQTkgYXBwZWFycyBpbiBETlMu ICBTbyBOb2RlIDEgd2lsbCBzZWUgOSBhcyBBOSwgYW5kIHdpbGwgdXNlIHRoYXQuICANCj4+IFM5 IHdpbGwgYXBwZWFyIGluIFNSIFBvbGljaWVzIGFib3V0IHRyYWZmaWMgdG8gbm9kZSA5LCBidXQg bm90IGluIEROUy4NCj4+IFRoYXQgaXMgd2hhdCB3ZSBuZWVkLiAgSSB3aXNoIGl0IHdlcmUgY2xl YXJlciBpbiB0aGUgdGV4dC4gPC9qbWg+DQo+PiANCj4+IDxqbWg+SWYgbm9kZSAyMCBpcyBnZW5l cmF0aW5nIFNSSHMgd2l0aCBITUFDcywgdGhlbiB0aGlzIGlzIGxhcmdlbHkgDQo+PiB0aGUgc2Ft ZSBhcyB0aGUgY2FzZSBmcm9tIDggdG8gOSwgZXhjZXB0IHRoYXQgd2hvbWV2ZXIgY3JlYXRlcyB0 aGUgU1IgDQo+PiBQb2xpY3kgdGhhdCAyMCBpcyB1c2luZyBuZWVkcyB0byBhbHNvIG1ha2Ugc3Vy ZSB0aGF0IHdoYXRldmVyIHRoZSANCj4+IGZpcnN0IFNJRCBpcyBpbiB0ZWggbGlzdCwgaXQgcHJv Y2Vzc2VzIEhNQUNzIGFuZCBpcyByZWNvZ25pemFibGUgdG8gDQo+PiBub2RlIDMgYXMgZG9pbmcg c3VjaCBwcm9jZXNzaW5nLiBJIGFtIGd1ZXNzaW5nIHRoYXQgdGhlIHJlYXNvbiBmb3IgDQo+PiBh bGxvd2luZyBpbnRlcm5hbCBub2RlcyB0byBkbyB0aGUgcHJvY2Vzc2luZyBpcyB0byBtb3ZlIHRo ZSANCj4+IHZlcmlmaWNhdGlvbiBsb2FkIG9mZiB0aGUgZWRnZSBub2Rlcy4gIEl0IGRvZXMgY3Jl YXRlIHNpZ25pZmljYW50IA0KPj4gYWRkaXRpb25hbCBjb25maWd1cmF0aW9uIGNvbXBsZXhpdHku IDwvam1oPg0KPiANCj4gPGRkPldlIGRpZG7igJl0IHNlZSBhIHJlYXNvbiB0byByZXN0cmljdCB0 aGUgSE1BQyBwcm9jZXNzaW5nIHRvIG9ubHkgDQo+IGVkZ2Ugbm9kZXMgd2hlbiBpdCB3YXMgc3Ry YWlnaHQgZm9yd2FyZCB0byBkZWZpbmUgaG93IHRoZXkgY291bGQgYmUgDQo+IHByb2Nlc3NlZCBh dCBub24tZWRnZSBub2Rlcy48L2RkPg0KPiANCj4+IA0KPj4+IFRoaXMgaXMgaW5jb3JyZWN0Lg0K Pj4+IFNlZSBTZWN0aW9uIDYuMi4xIOKAnFNSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0bHkgQ29u bmVjdGVk4oCdIEkgd2lsbCBleHBhbmQgb24gdGhlIGV4YW1wbGUgZnJvbSB0aGF0IHNlY3Rpb24u DQo+Pj4gTm9kZSAyMCBzZW5kcyBhIHBhY2tldCB0byBBOSB3aXRoIFNSIFBvbGljeSA8SDc+IGFu ZCBhbiBITUFDIA0KPj4+IHByb3ZpZGVkIHRvIG5vZGUgMjAgYnkgc29tZSB5ZXQgdG8gYmUgZGVm aW5lZCBtZXRob2QuICBSZXN1bHRpbmcgaW4gDQo+Pj4gcGFja2V0IHNlbnQgZnJvbSBub2RlIDIw DQo+Pj4gIFA6IChBMjAsSDcpKEE5O1NMPTEpKHBheWxvYWQpDQo+Pj4gUmVjYWxsIEhrIGlzIGEg U0lEIGF0IG5vZGUgayByZXF1aXJpbmcgSE1BQyB2ZXJpZmljYXRpb24sIGFuZCBpdCBpcyBjb3Zl cmVkIGJ5IFByZWZpeC1ILg0KPj4+IFByZWZpeC1IIGlzIF9ub3RfIHN1YmplY3QgdG8gaW5ncmVz cyBmaWx0ZXJpbmcgYXQgbm9kZSAzLg0KPj4+IFRoZXJlZm9yZSB0aGUgcGFja2V0IFAgZGVzdGlu ZWQgdG8gSDcgaXMgbm90IHN1YmplY3QgdG8gaW5ncmVzcyBmaWx0ZXJpbmcgYXQgbm9kZSAzLg0K Pj4+IFAgaXMgZm9yd2FyZGVkIHRvIG5vZGUgNywgd2hlcmUgSDcgaXMgcHJvY2Vzc2VkIGFuZCB0 aGUgSE1BQyB2ZXJpZmllZC4NCj4+PiBJZiB0aGUgSE1BQyBjYW4gbm90IGJlIHZlcmlmaWVkIHRo ZSBwYWNrZXQgaXMgZHJvcHBlZCwgZWxzZSBpdCBpcyBmb3J3YXJkZWQgdG8gdGhlIG5leHQgc2Vn bWVudCBhbmQgZGVzdGluYXRpb24sIEE5Lg0KPj4+IERhcnJlbg0KPj4+PiANCj4+Pj4gWW91cnMs DQo+Pj4+IEpvZWwNCj4+Pj4gDQo+Pj4+IE9uIDEwLzIyLzE4IDg6MDQgUE0sIERhcnJlbiBEdWtl cyAoZGR1a2VzKSB3cm90ZToNCj4+Pj4+IGlubGluZS4NCj4+Pj4+PiBPbiBPY3QgMjIsIDIwMTgs IGF0IDc6MjEgUE0sIEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6 DQo+Pj4+IC4uDQo+Pj4+Pj4gMikgTm93IGxldCB1cyBsb29rIGF0IHBhY2tldHMgYXJyaXZpbmcg YXQgYW5kIGFjdHVhbGx5IGRlc3RpbmVkIGZvciBhbiBTUiBIb3N0IGluIHRoZSBTUiBEb21haW4g d2hlcmUgdGhhdCBwYWNrZXQgaGFzIGFuIFNSSC4gIElmIHRoZSBwYWNrZXQgaXMgY29taW5nIGZy b20gYW5vdGhlciBTUiBIb3N0LCB0aGUgU1JIIHdpbGwgYmUgaW4gdGhlIGJhc2UgaGVhZGVyLCBh bmQgdGhlIGhvc3QgY2FuIHNpbXBseSBjaGVjayBpdCBmb3IgYW55IHZpb2xhdGlvbnMsIGFuZCBj b250aW51ZS4gIEJ1dCwgaWYgdGhlIHBhY2tldCBjYW1lIGZyb20gb3V0c2lkZSB0aGUgZG9tYWlu LCB0aGVuIGl0IHdpbGwgaGF2ZSBhbiBlbmNhcHN1bGF0aW5nIFNSdjYgaGVhZGVyLiAgU28gdGhl IGhvc3QgaGFzIHRvIGRldGVjdCB0aGlzIGNhc2UsIGNoZWNrIGFuZCB0aGVuIHBlYWwgb2ZmIHRo ZSBlbmNhcHN1bGF0aW5nIGhlYWRlciwgYW5kIHRoZW4gcHJvY2VzcyB0aGUgcmVjZWl2ZWQgcGFj a2V0LiBZZXMsIGl0IGNhbiBkbyBzby4gIEJ1dCBub3RoaW5nIGluIHRlaCBkb2N1bWVudCB0ZWxs cyBpbXBsZW1lbnRvcnMgdGhleSBoYXZlIHRvIGRlYWwgd2l0aCBib3RoIGNhc2VzLg0KPj4+Pj4+ IA0KPj4+Pj4gQ2FuIHlvdSBiZSBtb3JlIHByZWNpc2UgaGVyZS4gIFBlcmhhcHMgdXNlIHRoZSBl eGFtcGxlIGZyb20gc2VjdGlvbiA1LjIgb3IgNi4yLjE/DQo+Pj4+IC4uDQo+IA0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRm Lm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Sun Nov 4 22:06:16 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9531712D4E9 for ; Sun, 4 Nov 2018 22:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 xISFd-zuSjDT for ; Sun, 4 Nov 2018 22:06:12 -0800 (PST) Received: from atl4mhob14.registeredsite.com (atl4mhob14.registeredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 464D612777C for ; Sun, 4 Nov 2018 22:06:12 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob14.registeredsite.com (8.14.4/8.14.4) with ESMTP id wA566AQ6012017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 5 Nov 2018 01:06:10 -0500 Received: (qmail 23149 invoked by uid 0); 5 Nov 2018 06:06:10 -0000 X-TCPREMOTEIP: 49.248.225.53 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?100.77.55.205?) (lee@asgard.org@49.248.225.53) by 0 with ESMTPA; 5 Nov 2018 06:06:09 -0000 Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Brian E Carpenter , ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> From: Lee Howard Message-ID: <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> Date: Mon, 5 Nov 2018 11:36:04 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1BA9841FF75F6A3C5E1B77C6" Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 06:06:15 -0000 This is a multi-part message in MIME format. --------------1BA9841FF75F6A3C5E1B77C6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/4/18 2:45 AM, Brian E Carpenter wrote: > On 2018-11-04 00:35, Lee Howard wrote: >> >>>> If a network administrator wants central control over IPv4/IPv6 >>>> enablement in hosts, there are better, more centralized tools for that. >>>> As a principle, host behavior should be managed by host management >>>> tools, and not by hints from a router. >>> I'm not sure how that can work on a BYOD network. On a fully managed network, >>> sure, we could "easily" invent a solution. >> Taken all-in-all, then, the use case for this flag is a network where >> the administrator: >> >> 1. does not know what's on the network, > May not know what's on the link, or does not have management access > to some devices on the link, or does not have policy control over > some devices on the link. There are many such networks. > >> 2. expects that there are some applications using IPv4, > I don't see that. The admin has decided that there are no IPv4 > services on the link - presumably no DHCPv4, no DNS over IPv4, > no IPv4 routing. Whether or not some hosts contain IPv4 applications > isn't necessarily known to the admin. If there are no IPv4 services, there is nothing to turn off using this flag. > >> 3. understands that IPv4 will continue to work locally, 3b. except for >> dual-stack hosts that honor the flag, > It might be fairer to say that the admin doesn't care whether > IPv4 works locally, but has decided to announce to everybody that > there are no IPv4 services on the link, knowing that only 3b hosts > will understand the announcement. > > (The fact that RAs are universal, whereas other possible mechanisms > such as DHCPv6 or NETCONF are not, is relevant here.) Okay, "understands that IPv4 will continue to work locally if enabled on hosts." >> 4. understands that applications may have already negotiated IPv4 >> connectivity, > Again - doesn't care. The document says: Administrators MUST only use this mechanism if they are certain that the link is IPv6-Only. For example, in cases where there is a need to continue to use IPv4, when there are intended to be IPv4-only hosts or IPv4 routers on the link, setting this flag to 1 is a configuration error. "certain that the link is IPv6-Only" is not the same as "doesn't care if there are residual IPv4 connections." > >> 5. desires to break communications for 3b and 4, > Again - doesn't care. The flag is specifically to disable connectivity through IPv4. If you don't care about IPv4, you don't set the flag. > >> and prevent IPv4 >> Internet access. > Yes, that's the primary decision. Of course, the assumption is that > IPv6-only access to the Internet is necessary and sufficient. > >> It's not just that administrator accepts that 3b and 4 won't work, but >> as you said above, "The admin will presumably be happy with this result." > Or doesn't care. If she didn't care, she wouldn't set the flag. This administrator is intentionally setting the flag for one or more of the reasons given in the Introduction. >> This seems to me a very narrow application. > It's certainly directed at a specific (and future) phase of history, when > IPv6-only is viable and IPv4 has not yet faded into oblivion. How many > links for how many years would be in that phase is an open question. > > As the draft recognizes, there are other mechanisms available too. > What strikes me as unique about this mechanism is simply that *every* > dual stack host receives and understands RAs; this is our only way > of getting a bit to every single dual stack device. That's not > narrow, IMHO. The number of cases where IPv4 might exist and an administrator wants to shut it down and has no other tools seems narrow to me. While I agree that all dual-stack hosts understand RAs, that doesn't mean they all understand this flag. I have counted zero host operating system implementers who have said they will take action on this flag, but check my math. In a desire to be constructive, I think we had talked earlier about defining the flag to mean, "I have no IPv4 routes." That might be useful information for a host, letting it decide whether it needs IPv4 locally (or has another IPv4 route), and disable appropriately. Lee > > Brian > > --------------1BA9841FF75F6A3C5E1B77C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 11/4/18 2:45 AM, Brian E Carpenter wrote:
On 2018-11-04 00:35, Lee Howard wrote:

If a network administrator wants central control over IPv4/IPv6
enablement in hosts, there are better, more centralized tools for that.
As a principle, host behavior should be managed by host management
tools, and not by hints from a router.
I'm not sure how that can work on a BYOD network. On a fully managed network,
sure, we could "easily" invent a solution.
Taken all-in-all, then, the use case for this flag is a network where 
the administrator:

1. does not know what's on the network,
May not know what's on the link, or does not have management access
to some devices on the link, or does not have policy control over
some devices on the link. There are many such networks.

2. expects that there are some applications using IPv4,
I don't see that. The admin has decided that there are no IPv4
services on the link - presumably no DHCPv4, no DNS over IPv4,
no IPv4 routing. Whether or not some hosts contain IPv4 applications
isn't necessarily known to the admin.

If there are no IPv4 services, there is nothing to turn off using this flag.



3. understands that IPv4 will continue to work locally, 3b. except for 
dual-stack hosts that honor the flag,
It might be fairer to say that the admin doesn't care whether
IPv4 works locally, but has decided to announce to everybody that
there are no IPv4 services on the link, knowing that only 3b hosts
will understand the announcement.

(The fact that RAs are universal, whereas other possible mechanisms
such as DHCPv6 or NETCONF are not, is relevant here.)

Okay, "understands that IPv4 will continue to work locally if enabled on hosts."


      
4. understands that applications may have already negotiated IPv4 
connectivity,
Again - doesn't care.

The document says:

Administrators MUST only use this mechanism if they are certain that
   the link is IPv6-Only.  For example, in cases where there is a need
   to continue to use IPv4, when there are intended to be IPv4-only
   hosts or IPv4 routers on the link, setting this flag to 1 is a
   configuration error.

"certain that the link is IPv6-Only" is not the same as "doesn't care if there are residual IPv4 connections."



5. desires to break communications for 3b and 4, 
Again - doesn't care.

The flag is specifically to disable connectivity through IPv4. If you don't care about IPv4, you don't set the flag.



and prevent IPv4 
Internet access.
Yes, that's the primary decision. Of course, the assumption is that
IPv6-only access to the Internet is necessary and sufficient.

It's not just that administrator accepts that 3b and 4 won't work, but 
as you said above, "The admin will presumably be happy with this result."
Or doesn't care.

If she didn't care, she wouldn't set the flag. This administrator is intentionally setting the flag for one or more of the reasons given in the Introduction.

This seems to me a very narrow application.
It's certainly directed at a specific (and future) phase of history, when
IPv6-only is viable and IPv4 has not yet faded into oblivion. How many
links for how many years would be in that phase is an open question.

As the draft recognizes, there are other mechanisms available too.
What strikes me as unique about this mechanism is simply that *every*
dual stack host receives and understands RAs; this is our only way
of getting a bit to every single dual stack device. That's not
narrow, IMHO.

The number of cases where IPv4 might exist and an administrator wants to shut it down and has no other tools seems narrow to me. While I agree that all dual-stack hosts understand RAs, that doesn't mean they all understand this flag. I have counted zero host operating system implementers who have said they will take action on this flag, but check my math.

In a desire to be constructive, I think we had talked earlier about defining the flag to mean, "I have no IPv4 routes." That might be useful information for a host, letting it decide whether it needs IPv4 locally (or has another IPv4 route), and disable appropriately.

Lee


     Brian


--------------1BA9841FF75F6A3C5E1B77C6-- From nobody Sun Nov 4 22:06:59 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42D012F1A5; Sun, 4 Nov 2018 22:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 LUHIM3eLD8Ca; Sun, 4 Nov 2018 22:06:54 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 426C312777C; Sun, 4 Nov 2018 22:06:54 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id a2-v6so1878181edi.5; Sun, 04 Nov 2018 22:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GaNN1jABjfGmGklPJFLhQDn4mBZRn4p5cJQ2x2XIlyE=; b=LBgYDKePD5G4+0PVSF+TiXtKh3o+5MDHK62niHvgkMM+i1UNVQfP67T6TxtRu38xm5 9E3nTJxAAePEcp+GrTTN20AhjXF6OqT9hUeQ8EgmLGoA4XdPl/9g9zjlGXlS90/Ild/g YgI0FcOQQX33tcN/x7LlgwTfL+jcIMlo9EIUVYWDmnSVM11DQ7FJiv0lwxDLFZxottAU oG/GR/llBZ/wn7EOht0HPv60RSQ+Am6pwBG1Qe8I4I2EeS7SiQZz5oG5gsrFvCqCPZE5 8t+jHWfRLTU0UIjmz/iF4sMBVwqcLmifN04aCiIaKCeV+mQPhz6U/b5aCvPoAmO5LbpI lb5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GaNN1jABjfGmGklPJFLhQDn4mBZRn4p5cJQ2x2XIlyE=; b=HZYsesjnhFJfpk1FryXWd3l3BTB1HtA/zQZM+FX5biU6MzPjaCsPLRzXAufTJqBVUk bfyZbpMny6MmCIAgSwHtau3s7b5ZzQmkDp+2y0GejJnUFXnBXVIw7YRLhHx/krLGwtaw 7DzmGRdNN9UaASw4ORn2YpSPlDe1ykzMKNRr0IjUVmKdzlYaXGw6/cCcz8WkaegJEgeH SoRswNU3p+XRYwfAbZlvAK7MqVMKf23QIEn+/tqtm4eLnk6EIcXBZV8qCATjPWDK721S FblYqq/bK76J6+AwvfthQPIuAha+aGIRw0dDTxgRcqQ0I8TsommrOJF4Kv0CJVpkycGH Vrqw== X-Gm-Message-State: AGRZ1gKbTsbB5nm4fgsBopQ3JzZoCgs0upYHuI+HiDK1EIdD7WB2Phq1 nyEzocYOk37gUOfEQPdQ17c= X-Google-Smtp-Source: AJdET5fq/q2bdJ0/BOIB1yL3nmJtwWRijMeXqdDlChoIdks65MlieTrk43yQqc8yNCQ0qDpWFkLMOg== X-Received: by 2002:a50:b322:: with SMTP id q31-v6mr16389698edd.194.1541398012494; Sun, 04 Nov 2018 22:06:52 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:b5f7:85c:c0f9:9250? ([2001:67c:1232:144:b5f7:85c:c0f9:9250]) by smtp.gmail.com with ESMTPSA id h4-v6sm2258287edd.33.2018.11.04.22.06.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 22:06:51 -0800 (PST) From: Fred Baker Message-Id: <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8A54C296-C1FD-4EC8-8237-10F608E7F48A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Date: Mon, 5 Nov 2018 13:06:44 +0700 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> Cc: tom petch , Joel Jaeggli , "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 06:06:58 -0000 --Apple-Mail=_8A54C296-C1FD-4EC8-8237-10F608E7F48A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Linda, I see a couple of issues here. Speaking as an individual. First, IPv6 doesn't have private addresses, and in the general case = doesn't use NATs. There is no direct counterpart to RFC 1918. The = nearest parallel might be a ULA (RFC 4193), but they are by design not = routable using BGP. Second, yes NAT64 technology exists, but from a routing perspective the = endpoint either has an IPv4 address or an IPv6 address, not an IPv6 = address that is translated into an IPv4 address. That concept doesn't = exist in routing. > On Nov 4, 2018, at 1:13 PM, Linda Dunbar = wrote: >=20 > = https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ = specifies a new BGP SAFI (=3D74) in order to advertise a SD-WAN edge = node=E2=80=99s capabilities in establishing SD-WAN overlay tunnels with = other SD-WAN nodes through third party untrusted networks. >=20 > Since a SD-WAN end point might use IPv6 private address, which is = translated to IPv4 public address via NAT, want to get IPv6 group & = Inter Area WG feedback on the subTLV proposed in the draft: >=20 > EncapsExt sub-TLV is for describing additional information about the = SD-WAN tunnel end-points, such as NAT property. A SD-WAN edge node can = inquire STUN (Session Traversal of UDP Through Network Address = Translation RFC 3489) Server to get the NAT property, the public IP = address and the Public Port number to pass to peers. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |EncapExt Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NAT Type | Encap-Type |Trans networkID| RD ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Private IP Address | > 32-bits for IPv4, 128-bits for Ipv6 > ~~~~~~~~~~~~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Private Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Public IP | > 32-bits for IPv4, 128-bits for Ipv6 > ~~~~~~~~~~~~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Public Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Where: > o EncapExt Type: indicate it is the EncapExt SubTLV. > o EncapExt subTLV Length: the length of the subTLVE. > o Flags: > o I bit: if set to 0, indicate the private address is IPv4. If = set to 1, it indicates the private address is IPv6. > o O bit: if set to 0, indicate the public address is IPv4. If = set to 1, it indicates the public address is IPv6. > o R bits: reserved for future use. Must be set to 0 now. >=20 > o NAT Type=EF=BC=9Awithout NAT; 1:1 static NAT; Full Cone; = Restricted Cone; Port Restricted Cone; or Symmetric > o Encap Type=EF=BC=9ASD-WAN tunnel encapsulation types, such as = IPsec+GRE, IPsec+VxLAN, IPsec without GRE, GRE (when tunnel is over = secure underlay network) > o Transport Network ID=EF=BC=9ACentral Controller assign a = global unique ID to each transport network=EF=BC=9B > o RD ID=EF=BC=9ARouting Domain ID=EF=BC=8CNeed to be global = unique. > o Private IP=EF=BC=9AThe local IP address of the tunnel = end-point=EF=BC=9B > o Private Port=EF=BC=9Aused by Remote SD-WAN node for = establishing IPsec to this specific port. > o Public IP=EF=BC=9AThe IP address after the NAT. > o Public Port=EF=BC=9AThe Port after the NAT. >=20 >=20 > Thank you very much for feedback. >=20 > Linda Dunbar >=20 >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of tom petch > Sent: Friday, November 02, 2018 11:26 PM > To: Joel Jaeggli > Cc: ipv6@ietf.org > Subject: Re: registering tunnel types >=20 > ---- Original Message ----- > From: "Joel Jaeggli" > To: "tom petch" > Cc: ; ; "Alexandre = Petrescu" > Sent: Tuesday, October 30, 2018 8:23 PM >=20 > > On Oct 30, 2018, at 05:07, tom petch wrote: > >> > > > > Alex > > > > I agree, at least in part; tunnels and interfaces are different > animals > > and it is unfortunate that they were conflated in SMI. > > > > I was surprised that NETMOD had not produced a YANG module for = tunnels > > but it seems that there has been no need for the past decade. That > > said, I think that it is a good idea to have one. Whether or not it > > should mirror the Tunnel MIB I find more debatable. >=20 > It=E2=80=99s not entirely obvious to me that netted / netconfig would = be where the tunnel models were produced. >=20 > They tend if fact to be produced by the tunnel protocol maintainers = e.g. > l3sm/l2sm/ccamp and so on. The management tools for a product tend to = be developed itself in my experience. >=20 > >=20 > Joel >=20 > My concern is that something that cuts across a number of IETF WG = should get adequate review. The YANG interface module was much = discussed in the netmod WG, with an existing MIB as guidance, before = becoming an RFC. >=20 > The proposed YANG tunnel module, which borrows the concepts of the = interface module, that additions should be made by the Tunnel MIB = Designated Expert to a registry and then propagated to the Tunnel MIB = and the Tunnel YANG module, has not been discussed in any WG. The = proposal, as I mentioned before, has been added to the I-D after IETF = Last Call has been completed so appears to me to be the work of one = individual, without any review; the I-D lists seven editors, six of whom = appear to be absent. TheWG mailing list seems devoid of any discussion. >=20 > I believe that the IETF succeeds because of peer review, and I = struggle to see that here. >=20 > Tom Petch >=20 > > My own homework came across other IP in IP varieties which do not > > appear. > > > > Tom Petch > > > > > >> > >> Alex > >> > >>> > >>> If you need a new value or if you have a question about a given > > interface tunnel type, please follow the guidelines in the url cited > > above. All this is out of the scope of draft-ietf-softwire-yang. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Alexandre > > Petrescu > >>>> Envoy=C3=A9 : jeudi 25 octobre 2018 09:54 =C3=80 : ipv6@ietf.org = Objet : Re: > >>>> registering tunnel types > >>>> > >>>> Are: > >>>> -IPv6 in UDPv4 and > >>>> -IPv6 in IPv6 as used by openvpn; > >>>> > >>>> covered by the list below? > >>>> > >>>> These are a few tunnelling mechanisms I use routinely. > >>>> > >>>> Existing identity 6tofour should be deprecated, if that means = 6to4, > >>>> which is deprecated. > >>>> > >>>> Existing identity iphttps has a version number for IP? > >>>> > >>>> Alex > >>>> > >>>> Le 24/10/2018 =C3=A0 17:57, tom petch a =C3=A9crit : > >>>>> draft-ietf-softwire-yang > >>>>> completed IETF Last Call two weeks ago and, since then, has > > acquired a > >>>>> YANG module that defines tunnel types, as listed below. It is > > intended > >>>>> to be a IANA-maintained module and so changes to the list of > > tunnels > >>>>> will not require a reissue of the softwires RFC-to-be. At the > > same > >>>>> time, getting it right first time never did any harm so if = anyone > > can > >>>>> think of any missing, or can think of other places where there > > might be > >>>>> other tunnels lurking, now would be a good time to mention it. > >>>>> > >>>>> It is based on RFC4087 Tunnel MIB (which created an SMI Textual > >>>>> Convention that went up to Teredo) so tunnels from that vintage > > are > >>>>> likely well catered for. softwires is not where I would have > > first > >>>>> looked for tunnel types, but it has a certain logic to it. > >>>>> > >>>>> identity other > >>>>> > >>>>> identity direct > >>>>> > >>>>> identity gre > >>>>> > >>>>> identity minimal > >>>>> > >>>>> identity l2tp > >>>>> > >>>>> identity pptp > >>>>> > >>>>> identity l2f > >>>>> > >>>>> identity udp > >>>>> > >>>>> identity atmp > >>>>> > >>>>> identity msdp > >>>>> > >>>>> identity sixtofour > >>>>> > >>>>> identity sixoverfour > >>>>> > >>>>> identity isatap > >>>>> > >>>>> identity teredo > >>>>> > >>>>> identity iphttps > >>>>> > >>>>> identity softwiremesh > >>>>> > >>>>> identity dslite > >>>>> > >>>>> identity aplusp > >>>>> > >>>>> Tom Petch > >>>>> > >> > >>>> = ------------------------------------------------------------------- > - > >>>>> IETF IPv6 working group mailing list ipv6@ietf.org = Administrative > >>>>> Requests: > > https://www.ietf.org/mailman/listinfo/ipv6 > >> > >>>> = ------------------------------------------------------------------- > - > >>>>> > >>>> > >> > >>> = -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> > >>> = -------------------------------------------------------------------- > >> > >> = -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> = -------------------------------------------------------------------- > >> > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_8A54C296-C1FD-4EC8-8237-10F608E7F48A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvf3fQACgkQEhdRnd2G P+DAhQ//ZnCGRGJVfVAW0gogIvCrS5pnLJxKJUjznxtvU5SmKYVYcHNwbUy0mhMr rdI7jWNb1kozIs4mqQAGrdAt4PhFsEaN+GhVABxEHI33/wNkFAyyxHj/vsz6yXmM O8q9Ya9f486QpLi4dFiJoS5QoNzyF0PVZ+KB4m3s7OsseW+j2dHVU0vASsueTpFe 7t6RPcJCm+Femj2OxE0CIP6IarjXtG/ewNzcl/xu7Oy5wsSHwt8jU/ZOIPvJtFR7 a9II6tD0M/uuTMCZbAwubyi8OFlQCjfC7iLfGJ8RSleKHf7g2oNOgudMyLU7kDMF WT/nqwBbLLPGcdyBhP5w4J+VQNx9LWMyQ+8UMNFzTGwSLEr3axwEHDsfPLYmwXfW h2b1S77D2qHAyTJe37gQA4vkiY3H7/2eAjfuZP15lc96uSjOwa62SP6s9d0jd1Yf aUJbKXQKjXI9r60xyDkqc7ofBnNj0rS+OgvHovm2ItIKZzfykRsuBxOSeMa6+9wx IkpXWa1LxwODDLP2GCCvQx4Pa5uo61nOIt9gXBZgdpUTd6yRfNvKX1+o0n7sSMK5 wZ5I6l/SKHqYwjNGFq9J45vFRlvSTsvK9de8V8R04RAm+J9ZH5UlQSG6ygexD017 4d9EZp7he9UgKGFTDWxtur4+ezVXEW3+qtHLTGFyWDUjVdKC8W0= =DzmS -----END PGP SIGNATURE----- --Apple-Mail=_8A54C296-C1FD-4EC8-8237-10F608E7F48A-- From nobody Sun Nov 4 23:38:59 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750661274D0 for ; Sun, 4 Nov 2018 23:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 J76jfhj4VsKa for ; Sun, 4 Nov 2018 23:38:55 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 97CB7130DC2 for ; Sun, 4 Nov 2018 23:38:55 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id g21-v6so3997273pfi.7 for ; Sun, 04 Nov 2018 23:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=hsP+Uq/JZGQB5Eq0GHNoCGrflgghfv9pymD5Ye3SA5Y=; b=tipVgpJ+EgAkV+pJfDd6kI9B25s37oZxymBj2mlgnIoL0PTSb5bH45RpWEDOwlDkar oX6aEKHg6FluCSVse6wdc/1TPHX+lbqTErVZRkp9u4l+msJNToX5bBZHI2Lkw2DIeZJk GSrz1HCug91djFQavqsquEHaymprcXiVfYA+T0U0UK8CA95NKD339bAJJolpKeQoEP6f 0HUEnvpbfMDCqRp34p6nh1kLcytaZLdjEW2/Y0L27dD24yx0bjpd6VJqFglOmj0pva5B Pzy0pHyZ1PDSL+08YPLUEUH7Y9av7hKHWBMGP2yAtMqaFAUq97Bs3gSkiqCTMBAdMMXc 9Zkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hsP+Uq/JZGQB5Eq0GHNoCGrflgghfv9pymD5Ye3SA5Y=; b=Zn+BTZ6B/EW9y+ttMUTFh8T9euCKP0eG+K9CQ9Exw8FWysw3XVs1BlbiOpK1EYut0X J61Xv3cZH+BS756EgaGGe5utP9c0kBKDIAL2h8eNjuFwwnvfwt0cqYPk1c6UTzJBSems 3g5mrvmSPFljtODwjxvP2scH6TP5yXnDz9aks5wAyMMiG3O8wjtuaRZug313MqlEhvm1 vMED8OyVk4nK4sR60zXx6wnSxuhnlMme1oiTn0axsESxHeaoD8ntCWe+xpTstp6k299/ 6SHQF2acswGsv8xk6q8K6CGhUPeglxdW1w1KGMbBmVZowz3LqguhFfoa2w6t0ztBg6oV 1XHw== X-Gm-Message-State: AGRZ1gItN2kE471d0kTlRjPwQgJFdM8RN0KWCIdY+2Xa68Dhmdp5K57Q CtuBkhzcQ6qwOG7d7m6WZs6OUCs0 X-Google-Smtp-Source: AJdET5doGzn/G4f8aQUM0CsRTHbXSPbs72Fhf38ahpJOyiAippN3zoc0BpETs0eyB5T+tx/NpMCScg== X-Received: by 2002:a62:31c2:: with SMTP id x185-v6mr3052512pfx.39.1541403534687; Sun, 04 Nov 2018 23:38:54 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id p11-v6sm29138915pfn.53.2018.11.04.23.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 23:38:53 -0800 (PST) Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Lee Howard , ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> From: Brian E Carpenter Message-ID: Date: Mon, 5 Nov 2018 20:38:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 07:38:57 -0000 While waiting for meetecho to fix the feed I was using... On 2018-11-05 19:06, Lee Howard wrote: > > On 11/4/18 2:45 AM, Brian E Carpenter wrote: >> On 2018-11-04 00:35, Lee Howard wrote: >>> >>>>> If a network administrator wants central control over IPv4/IPv6 >>>>> enablement in hosts, there are better, more centralized tools for that. >>>>> As a principle, host behavior should be managed by host management >>>>> tools, and not by hints from a router. >>>> I'm not sure how that can work on a BYOD network. On a fully managed network, >>>> sure, we could "easily" invent a solution. >>> Taken all-in-all, then, the use case for this flag is a network where >>> the administrator: >>> >>> 1. does not know what's on the network, >> May not know what's on the link, or does not have management access >> to some devices on the link, or does not have policy control over >> some devices on the link. There are many such networks. >> >>> 2. expects that there are some applications using IPv4, >> I don't see that. The admin has decided that there are no IPv4 >> services on the link - presumably no DHCPv4, no DNS over IPv4, >> no IPv4 routing. Whether or not some hosts contain IPv4 applications >> isn't necessarily known to the admin. > > If there are no IPv4 services, there is nothing to turn off using this flag. The host doesn't know that; the flag tells the host not to waste its time. > > >> >>> 3. understands that IPv4 will continue to work locally, 3b. except for >>> dual-stack hosts that honor the flag, >> It might be fairer to say that the admin doesn't care whether >> IPv4 works locally, but has decided to announce to everybody that >> there are no IPv4 services on the link, knowing that only 3b hosts >> will understand the announcement. >> >> (The fact that RAs are universal, whereas other possible mechanisms >> such as DHCPv6 or NETCONF are not, is relevant here.) > > Okay, "understands that IPv4 will continue to work locally if enabled on > hosts." Locally = on a traditional broadcast LAN segment with no L2 filters. But I don't see why this changes anything; we know we can't physically prevent a host trying to use IPv4 if it insists. > >>> 4. understands that applications may have already negotiated IPv4 >>> connectivity, >> Again - doesn't care. > > The document says: > > Administrators MUST only use this mechanism if they are certain that > the link is IPv6-Only. For example, in cases where there is a need > to continue to use IPv4, when there are intended to be IPv4-only > hosts or IPv4 routers on the link, setting this flag to 1 is a > configuration error. > > "certain that the link is IPv6-Only" is not the same as "doesn't care if > there are residual IPv4 connections." Again, I don't see your worry. It's all about the admin's intention, and it's fair warning to any hosts. This is not a switch, it's literally a flag with "No IPv4 services" written on it. >>> 5. desires to break communications for 3b and 4, >> Again - doesn't care. > > The flag is specifically to disable connectivity through IPv4. If you > don't care about IPv4, you don't set the flag. No, the flag is to announce that there is no IPv4 service. That is not the same thing as "to disable connectivity." >>> and prevent IPv4 >>> Internet access. >> Yes, that's the primary decision. Of course, the assumption is that >> IPv6-only access to the Internet is necessary and sufficient. >> >>> It's not just that administrator accepts that 3b and 4 won't work, but >>> as you said above, "The admin will presumably be happy with this result." >> Or doesn't care. > > If she didn't care, she wouldn't set the flag. This administrator is > intentionally setting the flag for one or more of the reasons given in > the Introduction. Yes, but the real action is *not* enabling IPv4 routing, DHCPv4, or DNS over IPv4. (And installing L2 filters, maybe.) The flag is only a flag. > >>> This seems to me a very narrow application. >> It's certainly directed at a specific (and future) phase of history, when >> IPv6-only is viable and IPv4 has not yet faded into oblivion. How many >> links for how many years would be in that phase is an open question. >> >> As the draft recognizes, there are other mechanisms available too. >> What strikes me as unique about this mechanism is simply that *every* >> dual stack host receives and understands RAs; this is our only way >> of getting a bit to every single dual stack device. That's not >> narrow, IMHO. > > The number of cases where IPv4 might exist and an administrator wants to > shut it down and has no other tools seems narrow to me. While I agree > that all dual-stack hosts understand RAs, that doesn't mean they all > understand this flag. I have counted zero host operating system > implementers who have said they will take action on this flag, but check > my math. As for most IETF proposals, it takes time. > In a desire to be constructive, I think we had talked earlier about > defining the flag to mean, "I have no IPv4 routes." That might be useful > information for a host, letting it decide whether it needs IPv4 locally > (or has another IPv4 route), and disable appropriately. That is one of the things it means, along with "I don't grok DHCP" (which also means "I don't announce a DNS/IPv4 server"). And yes, a host MAY ignore it (that's the complement to the SHOULD in the draft). We've never said anything else. Brian From nobody Sun Nov 4 23:44:17 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B37128CFD for ; Sun, 4 Nov 2018 23:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 1Lmaro7aHjJK for ; Sun, 4 Nov 2018 23:44:14 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 866AD1271FF for ; Sun, 4 Nov 2018 23:44:14 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id o89so13159978qko.0 for ; Sun, 04 Nov 2018 23:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8ExFn+VGo41MdyRlQYEIKIyJ5wDT2mPTvDpZbZRBr0s=; b=T5HPkzD0bPV5vfM8f61dLEYFsc0yyP9fa1Zd8OCgVe9J8ziOJxd4Kw/uNbOEntqdXq b1wMoHRb4CQTGjJ4G8qfXSxXCWvojygxYa7Dy5tC+CUBfUeWEGGeXxe0b7g6XdjrKPGc F/0DS32P7mYpZjUuhPdmYVHGGnN2lPU8SSrbIDGedGOEs8XOZJ9PXXlu8iaWjeE/7JJg W2ziIXU+gMvYgJK1wtrfmcF6Hd91PKlq7y0G1Wpr40ap5nOW/PIgJBlmN7j3CtwrSlPo NO9fpQGq9TjeKW98Npgc7PUPOOoye7blDtFRDrBe/FVG8AO2pQpe57IduPNYMALBxGrl OyCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8ExFn+VGo41MdyRlQYEIKIyJ5wDT2mPTvDpZbZRBr0s=; b=FvRowoxeX7OwnLNXpCjAhvPJWefnfayXTTjyPmIuYKi2D8REej/uD+nHjVhnSHkZC/ GdwY6sNtg1Ydoh2FlPMpUg6eoGhBaP3XXZAwFdjmRf/n9WxLhMD9D1ii3u2duMXfy2Od pxiYweNbYTQwK8/v5HBil0sju9pTQniwI6+JwxfTPifdHlpjuJcslyfakTSmHE4M4z8H Tc45JEI2q3wBlqDPl0k98hFrRfwOfMMUw8T7K0Tq794ces8tvrMNcjpMo9AL7QYRClda it3GoWlO35u6hCo+N9K8dbEV2X8p9qI/BUoaGz0qeYiQoBXjBmTRntk1gF6B4G1lHOrB HGYA== X-Gm-Message-State: AGRZ1gKXfwtHVmy/fUmFHs1ShhQznH8dGu2m2a2+HRsvgJ2ZXxFziniD YCB9gil95dxNBAWQWPdJzN9Yf60h12XyOWz2CPUcjkoAt6o= X-Google-Smtp-Source: AJdET5c/Hu7D+Y8BEUU9YWRd8i5Tq5taEInIGHe41Z/VrP4HH4lMA40ZRhLPgj8eBrIs4htILSqvK8CTiBYvl6najBo= X-Received: by 2002:ac8:2bb9:: with SMTP id m54-v6mr20215373qtm.36.1541403853523; Sun, 04 Nov 2018 23:44:13 -0800 (PST) MIME-Version: 1.0 References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> In-Reply-To: <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> From: Jen Linkova Date: Mon, 5 Nov 2018 18:44:01 +1100 Message-ID: Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Lee Howard Cc: 6man Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 07:44:16 -0000 On Fri, Nov 2, 2018 at 5:09 PM Lee Howard wrote: > IPv4-only hosts, and dual-stack hosts > that do not recognize the new > flag, may continue to attempt IPv4 operations > > If some devices require IPv4 and others disable IPv4, you have lost connectivity between systems on a local network. As written, this is not considered a misconfiguration by the administrator who sets the flag. If some devices require IPv4 and the administrator implemented ethertype filtering, blocking IPv4 packets on that LAN segment, you have lost connectivity between systems on a local network. I'd not considered this a misconfiguration by the administrator who configured filtering based on ethertypes. If some devices require IPv4 and the administrator has control over some other devices and disabled IPv4 on them (as I did on my workstation), you have lost connectivity between systems on a local network. Again, I'd not considered this a misconfiguration by the administrator who disabled IPv4 on devices which are managed. -- SY, Jen Linkova aka Furry From nobody Mon Nov 5 02:40:56 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A271130934; Mon, 5 Nov 2018 02:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 e3o6FwDSSbbo; Mon, 5 Nov 2018 02:40:45 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 56DA112EB11; Mon, 5 Nov 2018 02:40:45 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DC9FBB5FC8E0D; Mon, 5 Nov 2018 10:40:41 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 10:40:42 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.103]) by SJCEML703-CHM.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 02:40:37 -0800 From: Linda Dunbar To: Fred Baker CC: tom petch , Joel Jaeggli , "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" Subject: RE: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AdR0BGE++Z0BF4I3RCC8M7+3nc3iHQBDGb8AAAd6+dA= Date: Mon, 5 Nov 2018 10:40:36 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> In-Reply-To: <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.174.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 10:40:49 -0000 RnJlZCwgDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBjb21tZW50cy4gDQoNClF1ZXN0 aW9ucyB0byB5b3U6IA0KDQpJZiBhIENQRS0xIGhhcyBwcml2YXRlIElQdjYgYWRkcmVzc2VzIGZv ciBpdHMgcG9ydHMgYmVoaW5kIE5BVCwgYW5kIENQRS0yIGhhcyBJUHY0IGFkZHJlc3MsIGNhbiBD UEUtMSBjb21tdW5pY2F0ZSB3aXRoIENQRS0yIGJ5IHRoZSBOQVQncyBJUHY0IGFkZHJlc3M/IA0K DQpMaW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRnJlZCBCYWtlciBb bWFpbHRvOmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIE5vdmVtYmVy IDA1LCAyMDE4IDE6MDcgUE0NClRvOiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWku Y29tPg0KQ2M6IHRvbSBwZXRjaCA8aWV0ZmNAYnRjb25uZWN0LmNvbT47IEpvZWwgSmFlZ2dsaSA8 am9lbGphQGJvZ3VzLmNvbT47IGlkckBpZXRmLm9yZzsgaW50LWFyZWFAaWV0Zi5vcmc7IGlwdjZA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBVc2luZyBCR1AgdG8gYWR2ZXJ0aXNlIFNELVdBTiB0dW5u ZWxzIGVuZCBwb2ludCdzIHByaXZhdGUgSVB2NiBhZGRyZXNzZXMuICh3YXMgcmVnaXN0ZXJpbmcg dHVubmVsIHR5cGVzDQoNCkxpbmRhLCBJIHNlZSBhIGNvdXBsZSBvZiBpc3N1ZXMgaGVyZS4gU3Bl YWtpbmcgYXMgYW4gaW5kaXZpZHVhbC4NCg0KRmlyc3QsIElQdjYgZG9lc24ndCBoYXZlIHByaXZh dGUgYWRkcmVzc2VzLCBhbmQgaW4gdGhlIGdlbmVyYWwgY2FzZSBkb2Vzbid0IHVzZSBOQVRzLiBU aGVyZSBpcyBubyBkaXJlY3QgY291bnRlcnBhcnQgdG8gUkZDIDE5MTguIFRoZSBuZWFyZXN0IHBh cmFsbGVsIG1pZ2h0IGJlIGEgVUxBIChSRkMgNDE5MyksIGJ1dCB0aGV5IGFyZSBieSBkZXNpZ24g bm90IHJvdXRhYmxlIHVzaW5nIEJHUC4NCg0KU2Vjb25kLCB5ZXMgTkFUNjQgdGVjaG5vbG9neSBl eGlzdHMsIGJ1dCBmcm9tIGEgcm91dGluZyBwZXJzcGVjdGl2ZSB0aGUgZW5kcG9pbnQgZWl0aGVy IGhhcyBhbiBJUHY0IGFkZHJlc3Mgb3IgYW4gSVB2NiBhZGRyZXNzLCBub3QgYW4gSVB2NiBhZGRy ZXNzIHRoYXQgaXMgdHJhbnNsYXRlZCBpbnRvIGFuIElQdjQgYWRkcmVzcy4gVGhhdCBjb25jZXB0 IGRvZXNuJ3QgZXhpc3QgaW4gcm91dGluZy4NCg0KDQoNCj4gT24gTm92IDQsIDIwMTgsIGF0IDE6 MTMgUE0sIExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KPiAN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFyLWlkci1iZ3At c2R3YW4tb3ZlcmxheS1leHQvIHNwZWNpZmllcyBhIG5ldyBCR1AgU0FGSSAoPTc0KSBpbiBvcmRl ciB0byBhZHZlcnRpc2UgYSBTRC1XQU4gZWRnZSBub2Rl4oCZcyBjYXBhYmlsaXRpZXMgaW4gZXN0 YWJsaXNoaW5nIFNELVdBTiBvdmVybGF5IHR1bm5lbHMgd2l0aCBvdGhlciBTRC1XQU4gbm9kZXMg dGhyb3VnaCB0aGlyZCBwYXJ0eSB1bnRydXN0ZWQgbmV0d29ya3MuDQo+IA0KPiBTaW5jZSBhIFNE LVdBTiBlbmQgcG9pbnQgbWlnaHQgdXNlIElQdjYgcHJpdmF0ZSBhZGRyZXNzLCB3aGljaCBpcyB0 cmFuc2xhdGVkIHRvIElQdjQgcHVibGljIGFkZHJlc3MgdmlhIE5BVCwgIHdhbnQgdG8gZ2V0IElQ djYgZ3JvdXAgJiBJbnRlciBBcmVhIFdHIGZlZWRiYWNrIG9uIHRoZSBzdWJUTFYgcHJvcG9zZWQg aW4gdGhlIGRyYWZ0Og0KPiANCj4gRW5jYXBzRXh0IHN1Yi1UTFYgaXMgZm9yIGRlc2NyaWJpbmcg YWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgU0QtV0FOIHR1bm5lbCBlbmQtcG9pbnRz LCBzdWNoIGFzIE5BVCBwcm9wZXJ0eS4gQSBTRC1XQU4gZWRnZSBub2RlIGNhbiBpbnF1aXJlIFNU VU4gKFNlc3Npb24gVHJhdmVyc2FsIG9mIFVEUCBUaHJvdWdoIE5ldHdvcmsgQWRkcmVzcyBUcmFu c2xhdGlvbiBSRkMgMzQ4OSkgU2VydmVyIHRvIGdldCB0aGUgTkFUIHByb3BlcnR5LCB0aGUgcHVi bGljIElQIGFkZHJlc3MgYW5kIHRoZSBQdWJsaWMgUG9ydCBudW1iZXIgdG8gcGFzcyB0byBwZWVy cy4NCj4gDQo+ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgfEVuY2FwRXh0IFR5 cGUgIHwgIEVuY2FwRXh0IHN1YlRMViBMZW5ndGggICAgICAgfEl8T3xSfFJ8UnxSfFJ8UnwNCj4g ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQo+ICAgICB8IE5BVCBUeXBlICAgICAgfCAgRW5jYXAtVHlwZSAgIHxUcmFu cyBuZXR3b3JrSUR8ICAgICBSRCBJRCAgICAgfA0KPiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgIHwgICAg ICAgICAgICAgICAgUHJpdmF0ZSAgSVAgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQo+ICAgICAgICAgICAgIDMyLWJpdHMgZm9yIElQdjQsIDEyOC1iaXRzIGZvciBJcHY2DQo+ ICAgICAgICAgICAgICAgICAgICAgfn5+fn5+fn5+fn5+DQo+ICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAg fCAgICAgICAgICAgICAgICBQcml2YXRlICBQb3J0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCj4gICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICB8ICAgICAgICAgICAgICAgIFB1YmxpYyBJ UCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAz Mi1iaXRzIGZvciBJUHY0LCAxMjgtYml0cyBmb3IgSXB2Ng0KPiAgICAgICAgICAgICAgICAgICAg IH5+fn5+fn5+fn5+fg0KPiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgIHwgICAgICAgICAgICAgICAgUHVi bGljIFBvcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KPiANCj4gV2hlcmU6DQo+IG8gICAgICAgRW5jYXBFeHQgVHlwZTogaW5kaWNhdGUgaXQg aXMgdGhlIEVuY2FwRXh0IFN1YlRMVi4NCj4gbyAgICAgICBFbmNhcEV4dCBzdWJUTFYgTGVuZ3Ro OiB0aGUgbGVuZ3RoIG9mIHRoZSBzdWJUTFZFLg0KPiBvICAgICAgIEZsYWdzOg0KPiBvICAgICAg IEkgYml0OiBpZiBzZXQgdG8gMCwgaW5kaWNhdGUgdGhlIHByaXZhdGUgYWRkcmVzcyBpcyBJUHY0 LiBJZiBzZXQgdG8gMSwgaXQgaW5kaWNhdGVzIHRoZSBwcml2YXRlIGFkZHJlc3MgaXMgSVB2Ni4N Cj4gbyAgICAgICBPIGJpdDogaWYgc2V0IHRvIDAsIGluZGljYXRlIHRoZSBwdWJsaWMgYWRkcmVz cyBpcyBJUHY0LiBJZiBzZXQgdG8gMSwgaXQgaW5kaWNhdGVzIHRoZSBwdWJsaWMgYWRkcmVzcyBp cyBJUHY2Lg0KPiBvICAgICAgIFIgYml0czogcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuIE11c3Qg YmUgc2V0IHRvIDAgbm93Lg0KPiANCj4gbyAgICAgICBOQVQgVHlwZe+8mndpdGhvdXQgTkFUOyAx OjEgc3RhdGljIE5BVDsgRnVsbCBDb25lOyBSZXN0cmljdGVkIENvbmU7IFBvcnQgUmVzdHJpY3Rl ZCBDb25lOyBvciBTeW1tZXRyaWMNCj4gbyAgICAgICBFbmNhcCBUeXBl77yaU0QtV0FOIHR1bm5l bCBlbmNhcHN1bGF0aW9uIHR5cGVzLCBzdWNoIGFzIElQc2VjK0dSRSwgSVBzZWMrVnhMQU4sIElQ c2VjIHdpdGhvdXQgR1JFLCBHUkUgKHdoZW4gdHVubmVsIGlzIG92ZXIgc2VjdXJlIHVuZGVybGF5 IG5ldHdvcmspDQo+IG8gICAgICAgVHJhbnNwb3J0IE5ldHdvcmsgSUTvvJpDZW50cmFsIENvbnRy b2xsZXIgYXNzaWduIGEgZ2xvYmFsIHVuaXF1ZSBJRCB0byBlYWNoIHRyYW5zcG9ydCBuZXR3b3Jr 77ybDQo+IG8gICAgICAgUkQgSUTvvJpSb3V0aW5nIERvbWFpbiBJRO+8jE5lZWQgdG8gYmUgZ2xv YmFsIHVuaXF1ZS4NCj4gbyAgICAgICBQcml2YXRlIElQ77yaVGhlIGxvY2FsIElQIGFkZHJlc3Mg b2YgdGhlIHR1bm5lbCBlbmQtcG9pbnTvvJsNCj4gbyAgICAgICBQcml2YXRlIFBvcnTvvJp1c2Vk IGJ5IFJlbW90ZSBTRC1XQU4gbm9kZSBmb3IgZXN0YWJsaXNoaW5nIElQc2VjIHRvIHRoaXMgc3Bl Y2lmaWMgcG9ydC4NCj4gbyAgICAgICBQdWJsaWMgSVDvvJpUaGUgSVAgYWRkcmVzcyBhZnRlciB0 aGUgTkFULg0KPiBvICAgICAgIFB1YmxpYyBQb3J077yaVGhlIFBvcnQgYWZ0ZXIgdGhlIE5BVC4N Cj4gDQo+IA0KPiBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBmZWVkYmFjay4NCj4gDQo+IExpbmRh IER1bmJhcg0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlw djYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB0b20gcGV0Y2gN Cj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwMiwgMjAxOCAxMToyNiBQTQ0KPiBUbzogSm9lbCBK YWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPg0KPiBDYzogaXB2NkBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogcmVnaXN0ZXJpbmcgdHVubmVsIHR5cGVzDQo+IA0KPiAtLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCj4gRnJvbTogIkpvZWwgSmFlZ2dsaSIgPGpvZWxqYUBib2d1cy5jb20+DQo+IFRv OiAidG9tIHBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbT4NCj4gQ2M6IDxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPjsgPGlwdjZAaWV0Zi5vcmc+OyAiQWxleGFuZHJlIA0KPiBQZXRyZXNj dSIgPGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIE9jdG9i ZXIgMzAsIDIwMTggODoyMyBQTQ0KPiANCj4gPiBPbiBPY3QgMzAsIDIwMTgsIGF0IDA1OjA3LCB0 b20gcGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+DQo+ID4gQWxl eA0KPiA+DQo+ID4gSSBhZ3JlZSwgYXQgbGVhc3QgaW4gcGFydDsgdHVubmVscyBhbmQgaW50ZXJm YWNlcyBhcmUgZGlmZmVyZW50DQo+IGFuaW1hbHMNCj4gPiBhbmQgaXQgaXMgdW5mb3J0dW5hdGUg dGhhdCB0aGV5IHdlcmUgY29uZmxhdGVkIGluIFNNSS4NCj4gPg0KPiA+IEkgd2FzIHN1cnByaXNl ZCB0aGF0IE5FVE1PRCBoYWQgbm90IHByb2R1Y2VkIGEgWUFORyBtb2R1bGUgZm9yIA0KPiA+IHR1 bm5lbHMgYnV0IGl0IHNlZW1zIHRoYXQgdGhlcmUgaGFzIGJlZW4gbm8gbmVlZCBmb3IgdGhlIHBh c3QgDQo+ID4gZGVjYWRlLiAgVGhhdCBzYWlkLCBJIHRoaW5rIHRoYXQgaXQgaXMgYSBnb29kIGlk ZWEgdG8gaGF2ZSBvbmUuICANCj4gPiBXaGV0aGVyIG9yIG5vdCBpdCBzaG91bGQgbWlycm9yIHRo ZSBUdW5uZWwgTUlCIEkgZmluZCBtb3JlIGRlYmF0YWJsZS4NCj4gDQo+IEl04oCZcyBub3QgZW50 aXJlbHkgb2J2aW91cyB0byBtZSB0aGF0IG5ldHRlZCAvIG5ldGNvbmZpZyB3b3VsZCBiZSB3aGVy ZSB0aGUgdHVubmVsIG1vZGVscyB3ZXJlIHByb2R1Y2VkLg0KPiANCj4gVGhleSB0ZW5kIGlmIGZh Y3QgdG8gYmUgcHJvZHVjZWQgYnkgdGhlIHR1bm5lbCBwcm90b2NvbCBtYWludGFpbmVycyBlLmcu DQo+IGwzc20vbDJzbS9jY2FtcCBhbmQgc28gb24uIFRoZSBtYW5hZ2VtZW50IHRvb2xzIGZvciBh IHByb2R1Y3QgdGVuZCB0byBiZSBkZXZlbG9wZWQgaXRzZWxmIGluIG15IGV4cGVyaWVuY2UuDQo+ IA0KPiA8dHA+DQo+IA0KPiBKb2VsDQo+IA0KPiBNeSBjb25jZXJuIGlzIHRoYXQgc29tZXRoaW5n IHRoYXQgY3V0cyBhY3Jvc3MgYSBudW1iZXIgb2YgSUVURiBXRyBzaG91bGQgZ2V0IGFkZXF1YXRl IHJldmlldy4gIFRoZSBZQU5HIGludGVyZmFjZSBtb2R1bGUgd2FzIG11Y2ggZGlzY3Vzc2VkIGlu IHRoZSBuZXRtb2QgV0csIHdpdGggYW4gZXhpc3RpbmcgTUlCIGFzIGd1aWRhbmNlLCBiZWZvcmUg YmVjb21pbmcgYW4gUkZDLg0KPiANCj4gVGhlIHByb3Bvc2VkIFlBTkcgdHVubmVsIG1vZHVsZSwg d2hpY2ggYm9ycm93cyB0aGUgY29uY2VwdHMgb2YgdGhlIGludGVyZmFjZSBtb2R1bGUsIHRoYXQg YWRkaXRpb25zIHNob3VsZCBiZSBtYWRlIGJ5IHRoZSBUdW5uZWwgTUlCIERlc2lnbmF0ZWQgRXhw ZXJ0IHRvIGEgcmVnaXN0cnkgYW5kIHRoZW4gcHJvcGFnYXRlZCB0byB0aGUgVHVubmVsIE1JQiBh bmQgdGhlIFR1bm5lbCBZQU5HIG1vZHVsZSwgaGFzIG5vdCBiZWVuIGRpc2N1c3NlZCBpbiBhbnkg V0cuICBUaGUgcHJvcG9zYWwsIGFzIEkgbWVudGlvbmVkIGJlZm9yZSwgaGFzIGJlZW4gYWRkZWQg dG8gdGhlIEktRCBhZnRlciBJRVRGIExhc3QgQ2FsbCBoYXMgYmVlbiBjb21wbGV0ZWQgc28gYXBw ZWFycyB0byBtZSB0byBiZSB0aGUgd29yayBvZiBvbmUgaW5kaXZpZHVhbCwgd2l0aG91dCBhbnkg cmV2aWV3OyB0aGUgSS1EIGxpc3RzIHNldmVuIGVkaXRvcnMsIHNpeCBvZiB3aG9tIGFwcGVhciB0 byBiZSBhYnNlbnQuICBUaGVXRyBtYWlsaW5nIGxpc3Qgc2VlbXMgZGV2b2lkIG9mIGFueSBkaXNj dXNzaW9uLg0KPiANCj4gSSBiZWxpZXZlIHRoYXQgdGhlIElFVEYgc3VjY2VlZHMgYmVjYXVzZSBv ZiBwZWVyIHJldmlldywgYW5kIEkgc3RydWdnbGUgdG8gc2VlIHRoYXQgaGVyZS4NCj4gDQo+IFRv bSBQZXRjaA0KPiANCj4gPiBNeSBvd24gaG9tZXdvcmsgY2FtZSBhY3Jvc3Mgb3RoZXIgSVAgaW4g SVAgdmFyaWV0aWVzIHdoaWNoIGRvIG5vdCANCj4gPiBhcHBlYXIuDQo+ID4NCj4gPiBUb20gUGV0 Y2gNCj4gPg0KPiA+DQo+ID4+DQo+ID4+IEFsZXgNCj4gPj4NCj4gPj4+DQo+ID4+PiBJZiB5b3Ug bmVlZCBhIG5ldyB2YWx1ZSBvciBpZiB5b3UgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IGEgZ2l2ZW4N Cj4gPiBpbnRlcmZhY2UgdHVubmVsIHR5cGUsIHBsZWFzZSBmb2xsb3cgdGhlIGd1aWRlbGluZXMg aW4gdGhlIHVybCBjaXRlZCANCj4gPiBhYm92ZS4gQWxsIHRoaXMgaXMgb3V0IG9mIHRoZSBzY29w ZSBvZiBkcmFmdC1pZXRmLXNvZnR3aXJlLXlhbmcuDQo+ID4+Pg0KPiA+Pj4gQ2hlZXJzLA0KPiA+ Pj4gTWVkDQo+ID4+Pg0KPiA+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+Pj4+ IERlIDogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBB bGV4YW5kcmUNCj4gPiBQZXRyZXNjdQ0KPiA+Pj4+IEVudm95w6kgOiBqZXVkaSAyNSBvY3RvYnJl IDIwMTggMDk6NTQgw4AgOiBpcHY2QGlldGYub3JnIE9iamV0IDogUmU6DQo+ID4+Pj4gcmVnaXN0 ZXJpbmcgdHVubmVsIHR5cGVzDQo+ID4+Pj4NCj4gPj4+PiBBcmU6DQo+ID4+Pj4gLUlQdjYgaW4g VURQdjQgYW5kDQo+ID4+Pj4gLUlQdjYgaW4gSVB2NiBhcyB1c2VkIGJ5IG9wZW52cG47DQo+ID4+ Pj4NCj4gPj4+PiBjb3ZlcmVkIGJ5IHRoZSBsaXN0IGJlbG93Pw0KPiA+Pj4+DQo+ID4+Pj4gVGhl c2UgYXJlIGEgZmV3IHR1bm5lbGxpbmcgbWVjaGFuaXNtcyBJIHVzZSByb3V0aW5lbHkuDQo+ID4+ Pj4NCj4gPj4+PiBFeGlzdGluZyBpZGVudGl0eSA2dG9mb3VyIHNob3VsZCBiZSBkZXByZWNhdGVk LCBpZiB0aGF0IG1lYW5zIA0KPiA+Pj4+IDZ0bzQsIHdoaWNoIGlzIGRlcHJlY2F0ZWQuDQo+ID4+ Pj4NCj4gPj4+PiBFeGlzdGluZyBpZGVudGl0eSBpcGh0dHBzIGhhcyBhIHZlcnNpb24gbnVtYmVy IGZvciBJUD8NCj4gPj4+Pg0KPiA+Pj4+IEFsZXgNCj4gPj4+Pg0KPiA+Pj4+IExlIDI0LzEwLzIw MTggw6AgMTc6NTcsIHRvbSBwZXRjaCBhIMOpY3JpdCA6DQo+ID4+Pj4+IGRyYWZ0LWlldGYtc29m dHdpcmUteWFuZw0KPiA+Pj4+PiBjb21wbGV0ZWQgSUVURiBMYXN0IENhbGwgdHdvIHdlZWtzIGFn byBhbmQsIHNpbmNlIHRoZW4sIGhhcw0KPiA+IGFjcXVpcmVkIGENCj4gPj4+Pj4gWUFORyBtb2R1 bGUgdGhhdCBkZWZpbmVzIHR1bm5lbCB0eXBlcywgYXMgbGlzdGVkIGJlbG93LiAgSXQgaXMNCj4g PiBpbnRlbmRlZA0KPiA+Pj4+PiB0byBiZSBhIElBTkEtbWFpbnRhaW5lZCBtb2R1bGUgYW5kIHNv IGNoYW5nZXMgdG8gdGhlIGxpc3Qgb2YNCj4gPiB0dW5uZWxzDQo+ID4+Pj4+IHdpbGwgbm90IHJl cXVpcmUgYSByZWlzc3VlIG9mIHRoZSBzb2Z0d2lyZXMgUkZDLXRvLWJlLiAgQXQgdGhlDQo+ID4g c2FtZQ0KPiA+Pj4+PiB0aW1lLCBnZXR0aW5nIGl0IHJpZ2h0IGZpcnN0IHRpbWUgbmV2ZXIgZGlk IGFueSBoYXJtIHNvIGlmIA0KPiA+Pj4+PiBhbnlvbmUNCj4gPiBjYW4NCj4gPj4+Pj4gdGhpbmsg b2YgYW55IG1pc3NpbmcsIG9yIGNhbiB0aGluayBvZiBvdGhlciBwbGFjZXMgd2hlcmUgdGhlcmUN Cj4gPiBtaWdodCBiZQ0KPiA+Pj4+PiBvdGhlciB0dW5uZWxzIGx1cmtpbmcsIG5vdyB3b3VsZCBi ZSBhIGdvb2QgdGltZSB0byBtZW50aW9uIGl0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJdCBpcyBiYXNl ZCBvbiBSRkM0MDg3IFR1bm5lbCBNSUIgKHdoaWNoIGNyZWF0ZWQgYW4gU01JIFRleHR1YWwgDQo+ ID4+Pj4+IENvbnZlbnRpb24gdGhhdCB3ZW50IHVwIHRvIFRlcmVkbykgc28gdHVubmVscyBmcm9t IHRoYXQgdmludGFnZQ0KPiA+IGFyZQ0KPiA+Pj4+PiBsaWtlbHkgd2VsbCBjYXRlcmVkIGZvci4g IHNvZnR3aXJlcyBpcyBub3Qgd2hlcmUgSSB3b3VsZCBoYXZlDQo+ID4gZmlyc3QNCj4gPj4+Pj4g bG9va2VkIGZvciB0dW5uZWwgdHlwZXMsIGJ1dCBpdCBoYXMgYSBjZXJ0YWluIGxvZ2ljIHRvIGl0 Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBpZGVudGl0eSAgb3RoZXINCj4gPj4+Pj4NCj4gPj4+ Pj4gICAgICAgaWRlbnRpdHkgZGlyZWN0DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIGlkZW50aXR5 IGdyZQ0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBpZGVudGl0eSBtaW5pbWFsDQo+ID4+Pj4+DQo+ ID4+Pj4+ICAgICAgIGlkZW50aXR5IGwydHANCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgaWRlbnRp dHkgcHB0cA0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBpZGVudGl0eSBsMmYNCj4gPj4+Pj4NCj4g Pj4+Pj4gICAgICAgaWRlbnRpdHkgdWRwDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIGlkZW50aXR5 IGF0bXANCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgaWRlbnRpdHkgbXNkcA0KPiA+Pj4+Pg0KPiA+ Pj4+PiAgICAgICBpZGVudGl0eSBzaXh0b2ZvdXINCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgaWRl bnRpdHkgc2l4b3ZlcmZvdXINCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgaWRlbnRpdHkgaXNhdGFw DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIGlkZW50aXR5IHRlcmVkbw0KPiA+Pj4+Pg0KPiA+Pj4+ PiAgICAgICBpZGVudGl0eSBpcGh0dHBzDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIGlkZW50aXR5 IHNvZnR3aXJlbWVzaA0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBpZGVudGl0eSBkc2xpdGUNCj4g Pj4+Pj4NCj4gPj4+Pj4gICAgICAgaWRlbnRpdHkgIGFwbHVzcA0KPiA+Pj4+Pg0KPiA+Pj4+PiBU b20gUGV0Y2gNCj4gPj4+Pj4NCj4gPj4NCj4gPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+IC0tDQo+IC0N Cj4gPj4+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5v cmcgDQo+ID4+Pj4+IEFkbWluaXN0cmF0aXZlDQo+ID4+Pj4+IFJlcXVlc3RzOg0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+Pg0KPiA+Pj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4+Pj4gLS0NCj4gLQ0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+DQo+ID4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPj4+IC0tDQo+ID4+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0 IGlwdjZAaWV0Zi5vcmcgQWRtaW5pc3RyYXRpdmUNCj4gPj4+PiBSZXF1ZXN0czogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+DQo+ID4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4+IC0tDQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLSBJRVRGIElQdjYgd29ya2lu ZyBncm91cCBtYWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZyBBZG1pbmlzdHJhdGl2ZSANCj4gPj4g UmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVU RiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5vcmcgDQo+ID4gPG1h aWx0bzppcHY2QGlldGYub3JnPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IDxodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2 NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9y Zw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpWaWN0b3Jpb3VzIHdhcnJpb3JzIHdpbiBmaXJzdCBhbmQgdGhlbiBnbyB0byB3YXIsIERlZmVh dGVkIHdhcnJpb3JzIGdvIHRvIHdhciBmaXJzdCBhbmQgdGhlbiBzZWVrIHRvIHdpbi4NCiAgICAg U3VuIFR6dQ0KDQo= From nobody Mon Nov 5 02:42:13 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460C7130EC9; Mon, 5 Nov 2018 02:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 WoCMIPUJMPqU; Mon, 5 Nov 2018 02:41:49 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 B61E0130F52; Mon, 5 Nov 2018 02:41:49 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id g59-v6so4265138plb.10; Mon, 05 Nov 2018 02:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GAGHHHfxftLrorNtL5OvXrKs8BXlR583FqdRfaYJC0M=; b=BOj0EVeyTfmjOYrfwO5cNtGrz7yxPgEChJUtNAlZGZ/UfVo7uKg21t3F85Bn7xB8s1 scWbPU0pSDa0lhZq2pyVEGTiVBgZrb6l/5J3fd3iiijlwVAIG8e4CZrmTvkiy3har2Oo dcEOSp0CfbydE3S4n045+itxZyF6UhMzUs87bptbjAF+0cJuhw82pqY8GXxGNbDSs+er 3Ms15J6zaoYo2XYa8bJc8HMv8ppx+PDYciQiH5u0/E5ZfqvIZo4kPemmLwy+Y3UEiWdQ +L0oKFrnHLL+qKCB8z0ALv02jii6Vw+8PbprSCfhkxauoaWh8EUjlXX9ieaCljuRXWyW 7oMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GAGHHHfxftLrorNtL5OvXrKs8BXlR583FqdRfaYJC0M=; b=M88/WwrX0eIFNr2v44HK0KVrHoyzjPUVi93yo4wUeCgw5L4moKWdJIzxKHbfsL5vT/ A2nbXoFWXm1IvbuKvDSxIhljj+AeuvHk88VPUrhiWjUsVRP9w9WlXzFAWxVcjrHjidmZ I1bqScYMn7vK4bJ5JA31iAfPd+9eo8Emzu1XKuLa+QJ31uDobnIOeaGslc9QK+OuEOyT Nx9O3V7g7hgb69NS2mRTkwHipqlhBkhXse4IHuwUK0ZJjAha2bOf/k39LSF1Nd3S8HD1 CDIEbcoXrMeCNWqIoe80npFbnZyVhNyCBn1uThx31T3o/nNKWwyXbIN0X9p2PnvcQ4vl AkOA== X-Gm-Message-State: AGRZ1gJjd/w+f01+VUrC2rR4uiJ1IQilJauMsVS8sdU7KLMuV9vvC5iA bcLo7+yanJY5pB9Km0yjeDo= X-Google-Smtp-Source: AJdET5ce4QO7V73KkW0Ine5TnDOXHl1vRXDGylo79fRZUuvOBDvQS1KbvjhxONegPwSfotK88REscQ== X-Received: by 2002:a17:902:8b8a:: with SMTP id ay10-v6mr21537019plb.130.1541414509320; Mon, 05 Nov 2018 02:41:49 -0800 (PST) Received: from dhcp-94bc.meeting.ietf.org (dhcp-94bc.meeting.ietf.org. [31.133.148.188]) by smtp.gmail.com with ESMTPSA id i189-v6sm33505603pfg.156.2018.11.05.02.41.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 02:41:48 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5B6B8F97-23B3-4304-8444-FCA742B0B33D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Date: Mon, 5 Nov 2018 17:41:41 +0700 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> Cc: tom petch , Joel Jaeggli , "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 10:41:58 -0000 --Apple-Mail=_5B6B8F97-23B3-4304-8444-FCA742B0B33D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 5, 2018, at 5:40 PM, Linda Dunbar = wrote: >=20 > If a CPE-1 has private IPv6 addresses for its ports behind NAT, and = CPE-2 has IPv4 address, can CPE-1 communicate with CPE-2 by the NAT's = IPv4 address? There is no such thing as an IPv6 private address. I'm not sure how to = respond to the question. = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_5B6B8F97-23B3-4304-8444-FCA742B0B33D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvgHmUACgkQEhdRnd2G P+CX6g/+OJSfGBFZXtKFLPVQaD/pPTSrfAXEW74spKzGdi/PMg4z3LwcV+zzjLLl 5V4xtfDu/g9wDEA6tkFK4RUaBOTT7bx/uTsV5uiLCpOZJQOXgu9HzN0NGHWwWq+B 1SrCQVUU3XbFCTd6zqWP8qdHHZ+wxovxQfq9TB+ZfI4FBk4KpoR2u1GrcgJzjQbo atm5hYB2D0A6jVHGamw8rrBu/wcDYscBRL3n5+I91iTmHppTk08+PTKzq0IH9JXd zsYnoxbUH5PINliTnaBjgqIXVjGsVjLNAEVSKKHHENcwE546GR4R0sS+c+RKZ0ZW oRlH9eljpXCCw6DVxBVaoLN64CutO8b6IQX/WMGOyBK+JO2ip1C1kGIApmR0vyGF j8pef4SS1pFIITO/CXzFSdJRS/XibmUz9mF3lLxeuzvOhSKOmQlFBYm4HoVulI59 wYI/xaZ/acBb20eIGt1c8L1ZC9QVeiwL/IcYGMPrO63uf73wX10mu/oOUrWPLvqE N4JjeShbfm/SOZcOLzSqFSus4JiWxzRlgc2echmuz62x1OPeH9bLuBQnBnozS9zM tBWK/cpSoDxesxbH9JsFnHQNeZXUeSE1xS1vnsRcX7/4JnRVRvNpNdSd1KObq2cb 70hrBohZv58ZeqphrOiYl1RYbvuKIQmcGpStSSv3MwA9yIrF6Mw= =ZVHV -----END PGP SIGNATURE----- --Apple-Mail=_5B6B8F97-23B3-4304-8444-FCA742B0B33D-- From nobody Mon Nov 5 02:44:29 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC12012EB11; Mon, 5 Nov 2018 02:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xRI3UC1y4yJE; Mon, 5 Nov 2018 02:44:13 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 678FE130934; Mon, 5 Nov 2018 02:44:13 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1096BAF6A66C0; Mon, 5 Nov 2018 10:44:10 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 10:44:11 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.103]) by SJCEML701-CHM.china.huawei.com ([169.254.3.13]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 02:44:06 -0800 From: Linda Dunbar To: Fred Baker CC: tom petch , Joel Jaeggli , "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" Subject: RE: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AdR0BGE++Z0BF4I3RCC8M7+3nc3iHQBDGb8AAAd6+dAAAh9GgAAQuA7Q Date: Mon, 5 Nov 2018 10:44:05 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B182BBD@sjceml521-mbs.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.174.222] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 10:44:15 -0000 Fred,=20 How does my phone (being IPv6 address) communicate with a web server that i= s IPv4 public address?=20 Linda -----Original Message----- From: Fred Baker [mailto:fredbaker.ietf@gmail.com]=20 Sent: Monday, November 05, 2018 5:42 PM To: Linda Dunbar Cc: tom petch ; Joel Jaeggli ; idr@i= etf.org; int-area@ietf.org; ipv6@ietf.org Subject: Re: Using BGP to advertise SD-WAN tunnels end point's private IPv6= addresses. (was registering tunnel types > On Nov 5, 2018, at 5:40 PM, Linda Dunbar wrote: >=20 > If a CPE-1 has private IPv6 addresses for its ports behind NAT, and CPE-2= has IPv4 address, can CPE-1 communicate with CPE-2 by the NAT's IPv4 addre= ss? There is no such thing as an IPv6 private address. I'm not sure how to resp= ond to the question. ---------------------------------------------------------------------------= ----- Victorious warriors win first and then go to war, Defeated warriors go to w= ar first and then seek to win. Sun Tzu From nobody Mon Nov 5 03:12:07 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E70130F0E for ; Mon, 5 Nov 2018 03:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 VU85XAxJTHjJ for ; Mon, 5 Nov 2018 03:11:57 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 15405130DD3 for ; Mon, 5 Nov 2018 03:11:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wA5BBsZR019513; Mon, 5 Nov 2018 12:11:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 720C7204346; Mon, 5 Nov 2018 12:11:54 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 637912043EF; Mon, 5 Nov 2018 12:11:54 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wA5BBsSN023323; Mon, 5 Nov 2018 12:11:54 +0100 Subject: Re: IPv6 on WIMAX 16e To: bernice kibet References: Cc: ipv6@ietf.org From: Alexandre Petrescu Message-ID: Date: Mon, 5 Nov 2018 12:11:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 11:12:06 -0000 I thought WiMAX per se was no longer relevant? Where I live, the frequency band initially allocated to WiMAX use (3.5GHz) seems to be heading towards re-allocation for 5G use. Is the group 802.16e still active? If there were something IPv6 to be done about 802.16e, then it should be about getting rid of the IPv4 lower layer of encapsulation. Alex Le 03/11/2018 à 12:40, bernice kibet a écrit : > Hello, > > Any advise on ipv6 transition on WIMAX 16 e. P2P not up on WIMAX 16e but > up on WIMAX 16d. > > Regards, > Bernice > > > Re > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Nov 5 03:15:38 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEA6128DFD for ; Mon, 5 Nov 2018 03:15:36 -0800 (PST) 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 wp3nYPXz23CQ for ; Mon, 5 Nov 2018 03:15:34 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA750127133 for ; Mon, 5 Nov 2018 03:15:33 -0800 (PST) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wA5AF0Ba019034 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2018 10:15:00 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Brian E Carpenter Cc: ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> From: Nick Hilliard Message-ID: Date: Mon, 5 Nov 2018 11:15:31 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 11:15:36 -0000 Brian E Carpenter wrote on 05/11/2018 07:38: > And yes, a host MAY ignore it (that's the complement to the SHOULD > in the draft). We've never said anything else. yes, but you have stated "On an IPv6-Only link, IPv4 might be used for malicious purposes and pass unnoticed by IPv6-Only monitoring mechanisms". If you want ipv6only-flag to be advisory, then you need to remove this bullet-point from the document because the presence or absence of an RA with ipv6only-flag set will not have any effect on malicious use of ipv4 on an otherwise "ipv6-only" network. You cannot use security to justify something unless the proposal provides a mechanism for enforcement; if you have no means of enforcement, it's fluff, not security. Nick From nobody Mon Nov 5 03:49:38 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A12128CFD for ; Mon, 5 Nov 2018 03:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 ySvRmEIJKN3f for ; Mon, 5 Nov 2018 03:49:34 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 6D4BD1277CC for ; Mon, 5 Nov 2018 03:49:34 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wA5BnWgr009193 for ; Mon, 5 Nov 2018 12:49:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 45C382043D0 for ; Mon, 5 Nov 2018 12:49:32 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3C1032042CE for ; Mon, 5 Nov 2018 12:49:32 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wA5BnV7j006276 for ; Mon, 5 Nov 2018 12:49:32 +0100 Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> From: Alexandre Petrescu Message-ID: <95330b88-890b-731e-236b-e25d96c738d6@gmail.com> Date: Mon, 5 Nov 2018 12:49:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 11:49:37 -0000 Le 05/11/2018 à 12:15, Nick Hilliard a écrit : > Brian E Carpenter wrote on 05/11/2018 07:38: >> And yes, a host MAY ignore it (that's the complement to the SHOULD >> in the draft). We've never said anything else. > > yes, but you have stated "On an IPv6-Only link, IPv4 might be used for > malicious purposes and pass unnoticed by IPv6-Only monitoring mechanisms". > > If you want ipv6only-flag to be advisory, then you need to remove this > bullet-point from the document because the presence or absence of an RA > with ipv6only-flag set will not have any effect on malicious use of ipv4 > on an otherwise "ipv6-only" network. > > You cannot use security to justify something unless the proposal > provides a mechanism for enforcement; if you have no means of > enforcement, it's fluff, not security. Well there is the Secure Neighbor Discovery protocol (SeND). With it one can claim the link to be secure if IPv6-Only and insecure if IPv4 is present. Simpler but less strong than SeND, there can be mechanisms to ensure a certain level of security, about the MAC address in the L2 header of the RA. Alex > > Nick > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Nov 5 03:52:29 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB245127133; Mon, 5 Nov 2018 03:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 (1024-bit key) header.d=nokia.onmicrosoft.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 xO5K2UNAYhia; Mon, 5 Nov 2018 03:52:07 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00111.outbound.protection.outlook.com [40.107.0.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C78D1277CC; Mon, 5 Nov 2018 03:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lcXvL1M5O3Rfnf0b9gaC9cQvBp7qSOBqQcVD74BDBcU=; b=PDuRR4J8Tj9yiHznPkxBy8swJ1s2RUEehK/x9hauyd3uQpzdo0sGvfm9oxtMSgHeo0z8yRXekMomnZ7vEGPW9IsLIkGTzxwI48ldviDdfzUju5M2J83tBTxV/evstqi2BC6gRVZs295YAtJIBdDlm6TdwO5xb4GofkZk44XgU+E= Received: from DB6PR07MB3477.eurprd07.prod.outlook.com (10.175.234.32) by DB6PR07MB3063.eurprd07.prod.outlook.com (10.175.235.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Mon, 5 Nov 2018 11:52:05 +0000 Received: from DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686]) by DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686%2]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 11:52:05 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Fred Baker , Linda Dunbar CC: "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AQHUdPQP+ZmmSSJuak+m74M0Ps0ZxKVA/l6AgAAkbQA= Date: Mon, 5 Nov 2018 11:52:04 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.12.0.181014 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-originating-ip: [110.170.235.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3063; 6:hmQaBZY87hcWaGll+8L5XdrJgsgXVIrWeltc7tO0SZXuY+PqrsCbQjs5n8bwXaCQY6sO8fywdlHZreuJrOurlDWE6Z/tzkRnt55ZA/oBqIYi7cqEPizZYl2NcpeymUTQNdJd3n87vsY6pCuvlPamSVi6Q+RrvlA59N7V/IH8O3wKbbO14ob9fWFDgsaff8He24Bca3PGdpCm23KpfNQmRKZ7HKLUJUZ8u4ScQ03xgGGdr9UzXkIbLARIKfPtvtjfF9PCCjTbVURJEizZ+dfWuYK6JjBL7JUU5sp8eBWH6Tp2A0alapM0F952KcwRZtmwTamh9n8p/DBBcq+OsUkuVve/R4JzJOeMHp+mu3UGHkvWzwwpdcaScB7yuTk2HXONNGwugDSfbgq3zOZMs6z2FGvwOou2kFtVMCm8AX7DZyb8gH3buhGkK678UKamUAHhz8Ow72o/VnYy86C3nDDOZw==; 5:iYA21awqFtp1Bocz/gRiCvwPZ/z7WPdE1Um/67F+f9zWNNFPTNQuzQMkJqQEpgypYMU2s4iIgyllOmhU1mldIkBkZy/UFTmLM0SgTsThWDCTDz7RH+wy1OW1KYZLh4oGBQXCWNJbSS1tbb5R/xM2+Md+eQrKjp7+3rAr6WeLIow=; 7:4viIW/KEMNWOjlp8PU2VBp5cAoTVt8wRyhL4neqzzc8xlZVnstonoh7H2LgL3ZCyawuV9XvO/XagXUQH4rp48RASY76+019vZaWd0Czzm/piS2cNdme/tAZ0VBkoxwPzySutfEEyGT1yUUSj59ZYSw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 22630125-461f-4dd7-b03d-08d643151b4c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7167020)(7193020); SRVR:DB6PR07MB3063; x-ms-traffictypediagnostic: DB6PR07MB3063: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(50582790962513); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB6PR07MB3063; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3063; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(396003)(376002)(136003)(189003)(199004)(110136005)(54906003)(186003)(26005)(93886005)(229853002)(478600001)(14454004)(58126008)(7736002)(2616005)(446003)(476003)(486006)(25786009)(81156014)(81166006)(305945005)(316002)(11346002)(8936002)(66066001)(256004)(8676002)(86362001)(53546011)(6506007)(68736007)(82746002)(76176011)(97736004)(83716004)(3846002)(33656002)(99286004)(6116002)(39060400002)(71200400001)(71190400001)(4326008)(6246003)(55236004)(102836004)(2906002)(5660300001)(6486002)(6512007)(6436002)(53936002)(105586002)(2900100001)(106356001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB3063; H:DB6PR07MB3477.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5Bcrppqs/yf/omJPnHkl3kLQTfe2TGnq/KtanNAIwW8QDop8riliIP8MpSHdlxLiGueZEv4pSeIVUDJkWukJhH/EWfBkEAsiiIzN2gjEnFWK3rw5KKoUpQ7NpWmJ9LGZKESX42QqMoWy0Xr/fAPFwEYlQHVBxxCFIGnvQ1+kYk90MKyT/cKyrS9+/X7xBnhm1QG4VZir5O3B2A7Dc0hZTW69BsNTQcwpQpm3F3eUSAAeydFCyfhAgn0UcM+rV3SulCkJaiKQT9XnvK7zUAR0ZWFnrvnOK4jVrIR11fGhn68qImuOWhamxX0Da/6Hrc8H7/+xDYnClwtCIg9sBi3z+a+F/xo458sYk+UpxUFiTFk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <36885E41B8E4C346A71484C1629BD1BD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22630125-461f-4dd7-b03d-08d643151b4c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 11:52:04.9597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3063 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 11:52:10 -0000 SW4gU0QtV0FOIGN0eHQsIHRvIGxldCBhIHNpdGUgd2hpY2ggaGFzIElQdjQgb24gdGhlIFdBTiB0 YWxrIHRvIGFub3RoZXIgc2l0ZSB3aGljaCBoYXMgIElQdjYgb24gdGhlIFdBTiwgd2Ugd2lsbCBu ZWVkIHRvIHNlbmQgdGhlIHBhY2tldHMgdG8gYSBkZXZpY2Ugd2hvIGNhbiBtYXAgdGhlIHY0IGFk ZHJlc3MgdG8gYSB2NiBhZGRyZXNzIChubyBOQVQsIGJ1dCBtYXBwZWQgSSBjYWxsIGl0KS4gVGhl IG1hcHBpbmcgdGFibGUgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBOQVQgYW5kIGlzIHNldHVwIGJ5 IGEgY29udHJvbGxlciBpbiBtb3N0IHNvbHV0aW9ucy4NCg0KTm93IHRoaXMgaXMgd29ya2luZyBp cnJlc3BlY3RpdmUgaWYgdGhlIHY0IHNpdGUgaXMgTkFUZWQgIChvbmUgd2F5IG9yIGFub3RoZXIp IG9yIG5vdC4NCg0K77u/T24gMDUvMTEvMjAxOCwgMTc6NDIsICJJZHIgb24gYmVoYWxmIG9mIEZy ZWQgQmFrZXIiIDxpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZnJlZGJha2VyLmll dGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIA0KICAgIA0KICAgID4gT24gTm92IDUsIDIwMTgs IGF0IDU6NDAgUE0sIExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3Rl Og0KICAgID4gDQogICAgPiBJZiBhIENQRS0xIGhhcyBwcml2YXRlIElQdjYgYWRkcmVzc2VzIGZv ciBpdHMgcG9ydHMgYmVoaW5kIE5BVCwgYW5kIENQRS0yIGhhcyBJUHY0IGFkZHJlc3MsIGNhbiBD UEUtMSBjb21tdW5pY2F0ZSB3aXRoIENQRS0yIGJ5IHRoZSBOQVQncyBJUHY0IGFkZHJlc3M/DQog ICAgDQogICAgVGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhbiBJUHY2IHByaXZhdGUgYWRkcmVz cy4gSSdtIG5vdCBzdXJlIGhvdyB0byByZXNwb25kIHRvIHRoZSBxdWVzdGlvbi4NCiAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIFZpY3RvcmlvdXMgd2FycmlvcnMgd2luIGZpcnN0IGFu ZCB0aGVuIGdvIHRvIHdhciwNCiAgICBEZWZlYXRlZCB3YXJyaW9ycyBnbyB0byB3YXIgZmlyc3Qg YW5kIHRoZW4gc2VlayB0byB3aW4uDQogICAgICAgICBTdW4gVHp1DQogICAgDQogICAgDQoNCg== From nobody Mon Nov 5 04:13:54 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AEA1298C5 for ; Mon, 5 Nov 2018 04:13:53 -0800 (PST) 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 92T-2TyGqTXd for ; Mon, 5 Nov 2018 04:13:51 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E9B1277CC for ; Mon, 5 Nov 2018 04:13:50 -0800 (PST) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wA5BDGfq026713 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2018 11:13:17 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Alexandre Petrescu Cc: ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> <95330b88-890b-731e-236b-e25d96c738d6@gmail.com> From: Nick Hilliard Message-ID: <219d0746-affa-a993-9b0e-fa12b79383ae@foobar.org> Date: Mon, 5 Nov 2018 12:13:47 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.4 MIME-Version: 1.0 In-Reply-To: <95330b88-890b-731e-236b-e25d96c738d6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 12:13:54 -0000 Alexandre Petrescu wrote on 05/11/2018 11:49: > Well there is the Secure Neighbor Discovery protocol (SeND).  With it > one can claim the link to be secure if IPv6-Only and insecure if IPv4 is > present. well, there isn't because the presence or absence of SEND won't stop anyone from using ipv4, particularly if the use case is malicious. > Simpler but less strong than SeND, there can be mechanisms to ensure a > certain level of security, about the MAC address in the L2 header of the > RA. "secure" mac addresses can only be deployed if the network supports l2 filtering at the user edge, in which case the ipv6only flag is largely pointless because you can make ipv4 go away with the same style of ACL, with the added benefit that it will actually make your network ipv6-only. Nick From nobody Mon Nov 5 07:51:13 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5DE130DF7 for ; Mon, 5 Nov 2018 07:51:12 -0800 (PST) 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, 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 5fSSA_AU61RX for ; Mon, 5 Nov 2018 07:51:05 -0800 (PST) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA79A130DD4 for ; Mon, 5 Nov 2018 07:51:04 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 392FD8D4A216; Mon, 5 Nov 2018 15:51:01 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 298DDD1F96E; Mon, 5 Nov 2018 15:51:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 0LHZ0ieaUTK8; Mon, 5 Nov 2018 15:50:59 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id EC9BCD1F83A; Mon, 5 Nov 2018 15:50:58 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Lee Howard" Cc: "Brian E Carpenter" , ipv6@ietf.org Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Date: Mon, 05 Nov 2018 15:50:59 +0000 X-Mailer: MailMate (2.0BETAr6126) Message-ID: <6D0D242D-96C4-4F09-9028-ED388B9392C3@lists.zabbadoz.net> In-Reply-To: <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 15:51:12 -0000 On 5 Nov 2018, at 6:06, Lee Howard wrote: > I have counted zero host operating system implementers who have said > they will take action on this flag, but check my math. Well, given you are replying to a thread that has “you have running code” in the Subject, check your math*s* please. You have 1 OS with an implementation already (both router and basic host side). If this draft moves forward I’ll make sure the “basic” can be removed from that sentence as well. It’s about 50 LoC. Double it and dhclient no longer tries to run either and I’ll have RX side filters as well as well as IPv4 configuration being degraded to run after IPv6. That’s about the end of the story. Can be implemented and tested in a few hours. Sample code exists. /bz From nobody Mon Nov 5 08:23:52 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF890130F1F; Mon, 5 Nov 2018 08:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7rXEYueq6ezQ; Mon, 5 Nov 2018 08:23:22 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2881A130E7D; Mon, 5 Nov 2018 08:23:22 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 99F799B2EA70A; Mon, 5 Nov 2018 16:23:18 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 16:23:20 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.103]) by SJCEML702-CHM.china.huawei.com ([169.254.4.237]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 08:23:16 -0800 From: Linda Dunbar To: "Henderickx, Wim (Nokia - BE/Antwerp)" , "Fred Baker" CC: "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" Subject: RE: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AQHUdP39JxtZsSK87kCi+BjaMuwg9KVBUglA Date: Mon, 5 Nov 2018 16:23:16 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B182E67@sjceml521-mbs.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.173.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 16:23:30 -0000 U28gd2UgbmVlZCB0byBhZGQgYW5vdGhlciB0eXBlIHRvIHRoZSBzdWJUTFY6IE1hcHBpbmcgKGZv ciB0aGUgc2NlbmFyaW8gb2YgQ1BFIHVzaW5nIElQdjYsIGJlaW5nIHRyYW5zbGF0ZWQgdG8gSVB2 NCB0byBjb25uZWN0IHRvIGl0cyBwZWVyIHRoYXQgdXNlcyBJUHY0LCBjb3JyZWN0Pw0KDQpMaW5k YQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGVuZGVyaWNreCwgV2ltIChO b2tpYSAtIEJFL0FudHdlcnApIFttYWlsdG86d2ltLmhlbmRlcmlja3hAbm9raWEuY29tXSANClNl bnQ6IE1vbmRheSwgTm92ZW1iZXIgMDUsIDIwMTggNjo1MiBQTQ0KVG86IEZyZWQgQmFrZXIgPGZy ZWRiYWtlci5pZXRmQGdtYWlsLmNvbT47IExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdl aS5jb20+DQpDYzogaWRyQGlldGYub3JnOyBpbnQtYXJlYUBpZXRmLm9yZzsgaXB2NkBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtJZHJdIFVzaW5nIEJHUCB0byBhZHZlcnRpc2UgU0QtV0FOIHR1bm5l bHMgZW5kIHBvaW50J3MgcHJpdmF0ZSBJUHY2IGFkZHJlc3Nlcy4gKHdhcyByZWdpc3RlcmluZyB0 dW5uZWwgdHlwZXMNCg0KSW4gU0QtV0FOIGN0eHQsIHRvIGxldCBhIHNpdGUgd2hpY2ggaGFzIElQ djQgb24gdGhlIFdBTiB0YWxrIHRvIGFub3RoZXIgc2l0ZSB3aGljaCBoYXMgIElQdjYgb24gdGhl IFdBTiwgd2Ugd2lsbCBuZWVkIHRvIHNlbmQgdGhlIHBhY2tldHMgdG8gYSBkZXZpY2Ugd2hvIGNh biBtYXAgdGhlIHY0IGFkZHJlc3MgdG8gYSB2NiBhZGRyZXNzIChubyBOQVQsIGJ1dCBtYXBwZWQg SSBjYWxsIGl0KS4gVGhlIG1hcHBpbmcgdGFibGUgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBOQVQg YW5kIGlzIHNldHVwIGJ5IGEgY29udHJvbGxlciBpbiBtb3N0IHNvbHV0aW9ucy4NCg0KTm93IHRo aXMgaXMgd29ya2luZyBpcnJlc3BlY3RpdmUgaWYgdGhlIHY0IHNpdGUgaXMgTkFUZWQgIChvbmUg d2F5IG9yIGFub3RoZXIpIG9yIG5vdC4NCg0K77u/T24gMDUvMTEvMjAxOCwgMTc6NDIsICJJZHIg b24gYmVoYWxmIG9mIEZyZWQgQmFrZXIiIDxpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgZnJlZGJha2VyLmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIA0KICAgIA0KICAgID4g T24gTm92IDUsIDIwMTgsIGF0IDU6NDAgUE0sIExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1 YXdlaS5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiBJZiBhIENQRS0xIGhhcyBwcml2YXRlIElQ djYgYWRkcmVzc2VzIGZvciBpdHMgcG9ydHMgYmVoaW5kIE5BVCwgYW5kIENQRS0yIGhhcyBJUHY0 IGFkZHJlc3MsIGNhbiBDUEUtMSBjb21tdW5pY2F0ZSB3aXRoIENQRS0yIGJ5IHRoZSBOQVQncyBJ UHY0IGFkZHJlc3M/DQogICAgDQogICAgVGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhbiBJUHY2 IHByaXZhdGUgYWRkcmVzcy4gSSdtIG5vdCBzdXJlIGhvdyB0byByZXNwb25kIHRvIHRoZSBxdWVz dGlvbi4NCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIFZpY3RvcmlvdXMgd2Fycmlv cnMgd2luIGZpcnN0IGFuZCB0aGVuIGdvIHRvIHdhciwNCiAgICBEZWZlYXRlZCB3YXJyaW9ycyBn byB0byB3YXIgZmlyc3QgYW5kIHRoZW4gc2VlayB0byB3aW4uDQogICAgICAgICBTdW4gVHp1DQog ICAgDQogICAgDQoNCg== From nobody Mon Nov 5 09:00:32 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A93130E17 for ; Mon, 5 Nov 2018 09:00:12 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] 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 Y-En8a-0b5TW for ; Mon, 5 Nov 2018 09:00:11 -0800 (PST) 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 4161F130E0C for ; Mon, 5 Nov 2018 09:00:05 -0800 (PST) X-Original-To: ipv6@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C795F41C36 for ; Mon, 5 Nov 2018 17:59:59 +0100 (CET) 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 B707C41C11; Mon, 5 Nov 2018 17:59:59 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id A84537D15; Mon, 5 Nov 2018 17:59:59 +0100 (CET) Date: Mon, 5 Nov 2018 17:59:59 +0100 From: Gert Doering To: Linda Dunbar Cc: Fred Baker , "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Message-ID: <20181105165959.GB11393@Space.Net> References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 17:00:13 -0000 Hi, On Mon, Nov 05, 2018 at 10:40:36AM +0000, Linda Dunbar wrote: > If a CPE-1 has private IPv6 addresses for its ports behind NAT, and CPE-2 has IPv4 address, can CPE-1 communicate with CPE-2 by the NAT's IPv4 address? Since there are no private IPv6 addresses, no. Generally speaking, if CPE1 has only IPv6 addresses and CPE2 has only an IPv4 address, the answer is no as well, unless there is a NAT64 involved somewhere. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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 Mon Nov 5 11:37:49 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1AB130E10 for ; Mon, 5 Nov 2018 11:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 E_hEfsRv-UGJ for ; Mon, 5 Nov 2018 11:37:45 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 9EB071277D2 for ; Mon, 5 Nov 2018 11:37:45 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id y18-v6so2520755pfn.1 for ; Mon, 05 Nov 2018 11:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lTavgP8FeoM3Xgdjxa4LAJk3sRbfR8dfALh8SLcJW6Y=; b=rySOmNesnoNqubWDqc37Re4i+TneffEZ0G8u1NzJgG3eigbyjBqU5tlFb2Etp08nky u42k5vz/FeX+6Pw+CtaFdCo4EIw3BUi647I4UtfniIp7LkyQZl3pFMXUc4sbeeSlF0X+ ttMAgiKNeLlBNH9uoIhI6lwmagTqCFN2o4jsvpqv0GbXi2SKskgTezrFaPXTyEkul5KD QF783GWSliDHKVk8PgB3PzBN7Dvtk3EmpivNTdp/Seb4y4NUPwMIJNlS1tOFXqQVYk7z mLVn3OyrKqxreQhZN7WeH3wMYINCiB3R/I8y+i8RiT2s5FKQbgctQQjfZ6V+P93Vsa3Y ERPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lTavgP8FeoM3Xgdjxa4LAJk3sRbfR8dfALh8SLcJW6Y=; b=efmgseGhVtiIbHS/MZKEuoucH6rz44WYGYXfObtX1GPyoDe66IYqcDGdfd3YbbsFCp JBjzyP/B03McuKBSIuD5WBwfsIOlTqVG4Lx3itTtt6i1S7SuIqA+5VXIctt1pYYb3fSI rwiUdjiczQvvQlgixIur9bXl2cq6rSnRbEYXFX6eWWqU+7N1kVDxX1oI6xOPkVM8aTLS bYLnjiOH6BjMmDfpVr4zj8lRapPM5Yuk4mXOhfMSTr0ZMIkR282hL2YwS6Ughc/PZvIw Aq9E/srhkP1NlqsfUTeuuxXY/74qtYFluUDGfoD3xgjeELCMKIYb726hwMz0F9EM6AQY QRGA== X-Gm-Message-State: AGRZ1gI3bJbefd99ww8RmxqeDyWAJKl2IpW6oPrPygyn85AcF7FzPJXp acSNRToFW3iwYG+fE0bfE4gyQS/8 X-Google-Smtp-Source: AJdET5dS/7ngn7hCEQyAkRqgrtdDkS8kt14wUtNtT2u8YNmlE5ZhSpQWLudH6KR5jnVK4HAYRmtZ2A== X-Received: by 2002:a63:2744:: with SMTP id n65mr21050360pgn.65.1541446664770; Mon, 05 Nov 2018 11:37:44 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id 80-v6sm13404587pfv.154.2018.11.05.11.37.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 11:37:43 -0800 (PST) Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt To: Nick Hilliard Cc: ipv6@ietf.org References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> From: Brian E Carpenter Message-ID: <10a71216-7aed-8089-3b6c-a8f952daaf4c@gmail.com> Date: Tue, 6 Nov 2018 08:37:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 19:37:47 -0000 On 2018-11-06 00:15, Nick Hilliard wrote: > Brian E Carpenter wrote on 05/11/2018 07:38: >> And yes, a host MAY ignore it (that's the complement to the SHOULD >> in the draft). We've never said anything else. > > yes, but you have stated "On an IPv6-Only link, IPv4 might be used for > malicious purposes and pass unnoticed by IPv6-Only monitoring mechanisms". > > If you want ipv6only-flag to be advisory, then you need to remove this > bullet-point from the document because the presence or absence of an RA > with ipv6only-flag set will not have any effect on malicious use of ipv4 > on an otherwise "ipv6-only" network. Yes, you're correct. There is a slight mitigation effect - hosts that *do* use the flag to shut down IPv4 operations will not see any malicious IPv4 traffic. Some rewording is needed. > You cannot use security to justify something unless the proposal > provides a mechanism for enforcement; if you have no means of > enforcement, it's fluff, not security. > > Nick Thanks Brian From nobody Mon Nov 5 13:28:04 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E0B123FFD; Mon, 5 Nov 2018 13:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 rYCr5r0Tq6Qz; Mon, 5 Nov 2018 13:28:00 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0A2130DC0; Mon, 5 Nov 2018 13:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20236; q=dns/txt; s=iport; t=1541453279; x=1542662879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AtfJnZ+ptXON6SIAstxfGv8Eg9LJSmcYwIduZhjZGac=; b=YlfcCHrM2LG05SGIs73DKFwUfFKMTpDGfdBVTFWEfkpkwECLubOBSVsA QB+KGA0ZZ77fgXGOtcZ5rw+M+2EHVcmyyMYVuGNWKCYsaoSWCP4kzrnZQ WBaVRS8aPjFenwPqC+vy32t2YJL5hEFZOR1prYuVtuo5grSZ1qBgeTUdJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAKteBb/51dJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmfygKg2yIGIwYgWglly2BegsBARg?= =?us-ascii?q?LCYRAAheDOiI0DQ0BAwEBAgEBAm0cDIU6AQEBAQIBAQEhETMHCwUHBAIBBgI?= =?us-ascii?q?RBAEBAQICIwMCAgIlCxQBCAgCBA4FgyEBgXkID48om0+BLoodBYELimsXgUE?= =?us-ascii?q?/gREnDBOCTIMbAQGBYQcxAoJKMYImAohlIQOBa5NqVAkCh3CJHxiBVYUAigu?= =?us-ascii?q?CbpQxAhEUgSYdOIFVcBU7KgGCQYInBRKIXYU+bwGBJ4ogB4EnAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.54,469,1534809600"; d="scan'208";a="480274321" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 21:27:57 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id wA5LRvhQ002267 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Nov 2018 21:27:57 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 5 Nov 2018 15:27:56 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Mon, 5 Nov 2018 15:27:56 -0600 From: "Darren Dukes (ddukes)" To: "Chengli (Cheng Li)" CC: Joel Halpern , "spring@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Lizhenbin , Mach Chen Subject: Re: SRv6 - SRH in encaps or base header - point 2 Thread-Topic: SRv6 - SRH in encaps or base header - point 2 Thread-Index: AQHUampMSmaiE2sUnkOZwbcZBqOzaaUyIfaAgAAQcoCABlqwgIAAiTcAgAQfoYCAA+FHgIABFVwA Date: Mon, 5 Nov 2018 21:27:56 +0000 Message-ID: <0CA05243-FAC4-4344-BCBE-9B0306A32486@cisco.com> References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.123] Content-Type: text/plain; charset="utf-8" Content-ID: <73151EE8503C044D9D810EAE2E185240@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 21:28:03 -0000 WWVzLCBTUkggaW5zZXJ0aW9uIGlzIG5vdCBkaXNjdXNzZWQgaW4gdGhpcyBkcmFmdCBhbmQgbm90 IHdpdGhpbiBpdHMgc2NvcGUuDQoNCkRhcnJlbg0KDQo+IE9uIE5vdiA0LCAyMDE4LCBhdCAxMTo1 NSBQTSwgQ2hlbmdsaSAoQ2hlbmcgTGkpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ IA0KPiBzbyBob3cgdG8gdXNlIFNSSCBpbnNlcnRpb24/IE91dCBvZiBzY29wZSBvZiB0aGlzIGRy YWZ0Pw0KPiANCj4gQ2hlbmcNCj4gDQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWP keS7tuS6ujogRGFycmVuIER1a2VzIChkZHVrZXMpIFttYWlsdG86ZGR1a2VzQGNpc2NvLmNvbV0g DQo+IOWPkemAgeaXtumXtDogMjAxOOW5tDEx5pyIM+aXpSAyOjQwDQo+IOaUtuS7tuS6ujogQ2hl bmdsaSAoQ2hlbmcgTGkpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT4NCj4g5oqE6YCBOiBKb2VsIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+OyBzcHJpbmdAaWV0Zi5vcmc7IDZtYW5AaWV0Zi5v cmc7IExpemhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb20+OyBNYWNoIENoZW4gPG1hY2guY2hl bkBodWF3ZWkuY29tPg0KPiDkuLvpopg6IFJlOiBTUnY2IC0gU1JIIGluIGVuY2FwcyBvciBiYXNl IGhlYWRlciAtIHBvaW50IDINCj4gDQo+IEhlbGxvIENoZW5nLCB0aGFua3MgZm9yIHRoZSByZXZp ZXchICBQbGVhc2Ugc2VlIGlubGluZQ0KPiANCj4+IE9uIE9jdCAzMCwgMjAxOCwgYXQgMTE6NDEg UE0sIENoZW5nbGkgKElQIFRlY2hub2xvZ3kgUmVzZWFyY2gpIDxjaGVuZ2xpMTNAaHVhd2VpLmNv bT4gd3JvdGU6DQo+PiANCj4+IEhpIERhcnJlbiwNCj4+IA0KPj4gSSB0aGluayB0aGUgdGV4dCBv ZiBlbmNhcHN1bGF0aW5nIG1vZGUgaXMgY2xlYXIgZm9yIG1lLiBCdXQgSSBzdGlsbCBoYXZlIHNv bWUgcXVlc3Rpb25zIG9mIHRoZSBpbnNlcnRpb24gbW9kZSAuDQo+PiANCj4+IDEuMSA6PGRkPiBO b2RlIDkgaGFzIGEgY2hvaWNlLCBlbmNhcHN1bGF0ZSB0byBub2RlIDMgb3Igbm90LiANCj4+IElm IG5vZGUgOSBkb2VzIG5vdCBlbmNhcHN1bGF0ZSwgaXQgd2lsbCBpbmZvcm0gdGhlIGRlc3RpbmF0 aW9uIG9mIHRoZSBzZWdtZW50cyBpbiB0aGUgU1JIIGFuZCBwb3NzaWJseSBsZWFrIHRoZW0gdG8g aW50ZXJtZWRpYXRlIG5vZGVzLg0KPj4gDQo+PiBJZiB0aGVyZSBpcyBub3QgaW5kaWNhdG9yIHRv IG1ha2UgYSBjaG9pY2Ugb2YgZW5jYXBzdWxhdGluZyBvciBub3QsIGhvdyB0aGUgbm9kZSB0byBt YWtlIHRoZSBjaG9pY2U/IExvY2FsIHBvbGljeT8gIA0KPj4gT3IgbWFrZSBpdCB0aGUgc2FtZSBs aWtlIHRoZSByZWNlaXZlZCBwYWNrZXQ/IEVuY2Fwc3VsYXRlIGlmIHJlY2VpdmVkIHBhY2tldCBk b2VzLCBlbHNlLCBpbnNlcnQ/DQo+IA0KPiBBIGhvc3QgbmVlZHMgbWFueSB0aGluZ3MgdG8gZGV0 ZXJtaW5lIGhvdyB0byBhZGQgYW4gU1JIIHRvIGEgcGFja2V0IGl0IGlzIHNlbmRpbmcgdG8gYSBk ZXN0aW5hdGlvbiwgYXQgbGVhc3QgaXQgbmVlZHMgdG8gbGVhcm4gU0lEcyBmb3Igbm9kZXMgYW5k IGhhdmUgc29tZSBsb2dpYyBpbiBwbGFjZSB0byBkZXRlcm1pbmUgaG93IGFuZCB3aGVuIHRvIHVz ZSBhIHBhcnRpY3VsYXIgc2VnbWVudCBsaXN04oCmIFRoYXQgaXMgd2VsbCBiZXlvbmQgdGhpcyBk b2N1bWVudCBhbmQgdGhlcmUgaXMgYW5kIHdpbGwgYmUgbW9yZSBpbm5vdmF0aXZlIHdheXMgb2Yg ZGV0ZXJtaW5pbmcgd2hlbiB0byBhZGQgYSBTUkggdG8gYSBwYWNrZXQgc291cmNlZCBieSBhIG5v ZGUuDQo+IA0KPiBUaGVyZWZvcmUgSeKAmWxsIHNheSB0aGlzIHF1ZXN0aW9uIGlzIG5vdCB3aXRo aW4gc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQsIGl0IG5lZWRzIHRvIGJlIGFuc3dlcmVkIGZvciBz cGVjaWZpYyB1c2UgY2FzZXMgYW5kIGFwcGxpY2F0aW9ucyBvZiB0aGUgU1JILg0KPiANCj4gVGhh dCBzYWlkIHRoZXJlIGlzIG9uZ29pbmcgd29yayB0byBkZWZpbmUgaG93IGEgbm9kZSBtYXkgbGVh cm4gYW4gU1IgUG9saWN5Og0KPiBQQ0VQIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW5l Z2ktcGNlLXNlZ21lbnQtcm91dGluZy1pcHY2LTAzLnR4dCwNCj4gQkdQLVRFIGh0dHBzOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3ktMDQu dHh0LA0KPiBvciDigJxTRE7igJ0gbWV0aG9kcyB3aGVyZSBzb21lIG91dHNpZGUgY29udHJvbGxl ciBzZXRzIHVwIGEgc2VnbWVudCBsaXN0IHZpYSBzb21lIFJFU1QsIENMSSwgbmV0Y29uZi95YW5n IGludGVyZmFjZSB0byBzYXRpc2Z5IHNwZWNpZmljIHVzZSBjYXNlcy4NCj4gDQo+IEFuZCB3aGVu IHRvIHVzZSBpdDoNCj4gQkdQIFNSdjYgc2VydmljZXMgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQv ZHJhZnQtZGF3cmEtaWRyLXNydjYtdnBuLTA1LnR4dA0KPiANCj4gDQo+PiANCj4+IDEuMiA6IEhv dyB0byBpbmZvcm0gdGhlIGRlc3RpbmF0aW9uIG9mIHRoZSBzZWdtZW50cyBpbiB0aGUgU1JIPyAg QW55IGluZGljYXRvciBpbiBTUkg/IE9yIHRocm91Z2ggc2lnbmFsaW5nPyANCj4+IA0KPiANCj4g DQo+IFNhbWUgYW5zd2VyIGFzIDEuMS4gIA0KPiANCj4+IDI6IENhbiBhIG5vcm1hbChub24tU0lE KSBJUHY2IGFkZHJlc3MgYmUgYWRkZWQgaW50byBTSUQgbGlzdD8NCj4+IA0KPj4gSSBwcmVmZXIg eWVzLg0KPj4gDQo+PiBBcyBzZWN0aW9uIDQuMyBzYXlzLCBpdCBzZWVtcyBsaWtlIHdlIGNhbiBk byB0aGF0Lg0KPj4gDQo+PiAgIldoZW4gYW4gU1J2Ni1jYXBhYmxlIG5vZGUgcmVjZWl2ZXMgYW4g SVB2NiBwYWNrZXQsIGl0IHBlcmZvcm1zIGENCj4+ICBsb25nZXN0LXByZWZpeC1tYXRjaCBsb29r dXAgb24gdGhlIHBhY2tldHMgZGVzdGluYXRpb24gYWRkcmVzcy4gIFRoaXMNCj4+ICBsb29rdXAg Y2FuIHJldHVybiBhbnkgb2YgdGhlIGZvbGxvd2luZzoNCj4+IA0KPj4gICAgICBBIEZJQiBlbnRy eSB0aGF0IHJlcHJlc2VudHMgYSBsb2NhbGx5IGluc3RhbnRpYXRlZCBTUnY2IFNJRA0KPj4gICAg ICBBIEZJQiBlbnRyeSB0aGF0IHJlcHJlc2VudHMgYSBsb2NhbCBpbnRlcmZhY2UsIG5vdCBsb2Nh bGx5DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluc3RhbnRpYXRlZCBh cyBhbiBTUnY2IFNJRA0KPj4gICAgICBBIEZJQiBlbnRyeSB0aGF0IHJlcHJlc2VudHMgYSBub24t bG9jYWwgcm91dGUNCj4+ICAgICAgTm8gTWF0Y2gNCj4+ICAgICAiDQo+PiBBbHNvLCBpbiBzZWN0 aW9uIDUsIHdlIGNhbiBzZWUgQTkgY2FuIGJlIGFkZGVkIGluIFNJRCBsaXN0IG9mIGEgU1IgcG9s aWN5Lg0KPj4gDQo+PiBTbyBmb3IgdGhlIHBhY2tldCBmcm9tIEE5IHRvIEExLCB0aGUgYWRkcmVz cyBvZiBBMSBjYW4gYmUgYWRkZWQgYXMgdGhlIGxhc3QgZW50cnkgb2YgU0lEIGxpc3QsIHJpZ2h0 PyANCj4+IA0KPj4gSWYgeWVzLCBhZGRyZXNzIG9mIEExIGlzIG5vdCBhbiBpbnN0YW50aWF0ZWQg U0lELCBzbyBub3QgUFNQIGZsYXZvciBjYW4gYmUgZW5hYmxlZC4gU28gdGhlIHBhY2tldCB3aWxs IGJlIHNlbnQgb3V0IGJ5IGNhcnJ5aW5nIHRoZSBTUkggYWZ0ZXIgQTEgaXMgdXBkYXRlZCB0byB0 aGUgSVB2NiBEQS4gDQo+PiBTUkggd2lsbCBiZSBsZWFrZWQgdG8gb3V0c2lkZSBvZiB0aGUgU1Ig ZG9tYWluLCB3aGljaCB3aWxsIGJyaW5nIG5ldyBzZWN1cml0eSBpc3N1ZXMuIA0KPj4gDQo+IA0K PiBZZXMgYXMgdGhlIGxhc3Qgc2VnbWVudCBpbiBhIHNlZ21lbnQgbGlzdCwgYW5kIGFzIFJGQzgy MDAgc2VjdGlvbiA0LjQgZGVzY3JpYmVzIFJvdXRpbmcgSGVhZGVyIHByb2Nlc3Npbmcgd2hlbiBz ZWdtZW50cyBsZWZ0IGlzIDAuDQo+IA0KPiBJdCBpcyB1cCB0byB0aGUgc3BlY2lmaWMgdXNlIGNh c2UgdG8gZGV0ZXJtaW5lIGlmIGluZm9ybWluZyB0aGUgZGVzdGluYXRpb24gb3IgaW50ZXJtZWRp YXRlIG5vZGVzIG9mIHRoZSBzZWdtZW50IGxpc3QgdXNlZCB0byByZWFjaCBpdCBpcyBhIHNlY3Vy aXR5IHJpc2suIA0KPiANCj4gQ2VydGFpbmx5IG9uIHRoZSBsYXJnZXIgaW50ZXJuZXQgdGhpcyBp cyBhbiBpc3N1ZSB0aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQsIGJ1dCB3aXRoaW4gYW4gZW50 ZXJwcmlzZSBuZXR3b3JrIG9yIHdpdGhpbiBhIHNpbmdsZSBwcm92aWRlcnMgbmV0d29yayBjcm9z c2luZyBtdWx0aXBsZSBkb21haW5zLCBvciBldmVuIGJldHdlZW4gcHJvdmlkZXJzIHRoZSBkaXNj bG9zdXJlIG1heSBiZSBhY2NlcHRhYmxlIG9yIGRlc2lyZWQuDQo+IA0KPj4gDQo+PiAzOiBGb3Ig c2VjdGlvbiA2LjIsDQo+PiAgTm9kZXMgb3V0c2lkZSB0aGUgU1IgRG9tYWluIGNhbm5vdCBiZSB0 cnVzdGVkLiAgU1IgRG9tYWluIEluZ3Jlc3MNCj4+ICByb3V0ZXJzIFNIT1VMRCBkaXNjYXJkIHBh Y2tldHMgZGVzdGluZWQgdG8gU0lEcyB3aXRoaW4gdGhlIFNSIERvbWFpbg0KPj4gIChyZWdhcmRs ZXNzIG9mIHRoZSBwcmVzZW5jZSBvZiBhbiBTUkgpIHRvIGF2b2lkIGF0dGFja3Mgb24gdGhlIFNS DQo+PiAgRG9tYWluIGFzIGRlc2NyaWJlZCBhbmQgcmVmZXJlbmNlZCBpbiBbUkZDNTA5NV0uIA0K Pj4gDQo+PiAgQXMgYW4gYWRkaXRpb25hbA0KPj4gIGxheWVyIG9mIHByb3RlY3Rpb24sIFNSIFNl Z21lbnQgRW5kcG9pbnQgbm9kZXMgU0hPVUxEIGRpc2NhcmQgcGFja2V0cw0KPj4gIGRlc3RpbmVk IHRvIGxvY2FsIFNJRHMgZnJvbSBzb3VyY2UgYWRkcmVzc2VzIG5vdCBwYXJ0IG9mIHRoZSBTUg0K Pj4gIERvbWFpbi4NCj4+IA0KPj4gRm9yIGEgcGFja2V0IGZyb20gQTEgdG8gQTksICB0aGUgcGFj a2V0IGlzIChBMSwgQTkpLiBOb2RlMyB3aWxsIG5vdCBkcm9wIHRoZSBwYWNrZXQgc2luY2UgdGhl IGRlc3RpbmF0aW9uIGlzIEE5IG5vdCBTOS4NCj4+IA0KPj4gSWYgbm9kZSAzIGluc2VydCBhIFNS SCBpbiB0aGUgb3JpZ2luYWwgSVB2NiBwYWNrZXQsIHRoZW4gdGhlIHNvdXJjZSBBZGRyZXNzIHdp bGwgYmUgQTEuIEFuZCB0aGUgU0lEIGxpc3QgY2FuIGJlICA8QTksIFM2ID4uDQo+PiBJbiB0aGlz IGNhc2UsIHRoZSBwYWNrZXQgd2lsbCBiZSBkcm9wcGVkIGJ5IG5vZGUgNiwgc2luY2UgdGhlIHNv dXJjZSBhZGRyZXNzIGlzIG5vdCBwYXJ0IG9mIHRoZSBTUiBkb21haW4uICBbU2VjdGlvbiA2LjJd LCByaWdodD8NCj4+IA0KPj4gSU1ITywgdGhlcmUgYXJlIHNvbWUgcHJvYmxlbXMgYWJvdXQgaW5z ZXJ0aW9uIG1vZGUuDQo+IA0KPiBJbiB0aGUgY29udGV4dCBvZiB0aGUgU1JIIGRyYWZ0IHdlIGRv IG5vdCBtYWtlIGFueSBtZW50aW9uIG9yIHVzZSBvZiBTUkggaW5zZXJ0aW9uLiBJLmUuIG5vZGUg MyBkb2VzIG5vdCBpbnNlcnQgYW4gU1JILCBpdCBlbmNhcHN1bGF0ZXMgaW4gYW4gb3V0ZXIgSVB2 NiBoZWFkZXIuDQo+IA0KPiBEYXJyZW4NCj4gDQo+PiANCj4+IFRoYW5rcywNCj4+IENoZW5nDQo+ PiANCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogaXB2 NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhcnJlbiBEdWtl cyANCj4+IChkZHVrZXMpDQo+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMzEsIDIwMTggMzoz MSBBTQ0KPj4gVG86IEpvZWwgSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+IENjOiBz cHJpbmdAaWV0Zi5vcmc7IDZtYW5AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBTUnY2IC0gU1JI IGluIGVuY2FwcyBvciBiYXNlIGhlYWRlciAtIHBvaW50IDINCj4+IA0KPj4gSSB0aGluayB3ZeKA mXJlIGFsbW9zdCBjb25jbHVkZWQgc28gb25jZSBtb3JlIGlubGluZSBhdCA8ZGQ+PC9kZD4NCj4+ IA0KPj4+IE9uIE9jdCAyNiwgMjAxOCwgYXQgMjoyOCBQTSwgSm9lbCBIYWxwZXJuIDxqbWhAam9l bGhhbHBlcm4uY29tPiB3cm90ZToNCj4+PiANCj4+PiAocmVzZW5kaW5nLCArc3ByaW5nIGFzIHJl cXVlc3RlZCkNCj4+PiANCj4+PiBUaGFuayB5b3UgZm9yIHRoZSByZXNwb25zZXMuICBJIHdpbGwg cmVzcG9uZCBpbiBsaW5lLCBtYXJrZWQgPGptaD48L2ptaD4uICBJIGZlYXIgaXQgd2lsbCBzaG9y dGx5IGdldCB0b28gZGVlcCwgYnV0IHRoZSBjb250ZXh0IGlzIGltcG9ydGFudC4NCj4+PiANCj4+ PiBJIHdpbGwgcmVwaHJhc2UgaGVyZSBhbiBpc3N1ZSBmcm9tIGFub3RoZXIgdGhyZWFkIHRoYXQg SSBhaHZlIG5vdCBzZWVuIHlvdXIgY29tbWVudHMgb24uICBJZiBOb2RlIDkgaXMgc2VuZGluZyB0 cmFmZmljIHRvIE5vZGUgMSAoZm9yIGV4YW1wbGUsIHRoZSByZXZlcnNlIHRyYWZmaWMgZm9yIHRo ZSB0cmFmZmljIGZyb20gMSB0byA5IGluIHRoZSBleGFtcGxlcyBiZWxvdyksIGl0IHByZXN1bWFi bHkgaGFzIGFuIFNSIFBvbGljeSB0byBiZSBhcHBsaWVkLiBUaGUgaXNzdWUgSSByYWlzZWQgYmVm b3JlIGlzIHRoZSBsZWFrYWdlIGlzc3VlLiAgSWYgOSBwdXRzIHRoZSBTUkggaW4gaXRzIHBhY2tl dCAoYXMgdGhlIGRvY3VtZW50IGN1cnJlbnRseSBtYW5kYXRlcyksIHRoZW4gaXQgd2lsbCBub3Qg YmUgcG9zc2libGUgZm9yIDMgdG8gcmVtb3ZlIHRoZSBTUkguICBUaHVzLCB0aGUgU1JIIHdpbGwg bGVhay4NCj4+PiANCj4+PiBTb21lIGhhdmUgYXJndWVkIHRoYXQgaXMgbm90IGEgYmlnIGRlYWwu ICBJdCBzZWVtcyB0byBtYXR0ZXIgdG8gbWUuICBCdXQgdGhlcmUgaXMgYW4gYWRkaXRpb25hbCBw cm9ibGVtLiAgQTEgaXMgbm90IGEgU0lELiAgVGhlcmVmb3JlLCA5IGNhbiBub3QgcHV0IEExIGlu dG8gdGhlIFNSSC4gIElmIGl0IGNhbiBub3QgcHV0IEExIGludG8gdGhlIFNSSCwgYW5kIGl0IGRv ZXMgbm90IGVuY2Fwc3VsYXRlIHRoZSBwYWNrZXQsIHdoZXJlIGRvZXMgaXQgcHV0IEExLg0KPj4g DQo+PiA8ZGQ+IE5vZGUgOSBoYXMgYSBjaG9pY2UsIGVuY2Fwc3VsYXRlIHRvIG5vZGUgMyBvciBu b3QuIA0KPj4gSWYgbm9kZSA5IGRvZXMgbm90IGVuY2Fwc3VsYXRlLCBpdCB3aWxsIGluZm9ybSB0 aGUgZGVzdGluYXRpb24gb2YgdGhlIHNlZ21lbnRzIGluIHRoZSBTUkggYW5kIHBvc3NpYmx5IGxl YWsgdGhlbSB0byBpbnRlcm1lZGlhdGUgbm9kZXMuDQo+PiBJZiBub2RlIDkgZG9lcyBlbmNhcHN1 bGF0ZSwgbm9kZSAzIHJlbW92ZXMgdGhlIG91dGVyIGhlYWRlciBhbmQgbm9kZSAxIHdvdWxkIG5v dCBsZWFybiB0aGUgc2VnbWVudCBsaXN0Lg0KPj4gSSB0aGluayBpdHMgY2hvaWNlIHNob3VsZCBu b3QgYmUgbWFuZGF0ZWQgaW4gdGhlIGRyYWZ0LiA8L2RkPg0KPj4gDQo+Pj4gDQo+Pj4gWW91cnMs DQo+Pj4gSm9lbA0KPj4+IA0KPj4+IE9uIDEwLzI2LzE4IDE6MjkgUE0sIERhcnJlbiBEdWtlcyAo ZGR1a2VzKSB3cm90ZToNCj4+Pj4gSGkgSm9lbCwgeW914oCZdmUgZGVzY3JpYmVkIHNlY3Rpb25z IHRpdGxlZCDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLCDigJxUcmFuc2l0IFBhY2tldCBU aHJvdWdoIFNSIERvbWFpbuKAnSwgYW5kICJTUiBTb3VyY2UgTm9kZXMgTm90IERpcmVjdGx5IENv bm5lY3RlZOKAnS4NCj4+Pj4gSeKAmXZlIHBhcnNlZCB0aGVtIGlubGluZSB0byB0aGUgc2VjdGlv bnMgb2YgdGhlIGRyYWZ0IGRlZmluaW5nIHRoZW0gYW5kIGdpdmVuIG1vcmUgY29udGV4dCB3aGVy ZSBuZWVkZWQuDQo+Pj4+PiBPbiBPY3QgMjIsIDIwMTgsIGF0IDg6NDkgUE0sIEpvZWwgTS4gSGFs cGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IFJlcGhyYXNp bmcgdXNpbmcgdGhlIGV4YW1wbGUgZnJvbSA1LjIuICBBc3N1bWluZyB0aGF0IDggYW5kIDkgYXJl IA0KPj4+Pj4gU1IgSG9zdHMgKG5vdCBqdXN0IGhvc3RzIHdpdGhpbiB0aGUgZG9tYWluLCB0aGV5 IGFyZSBjYXBhYmxlIG9mIGFuZCANCj4+Pj4+IGV4cGVjdCB0byBkZWFsIHdpdGggU1JIcywgYW5k IHRoZXJlZm9yZSBoYXZlIGxvY2FsIFNJRHMsIC4uLikNCj4+Pj4+IA0KPj4+Pj4gRm9yIHRyYWZm aWMgZnJvbSA4IHRvIDkgdGhhdCBuZWVkcyBhbiBTUkgsIHRoZSBTUkggZ29lcyBpbiB0aGUgSVB2 NiBoZWFkZXIgc2VudCBteSA4IHRvIDkuICBXaGVuIDkgcHJvY2Vzc2VzIHRoZSBwYWNrZXQsIGl0 IHNlZW1zIHRoYXQgaXQgaXMgdGhlIGxhc3QgU0lELCBmaWd1cmVzIG91dCB0aGF0IHRoZXJlIGlz IG5vIGVuY2Fwc3VsYXRpb24sIGFuZCBzZW5kIHRoZSBUQ1AgLyBVRFAgLyBRVUlDIGluZm9ybWF0 aW9uIHRvIGl0cyBpbnRlcm5hbCBwcm90b2NvbHMgc3RhY2tzLg0KPj4+PiBZZXMsIHRoaXMgaXMg U2VjdGlvbiA1LjMuMSDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLg0KPj4+IDxqbWg+QWdy ZWVkIGFzIGZhciBhcyBpdCBnb2VzLiAgSG93ZXZlciwgIHRoZSBleGlzdGVuY2Ugb2YgUzkgYW5k IEE5IA0KPj4+IHBvaW50cyB0byBhIHByb2JsZW0uICBOb2RlIDggaXMgdHJ5aW5nIHRvIHB1dCBv biBhbiBTUkggZ29pbmcgdGhyb3VnaCANCj4+PiBTeCwgU3ksIHdoYXRldmVyIGZvciBzb21lIHJl YXNvbi4gIEl0IGNhbid0IHB1dCBBOSBpbnRvIHRoZSBTUkgsIGFzIA0KPj4+IEFIIGlzIG5vdCBh IFNJRCwgaXQgaXMgYW4gYWRkcmVzcy4gIEkgcHJlc3VtZSBub2RlIDggZ290IFM5IGZyb20gDQo+ Pj4gd2hhdGV2ZXIgcHJvdmlkZWQgaGltIHRoZSBTUiBQb2xpY3kgdGhhdCBpdCBpcyB1c2luZy4g IERvZXMgaXQgc2ltcGx5IA0KPj4+IHVzZSBTOSBhcyB0aGUgYWRkcmVzcyBmb3Igbm9kZSA5LCBy YXRoZXIgdGhhbiBBOSB0aGF0IGl0IGdvdCBmcm9tIA0KPj4+IEROUz8gIEFuZCBkb2VzIHRoZSBU Q1Agc3RhY2sga25vdyB0aGF0IHRoaXMgc3Vic3RpdHV0aW9uIGlzIGJlaW5nIA0KPj4+IG1hZGU/ ICAoVGhpcyBpcyBhbm90aGVyIGV4YW1wbGUgb2YgYSBwcm9ibGVtIHRoYXQgZ29lcyBhd2F5IGlm IHdlIA0KPj4+IGFsd2F5cyBlbmNhcHN1bGF0ZS4pIDwvam1oPg0KPj4gDQo+PiA8ZGQ+U2VjdGlv biA0LjMuMiBjb3ZlcnMgdGhlc2UgcXVlc3Rpb25zLCBpLmUuIEE5IGNhbiBiZSBwbGFjZWQgaW4g dGhlIA0KPj4gU1JIIGFzIHRoZSBsYXN0IHNlZ21lbnQsIGFuZCB0aGlzIHNlY3Rpb24gZGVzY3Jp YmVzIGhvdyBpdOKAmXMgDQo+PiBoYW5kbGVkLjwvZGQ+DQo+PiANCj4+PiANCj4+Pj4+IA0KPj4+ Pj4gRm9yIHRyYWZmaWMgZnJvbSAxIHRvIDksIHdoZXJlIDMgYWRkcyBhbiBTUkgsIHRoYXQgU1JI IHN0aWxsIHByZXN1bWFibHkgZW5kcyBhdCA5LiAgOSBSZWNlaXZlcyB0aGUgSVAgcGFja2V0LiAg U2VlcyB0aGF0IGl0IGlzIGFkZHJlc3NlZCB0byBpdHNlbGYuICBTZWVzIHRoYXQgdGhlIFNSSCBp cyBmaW5pc2hlZC4gIEFuZCB0aGVuIG5vdGljZXMgdGhhdCB0aGUgbmV4dC1oZWFkZXIgaXMgSVB2 Ni4gIFVud3JhcHMgdGhlIGhlYWRlciwgY2hlY2tzIHRoYXQgdGhlIGlubmVyIGRlc3RpbmF0aW9u IGFkZHJlc3MgaXMgYWxzbyBpdHNlbGYsIGFuZCBwYXNzZXMgdGhlIG1hdGVyaWFsIGNhcnJpZWQg YnkgdGhlIGlubmVyIGhlYWRlciB1cCB0byB0aGUgYXBwcm9wcmlhdGUgc3RhY2suDQo+Pj4+IFNv IG5vZGUgMSBzZW5kcyBhIHBhY2tldCB0byBub2RlIDkgKEExLEE5KSBJRiB0aGVyZSBpcyBzb21l IHN0ZWVyaW5nIA0KPj4+PiBpbnRvIGFuIFNSIFBvbGljeSBhdCBub2RlIDMgdG8gcmVhY2ggbm9k ZSA5LCB0aGlzIGlzIGlkZW50aWNhbCB0byBzZWN0aW9uIDUuMy4yIOKAnFRyYW5zaXQgcGFja2V0 IHRocm91Z2ggU1IgZG9tYWlu4oCdLCBleGNlcHQgZm9yIGRlc3RpbmF0aW9uIG9mIEE5IHZpYSBu b2RlIDkgIGluc3RlYWQgb2YgQTIgdmlhIG5vZGUgNC4NCj4+PiANCj4+Pj4+IA0KPj4+Pj4gVGh1 cywgOSBuZWVkcyB0byBiZSBhYmxlIHRvIGNoZWNrIGZvciBib3RoIGNhc2VzLiAgV2UgYXQgbGVh c3QgbmVlZCB0byB0ZWxsIGltcGxlbWVudG9ycyB0aGF0Lg0KPj4+PiBXZWxsLCA5IG5lZWRzIGEg U0lEIFM5IGFuZCBBZGRyZXNzIEE5LiAgVGhhdCBpcyBzaG93biBpbiBTZWN0aW9uIDUuMSBTSUQg YW5kIGFkZHJlc3MgcmVwcmVzZW50YXRpb24uDQo+Pj4gPGptaD5TbywgbGV0IHVzIGFzc3VtZSB0 aGF0IDMgaGFzIGFuIFNSIHBvbGljeSBpdCB3YW50cyB0byBhcHBseSB0byANCj4+PiB0aGUgdHJh ZmZpYyBmcm9tIEExIHRvIEE5LiAgSW4gdGhpcyBjYXNlLCB0aGUgUzkgLyBBOSBkaWNob3RvbXkg aXMgDQo+Pj4gbm90IGEgcHJvYmxlbSwgSSB0aGluay4gIE5vZGUgMyBlbmNhcHN1YWx0ZXMgdGhl IHBhY2tldCBmcm9tIEExIHRvIA0KPj4+IEE5LCB1c2VzIFMzIGFzIHRoZSBzb3VyY2UgYWRkcmVz cyBvZiB0aGUgZW5jYXBzdWxhdGluZyBoZWFkZXIsIGFuZCANCj4+PiBlbmRzIHRoZSBTSUQgbGlz dCBpbiB0aGUgU1JIIHdpdGggUzkuICBUaGUgdW5zcGVjaWZpZWQgcGFydCBpcyB0aGF0IA0KPj4+ IG5vZGUgOSBuZWVkcyB0byBiZSBwcmVwYXJlZCB0byByZWNlaXZlIHN1Y2ggcGFja2V0cyBhbmQg ZG8gdGhlIGRvdWJsZSANCj4+PiBwcm9jZXNzaW5nLiAgSXQgaXMgcmVhc29uYWJsZSBkb3VibGUg cHJvY2Vzc2luZy4gIE15IG9ubHkgcmVxdWVzdCANCj4+PiBoZXJlIGlzIHRoYXQgd2UgdGVsbCBm b2xrcyB0aGV5IG5lZWQgdG8gc3VwcG9ydCBpdC4gPC9qbWg+DQo+PiANCj4+IDxkZD5BY3R1YWxs eSwgbm9kZSAzIHVzZXMgQTMgYXMgaXRzIHNvdXJjZSBhZGRyZXNzLCBidXQgdGhhdOKAmXMgbWlu b3IuDQo+PiBUaGUgZG91YmxlIHByb2Nlc3NpbmcgKGxvb2t1cCwgZG8gZW5kIHByb2Nlc3Npbmcs IGRvIGFub3RoZXIgbG9va3VwKSBpcyBkb2N1bWVudGVkIGluIFNlY3Rpb24gNC4zLg0KPj4gSXMg dGhlcmUgYSBuZWVkIGZvciBtb3JlIHRoYW4gd2hhdCBpcyBjdXJyZW50bHkgc3BlY2lmaWVkPyA8 L2RkPg0KPj4gDQo+Pj4+PiANCj4+Pj4+IFRoZXJlIGlzIGEgZnVydGhlciBjb21wbGljYXRpb24u ICA5IHNlZW1zIHRvIG5lZWQgdG8gaGF2ZSBhbiBhZGRyZXNzIHRoYXQgaXMgYSB2YWxpZCBTSUQs IHNvIGl0IGNhbiBiZSB0aGUgbGFzdCBlbnRyeSBpbiB0aGUgU1JIIGZyb20gOCB0byA5Lg0KPj4+ PiBBcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LCBTZWN0aW9uIDUuMSBhIG5vZGUgayBoYXMgYW4g YWRkcmVzcyBBayBhbmQgU0lEIFNrLiAgU28gbm9kZSA5IGhhcyBhIHZhbGlkIFNJRC4NCj4+Pj4g Rm9yIHRyYWZmaWMgZnJvbSA4IHRvIDksIEE5IGlzIHVzZWQgYXMgdGhlIGRlc3RpbmF0aW9uIGFz IHNob3duIGluIHNlY3Rpb24gNS4zLjEsIDUuNCBhbmQgNS41Lg0KPj4+Pj4gSG93ZXZlciwgaWYg MSB3ZXJlIHRvIHNlbmQgdGhlIHBhY2tldCB0byB0aGF0IFNJRCBmb3IgOSwgcm91dGVyIDMgd291 bGQgYmUgcmVxdWlyZWQgYnkgdGhlIHJ1bGVzIHdlIGRpc2N1c3NlZCBpbiB0aGUgb3RoZXIgdGhy ZWFkIHRvIGRpc2NhcmQgdGhlIHBhY2tldCBhcyBpdCBpcyBuZWl0aGVyIHRvIHByZWZpeCBub3Ig Y29udGFpbnMgYW4gSEFNQy4NCj4+Pj4+IEFuZCBzb21laG93LCA4IGFuZCAxIG5lZWQgdG8gZWFj aCBwaWNrIHRoZSByaWdodCBhZGRyZXNzIHRvIHVzZSBmb3IgOS4gKHNwbGl0IEROUyBtYXliZT8p ICBBbmQgMyBuZWVkcyB0byBiZSBhYmxlIHRvIGRlcml2ZSB0ZWggU0lELWZvcm1uIGFkZHJlc3Mg Zm9yIDkgZnJvbSB0aGUgbm9uLVNJRCBmb3JtIG9mIHRoZSBhZGRyZXNzIHNvIHRoYXQgaXQgKDMp IGNhbiBidWlsZCBhIHByb3BlciBTUkggdG8gZ2V0IHRoZSBwYWNrZXQgdG8gOS4NCj4+PiA8am1o PkkgaGF2ZSByZXRhaW5lZCB5b3VyIGFuc3dlciBiZWxvdyBmb3IgY29udGV4dCwgYnV0IEkgdGhp bmsgdGhhdCANCj4+PiBhbnN3ZXJzIHRoZSB3cm9uZyBxdWVzdGlvbi4gIEkgYmVsaWV2ZSB3aGF0 IGlzIGl0bmVuZGVkIGlzIHRoYXQgb25seQ0KPj4+IEE5IGFwcGVhcnMgaW4gRE5TLiAgU28gTm9k ZSAxIHdpbGwgc2VlIDkgYXMgQTksIGFuZCB3aWxsIHVzZSB0aGF0LiAgDQo+Pj4gUzkgd2lsbCBh cHBlYXIgaW4gU1IgUG9saWNpZXMgYWJvdXQgdHJhZmZpYyB0byBub2RlIDksIGJ1dCBub3QgaW4g RE5TLg0KPj4+IFRoYXQgaXMgd2hhdCB3ZSBuZWVkLiAgSSB3aXNoIGl0IHdlcmUgY2xlYXJlciBp biB0aGUgdGV4dC4gPC9qbWg+DQo+Pj4gDQo+Pj4gPGptaD5JZiBub2RlIDIwIGlzIGdlbmVyYXRp bmcgU1JIcyB3aXRoIEhNQUNzLCB0aGVuIHRoaXMgaXMgbGFyZ2VseSANCj4+PiB0aGUgc2FtZSBh cyB0aGUgY2FzZSBmcm9tIDggdG8gOSwgZXhjZXB0IHRoYXQgd2hvbWV2ZXIgY3JlYXRlcyB0aGUg U1IgDQo+Pj4gUG9saWN5IHRoYXQgMjAgaXMgdXNpbmcgbmVlZHMgdG8gYWxzbyBtYWtlIHN1cmUg dGhhdCB3aGF0ZXZlciB0aGUgDQo+Pj4gZmlyc3QgU0lEIGlzIGluIHRlaCBsaXN0LCBpdCBwcm9j ZXNzZXMgSE1BQ3MgYW5kIGlzIHJlY29nbml6YWJsZSB0byANCj4+PiBub2RlIDMgYXMgZG9pbmcg c3VjaCBwcm9jZXNzaW5nLiBJIGFtIGd1ZXNzaW5nIHRoYXQgdGhlIHJlYXNvbiBmb3IgDQo+Pj4g YWxsb3dpbmcgaW50ZXJuYWwgbm9kZXMgdG8gZG8gdGhlIHByb2Nlc3NpbmcgaXMgdG8gbW92ZSB0 aGUgDQo+Pj4gdmVyaWZpY2F0aW9uIGxvYWQgb2ZmIHRoZSBlZGdlIG5vZGVzLiAgSXQgZG9lcyBj cmVhdGUgc2lnbmlmaWNhbnQgDQo+Pj4gYWRkaXRpb25hbCBjb25maWd1cmF0aW9uIGNvbXBsZXhp dHkuIDwvam1oPg0KPj4gDQo+PiA8ZGQ+V2UgZGlkbuKAmXQgc2VlIGEgcmVhc29uIHRvIHJlc3Ry aWN0IHRoZSBITUFDIHByb2Nlc3NpbmcgdG8gb25seSANCj4+IGVkZ2Ugbm9kZXMgd2hlbiBpdCB3 YXMgc3RyYWlnaHQgZm9yd2FyZCB0byBkZWZpbmUgaG93IHRoZXkgY291bGQgYmUgDQo+PiBwcm9j ZXNzZWQgYXQgbm9uLWVkZ2Ugbm9kZXMuPC9kZD4NCj4+IA0KPj4+IA0KPj4+PiBUaGlzIGlzIGlu Y29ycmVjdC4NCj4+Pj4gU2VlIFNlY3Rpb24gNi4yLjEg4oCcU1IgU291cmNlIE5vZGVzIE5vdCBE aXJlY3RseSBDb25uZWN0ZWTigJ0gSSB3aWxsIGV4cGFuZCBvbiB0aGUgZXhhbXBsZSBmcm9tIHRo YXQgc2VjdGlvbi4NCj4+Pj4gTm9kZSAyMCBzZW5kcyBhIHBhY2tldCB0byBBOSB3aXRoIFNSIFBv bGljeSA8SDc+IGFuZCBhbiBITUFDIA0KPj4+PiBwcm92aWRlZCB0byBub2RlIDIwIGJ5IHNvbWUg eWV0IHRvIGJlIGRlZmluZWQgbWV0aG9kLiAgUmVzdWx0aW5nIGluIA0KPj4+PiBwYWNrZXQgc2Vu dCBmcm9tIG5vZGUgMjANCj4+Pj4gUDogKEEyMCxINykoQTk7U0w9MSkocGF5bG9hZCkNCj4+Pj4g UmVjYWxsIEhrIGlzIGEgU0lEIGF0IG5vZGUgayByZXF1aXJpbmcgSE1BQyB2ZXJpZmljYXRpb24s IGFuZCBpdCBpcyBjb3ZlcmVkIGJ5IFByZWZpeC1ILg0KPj4+PiBQcmVmaXgtSCBpcyBfbm90XyBz dWJqZWN0IHRvIGluZ3Jlc3MgZmlsdGVyaW5nIGF0IG5vZGUgMy4NCj4+Pj4gVGhlcmVmb3JlIHRo ZSBwYWNrZXQgUCBkZXN0aW5lZCB0byBINyBpcyBub3Qgc3ViamVjdCB0byBpbmdyZXNzIGZpbHRl cmluZyBhdCBub2RlIDMuDQo+Pj4+IFAgaXMgZm9yd2FyZGVkIHRvIG5vZGUgNywgd2hlcmUgSDcg aXMgcHJvY2Vzc2VkIGFuZCB0aGUgSE1BQyB2ZXJpZmllZC4NCj4+Pj4gSWYgdGhlIEhNQUMgY2Fu IG5vdCBiZSB2ZXJpZmllZCB0aGUgcGFja2V0IGlzIGRyb3BwZWQsIGVsc2UgaXQgaXMgZm9yd2Fy ZGVkIHRvIHRoZSBuZXh0IHNlZ21lbnQgYW5kIGRlc3RpbmF0aW9uLCBBOS4NCj4+Pj4gRGFycmVu DQo+Pj4+PiANCj4+Pj4+IFlvdXJzLA0KPj4+Pj4gSm9lbA0KPj4+Pj4gDQo+Pj4+PiBPbiAxMC8y Mi8xOCA4OjA0IFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykgd3JvdGU6DQo+Pj4+Pj4gaW5saW5l Lg0KPj4+Pj4+PiBPbiBPY3QgMjIsIDIwMTgsIGF0IDc6MjEgUE0sIEpvZWwgTS4gSGFscGVybiA8 am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4+PiAuLg0KPj4+Pj4+PiAyKSBOb3cgbGV0 IHVzIGxvb2sgYXQgcGFja2V0cyBhcnJpdmluZyBhdCBhbmQgYWN0dWFsbHkgZGVzdGluZWQgZm9y IGFuIFNSIEhvc3QgaW4gdGhlIFNSIERvbWFpbiB3aGVyZSB0aGF0IHBhY2tldCBoYXMgYW4gU1JI LiAgSWYgdGhlIHBhY2tldCBpcyBjb21pbmcgZnJvbSBhbm90aGVyIFNSIEhvc3QsIHRoZSBTUkgg d2lsbCBiZSBpbiB0aGUgYmFzZSBoZWFkZXIsIGFuZCB0aGUgaG9zdCBjYW4gc2ltcGx5IGNoZWNr IGl0IGZvciBhbnkgdmlvbGF0aW9ucywgYW5kIGNvbnRpbnVlLiAgQnV0LCBpZiB0aGUgcGFja2V0 IGNhbWUgZnJvbSBvdXRzaWRlIHRoZSBkb21haW4sIHRoZW4gaXQgd2lsbCBoYXZlIGFuIGVuY2Fw c3VsYXRpbmcgU1J2NiBoZWFkZXIuICBTbyB0aGUgaG9zdCBoYXMgdG8gZGV0ZWN0IHRoaXMgY2Fz ZSwgY2hlY2sgYW5kIHRoZW4gcGVhbCBvZmYgdGhlIGVuY2Fwc3VsYXRpbmcgaGVhZGVyLCBhbmQg dGhlbiBwcm9jZXNzIHRoZSByZWNlaXZlZCBwYWNrZXQuIFllcywgaXQgY2FuIGRvIHNvLiAgQnV0 IG5vdGhpbmcgaW4gdGVoIGRvY3VtZW50IHRlbGxzIGltcGxlbWVudG9ycyB0aGV5IGhhdmUgdG8g ZGVhbCB3aXRoIGJvdGggY2FzZXMuDQo+Pj4+Pj4+IA0KPj4+Pj4+IENhbiB5b3UgYmUgbW9yZSBw cmVjaXNlIGhlcmUuICBQZXJoYXBzIHVzZSB0aGUgZXhhbXBsZSBmcm9tIHNlY3Rpb24gNS4yIG9y IDYuMi4xPw0KPj4+Pj4gLi4NCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IElFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4gaXB2NkBpZXRmLm9yZw0KPj4gQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0K Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQoNCg== From nobody Mon Nov 5 14:07:03 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C471286E7 for ; Mon, 5 Nov 2018 14:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 jrWcLZUIPHrM for ; Mon, 5 Nov 2018 14:06:58 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20692124D68 for ; Mon, 5 Nov 2018 14:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10490; q=dns/txt; s=iport; t=1541455618; x=1542665218; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=REPieG2QdSxVRxUNlBHv65AuHODFGiGfrO+YmSiOAkI=; b=a/NIzoMXyaU9aLBwbA4MAq/9dq+fCiPifH7Yg5XCww7wjiaLfkdzIiSn WG2kvm6+KG9McjoiBEDnfNvmsDAkhCV2Htr4fzueSZy2iUboRCoL4lVaL pkQQqhiwlgrEGdGl6T8oqMAis9iHujG3SYYEwVm9svLxEr425/NB4TjH5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABMvuBb/51dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCBGZ/KAqDbIgYjBiTZoVUgXoLAQEYAQoJhEA?= =?us-ascii?q?CF4M6IjQNDQEDAQECAQECbRwMhTsCAQMBASFLCxACAQgOMQMCAgIlCxQRAQE?= =?us-ascii?q?EDgWDIQGBHWQPqlWBLoU8hGIFi3YXgUE/gREnH4JMgxsBAYIXgk4xgiYCiQY?= =?us-ascii?q?DhVWQVAkCkQ8YgVWPC4lCjV0CERSBJh04gVVwFTsqAYJBgicXiF2FPm+BKIt?= =?us-ascii?q?OAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.54,469,1534809600"; d="scan'208,217";a="196564923" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 22:06:57 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id wA5M6ux1011823 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Nov 2018 22:06:57 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 5 Nov 2018 16:06:56 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Mon, 5 Nov 2018 16:06:56 -0600 From: "Darren Dukes (ddukes)" To: Ron Bonica CC: IPv6 List Subject: Re: draft-ietf-6man-segment-routing-header-15 Thread-Topic: draft-ietf-6man-segment-routing-header-15 Thread-Index: AdRyDvu4FzhF5rDiS9auJmSAqrSxPQDdys4A Date: Mon, 5 Nov 2018 22:06:56 +0000 Message-ID: <896C3666-9F00-41FD-A244-F49A69C260A9@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.123] Content-Type: multipart/alternative; boundary="_000_896C36669F0041FDA244F49A69C260A9ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 22:07:01 -0000 --_000_896C36669F0041FDA244F49A69C260A9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lDQoNCk9uIE5vdiAxLCAyMDE4LCBhdCAyOjQzIFBNLCBSb24gQm9uaWNhIDxyYm9uaWNh QGp1bmlwZXIubmV0PG1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQoNCkZvbGtz LA0KDQpUaGlzIHZlcnNpb24gbG9va3MgbXVjaCBiZXR0ZXIuIFRoYW5rcyBmb3IgcG9zdGluZyBp dC4NCg0KVGhlIGZvbGxvd2luZyBhcmUgYSBmZXcgY29tbWVudHMgdGhhdCBJIGFtIHN1cmUgY2Fu IGJlIGZpeGVkIGVhc2lseToNCg0KTWFqb3IgSXNzdWVzOg0KDQotICBJbiBTZWN0aW9uIDIuMS4y LjEsIGRpZCB5b3UgcmVhbGx5IG1lYW4gdG8gc2F5IHRoYXQgdGhlIEhNQUMgaXMgY2FsY3VsYXRl IG92ZXIgdGhlIFNlZ21lbnRzIExlZnQgZmllbGQ/IEdpdmVuIHRoYXQgU2VnbWVudHMgTGVmdCBp cyBtdXRhYmxlLCB3aGF0IHZhbHVlIHNob3VsZCBiZSB1c2VkPw0KTm8sIEpvaG4gTGVkZHkgYWxz byBjYXVnaHQgdGhpcyByaWdodCBhZnRlciB3ZSBzdWJtaXR0ZWQgaXQuICBJdOKAmXMgZml4ZWQg aW4gcmV2aXNpb24gMTYgYXMgc3VnZ2VzdGVkIGluIEF1Z3VzdCBvbiB0aGUgbGlzdCAtIGNoZWNr IHNlZ21lbnRzIGxpc3QgW3NlZ21lbnRzIGxlZnRdID09IGRlc3RpbmF0aW9uIGFkZHJlc3MgYXMg cGFydCBvZiBITUFDIHByb2Nlc3NpbmcNCg0KDQotIEluIFNlY3Rpb24gNC4zLjEuMiwgdGhlcmUg bWF5IGJlIGEgc2VudGVuY2UgbWlzc2luZy4gVW5kZXIgd2hhdCBjb25kaXRpb25zIHNob3VsZCB0 aGUgSUNNUCBQYXJhbWV0ZXIgUHJvYmxlbSBtZXNzYWdlIGJlIHNlbnQ/DQoNCkxpa2U6ICJXaGVu IHByb2Nlc3NpbmcgdGhlIFVwcGVyLWxheWVyIGhlYWRlciBvZiBhIEZJQiBlbnRyeSBsb2NhbGx5 IGluc3RhbnRpYXRlZCBhcyBhbiBTUnY2IFNJRC7igJ0/ICBEaWQgeW91IGhhdmUgc29tZXRoaW5n IGVsc2UgaW4gbWluZD8NCg0KDQotIFJGQyA0MzAyIHNheXMsICJBcyBhIG5ldyBleHRlbnNpb24g aGVhZGVyIG9yIElQdjQgb3B0aW9uIGlzIGNyZWF0ZWQsIGl0IHdpbGwgYmUgZGVmaW5lZCBpbiBp dHMgb3duIFJGQyBhbmQgU0hPVUxEIGluY2x1ZGUgKGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uKSBkaXJlY3Rpb25zIGZvciBob3cgaXQgc2hvdWxkIGJlIGhhbmRsZWQgd2hl biBjYWxjdWxhdGluZyB0aGUgQUggSUNWLuKAnQ0KT0ssIEkgcHJlZmVyIHRvIHVwZGF0ZSB0aGlz IHdpdGggdGhlIFRMViB0ZXh0IGluIHRoZSBkcmFmdC4gQnV0IHRoZSBmb2xsb3dpbmcgc2hvdWxk IGJlIGEgZ29vZCBzdGFydCB0byBnZXQgY29tbWVudHMgZnJvbSBXRyBtZW1iZXJzIG9uIHRoZSBs aXN0Lg0KDQpGb3IgdGhlIHB1cnBvc2Ugb2YgQUggSUNWIGNhbGN1bGF0aW9uIHRoZSBTUkggZmll bGRzIGFyZSBhcyBkZWZpbmVkDQpNdXRhYmxlOiBPcHRpb25hbCBUTFYgb2JqZWN0cyBhcyBkZWZp bmVkIHBlciBUTFYNCg0KTXV0YWJsZSBidXQgcHJlZGljdGFibGU6IHNlZ21lbnRzIGxlZnQsDQoN CkltbXV0YWJsZTogbmV4dCBoZWFkZXIsIGhkciBleHQgbGVuLCByb3V0aW5nIHR5cGUsIGZsYWdz LCB0YWcsIHNlZ21lbnQgbGlzdA0KDQoNCg0KSSB0aGluayB0aGF0IHRoaXMgcmVxdWlyZW1lbnQg Y2FuIGJlIHNhdGlzZmllZCB3aXRoIGEgdmVyeSBzaG9ydCBzZWN0aW9uIHRoYXQgY29udGFpbnMg dGhyZWUgYnVsbGV0cyBsaXN0cy4gVGhlIGJ1bGxldCBsaXN0cyB3b3VsZCBzYXkgd2hpY2ggU1JI IGZpZWxkcyBhcmUgbXV0YWJsZSwgcHJlZGljdGFibHkgbXV0YWJsZSwgYW5kIGltbXV0YWJsZS4g KFRoZXNlIHdvcmRzIGFyZSBhc3NvY2lhdGVkIHdpdGggcHJvY2Vzc2luZyBydWxlIGluIFJGQyA0 MjAzLikNCg0KTWlub3IgSXNzdWVzOg0KDQotIFRoZSBkcmFmdCBkb2Vzbid0IHRlbGwgdGhlIHJl YWRlciB3aGF0IHRvIGRvIHdoZW4gdGhlIHJlY2VpdmUgYSBub24temVybyB0YWcgZmllbGQuIElu IGZhY3QsIHRoZSBkb2N1bWVudCBzYXlzLCAiVGhlIGFsbG9jYXRpb24gYW5kIHVzZSBvZiB0YWcg aXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4iDQoNCkkgdGhpbmsgdGhhdCB3 ZSBuZWVkIHRvIGVpdGhlciBkZWZpbmUgdGhlIHRhZyBmaWVsZCBvciB0YWtlIGl0IG91dCBvZiB0 aGlzIGRvY3VtZW50Lg0KDQpZZXMsIHRoZXJlIGlzIGFuIG9wZW4gaXRlbSBmb3IgdGhpcyBhbmQg aXTigJlzIHRyYWNrZWQgZm9yIGRlZmluaXRpb24uDQoNCg0KLSBTYW1lIGFyZ3VtZW50IGZvciB0 aGUgRmxhZ3MgZmllbGQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3Jn PG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K --_000_896C36669F0041FDA244F49A69C260A9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <573C9A343FA112429E7BE4AA23E3C666@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCklubGluZTxiciBjbGFzcz0iIj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPk9uIE5vdiAxLCAyMDE4LCBhdCAyOjQzIFBNLCBSb24gQm9uaWNhICZsdDs8YSBocmVmPSJt YWlsdG86cmJvbmljYUBqdW5pcGVyLm5ldCIgY2xhc3M9IiI+cmJvbmljYUBqdW5pcGVyLm5ldDwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkZvbGtzLDxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClRoaXMgdmVyc2lvbiBsb29rcyBtdWNoIGJldHRlci4gVGhhbmtzIGZvciBw b3N0aW5nIGl0LiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgZm9sbG93aW5nIGFy ZSBhIGZldyBjb21tZW50cyB0aGF0IEkgYW0gc3VyZSBjYW4gYmUgZml4ZWQgZWFzaWx5OjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk1ham9yIElzc3Vlczo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQotICZuYnNwO0luIFNlY3Rpb24gMi4xLjIuMSwgZGlkIHlvdSByZWFsbHkgbWVh biB0byBzYXkgdGhhdCB0aGUgSE1BQyBpcyBjYWxjdWxhdGUgb3ZlciB0aGUgU2VnbWVudHMgTGVm dCBmaWVsZD8gR2l2ZW4gdGhhdCBTZWdtZW50cyBMZWZ0IGlzIG11dGFibGUsIHdoYXQgdmFsdWUg c2hvdWxkIGJlIHVzZWQ/PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCk5vLCBKb2huIExlZGR5IGFsc28gY2F1Z2h0IHRoaXMgcmlnaHQgYWZ0ZXIgd2Ugc3VibWl0 dGVkIGl0LiAmbmJzcDtJdOKAmXMgZml4ZWQgaW4gcmV2aXNpb24gMTYgYXMgc3VnZ2VzdGVkIGlu IEF1Z3VzdCBvbiB0aGUgbGlzdCAtIGNoZWNrIHNlZ21lbnRzIGxpc3QgW3NlZ21lbnRzIGxlZnRd ID09IGRlc3RpbmF0aW9uIGFkZHJlc3MgYXMgcGFydCBvZiBITUFDIHByb2Nlc3Npbmc8L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQotIEluIFNlY3Rpb24g NC4zLjEuMiwgdGhlcmUgbWF5IGJlIGEgc2VudGVuY2UgbWlzc2luZy4gVW5kZXIgd2hhdCBjb25k aXRpb25zIHNob3VsZCB0aGUgSUNNUCBQYXJhbWV0ZXIgUHJvYmxlbSBtZXNzYWdlIGJlIHNlbnQ/ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pkxpa2U6ICZxdW90O1doZW4gcHJvY2Vzc2luZyB0aGUgVXBw ZXItbGF5ZXIgaGVhZGVyIG9mIGEgRklCIGVudHJ5IGxvY2FsbHkgaW5zdGFudGlhdGVkIGFzIGFu IFNSdjYgU0lELuKAnT8gJm5ic3A7RGlkIHlvdSBoYXZlIHNvbWV0aGluZyBlbHNlIGluIG1pbmQ/ PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCi0gUkZDIDQzMDIg c2F5cywgJnF1b3Q7QXMgYSBuZXcgZXh0ZW5zaW9uIGhlYWRlciBvciBJUHY0IG9wdGlvbiBpcyBj cmVhdGVkLCBpdCB3aWxsIGJlIGRlZmluZWQgaW4gaXRzIG93biBSRkMgYW5kIFNIT1VMRCBpbmNs dWRlIChpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbikgZGlyZWN0aW9ucyBm b3IgaG93IGl0IHNob3VsZCBiZSBoYW5kbGVkIHdoZW4gY2FsY3VsYXRpbmcgdGhlIEFIIElDVi7i gJ08L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KT0ssIEkgcHJlZmVyIHRvIHVwZGF0ZSB0 aGlzIHdpdGggdGhlIFRMViB0ZXh0IGluIHRoZSBkcmFmdC4gQnV0IHRoZSBmb2xsb3dpbmcgc2hv dWxkIGJlIGEgZ29vZCBzdGFydCB0byBnZXQgY29tbWVudHMgZnJvbSBXRyBtZW1iZXJzIG9uIHRo ZSBsaXN0LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Rm9yIHRoZSBw dXJwb3NlIG9mIEFIIElDViBjYWxjdWxhdGlvbiB0aGUgU1JIIGZpZWxkcyBhcmUgYXMgZGVmaW5l ZDwvZGl2Pg0KPGRpdj48YiBjbGFzcz0iIj5NdXRhYmxlPC9iPjogT3B0aW9uYWwgVExWIG9iamVj dHMgYXMgZGVmaW5lZCBwZXIgVExWJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj48YiBjbGFzcz0iIj5NdXRhYmxlJm5ic3A7YnV0IHByZWRpY3RhYmxlOiA8L2I+ c2VnbWVudHMgbGVmdCwmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PjxiIGNsYXNzPSIiPkltbXV0YWJsZTo8L2I+Jm5ic3A7bmV4dCBoZWFkZXIsIGhkciBleHQg bGVuLCByb3V0aW5nIHR5cGUsIGZsYWdzLCB0YWcsIHNlZ21lbnQgbGlzdDwvZGl2Pg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQpJIHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVudCBjYW4gYmUgc2F0aXNmaWVkIHdp dGggYSB2ZXJ5IHNob3J0IHNlY3Rpb24gdGhhdCBjb250YWlucyB0aHJlZSBidWxsZXRzIGxpc3Rz LiBUaGUgYnVsbGV0IGxpc3RzIHdvdWxkIHNheSB3aGljaCBTUkggZmllbGRzIGFyZSBtdXRhYmxl LCBwcmVkaWN0YWJseSBtdXRhYmxlLCBhbmQgaW1tdXRhYmxlLiAoVGhlc2Ugd29yZHMgYXJlIGFz c29jaWF0ZWQgd2l0aCBwcm9jZXNzaW5nIHJ1bGUgaW4gUkZDDQogNDIwMy4pPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KTWlub3IgSXNzdWVzOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCi0gVGhlIGRyYWZ0IGRvZXNuJ3QgdGVsbCB0aGUgcmVhZGVyIHdoYXQgdG8gZG8gd2hlbiB0 aGUgcmVjZWl2ZSBhIG5vbi16ZXJvIHRhZyBmaWVsZC4gSW4gZmFjdCwgdGhlIGRvY3VtZW50IHNh eXMsICZxdW90O1RoZSBhbGxvY2F0aW9uIGFuZCB1c2Ugb2YgdGFnIGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnQuJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K SSB0aGluayB0aGF0IHdlIG5lZWQgdG8gZWl0aGVyIGRlZmluZSB0aGUgdGFnIGZpZWxkIG9yIHRh a2UgaXQgb3V0IG9mIHRoaXMgZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlllcywgdGhl cmUgaXMgYW4gb3BlbiBpdGVtIGZvciB0aGlzIGFuZCBpdOKAmXMgdHJhY2tlZCBmb3IgZGVmaW5p dGlvbi48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KLSBTYW1l IGFyZ3VtZW50IGZvciB0aGUgRmxhZ3MgZmllbGQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Um9uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnIgY2xhc3M9IiI+DQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgY2xhc3M9IiI+ aXB2NkBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PGJyIGNsYXNzPSIiPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_896C36669F0041FDA244F49A69C260A9ciscocom_-- From nobody Mon Nov 5 17:07:12 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BEC12DDA3; Mon, 5 Nov 2018 17:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 IkrP9mAEM1nJ; Mon, 5 Nov 2018 17:06:56 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00119.outbound.protection.outlook.com [40.107.0.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D4D126DBF; Mon, 5 Nov 2018 17:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PoRygnlaJWGs1pjUln2Hm2+alH3F9NfgRUgxVZ6O+EY=; b=GdA6dyk+Fy+CybiIxo4P8ejSmwbZqTRaWdObYlpnyDjh3t0fuZHu8Y/8vgsFwTi7eJFjpTZqcKJuL4torP7UGFfOGtGdmXvIhX3iib622hdPaJYs16fHY/4hXb38yGUJcdbDybxYAlTNordgZKBa5Z7T0LyE77I4IjHIEoJWqJg= Received: from DB6PR07MB3477.eurprd07.prod.outlook.com (10.175.234.32) by DB6PR07MB3463.eurprd07.prod.outlook.com (10.170.222.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Tue, 6 Nov 2018 01:06:52 +0000 Received: from DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686]) by DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686%2]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 01:06:52 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Gert Doering , Linda Dunbar CC: "idr@ietf.org" , "ipv6@ietf.org" , "int-area@ietf.org" , Fred Baker Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AQHUdPQP+ZmmSSJuak+m74M0Ps0ZxKVBaBCAgACYwgA= Date: Tue, 6 Nov 2018 01:06:52 +0000 Message-ID: <4B2F3673-5106-4914-B79F-F3C44013ED06@nokia.com> References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> <20181105165959.GB11393@Space.Net> In-Reply-To: <20181105165959.GB11393@Space.Net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.12.0.181014 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-originating-ip: [110.170.235.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3463; 6:weuF8YeXtGntx5qlF0wKsBi/t5FfzVpExWS35eGo1pru37V2OxDL0gQ5jbsPMJW+ciJmZ+bVvZXVtJ+ZqQcqnIL1tKFYHboHYS5tjPV4TdnA0bLfGT0V02D27w5QvfGjx/SqZTl5iwBr/aAVkn2bQXHtJ1IZAunb93c8ofHhWMSJHOc8BQdo+IMTNUY8eTmyGRN4gC8PaeLJaXd2NMI1DRnliGa1A48KR7svKbcf5RlyaLPBAAa9KgssKkgOxIRlL2oSKl5I2K68lf8zGaNad8oJLlSXr88UnWBZgMqjThmBBNsAzPoUqVBMd4QTBZLmiwNH4SEmqjVzO1DgqlLroJoBIT+lDZaK8mXQOKHNDf9I+m2cn067ZkaAIxW7ODcVUb7PZES9JksYAzYWl1HyslkpsJ/XEHKBerl+5dtOWDHb2ijqH7lyuelrBJBu3Em1YToM//fPrRbYCvp3SoZYhg==; 5:VO4LgWgu2KrRyWL25mX09USEZAgdQUpQHHs1vI1AxjvmyN7l4kPxvvHLeWCKV+F33zeRUOgC6mO8/l8SWvflfyjrVDrXx5u1/T6WzElb2xYzOtIpX6Yjh8de/TxYOX8w9BmS7fPdBHz/fAx+2/aZG/3mzL0D/aPAcz5LrcYo8bI=; 7:yjTN9LdnJOSPCUylaP5GdMfWhj8rROh0B0R8dUNZf0zASpkbF+KPbUARdmbYYpTfN4UPUsHJzVHF0sLpVrAFS6G+ItzpAiPly4pP/eIhV5s40bv5xeOMRAzZmVdasCGNnjgrJPpZHf3JX3TfMFc6xQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a9d2e81d-67d0-4865-90df-08d643842375 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7167020)(7193020); SRVR:DB6PR07MB3463; x-ms-traffictypediagnostic: DB6PR07MB3463: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB6PR07MB3463; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3463; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(376002)(396003)(39860400002)(189003)(199004)(305945005)(97736004)(6306002)(446003)(93886005)(5660300001)(11346002)(2906002)(76176011)(229853002)(6436002)(6512007)(6486002)(486006)(2616005)(7736002)(186003)(4326008)(316002)(476003)(53936002)(71200400001)(83716004)(55236004)(71190400001)(6506007)(66066001)(25786009)(39060400002)(81156014)(86362001)(33656002)(478600001)(58126008)(6116002)(110136005)(102836004)(36756003)(99286004)(966005)(3846002)(26005)(6246003)(14454004)(106356001)(105586002)(8676002)(256004)(8936002)(68736007)(54906003)(14444005)(81166006)(2900100001)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB3463; H:DB6PR07MB3477.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bwMQS/KJF9AIkr+Q1JDMfBj+ufbCmvURkNlSsZS1nu0ZJSPppSrNjv6k8XLBJgxaUQpVWPb/3Cp/NPZ4Xje2kaKWjgil3URVFjznN64Hma7guxs1nWdLWdFNgqg2DS8M0SxJ/Z5KCc39ckYVZ93amXBDhlLuBHlVEQC0L2CUwGNh1sMYjvU1CvzVtdq4jnI8y8AHrNK1VfDrV0vIqlR5sSJQVWq174+GswfjipWBrQk7i8P4hNxPylqn2WMBppEY/VVaSebr9Lplwtck44v9ZtGM3WLMkHsqVfIJw2coGuhUYTh1x5bxBG39Wa3uuafbV8+TNXqoOIh5719zhF7LzAaq8t3MbbqDk9tvtRfoNN0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <91507FF468EF8448A1F2BBCC26D6F073@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a9d2e81d-67d0-4865-90df-08d643842375 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 01:06:52.7444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3463 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 01:06:58 -0000 RXZlbiBhIE5BVDY0IGlzIG5vdCBuZWVkZWQuIFdoYXQgd2UgZG8gbm93IGlzIHdlIGdvIHRvIGEg R1cgKGxldHMgY2FsbCBpdCBsaWtlIHRoaXMgZm9yIG5vdykgYW5kIHRoZSBHVyByZXdyaXRlcyB0 aGUgb3V0ZXIgaGVhZGVyIG9mIHRoZSB0dW5uZWwgc3JjSVAgYW5kIGRzdElQIGZyb20gdjQgdG8g djYgb3IgdmljZSB2ZXJzYS4gSXQgaXMga2luZCBvZiBkZWNhcC9lbmNhcCBvcGVyYXRpb24gb24g dGhlIG91dGVyIGhlYWRlciBhcyBpZiB5b3UgdGVybWluYXRlIHRoZSB0dW5uZWwgYW5kIHJlaW5p dGlhdGUgdGhlIHR1bm5lbC4gTm8gTkFUNjQgcmVxdWlyZWQuDQoNCg0KDQrvu79PbiAwNi8xMS8y MDE4LCAwMDowMCwgIklkciBvbiBiZWhhbGYgb2YgR2VydCBEb2VyaW5nIiA8aWRyLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGdlcnRAc3BhY2UubmV0PiB3cm90ZToNCg0KICAgIEhpLA0K ICAgIA0KICAgIE9uIE1vbiwgTm92IDA1LCAyMDE4IGF0IDEwOjQwOjM2QU0gKzAwMDAsIExpbmRh IER1bmJhciB3cm90ZToNCiAgICA+IElmIGEgQ1BFLTEgaGFzIHByaXZhdGUgSVB2NiBhZGRyZXNz ZXMgZm9yIGl0cyBwb3J0cyBiZWhpbmQgTkFULCBhbmQgQ1BFLTIgaGFzIElQdjQgYWRkcmVzcywg Y2FuIENQRS0xIGNvbW11bmljYXRlIHdpdGggQ1BFLTIgYnkgdGhlIE5BVCdzIElQdjQgYWRkcmVz cz8gDQogICAgDQogICAgU2luY2UgdGhlcmUgYXJlIG5vIHByaXZhdGUgSVB2NiBhZGRyZXNzZXMs IG5vLg0KICAgIA0KICAgIEdlbmVyYWxseSBzcGVha2luZywgaWYgQ1BFMSBoYXMgb25seSBJUHY2 IGFkZHJlc3NlcyBhbmQgQ1BFMiBoYXMgb25seQ0KICAgIGFuIElQdjQgYWRkcmVzcywgdGhlIGFu c3dlciBpcyBubyBhcyB3ZWxsLCB1bmxlc3MgdGhlcmUgaXMgYSBOQVQ2NCANCiAgICBpbnZvbHZl ZCBzb21ld2hlcmUuDQogICAgDQogICAgR2VydCBEb2VyaW5nDQogICAgICAgICAgICAtLSBOZXRN YXN0ZXINCiAgICAtLSANCiAgICBoYXZlIHlvdSBlbmFibGVkIElQdjYgb24gc29tZXRoaW5nIHRv ZGF5Li4uPw0KICAgIA0KICAgIFNwYWNlTmV0IEFHICAgICAgICAgICAgICAgICAgICAgIFZvcnN0 YW5kOiBTZWJhc3RpYW4gdi4gQm9taGFyZCwgTWljaGFlbCBFbW1lcg0KICAgIEpvc2VwaC1Eb2xs aW5nZXItQm9nZW4gMTQgICAgICAgIEF1ZnNpY2h0c3JhdHN2b3JzLjogQS4gR3J1bmRuZXItQ3Vs ZW1hbm4NCiAgICBELTgwODA3IE11ZW5jaGVuICAgICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAo QUcgTXVlbmNoZW4pDQogICAgVGVsOiArNDkgKDApODkvMzIzNTYtNDQ0ICAgICAgICAgVVN0LUlk TnIuOiBERTgxMzE4NTI3OQ0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgSWRyIG1haWxpbmcgbGlzdA0KICAgIElkckBpZXRmLm9y Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQogICAgDQoN Cg== From nobody Mon Nov 5 17:08:10 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534BD130DC7; Mon, 5 Nov 2018 17:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 kateSPC_peh1; Mon, 5 Nov 2018 17:08:07 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00139.outbound.protection.outlook.com [40.107.0.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50780126DBF; Mon, 5 Nov 2018 17:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FyuV9osTuAeNIsmave3CdNSHncvjHn1wBj8UecJOFqo=; b=NoyTueJIKC/K7ajIrUQTNcsnCijwFE/+0hRGbnEPWnjFD1/GLNamS+kIJKyD6A8wljvrLTPrd9ETTPKe7AsqAfxpJ8wAT+gSJu7pyLKw0lyN4gCBy/jR0DAvH0h3ssVfIKB/OjKfw1sXfCb5PVm+VGwBBu5mcpdlUFgeG8GJBlc= Received: from DB6PR07MB3477.eurprd07.prod.outlook.com (10.175.234.32) by DB6PR07MB3463.eurprd07.prod.outlook.com (10.170.222.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Tue, 6 Nov 2018 01:08:05 +0000 Received: from DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686]) by DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686%2]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 01:08:05 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Linda Dunbar , Fred Baker CC: "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AQHUdPQP+ZmmSSJuak+m74M0Ps0ZxKVA/l6AgAAkbQCAADsCAIAAo1yA Date: Tue, 6 Nov 2018 01:08:04 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F66B182E67@sjceml521-mbs.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B182E67@sjceml521-mbs.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.12.0.181014 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-originating-ip: [110.170.235.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3463; 6:RYHJQPYI4fUkwRPsKmRlYeY6YrKp0oGVbmwtqIY8kB6/gENN9ajXyg3ammB1FEeNPz9EpZadcoy2l0QRE/cHNWsMGcWUwYVra1apJ68YWS+ODGvPChdI2GlDc2q8UPUlyv6IO0ugWNvO7MYJvbXxlFcsoVUuFyJ/tVC6jT0ZAAwlUdFlCvY8wRTLrQ1+Gmke7lDC02dTGXuJ32/VU0WRlt1YC8MfLObCKUtNyYUIka5P+DBagjXDF2k2aqz5RNduTgoKAqXp/gwhkqCY1BfkmNquB1Y3hGZTsDQ9FysTGcWZT5zLw7lhiVOrfIgncHu82uCbFYE36eXv2n57aQAyuUFcVLQIbRb8nQ+z/PPz5VD17IaYlwHzWxTQQAwyXkKr9nggFAy5yUdBvsD50U1pdO3wpuxT/CgF7IQeNEB/iUIQka7fnHKt2bLRuRADcAVWsi9YBWpUs7AYN9/yX7NSJw==; 5:HtGvr/Lnf0oOLbwXFd7ltbZPK4/A7IGPqYjanMrN7hJGZHrZ7oFYABQ2pVDtAYA75okbZyb2RLBRCqdtFJ5LRz1SWPbsUs3XIS4UgGFvtMJPnBzJv+/aWCwW0ppSnI7BQpWzI1dhhse3n+qc9M+YkLRzjXcomJ+XBoTuK9nDICk=; 7:vjslA9o4Pb7lxqs7qoTCz0ZMVEBNB+u5kOPuLRQk+wlyIYOKay7MVkHu+BVWLXyxyklVDS5eX77X5KXwbgGNJ48AvMDt/3WA647kEFzlykwsLqJFPlLzrzAjyRDD1Nq7Q/KFZHyX1VFyblBOaw41nw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e7db8649-a4fa-4e43-5e99-08d643844e7a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7167020)(7193020); SRVR:DB6PR07MB3463; x-ms-traffictypediagnostic: DB6PR07MB3463: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21532816269658)(195916259791689)(82608151540597)(109105607167333)(50582790962513)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB6PR07MB3463; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3463; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(376002)(396003)(39860400002)(189003)(199004)(13464003)(305945005)(97736004)(446003)(93886005)(5660300001)(11346002)(2906002)(76176011)(229853002)(6436002)(6512007)(6486002)(486006)(2616005)(7736002)(186003)(4326008)(316002)(476003)(53936002)(53546011)(71200400001)(83716004)(55236004)(71190400001)(6506007)(66066001)(25786009)(39060400002)(81156014)(86362001)(33656002)(478600001)(58126008)(6116002)(110136005)(102836004)(36756003)(99286004)(3846002)(26005)(6246003)(14454004)(106356001)(105586002)(8676002)(256004)(8936002)(68736007)(54906003)(81166006)(2900100001)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB3463; H:DB6PR07MB3477.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vPgGiCvc4lBcum2+XnXVDccUxHsaO+RYH9mInsGHBZkkVlFrsdTW5rO2wo0iD8rWJAJY88f08U//It1wu55TPVxx++Bmktn7PXHXdixS6zQzFH+EWn6HNO3nXj44GBz7gtYoTfIz99kX798I01Xsy8mpMAUPFB9Nkh5OZka1ds81B3HYrHduVnU7gpsga/xRGT86FB6+tcBnLOSeyovZwJesWIFGBRcagVuoencLMFosC5lDtWmBmpeYTwg1Gf41ZtHQe6dzkSCf+LV7F5h8j9v0m7tjyZYzPf2ptTsn3BXw/QUdqcYn87Acch7o4+9PBsTFIlICnzoGqGw3fu+v9iwyfM+mhhbmQXZ2qaf9kTA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9108D6081A33CE4F806C18CAE6090697@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7db8649-a4fa-4e43-5e99-08d643844e7a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 01:08:04.9239 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3463 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 01:08:09 -0000 VGhlIHNlbWFudGljcyBvbiBob3cgdG8gaGFuZGxlIHRoaXMgaXMgYSBkaWZmZXJlbnQgZGlzY3Vz c2lvbi4gSSBiZWxpZXZlIHRoZSBiYXNpYyBvcGVyYXRpb24gbmVlZHMgdG8gYmUgdW5kZXJzdG9v ZCBmaXJzdC4gQWZ0ZXIgd2UgY2FuIHNlZSBob3cgdGhpcyBzaG91bGQgYmUgc2lnbmFsZWQuDQoN Cu+7v09uIDA1LzExLzIwMTgsIDIzOjIzLCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1 YXdlaS5jb20+IHdyb3RlOg0KDQogICAgU28gd2UgbmVlZCB0byBhZGQgYW5vdGhlciB0eXBlIHRv IHRoZSBzdWJUTFY6IE1hcHBpbmcgKGZvciB0aGUgc2NlbmFyaW8gb2YgQ1BFIHVzaW5nIElQdjYs IGJlaW5nIHRyYW5zbGF0ZWQgdG8gSVB2NCB0byBjb25uZWN0IHRvIGl0cyBwZWVyIHRoYXQgdXNl cyBJUHY0LCBjb3JyZWN0Pw0KICAgIA0KICAgIExpbmRhDQogICAgDQogICAgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBIZW5kZXJpY2t4LCBXaW0gKE5va2lhIC0gQkUvQW50 d2VycCkgW21haWx0bzp3aW0uaGVuZGVyaWNreEBub2tpYS5jb21dIA0KICAgIFNlbnQ6IE1vbmRh eSwgTm92ZW1iZXIgMDUsIDIwMTggNjo1MiBQTQ0KICAgIFRvOiBGcmVkIEJha2VyIDxmcmVkYmFr ZXIuaWV0ZkBnbWFpbC5jb20+OyBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29t Pg0KICAgIENjOiBpZHJAaWV0Zi5vcmc7IGludC1hcmVhQGlldGYub3JnOyBpcHY2QGlldGYub3Jn DQogICAgU3ViamVjdDogUmU6IFtJZHJdIFVzaW5nIEJHUCB0byBhZHZlcnRpc2UgU0QtV0FOIHR1 bm5lbHMgZW5kIHBvaW50J3MgcHJpdmF0ZSBJUHY2IGFkZHJlc3Nlcy4gKHdhcyByZWdpc3Rlcmlu ZyB0dW5uZWwgdHlwZXMNCiAgICANCiAgICBJbiBTRC1XQU4gY3R4dCwgdG8gbGV0IGEgc2l0ZSB3 aGljaCBoYXMgSVB2NCBvbiB0aGUgV0FOIHRhbGsgdG8gYW5vdGhlciBzaXRlIHdoaWNoIGhhcyAg SVB2NiBvbiB0aGUgV0FOLCB3ZSB3aWxsIG5lZWQgdG8gc2VuZCB0aGUgcGFja2V0cyB0byBhIGRl dmljZSB3aG8gY2FuIG1hcCB0aGUgdjQgYWRkcmVzcyB0byBhIHY2IGFkZHJlc3MgKG5vIE5BVCwg YnV0IG1hcHBlZCBJIGNhbGwgaXQpLiBUaGUgbWFwcGluZyB0YWJsZSBoYXMgbm90aGluZyB0byBk byB3aXRoIE5BVCBhbmQgaXMgc2V0dXAgYnkgYSBjb250cm9sbGVyIGluIG1vc3Qgc29sdXRpb25z Lg0KICAgIA0KICAgIE5vdyB0aGlzIGlzIHdvcmtpbmcgaXJyZXNwZWN0aXZlIGlmIHRoZSB2NCBz aXRlIGlzIE5BVGVkICAob25lIHdheSBvciBhbm90aGVyKSBvciBub3QuDQogICAgDQogICAgT24g MDUvMTEvMjAxOCwgMTc6NDIsICJJZHIgb24gYmVoYWxmIG9mIEZyZWQgQmFrZXIiIDxpZHItYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZnJlZGJha2VyLmlldGZAZ21haWwuY29tPiB3cm90 ZToNCiAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICA+IE9uIE5vdiA1LCAyMDE4LCBh dCA1OjQwIFBNLCBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiB3cm90ZToN CiAgICAgICAgPiANCiAgICAgICAgPiBJZiBhIENQRS0xIGhhcyBwcml2YXRlIElQdjYgYWRkcmVz c2VzIGZvciBpdHMgcG9ydHMgYmVoaW5kIE5BVCwgYW5kIENQRS0yIGhhcyBJUHY0IGFkZHJlc3Ms IGNhbiBDUEUtMSBjb21tdW5pY2F0ZSB3aXRoIENQRS0yIGJ5IHRoZSBOQVQncyBJUHY0IGFkZHJl c3M/DQogICAgICAgIA0KICAgICAgICBUaGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGFuIElQdjYg cHJpdmF0ZSBhZGRyZXNzLiBJJ20gbm90IHN1cmUgaG93IHRvIHJlc3BvbmQgdG8gdGhlIHF1ZXN0 aW9uLg0KICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICBWaWN0b3Jpb3Vz IHdhcnJpb3JzIHdpbiBmaXJzdCBhbmQgdGhlbiBnbyB0byB3YXIsDQogICAgICAgIERlZmVhdGVk IHdhcnJpb3JzIGdvIHRvIHdhciBmaXJzdCBhbmQgdGhlbiBzZWVrIHRvIHdpbi4NCiAgICAgICAg ICAgICBTdW4gVHp1DQogICAgICAgIA0KICAgICAgICANCiAgICANCiAgICANCg0K From nobody Mon Nov 5 18:01:11 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4112F295 for ; Mon, 5 Nov 2018 18:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 VB6-L2yuUpr5 for ; Mon, 5 Nov 2018 18:01:08 -0800 (PST) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 76C9912D4EA for ; Mon, 5 Nov 2018 18:01:08 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id y4so4640046pgc.12 for ; Mon, 05 Nov 2018 18:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=Fvg7lEW0z67IBPP/l0xm3vgjAL9+TPtp7ZaqhlJBjpk=; b=bnoVwz4zKq9p4yiuG7dU6U0FL7qCPqmwymd8pH9xzB6eS48lstZcJXkJHeCyBpliQR OpiBaZ0mmU2F03Hc5OtSozUy8ax910T9E2kd/Z2micPkIxJkR+H2Dyk3qGDJ3JsZxzc3 dT/AZaZEC2G2yqdxKUdxa99O4iTMXOGQxvZ0XzCm1Ku60k0j6uuXPKEXLCoY5bOIMDau 1LYeFdDAGQrVmHSpky50Hh6RI+4NmiikboJOZ48chvuktHDG1g/s5jftJRTZS50ksgqU f6ySGmIrHKx0w03ZVD6eCQw6+h41+/pflpQiqA8fJ1gGIHd5vdroKwMSbcplhjbgsZDx 9x9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=Fvg7lEW0z67IBPP/l0xm3vgjAL9+TPtp7ZaqhlJBjpk=; b=qKZKRzUlnNZxUlksg4QeoDRFZ++CFvJ5b1N5J2xm0Se0vzLj6OJHp+aKWZWcuTg5+4 LmsGufoyez6ca6UrmpePKCwRj00p9jz7E730W3LtOrySvfNRQFbo64rS8SDNlafMBmXK 2z3OrVABnjueQqrRdURBUt3z35fLK4YhZ53swekBpb+ejVgVUuqDZmmxAsM3HNLXv3Uq s9m1c4G3LdFI0oLfZCxZCCvZg/UqJhJtm0FKjFYIru7ULQ7/5NRsfKz4tYhA6X4rzK1N 2matYzzgffzuOS8KzhCr/90ms3WfYDtYKtHlQKx+sJxcEkB/INVdjPJ68FpBM4Zfdhvr L3fQ== X-Gm-Message-State: AGRZ1gJ5UQz2rnLzJJWMdvrok0DIrfxQ1BQlWrEfVUjbJldrUZUOpKqn 9QyF5t3lB8w09KnMetMmK65ij6sh X-Google-Smtp-Source: AJdET5eKgb4mIZ/XdVVYqOfvWsblxnZpiWFif7Sua1gNhnhNd39opYqkZjadEB3zqQiTO0jI7kaccQ== X-Received: by 2002:a62:31c2:: with SMTP id x185-v6mr6371570pfx.39.1541469667627; Mon, 05 Nov 2018 18:01:07 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:7c70:a184:8d35:e91e? ([2001:67c:370:128:7c70:a184:8d35:e91e]) by smtp.gmail.com with ESMTPSA id 72-v6sm57571893pfl.126.2018.11.05.18.01.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 18:01:06 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_F120C398-B048-4767-A206-8CDC9C2B80CD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Jabber Scribe needed for today's 6man session Message-Id: Date: Tue, 6 Nov 2018 09:01:05 +0700 Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 02:01:10 -0000 --Apple-Mail=_F120C398-B048-4767-A206-8CDC9C2B80CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, We still need a jabber scribe for today=E2=80=99s meeting. Please = volunteer. Many thanks to Barbara Stark who going to be our minute taker. Thanks, Bob & Ole --Apple-Mail=_F120C398-B048-4767-A206-8CDC9C2B80CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlvg9eEACgkQrut0EXfn u6jv3Af9E90VqMMWsUjYd/FOH4u7JT9e39N7NjEKSWjH+QRQNPrPVcn6AjK4tfVm X2VXPAMhj9wC6PiPfiLbVkQglu5+75739Ud7opwV8bmvhLPSwj6nQa7y1nnn/MJr q0/bJFLL/cNGCaZXjzacDjd1WCxUv8ea2I10uwt+AFX9yQwabcycZn0ENwG+lwda TLHNhINhGUy/jPNiKIs/cV1s+yJre+p8VegSTiWoIWXOgPEGb56RBRA1yrYVlX3h L2y1P8jLi5zxOqnapMqygeytFeCFNQdPAzocbUtSo4u7cRpUFBYb0MrhEYTiBj4V tHEQJfzupKfbgVGCUc1K0RmueTosBQ== =j9kY -----END PGP SIGNATURE----- --Apple-Mail=_F120C398-B048-4767-A206-8CDC9C2B80CD-- From nobody Mon Nov 5 18:52:42 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BAB130DD1 for ; Mon, 5 Nov 2018 18:52:40 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SJQ6MxYIzknb for ; Mon, 5 Nov 2018 18:52:38 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 70839130DCC for ; Mon, 5 Nov 2018 18:52:38 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id r64-v6so5377479pfb.13 for ; Mon, 05 Nov 2018 18:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WAgErqetdMgBe2xg4qoIGLmXgspKu+hXOSK2Ze6bxO0=; b=JRgo3njb1wnI0Mu8Ys4E6E0dwWIfYU5DXvIwXz3NHzP2bVoCHY+DgJ4/vhXdOlwgg4 PB9gkCH2T9ClNjCrdQKBmtivRYLyNS9hcyD0vZKWBRPtXnfFWBw9oo9aQv/PzHhpJsF1 Y2LRhql6NCW034Okkupt1Xryt/2hvf8bfWmetTAsbirYk9vVcXKto5U3tzqb+v9wpCFE H052TpawKjtDrziRx4sQ5/QQutgpaKMwlRdULo7lx6H5S2ueJ5mALCkg/kQKRKj2HbJa g/dxnE1n/YgBD/jl1U28sSN7Jw8EdtTuu5wQ3JVnuLfwFpmJcm55YTlT8Nghp0pQIXJQ UUdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WAgErqetdMgBe2xg4qoIGLmXgspKu+hXOSK2Ze6bxO0=; b=nh+88y/ScQK90FzFHfC7cMbb8hbXdaJBy174GKUTNQzVEUBi+OrgjJvomacvU0p6f1 qVqC4JCl7QpaJp4A5EUJjEiFdgt9AwXdI2IEFSTpQAlVio+5o9XQJt0RHdruE0byJeAX To+/iU1dRCSxVRG2IPVi+dQMDu+YjPU24YLHoiepqYfA8EDnmr3G4mco48wEd7XAiHxN Q+bIKwGnOqXBq8X8XQXEWzIVdyHhW4OoRx3Uk5W7WT88ZsiuUwlK2vZK2HA+/hXGAWMT oRuRsw3CPVCe8ry5QKIzeJdli0tuUv2oBZPPPOlwlGvJ1rE+nTo08cMTX7VLQesRqMtN BSbQ== X-Gm-Message-State: AGRZ1gIfrafcrd8XSazcioLxVJGRr12Lql+XrI7MGtmxNLgKjrXG7z31 X8j72V2hPsS+Rd5b51w+VFM= X-Google-Smtp-Source: AJdET5fvFw1EEXu/t/l/zr9WiMOwJKbN6sFzgLJMc8WIA58Y3M0NDVNxuj8jQfcG6fVZJJI7Faw5PQ== X-Received: by 2002:a63:e101:: with SMTP id z1mr18806061pgh.310.1541472757785; Mon, 05 Nov 2018 18:52:37 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:7c70:a184:8d35:e91e? ([2001:67c:370:128:7c70:a184:8d35:e91e]) by smtp.gmail.com with ESMTPSA id z5-v6sm47766107pfd.99.2018.11.05.18.52.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 18:52:36 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_BAFC4832-FA0B-4D34-B8E6-1A019623C289"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Date: Tue, 6 Nov 2018 09:52:34 +0700 In-Reply-To: <10a71216-7aed-8089-3b6c-a8f952daaf4c@gmail.com> Cc: Bob Hinden , Nick Hilliard , IPv6 List To: Brian Carpenter References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> <10a71216-7aed-8089-3b6c-a8f952daaf4c@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 02:52:41 -0000 --Apple-Mail=_BAFC4832-FA0B-4D34-B8E6-1A019623C289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Nov 6, 2018, at 2:37 AM, Brian E Carpenter = wrote: >=20 > On 2018-11-06 00:15, Nick Hilliard wrote: >> Brian E Carpenter wrote on 05/11/2018 07:38: >>> And yes, a host MAY ignore it (that's the complement to the SHOULD >>> in the draft). We've never said anything else. >>=20 >> yes, but you have stated "On an IPv6-Only link, IPv4 might be used = for >> malicious purposes and pass unnoticed by IPv6-Only monitoring = mechanisms". >>=20 >> If you want ipv6only-flag to be advisory, then you need to remove = this >> bullet-point from the document because the presence or absence of an = RA >> with ipv6only-flag set will not have any effect on malicious use of = ipv4 >> on an otherwise "ipv6-only" network. >=20 > Yes, you're correct. There is a slight mitigation effect - hosts that = *do* > use the flag to shut down IPv4 operations will not see any malicious = IPv4 > traffic. To clarify, the draft says that hosts SHOULD do what the flag specifies. = It doesn=E2=80=99t say it is advisory. RFC2119 defines SHOULD as: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. This discussion would be better if we used the words that are in the = draft in the discussion. I do agree that a node that doesn=E2=80=99t support IPv4 will not see = IPv4 traffic, this needs to be clarified in the current draft. Thanks, Bob >=20 > Some rewording is needed. >=20 >> You cannot use security to justify something unless the proposal >> provides a mechanism for enforcement; if you have no means of >> enforcement, it's fluff, not security. >>=20 >> Nick >=20 > Thanks > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_BAFC4832-FA0B-4D34-B8E6-1A019623C289 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlvhAfIACgkQrut0EXfn u6iGMQgArVlvk2AamVWce0OaLES2VS+WHorYS0HtPNQl2cYGxQyKx7PTCh+vdn7/ HU3pRqPo/Ww+WBnh8m2PAvoU5ZV+Zw5EK7LT6RnjINQGZpaDkjC2V064qqIY0uOR DuTxCw+Dz4E+PblPN32lOVoC0yUobNWzt8cPE/+ss3CnO4vk+qSuO5mpBVgIikZl VGiVpcdLQLcwCKuzXSWOssxjyUVeu1fKzIMmdtoQV8ZR6Sk0Ij5AtZV6jG5J6UFD wikTlOZ4M0AATS4dPKsG7HOk8cWktsclxByUtpS4oIvMKIM40ykP3Fml7urIkfSx E2ZNfJq2PtZJoF6ZinApqDBPEdZZgA== =gv9f -----END PGP SIGNATURE----- --Apple-Mail=_BAFC4832-FA0B-4D34-B8E6-1A019623C289-- From nobody Mon Nov 5 19:26:22 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDAE1276D0; Mon, 5 Nov 2018 19:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 4OkxnN_emu-L; Mon, 5 Nov 2018 19:26:10 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F23DF127148; Mon, 5 Nov 2018 19:26:09 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B32356E612B91; Tue, 6 Nov 2018 03:26:06 +0000 (GMT) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 6 Nov 2018 03:26:06 +0000 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.70]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 11:25:58 +0800 From: "Chengli (Cheng Li)" To: "Darren Dukes (ddukes)" CC: Joel Halpern , spring , 6man <6man@ietf.org>, Lizhenbin , Mach Chen Subject: RE: SRv6 - SRH in encaps or base header - point 2 Thread-Topic: SRv6 - SRH in encaps or base header - point 2 Thread-Index: AQHUcIcsTbFeHZpwLku+NvhkEcQp5qU4pNnQgAOq8QCABFXpAIAAj/cAgADqJXI= Date: Tue, 6 Nov 2018 03:25:58 +0000 Message-ID: References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> , <0CA05243-FAC4-4344-BCBE-9B0306A32486@cisco.com> In-Reply-To: <0CA05243-FAC4-4344-BCBE-9B0306A32486@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB01A5663Cdggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 03:26:15 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB01A5663Cdggeml529mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 T0ssIHRoYW5rcyBmb3IgeW91ciByZXBseS4gSXQgc29sdmVzIG15IHByb2JsZW1zLg0KDQpSZWdh cmRzLA0KQ2hlbmcNCg0KRnJvbTogRGFycmVuIER1a2VzIChkZHVrZXMpDQpUbzogQ2hlbmdsaSAo Q2hlbmcgTGkpPGNoZW5nbGkxM0BodWF3ZWkuY29tPG1haWx0bzpjaGVuZ2xpMTNAaHVhd2VpLmNv bT4+DQpDYzogSm9lbCBIYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+PjtzcHJpbmc8c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+Pjs2bWFuPDZtYW5AaWV0Zi5vcmc8bWFpbHRvOjZtYW5AaWV0Zi5vcmc+PjtMaXpoZW5iaW48 bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJpbkBodWF3ZWkuY29tPj47TWFjaCBD aGVuPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+DQpT dWJqZWN0OiBSZTogU1J2NiAtIFNSSCBpbiBlbmNhcHMgb3IgYmFzZSBoZWFkZXIgLSBwb2ludCAy DQpUaW1lOiAyMDE4LTExLTA2IDA0OjI4OjE4DQoNClllcywgU1JIIGluc2VydGlvbiBpcyBub3Qg ZGlzY3Vzc2VkIGluIHRoaXMgZHJhZnQgYW5kIG5vdCB3aXRoaW4gaXRzIHNjb3BlLg0KDQpEYXJy ZW4NCg0KPiBPbiBOb3YgNCwgMjAxOCwgYXQgMTE6NTUgUE0sIENoZW5nbGkgKENoZW5nIExpKSA8 Y2hlbmdsaTEzQGh1YXdlaS5jb20+IHdyb3RlOg0KPg0KPiBzbyBob3cgdG8gdXNlIFNSSCBpbnNl cnRpb24/IE91dCBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0Pw0KPg0KPiBDaGVuZw0KPg0KPg0KPiAt LS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBEYXJyZW4gRHVrZXMgKGRkdWtlcykgW21haWx0 bzpkZHVrZXNAY2lzY28uY29tXQ0KPiC3osvNyrG85DogMjAxOMTqMTHUwjPI1SAyOjQwDQo+IMrV vP7IyzogQ2hlbmdsaSAoQ2hlbmcgTGkpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT4NCj4gs63LzTog Sm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgc3ByaW5nQGlldGYub3JnOyA2bWFu QGlldGYub3JnOyBMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29tPjsgTWFjaCBDaGVuIDxt YWNoLmNoZW5AaHVhd2VpLmNvbT4NCj4g1vfM4jogUmU6IFNSdjYgLSBTUkggaW4gZW5jYXBzIG9y IGJhc2UgaGVhZGVyIC0gcG9pbnQgMg0KPg0KPiBIZWxsbyBDaGVuZywgdGhhbmtzIGZvciB0aGUg cmV2aWV3ISAgUGxlYXNlIHNlZSBpbmxpbmUNCj4NCj4+IE9uIE9jdCAzMCwgMjAxOCwgYXQgMTE6 NDEgUE0sIENoZW5nbGkgKElQIFRlY2hub2xvZ3kgUmVzZWFyY2gpIDxjaGVuZ2xpMTNAaHVhd2Vp LmNvbT4gd3JvdGU6DQo+Pg0KPj4gSGkgRGFycmVuLA0KPj4NCj4+IEkgdGhpbmsgdGhlIHRleHQg b2YgZW5jYXBzdWxhdGluZyBtb2RlIGlzIGNsZWFyIGZvciBtZS4gQnV0IEkgc3RpbGwgaGF2ZSBz b21lIHF1ZXN0aW9ucyBvZiB0aGUgaW5zZXJ0aW9uIG1vZGUgLg0KPj4NCj4+IDEuMSA6PGRkPiBO b2RlIDkgaGFzIGEgY2hvaWNlLCBlbmNhcHN1bGF0ZSB0byBub2RlIDMgb3Igbm90Lg0KPj4gSWYg bm9kZSA5IGRvZXMgbm90IGVuY2Fwc3VsYXRlLCBpdCB3aWxsIGluZm9ybSB0aGUgZGVzdGluYXRp b24gb2YgdGhlIHNlZ21lbnRzIGluIHRoZSBTUkggYW5kIHBvc3NpYmx5IGxlYWsgdGhlbSB0byBp bnRlcm1lZGlhdGUgbm9kZXMuDQo+Pg0KPj4gSWYgdGhlcmUgaXMgbm90IGluZGljYXRvciB0byBt YWtlIGEgY2hvaWNlIG9mIGVuY2Fwc3VsYXRpbmcgb3Igbm90LCBob3cgdGhlIG5vZGUgdG8gbWFr ZSB0aGUgY2hvaWNlPyBMb2NhbCBwb2xpY3k/DQo+PiBPciBtYWtlIGl0IHRoZSBzYW1lIGxpa2Ug dGhlIHJlY2VpdmVkIHBhY2tldD8gRW5jYXBzdWxhdGUgaWYgcmVjZWl2ZWQgcGFja2V0IGRvZXMs IGVsc2UsIGluc2VydD8NCj4NCj4gQSBob3N0IG5lZWRzIG1hbnkgdGhpbmdzIHRvIGRldGVybWlu ZSBob3cgdG8gYWRkIGFuIFNSSCB0byBhIHBhY2tldCBpdCBpcyBzZW5kaW5nIHRvIGEgZGVzdGlu YXRpb24sIGF0IGxlYXN0IGl0IG5lZWRzIHRvIGxlYXJuIFNJRHMgZm9yIG5vZGVzIGFuZCBoYXZl IHNvbWUgbG9naWMgaW4gcGxhY2UgdG8gZGV0ZXJtaW5lIGhvdyBhbmQgd2hlbiB0byB1c2UgYSBw YXJ0aWN1bGFyIHNlZ21lbnQgbGlzdKGtIFRoYXQgaXMgd2VsbCBiZXlvbmQgdGhpcyBkb2N1bWVu dCBhbmQgdGhlcmUgaXMgYW5kIHdpbGwgYmUgbW9yZSBpbm5vdmF0aXZlIHdheXMgb2YgZGV0ZXJt aW5pbmcgd2hlbiB0byBhZGQgYSBTUkggdG8gYSBwYWNrZXQgc291cmNlZCBieSBhIG5vZGUuDQo+ DQo+IFRoZXJlZm9yZSBJoa9sbCBzYXkgdGhpcyBxdWVzdGlvbiBpcyBub3Qgd2l0aGluIHNjb3Bl IGZvciB0aGlzIGRvY3VtZW50LCBpdCBuZWVkcyB0byBiZSBhbnN3ZXJlZCBmb3Igc3BlY2lmaWMg dXNlIGNhc2VzIGFuZCBhcHBsaWNhdGlvbnMgb2YgdGhlIFNSSC4NCj4NCj4gVGhhdCBzYWlkIHRo ZXJlIGlzIG9uZ29pbmcgd29yayB0byBkZWZpbmUgaG93IGEgbm9kZSBtYXkgbGVhcm4gYW4gU1Ig UG9saWN5Og0KPiBQQ0VQIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW5lZ2ktcGNlLXNl Z21lbnQtcm91dGluZy1pcHY2LTAzLnR4dCwNCj4gQkdQLVRFIGh0dHBzOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3ktMDQudHh0LA0KPiBv ciChsFNETqGxIG1ldGhvZHMgd2hlcmUgc29tZSBvdXRzaWRlIGNvbnRyb2xsZXIgc2V0cyB1cCBh IHNlZ21lbnQgbGlzdCB2aWEgc29tZSBSRVNULCBDTEksIG5ldGNvbmYveWFuZyBpbnRlcmZhY2Ug dG8gc2F0aXNmeSBzcGVjaWZpYyB1c2UgY2FzZXMuDQo+DQo+IEFuZCB3aGVuIHRvIHVzZSBpdDoN Cj4gQkdQIFNSdjYgc2VydmljZXMgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZGF3cmEt aWRyLXNydjYtdnBuLTA1LnR4dA0KPg0KPg0KPj4NCj4+IDEuMiA6IEhvdyB0byBpbmZvcm0gdGhl IGRlc3RpbmF0aW9uIG9mIHRoZSBzZWdtZW50cyBpbiB0aGUgU1JIPyAgQW55IGluZGljYXRvciBp biBTUkg/IE9yIHRocm91Z2ggc2lnbmFsaW5nPw0KPj4NCj4NCj4NCj4gU2FtZSBhbnN3ZXIgYXMg MS4xLg0KPg0KPj4gMjogQ2FuIGEgbm9ybWFsKG5vbi1TSUQpIElQdjYgYWRkcmVzcyBiZSBhZGRl ZCBpbnRvIFNJRCBsaXN0Pw0KPj4NCj4+IEkgcHJlZmVyIHllcy4NCj4+DQo+PiBBcyBzZWN0aW9u IDQuMyBzYXlzLCBpdCBzZWVtcyBsaWtlIHdlIGNhbiBkbyB0aGF0Lg0KPj4NCj4+ICAiV2hlbiBh biBTUnY2LWNhcGFibGUgbm9kZSByZWNlaXZlcyBhbiBJUHY2IHBhY2tldCwgaXQgcGVyZm9ybXMg YQ0KPj4gIGxvbmdlc3QtcHJlZml4LW1hdGNoIGxvb2t1cCBvbiB0aGUgcGFja2V0cyBkZXN0aW5h dGlvbiBhZGRyZXNzLiAgVGhpcw0KPj4gIGxvb2t1cCBjYW4gcmV0dXJuIGFueSBvZiB0aGUgZm9s bG93aW5nOg0KPj4NCj4+ICAgICAgQSBGSUIgZW50cnkgdGhhdCByZXByZXNlbnRzIGEgbG9jYWxs eSBpbnN0YW50aWF0ZWQgU1J2NiBTSUQNCj4+ICAgICAgQSBGSUIgZW50cnkgdGhhdCByZXByZXNl bnRzIGEgbG9jYWwgaW50ZXJmYWNlLCBub3QgbG9jYWxseQ0KPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBpbnN0YW50aWF0ZWQgYXMgYW4gU1J2NiBTSUQNCj4+ICAgICAgQSBG SUIgZW50cnkgdGhhdCByZXByZXNlbnRzIGEgbm9uLWxvY2FsIHJvdXRlDQo+PiAgICAgIE5vIE1h dGNoDQo+PiAgICAgIg0KPj4gQWxzbywgaW4gc2VjdGlvbiA1LCB3ZSBjYW4gc2VlIEE5IGNhbiBi ZSBhZGRlZCBpbiBTSUQgbGlzdCBvZiBhIFNSIHBvbGljeS4NCj4+DQo+PiBTbyBmb3IgdGhlIHBh Y2tldCBmcm9tIEE5IHRvIEExLCB0aGUgYWRkcmVzcyBvZiBBMSBjYW4gYmUgYWRkZWQgYXMgdGhl IGxhc3QgZW50cnkgb2YgU0lEIGxpc3QsIHJpZ2h0Pw0KPj4NCj4+IElmIHllcywgYWRkcmVzcyBv ZiBBMSBpcyBub3QgYW4gaW5zdGFudGlhdGVkIFNJRCwgc28gbm90IFBTUCBmbGF2b3IgY2FuIGJl IGVuYWJsZWQuIFNvIHRoZSBwYWNrZXQgd2lsbCBiZSBzZW50IG91dCBieSBjYXJyeWluZyB0aGUg U1JIIGFmdGVyIEExIGlzIHVwZGF0ZWQgdG8gdGhlIElQdjYgREEuDQo+PiBTUkggd2lsbCBiZSBs ZWFrZWQgdG8gb3V0c2lkZSBvZiB0aGUgU1IgZG9tYWluLCB3aGljaCB3aWxsIGJyaW5nIG5ldyBz ZWN1cml0eSBpc3N1ZXMuDQo+Pg0KPg0KPiBZZXMgYXMgdGhlIGxhc3Qgc2VnbWVudCBpbiBhIHNl Z21lbnQgbGlzdCwgYW5kIGFzIFJGQzgyMDAgc2VjdGlvbiA0LjQgZGVzY3JpYmVzIFJvdXRpbmcg SGVhZGVyIHByb2Nlc3Npbmcgd2hlbiBzZWdtZW50cyBsZWZ0IGlzIDAuDQo+DQo+IEl0IGlzIHVw IHRvIHRoZSBzcGVjaWZpYyB1c2UgY2FzZSB0byBkZXRlcm1pbmUgaWYgaW5mb3JtaW5nIHRoZSBk ZXN0aW5hdGlvbiBvciBpbnRlcm1lZGlhdGUgbm9kZXMgb2YgdGhlIHNlZ21lbnQgbGlzdCB1c2Vk IHRvIHJlYWNoIGl0IGlzIGEgc2VjdXJpdHkgcmlzay4NCj4NCj4gQ2VydGFpbmx5IG9uIHRoZSBs YXJnZXIgaW50ZXJuZXQgdGhpcyBpcyBhbiBpc3N1ZSB0aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVy ZWQsIGJ1dCB3aXRoaW4gYW4gZW50ZXJwcmlzZSBuZXR3b3JrIG9yIHdpdGhpbiBhIHNpbmdsZSBw cm92aWRlcnMgbmV0d29yayBjcm9zc2luZyBtdWx0aXBsZSBkb21haW5zLCBvciBldmVuIGJldHdl ZW4gcHJvdmlkZXJzIHRoZSBkaXNjbG9zdXJlIG1heSBiZSBhY2NlcHRhYmxlIG9yIGRlc2lyZWQu DQo+DQo+Pg0KPj4gMzogRm9yIHNlY3Rpb24gNi4yLA0KPj4gIE5vZGVzIG91dHNpZGUgdGhlIFNS IERvbWFpbiBjYW5ub3QgYmUgdHJ1c3RlZC4gIFNSIERvbWFpbiBJbmdyZXNzDQo+PiAgcm91dGVy cyBTSE9VTEQgZGlzY2FyZCBwYWNrZXRzIGRlc3RpbmVkIHRvIFNJRHMgd2l0aGluIHRoZSBTUiBE b21haW4NCj4+ICAocmVnYXJkbGVzcyBvZiB0aGUgcHJlc2VuY2Ugb2YgYW4gU1JIKSB0byBhdm9p ZCBhdHRhY2tzIG9uIHRoZSBTUg0KPj4gIERvbWFpbiBhcyBkZXNjcmliZWQgYW5kIHJlZmVyZW5j ZWQgaW4gW1JGQzUwOTVdLg0KPj4NCj4+ICBBcyBhbiBhZGRpdGlvbmFsDQo+PiAgbGF5ZXIgb2Yg cHJvdGVjdGlvbiwgU1IgU2VnbWVudCBFbmRwb2ludCBub2RlcyBTSE9VTEQgZGlzY2FyZCBwYWNr ZXRzDQo+PiAgZGVzdGluZWQgdG8gbG9jYWwgU0lEcyBmcm9tIHNvdXJjZSBhZGRyZXNzZXMgbm90 IHBhcnQgb2YgdGhlIFNSDQo+PiAgRG9tYWluLg0KPj4NCj4+IEZvciBhIHBhY2tldCBmcm9tIEEx IHRvIEE5LCAgdGhlIHBhY2tldCBpcyAoQTEsIEE5KS4gTm9kZTMgd2lsbCBub3QgZHJvcCB0aGUg cGFja2V0IHNpbmNlIHRoZSBkZXN0aW5hdGlvbiBpcyBBOSBub3QgUzkuDQo+Pg0KPj4gSWYgbm9k ZSAzIGluc2VydCBhIFNSSCBpbiB0aGUgb3JpZ2luYWwgSVB2NiBwYWNrZXQsIHRoZW4gdGhlIHNv dXJjZSBBZGRyZXNzIHdpbGwgYmUgQTEuIEFuZCB0aGUgU0lEIGxpc3QgY2FuIGJlICA8QTksIFM2 ID4uDQo+PiBJbiB0aGlzIGNhc2UsIHRoZSBwYWNrZXQgd2lsbCBiZSBkcm9wcGVkIGJ5IG5vZGUg Niwgc2luY2UgdGhlIHNvdXJjZSBhZGRyZXNzIGlzIG5vdCBwYXJ0IG9mIHRoZSBTUiBkb21haW4u ICBbU2VjdGlvbiA2LjJdLCByaWdodD8NCj4+DQo+PiBJTUhPLCB0aGVyZSBhcmUgc29tZSBwcm9i bGVtcyBhYm91dCBpbnNlcnRpb24gbW9kZS4NCj4NCj4gSW4gdGhlIGNvbnRleHQgb2YgdGhlIFNS SCBkcmFmdCB3ZSBkbyBub3QgbWFrZSBhbnkgbWVudGlvbiBvciB1c2Ugb2YgU1JIIGluc2VydGlv bi4gSS5lLiBub2RlIDMgZG9lcyBub3QgaW5zZXJ0IGFuIFNSSCwgaXQgZW5jYXBzdWxhdGVzIGlu IGFuIG91dGVyIElQdjYgaGVhZGVyLg0KPg0KPiBEYXJyZW4NCj4NCj4+DQo+PiBUaGFua3MsDQo+ PiBDaGVuZw0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXJy ZW4gRHVrZXMNCj4+IChkZHVrZXMpDQo+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMzEsIDIw MTggMzozMSBBTQ0KPj4gVG86IEpvZWwgSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+ IENjOiBzcHJpbmdAaWV0Zi5vcmc7IDZtYW5AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBTUnY2 IC0gU1JIIGluIGVuY2FwcyBvciBiYXNlIGhlYWRlciAtIHBvaW50IDINCj4+DQo+PiBJIHRoaW5r IHdloa9yZSBhbG1vc3QgY29uY2x1ZGVkIHNvIG9uY2UgbW9yZSBpbmxpbmUgYXQgPGRkPjwvZGQ+ DQo+Pg0KPj4+IE9uIE9jdCAyNiwgMjAxOCwgYXQgMjoyOCBQTSwgSm9lbCBIYWxwZXJuIDxqbWhA am9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4+Pg0KPj4+IChyZXNlbmRpbmcsICtzcHJpbmcgYXMg cmVxdWVzdGVkKQ0KPj4+DQo+Pj4gVGhhbmsgeW91IGZvciB0aGUgcmVzcG9uc2VzLiAgSSB3aWxs IHJlc3BvbmQgaW4gbGluZSwgbWFya2VkIDxqbWg+PC9qbWg+LiAgSSBmZWFyIGl0IHdpbGwgc2hv cnRseSBnZXQgdG9vIGRlZXAsIGJ1dCB0aGUgY29udGV4dCBpcyBpbXBvcnRhbnQuDQo+Pj4NCj4+ PiBJIHdpbGwgcmVwaHJhc2UgaGVyZSBhbiBpc3N1ZSBmcm9tIGFub3RoZXIgdGhyZWFkIHRoYXQg SSBhaHZlIG5vdCBzZWVuIHlvdXIgY29tbWVudHMgb24uICBJZiBOb2RlIDkgaXMgc2VuZGluZyB0 cmFmZmljIHRvIE5vZGUgMSAoZm9yIGV4YW1wbGUsIHRoZSByZXZlcnNlIHRyYWZmaWMgZm9yIHRo ZSB0cmFmZmljIGZyb20gMSB0byA5IGluIHRoZSBleGFtcGxlcyBiZWxvdyksIGl0IHByZXN1bWFi bHkgaGFzIGFuIFNSIFBvbGljeSB0byBiZSBhcHBsaWVkLiBUaGUgaXNzdWUgSSByYWlzZWQgYmVm b3JlIGlzIHRoZSBsZWFrYWdlIGlzc3VlLiAgSWYgOSBwdXRzIHRoZSBTUkggaW4gaXRzIHBhY2tl dCAoYXMgdGhlIGRvY3VtZW50IGN1cnJlbnRseSBtYW5kYXRlcyksIHRoZW4gaXQgd2lsbCBub3Qg YmUgcG9zc2libGUgZm9yIDMgdG8gcmVtb3ZlIHRoZSBTUkguICBUaHVzLCB0aGUgU1JIIHdpbGwg bGVhay4NCj4+Pg0KPj4+IFNvbWUgaGF2ZSBhcmd1ZWQgdGhhdCBpcyBub3QgYSBiaWcgZGVhbC4g IEl0IHNlZW1zIHRvIG1hdHRlciB0byBtZS4gIEJ1dCB0aGVyZSBpcyBhbiBhZGRpdGlvbmFsIHBy b2JsZW0uICBBMSBpcyBub3QgYSBTSUQuICBUaGVyZWZvcmUsIDkgY2FuIG5vdCBwdXQgQTEgaW50 byB0aGUgU1JILiAgSWYgaXQgY2FuIG5vdCBwdXQgQTEgaW50byB0aGUgU1JILCBhbmQgaXQgZG9l cyBub3QgZW5jYXBzdWxhdGUgdGhlIHBhY2tldCwgd2hlcmUgZG9lcyBpdCBwdXQgQTEuDQo+Pg0K Pj4gPGRkPiBOb2RlIDkgaGFzIGEgY2hvaWNlLCBlbmNhcHN1bGF0ZSB0byBub2RlIDMgb3Igbm90 Lg0KPj4gSWYgbm9kZSA5IGRvZXMgbm90IGVuY2Fwc3VsYXRlLCBpdCB3aWxsIGluZm9ybSB0aGUg ZGVzdGluYXRpb24gb2YgdGhlIHNlZ21lbnRzIGluIHRoZSBTUkggYW5kIHBvc3NpYmx5IGxlYWsg dGhlbSB0byBpbnRlcm1lZGlhdGUgbm9kZXMuDQo+PiBJZiBub2RlIDkgZG9lcyBlbmNhcHN1bGF0 ZSwgbm9kZSAzIHJlbW92ZXMgdGhlIG91dGVyIGhlYWRlciBhbmQgbm9kZSAxIHdvdWxkIG5vdCBs ZWFybiB0aGUgc2VnbWVudCBsaXN0Lg0KPj4gSSB0aGluayBpdHMgY2hvaWNlIHNob3VsZCBub3Qg YmUgbWFuZGF0ZWQgaW4gdGhlIGRyYWZ0LiA8L2RkPg0KPj4NCj4+Pg0KPj4+IFlvdXJzLA0KPj4+ IEpvZWwNCj4+Pg0KPj4+IE9uIDEwLzI2LzE4IDE6MjkgUE0sIERhcnJlbiBEdWtlcyAoZGR1a2Vz KSB3cm90ZToNCj4+Pj4gSGkgSm9lbCwgeW91oa92ZSBkZXNjcmliZWQgc2VjdGlvbnMgdGl0bGVk IKGwSW50cmEgU1IgRG9tYWluIFBhY2tldKGxLCChsFRyYW5zaXQgUGFja2V0IFRocm91Z2ggU1Ig RG9tYWluobEsIGFuZCAiU1IgU291cmNlIE5vZGVzIE5vdCBEaXJlY3RseSBDb25uZWN0ZWShsS4N Cj4+Pj4gSaGvdmUgcGFyc2VkIHRoZW0gaW5saW5lIHRvIHRoZSBzZWN0aW9ucyBvZiB0aGUgZHJh ZnQgZGVmaW5pbmcgdGhlbSBhbmQgZ2l2ZW4gbW9yZSBjb250ZXh0IHdoZXJlIG5lZWRlZC4NCj4+ Pj4+IE9uIE9jdCAyMiwgMjAxOCwgYXQgODo0OSBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9l bGhhbHBlcm4uY29tPiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBSZXBocmFzaW5nIHVzaW5nIHRoZSBl eGFtcGxlIGZyb20gNS4yLiAgQXNzdW1pbmcgdGhhdCA4IGFuZCA5IGFyZQ0KPj4+Pj4gU1IgSG9z dHMgKG5vdCBqdXN0IGhvc3RzIHdpdGhpbiB0aGUgZG9tYWluLCB0aGV5IGFyZSBjYXBhYmxlIG9m IGFuZA0KPj4+Pj4gZXhwZWN0IHRvIGRlYWwgd2l0aCBTUkhzLCBhbmQgdGhlcmVmb3JlIGhhdmUg bG9jYWwgU0lEcywgLi4uKQ0KPj4+Pj4NCj4+Pj4+IEZvciB0cmFmZmljIGZyb20gOCB0byA5IHRo YXQgbmVlZHMgYW4gU1JILCB0aGUgU1JIIGdvZXMgaW4gdGhlIElQdjYgaGVhZGVyIHNlbnQgbXkg OCB0byA5LiAgV2hlbiA5IHByb2Nlc3NlcyB0aGUgcGFja2V0LCBpdCBzZWVtcyB0aGF0IGl0IGlz IHRoZSBsYXN0IFNJRCwgZmlndXJlcyBvdXQgdGhhdCB0aGVyZSBpcyBubyBlbmNhcHN1bGF0aW9u LCBhbmQgc2VuZCB0aGUgVENQIC8gVURQIC8gUVVJQyBpbmZvcm1hdGlvbiB0byBpdHMgaW50ZXJu YWwgcHJvdG9jb2xzIHN0YWNrcy4NCj4+Pj4gWWVzLCB0aGlzIGlzIFNlY3Rpb24gNS4zLjEgobBJ bnRyYSBTUiBEb21haW4gUGFja2V0obEuDQo+Pj4gPGptaD5BZ3JlZWQgYXMgZmFyIGFzIGl0IGdv ZXMuICBIb3dldmVyLCAgdGhlIGV4aXN0ZW5jZSBvZiBTOSBhbmQgQTkNCj4+PiBwb2ludHMgdG8g YSBwcm9ibGVtLiAgTm9kZSA4IGlzIHRyeWluZyB0byBwdXQgb24gYW4gU1JIIGdvaW5nIHRocm91 Z2gNCj4+PiBTeCwgU3ksIHdoYXRldmVyIGZvciBzb21lIHJlYXNvbi4gIEl0IGNhbid0IHB1dCBB OSBpbnRvIHRoZSBTUkgsIGFzDQo+Pj4gQUggaXMgbm90IGEgU0lELCBpdCBpcyBhbiBhZGRyZXNz LiAgSSBwcmVzdW1lIG5vZGUgOCBnb3QgUzkgZnJvbQ0KPj4+IHdoYXRldmVyIHByb3ZpZGVkIGhp bSB0aGUgU1IgUG9saWN5IHRoYXQgaXQgaXMgdXNpbmcuICBEb2VzIGl0IHNpbXBseQ0KPj4+IHVz ZSBTOSBhcyB0aGUgYWRkcmVzcyBmb3Igbm9kZSA5LCByYXRoZXIgdGhhbiBBOSB0aGF0IGl0IGdv dCBmcm9tDQo+Pj4gRE5TPyAgQW5kIGRvZXMgdGhlIFRDUCBzdGFjayBrbm93IHRoYXQgdGhpcyBz dWJzdGl0dXRpb24gaXMgYmVpbmcNCj4+PiBtYWRlPyAgKFRoaXMgaXMgYW5vdGhlciBleGFtcGxl IG9mIGEgcHJvYmxlbSB0aGF0IGdvZXMgYXdheSBpZiB3ZQ0KPj4+IGFsd2F5cyBlbmNhcHN1bGF0 ZS4pIDwvam1oPg0KPj4NCj4+IDxkZD5TZWN0aW9uIDQuMy4yIGNvdmVycyB0aGVzZSBxdWVzdGlv bnMsIGkuZS4gQTkgY2FuIGJlIHBsYWNlZCBpbiB0aGUNCj4+IFNSSCBhcyB0aGUgbGFzdCBzZWdt ZW50LCBhbmQgdGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBob3cgaXShr3MNCj4+IGhhbmRsZWQuPC9k ZD4NCj4+DQo+Pj4NCj4+Pj4+DQo+Pj4+PiBGb3IgdHJhZmZpYyBmcm9tIDEgdG8gOSwgd2hlcmUg MyBhZGRzIGFuIFNSSCwgdGhhdCBTUkggc3RpbGwgcHJlc3VtYWJseSBlbmRzIGF0IDkuICA5IFJl Y2VpdmVzIHRoZSBJUCBwYWNrZXQuICBTZWVzIHRoYXQgaXQgaXMgYWRkcmVzc2VkIHRvIGl0c2Vs Zi4gIFNlZXMgdGhhdCB0aGUgU1JIIGlzIGZpbmlzaGVkLiAgQW5kIHRoZW4gbm90aWNlcyB0aGF0 IHRoZSBuZXh0LWhlYWRlciBpcyBJUHY2LiAgVW53cmFwcyB0aGUgaGVhZGVyLCBjaGVja3MgdGhh dCB0aGUgaW5uZXIgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhbHNvIGl0c2VsZiwgYW5kIHBhc3Nl cyB0aGUgbWF0ZXJpYWwgY2FycmllZCBieSB0aGUgaW5uZXIgaGVhZGVyIHVwIHRvIHRoZSBhcHBy b3ByaWF0ZSBzdGFjay4NCj4+Pj4gU28gbm9kZSAxIHNlbmRzIGEgcGFja2V0IHRvIG5vZGUgOSAo QTEsQTkpIElGIHRoZXJlIGlzIHNvbWUgc3RlZXJpbmcNCj4+Pj4gaW50byBhbiBTUiBQb2xpY3kg YXQgbm9kZSAzIHRvIHJlYWNoIG5vZGUgOSwgdGhpcyBpcyBpZGVudGljYWwgdG8gc2VjdGlvbiA1 LjMuMiChsFRyYW5zaXQgcGFja2V0IHRocm91Z2ggU1IgZG9tYWluobEsIGV4Y2VwdCBmb3IgZGVz dGluYXRpb24gb2YgQTkgdmlhIG5vZGUgOSAgaW5zdGVhZCBvZiBBMiB2aWEgbm9kZSA0Lg0KPj4+ DQo+Pj4+Pg0KPj4+Pj4gVGh1cywgOSBuZWVkcyB0byBiZSBhYmxlIHRvIGNoZWNrIGZvciBib3Ro IGNhc2VzLiAgV2UgYXQgbGVhc3QgbmVlZCB0byB0ZWxsIGltcGxlbWVudG9ycyB0aGF0Lg0KPj4+ PiBXZWxsLCA5IG5lZWRzIGEgU0lEIFM5IGFuZCBBZGRyZXNzIEE5LiAgVGhhdCBpcyBzaG93biBp biBTZWN0aW9uIDUuMSBTSUQgYW5kIGFkZHJlc3MgcmVwcmVzZW50YXRpb24uDQo+Pj4gPGptaD5T bywgbGV0IHVzIGFzc3VtZSB0aGF0IDMgaGFzIGFuIFNSIHBvbGljeSBpdCB3YW50cyB0byBhcHBs eSB0bw0KPj4+IHRoZSB0cmFmZmljIGZyb20gQTEgdG8gQTkuICBJbiB0aGlzIGNhc2UsIHRoZSBT OSAvIEE5IGRpY2hvdG9teSBpcw0KPj4+IG5vdCBhIHByb2JsZW0sIEkgdGhpbmsuICBOb2RlIDMg ZW5jYXBzdWFsdGVzIHRoZSBwYWNrZXQgZnJvbSBBMSB0bw0KPj4+IEE5LCB1c2VzIFMzIGFzIHRo ZSBzb3VyY2UgYWRkcmVzcyBvZiB0aGUgZW5jYXBzdWxhdGluZyBoZWFkZXIsIGFuZA0KPj4+IGVu ZHMgdGhlIFNJRCBsaXN0IGluIHRoZSBTUkggd2l0aCBTOS4gIFRoZSB1bnNwZWNpZmllZCBwYXJ0 IGlzIHRoYXQNCj4+PiBub2RlIDkgbmVlZHMgdG8gYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBzdWNo IHBhY2tldHMgYW5kIGRvIHRoZSBkb3VibGUNCj4+PiBwcm9jZXNzaW5nLiAgSXQgaXMgcmVhc29u YWJsZSBkb3VibGUgcHJvY2Vzc2luZy4gIE15IG9ubHkgcmVxdWVzdA0KPj4+IGhlcmUgaXMgdGhh dCB3ZSB0ZWxsIGZvbGtzIHRoZXkgbmVlZCB0byBzdXBwb3J0IGl0LiA8L2ptaD4NCj4+DQo+PiA8 ZGQ+QWN0dWFsbHksIG5vZGUgMyB1c2VzIEEzIGFzIGl0cyBzb3VyY2UgYWRkcmVzcywgYnV0IHRo YXShr3MgbWlub3IuDQo+PiBUaGUgZG91YmxlIHByb2Nlc3NpbmcgKGxvb2t1cCwgZG8gZW5kIHBy b2Nlc3NpbmcsIGRvIGFub3RoZXIgbG9va3VwKSBpcyBkb2N1bWVudGVkIGluIFNlY3Rpb24gNC4z Lg0KPj4gSXMgdGhlcmUgYSBuZWVkIGZvciBtb3JlIHRoYW4gd2hhdCBpcyBjdXJyZW50bHkgc3Bl Y2lmaWVkPyA8L2RkPg0KPj4NCj4+Pj4+DQo+Pj4+PiBUaGVyZSBpcyBhIGZ1cnRoZXIgY29tcGxp Y2F0aW9uLiAgOSBzZWVtcyB0byBuZWVkIHRvIGhhdmUgYW4gYWRkcmVzcyB0aGF0IGlzIGEgdmFs aWQgU0lELCBzbyBpdCBjYW4gYmUgdGhlIGxhc3QgZW50cnkgaW4gdGhlIFNSSCBmcm9tIDggdG8g OS4NCj4+Pj4gQXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCwgU2VjdGlvbiA1LjEgYSBub2RlIGsg aGFzIGFuIGFkZHJlc3MgQWsgYW5kIFNJRCBTay4gIFNvIG5vZGUgOSBoYXMgYSB2YWxpZCBTSUQu DQo+Pj4+IEZvciB0cmFmZmljIGZyb20gOCB0byA5LCBBOSBpcyB1c2VkIGFzIHRoZSBkZXN0aW5h dGlvbiBhcyBzaG93biBpbiBzZWN0aW9uIDUuMy4xLCA1LjQgYW5kIDUuNS4NCj4+Pj4+IEhvd2V2 ZXIsIGlmIDEgd2VyZSB0byBzZW5kIHRoZSBwYWNrZXQgdG8gdGhhdCBTSUQgZm9yIDksIHJvdXRl ciAzIHdvdWxkIGJlIHJlcXVpcmVkIGJ5IHRoZSBydWxlcyB3ZSBkaXNjdXNzZWQgaW4gdGhlIG90 aGVyIHRocmVhZCB0byBkaXNjYXJkIHRoZSBwYWNrZXQgYXMgaXQgaXMgbmVpdGhlciB0byBwcmVm aXggbm9yIGNvbnRhaW5zIGFuIEhBTUMuDQo+Pj4+PiBBbmQgc29tZWhvdywgOCBhbmQgMSBuZWVk IHRvIGVhY2ggcGljayB0aGUgcmlnaHQgYWRkcmVzcyB0byB1c2UgZm9yIDkuIChzcGxpdCBETlMg bWF5YmU/KSAgQW5kIDMgbmVlZHMgdG8gYmUgYWJsZSB0byBkZXJpdmUgdGVoIFNJRC1mb3JtbiBh ZGRyZXNzIGZvciA5IGZyb20gdGhlIG5vbi1TSUQgZm9ybSBvZiB0aGUgYWRkcmVzcyBzbyB0aGF0 IGl0ICgzKSBjYW4gYnVpbGQgYSBwcm9wZXIgU1JIIHRvIGdldCB0aGUgcGFja2V0IHRvIDkuDQo+ Pj4gPGptaD5JIGhhdmUgcmV0YWluZWQgeW91ciBhbnN3ZXIgYmVsb3cgZm9yIGNvbnRleHQsIGJ1 dCBJIHRoaW5rIHRoYXQNCj4+PiBhbnN3ZXJzIHRoZSB3cm9uZyBxdWVzdGlvbi4gIEkgYmVsaWV2 ZSB3aGF0IGlzIGl0bmVuZGVkIGlzIHRoYXQgb25seQ0KPj4+IEE5IGFwcGVhcnMgaW4gRE5TLiAg U28gTm9kZSAxIHdpbGwgc2VlIDkgYXMgQTksIGFuZCB3aWxsIHVzZSB0aGF0Lg0KPj4+IFM5IHdp bGwgYXBwZWFyIGluIFNSIFBvbGljaWVzIGFib3V0IHRyYWZmaWMgdG8gbm9kZSA5LCBidXQgbm90 IGluIEROUy4NCj4+PiBUaGF0IGlzIHdoYXQgd2UgbmVlZC4gIEkgd2lzaCBpdCB3ZXJlIGNsZWFy ZXIgaW4gdGhlIHRleHQuIDwvam1oPg0KPj4+DQo+Pj4gPGptaD5JZiBub2RlIDIwIGlzIGdlbmVy YXRpbmcgU1JIcyB3aXRoIEhNQUNzLCB0aGVuIHRoaXMgaXMgbGFyZ2VseQ0KPj4+IHRoZSBzYW1l IGFzIHRoZSBjYXNlIGZyb20gOCB0byA5LCBleGNlcHQgdGhhdCB3aG9tZXZlciBjcmVhdGVzIHRo ZSBTUg0KPj4+IFBvbGljeSB0aGF0IDIwIGlzIHVzaW5nIG5lZWRzIHRvIGFsc28gbWFrZSBzdXJl IHRoYXQgd2hhdGV2ZXIgdGhlDQo+Pj4gZmlyc3QgU0lEIGlzIGluIHRlaCBsaXN0LCBpdCBwcm9j ZXNzZXMgSE1BQ3MgYW5kIGlzIHJlY29nbml6YWJsZSB0bw0KPj4+IG5vZGUgMyBhcyBkb2luZyBz dWNoIHByb2Nlc3NpbmcuIEkgYW0gZ3Vlc3NpbmcgdGhhdCB0aGUgcmVhc29uIGZvcg0KPj4+IGFs bG93aW5nIGludGVybmFsIG5vZGVzIHRvIGRvIHRoZSBwcm9jZXNzaW5nIGlzIHRvIG1vdmUgdGhl DQo+Pj4gdmVyaWZpY2F0aW9uIGxvYWQgb2ZmIHRoZSBlZGdlIG5vZGVzLiAgSXQgZG9lcyBjcmVh dGUgc2lnbmlmaWNhbnQNCj4+PiBhZGRpdGlvbmFsIGNvbmZpZ3VyYXRpb24gY29tcGxleGl0eS4g PC9qbWg+DQo+Pg0KPj4gPGRkPldlIGRpZG6hr3Qgc2VlIGEgcmVhc29uIHRvIHJlc3RyaWN0IHRo ZSBITUFDIHByb2Nlc3NpbmcgdG8gb25seQ0KPj4gZWRnZSBub2RlcyB3aGVuIGl0IHdhcyBzdHJh aWdodCBmb3J3YXJkIHRvIGRlZmluZSBob3cgdGhleSBjb3VsZCBiZQ0KPj4gcHJvY2Vzc2VkIGF0 IG5vbi1lZGdlIG5vZGVzLjwvZGQ+DQo+Pg0KPj4+DQo+Pj4+IFRoaXMgaXMgaW5jb3JyZWN0Lg0K Pj4+PiBTZWUgU2VjdGlvbiA2LjIuMSChsFNSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0bHkgQ29u bmVjdGVkobEgSSB3aWxsIGV4cGFuZCBvbiB0aGUgZXhhbXBsZSBmcm9tIHRoYXQgc2VjdGlvbi4N Cj4+Pj4gTm9kZSAyMCBzZW5kcyBhIHBhY2tldCB0byBBOSB3aXRoIFNSIFBvbGljeSA8SDc+IGFu ZCBhbiBITUFDDQo+Pj4+IHByb3ZpZGVkIHRvIG5vZGUgMjAgYnkgc29tZSB5ZXQgdG8gYmUgZGVm aW5lZCBtZXRob2QuICBSZXN1bHRpbmcgaW4NCj4+Pj4gcGFja2V0IHNlbnQgZnJvbSBub2RlIDIw DQo+Pj4+IFA6IChBMjAsSDcpKEE5O1NMPTEpKHBheWxvYWQpDQo+Pj4+IFJlY2FsbCBIayBpcyBh IFNJRCBhdCBub2RlIGsgcmVxdWlyaW5nIEhNQUMgdmVyaWZpY2F0aW9uLCBhbmQgaXQgaXMgY292 ZXJlZCBieSBQcmVmaXgtSC4NCj4+Pj4gUHJlZml4LUggaXMgX25vdF8gc3ViamVjdCB0byBpbmdy ZXNzIGZpbHRlcmluZyBhdCBub2RlIDMuDQo+Pj4+IFRoZXJlZm9yZSB0aGUgcGFja2V0IFAgZGVz dGluZWQgdG8gSDcgaXMgbm90IHN1YmplY3QgdG8gaW5ncmVzcyBmaWx0ZXJpbmcgYXQgbm9kZSAz Lg0KPj4+PiBQIGlzIGZvcndhcmRlZCB0byBub2RlIDcsIHdoZXJlIEg3IGlzIHByb2Nlc3NlZCBh bmQgdGhlIEhNQUMgdmVyaWZpZWQuDQo+Pj4+IElmIHRoZSBITUFDIGNhbiBub3QgYmUgdmVyaWZp ZWQgdGhlIHBhY2tldCBpcyBkcm9wcGVkLCBlbHNlIGl0IGlzIGZvcndhcmRlZCB0byB0aGUgbmV4 dCBzZWdtZW50IGFuZCBkZXN0aW5hdGlvbiwgQTkuDQo+Pj4+IERhcnJlbg0KPj4+Pj4NCj4+Pj4+ IFlvdXJzLA0KPj4+Pj4gSm9lbA0KPj4+Pj4NCj4+Pj4+IE9uIDEwLzIyLzE4IDg6MDQgUE0sIERh cnJlbiBEdWtlcyAoZGR1a2VzKSB3cm90ZToNCj4+Pj4+PiBpbmxpbmUuDQo+Pj4+Pj4+IE9uIE9j dCAyMiwgMjAxOCwgYXQgNzoyMSBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4u Y29tPiB3cm90ZToNCj4+Pj4+IC4uDQo+Pj4+Pj4+IDIpIE5vdyBsZXQgdXMgbG9vayBhdCBwYWNr ZXRzIGFycml2aW5nIGF0IGFuZCBhY3R1YWxseSBkZXN0aW5lZCBmb3IgYW4gU1IgSG9zdCBpbiB0 aGUgU1IgRG9tYWluIHdoZXJlIHRoYXQgcGFja2V0IGhhcyBhbiBTUkguICBJZiB0aGUgcGFja2V0 IGlzIGNvbWluZyBmcm9tIGFub3RoZXIgU1IgSG9zdCwgdGhlIFNSSCB3aWxsIGJlIGluIHRoZSBi YXNlIGhlYWRlciwgYW5kIHRoZSBob3N0IGNhbiBzaW1wbHkgY2hlY2sgaXQgZm9yIGFueSB2aW9s YXRpb25zLCBhbmQgY29udGludWUuICBCdXQsIGlmIHRoZSBwYWNrZXQgY2FtZSBmcm9tIG91dHNp ZGUgdGhlIGRvbWFpbiwgdGhlbiBpdCB3aWxsIGhhdmUgYW4gZW5jYXBzdWxhdGluZyBTUnY2IGhl YWRlci4gIFNvIHRoZSBob3N0IGhhcyB0byBkZXRlY3QgdGhpcyBjYXNlLCBjaGVjayBhbmQgdGhl biBwZWFsIG9mZiB0aGUgZW5jYXBzdWxhdGluZyBoZWFkZXIsIGFuZCB0aGVuIHByb2Nlc3MgdGhl IHJlY2VpdmVkIHBhY2tldC4gWWVzLCBpdCBjYW4gZG8gc28uICBCdXQgbm90aGluZyBpbiB0ZWgg ZG9jdW1lbnQgdGVsbHMgaW1wbGVtZW50b3JzIHRoZXkgaGF2ZSB0byBkZWFsIHdpdGggYm90aCBj YXNlcy4NCj4+Pj4+Pj4NCj4+Pj4+PiBDYW4geW91IGJlIG1vcmUgcHJlY2lzZSBoZXJlLiAgUGVy aGFwcyB1c2UgdGhlIGV4YW1wbGUgZnJvbSBzZWN0aW9uIDUuMiBvciA2LjIuMT8NCj4+Pj4+IC4u DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdA0KPj4gaXB2NkBpZXRmLm9yZw0KPj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4N Cg0K --_000_C7C2E1C43D652C4E9E49FE7517C236CB01A5663Cdggeml529mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
OK, thanks for your = reply. It solves my problems.

Regards,
Cheng

From: Darren Dukes (ddukes)
To: Chengli (Cheng Li)<chengli13@huawei.com>
Subject: Re: SRv6 - SRH in encaps or base header - point 2
Time: 2018-11-06 04:28:18

Yes, SRH insertion is not discussed in this draft = and not within its scope.

Darren

> On Nov 4, 2018, at 11:55 PM, Chengli (Cheng Li) <chengli13@huawei.c= om> wrote:
>
> so how to use SRH insertion? Out of scope of this draft?
>
> Cheng
>
>
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Darren Dukes (ddukes) [mailto:ddukes@cisco.com]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA11=D4=C23=C8=D5 2:40
> =CA=D5=BC=FE=C8=CB: Chengli (Cheng Li) <chengli13@huawei.com> > =B3=AD=CB=CD: Joel Halpern <jmh@joelhalpern.com>; spring@ietf.or= g; 6man@ietf.org; Lizhenbin <lizhenbin@huawei.com>; Mach Chen <mac= h.chen@huawei.com>
> =D6=F7=CC=E2: Re: SRv6 - SRH in encaps or base header - point 2
>
> Hello Cheng, thanks for the review!  Please see inline
>
>> On Oct 30, 2018, at 11:41 PM, Chengli (IP Technology Research) <= ;chengli13@huawei.com> wrote:
>>
>> Hi Darren,
>>
>> I think the text of encapsulating mode is clear for me. But I stil= l have some questions of the insertion mode .
>>
>> 1.1 :<dd> Node 9 has a choice, encapsulate to node 3 or not.=
>> If node 9 does not encapsulate, it will inform the destination of = the segments in the SRH and possibly leak them to intermediate nodes.
>>
>> If there is not indicator to make a choice of encapsulating or not= , how the node to make the choice? Local policy? 
>> Or make it the same like the received packet? Encapsulate if recei= ved packet does, else, insert?
>
> A host needs many things to determine how to add an SRH to a packet it= is sending to a destination, at least it needs to learn SIDs for nodes and= have some logic in place to determine how and when to use a particular seg= ment list=A1=AD That is well beyond this document and there is and will be more innovative ways of determining when= to add a SRH to a packet sourced by a node.
>
> Therefore I=A1=AFll say this question is not within scope for this doc= ument, it needs to be answered for specific use cases and applications of t= he SRH.
>
> That said there is ongoing work to define how a node may learn an SR P= olicy:
> PCEP https://www.ietf.org/id/draft-negi-pce-segment-routing-ipv6-03.txt,
> BGP-TE https://www.ietf.org/id/draft-ietf-idr-segment-routing-te-policy-04.txt= ,
> or =A1=B0SDN=A1=B1 methods where some outside controller sets up a seg= ment list via some REST, CLI, netconf/yang interface to satisfy specific us= e cases.
>
> And when to use it:
> BGP SRv6 services https://www.ietf.org/id/draft-dawra-idr-srv6-vpn-05.txt
>
>
>>
>> 1.2 : How to inform the destination of the segments in the SRH?&nb= sp; Any indicator in SRH? Or through signaling?
>>
>
>
> Same answer as 1.1. 
>
>> 2: Can a normal(non-SID) IPv6 address be added into SID list?
>>
>> I prefer yes.
>>
>> As section 4.3 says, it seems like we can do that.
>>
>>  "When an SRv6-capable node receives an IPv6 packet, it = performs a
>>  longest-prefix-match lookup on the packets destination addre= ss.  This
>>  lookup can return any of the following:
>>
>>      A FIB entry that represents a locall= y instantiated SRv6 SID
>>      A FIB entry that represents a local = interface, not locally
>>           &= nbsp;           &nbs= p;            instan= tiated as an SRv6 SID
>>      A FIB entry that represents a non-lo= cal route
>>      No Match
>>     "
>> Also, in section 5, we can see A9 can be added in SID list of a SR= policy.
>>
>> So for the packet from A9 to A1, the address of A1 can be added as= the last entry of SID list, right?
>>
>> If yes, address of A1 is not an instantiated SID, so not PSP flavo= r can be enabled. So the packet will be sent out by carrying the SRH after = A1 is updated to the IPv6 DA.
>> SRH will be leaked to outside of the SR domain, which will bring n= ew security issues.
>>
>
> Yes as the last segment in a segment list, and as RFC8200 section 4.4 = describes Routing Header processing when segments left is 0.
>
> It is up to the specific use case to determine if informing the destin= ation or intermediate nodes of the segment list used to reach it is a secur= ity risk.
>
> Certainly on the larger internet this is an issue that needs to be con= sidered, but within an enterprise network or within a single providers netw= ork crossing multiple domains, or even between providers the disclosure may= be acceptable or desired.
>
>>
>> 3: For section 6.2,
>>  Nodes outside the SR Domain cannot be trusted.  SR Doma= in Ingress
>>  routers SHOULD discard packets destined to SIDs within the S= R Domain
>>  (regardless of the presence of an SRH) to avoid attacks on t= he SR
>>  Domain as described and referenced in [RFC5095].
>>
>>  As an additional
>>  layer of protection, SR Segment Endpoint nodes SHOULD discar= d packets
>>  destined to local SIDs from source addresses not part of the= SR
>>  Domain.
>>
>> For a packet from A1 to A9,  the packet is (A1, A9). Node3 wi= ll not drop the packet since the destination is A9 not S9.
>>
>> If node 3 insert a SRH in the original IPv6 packet, then the sourc= e Address will be A1. And the SID list can be  <A9, S6 >.
>> In this case, the packet will be dropped by node 6, since the sour= ce address is not part of the SR domain.  [Section 6.2], right?
>>
>> IMHO, there are some problems about insertion mode.
>
> In the context of the SRH draft we do not make any mention or use of S= RH insertion. I.e. node 3 does not insert an SRH, it encapsulates in an out= er IPv6 header.
>
> Darren
>
>>
>> Thanks,
>> Cheng
>>
>>
>>
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-b= ounces@ietf.org] On Behalf Of Darren Dukes
>> (ddukes)
>> Sent: Wednesday, October 31, 2018 3:31 AM
>> To: Joel Halpern <jmh@joelhalpern.com>
>> Cc: spring@ietf.org; 6man@ietf.org
>> Subject: Re: SRv6 - SRH in encaps or base header - point 2
>>
>> I think we=A1=AFre almost concluded so once more inline at <dd&= gt;</dd>
>>
>>> On Oct 26, 2018, at 2:28 PM, Joel Halpern <jmh@joelhalpern.= com> wrote:
>>>
>>> (resending, +spring as requested)
>>>
>>> Thank you for the responses.  I will respond in line, mar= ked <jmh></jmh>.  I fear it will shortly get too deep, but= the context is important.
>>>
>>> I will rephrase here an issue from another thread that I ahve = not seen your comments on.  If Node 9 is sending traffic to Node 1 (fo= r example, the reverse traffic for the traffic from 1 to 9 in the examples = below), it presumably has an SR Policy to be applied. The issue I raised before is the leakage issue.  If 9 puts the SRH in= its packet (as the document currently mandates), then it will not be possi= ble for 3 to remove the SRH.  Thus, the SRH will leak.
>>>
>>> Some have argued that is not a big deal.  It seems to mat= ter to me.  But there is an additional problem.  A1 is not a SID.=   Therefore, 9 can not put A1 into the SRH.  If it can not put A1= into the SRH, and it does not encapsulate the packet, where does it put A1.
>>
>> <dd> Node 9 has a choice, encapsulate to node 3 or not.
>> If node 9 does not encapsulate, it will inform the destination of = the segments in the SRH and possibly leak them to intermediate nodes.
>> If node 9 does encapsulate, node 3 removes the outer header and no= de 1 would not learn the segment list.
>> I think its choice should not be mandated in the draft. </dd>= ;
>>
>>>
>>> Yours,
>>> Joel
>>>
>>> On 10/26/18 1:29 PM, Darren Dukes (ddukes) wrote:
>>>> Hi Joel, you=A1=AFve described sections titled =A1=B0Intra= SR Domain Packet=A1=B1, =A1=B0Transit Packet Through SR Domain=A1=B1, and = "SR Source Nodes Not Directly Connected=A1=B1.
>>>> I=A1=AFve parsed them inline to the sections of the draft = defining them and given more context where needed.
>>>>> On Oct 22, 2018, at 8:49 PM, Joel M. Halpern <jmh@j= oelhalpern.com> wrote:
>>>>>
>>>>> Rephrasing using the example from 5.2.  Assuming = that 8 and 9 are
>>>>> SR Hosts (not just hosts within the domain, they are c= apable of and
>>>>> expect to deal with SRHs, and therefore have local SID= s, ...)
>>>>>
>>>>> For traffic from 8 to 9 that needs an SRH, the SRH goe= s in the IPv6 header sent my 8 to 9.  When 9 processes the packet, it = seems that it is the last SID, figures out that there is no encapsulation, = and send the TCP / UDP / QUIC information to its internal protocols stacks.
>>>> Yes, this is Section 5.3.1 =A1=B0Intra SR Domain Packet=A1= =B1.
>>> <jmh>Agreed as far as it goes.  However,  the = existence of S9 and A9
>>> points to a problem.  Node 8 is trying to put on an SRH g= oing through
>>> Sx, Sy, whatever for some reason.  It can't put A9 into t= he SRH, as
>>> AH is not a SID, it is an address.  I presume node 8 got = S9 from
>>> whatever provided him the SR Policy that it is using.  Do= es it simply
>>> use S9 as the address for node 9, rather than A9 that it got f= rom
>>> DNS?  And does the TCP stack know that this substitution = is being
>>> made?  (This is another example of a problem that goes aw= ay if we
>>> always encapsulate.) </jmh>
>>
>> <dd>Section 4.3.2 covers these questions, i.e. A9 can be pla= ced in the
>> SRH as the last segment, and this section describes how it=A1=AFs =
>> handled.</dd>
>>
>>>
>>>>>
>>>>> For traffic from 1 to 9, where 3 adds an SRH, that SRH= still presumably ends at 9.  9 Receives the IP packet.  Sees tha= t it is addressed to itself.  Sees that the SRH is finished.  And= then notices that the next-header is IPv6.  Unwraps the header, check= s that the inner destination address is also itself, and passes the material= carried by the inner header up to the appropriate stack.
>>>> So node 1 sends a packet to node 9 (A1,A9) IF there is som= e steering
>>>> into an SR Policy at node 3 to reach node 9, this is ident= ical to section 5.3.2 =A1=B0Transit packet through SR domain=A1=B1, except = for destination of A9 via node 9  instead of A2 via node 4.
>>>
>>>>>
>>>>> Thus, 9 needs to be able to check for both cases. = ; We at least need to tell implementors that.
>>>> Well, 9 needs a SID S9 and Address A9.  That is shown= in Section 5.1 SID and address representation.
>>> <jmh>So, let us assume that 3 has an SR policy it wants = to apply to
>>> the traffic from A1 to A9.  In this case, the S9 / A9 dic= hotomy is
>>> not a problem, I think.  Node 3 encapsualtes the packet f= rom A1 to
>>> A9, uses S3 as the source address of the encapsulating header,= and
>>> ends the SID list in the SRH with S9.  The unspecified pa= rt is that
>>> node 9 needs to be prepared to receive such packets and do the= double
>>> processing.  It is reasonable double processing.  My= only request
>>> here is that we tell folks they need to support it. </jmh&g= t;
>>
>> <dd>Actually, node 3 uses A3 as its source address, but that= =A1=AFs minor.
>> The double processing (lookup, do end processing, do another looku= p) is documented in Section 4.3.
>> Is there a need for more than what is currently specified? </dd= >
>>
>>>>>
>>>>> There is a further complication.  9 seems to need= to have an address that is a valid SID, so it can be the last entry in the= SRH from 8 to 9.
>>>> As described in the draft, Section 5.1 a node k has an add= ress Ak and SID Sk.  So node 9 has a valid SID.
>>>> For traffic from 8 to 9, A9 is used as the destination as = shown in section 5.3.1, 5.4 and 5.5.
>>>>> However, if 1 were to send the packet to that SID for = 9, router 3 would be required by the rules we discussed in the other thread= to discard the packet as it is neither to prefix nor contains an HAMC.
>>>>> And somehow, 8 and 1 need to each pick the right addre= ss to use for 9. (split DNS maybe?)  And 3 needs to be able to derive = teh SID-formn address for 9 from the non-SID form of the address so that it= (3) can build a proper SRH to get the packet to 9.
>>> <jmh>I have retained your answer below for context, but = I think that
>>> answers the wrong question.  I believe what is itnended i= s that only
>>> A9 appears in DNS.  So Node 1 will see 9 as A9, and will = use that. 
>>> S9 will appear in SR Policies about traffic to node 9, but not= in DNS.
>>> That is what we need.  I wish it were clearer in the text= . </jmh>
>>>
>>> <jmh>If node 20 is generating SRHs with HMACs, then this= is largely
>>> the same as the case from 8 to 9, except that whomever creates= the SR
>>> Policy that 20 is using needs to also make sure that whatever = the
>>> first SID is in teh list, it processes HMACs and is recognizab= le to
>>> node 3 as doing such processing. I am guessing that the reason= for
>>> allowing internal nodes to do the processing is to move the >>> verification load off the edge nodes.  It does create sig= nificant
>>> additional configuration complexity. </jmh>
>>
>> <dd>We didn=A1=AFt see a reason to restrict the HMAC process= ing to only
>> edge nodes when it was straight forward to define how they could b= e
>> processed at non-edge nodes.</dd>
>>
>>>
>>>> This is incorrect.
>>>> See Section 6.2.1 =A1=B0SR Source Nodes Not Directly Conne= cted=A1=B1 I will expand on the example from that section.
>>>> Node 20 sends a packet to A9 with SR Policy <H7> and= an HMAC
>>>> provided to node 20 by some yet to be defined method. = ; Resulting in
>>>> packet sent from node 20
>>>> P: (A20,H7)(A9;SL=3D1)(payload)
>>>> Recall Hk is a SID at node k requiring HMAC verification, = and it is covered by Prefix-H.
>>>> Prefix-H is _not_ subject to ingress filtering at node 3.<= br> >>>> Therefore the packet P destined to H7 is not subject to in= gress filtering at node 3.
>>>> P is forwarded to node 7, where H7 is processed and the HM= AC verified.
>>>> If the HMAC can not be verified the packet is dropped, els= e it is forwarded to the next segment and destination, A9.
>>>> Darren
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>> On 10/22/18 8:04 PM, Darren Dukes (ddukes) wrote:
>>>>>> inline.
>>>>>>> On Oct 22, 2018, at 7:21 PM, Joel M. Halpern &= lt;jmh@joelhalpern.com> wrote:
>>>>> ..
>>>>>>> 2) Now let us look at packets arriving at and = actually destined for an SR Host in the SR Domain where that packet has an = SRH.  If the packet is coming from another SR Host, the SRH will be in= the base header, and the host can simply check it for any violations, and continue.  But, if the packet came from outside the d= omain, then it will have an encapsulating SRv6 header.  So the host ha= s to detect this case, check and then peal off the encapsulating header, an= d then process the received packet. Yes, it can do so.  But nothing in teh document tells implementors they have = to deal with both cases.
>>>>>>>
>>>>>> Can you be more precise here.  Perhaps use th= e example from section 5.2 or 6.2.1?
>>>>> ..
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> ------------------------------------------------------------------= --
>

--_000_C7C2E1C43D652C4E9E49FE7517C236CB01A5663Cdggeml529mbxchi_-- From nobody Mon Nov 5 20:09:01 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4877012D4EA; Mon, 5 Nov 2018 20:08:47 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es 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 g8d7HHU9KxT2; Mon, 5 Nov 2018 20:08:42 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7201612F295; Mon, 5 Nov 2018 20:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1541477297; x=1542082097; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=N3IlJOdmnQuW8UDcu3tsIYCBv5qc597Dti0QdFB4m1o=; b=X809cA0hInpk1 w27bOYV8xoGkE+uNvPQCdwnt7wthZzsyVFlWTnHucVjR3pfL0rN1D9AqEL4xqAd8 LwKDEvAN5+hC08iFuL+6gzmz1l+vwTrJlm8bRfO4ibI1l74MUUjNLxCoBd/aBlXh rs7BptoO0D0M1xf3pNNqUIArzvcVR4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 06 Nov 2018 05:08:17 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 06 Nov 2018 05:08:16 +0100 Received: from [172.20.60.83] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005945526.msg; Tue, 06 Nov 2018 05:08:15 +0100 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [172.20.60.83] X-MDArrival-Date: Tue, 06 Nov 2018 05:08:15 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=184881054d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.3.181015 Date: Tue, 06 Nov 2018 11:08:04 +0700 Subject: Re: [Int-area] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types From: JORDI PALET MARTINEZ To: Fred Baker , Linda Dunbar CC: "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" Message-ID: Thread-Topic: [Int-area] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> In-Reply-To: <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 04:08:48 -0000 I also share bad feelings here ... Do it natively with IPv6, no mappings, nothing strange. It will also make p= ossible for existing hardware, to do offload in the chipsets, which I don't= think you're considering. I also feel really weird that you are writing Ipv6 instead of IPv6, no reas= on for that. If you're intending to talk about an "internal" address, use "internal" not= private, please. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Int-area en nombre de Fred Baker Fecha: lunes, 5 de noviembre de 2018, 13:08 Para: Linda Dunbar CC: "idr@ietf.org" , "int-area@ietf.org" ,= "ipv6@ietf.org" Asunto: Re: [Int-area] Using BGP to advertise SD-WAN tunnels end point's pr= ivate IPv6 addresses. (was registering tunnel types Linda, I see a couple of issues here. Speaking as an individual. =20 First, IPv6 doesn't have private addresses, and in the general case doe= sn't use NATs. There is no direct counterpart to RFC 1918. The nearest para= llel might be a ULA (RFC 4193), but they are by design not routable using B= GP. =20 Second, yes NAT64 technology exists, but from a routing perspective the= endpoint either has an IPv4 address or an IPv6 address, not an IPv6 addres= s that is translated into an IPv4 address. That concept doesn't exist in ro= uting. =20 > On Nov 4, 2018, at 1:13 PM, Linda Dunbar wr= ote: >=20 > https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-e= xt/ specifies a new BGP SAFI (=3D74) in order to advertise a SD-WAN edge no= de=E2=80=99s capabilities in establishing SD-WAN overlay tunnels with other= SD-WAN nodes through third party untrusted networks. >=20 > Since a SD-WAN end point might use IPv6 private address, which is tra= nslated to IPv4 public address via NAT, want to get IPv6 group & Inter Are= a WG feedback on the subTLV proposed in the draft: >=20 > EncapsExt sub-TLV is for describing additional information about the = SD-WAN tunnel end-points, such as NAT property. A SD-WAN edge node can inqu= ire STUN (Session Traversal of UDP Through Network Address Translation RFC = 3489) Server to get the NAT property, the public IP address and the Public = Port number to pass to peers. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |EncapExt Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NAT Type | Encap-Type |Trans networkID| RD ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Private IP Address | > 32-bits for IPv4, 128-bits for Ipv6 > ~~~~~~~~~~~~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Private Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Public IP | > 32-bits for IPv4, 128-bits for Ipv6 > ~~~~~~~~~~~~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Public Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Where: > o EncapExt Type: indicate it is the EncapExt SubTLV. > o EncapExt subTLV Length: the length of the subTLVE. > o Flags: > o I bit: if set to 0, indicate the private address is IPv4. If = set to 1, it indicates the private address is IPv6. > o O bit: if set to 0, indicate the public address is IPv4. If s= et to 1, it indicates the public address is IPv6. > o R bits: reserved for future use. Must be set to 0 now. >=20 > o NAT Type=EF=BC=9Awithout NAT; 1:1 static NAT; Full Cone; Rest= ricted Cone; Port Restricted Cone; or Symmetric > o Encap Type=EF=BC=9ASD-WAN tunnel encapsulation types, such as= IPsec+GRE, IPsec+VxLAN, IPsec without GRE, GRE (when tunnel is over secure= underlay network) > o Transport Network ID=EF=BC=9ACentral Controller assign a glob= al unique ID to each transport network=EF=BC=9B > o RD ID=EF=BC=9ARouting Domain ID=EF=BC=8CNeed to be global uni= que. > o Private IP=EF=BC=9AThe local IP address of the tunnel end-poi= nt=EF=BC=9B > o Private Port=EF=BC=9Aused by Remote SD-WAN node for establish= ing IPsec to this specific port. > o Public IP=EF=BC=9AThe IP address after the NAT. > o Public Port=EF=BC=9AThe Port after the NAT. >=20 >=20 > Thank you very much for feedback. >=20 > Linda Dunbar >=20 >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of tom petch > Sent: Friday, November 02, 2018 11:26 PM > To: Joel Jaeggli > Cc: ipv6@ietf.org > Subject: Re: registering tunnel types >=20 > ---- Original Message ----- > From: "Joel Jaeggli" > To: "tom petch" > Cc: ; ; "Alexandre Petre= scu" > Sent: Tuesday, October 30, 2018 8:23 PM >=20 > > On Oct 30, 2018, at 05:07, tom petch wrote: > >> > > > > Alex > > > > I agree, at least in part; tunnels and interfaces are different > animals > > and it is unfortunate that they were conflated in SMI. > > > > I was surprised that NETMOD had not produced a YANG module for tunn= els > > but it seems that there has been no need for the past decade. That > > said, I think that it is a good idea to have one. Whether or not i= t > > should mirror the Tunnel MIB I find more debatable. >=20 > It=E2=80=99s not entirely obvious to me that netted / netconfig would= be where the tunnel models were produced. >=20 > They tend if fact to be produced by the tunnel protocol maintainers e= .g. > l3sm/l2sm/ccamp and so on. The management tools for a product tend to= be developed itself in my experience. >=20 > >=20 > Joel >=20 > My concern is that something that cuts across a number of IETF WG sho= uld get adequate review. The YANG interface module was much discussed in t= he netmod WG, with an existing MIB as guidance, before becoming an RFC. >=20 > The proposed YANG tunnel module, which borrows the concepts of the in= terface module, that additions should be made by the Tunnel MIB Designated = Expert to a registry and then propagated to the Tunnel MIB and the Tunnel Y= ANG module, has not been discussed in any WG. The proposal, as I mentioned= before, has been added to the I-D after IETF Last Call has been completed = so appears to me to be the work of one individual, without any review; the = I-D lists seven editors, six of whom appear to be absent. TheWG mailing li= st seems devoid of any discussion. >=20 > I believe that the IETF succeeds because of peer review, and I strugg= le to see that here. >=20 > Tom Petch >=20 > > My own homework came across other IP in IP varieties which do not > > appear. > > > > Tom Petch > > > > > >> > >> Alex > >> > >>> > >>> If you need a new value or if you have a question about a given > > interface tunnel type, please follow the guidelines in the url cite= d > > above. All this is out of the scope of draft-ietf-softwire-yang. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Alexandre > > Petrescu > >>>> Envoy=C3=A9 : jeudi 25 octobre 2018 09:54 =C3=80 : ipv6@ietf.org= Objet : Re: > >>>> registering tunnel types > >>>> > >>>> Are: > >>>> -IPv6 in UDPv4 and > >>>> -IPv6 in IPv6 as used by openvpn; > >>>> > >>>> covered by the list below? > >>>> > >>>> These are a few tunnelling mechanisms I use routinely. > >>>> > >>>> Existing identity 6tofour should be deprecated, if that means 6t= o4, > >>>> which is deprecated. > >>>> > >>>> Existing identity iphttps has a version number for IP? > >>>> > >>>> Alex > >>>> > >>>> Le 24/10/2018 =C3=A0 17:57, tom petch a =C3=A9crit : > >>>>> draft-ietf-softwire-yang > >>>>> completed IETF Last Call two weeks ago and, since then, has > > acquired a > >>>>> YANG module that defines tunnel types, as listed below. It is > > intended > >>>>> to be a IANA-maintained module and so changes to the list of > > tunnels > >>>>> will not require a reissue of the softwires RFC-to-be. At the > > same > >>>>> time, getting it right first time never did any harm so if anyo= ne > > can > >>>>> think of any missing, or can think of other places where there > > might be > >>>>> other tunnels lurking, now would be a good time to mention it. > >>>>> > >>>>> It is based on RFC4087 Tunnel MIB (which created an SMI Textual > >>>>> Convention that went up to Teredo) so tunnels from that vintage > > are > >>>>> likely well catered for. softwires is not where I would have > > first > >>>>> looked for tunnel types, but it has a certain logic to it. > >>>>> > >>>>> identity other > >>>>> > >>>>> identity direct > >>>>> > >>>>> identity gre > >>>>> > >>>>> identity minimal > >>>>> > >>>>> identity l2tp > >>>>> > >>>>> identity pptp > >>>>> > >>>>> identity l2f > >>>>> > >>>>> identity udp > >>>>> > >>>>> identity atmp > >>>>> > >>>>> identity msdp > >>>>> > >>>>> identity sixtofour > >>>>> > >>>>> identity sixoverfour > >>>>> > >>>>> identity isatap > >>>>> > >>>>> identity teredo > >>>>> > >>>>> identity iphttps > >>>>> > >>>>> identity softwiremesh > >>>>> > >>>>> identity dslite > >>>>> > >>>>> identity aplusp > >>>>> > >>>>> Tom Petch > >>>>> > >> > >>>> ----------------------------------------------------------------= --- > - > >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrati= ve > >>>>> Requests: > > https://www.ietf.org/mailman/listinfo/ipv6 > >> > >>>> ----------------------------------------------------------------= --- > - > >>>>> > >>>> > >> > >>> -----------------------------------------------------------------= --- > >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrativ= e > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> > >>> -----------------------------------------------------------------= --- > >> > >> ------------------------------------------------------------------= -- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 > >> ------------------------------------------------------------------= -- > >> > > > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------= - >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- =20 -----------------------------------------------------------------------= --------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu =20 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Nov 5 22:05:31 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BCD130E39; Mon, 5 Nov 2018 22:05:29 -0800 (PST) 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 9A8uS5-aeVYX; Mon, 5 Nov 2018 22:05:27 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 078FA130E25; Mon, 5 Nov 2018 22:05:24 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id k19-v6so10294906lji.11; Mon, 05 Nov 2018 22:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/4n/WeEBaQIP6b57g75A+50fRgesYVDRP+FtUiV+oko=; b=VJokdis2VKMKuULP+h78obxvFGzS5RFR+Mm4vrcLeaLPThFx7q+bS2imvfhPTPb5zD EoHspTEXR+h6uWhgP6j1pYMN56f9awxo+Qf6ZHMuxHFHJEV35W2ABRsPUO63zbrIE/SN YG9yUBkqgotEgm3jkGUbsIT4zFmlOyEaL/Vz92TJHQYYVex4RPWnnnjnswesEv7Vg4QS 3UxAW6foS3+i1mN1jTJAMJlKRwMbHxfNoRZiqeq8LGGYskcsYPDpHxtW7XMCFRgxdpwM FTlVWneU04mS+QXpcyhSIegYkCyNPPQvbvTpPPEbwGaAfxQLnQDnkr6CDqGOzUBqdAQR hjCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/4n/WeEBaQIP6b57g75A+50fRgesYVDRP+FtUiV+oko=; b=dc93XQQqnVVM8JvJSXRFMnwjrnX1BB6jZ9sx/qvau4ngLZe6jvDIpCjE1HxvWu8XFq asHCTYyhY7RCDdCepXKIiPZr+dP3VFCHAuj79Yq+eEZRYr6PcxV/D0AjSyx/mSc6gVDt jQhICN0cJA8oEiUaN9ywIKRBdTqCz2cYp4ctqxTT66Dtgf67ru+40svH/U8vxcxnCTjN nHA+VQVdNQ8ShDw/j695e9YWugdEhmiXVJr8vNOVl7TbWjf3hFfIrz1F5DSiqNmpeyZk tqOORAoiXJJKObT19N4bWUG4hhbUr3Tuli3WwHQWNrM9TESFlTxLjUz+uLZU8xmAss0e 09vA== X-Gm-Message-State: AGRZ1gLuu9sbY1vGpH0CJz3Ekii2AAC82A3GarjF2LpB+DQ8A6K7ZlRt DDDKjwhbHxdBdy50Iz2PVyR2H23PyUA0MJ6HDEMpGGqCQl8= X-Google-Smtp-Source: AJdET5d9JKVUaa5XCsXMjJHINrL5KVpEGpie/prRNQicdsNuhnpkz/0oK55FxNcX3s7ZJV5HYQR2eS93QWYBz/xtzVE= X-Received: by 2002:a2e:94ce:: with SMTP id r14-v6mr14443527ljh.34.1541484320421; Mon, 05 Nov 2018 22:05:20 -0800 (PST) MIME-Version: 1.0 From: Greg Mirsky Date: Tue, 6 Nov 2018 13:05:10 +0700 Message-ID: Subject: Sequence Number in RFC 6374 and Synthetic Loss Measurement To: draft-gandhi-spring-udp-pm@ietf.org, spring , IETF IPPM WG , 6man WG Content-Type: multipart/alternative; boundary="000000000000587baa0579f8c9ae" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 06:05:29 -0000 --000000000000587baa0579f8c9ae Content-Type: text/plain; charset="UTF-8" Dear Authors, in your presentation of this draft at IPPM WG meeting I've pointed that assertion in Section 6 of the draft: The message formats for DM and LM [RFC6374] do not contain sequence number for probe query packets. is not accurate. RFC 6374 allows interpretation of the Timestamp field as a sequence number. Section 3.4 explains that QTF and RTF values could be 0, 1, 2, or 3, with 1 identifying the sequence number: 1: Sequence number. This value indicates that the timestamp field is to be viewed as a simple 64-bit sequence number. This provides a simple solution for applications that do not require a real absolute timestamp, but only an indication of message ordering; an example is LM exception detection. Regards, Greg --000000000000587baa0579f8c9ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors,
in you= r presentation of this draft at IPPM WG meeting I've pointed that asser= tion in Section 6 of the draft:
=C2=A0 =C2=A0The message for= mats for DM and LM [RFC6374] do not contain sequence
=C2=A0 =C2= =A0number for probe query packets.
is not accurate. RFC 637= 4 allows interpretation of the Timestamp field as a sequence number. Sectio= n 3.4 explains that QTF and RTF values could be 0, 1, 2, or 3, with 1 ident= ifying the sequence number:
=C2=A0 =C2=A0 =C2=A0 1: Sequence= number.=C2=A0 This value indicates that the timestamp field
=C2= =A0 =C2=A0 =C2=A0 is to be viewed as a simple 64-bit sequence number.=C2=A0= This provides
=C2=A0 =C2=A0 =C2=A0 a simple solution for applica= tions that do not require a real
=C2=A0 =C2=A0 =C2=A0 absolute ti= mestamp, but only an indication of message ordering; an
=C2=A0 = =C2=A0 =C2=A0 example is LM exception detection.

=
Regards,
Greg

--000000000000587baa0579f8c9ae-- From nobody Mon Nov 5 23:29:34 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8057B128CB7 for ; Mon, 5 Nov 2018 23:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 vQnXwA34EV9s for ; Mon, 5 Nov 2018 23:29:30 -0800 (PST) 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 436DB128A5C for ; Mon, 5 Nov 2018 23:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1930; q=dns/txt; s=iport; t=1541489370; x=1542698970; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ucdL20xP/NxoVfqh2KQkdTQnNzxzmp9DiYjfT7hTHX0=; b=Dcm3mT/wZ2dQ6/1UwTj9RwRHF84XxDO8bHs1GrqVzwHF3kBPYeDsTFwY YSOhGYX0fvLdf+vcVfn+HxPEFWoB+E5R3/VegiBVm1LsUPb7EBfTlgyNp vb0ZEclcHL8SWOaR4VMPffp0dcuohzOQzLlNYqZTQzha1WxOXLWrcAuAs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABrQuFb/5pdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVUvZn8oCoNsiBiOAJdUFIFmCwEBGAu?= =?us-ascii?q?ESQIXg0EiNA0NAQMBAQIBAQJtHAyFOwIEAQEhEToLEAIBCBoCJgICAiULFRA?= =?us-ascii?q?CBAENBYMhAYIBD6hwgS6KLgWBC4prF4FBP4E4DBOCTIMbAQGBLgESAR8Xgm0?= =?us-ascii?q?xgiYCiQmWKgkCkQ8YkGCXIgIRFIEmHThkcXAVOyoBgkGCJxeIXYU+b4ttgR+?= =?us-ascii?q?BHwEB?= X-IronPort-AV: E=Sophos;i="5.54,470,1534809600"; d="scan'208";a="259207141" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 07:29:25 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id wA67TPBL000402 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2018 07:29:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Nov 2018 02:29:24 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Tue, 6 Nov 2018 02:29:24 -0500 From: "Eric Vyncke (evyncke)" To: Nick Hilliard , Brian E Carpenter CC: "ipv6@ietf.org" Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Thread-Topic: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt Thread-Index: AQHUZaVwWh7cAlkP9UKM0gKm7J2j56U4kZEAgAAEOQCAANkRgIAArMqAgAJBRACAAN0FAIABEJ2AgACh9YCAAjdLAIAAGeqAgAA8i4CAAciAgA== Date: Tue, 6 Nov 2018 07:29:24 +0000 Message-ID: References: <153973137181.9473.10666616544238076833@ietfa.amsl.com> <6264F7A1-59EB-467D-A576-E5F2F0DEE7DD@lists.zabbadoz.net> <97ba35ff-b4a7-314c-3010-297d06be645d@foobar.org> <01c2a55e-1888-3ebc-3252-11b9005b8272@gmail.com> <0abd7b4d-b0e0-b1bc-2468-678befbc7cac@asgard.org> <3e155df0-5799-8788-5fbe-767a7421828c@gmail.com> <18646396-e3f7-b9ad-3871-69868468859a@asgard.org> <95654922-acd1-3cb3-c650-942c97e3cc85@asgard.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.3.181015 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.68.214.26] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 07:29:33 -0000 Tmljaw0KDQpKdXN0IHJlYWRpbmcgeW91IG5vdyBhdCB0aGUgNk1BTiBXRyBtZWV0aW5nIGFmdGVy IG1ha2luZyBleGFjdGx5IHRoZSBzYW1lIHBvaW50IGFzIHlvdXJzIDotKA0KDQpUbyBidXN5IGhl cmUgdG8gZm9sbG93IGFsbCBlbWFpbCBtZXNzYWdlcy4uLg0KDQotw6lyaWMNCg0K77u/T24gMDUv MTEvMjAxOCwgMTg6MTYsICJpcHY2IG9uIGJlaGFsZiBvZiBOaWNrIEhpbGxpYXJkIiA8aXB2Ni1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBuaWNrQGZvb2Jhci5vcmc+IHdyb3RlOg0KDQog ICAgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGUgb24gMDUvMTEvMjAxOCAwNzozODoNCiAgICA+IEFu ZCB5ZXMsIGEgaG9zdCBNQVkgaWdub3JlIGl0ICh0aGF0J3MgdGhlIGNvbXBsZW1lbnQgdG8gdGhl IFNIT1VMRA0KICAgID4gaW4gdGhlIGRyYWZ0KS4gV2UndmUgbmV2ZXIgc2FpZCBhbnl0aGluZyBl bHNlLg0KICAgIA0KICAgIHllcywgYnV0IHlvdSBoYXZlIHN0YXRlZCAiT24gYW4gSVB2Ni1Pbmx5 IGxpbmssIElQdjQgbWlnaHQgYmUgdXNlZCBmb3IgDQogICAgbWFsaWNpb3VzIHB1cnBvc2VzIGFu ZCBwYXNzIHVubm90aWNlZCBieSBJUHY2LU9ubHkgbW9uaXRvcmluZyBtZWNoYW5pc21zIi4NCiAg ICANCiAgICBJZiB5b3Ugd2FudCBpcHY2b25seS1mbGFnIHRvIGJlIGFkdmlzb3J5LCB0aGVuIHlv dSBuZWVkIHRvIHJlbW92ZSB0aGlzIA0KICAgIGJ1bGxldC1wb2ludCBmcm9tIHRoZSBkb2N1bWVu dCBiZWNhdXNlIHRoZSBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIGFuIFJBIA0KICAgIHdpdGggaXB2 Nm9ubHktZmxhZyBzZXQgd2lsbCBub3QgaGF2ZSBhbnkgZWZmZWN0IG9uIG1hbGljaW91cyB1c2Ug b2YgaXB2NCANCiAgICBvbiBhbiBvdGhlcndpc2UgImlwdjYtb25seSIgbmV0d29yay4NCiAgICAN CiAgICBZb3UgY2Fubm90IHVzZSBzZWN1cml0eSB0byBqdXN0aWZ5IHNvbWV0aGluZyB1bmxlc3Mg dGhlIHByb3Bvc2FsIA0KICAgIHByb3ZpZGVzIGEgbWVjaGFuaXNtIGZvciBlbmZvcmNlbWVudDsg aWYgeW91IGhhdmUgbm8gbWVhbnMgb2YgDQogICAgZW5mb3JjZW1lbnQsIGl0J3MgZmx1ZmYsIG5v dCBzZWN1cml0eS4NCiAgICANCiAgICBOaWNrDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBJ RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCiAgICBpcHY2QGlldGYub3JnDQog ICAgQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQoNCg== From nobody Mon Nov 5 23:42:45 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6158128A5C for ; Mon, 5 Nov 2018 23:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 BZlmF2EuNeUm for ; Mon, 5 Nov 2018 23:42:41 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 55E7412007C for ; Mon, 5 Nov 2018 23:42:41 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id t190-v6so10851955itb.2 for ; Mon, 05 Nov 2018 23:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=r8XKTxVoRqIePTrIosIALQrFMd+ZvVYM1IJfYhNid9Q=; b=hw3fCpZrsespTSZ4Hz81tCPHU/TDJUYnFWrQs3jwP9z72zkuM8kTvANqZ0/qM1GvOY dM+Auo0FWJ3EcLqIrdrxinjKy1U0iUDuVdo0XMVssAsZ3g9zMl3yEyb9yoy1iS/tExCF xIBEcuUbsmd8SgG6yqpq7ArMH0W3u7txRm3kTAcMUQ1R4FE0GOg+IJHtoxIaqCsR8Anx kJruehDQezp0Bqy0Djth/qNGwvotcv6dYWp85L4e9zLogcCED2PgL87TvZCEaGS226fU jaJm/lZHa5N7eGswFynHVYU/0ebd81ZnEo3Hnic1cA1bw1cAh+ia9sn+BGbAYtakm+q6 XatQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r8XKTxVoRqIePTrIosIALQrFMd+ZvVYM1IJfYhNid9Q=; b=hDsINSBhtOP8XhdhqRhkFS+DVz8FJAuMQbv10+4onxpeHjJqUIDNslsni4V/lIsoPz 0xFIMnJKBjO0j38oJd8DDn0b+HFdkvvxUutZPawcN2NvyPInPk3D21Xex9eAvOhZD+XL AYHMkV2yWtAa9FLuvzj6UdySb8G1FwgVVAH3haokT39dIku5qsJxsYCREy4t2M+vMf31 sFPH5bwqipsTZUI2noNTwARtYVhpwuzGJzVu2uE5l4EL/oCKXDJ6gS3Swcq/27f9GtEK KQn47XXS8K2BvDMUS+4YQ9lVMXJfUhaa4jsdOlyISoijmR22x9cHFotx/cpFIarFrwu0 TS2w== X-Gm-Message-State: AGRZ1gInXE8XAyqlNmPTK/GAttCkFJm7nuzA8gmJoQwkvkdSonyNGqpl izVv0wglxDqWTAJk7qUrX9w/XlJMww4A2sY4LwLsTd3mMbEKpq4e X-Google-Smtp-Source: AJdET5ca6gGOfsNXs/3VR26mVQDRrVNGBjH+xsVMY8gDot6BD7iUDFrBn/lp6nCZ2nLCT9oGDhJolLtjG+Ed98fJi6g= X-Received: by 2002:a24:af5e:: with SMTP id l30-v6mr1211859iti.134.1541490159901; Mon, 05 Nov 2018 23:42:39 -0800 (PST) MIME-Version: 1.0 From: Lorenzo Colitti Date: Tue, 6 Nov 2018 14:42:28 +0700 Message-ID: Subject: Comments on IPv4-only flag document To: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="0000000000006864000579fa25c3" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 07:42:43 -0000 --0000000000006864000579fa25c3 Content-Type: text/plain; charset="UTF-8" Playing back my comments at the mike: 1. I don't think it's useful to say that IPv4 should be enabled if the default router lifetime goes to zero. The default router lifetime going to zero is a normal occurrence, e.g., when the router loses uplink connectivity. I would say that the flag is valid in all cases. If the network says it doesn't have IPv4, and it doesn't have working IPv6, the host can always disconnect, try another network, or ignore the flag. 2. We should not say that the flag means that IPv6 is "the only ip version on the link". We don't want this draft to rule out new versions of IP. Maybe instead of saying "no other versions of Internet protocol" we can say "no lower-numbered version of the Internet protocol is in use". 3. We should say that this flag has no effect if IPv4 configuration has already succeeded (e.g., the host has obtained a valid configuration from DHCPv4). This should address many of the security questions that have been raised. Cheers, Lorenzo --0000000000006864000579fa25c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Playing back my comments at the mike:

1. I don't think it's= useful to say that IPv4 should be enabled if the default router lifetime g= oes to zero. The default router lifetime going to zero is a normal occurren= ce, e.g., when the router loses uplink connectivity. I would say that the f= lag is valid in all cases. If the network says it doesn't have IPv4, an= d it doesn't have working IPv6, the host can always disconnect, try ano= ther network, or ignore the flag.

2. We= should not say that the flag means that IPv6 is "the only ip version = on the link". We don't want this draft to rule out new versions of= IP. Maybe instead of saying "no other versions of Internet protocol&q= uot; we can say "no lower-numbered version of the Internet protocol is= in use".

3. We should say that this flag has= no effect if IPv4 configuration has already succeeded (e.g., the host has = obtained a valid configuration from DHCPv4). This should address many of th= e security questions that have been raised.

= Cheers,
Lorenzo
--0000000000006864000579fa25c3-- From nobody Mon Nov 5 23:53:17 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA6130F25 for ; Mon, 5 Nov 2018 23:53:05 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] 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 KqsUbzmUjodS for ; Mon, 5 Nov 2018 23:53:02 -0800 (PST) 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 BDC60130EAC for ; Mon, 5 Nov 2018 23:53:01 -0800 (PST) X-Original-To: ipv6@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5E3C541C1E for ; Tue, 6 Nov 2018 08:52:59 +0100 (CET) X-SpaceNet-Relay: true 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 497C041135; Tue, 6 Nov 2018 08:52:59 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 39D007357; Tue, 6 Nov 2018 08:52:59 +0100 (CET) Date: Tue, 6 Nov 2018 08:52:59 +0100 From: Gert Doering To: "Henderickx, Wim (Nokia - BE/Antwerp)" Cc: Gert Doering , Linda Dunbar , "idr@ietf.org" , "ipv6@ietf.org" , "int-area@ietf.org" , Fred Baker Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Message-ID: <20181106075259.GM11393@Space.Net> References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> <20181105165959.GB11393@Space.Net> <4B2F3673-5106-4914-B79F-F3C44013ED06@nokia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U+bklQA0mt3anuN/" Content-Disposition: inline In-Reply-To: <4B2F3673-5106-4914-B79F-F3C44013ED06@nokia.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 07:53:11 -0000 --U+bklQA0mt3anuN/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Nov 06, 2018 at 01:06:52AM +0000, Henderickx, Wim (Nokia - BE/Antwe= rp) wrote: > Even a NAT64 is not needed. What we do now is we go to a GW (lets call it= like this for now) and the GW rewrites the outer header of the tunnel srcI= P and dstIP from v4 to v6 or vice versa. It is kind of decap/encap operatio= n on the outer header as if you terminate the tunnel and reinitiate the tun= nel. No NAT64 required. >=20 So how exactly is this different from a NAT64? "You take off the IPv4 header, put on an IPv6 header, and remember where the response packets needs to be sent to" If you preconfigure the mapping, it's still a NAT64 :-) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --U+bklQA0mt3anuN/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlvhSFgACgkQ31bAZeTO f8XCEA//f/zEQigofnIEKvkJKYAzKci2x7pBGMIM1/n3Hyfkdfn0Xg0yB9WG5Ocv tMehUrrzvsbhuWVgjVXDxPMHvBzN1xyfKf4+VDYoGzCZtYkJhdpr2oeCnN6kMwDc 7BobcIwDOpKxJPT0oLzIysXFwyUlfjnJVkoAF9bOlAxDONtoPN5uAV4zIgESUpvD Q3Kq6CNawEGgrAX252Dvk135YhevmbQn5atQTR9cjlc5BIvyvzixjs396IMw9qIs 1tPOqKFf2LReG+BFLseo9vxzmon9WdWO+y2Q2jdlgjHDYxrdTedbVvKjqKTcwjX2 8o5zDErw2d2tJKZNbln9qQv3AZnm5N1dGAIqUTeQ6SPmbtfOpPEZ+GQw/G2rgA5C goBlnPnHqZsdjxhaUKLcSefM4Hw/B0q7/LwfQyPj41EF+Gu2sJLDaHOZq7aTZE6n TrTzEQzLMSrrUtWJT4ENd4LHEDTDUgQt+m5ApBc25M3EcJK6yyIN5K0u9PMT2JmC OvguAEa1E5v8lifrlRN+WLndds84cAdbmaaT+3U6z6/BQoYEZuFY6NVDk1t5RAPz 8N9YdlmmIk57ZWavQ0WvIVAfZ9l/+mkgmUH1vPUboBJmMAyL47ptYUigsb5o26dG NNCY7bULAFYUy4anvudbqgyT6B+BwRDFVkN85qkbA7jBfYcCJtk= =EdDo -----END PGP SIGNATURE----- --U+bklQA0mt3anuN/-- From nobody Tue Nov 6 00:03:32 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F36B128CF2; Tue, 6 Nov 2018 00:03:19 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es 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 iXPyKUXAhoSZ; Tue, 6 Nov 2018 00:03:16 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBF612007C; Tue, 6 Nov 2018 00:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1541491394; x=1542096194; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=+EBh5mz/hwj7bXV/Hbpz+QIM7Tef90j9lBXQo/48eIw=; b=ZWFyreXb3LZ0d Z8B51nAir9jsKBVH7RfviZSv84UfO1zr7BZwrk1KOkRrEYMbhLrUtbeS16HavQ3y 6fq9Dj/vRjsADdiqrexliH7TQISs4SQ1zMp3cnsGdtQpNW41rOC+arrc88vVSLwM U9e1vTXVu8mzEN2NGeSbrcSTDF/IeI= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 06 Nov 2018 09:03:14 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 06 Nov 2018 09:03:14 +0100 Received: from [31.133.128.251] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005945793.msg; Tue, 06 Nov 2018 09:03:13 +0100 X-MDRemoteIP: 2001:67c:370:128:d0dc:690:511c:2ead X-MDHelo: [31.133.128.251] X-MDArrival-Date: Tue, 06 Nov 2018 09:03:13 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=184881054d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.3.181015 Date: Tue, 06 Nov 2018 15:03:04 +0700 Subject: Re: [Int-area] [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types From: JORDI PALET MARTINEZ To: Gert Doering , "Henderickx, Wim (Nokia - BE/Antwerp)" CC: "idr@ietf.org" , "int-area@ietf.org" , "ipv6@ietf.org" Message-ID: <0B252807-935A-4CE7-8CFD-23801B594F59@consulintel.es> Thread-Topic: [Int-area] [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> <20181105165959.GB11393@Space.Net> <4B2F3673-5106-4914-B79F-F3C44013ED06@nokia.com> <20181106075259.GM11393@Space.Net> In-Reply-To: <20181106075259.GM11393@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:03:19 -0000 I guess they are missing that this is an stateless NAT64 ? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Int-area en nombre de Gert Doering Fecha: martes, 6 de noviembre de 2018, 14:54 Para: "Henderickx, Wim (Nokia - BE/Antwerp)" CC: "idr@ietf.org" , "int-area@ietf.org" ,= "ipv6@ietf.org" , Gert Doering Asunto: Re: [Int-area] [Idr] Using BGP to advertise SD-WAN tunnels end poin= t's private IPv6 addresses. (was registering tunnel types Hi, =20 On Tue, Nov 06, 2018 at 01:06:52AM +0000, Henderickx, Wim (Nokia - BE/A= ntwerp) wrote: > Even a NAT64 is not needed. What we do now is we go to a GW (lets cal= l it like this for now) and the GW rewrites the outer header of the tunnel = srcIP and dstIP from v4 to v6 or vice versa. It is kind of decap/encap oper= ation on the outer header as if you terminate the tunnel and reinitiate the= tunnel. No NAT64 required. >=20 =20 So how exactly is this different from a NAT64? =20 "You take off the IPv4 header, put on an IPv6 header, and remember wher= e the response packets needs to be sent to" =20 If you preconfigure the mapping, it's still a NAT64 :-) =20 Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? =20 SpaceNet AG Vorstand: Sebastian v. Bomhard, Michae= l Emmer 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Nov 6 00:08:15 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CA112D7EA for ; Tue, 6 Nov 2018 00:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 qngXoqDvMb6t for ; Tue, 6 Nov 2018 00:08:11 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716BA128A5C for ; Tue, 6 Nov 2018 00:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6370; q=dns/txt; s=iport; t=1541491691; x=1542701291; h=from:to:cc:subject:date:message-id:mime-version; bh=hxZOVn7eY+2UhHQz7OPalX/Pv34T3Jbcx2rA8+uiI+M=; b=KtElo9d9GhpU9XHVlXQuQGeOkSUVZfdXXc3Y8tIQ/iqgl4mNEj4zxB/g xlXoXn5PWhxXLVoJ5SLu3qiD2YhLN2i01a60c2/tSjVGr4ncqM3l5rjay RqCNkol8jfAayiYOpRWQjnA0CVtEPQXuifGhp10L9RrQR4YOxJNJD1UCM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAAAmS+Fb/4oNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBDXdmfygKg2yWGJIAhVSBegsBARuEURmDQSI?= =?us-ascii?q?2Cw0BAwEBAgEBAm0cDIVkVhIBSgIEMCcEAQ2DJgGBHWSofIEuhTyEdot2F4F?= =?us-ascii?q?BP4E4DBOICIJGMYImAo5fhiqKKgkChmyKIxiQYJciAhEUgSYkAy6BVXAVZQG?= =?us-ascii?q?CQQmIYodub40MgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,471,1534809600"; d="scan'208,217";a="480514541" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 08:08:10 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id wA688Aue004457 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2018 08:08:10 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Nov 2018 02:08:09 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1395.000; Tue, 6 Nov 2018 02:08:09 -0600 From: "Pablo Camarillo (pcamaril)" To: "Joel M. Halpern" , "Darren Dukes (ddukes)" CC: "ipv6@ietf.org" Subject: Question 6man SRH encaps only Thread-Topic: Question 6man SRH encaps only Thread-Index: AQHUdafa15+XY1Mf/0a+ctWznq09Vw== Date: Tue, 6 Nov 2018 08:08:09 +0000 Message-ID: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.68.85] Content-Type: multipart/alternative; boundary="_000_7E1C8E10DA954347A99A8A2FC1B79A77ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:08:14 -0000 --_000_7E1C8E10DA954347A99A8A2FC1B79A77ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lbCwNCg0KUmVnYXJkaW5nIHlvdXIgcXVlc3Rpb24gb24gNm1hbiBhYm91dCB0aGUgU1JI IGFuZCBhbGxvd2luZyBvbmx5IGVuY2Fwc3VsYXRpb246DQpUaGVyZSBhcmUgdHdvIG9wZW4tc291 cmNlIGhvc3QgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBTUkggKExpbnV4IEtlcm5lbCwgRkQuaW8g VlBQKS4gSSB3cm90ZSB0aGUgY29kZSBmb3IgU1JIIGluIHRoZSBsYXR0ZXIuDQoNCkEtLS0xLS0t Mi0tLUINCihBIGFuZCBCIGFyZSBob3N0cykNCg0KSW4gb25lIG9mIHRoZSB1c2UtY2FzZXMgaG9z dCBBIGhhcyBhd2FyZW5lc3Mgb2YgdGhlIHRyYW5zcG9ydCBuZXR3b3JrLg0KSG9zdCBBIGdlbmVy YXRlcyBhbmQgc2VuZHMgYSBwYWNrZXQgb2YgdGhlIGZvcm0gSVAoU1JIKFRDUCguLi4pKSkgd2hl cmUgdGhlIFNSSCBjb250YWlucyBzZWdtZW50cyA8MSwyLEI+Lg0KTm90ZSB0aGF0IEIgaXMgYW4g aW50ZXJmYWNlIGFkZHJlc3Mgb24gaG9zdCBCLg0KDQpEbyB5b3UgYmVsaWV2ZSB0aGF0IGluIHRo aXMgY2FzZSB0aGUgaG9zdCBzaG91bGQgc2VuZCBJUChTUkgoSVAoVENQKC4uLikpKSk/IElmIHll cywgd2h5Pw0KSSB0aGluayB0aGlzIGlzIGEgcmVsZXZhbnQgdXNlLWNhc2UgLWUuZy4gUEFOUkct LCBhbmQgZG9u4oCZdCBzZWUgd2h5IHdlIHdvdWxkIGVuZm9yY2UgZW5jYXBzdWxhdGlvbi4NCg0K VGhhbmtzLA0KUGFibG8uDQoNCg== --_000_7E1C8E10DA954347A99A8A2FC1B79A77ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <32FA63457102154FA5CD1751046BFCAC@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDMuMGNtIDcwLjg1cHQgMy4wY207fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIEpvZWwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZGlu ZyB5b3VyIHF1ZXN0aW9uIG9uIDZtYW4gYWJvdXQgdGhlIFNSSCBhbmQgYWxsb3dpbmcgb25seSBl bmNhcHN1bGF0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlcmUgYXJlIHR3 byBvcGVuLXNvdXJjZSBob3N0IGltcGxlbWVudGF0aW9ucyBvZiB0aGUgU1JIIChMaW51eCBLZXJu ZWwsIEZELmlvIFZQUCkuIEkgd3JvdGUgdGhlIGNvZGUgZm9yIFNSSCBpbiB0aGUgbGF0dGVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5BLS0tMS0tLTItLS1CPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4o QSBhbmQgQiBhcmUgaG9zdHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIG9uZSBvZiB0aGUgdXNlLWNhc2VzIGhv c3QgQSBoYXMgYXdhcmVuZXNzIG9mIHRoZSB0cmFuc3BvcnQgbmV0d29yay4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+SG9zdCBBIGdlbmVyYXRlcyBhbmQgc2VuZHMgYSBwYWNrZXQg b2YgdGhlIGZvcm0gSVAoU1JIKFRDUCguLi4pKSkgd2hlcmUgdGhlIFNSSCBjb250YWlucyBzZWdt ZW50cyAmbHQ7MSwyLEImZ3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Tm90ZSB0 aGF0IEIgaXMgYW4gaW50ZXJmYWNlIGFkZHJlc3Mgb24gaG9zdCBCLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EbyB5 b3UgYmVsaWV2ZSB0aGF0IGluIHRoaXMgY2FzZSB0aGUgaG9zdCBzaG91bGQgc2VuZCBJUChTUkgo SVAoVENQKC4uLikpKSk/IElmIHllcywgd2h5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SSB0aGluayB0aGlzIGlzIGEgcmVsZXZhbnQgdXNlLWNhc2UgLWUuZy4gUEFOUkctLCBhbmQg ZG9u4oCZdCBzZWUgd2h5IHdlIHdvdWxkIGVuZm9yY2UgZW5jYXBzdWxhdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGFibG8uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7E1C8E10DA954347A99A8A2FC1B79A77ciscocom_-- From nobody Tue Nov 6 00:11:20 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD71128A5C for ; Tue, 6 Nov 2018 00:11:18 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es 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 g8yfRH20eSeq for ; Tue, 6 Nov 2018 00:11:16 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B4B12D4F1 for <6man@ietf.org>; Tue, 6 Nov 2018 00:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1541491875; x=1542096675; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=3PliysDKmw0iD9ZRVXF+f 5Tr0Hpu/IN31r/orCwGaMo=; b=cLSEdfqPXzq0h8XdoaCcFm0x6k/3FAXwDvaJ5 63T91yK119rIVIdw3jU44ei8L1H3pePWEiVqrFNsA+kYn/ILGBw1ptVptPuc3rKF i2VR5Ozsno/q2AeVTNmiI5fNAn8rdAEWJbhO8a/mF70ERRTxqU1sXkkH85jejUkD j6myZE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 06 Nov 2018 09:11:15 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 06 Nov 2018 09:11:14 +0100 Received: from [31.133.128.251] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005945804.msg for <6man@ietf.org>; Tue, 06 Nov 2018 09:11:13 +0100 X-MDRemoteIP: 2001:67c:370:128:d0dc:690:511c:2ead X-MDHelo: [31.133.128.251] X-MDArrival-Date: Tue, 06 Nov 2018 09:11:13 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=184881054d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: 6man@ietf.org User-Agent: Microsoft-MacOutlook/10.10.3.181015 Date: Tue, 06 Nov 2018 15:11:07 +0700 Subject: draft-pref64folks-6man-ra-pref64-02 From: JORDI PALET MARTINEZ To: <6man@ietf.org> Message-ID: <79BEA68E-9E01-4579-BD5A-7001A1B5666D@consulintel.es> Thread-Topic: draft-pref64folks-6man-ra-pref64-02 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:11:19 -0000 As indicated in the mic ... I support this document. =EF=BB=BFI think I forgot to mention in previous comments about this docume= nt, that in the v6ops https://datatracker.ietf.org/doc/draft-ietf-v6ops-tra= nsition-ipv4aas, we decided to include in the preference order one more ite= m, that you may want to consider, so we get aligned in both documents. Chec= k requirement 464XLAT-7, so in section 5 of your document, you may want to = consider it. I also agree that we should have two options, one for /96 and one for varia= ble prefix length. Regards, Jordi =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Nov 6 00:12:18 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D205A130DCB for ; Tue, 6 Nov 2018 00:12:15 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qACYqsm8XTAK for ; Tue, 6 Nov 2018 00:12:13 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 37A8512D4F1 for <6man@ietf.org>; Tue, 6 Nov 2018 00:12:13 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id q5-v6so5478211pgv.0 for <6man@ietf.org>; Tue, 06 Nov 2018 00:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=M2weKHcgmLI+/mNC7ardOMAWzctNoyBeyjFQU69MFjQ=; b=qzG3rgWAUYq/2Gn+fo0VZRNxQMAiORau9aQRjkVHRLmuE3VEt4B4SQm8/T58MJp60a yJWbD4mfLqyu9Pn8rdZ0/zFJUSDjYuhLzTLnhh7WKVO09Q7BR44NNMqPlGMXssJzNAHu RKyAYE+HsfSkEZZbMn6lLdzGXExs2yeAo2BKwSuVpEJlc21S4A20jcj7jVJYT+ZUbay0 MbyN8hHnmRrReMjzz1oahcfQ2yGGLAhbtfod4dexfOf/HUrJ9YCBhTfbC4lleeUpA3Ew sVaT3GZVkU03w8SbRL+IeovqWO6LekXKm5XE2+BAKE5tITEWE2Rx4peAc4vv4OnY+kf0 jI2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=M2weKHcgmLI+/mNC7ardOMAWzctNoyBeyjFQU69MFjQ=; b=h0OjaLvHu2vLcbjk46yhu/LYlsG0+entnzfaBqsMK4ycvZF37gn0gwwR4fUxLELNO8 fDDUgj94YSsJlBUiK6aMQKJ8RrDuCHW5EXIC4uaIh2kHwdJ+ORNcjN58z2N9NY/FXGuZ 9WQnmXlecDUfX10rfj29ftqwgTZk4kq9D016ivjZJK3x5X+fh1hA2YYTtBl2Dr2YWiSl 8TpDKNjaQS+0XGE4Q6xQP+thyVV097jvipLTmO6lDYLKCWGBvlISZCArUnO/zupj6nOf A9RlRUdPIMWZHCxcHhFUaSgKZHdisxSFSo6QD5/aDeh2t4HtbUgYdLJ7bJLyqXKmw4U5 C8dw== X-Gm-Message-State: AGRZ1gLrXtPlbAf2c9vCi2agaGVd1AqPiJCR8j/7To/t9T9uTOy28z+6 iwtuYIemNGyQPIPqVFX1rRs= X-Google-Smtp-Source: AJdET5fx7xj6JoX+48p3yHYbSpuBKcKuiqGcirUrb4dcAER3WdPSCaV/bOqMq/uFno3ylSyrc251NQ== X-Received: by 2002:a62:1bcf:: with SMTP id b198-v6mr12885792pfb.102.1541491932689; Tue, 06 Nov 2018 00:12:12 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:ad25:5200:5cd1:e2dc? ([2001:67c:370:1998:ad25:5200:5cd1:e2dc]) by smtp.gmail.com with ESMTPSA id v1-v6sm30510162pfn.94.2018.11.06.00.12.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 00:12:11 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DE084D2E-3943-49B7-BCB5-26BC94991451"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: draft-pref64folks-6man-ra-pref64-02 Date: Tue, 6 Nov 2018 15:12:09 +0700 In-Reply-To: <79BEA68E-9E01-4579-BD5A-7001A1B5666D@consulintel.es> Cc: 6man@ietf.org To: JORDI PALET MARTINEZ References: <79BEA68E-9E01-4579-BD5A-7001A1B5666D@consulintel.es> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:12:16 -0000 --Apple-Mail=_DE084D2E-3943-49B7-BCB5-26BC94991451 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 6, 2018, at 3:11 PM, JORDI PALET MARTINEZ = wrote: >=20 > As indicated in the mic ... I support this document. Me three... --Apple-Mail=_DE084D2E-3943-49B7-BCB5-26BC94991451 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvhTNkACgkQEhdRnd2G P+Dofg//Yfi9zt7p41o80vyXJMRZhBnx14J9CRE/dNRcZqXuXb2yAh3mNJkc480J C+1kYFCqbb+vJUHxRavEAsaqAORq45T6O7SHnyL+3SFIyOQihcro7VALRNF1yWJk nbLwIJM9p2yEgQPEKouN6XIUzvEu4NOzwsafFIpAiZ9/pACIpVJe00BGsHAXngbE /uZTJGg0tmQa2jpog7SCAmLW95AxW7lKtEoNPz6SthR7uq5HCj2haTp+fFIuDiGS hRQbiqcDvC1l5KmYIblEo/CZHdrpGZSTTTaF+iv+f1jR6NtPCJoDq6w61KZz3j3L 3CAOmLsQR0HnW32ho1lp6u3MrMa1TLvwJHjkjGR6ZkR1qvZj3UrKviBoRtBNzE9b rThsUDo8URqKuUnJurQ1xQW7WnTYB40Qkk8wMj0+/k7R5hI1K1K7DuZd6R5BRpRO Vd5vaaQKmLA/+lTN6gjOtnBhqfUfr42HrLKxpO7M3uPzXTD5fj1y7Vs5GZi2qCgK SLuRrIbIQwJX31jhv6E9ZIk2gTgi1ifKoxuqrNAYM4YSMHgJCyQ6zHoJ1JgmmY6l yOH9TGdeeHCSVewaJyw/Sl3/m1+D6uc7nX/dA3ZvSYLQOlP2FiGFu8PJdCA/qTff ak4E+Qz+FhiokqUFm5N+EF1v7TINYr/ogBYA385bxYXBLSjJUZ0= =+1Dd -----END PGP SIGNATURE----- --Apple-Mail=_DE084D2E-3943-49B7-BCB5-26BC94991451-- From nobody Tue Nov 6 00:14:16 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C9712D4F1 for ; Tue, 6 Nov 2018 00:14:15 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 l69mOQWkwJGy for ; Tue, 6 Nov 2018 00:14:13 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 C71F2128A5C for ; Tue, 6 Nov 2018 00:14:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 74D36A803F6; Tue, 6 Nov 2018 00:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1541492053; bh=2bZUHr/HMkn6oKcYfPdIbCMnnqccbvAu6eb7oDbVWls=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FdHeaQRRfI0zaV0XG2gxJ5uJG5IWCLUp+3wpHN/tvzaXZAKTkmrwYA+1UvlTwuH6l LfPaUX+95OajPvNtjGMqi8EVSo+8Jr4JVVZ+ycvfcKAC63otXYNGa02zl9MB0LjPqA K6P3k2l+Hphaqr+gA1QQ5yw6fi7VnfKWUkTJojbk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-b9ce.meeting.ietf.org (dhcp-b9ce.meeting.ietf.org [31.133.185.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3A9F4A80359; Tue, 6 Nov 2018 00:14:11 -0800 (PST) Subject: Re: Question 6man SRH encaps only To: "Pablo Camarillo (pcamaril)" , "Darren Dukes (ddukes)" Cc: "ipv6@ietf.org" References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> From: "Joel M. Halpern" Message-ID: <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> Date: Tue, 6 Nov 2018 15:14:08 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:14:16 -0000 Yes, I am saying that we should always use IP(SRH(IP(...))). The reason is simplicity and robustness. As we have already discussed, the host has to be prepared to generate that form and process that form whenever it is talking to someone outside the SR Domain. Having two ways of encoding the same thing, and two processing paths for generating / handling the same thing, introduces complexity. If there is a strong benefit (beyond the number of bits in the packet), I would like to hear about that benefit. I can easily believe I missed something. In the absence of a benefit, choices are in and of themselves harmful. Yours, Joel On 11/6/18 3:08 PM, Pablo Camarillo (pcamaril) wrote: > Hi Joel, > > Regarding your question on 6man about the SRH and allowing only > encapsulation: > > There are two open-source host implementations of the SRH (Linux Kernel, > FD.io VPP). I wrote the code for SRH in the latter. > > A---1---2---B > > (A and B are hosts) > > In one of the use-cases host A has awareness of the transport network. > > Host A generates and sends a packet of the form IP(SRH(TCP(...))) where > the SRH contains segments <1,2,B>. > > Note that B is an interface address on host B. > > Do you believe that in this case the host should send > IP(SRH(IP(TCP(...))))? If yes, why? > > I think this is a relevant use-case -e.g. PANRG-, and don’t see why we > would enforce encapsulation. > > Thanks, > > Pablo. > From nobody Tue Nov 6 00:20:05 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3389128A6E for ; Tue, 6 Nov 2018 00:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 eYP1zQIGujZW for ; Tue, 6 Nov 2018 00:20:02 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 4A273128A5C for <6man@ietf.org>; Tue, 6 Nov 2018 00:20:02 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C0B613ABD06 for <6man@ietf.org>; Tue, 6 Nov 2018 08:20:01 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8A416160099 for <6man@ietf.org>; Tue, 6 Nov 2018 08:20:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 74C4E160097 for <6man@ietf.org>; Tue, 6 Nov 2018 08:20:01 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Gxeiqdcik28O for <6man@ietf.org>; Tue, 6 Nov 2018 08:20:01 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id F104B160050 for <6man@ietf.org>; Tue, 6 Nov 2018 08:20:00 +0000 (UTC) From: Mark Andrews Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: DNS64 pref option. Message-Id: Date: Tue, 6 Nov 2018 19:19:58 +1100 To: 6man@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:20:04 -0000 I want a option to be able to configure name servers that do DNS64 = inside a network with local dual stack. This requires knowing what IPv4 = addresses are not to be translated and which IPv6 addresses to ignore = and perform DNS64 synthesis on the IPv4 address. Both of these ACLs can = be provided at a single name with a APL record. For CLAT you effectively get this because you don=E2=80=99t route local = IPv4 traffic through the CLAT as the host has more specifics, regardless of whether it is a host or the = border CPE. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 6 00:23:11 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D93130F3C; Tue, 6 Nov 2018 00:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 ufR0rdCQRVFs; Tue, 6 Nov 2018 00:22:52 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0113.outbound.protection.outlook.com [104.47.0.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3397130E86; Tue, 6 Nov 2018 00:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gORENhim7VHXGAH3WOYyThI0s0Hjxn9cFaNmyYJJLqs=; b=Ueq7TRCHBQ+zP8BmeX1NY6UGBdeIiBJusrjwD/GexpaQIGahWNMSXfXb+z4cCd8Ajrv2fGcn0tsH/bJ0R3yJsxVwkWIDWJgsmVy1UhPljn2IwtZxNRIkUB4+0fvgqzTUzuLOfHanC9VN6WNp+ZPtYETJoku3eePiVqxCKbnFMWU= Received: from DB6PR07MB3477.eurprd07.prod.outlook.com (10.175.234.32) by DB6PR07MB4278.eurprd07.prod.outlook.com (10.168.23.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.8; Tue, 6 Nov 2018 08:22:49 +0000 Received: from DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686]) by DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686%2]) with mapi id 15.20.1294.034; Tue, 6 Nov 2018 08:22:49 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Gert Doering CC: Linda Dunbar , "idr@ietf.org" , "ipv6@ietf.org" , "int-area@ietf.org" , Fred Baker Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AQHUdPQP+ZmmSSJuak+m74M0Ps0ZxKVBaBCAgACYwgCAAGC+gIAAfaWA Date: Tue, 6 Nov 2018 08:22:49 +0000 Message-ID: <58297F7F-5B02-495B-9E2C-87871342E317@nokia.com> References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> <20181105165959.GB11393@Space.Net> <4B2F3673-5106-4914-B79F-F3C44013ED06@nokia.com> <20181106075259.GM11393@Space.Net> In-Reply-To: <20181106075259.GM11393@Space.Net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181104 x-originating-ip: [131.228.32.172] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB4278; 6:VrqW9G36NWbvVDxMU7mYI8SIh9OrZT53qIIPjqHXOjkwOfyTy7xXUnyNF/goQ98qCz27tvIi53bRGWRzOWpH9Qm7AOYt1fw3nrfTXPGAhHvwaitrpGsj7iFkl3sdItrxg3Gpw9VK8ZOcoa1mDNWG75dr1jVqsWQOOc/rmfLQPEw3SAV1sdypTX17sEJumkaN0kVrMbOKHBKsxWJIuhT331qsXChT7JltJJj2D8pudbotweCZtY3JQ8+h6QvjamZfpvE6PKozlmFPtQYQAyqUNgHnhM7AyrHll8NbOFHAw3LrQTEsz8yVW8mvlKFyJTrZhemB1D+evel/zT9fLPesxjdPOrMj01A36ut28UFonZn+L4aFiC1JMtyrkC41X9XihY3PAjAp8zGLf26GaLYah9QmbSesVfEHbYKyY8ewtBgmFee+OiYRWOhJ74wMB/vaz8kLigNvZ9NIluO53SF8UQ==; 5:kCdRNnAb40v8bZE1c/iRr6iaSl2LKSCGQIunuvMpcLMrHiY9qpru69H0oX1DigzLd1QK0p6H7ug83GJZVG34k2I8rHdm/WpivyH5Pzj/tOCz5t+4UzCvvGqIQdv65J2y1D55BIlu4h3iks2vBQUUlXuJKHua6/5r3pzZUj9v9nY=; 7:1i9dXGscajXuUmMCriKKKYpAsqIrjP4Dc5lDa0OqbUeVufZprWh8qk4m2LfzsdiQXKfjhMdbGU46PeHIe9420gfdRMKFnTDSEac2NZ8lM2XhSQi5dGlvitsx8TyWclvY553IpfV/v6r2QbdvDVOm2w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 189948cf-af00-48c1-c3a5-08d643c109d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB6PR07MB4278; x-ms-traffictypediagnostic: DB6PR07MB4278: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231382)(11241501184)(806099)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB6PR07MB4278; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB4278; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(376002)(346002)(366004)(189003)(199004)(186003)(478600001)(2906002)(83716004)(86362001)(33656002)(76176011)(68736007)(5660300001)(2900100001)(26005)(102836004)(6506007)(36756003)(2616005)(11346002)(446003)(486006)(476003)(256004)(14444005)(99286004)(81156014)(54906003)(81166006)(6512007)(6436002)(25786009)(8676002)(97736004)(93886005)(82746002)(316002)(53936002)(58126008)(8936002)(6246003)(71190400001)(71200400001)(105586002)(229853002)(106356001)(3846002)(7736002)(305945005)(66066001)(6116002)(4326008)(39060400002)(6916009)(14454004)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB4278; H:DB6PR07MB3477.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: J0pgAvZw1Ae7qJKVvoBWJi69IFe33v53Lbcv9SqKrPxswVok9y45gKyfbuQgZlOE27pi5GIxC+RwCI4cwCiaC8T/13Xhvn3aXyW+wGlgCDyNkn7BJEGFRPhFjy3Q3WqQW+3zDdKJdGZhXPMexvxwW5pTYaaUmiVVcgbizTbmASlNro3h91vpKPaDaSnwuP4RMUrqfEoGBaQYFemMJRZE/DIH04JhRk+e1OeUElM0cF2wvsZhdLX7ZV9+FDK3ld0PSXwMTRSqWZC9Tj2Ta6VydGfILVTQfn1+qC8SuP3AAh3UaHi4Mfb4Qisq4Ng09k0gvfU8bpRycKFKjEyEzYnOU+lC2C+6g6d83NgVGwynOZU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <888C83479F2C40408305E78E2D297F3F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 189948cf-af00-48c1-c3a5-08d643c109d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 08:22:49.0298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB4278 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:23:00 -0000 V2UgZG9u4oCZdCBwZXJmb3JtIGFueSBOQVQgb3BlcmF0aW9uLiBMZXQncyBmaXJzdCBkaXNjdXNz IHRoZSBlbmNhcHN1bGF0aW9uOg0KSW4gU0QtV0FOIHRoZXJlIGlzIGFuIElQIHR1bm5lbGluZyBv ZiBzb21lIHNvcnQgKHRoZXJlIGFyZSBzZXZlcmFsIG9wdGlvbnMgYnV0IG5vdCByZWxldmFudCBo ZXJlKS4gU28gd2UgaGF2ZSBhbiBpbm5lciBwYXlsb2FkIHdoaWNoIGNhbiBiZSB2NCBvciB2NiBh bmQgZ29lcyBlbmQgdG8gZW5kLCB0aGUgaW5uZXIgcGF5bG9hZCBpcyBlbmNhcHN1bGF0ZWQgaW4g YW4gb3V0ZXIgSVAgdHVubmVsLg0KDQpTbyB3aGF0IGhhcHBlbnMgaXMgdGhlIGZvbGxvd2luZy4g SSBtYWtlIGFic3RyYWN0aW9uIG9mIGlubmVyIHBheWxvYWQNCg0KU0QtV0FOIENQRTIgKHY0KQ0K U0QtV0FOIENQRTEgKHY0KSA8LS0tLS0tLS0tLS0gdjQgLS0tLS0tLS0tPiBHVyA8LS0tLS0tLS0t LS0tLS0tLS12NiAtLS0tLS0tLS0tLS0tID4gU0QtV0FOIENQRTModjYpLg0KDQpVcHN0cmVhbSB0 cmFmZmljIGZyb20gU0QtV0FOIENQRTENCnNyYy1pcCB2NDogQTEsIGRzdC1JUCB2NCBCMSAtLS0t LS0tLS0tLS0tLS0+IG1hcHBpbmcgPCBzcmMtSXAgdjY6IEMxLCBkc3QtaXAgdjYgRDEgLS0tLS0+ IA0KDQpVcHN0cmVhbSB0cmFmZmljIGZyb20gU0QtV0FOIENQRTINCnNyYy1pcCB2NDogQTIsIGRz dC1JUCB2NCBCMSAtLS0tLS0tLS0tLS0tLS0+IG1hcHBpbmcgPCBzcmMtSXAgdjY6IEMxLCBkc3Qt aXAgdjYgRDEgLS0tLS0+DQoNClNvIGlycmVzcGVjdGl2ZSBvZiB3aGljaCBzcmMtQ1BFIDEgb3Ig MiBpcyBzZW5kaW5nIHRvIHRoZSB2NiBTRC1XQU4gQ1BFMyB3aWxsIHVzZSB0aGUgc2FtZSBzcmMv ZHN0IHY2IGFkZHJlc3MNCg0KV2l0aCBOQVQ2NCBldmVuIHN0YXRlbGVzcyB0aGUgc3JjLUlQIG9y IHNyYy1wb3J0IHdpbGwgYmUgZGlmZmVyZW50IHRvIGVuc3VyZSB5b3UgY2FuIG1hcCB0aGUgcmV2 ZXJzZS4NClRoaXMgaXMgYWxzbyB1c2VkIHRvIG1hcCBwcml2YXRlIElQdjQgdG8gcHVibGljIElw djQsIGV0YyBhbmQgbWFueSBvdGhlciBvcGVyYXRpb25zLg0KDQoNCu+7v09uIDA2LzExLzIwMTgs IDE0OjUzLCAiR2VydCBEb2VyaW5nIiA8Z2VydEBzcGFjZS5uZXQ+IHdyb3RlOg0KDQogICAgSGks DQogICAgDQogICAgT24gVHVlLCBOb3YgMDYsIDIwMTggYXQgMDE6MDY6NTJBTSArMDAwMCwgSGVu ZGVyaWNreCwgV2ltIChOb2tpYSAtIEJFL0FudHdlcnApIHdyb3RlOg0KICAgID4gRXZlbiBhIE5B VDY0IGlzIG5vdCBuZWVkZWQuIFdoYXQgd2UgZG8gbm93IGlzIHdlIGdvIHRvIGEgR1cgKGxldHMg Y2FsbCBpdCBsaWtlIHRoaXMgZm9yIG5vdykgYW5kIHRoZSBHVyByZXdyaXRlcyB0aGUgb3V0ZXIg aGVhZGVyIG9mIHRoZSB0dW5uZWwgc3JjSVAgYW5kIGRzdElQIGZyb20gdjQgdG8gdjYgb3Igdmlj ZSB2ZXJzYS4gSXQgaXMga2luZCBvZiBkZWNhcC9lbmNhcCBvcGVyYXRpb24gb24gdGhlIG91dGVy IGhlYWRlciBhcyBpZiB5b3UgdGVybWluYXRlIHRoZSB0dW5uZWwgYW5kIHJlaW5pdGlhdGUgdGhl IHR1bm5lbC4gTm8gTkFUNjQgcmVxdWlyZWQuDQogICAgPiANCiAgICANCiAgICBTbyBob3cgZXhh Y3RseSBpcyB0aGlzIGRpZmZlcmVudCBmcm9tIGEgTkFUNjQ/DQogICAgDQogICAgIllvdSB0YWtl IG9mZiB0aGUgSVB2NCBoZWFkZXIsIHB1dCBvbiBhbiBJUHY2IGhlYWRlciwgYW5kIHJlbWVtYmVy IHdoZXJlDQogICAgdGhlIHJlc3BvbnNlIHBhY2tldHMgbmVlZHMgdG8gYmUgc2VudCB0byINCiAg ICANCiAgICBJZiB5b3UgcHJlY29uZmlndXJlIHRoZSBtYXBwaW5nLCBpdCdzIHN0aWxsIGEgTkFU NjQgOi0pDQogICAgDQogICAgR2VydCBEb2VyaW5nDQogICAgICAgICAgICAtLSBOZXRNYXN0ZXIN CiAgICAtLSANCiAgICBoYXZlIHlvdSBlbmFibGVkIElQdjYgb24gc29tZXRoaW5nIHRvZGF5Li4u Pw0KICAgIA0KICAgIFNwYWNlTmV0IEFHICAgICAgICAgICAgICAgICAgICAgIFZvcnN0YW5kOiBT ZWJhc3RpYW4gdi4gQm9taGFyZCwgTWljaGFlbCBFbW1lcg0KICAgIEpvc2VwaC1Eb2xsaW5nZXIt Qm9nZW4gMTQgICAgICAgIEF1ZnNpY2h0c3JhdHN2b3JzLjogQS4gR3J1bmRuZXItQ3VsZW1hbm4N CiAgICBELTgwODA3IE11ZW5jaGVuICAgICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAoQUcgTXVl bmNoZW4pDQogICAgVGVsOiArNDkgKDApODkvMzIzNTYtNDQ0ICAgICAgICAgVVN0LUlkTnIuOiBE RTgxMzE4NTI3OQ0KICAgIA0KDQo= From nobody Tue Nov 6 00:26:19 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99971128A5C for ; Tue, 6 Nov 2018 00:26:17 -0800 (PST) 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, 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 2yYKTTL6VES8 for ; Tue, 6 Nov 2018 00:26:15 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D6A128A6E for ; Tue, 6 Nov 2018 00:26:14 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5BFE78D4A24D for ; Tue, 6 Nov 2018 08:26:13 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 90D20D1F8F3 for ; Tue, 6 Nov 2018 08:26:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id KuDDqs4Fr7fL for ; Tue, 6 Nov 2018 08:26:10 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B62E3D1F8F7 for ; Tue, 6 Nov 2018 08:26:09 +0000 (UTC) From: "Bjoern A. Zeeb" To: "IETF IPv6 Mailing List" Subject: Re: Comments on IPv4-only flag document Date: Tue, 06 Nov 2018 08:26:09 +0000 X-Mailer: MailMate (2.0BETAr6126) Message-ID: <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:26:18 -0000 On 6 Nov 2018, at 7:42, Lorenzo Colitti wrote: > Playing back my comments at the mike: > > 1. I don't think it's useful to say that IPv4 should be enabled if the > default router lifetime goes to zero. The default router lifetime > going to > zero is a normal occurrence, e.g., when the router loses uplink > connectivity. I would say that the flag is valid in all cases. If the > network says it doesn't have IPv4, and it doesn't have working IPv6, > the > host can always disconnect, try another network, or ignore the flag. Or use link-local ( and I am not saying v4 or v6 ). The latest draft no longer says to turn IPv4 back on. There are to cases I see in the draft (both in section 7): (a) if a host goes from receiving all RAs with the flag set to 1 to a state with an RA that has the flag set to 0, “IPv4 operations MAY be started” (no longer SHOULD) (b) “If the lifetimes of all the routers on the link subsequently expire, then the host state for the link is not IPv6-Only.” Which doesn’t say what to do (but I’d probably do the same as above). It’s “implementors choice” and that’s probably good as some might want to try for simplicity and others might say “I have great callback mechanisms and unless someone asks for IPv4 I’ll not change anything”. As you said “over-specifying” will never fit for everyone. People will realise that once they were working IPv6-only going back to IPv4 makes little sense. > 2. We should not say that the flag means that IPv6 is "the only ip > version > on the link". We don't want this draft to rule out new versions of IP. > Maybe instead of saying "no other versions of Internet protocol" we > can say > "no lower-numbered version of the Internet protocol is in use". And when we re-use 1235 that will not help either. This will be the “Keep this new stuff out of my network” option so many people insisting on having these days. If they can’t turn IPv4 and DHCPv4 off currently, they won’t turn that flag off either. Because it’s too hard. Let them suffer by living in their legacy world and move forward. In addition Section 4 is hinting very good at “we mean no IPv4 here”. > 3. We should say that this flag has no effect if IPv4 configuration > has > already succeeded (e.g., the host has obtained a valid configuration > from > DHCPv4). This should address many of the security questions that have > been > raised. The latest version of the draft has changed to “MUST” for “Administrators MUST only use this mechanism if they are certain that the link is IPv6-Only. For example, in cases where there is a need to continue to use IPv4, when there are intended to be IPv4-only hosts or IPv4 routers on the link, setting this flag to 1 is a configuration error.” That is essentially what you are asking for. “If there is working IPv4 (services|forwarding) this flag is a configuration error”. As a host-side implementor I’d read this as “I MAY keep doing IPv4 in this case”. /bz From nobody Tue Nov 6 00:34:19 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166B5130DCB for ; Tue, 6 Nov 2018 00:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 jtE79ZJXBdj5 for ; Tue, 6 Nov 2018 00:34:14 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 9357412D4F1 for <6man@ietf.org>; Tue, 6 Nov 2018 00:34:14 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id h19-v6so8603485iog.9 for <6man@ietf.org>; Tue, 06 Nov 2018 00:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6oGlt8DRlVijqyG9fezPnUTEFlPtrBN6v2inh5QVj7E=; b=f8+ejEhACVT4NOwGAgK6P8MvdF/7w21ec6TZ6IwfuCAy9Lzkp6OTlLLBu0aGZhdSMe kWyBTUWez0KgPb+SaEIThJmfAFwfzFujuQUoKDZaaCPfwBK20HiZfAYsndn6PxEqZ9n+ 3RsuitlK52N0KxQH4f7jMq/MvQQJPMZkpd63M6UDkJZPvdkdZMGDt0WUyMdZbok/WeMt Q8TPc6MalJnIAgh6IkJGSpjeMfs7VBVchSxl0SJ+68xkXxl+hFxFQT3LbX+16UoxInQc Fob0a7xVO/SjlSwInIK2K/76/EX4LymvyHfVFxlx3yuiojjYvnGW0FP13rKXZaEwqtJB FhfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6oGlt8DRlVijqyG9fezPnUTEFlPtrBN6v2inh5QVj7E=; b=tl4i4nD4ukxdajIGyupl+CXHYLm/siXVE9Eest/EBbP1svkhDHYYofZ5TNjjqWosIp 8DgRzgMS0hKB1CY+QacI7m/Mu+u2xFjeOeabUz2O1zYMv51Bkj36YSs5GmhjWA113USI 1hMrQc9AYb4WbVtf7D0EiAd6BWvXz4WLjrstAG8NfSTh6BeaDVEfg6yXIyeuFnD/oq54 IPH6Qid+rAMiv3/b9lO6ob85iBq17W4mDsas7w5Dp+oKgIegeIPAiinqIZ0emoTfEVur Nycm8VAfB5GuZtwq4stnfyewVFpUVI3aAHYnlKdMyLn3sMH2H0WL7DZk6Q4XxEbdwpYZ dRSw== X-Gm-Message-State: AGRZ1gJFnG3FSSP9Mb+E7TJHKxbUsWT68Y+pau/de+n6EfvjGNjAcQne zBJTGik0TJqoytrXHoPmj9IMXnrMlIaUN6FXm805U+H3KhWPAc3n X-Google-Smtp-Source: AJdET5er2eLWTC/RC+x2A7HVrb4BkDvOFUanu+Gnku8x019VUMIIa90cm8b+l809jPlci0cfpjq1FXtEgWeBXIcZelk= X-Received: by 2002:a6b:c743:: with SMTP id x64-v6mr19666573iof.14.1541493253306; Tue, 06 Nov 2018 00:34:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Tue, 6 Nov 2018 15:34:01 +0700 Message-ID: Subject: Re: DNS64 pref option. To: Mark Andrews Cc: 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000c9f89e0579fadd43" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:34:18 -0000 --000000000000c9f89e0579fadd43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For more information, the proposal was originally made here . I'm not sure whether it's worth doing this, because: 1. It complicates the implementation. 2. It can substantially increase the size of the option (looks like it's at least 8 bytes per prefix), and the space available in an RA packets i= s quite limited. 3. RFC 3123 is experimental (since 2001), whereas this draft is intended to be a standards track document. 4. AIUI, the option is not useful on an IPv6-only network. It is only useful in the case where the host has an IPv4 address. In that case the network might as well provide IPv4. Mark, do you have a use case for #4? It's clear that this would be useful DNS64 translator that provides service to other hosts, but for the case where the host is just doing DNS64 synthesis for itself, the use case seems less clear. On Tue, Nov 6, 2018 at 3:20 PM Mark Andrews wrote: > I want a option to be able to configure name servers that do DNS64 inside > a network with local dual stack. This requires knowing what IPv4 address= es > are not to be translated and which IPv6 addresses to ignore and perform > DNS64 synthesis on the IPv4 address. Both of these ACLs can be provided = at > a single name with a APL record. > > For CLAT you effectively get this because you don=E2=80=99t route local I= Pv4 > traffic through the CLAT as the > host has more specifics, regardless of whether it is a host or the border > CPE. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000c9f89e0579fadd43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For mor= e information, the proposal was originally made here. I'm n= ot sure whether it's worth doing this, because:
<= ol>
  • It complicates the implementation.
  • It can substantially incr= ease the size of the option (looks like it's at least 8 bytes per prefi= x), and the space available in an RA packets is quite limited.
  • RFC = 3123 is experimental (since 2001), whereas this draft is intended to be a s= tandards track document.
  • AIUI, the option is not useful on an I= Pv6-only network. It is only useful in the case where the host has an IPv4 = address. In that case the network might as well provide IPv4.
  • Mark, do you have a use case for #4? It's clear that this would be use= ful DNS64 translator that provides service to other hosts, but for the case= where the host is just doing DNS64 synthesis for itself, the use case seem= s less clear.

    <= div dir=3D"ltr">On Tue, Nov 6, 2018 at 3:20 PM Mark Andrews <marka@isc.org> wrote:
    I want a option to be able to configure name servers that d= o DNS64 inside a network with local dual stack.=C2=A0 This requires knowing= what IPv4 addresses are not to be translated and which IPv6 addresses to i= gnore and perform DNS64 synthesis on the IPv4 address.=C2=A0 Both of these = ACLs can be provided at a single name with a APL record.

    For CLAT you effectively get this because you don=E2=80=99t route local IPv= 4 traffic through the CLAT as the
    host has more specifics, regardless of whether it is a host or the border C= PE.

    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE= RNET: marka@isc.org<= br>
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --000000000000c9f89e0579fadd43-- From nobody Tue Nov 6 00:37:42 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C26130F25 for ; Tue, 6 Nov 2018 00:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 7aXSTyxDSw5B for ; Tue, 6 Nov 2018 00:37:30 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 EBA72130E43 for ; Tue, 6 Nov 2018 00:37:29 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1gJwrX-0000GkC; Tue, 6 Nov 2018 09:37:27 +0100 Message-Id: To: ipv6@ietf.org Cc: "Bjoern A. Zeeb" Subject: Re: Comments on IPv4-only flag document From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> In-reply-to: Your message of "Tue, 06 Nov 2018 08:26:09 +0000 ." <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> Date: Tue, 06 Nov 2018 09:37:27 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:37:39 -0000 > (b) If the lifetimes of all the routers on the link subsequently > expire, then the host state for the link is not IPv6-Only. Which > doesnt say what to do (but Id probably do the same as above). Not switching back makes for a really nice attack vector on an IPv4-only network without RA-guard: wait an incoming DHCPv4 discover and send an RA with the IPv6-only set. Brilliant. It's great to have a draft that just consists of a new attack vector and nothing else. From nobody Tue Nov 6 00:39:59 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7278130DD4 for ; Tue, 6 Nov 2018 00:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 biJrvKJEr1NK for ; Tue, 6 Nov 2018 00:39:56 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 027A612D4F1 for ; Tue, 6 Nov 2018 00:39:56 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id e11so13285725itl.5 for ; Tue, 06 Nov 2018 00:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f0dyx8a5qKC0lU6oa0l+JKdJgMlEoDANN/aj9zoJ0WI=; b=QWGSvrmA2hTCQ7yW1vxMrbRRBIoGCnhmx50o1BIK/LPuvCG7d0A2RYFIjFFT6x7PeI 90w7Ylg+H1VRKFF6vhUwTgpqr/mrOibpQ6lrVL5Y6XXHmjVPva/6q6NWgjYDYZqAzx0P iVDM00Vy6Du8WolqvHWaUbk5vOjk7Z5pDjUbk0x5GSIIYU0rpqhjETdzu6UhWjYLC3rw fX/j3NFW9uvwbVZp19P3OL2jHMRte3DweRdep+gZyfStBh5MLZa8QYipjM/I9oytaKn3 z48EzRphcCEE+epyMT0tDRJ9QJceyApiNtVHosER01zw+FLfgZwWD6kuBC5s9fnQuT0T HIvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f0dyx8a5qKC0lU6oa0l+JKdJgMlEoDANN/aj9zoJ0WI=; b=Io+Uao/EM0tU4jEFKr6iQ3vD0J0eBuT8J4F/73/LA71CKyi1xWydNcQ79tRIepSASK MmzffPMbYVKL+3qceqzXdLWZWbCEzOe7E1Sb6Pc7hq5rkpC16BWfXJfcZ0tIZCgUwt4Q IlLVhC/7al/2eBCjuKvomHT9pW/aMskhVTb30Yicp2Yd5tvQ2TpSNlqHJOHjAB/zCDDw DTixuNz27JRUXFSqw2XxlPLbzxzRfv774YeE6kU7JMebO8K4SkQZ0Hc752e66xLQHsoL FeLMcCbnZwxg6wH5WlFB0vmHpTX7f5ke1jD+PBIi4UBQiOH1bMPlDibGshiNJ1V4nfXJ 4yWA== X-Gm-Message-State: AGRZ1gJadAhAsX15as2PjtR0InbETS27I4mqbxUHXKEd1d7mL3Xwuqhy 61uFfBEr8MMl+8E/1iF2zotlUc6nnHnciDtSQ8xkR/l/1qzLpQ== X-Google-Smtp-Source: AJdET5cAkBYjpU+bZixE+dfw30gHMcisa0yhepqTPLE5HpyBnuaBiKFQkbEu8iFkfhlSJqWb9ubPR18vNj+/qeB01k4= X-Received: by 2002:a02:41d2:: with SMTP id n79-v6mr23736945jad.112.1541493594938; Tue, 06 Nov 2018 00:39:54 -0800 (PST) MIME-Version: 1.0 References: <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> In-Reply-To: <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> From: Lorenzo Colitti Date: Tue, 6 Nov 2018 15:39:40 +0700 Message-ID: Subject: Re: Comments on IPv4-only flag document To: "Bjoern A. Zeeb" Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="00000000000026e7f20579faf28e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:39:58 -0000 --00000000000026e7f20579faf28e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2018 at 3:26 PM Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > 3. We should say that this flag has no effect if IPv4 configuration > > has > > already succeeded (e.g., the host has obtained a valid configuration > > from > > DHCPv4). This should address many of the security questions that have > > been > > raised. > > The latest version of the draft has changed to =E2=80=9CMUST=E2=80=9D for > =E2=80=9CAdministrators MUST only use this mechanism if they are certa= in that > the link is IPv6-Only. [...] > > That is essentially what you are asking for. =E2=80=9CIf there is workin= g > IPv4 (services|forwarding) this flag is a configuration error=E2=80=9D. = As a > host-side implementor I=E2=80=99d read this as =E2=80=9CI MAY keep doing = IPv4 in > this case=E2=80=9D. > No, it's not what I'm asking for. That text doesn't address the case where the RA was sent by an attacker on an IPv4-only network that is currently working just fine. That is the case for the majority of networks today. Such networks very likely don't have RA guard because they have never had a need for it. --00000000000026e7f20579faf28e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Tue, Nov 6,= 2018 at 3:26 PM Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:
    > 3. We should say that this flag has no effect if IPv4 configuration > has
    > already succeeded (e.g., the host has obtained a valid configuration <= br> > from
    > DHCPv4). This should address many of the security questions that have =
    > been
    > raised.

    The latest version of the draft has changed to =E2=80=9CMUST=E2=80=9D for =C2=A0 =C2=A0=E2=80=9CAdministrators MUST only use this mechanism if they a= re certain=C2=A0that
    =C2=A0 =C2=A0 the link is IPv6-Only.=C2=A0 [...]

    That is essentially what you are asking for.=C2=A0 =E2=80=9CIf there is wor= king
    IPv4 (services|forwarding) this flag is a configuration error=E2=80=9D.=C2= =A0 =C2=A0As a
    host-side implementor I=E2=80=99d read this as =E2=80=9CI MAY keep doing IP= v4 in
    this case=E2=80=9D.

    No, it's not wh= at I'm asking for. That text doesn't address the case where the RA = was sent by an attacker on an IPv4-only network that is currently working j= ust fine. That is the case for the majority of networks today. Such network= s very likely don't have RA guard because they have never had a need fo= r it.
    --00000000000026e7f20579faf28e-- From nobody Tue Nov 6 00:43:52 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7070130DD4 for ; Tue, 6 Nov 2018 00:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Nxiz1azh04xa for ; Tue, 6 Nov 2018 00:43:48 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 A30C3128A6E for <6man@ietf.org>; Tue, 6 Nov 2018 00:43:48 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 6413A3ABD01; Tue, 6 Nov 2018 08:43:48 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 03DF1160050; Tue, 6 Nov 2018 08:43:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CD19C160097; Tue, 6 Nov 2018 08:43:44 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qNksBngWop_M; Tue, 6 Nov 2018 08:43:44 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 0ECF7160050; Tue, 6 Nov 2018 08:43:43 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: DNS64 pref option. From: Mark Andrews In-Reply-To: Date: Tue, 6 Nov 2018 19:43:41 +1100 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:43:50 -0000 > On 6 Nov 2018, at 7:34 pm, Lorenzo Colitti wrote: >=20 > For more information, the proposal was originally made here. I'm not = sure whether it's worth doing this, because: > =E2=80=A2 It complicates the implementation. > =E2=80=A2 It can substantially increase the size of the option = (looks like it's at least 8 bytes per prefix), and the space available = in an RA packets is quite limited. > =E2=80=A2 RFC 3123 is experimental (since 2001), whereas this = draft is intended to be a standards track document. > =E2=80=A2 AIUI, the option is not useful on an IPv6-only = network. It is only useful in the case where the host has an IPv4 = address. In that case the network might as well provide IPv4. For local ipv6-only only the filtering of IPv6 is useful and possibly = could be skipped to just use well known values to skip. > Mark, do you have a use case for #4? It's clear that this would be = useful DNS64 translator that provides service to other hosts, but for = the case where the host is just doing DNS64 synthesis for itself, the = use case seems less clear. The host still needs to know what addresses to not translate at the = application level so long as we are locally dual stack. You don=E2=80=99t= want to send local traffic for IPv4 only local devices through the = NAT64. > On Tue, Nov 6, 2018 at 3:20 PM Mark Andrews wrote: > I want a option to be able to configure name servers that do DNS64 = inside a network with local dual stack. This requires knowing what IPv4 = addresses are not to be translated and which IPv6 addresses to ignore = and perform DNS64 synthesis on the IPv4 address. Both of these ACLs can = be provided at a single name with a APL record. >=20 > For CLAT you effectively get this because you don=E2=80=99t route = local IPv4 traffic through the CLAT as the > host has more specifics, regardless of whether it is a host or the = border CPE. >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 6 00:53:08 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1442A130E1B for ; Tue, 6 Nov 2018 00:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Qnr9YdAXuk7K for ; Tue, 6 Nov 2018 00:52:59 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 86F8B130E01 for <6man@ietf.org>; Tue, 6 Nov 2018 00:52:59 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id c6-v6so8632211iob.11 for <6man@ietf.org>; Tue, 06 Nov 2018 00:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3wNTKjXtOCcN03FlcST0S+594z72HiI2XxHiucxdQ0g=; b=UObGMKTA+nwbheV2ufhOXC/55sO9IBBrzGqAZA01dqHGd+eSdiY2oJzadbada/zVDG AtTWGs+sVt7rUgadpahBZGIdKRY/iIGQfPtoA7ig/89LTRAebBTRBfjco0+wbDCtEAvu N7pIEAluqC2dLMiaJSaa/vrY3q4Bf/M12HeeVXLe6DfuQM4T3rDIHUy2p/uwgdTZ17hf wt1W8060Koej8BcABjxgHunLCOgwUInrBrLB1lPk6cUJj4jzeQwEue9dWkcjPbU6iTDB DwE0zX2LMMpOgxfJeUsyxx6Kn0o1XL31Elkd5LAgRpZD9KpDcNL1gHrK3DscncT5RqNO t1Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3wNTKjXtOCcN03FlcST0S+594z72HiI2XxHiucxdQ0g=; b=dAC/vMbI7oGZRxX/PtSrdOHh1h1fANsTjjvQCUmuQ9Y8U6gTCg7lXXaYNFYFsoRpFl CsuNYFnaMVR2LHQ2bbn/iQUmYSUX1HJEpbKOfFRxCuT6rIoTO/8LOMX4a4WlQai1jDW+ vuaBYPQAoGW8rcoT3ri7FLff88IYnQ251AA8635uUgZwKKLsTyAbsiolx330LgMFkVyK HKoVfUqFxsfSMpRLX0J4HKIgXNajstceDJz0Bo82D2EUYovwGtk+gxgSKKLn3+oOvb74 eRrZgVymgCgnTSqKWJrp7wr4tFgMMIXP5ieHDxKkwxmw7iw0/q8AXCPyrJk3nfr+lFBC tw1w== X-Gm-Message-State: AGRZ1gIAVWYE/Dz6LuweruScT3IvL49crFaUjage1RcAlwQwWggkjAyE 2CfvfGI4h1GqGPIAAd3mjw32TPxpi+KLJgLbry0DNKJ1BOpNJg== X-Google-Smtp-Source: AJdET5c8V1Jcm510Fz0IITcl1zha7PnNHapgoXZRJm3Otnv5JIFUeaUDllnrzD6LLETLPYvup+AKSUF9RR0B2gGl4xE= X-Received: by 2002:a6b:c743:: with SMTP id x64-v6mr19705146iof.14.1541494378535; Tue, 06 Nov 2018 00:52:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Tue, 6 Nov 2018 15:52:44 +0700 Message-ID: Subject: Re: DNS64 pref option. To: Mark Andrews Cc: 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000dba19e0579fb2047" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:53:03 -0000 --000000000000dba19e0579fb2047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2018 at 3:43 PM Mark Andrews wrote: > > =E2=80=A2 AIUI, the option is not useful on an IPv6-only network.= It is > only useful in the case where the host has an IPv4 address. In that case > the network might as well provide IPv4. > > For local ipv6-only only the filtering of IPv6 is useful and possibly > could be skipped to just use well known values to skip. > What would be the purpose of such filters? A host that supports 464xlat is just going to get the A record and send the packet to the NAT64 anyway, no? > Mark, do you have a use case for #4? It's clear that this would be useful > DNS64 translator that provides service to other hosts, but for the case > where the host is just doing DNS64 synthesis for itself, the use case see= ms > less clear. > > The host still needs to know what addresses to not translate at the > application level so long as we are locally dual stack. You don=E2=80=99= t want to > send local traffic for IPv4 only local devices through the NAT64. > Can you provide an example scenario here? A host on a home network that has IPv4 as well as NAT64? Why would you deploy this as opposed to doing, say, 464xlat on the home gateway? --000000000000dba19e0579fb2047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Tue, Nov 6,= 2018 at 3:43 PM Mark Andrews <marka@is= c.org> wrote:
    >=C2=A0 =C2= =A0 =C2=A0 =C2=A0=E2=80=A2 AIUI, the option is not useful on an IPv6-only n= etwork. It is only useful in the case where the host has an IPv4 address. I= n that case the network might as well provide IPv4.

    For local ipv6-only only the filtering of IPv6 is useful and possibly could= be skipped to just use well known values to skip.
    What would be the purpose of such filters? A host that supports= 464xlat is just going to get the A record and send the packet to the NAT64= anyway, no?

    > Mark, do you have a use case for #4? It's clear that this would be= useful DNS64 translator that provides service to other hosts, but for the = case where the host is just doing DNS64 synthesis for itself, the use case = seems less clear.

    The host still needs to know what addresses to not translate at the applica= tion level so long as we are locally dual stack.=C2=A0 You don=E2=80=99t wa= nt to send local traffic for IPv4 only local devices through the NAT64.
    =

    Can you provide an example scenario here? = A host on a home network that has IPv4 as well as NAT64? Why would you depl= oy this as opposed to doing, say, 464xlat on the home gateway?
    <= /div> --000000000000dba19e0579fb2047-- From nobody Tue Nov 6 00:54:39 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F64130DE3; Tue, 6 Nov 2018 00:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 n74LNOy4Gexk; Tue, 6 Nov 2018 00:54:36 -0800 (PST) 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 3B0351277C8; Tue, 6 Nov 2018 00:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5766; q=dns/txt; s=iport; t=1541494476; x=1542704076; h=from:to:cc:subject:date:message-id:mime-version; bh=IGZTvwZuX2zoowrLLIsmWvM3rytEAdpKoiBYbqMOmxU=; b=YS+35utFsytA0HSjyw0tmp4vMUz1RkvwFn+OTNGNPAZSygABusPd/0+P OcSLd1QBDfhoASCYrXDEfaKdPP5rkVec06HNub+l23C2WNmIx0hNXbK1x /zZfDnq3bRA9lCfj3yyu8N3fJzC+YuITMZb6mQFVsk5wkj8OzjFI5ga58 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABFVuFb/5BdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGBDXdmfzKDbKgYhVQUgWYLAQEnhEUZg0EiNQw?= =?us-ascii?q?NAQMBAQIBAQJtHAELhWRWEgFKAgQwJwQOgyYBgR1kD6hfgS6ELQEDAgKFeAW?= =?us-ascii?q?LdheBQT+BOB+CHoMlJAIDgSaDPDGCJgKOX5BUCQKBXoUOiiMYkGCNC4oXAhE?= =?us-ascii?q?UgSYeATaBVXAVZQGCQoJPiEuFPo17gR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,471,1534809600"; d="scan'208,217";a="197080660" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 08:54:35 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id wA68sYmd032466 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2018 08:54:35 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Nov 2018 03:54:34 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Tue, 6 Nov 2018 03:54:34 -0500 From: "Eric Vyncke (evyncke)" To: "ipv6@ietf.org" CC: "draft-ietf-intarea-provisioning-domains.authors@ietf.org" Subject: Side meeting for 6MAN introduction to PvD draft-ietf-intarea-provisioning-domains Thread-Topic: Side meeting for 6MAN introduction to PvD draft-ietf-intarea-provisioning-domains Thread-Index: AQHUda5WcIgYbvisT0OGEk4KbAPbgQ== Date: Tue, 6 Nov 2018 08:54:34 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.3.181015 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.68.214.26] Content-Type: multipart/alternative; boundary="_000_D68C785FC82D4E88B07C0115F1A0331Dciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:54:38 -0000 --_000_D68C785FC82D4E88B07C0115F1A0331Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciA2TUFOIG1lbWJlcnMsDQoNCllvdSBtYXkgYmUgYXdhcmUgb2YgZHJhZnQtaWV0Zi1pbnRh cmVhLXByb3Zpc2lvbmluZy1kb21haW5zLTAzIHdoaWNoIGlzIGFuIElOVEFSRUEgZG9jdW1lbnQg c3BlY2lmeWluZyBhbiBSQSBvcHRpb24gZm9yIHByb3Zpc2lvbmluZyBkb21haW5zLg0KDQpJZiB5 b3UgYXJlIGludGVyZXN0ZWQgdG8ga25vdyBtb3JlIGFib3V0IHRoaXMgZHJhZnQsIEkgaW52aXRl IHlvdSB0byBqb2luIG1lIG9uIFdlZG5lc2RheSAxMDowMC0xMDozMCBBTSBpbiByb29tIFBhZ29k YSBtZWV0aW5nIHJvb20gKDR0aCBmbG9vciksIGl0IHdpbGwgdGFrZSAxMCBtaW51dGVzIHRvIGV4 cGxhaW4gdGhlIHdoeSBhbmQgdGhlIGhvdyBvZiB0aGlzIFB2RCBSQSBPcHRpb24uDQoNCkFsdGVy bmF0aXZlbHksIHlvdSBtYXkgaGF2ZSBhIGxvb2sgYXQgdGhlIGRyYWZ0IG9yIHRoZSBWNk9QUyBw cmVzZW50YXRpb24gYXQgSUVURi0xMDI6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvMTAyL21hdGVyaWFscy9zbGlkZXMtMTAyLXY2b3BzLXNlc3NhLWRpc2NvdmVyaW5nLXBy b3Zpc2lvbmluZy1kb21haW4tMDENCg0KT3Igd2FpdCBJRVRGLTEwMyB3aGVyZSBpdCB3aWxsIGJl IHByZXNlbnRlZCAoYWdlbmRhIGFsbG93aW5nIG9mIGNvdXJzZSkNCg0KUmVnYXJkcw0KDQotw6ly aWMNCg== --_000_D68C785FC82D4E88B07C0115F1A0331Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <599B10DCDC27C3499E5BCB44745352D7@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgNk1B TiBtZW1iZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPllvdSBtYXkgYmUgYXdhcmUgb2YgZHJhZnQtaWV0Zi1pbnRhcmVhLXByb3Zpc2lvbmlu Zy1kb21haW5zLTAzIHdoaWNoIGlzIGFuIElOVEFSRUEgZG9jdW1lbnQgc3BlY2lmeWluZyBhbiBS QSBvcHRpb24gZm9yIHByb3Zpc2lvbmluZyBkb21haW5zLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JZiB5b3UgYXJlIGludGVyZXN0ZWQgdG8ga25vdyBtb3Jl IGFib3V0IHRoaXMgZHJhZnQsIEkgaW52aXRlIHlvdSB0byBqb2luIG1lIG9uIFdlZG5lc2RheSAx MDowMC0xMDozMCBBTSBpbiByb29tIFBhZ29kYSBtZWV0aW5nIHJvb20gKDQ8c3VwPnRoPC9zdXA+ IGZsb29yKSwgaXQgd2lsbCB0YWtlIDEwIG1pbnV0ZXMgdG8gZXhwbGFpbiB0aGUgd2h5IGFuZCB0 aGUNCiBob3cgb2YgdGhpcyBQdkQgUkEgT3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+QWx0ZXJuYXRpdmVseSwgeW91IG1heSBoYXZlIGEgbG9vayBhdCB0 aGUgZHJhZnQgb3IgdGhlIFY2T1BTIHByZXNlbnRhdGlvbiBhdCBJRVRGLTEwMjoNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcv MTAyL21hdGVyaWFscy9zbGlkZXMtMTAyLXY2b3BzLXNlc3NhLWRpc2NvdmVyaW5nLXByb3Zpc2lv bmluZy1kb21haW4tMDEiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIv bWF0ZXJpYWxzL3NsaWRlcy0xMDItdjZvcHMtc2Vzc2EtZGlzY292ZXJpbmctcHJvdmlzaW9uaW5n LWRvbWFpbi0wMTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+T3Igd2FpdCBJRVRGLTEwMyB3aGVyZSBpdCB3aWxsIGJlIHByZXNlbnRlZCAoYWdlbmRhIGFs bG93aW5nIG9mIGNvdXJzZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi3D qXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D68C785FC82D4E88B07C0115F1A0331Dciscocom_-- From nobody Tue Nov 6 00:55:35 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FEB130F73 for ; Tue, 6 Nov 2018 00:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 eO3l8ue54Mr1 for ; Tue, 6 Nov 2018 00:55:24 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 C5A5D130F78 for <6man@ietf.org>; Tue, 6 Nov 2018 00:55:24 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 813683ABD1B; Tue, 6 Nov 2018 08:55:24 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2A489160098; Tue, 6 Nov 2018 08:55:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 10BC7160097; Tue, 6 Nov 2018 08:55:24 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mU_QhPorfVSu; Tue, 6 Nov 2018 08:55:23 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3876C160050; Tue, 6 Nov 2018 08:55:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: DNS64 pref option. From: Mark Andrews In-Reply-To: Date: Tue, 6 Nov 2018 19:55:20 +1100 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <9C07DE08-3E40-4DCB-9258-D7BF69BA8AFB@isc.org> References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:55:34 -0000 > On 6 Nov 2018, at 7:43 pm, Mark Andrews wrote: >=20 >=20 >=20 >> On 6 Nov 2018, at 7:34 pm, Lorenzo Colitti = wrote: >>=20 >> For more information, the proposal was originally made here. I'm not = sure whether it's worth doing this, because: >> =E2=80=A2 It complicates the implementation. >> =E2=80=A2 It can substantially increase the size of the option = (looks like it's at least 8 bytes per prefix), and the space available = in an RA packets is quite limited. >> =E2=80=A2 RFC 3123 is experimental (since 2001), whereas this = draft is intended to be a standards track document. The code point is assigned. There is a very clear description of the = record structure. Experimental is a red herring here. All servers can handle this record = either an a known type because they have implemented APL or a unknown = type as there is nothing in the packet format that prevents unknown type = processing being used for this record. The following are identical records. example. IN TYPE42 \# 1 00010000 example. IN APL 0:0.0.0.0/0 example. IN APL \# 1 00010000 example. IN TYPE42 0:0.0.0.0/0 >> =E2=80=A2 AIUI, the option is not useful on an IPv6-only = network. It is only useful in the case where the host has an IPv4 = address. In that case the network might as well provide IPv4. >=20 > For local ipv6-only only the filtering of IPv6 is useful and possibly = could be skipped to just use well known values to skip. >=20 >> Mark, do you have a use case for #4? It's clear that this would be = useful DNS64 translator that provides service to other hosts, but for = the case where the host is just doing DNS64 synthesis for itself, the = use case seems less clear. >=20 > The host still needs to know what addresses to not translate at the = application level so long as we are locally dual stack. You don=E2=80=99t= want to send local traffic for IPv4 only local devices through the = NAT64. >=20 >> On Tue, Nov 6, 2018 at 3:20 PM Mark Andrews wrote: >> I want a option to be able to configure name servers that do DNS64 = inside a network with local dual stack. This requires knowing what IPv4 = addresses are not to be translated and which IPv6 addresses to ignore = and perform DNS64 synthesis on the IPv4 address. Both of these ACLs can = be provided at a single name with a APL record. >>=20 >> For CLAT you effectively get this because you don=E2=80=99t route = local IPv4 traffic through the CLAT as the >> host has more specifics, regardless of whether it is a host or the = border CPE. >>=20 >> --=20 >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 6 00:56:50 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AFD130DE3 for ; Tue, 6 Nov 2018 00:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 KEhEY5pbSiJj for ; Tue, 6 Nov 2018 00:56:45 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97F2124BE5 for ; Tue, 6 Nov 2018 00:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3970; q=dns/txt; s=iport; t=1541494604; x=1542704204; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1desqfNAdxfheYRgHUyMTev9yI1c+Ju31RZBVh6PlF4=; b=kxdZV8b42gGPYg/uiUfSRjv2u14TyIKeIfKDUcEgJAXqDn+dwhg6e9fS O+eF6sYluFYr62SGR7tUq0ZBU0L/ixKECm9alMqyZt25fwn+KEXP0H/Dk SlNzKs3eV2LvlB3SPcJlHEPu3KGXqx5IVJts0+sDUoP1Wkf2FWOsjLTi+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAD8VuFb/4gNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmfygKg2yIGI4lly+BegsBASOBVIJ?= =?us-ascii?q?1AheDQSI0DQ0BAwEBAgEBAm0cDIU7AQUjEUUQAgEIGAICJgICAjAVEAIEDgW?= =?us-ascii?q?DIQGCAQ+oR4EuhC0BAwKBCYR2gQuKaxeBQT+BEScfgkyDGwEBA4F1gm0xgiY?= =?us-ascii?q?CnzMJAoZsiiMYgVWIIoZpjQuKFwIRFIEmHTiBVXAVOyoBgkEJiGKCMIU+bwG?= =?us-ascii?q?NC4EfAQE?= X-IronPort-AV: E=Sophos;i="5.54,471,1534809600"; d="scan'208";a="196835040" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 08:56:33 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id wA68uX8v005673 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2018 08:56:33 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Nov 2018 02:56:33 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1395.000; Tue, 6 Nov 2018 02:56:33 -0600 From: "Pablo Camarillo (pcamaril)" To: "Joel M. Halpern" CC: "Darren Dukes (ddukes)" , "ipv6@ietf.org" Subject: Re: Question 6man SRH encaps only Thread-Topic: Question 6man SRH encaps only Thread-Index: AQHUdafa15+XY1Mf/0a+ctWznq09V6VCyqYAgACBLwA= Date: Tue, 6 Nov 2018 08:56:32 +0000 Message-ID: References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> In-Reply-To: <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.68.85] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:56:48 -0000 SSBmYWlsIHRvIHNlZSBob3cgdGhpcyBvcHRpb24gaXMgc2ltcGxlci4gDQpOb3RlIHRoYXQgYXMg b3Bwb3NlZCB0byB3aGF0IHlvdSBzdGF0ZWQsIGhvc3RzIEEgYW5kIEIgZ2VuZXJhdGUgdGhlIHBh Y2tldCBhbmQgYXJlIGluc2lkZSB0aGUgU1IgZG9tYWluLg0KQSBMaW51eCBob3N0IEIgd2lsbCBy ZWNlaXZlIElQKFNSSChJUChUQ1AoLi4uKSkpLiBXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBp bm5lciBJUCBoZWFkZXI/IA0KDQpPbiB0b3Agb2YgdGhhdCwgeW91IGNhbiBsaW5rIGEgVENQL1VE UCBzb2NrZXQgd2l0aCBhIGdpdmVuIHNlZ21lbnQgcm91dGluZyBoZWFkZXIgWzFdLiBXaHkgd291 bGQgSSBpbnNlcnQgaGVyZSBhbiBJUCBoZWFkZXI/DQpJZiB5b3UgaGF2ZSB0aGUgdGltZSBbMl0g aXMgYW4gaW50ZXJlc3RpbmcgcmVhZC4gSW4gdGhlcmUgeW91IGhhdmUgYSBnb29kIGxpc3Qgb2Yg YmVuZWZpdHMuDQoNCkkgYmVsaWV2ZSB0aGF0IGlmIGhvc3RzIEEgYW5kIEIgYXJlIHdpdGhpbiB0 aGUgU1IgZG9tYWluIC13aGljaCBpcyB0aGUgY2FzZSB3aGVuIGhvc3RzIEEgYW5kIEIgZ2VuZXJh dGUgdGhlIFNSIGhlYWRlci0sIHRoZW4gdGhlcmUgaXMgbm8gYmVuZWZpdCB0byBpbnRyb2R1Y2Ug YW4gaW5uZXIgSVAgaGVhZGVyIGJlZm9yZSB0aGUgTDQgcGF5bG9hZC4NCg0KVGhhbmtzLA0KUGFi bG8uDQoNClsxXS4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1Y2hlbmUtc3By aW5nLXNydjYtc29ja2V0LTAwDQpbMl0uIERhdmlkIExlYnJ1biwgTWF0aGlldSBKYWRpbiwgRnJh bsOnb2lzIENsYWQsIENsYXJlbmNlIEZpbHNmaWxzLA0KYW5kIE9saXZpZXIgQm9uYXZlbnR1cmUu IDIwMTguIFNvZnR3YXJlIFJlc29sdmVkIE5ldHdvcmtzOiBSZXRoaW5raW5nDQpFbnRlcnByaXNl IE5ldHdvcmtzIHdpdGggSVB2NiBTZWdtZW50IFJvdXRpbmcuIEluIFNPU1INCuKAmTE4OiBTT1NS IOKAmTE4OiBTeW1wb3NpdW0gb24gU0ROIFJlc2VhcmNoLCBNYXJjaCAyNuKAkzI3LCAyMDE4LA0K TG9zIEFuZ2VsZXMsIENBLCBVU0EuIEFDTSwgTmV3IFlvcmssIE5ZLCBVU0EsIDE0IHBhZ2VzLg0K aHR0cHM6Ly9kb2kub3JnLzEwLjExNDUvMzE4NTQ2Ny4zMTg1NDcxDQoNCg0K77u/T24gMDYvMTEv MjAxOCwgMTU6MTQsICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90 ZToNCg0KICAgIFllcywgSSBhbSBzYXlpbmcgdGhhdCB3ZSBzaG91bGQgYWx3YXlzIHVzZSBJUChT UkgoSVAoLi4uKSkpLg0KICAgIFRoZSByZWFzb24gaXMgc2ltcGxpY2l0eSBhbmQgcm9idXN0bmVz cy4NCg0KICAgIEFzIHdlIGhhdmUgYWxyZWFkeSBkaXNjdXNzZWQsIHRoZSBob3N0IGhhcyB0byBi ZSBwcmVwYXJlZCB0byBnZW5lcmF0ZSANCiAgICB0aGF0IGZvcm0gYW5kIHByb2Nlc3MgdGhhdCBm b3JtIHdoZW5ldmVyIGl0IGlzIHRhbGtpbmcgdG8gc29tZW9uZSANCiAgICBvdXRzaWRlIHRoZSBT UiBEb21haW4uCQ0KDQogICAgSGF2aW5nIHR3byB3YXlzIG9mIGVuY29kaW5nIHRoZSBzYW1lIHRo aW5nLCBhbmQgdHdvIHByb2Nlc3NpbmcgcGF0aHMgZm9yIA0KICAgIGdlbmVyYXRpbmcgLyBoYW5k bGluZyB0aGUgc2FtZSB0aGluZywgaW50cm9kdWNlcyBjb21wbGV4aXR5Lg0KICAgIA0KICAgIElm IHRoZXJlIGlzIGEgc3Ryb25nIGJlbmVmaXQgKGJleW9uZCB0aGUgbnVtYmVyIG9mIGJpdHMgaW4g dGhlIHBhY2tldCksIA0KICAgIEkgd291bGQgbGlrZSB0byBoZWFyIGFib3V0IHRoYXQgYmVuZWZp dC4gIEkgY2FuIGVhc2lseSBiZWxpZXZlIEkgbWlzc2VkIA0KICAgIHNvbWV0aGluZy4NCiAgICAN CiAgICBJbiB0aGUgYWJzZW5jZSBvZiBhIGJlbmVmaXQsIGNob2ljZXMgYXJlIGluIGFuZCBvZiB0 aGVtc2VsdmVzIGhhcm1mdWwuDQogICAgDQogICAgWW91cnMsDQogICAgSm9lbA0KICAgIA0KICAg IE9uIDExLzYvMTggMzowOCBQTSwgUGFibG8gQ2FtYXJpbGxvIChwY2FtYXJpbCkgd3JvdGU6DQog ICAgPiBIaSBKb2VsLA0KICAgID4gDQogICAgPiBSZWdhcmRpbmcgeW91ciBxdWVzdGlvbiBvbiA2 bWFuIGFib3V0IHRoZSBTUkggYW5kIGFsbG93aW5nIG9ubHkgDQogICAgPiBlbmNhcHN1bGF0aW9u Og0KICAgID4gDQogICAgPiBUaGVyZSBhcmUgdHdvIG9wZW4tc291cmNlIGhvc3QgaW1wbGVtZW50 YXRpb25zIG9mIHRoZSBTUkggKExpbnV4IEtlcm5lbCwgDQogICAgPiBGRC5pbyBWUFApLiBJIHdy b3RlIHRoZSBjb2RlIGZvciBTUkggaW4gdGhlIGxhdHRlci4NCiAgICA+IA0KICAgID4gQS0tLTEt LS0yLS0tQg0KICAgID4gDQogICAgPiAoQSBhbmQgQiBhcmUgaG9zdHMpDQogICAgPiANCiAgICA+ IEluIG9uZSBvZiB0aGUgdXNlLWNhc2VzIGhvc3QgQSBoYXMgYXdhcmVuZXNzIG9mIHRoZSB0cmFu c3BvcnQgbmV0d29yay4NCiAgICA+IA0KICAgID4gSG9zdCBBIGdlbmVyYXRlcyBhbmQgc2VuZHMg YSBwYWNrZXQgb2YgdGhlIGZvcm0gSVAoU1JIKFRDUCguLi4pKSkgd2hlcmUgDQogICAgPiB0aGUg U1JIIGNvbnRhaW5zIHNlZ21lbnRzIDwxLDIsQj4uDQogICAgPiANCiAgICA+IE5vdGUgdGhhdCBC IGlzIGFuIGludGVyZmFjZSBhZGRyZXNzIG9uIGhvc3QgQi4NCiAgICA+IA0KICAgID4gRG8geW91 IGJlbGlldmUgdGhhdCBpbiB0aGlzIGNhc2UgdGhlIGhvc3Qgc2hvdWxkIHNlbmQgDQogICAgPiBJ UChTUkgoSVAoVENQKC4uLikpKSk/IElmIHllcywgd2h5Pw0KICAgID4gDQogICAgPiBJIHRoaW5r IHRoaXMgaXMgYSByZWxldmFudCB1c2UtY2FzZSAtZS5nLiBQQU5SRy0sIGFuZCBkb27igJl0IHNl ZSB3aHkgd2UgDQogICAgPiB3b3VsZCBlbmZvcmNlIGVuY2Fwc3VsYXRpb24uDQogICAgPiANCiAg ICA+IFRoYW5rcywNCiAgICA+IA0KICAgID4gUGFibG8uDQogICAgPiANCiAgICANCg0K From nobody Tue Nov 6 01:01:37 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5E1277C8 for ; Tue, 6 Nov 2018 01:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 TBKvYFZMImc8 for ; Tue, 6 Nov 2018 01:01:33 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 4D0DA124BE5 for ; Tue, 6 Nov 2018 01:01:33 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id g7-v6so3529179pfo.10 for ; Tue, 06 Nov 2018 01:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=tpX4/IjZ97o8SPVZKtIiKKc4YvunyQn6GZT+slq3nlo=; b=lGXXrtdoER6lI63Be4GMWNiC5PHFuvv1SuQecoPb8IpSLJT1luzzeRlejVKt8z9Xro g3iXcKVOG0opcLE8GkNv2VNqaGBWhStCtDj80pk/xra7G+AhqIK8/DQDd1s0V+FL7WrM 6Jc/G3Y8tsm7Mdd873zjdHglT2Ug4MSsUfSVUEC9TAOzDWpbM467CN/W8dykdxjqzeGH CN9cXhlRvXKQXuvD/OWB5+KQPbpzcpImHIGmGWmrXAoMU0T1EOw518qGR4EOw8u4jcpL Bv22C92FVyJsTJzw3AwSQLDmpMXKEXpcH2w1p2LxDMHuGt4EYRumjlfqeLxOZxfu4QX5 BOBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=tpX4/IjZ97o8SPVZKtIiKKc4YvunyQn6GZT+slq3nlo=; b=CuTz4FTwf1NS5J7aprK9PoPKxzeFYeqyUyFHJQ2pzICLGFNmU5oRfh2J5HpjSZPA9y b0j0KvffuwO3r4zSnX5VgIg128nRlbwsrP3nGlpyXkE/v6zdtNFiZCA9ioO0ImazUVFj /H6HUYkbkC0zX45v9yFrkeOx6GzPW5x7b8pVI72OyIR0Pq8gjYAWzAOZ6WfQkS2Exb8F KMqjRHrvZRsRtPop5sKopchiJhvu5IKonrsyjBhdEFMPHi7ieVoKWCRTO7w0x643q4p5 UCReYXm0PhxF6nW5AbQ32HB2a2x5mWzIlg5axIV+RWDmjXJAhFNOkcwdTif3TZEkyo2v 61jQ== X-Gm-Message-State: AGRZ1gIAUobwmH6bY6vyAh6EBaTK9Sf3tM9PNJmYVPLDpQUpjMdSsNAa bNfuJOPZllG6gJbtXqyoRUkSgpTj X-Google-Smtp-Source: AJdET5eef2nd3QboplT3+er2u79EKIDNBR1gdOXT4AxrpgUa66o9Ud/NjGDY11A1ZF7kVbu8ZEo2+g== X-Received: by 2002:a63:2045:: with SMTP id r5-v6mr22813561pgm.328.1541494892739; Tue, 06 Nov 2018 01:01:32 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:1478:fc66:d11e:336d? ([2001:67c:370:128:1478:fc66:d11e:336d]) by smtp.gmail.com with ESMTPSA id g72-v6sm60160946pfd.181.2018.11.06.01.01.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 01:01:32 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_DD025840-70F0-44EA-A276-FA553486B25B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Side Meeting: 6MAN/TSVWG Path MTU Discovery Discussion Message-Id: Date: Tue, 6 Nov 2018 16:01:29 +0700 Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , G Fairhurst To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:01:35 -0000 --Apple-Mail=_DD025840-70F0-44EA-A276-FA553486B25B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have scheduled a side meeting to discuss IPv6 Path MTU Discovery to = continue the discussion at today=E2=80=99s 6man session. It will be: Fri, November 9, 10am =E2=80=93 12pm Where: Thai Chitlada 2 room The goal is to discuss the current and new Path MTU Discovery = approaches. Please let us know if you plan to attend so we can make sure the room is = large enough. Bob & Ole & Gorry --Apple-Mail=_DD025840-70F0-44EA-A276-FA553486B25B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlvhWGkACgkQrut0EXfn u6hWZAf+NQGJKIYbU3HL8PLV9BLERfYTht/MC0p35SX5YcYAjYMRDD+9+0JtfXlw UpCtVND/Ra5d7ePdUUo9ymeVYUCbi4pEnyYFpIBrM5sA9RBIIIqvd7Nevi1vKEnC 1pFGtnD4A5eykmYSY+KaVTe5O1zgmzg22wnm0xhORCoyqNuTMWykagXzq7y7A7Lu CwDR8FRZejvDc+FD5mdKO65Xr45Rc7ViX1pxDPD9F44Z+Vs9fqACitguSjIBWoNt vUWVzHszjNaMBEqNG3y8MGGjZaLUqss46ZDLHjQkgjxKeCbXaZEgckstP0fv37/2 IGRXiDRcSMj+9r0I+78tlsmvNdiDow== =1NgK -----END PGP SIGNATURE----- --Apple-Mail=_DD025840-70F0-44EA-A276-FA553486B25B-- From nobody Tue Nov 6 01:03:26 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF390124BE5 for ; Tue, 6 Nov 2018 01:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 QEkKu1wu7u03 for ; Tue, 6 Nov 2018 01:03:18 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 97B3E1277C8 for <6man@ietf.org>; Tue, 6 Nov 2018 01:03:18 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4CA903ABD9B; Tue, 6 Nov 2018 09:03:17 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 196E6160098; Tue, 6 Nov 2018 09:03:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0AC87160097; Tue, 6 Nov 2018 09:03:17 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iLIUWIIy5a8Z; Tue, 6 Nov 2018 09:03:16 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 67CB9160050; Tue, 6 Nov 2018 09:03:16 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: DNS64 pref option. From: Mark Andrews In-Reply-To: Date: Tue, 6 Nov 2018 20:03:13 +1100 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:03:25 -0000 > On 6 Nov 2018, at 7:52 pm, Lorenzo Colitti wrote: >=20 > On Tue, Nov 6, 2018 at 3:43 PM Mark Andrews wrote: > > =E2=80=A2 AIUI, the option is not useful on an IPv6-only = network. It is only useful in the case where the host has an IPv4 = address. In that case the network might as well provide IPv4. >=20 > For local ipv6-only only the filtering of IPv6 is useful and possibly = could be skipped to just use well known values to skip. >=20 > What would be the purpose of such filters? A host that supports = 464xlat is just going to get the A record and send the packet to the = NAT64 anyway, no? >=20 > > Mark, do you have a use case for #4? It's clear that this would be = useful DNS64 translator that provides service to other hosts, but for = the case where the host is just doing DNS64 synthesis for itself, the = use case seems less clear. >=20 > The host still needs to know what addresses to not translate at the = application level so long as we are locally dual stack. You don=E2=80=99t= want to send local traffic for IPv4 only local devices through the = NAT64. >=20 > Can you provide an example scenario here? A host on a home network = that has IPv4 as well as NAT64? Why would you deploy this as opposed to = doing, say, 464xlat on the home gateway? Because you want to move the traffic to IPv6 as early as possible to = remove load from the router. Because your router doesn=E2=80=99t have a CLAT. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 6 01:44:44 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD36130E47 for ; Tue, 6 Nov 2018 01:44:43 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 6SQ3GCcROrHx for ; Tue, 6 Nov 2018 01:44:39 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 7AF6C128A5C for ; Tue, 6 Nov 2018 01:44:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 152942C024F; Tue, 6 Nov 2018 01:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1541497479; bh=bl5YJQPba/DV61TaCAV7db7sz3NmVDmyUqjAIhCNsBU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=je2NsUqXV+uGP3Ave1FuKGXhMOYoPxfu8NEYSaFwjA7FpApJkttBHLvAvnm1JRTnu UUmQaNwHEJwM+O1gj4LyNz9JT7OjGzdw3JNkk4CpoSNv4cA/b8BGCCKvH1SPZ+NsSm 0RvlkDjO+uv7RgTKdJ+zBxVC6u0BEagvG3LU4+v4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from dhcp-9f4f.meeting.ietf.org (unknown [IPv6:2001:67c:1232:144:9478:5251:141b:c977]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CB40A1C02A4; Tue, 6 Nov 2018 01:44:37 -0800 (PST) Subject: Re: Question 6man SRH encaps only To: "Pablo Camarillo (pcamaril)" Cc: "Darren Dukes (ddukes)" , "ipv6@ietf.org" References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <9e3b89c3-0eee-84f5-2bbc-04b5399fd72b@joelhalpern.com> Date: Tue, 6 Nov 2018 16:44:35 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:44:43 -0000 The point is that a host inside the SR domain, when processing an SR policy, has to be prepared, for reasons we discussed on the list before the meeting, to generate the full IP(SR(IP(...))) packet format. Having an option to generate two different SR formats does not add value and does inherently add complexity. On the receive side, the host must also be prepared to receive both formats. One can argue that this is less of a burden, but it is still complexity. And we have already determined that it needs to be able to handle the encapsulated case. Yours, Joel On 11/6/18 3:56 PM, Pablo Camarillo (pcamaril) wrote: > I fail to see how this option is simpler. > Note that as opposed to what you stated, hosts A and B generate the packet and are inside the SR domain. > A Linux host B will receive IP(SRH(IP(TCP(...))). What is the purpose of the inner IP header? > > On top of that, you can link a TCP/UDP socket with a given segment routing header [1]. Why would I insert here an IP header? > If you have the time [2] is an interesting read. In there you have a good list of benefits. > > I believe that if hosts A and B are within the SR domain -which is the case when hosts A and B generate the SR header-, then there is no benefit to introduce an inner IP header before the L4 payload. > > Thanks, > Pablo. > > [1]. https://tools.ietf.org/html/draft-duchene-spring-srv6-socket-00 > [2]. David Lebrun, Mathieu Jadin, François Clad, Clarence Filsfils, > and Olivier Bonaventure. 2018. Software Resolved Networks: Rethinking > Enterprise Networks with IPv6 Segment Routing. In SOSR > ’18: SOSR ’18: Symposium on SDN Research, March 26–27, 2018, > Los Angeles, CA, USA. ACM, New York, NY, USA, 14 pages. > https://doi.org/10.1145/3185467.3185471 > > > On 06/11/2018, 15:14, "Joel M. Halpern" wrote: > > Yes, I am saying that we should always use IP(SRH(IP(...))). > The reason is simplicity and robustness. > > As we have already discussed, the host has to be prepared to generate > that form and process that form whenever it is talking to someone > outside the SR Domain. > > Having two ways of encoding the same thing, and two processing paths for > generating / handling the same thing, introduces complexity. > > If there is a strong benefit (beyond the number of bits in the packet), > I would like to hear about that benefit. I can easily believe I missed > something. > > In the absence of a benefit, choices are in and of themselves harmful. > > Yours, > Joel > > On 11/6/18 3:08 PM, Pablo Camarillo (pcamaril) wrote: > > Hi Joel, > > > > Regarding your question on 6man about the SRH and allowing only > > encapsulation: > > > > There are two open-source host implementations of the SRH (Linux Kernel, > > FD.io VPP). I wrote the code for SRH in the latter. > > > > A---1---2---B > > > > (A and B are hosts) > > > > In one of the use-cases host A has awareness of the transport network. > > > > Host A generates and sends a packet of the form IP(SRH(TCP(...))) where > > the SRH contains segments <1,2,B>. > > > > Note that B is an interface address on host B. > > > > Do you believe that in this case the host should send > > IP(SRH(IP(TCP(...))))? If yes, why? > > > > I think this is a relevant use-case -e.g. PANRG-, and don’t see why we > > would enforce encapsulation. > > > > Thanks, > > > > Pablo. > > > > From nobody Tue Nov 6 01:49:12 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986F130E50 for ; Tue, 6 Nov 2018 01:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 aa3gnFUNNDs3 for ; Tue, 6 Nov 2018 01:49:08 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 D1AF4128A5C for ; Tue, 6 Nov 2018 01:49:07 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id l2-v6so10925862wmh.3 for ; Tue, 06 Nov 2018 01:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iILQaSzgJrLw0exXzjFcD9xRTudRkxhpxbzhyzxiHDI=; b=blXB5sMYxs4KQDsl9sLduHZuBTZnUQMULY2avfk/Wfk2ZQRfRYodOA8LzXOdVhJhpI bAxzUytr1x81CtNA27n2T5PPnDYBCyzxGmGpdtbg/4VUy02pZbzl+hRTj21Iq5ndHk8d scaRvHm+JRlDjzDfpIoBVrnHPTzFIA6gvkw3NS4qGisFBTYBKTuLzvFV4BM7Hrm9AUO2 LY5k4Pq5X7OswEdS0zyPGMQm6HpVTUD9lWx3/JDlhbR7Ab3Qu+PXX4TUmgcS/HBVX+zI 5JmVmOhGOZQYmCf3EBViIRi6abhCUPL7x+PUVxl9s3makojuh4CsYC3TTfYXXDNfNaga KxEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iILQaSzgJrLw0exXzjFcD9xRTudRkxhpxbzhyzxiHDI=; b=nBCuuwoD1BwdBsNGWrUsTirlaNbdbwrdjTbsECUQV37Xgtiy7yVb5MpHYTvmhlweN7 5nYMYqq/LtnEJj2pLZ71qgaPAOxuBNNMwJzqbqvkhB+6X4vX5Zd3lbAbCvQBZsWVykZa OlXTd/RTebQmYBj9F5Rpq9m0n/J9Mj7WOqZdCCQkfRKiH6lpAyEkt6kBzCCX+dMvVsM2 9RpdQRYcaqnmByqgsYUD6ipYoJFkTwiAQVhD1KIgL8jfIrU1637uv5ZfJt07VNmFDJAf V62U/KpKopa8+4HNmo870KXpE0OXhDuWXZi9iy38IjvYQLs6lyIbVPGhEVF9omlg7bEv hbUw== X-Gm-Message-State: AGRZ1gJmfpP2eH6RXA3tOgzCTThJqRlth0vXuHU5YG/Bn98xAlbK8TuB UN4DnwCUQMjGk5fmhYPl503w248e X-Google-Smtp-Source: AJdET5f9LYYcFWm/THAoxFHGgEqtDkNyoNqlvO959GOP8PGexMu0kwW+VFzVv4a9h3ScDF4bhEoSLA== X-Received: by 2002:a7b:c083:: with SMTP id r3-v6mr1380591wmh.101.1541497746138; Tue, 06 Nov 2018 01:49:06 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:9db1:5614:3dcc:6a56? ([2001:67c:370:128:9db1:5614:3dcc:6a56]) by smtp.gmail.com with ESMTPSA id v2-v6sm15784228wru.20.2018.11.06.01.49.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 01:49:05 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_85753BA0-B240-4638-91DE-B6CA674AFC7B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Side Meeting: 6MAN/TSVWG Path MTU Discovery Discussion Date: Tue, 6 Nov 2018 16:48:59 +0700 In-Reply-To: Cc: =?utf-8?Q?Ole_Tr=C3=B8an?= , G Fairhurst , Bob Hinden To: IPv6 List References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:49:10 -0000 --Apple-Mail=_85753BA0-B240-4638-91DE-B6CA674AFC7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 By the way, I found out that Thai Chitlada 2 is the same room as = Chitlada 2 on the second floor. There will be a projector, but not = meetecho. Bob > On Nov 6, 2018, at 4:01 PM, Bob Hinden wrote: >=20 > We have scheduled a side meeting to discuss IPv6 Path MTU Discovery to = continue the discussion at today=E2=80=99s 6man session. It will be: >=20 > Fri, November 9, 10am =E2=80=93 12pm > Where: Thai Chitlada 2 room >=20 > The goal is to discuss the current and new Path MTU Discovery = approaches. >=20 > Please let us know if you plan to attend so we can make sure the room = is large enough. >=20 > Bob & Ole & Gorry >=20 >=20 --Apple-Mail=_85753BA0-B240-4638-91DE-B6CA674AFC7B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlvhY4sACgkQrut0EXfn u6jDOAf+M94oFQVgWD+2rhqaPZXD4xwyJdzuNZW5AAZU38oFt7LC2HwV2cogQWNL HF4A7FeN+ygRAxYFpHJYy6dMSkfvuUSMoSWeFsw8ezfD5QyQiLm7qF7GJg28jGrN u4LR+yS3xZ7hfXBJdmM60pp1JxxMU+UYj5AVUp87kCPcS3FQsZHqyYI8I4F4sfvn cwCCWC4mv4ek9WxulWGps21dEcYiqCXPEVNhubFrEmqeHBQDS8+8LDBXLWxMKoFL jEG5KrjIXAi34tke9Ub8BRCaFwQQNqVYnZo8BFUf03dGLWjXhLCgc9Yzeo1lNpuX KGZnPdg1l3d9/oOGrN+iqAGeLmhI8g== =RS7+ -----END PGP SIGNATURE----- --Apple-Mail=_85753BA0-B240-4638-91DE-B6CA674AFC7B-- From nobody Tue Nov 6 02:01:14 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C44A128A5C for ; Tue, 6 Nov 2018 02:01:11 -0800 (PST) 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=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 46O0IHGZ3zT5 for ; Tue, 6 Nov 2018 02:01:09 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226531277C8 for ; Tue, 6 Nov 2018 02:01:08 -0800 (PST) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wA690XBQ086045 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Nov 2018 09:00:33 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Subject: Re: Comments on IPv4-only flag document To: Lorenzo Colitti Cc: IETF IPv6 Mailing List References: <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> From: Nick Hilliard Message-ID: <7bd14b0f-a62e-e15e-29a1-dbd3a09b3aec@foobar.org> Date: Tue, 6 Nov 2018 10:01:04 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 10:01:12 -0000 Lorenzo Colitti wrote on 06/11/2018 08:39: > No, it's not what I'm asking for. That text doesn't address the case > where the RA was sent by an attacker on an IPv4-only network that is > currently working just fine. That is the case for the majority of > networks today. Such networks very likely don't have RA guard because > they have never had a need for it. this is part of the reason that this draft is so objectively harmful: it encodes a protocol-level security vulnerability which will apply widely to most networks except those which have actively managed layer 2 security mechanisms in place. These networks could be - as you indicate - ipv4-only in the sense of not having any ipv6 routers, but will be ipv6 enabled to the extent that many hosts will have ipv6 RA solicitation configured by default because there is no admin to turn it off; they have no RA guard, and no real possibility of getting RA guard, because that requires active management and a realisation that without careful configuration, bad things could easily happen. Just because the text doesn't address this case, this doesn't mean that someone with malicious intent won't address the case. What does the IETF say to the victims of this form of attack? That their use case is not addressed and is therefore out of scope? Nick From nobody Tue Nov 6 02:12:29 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9E129AB8 for ; Tue, 6 Nov 2018 02:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 zd_i4XfADHpE for ; Tue, 6 Nov 2018 02:12:25 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 19ECE1277C8 for ; Tue, 6 Nov 2018 02:12:25 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id k141-v6so15052051itk.3 for ; Tue, 06 Nov 2018 02:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sFY9AAbEnyt/RYP/YedsUJ8ylZdz6Uv9EVEE9+Zffyc=; b=VfNx1qVJnIjkmXyexwL9fNEEJ18aFasn/rAvGu3S/ss+oiSn2s3ajuD6IJ4u3Hsr9X LrWYJoHb8CjSvrEtlBrFghTU0hUBuIVqsHkxL5KMZhD/bhMTdl8s+/tJ9qIhIOLAeFFq WHCy+g/EEHVeFTiQjtEPri70NPRgHtrr7ptQQmi4nOicfkACFP1pqCQ60qbZmDbSb3pK D0Tt6Kk5DFoIW3H1AMqSQ0p2YvLvCsGnYVjyhSaijJ6MkT8fnGhxWkeigD/oMcBBAxfV FphBrOg+5jF6+7+4FQLd4+vZqmWTtKUDhoMKu1JzdpTYiUS9KFTCt0GOmGCm1ve2s4KV Pvpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sFY9AAbEnyt/RYP/YedsUJ8ylZdz6Uv9EVEE9+Zffyc=; b=XuTOZMZtXTvvfTbppjjuqy+Ad2rT+s1/5Lh7hBcGDgFY9e+Cq2eBfmXIVYlgzOUlMr tQwloeCBsm+x05GAdgvM9B3PXE7VCkI12bXAcoOl/Ui1QRDeLjsdWhBX1VlcsbVVZnZ9 u9fBociDaIfQm/JY18GyK8A4XQ5Bpu0DEVoPLgsxV/kIl9Vvec7eqOcHDyd8IuZ/bmz0 cS1ift8j3CTJmUAhYSuPRm02I+7rPyUBiH5V3PRBJ6diUbsNaqHvfO0SqlwmvEeAjxo3 6mGA0CpiJXJtP8F5//Di8r0lqi+UstCantU1zDMHA9RnUWK9CDhWG91ZUVk5/FnnTsfz nDLw== X-Gm-Message-State: AGRZ1gLt07lN1bf09Qw7iPM8fM1gfYSQzgBe9Sdz4QrAuDdyLEh1VFCR q1W7IhuBBgXqAddnBNJnkPuAwXDiv/g4hdijBZyT8UQN2f+5kA== X-Google-Smtp-Source: AJdET5dEY37iE9NsoEG8F6NVVE2S7C3bi1uhW8GEOtE6PNbh2nVbNfxMShELyCOfZKcT9NP/NguKII2sMU4KfQuJe/c= X-Received: by 2002:a24:5d11:: with SMTP id w17-v6mr1330067ita.89.1541499143993; Tue, 06 Nov 2018 02:12:23 -0800 (PST) MIME-Version: 1.0 References: <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> <7bd14b0f-a62e-e15e-29a1-dbd3a09b3aec@foobar.org> In-Reply-To: <7bd14b0f-a62e-e15e-29a1-dbd3a09b3aec@foobar.org> From: Lorenzo Colitti Date: Tue, 6 Nov 2018 17:12:10 +0700 Message-ID: Subject: Re: Comments on IPv4-only flag document To: Nick Hilliard Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="000000000000e6b7ef0579fc3c61" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 10:12:27 -0000 --000000000000e6b7ef0579fc3c61 Content-Type: text/plain; charset="UTF-8" On Tue, 6 Nov 2018, 17:01 Nick Hilliard What does the IETF say to the victims of this form of attack? That > their use case is not addressed and is therefore out of scope? > I proposed that what the IETF should say about this is: if a host already has a working IPv4 configuration, it SHOULD NOT not turn it off on receipt of an IPv6-only flag. > --000000000000e6b7ef0579fc3c61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Tue, = 6 Nov 2018, 17:01 Nick Hilliard <nick= @foobar.org wrote:
    What does the IETF say to the victims of this form of attack?=C2=A0 That their use case is not addressed and is therefore out of scope?

    I proposed th= at what the IETF should say about this is: if a host already has a working = IPv4 configuration, it SHOULD NOT not turn it off on receipt of an IPv6-onl= y flag.
    --000000000000e6b7ef0579fc3c61-- From nobody Tue Nov 6 02:28:26 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6480B130DC9 for ; Tue, 6 Nov 2018 02:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Jl6a7md0cOIm for ; Tue, 6 Nov 2018 02:28:22 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28540130DDB for ; Tue, 6 Nov 2018 02:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5998; q=dns/txt; s=iport; t=1541500102; x=1542709702; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3Wz2WXVBLAz9gatCtWNKlPh3lMdqQ7Vn26GJ7vzaOT4=; b=Wsg/o8x4SJKb/B9/9WIY+EGMFnbIGXcm2dX1q1AzHUzbdjg+g12ksPi/ zcPsPCFn88jg86cCQt+yKoYfBXpaRsUFImhZLI2e2dz4P54qMvK/fswcj +3dDrZA2phUcx1kWfRux/QIywVGMT8MSQC0wt2e5nXfV8gjnvfzH/xLlU g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACta+Fb/4gNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVUuZoECJwqDbIgYjgAllzCBegsBASM?= =?us-ascii?q?JgUuCdQIXg0EiNA0NAQMBAQIBAQJtHAyFOgEBAQECASMRRQULAgEIGAICJgI?= =?us-ascii?q?CAjAVEAIEDgUbgwYBgXkID6gxgS6ELQEDAoEJhHaBC4prF4FBP4ERJwwTgky?= =?us-ascii?q?DGwEBA4E3JxeCbTGCJgKJB5YvCQKGbYojGIFWiCKGaY0MihcCERSBJh04gVV?= =?us-ascii?q?wFTsqAYJBCYhigjCFPnIBgSeKOoEuAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.54,471,1534809600"; d="scan'208";a="477240131" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 10:28:20 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id wA6ASKJh023808 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2018 10:28:20 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Nov 2018 04:28:20 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Tue, 6 Nov 2018 04:28:20 -0600 From: "Darren Dukes (ddukes)" To: "Joel M. Halpern" CC: "Pablo Camarillo (pcamaril)" , "ipv6@ietf.org" Subject: Re: Question 6man SRH encaps only Thread-Topic: Question 6man SRH encaps only Thread-Index: AQHUdafa15+XY1Mf/0a+ctWznq09V6VCyqYAgACBLwD//5gXgIAADDiA Date: Tue, 6 Nov 2018 10:28:20 +0000 Message-ID: References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> <9e3b89c3-0eee-84f5-2bbc-04b5399fd72b@joelhalpern.com> In-Reply-To: <9e3b89c3-0eee-84f5-2bbc-04b5399fd72b@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.26] Content-Type: text/plain; charset="utf-8" Content-ID: <546A553D57CA4A49AF4D9E3B3010C2FB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 10:28:24 -0000 SSB0aGluayBpdCBkZXBlbmQgb24geW91ciB2aWV3IG9mIHNpbXBsaWNpdHkuICBTaW1wbGUgdG8g aW1wbGVtZW50IGZvciBhIGJyb2FkIHNldCBvZiBzb2x1dGlvbnMgb3Igc2ltcGxlIHRvIHNwZWNp Znk/DQoNCkl0IGlzIHNpbXBsZSB0byBzcGVjaWZ5IGEgaG9zdCBtdXN0IG9ubHkgZW5jYXBzdWxh dGUsIG9yIG90aGVyIHJlc3RyaWN0aW9ucyBidXQgdGhhdCBkb2VzbuKAmXQgbmVjZXNzYXJpbHkg Z2l2ZSB1cyBhIHN0cm9uZyBiYXNlIHRvIGJ1aWxkIG90aGVyIHNwZWNpZmljYXRpb24uDQoNCkkg cHJlZmVyIHRoYXQgd2UgbWFrZSBzdXJlIHRoZSBTUkggZHJhZnQgZGVmaW5lIGEgZ29vZCBiYXNl IG9uIHdoaWNoIG90aGVyIGRvY3VtZW50cyBjYW4gYmUgYmFzZWQgdG8gc29sdmUgcmVhbCBwcm9i bGVtcyBiZXlvbmQgdGhlIHZlcnkgbGltaXRlZCB1c2UgY2FzZXMgd2UgaGF2ZSBkZWZpbmVkLg0K DQpCVFcgSXQgaXMgc2ltcGxlIHRvIGltcGxlbWVudCB0aGUgc29ja2V0IGJhc2VkIGFwcHJvYWNo IHRvIGFwcGx5IGFuIFNSIHBvbGljeSB0byBhIHNvY2tldCB3aXRoaW4gYW4gU1IgRG9tYWluIC0g SXQgaXMgaW1wbGVtZW50ZWQsIGFuZCBpdCB3b3Jrcy4NCg0KRGFycmVuDQoNCj4gT24gTm92IDYs IDIwMTgsIGF0IDQ6NDQgQU0sIEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4g d3JvdGU6DQo+IA0KPiBUaGUgcG9pbnQgaXMgdGhhdCBhIGhvc3QgaW5zaWRlIHRoZSBTUiBkb21h aW4sIHdoZW4gcHJvY2Vzc2luZyBhbiBTUiBwb2xpY3ksIGhhcyB0byBiZSBwcmVwYXJlZCwgZm9y IHJlYXNvbnMgd2UgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUgbWVldGluZywgdG8g Z2VuZXJhdGUgdGhlIGZ1bGwgSVAoU1IoSVAoLi4uKSkpIHBhY2tldCBmb3JtYXQuICBIYXZpbmcg YW4gb3B0aW9uIHRvIGdlbmVyYXRlIHR3byBkaWZmZXJlbnQgU1IgZm9ybWF0cyBkb2VzIG5vdCBh ZGQgdmFsdWUgYW5kIGRvZXMgaW5oZXJlbnRseSBhZGQgY29tcGxleGl0eS4NCj4gDQo+IE9uIHRo ZSByZWNlaXZlIHNpZGUsIHRoZSBob3N0IG11c3QgYWxzbyBiZSBwcmVwYXJlZCB0byByZWNlaXZl IGJvdGggZm9ybWF0cy4gIE9uZSBjYW4gYXJndWUgdGhhdCB0aGlzIGlzIGxlc3Mgb2YgYSBidXJk ZW4sIGJ1dCBpdCBpcyBzdGlsbCBjb21wbGV4aXR5LiAgQW5kIHdlIGhhdmUgYWxyZWFkeSBkZXRl cm1pbmVkIHRoYXQgaXQgbmVlZHMgdG8gYmUgYWJsZSB0byBoYW5kbGUgdGhlIGVuY2Fwc3VsYXRl ZCBjYXNlLg0KPiANCj4gWW91cnMsDQo+IEpvZWwNCj4gDQo+IE9uIDExLzYvMTggMzo1NiBQTSwg UGFibG8gQ2FtYXJpbGxvIChwY2FtYXJpbCkgd3JvdGU6DQo+PiBJIGZhaWwgdG8gc2VlIGhvdyB0 aGlzIG9wdGlvbiBpcyBzaW1wbGVyLg0KPj4gTm90ZSB0aGF0IGFzIG9wcG9zZWQgdG8gd2hhdCB5 b3Ugc3RhdGVkLCBob3N0cyBBIGFuZCBCIGdlbmVyYXRlIHRoZSBwYWNrZXQgYW5kIGFyZSBpbnNp ZGUgdGhlIFNSIGRvbWFpbi4NCj4+IEEgTGludXggaG9zdCBCIHdpbGwgcmVjZWl2ZSBJUChTUkgo SVAoVENQKC4uLikpKS4gV2hhdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgaW5uZXIgSVAgaGVhZGVy Pw0KPj4gT24gdG9wIG9mIHRoYXQsIHlvdSBjYW4gbGluayBhIFRDUC9VRFAgc29ja2V0IHdpdGgg YSBnaXZlbiBzZWdtZW50IHJvdXRpbmcgaGVhZGVyIFsxXS4gV2h5IHdvdWxkIEkgaW5zZXJ0IGhl cmUgYW4gSVAgaGVhZGVyPw0KPj4gSWYgeW91IGhhdmUgdGhlIHRpbWUgWzJdIGlzIGFuIGludGVy ZXN0aW5nIHJlYWQuIEluIHRoZXJlIHlvdSBoYXZlIGEgZ29vZCBsaXN0IG9mIGJlbmVmaXRzLg0K Pj4gSSBiZWxpZXZlIHRoYXQgaWYgaG9zdHMgQSBhbmQgQiBhcmUgd2l0aGluIHRoZSBTUiBkb21h aW4gLXdoaWNoIGlzIHRoZSBjYXNlIHdoZW4gaG9zdHMgQSBhbmQgQiBnZW5lcmF0ZSB0aGUgU1Ig aGVhZGVyLSwgdGhlbiB0aGVyZSBpcyBubyBiZW5lZml0IHRvIGludHJvZHVjZSBhbiBpbm5lciBJ UCBoZWFkZXIgYmVmb3JlIHRoZSBMNCBwYXlsb2FkLg0KPj4gVGhhbmtzLA0KPj4gUGFibG8uDQo+ PiBbMV0uIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdWNoZW5lLXNwcmluZy1z cnY2LXNvY2tldC0wMA0KPj4gWzJdLiBEYXZpZCBMZWJydW4sIE1hdGhpZXUgSmFkaW4sIEZyYW7D p29pcyBDbGFkLCBDbGFyZW5jZSBGaWxzZmlscywNCj4+IGFuZCBPbGl2aWVyIEJvbmF2ZW50dXJl LiAyMDE4LiBTb2Z0d2FyZSBSZXNvbHZlZCBOZXR3b3JrczogUmV0aGlua2luZw0KPj4gRW50ZXJw cmlzZSBOZXR3b3JrcyB3aXRoIElQdjYgU2VnbWVudCBSb3V0aW5nLiBJbiBTT1NSDQo+PiDigJkx ODogU09TUiDigJkxODogU3ltcG9zaXVtIG9uIFNETiBSZXNlYXJjaCwgTWFyY2ggMjbigJMyNywg MjAxOCwNCj4+IExvcyBBbmdlbGVzLCBDQSwgVVNBLiBBQ00sIE5ldyBZb3JrLCBOWSwgVVNBLCAx NCBwYWdlcy4NCj4+IGh0dHBzOi8vZG9pLm9yZy8xMC4xMTQ1LzMxODU0NjcuMzE4NTQ3MQ0KPj4g 77u/T24gMDYvMTEvMjAxOCwgMTU6MTQsICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBl cm4uY29tPiB3cm90ZToNCj4+ICAgICBZZXMsIEkgYW0gc2F5aW5nIHRoYXQgd2Ugc2hvdWxkIGFs d2F5cyB1c2UgSVAoU1JIKElQKC4uLikpKS4NCj4+ICAgICBUaGUgcmVhc29uIGlzIHNpbXBsaWNp dHkgYW5kIHJvYnVzdG5lc3MuDQo+PiAgICAgQXMgd2UgaGF2ZSBhbHJlYWR5IGRpc2N1c3NlZCwg dGhlIGhvc3QgaGFzIHRvIGJlIHByZXBhcmVkIHRvIGdlbmVyYXRlDQo+PiAgICAgdGhhdCBmb3Jt IGFuZCBwcm9jZXNzIHRoYXQgZm9ybSB3aGVuZXZlciBpdCBpcyB0YWxraW5nIHRvIHNvbWVvbmUN Cj4+ICAgICBvdXRzaWRlIHRoZSBTUiBEb21haW4uCQ0KPj4gICAgIEhhdmluZyB0d28gd2F5cyBv ZiBlbmNvZGluZyB0aGUgc2FtZSB0aGluZywgYW5kIHR3byBwcm9jZXNzaW5nIHBhdGhzIGZvcg0K Pj4gICAgIGdlbmVyYXRpbmcgLyBoYW5kbGluZyB0aGUgc2FtZSB0aGluZywgaW50cm9kdWNlcyBj b21wbGV4aXR5Lg0KPj4gICAgICAgICAgSWYgdGhlcmUgaXMgYSBzdHJvbmcgYmVuZWZpdCAoYmV5 b25kIHRoZSBudW1iZXIgb2YgYml0cyBpbiB0aGUgcGFja2V0KSwNCj4+ICAgICBJIHdvdWxkIGxp a2UgdG8gaGVhciBhYm91dCB0aGF0IGJlbmVmaXQuICBJIGNhbiBlYXNpbHkgYmVsaWV2ZSBJIG1p c3NlZA0KPj4gICAgIHNvbWV0aGluZy4NCj4+ICAgICAgICAgIEluIHRoZSBhYnNlbmNlIG9mIGEg YmVuZWZpdCwgY2hvaWNlcyBhcmUgaW4gYW5kIG9mIHRoZW1zZWx2ZXMgaGFybWZ1bC4NCj4+ICAg ICAgICAgIFlvdXJzLA0KPj4gICAgIEpvZWwNCj4+ICAgICAgICAgIE9uIDExLzYvMTggMzowOCBQ TSwgUGFibG8gQ2FtYXJpbGxvIChwY2FtYXJpbCkgd3JvdGU6DQo+PiAgICAgPiBIaSBKb2VsLA0K Pj4gICAgID4NCj4+ICAgICA+IFJlZ2FyZGluZyB5b3VyIHF1ZXN0aW9uIG9uIDZtYW4gYWJvdXQg dGhlIFNSSCBhbmQgYWxsb3dpbmcgb25seQ0KPj4gICAgID4gZW5jYXBzdWxhdGlvbjoNCj4+ICAg ICA+DQo+PiAgICAgPiBUaGVyZSBhcmUgdHdvIG9wZW4tc291cmNlIGhvc3QgaW1wbGVtZW50YXRp b25zIG9mIHRoZSBTUkggKExpbnV4IEtlcm5lbCwNCj4+ICAgICA+IEZELmlvIFZQUCkuIEkgd3Jv dGUgdGhlIGNvZGUgZm9yIFNSSCBpbiB0aGUgbGF0dGVyLg0KPj4gICAgID4NCj4+ICAgICA+IEEt LS0xLS0tMi0tLUINCj4+ICAgICA+DQo+PiAgICAgPiAoQSBhbmQgQiBhcmUgaG9zdHMpDQo+PiAg ICAgPg0KPj4gICAgID4gSW4gb25lIG9mIHRoZSB1c2UtY2FzZXMgaG9zdCBBIGhhcyBhd2FyZW5l c3Mgb2YgdGhlIHRyYW5zcG9ydCBuZXR3b3JrLg0KPj4gICAgID4NCj4+ICAgICA+IEhvc3QgQSBn ZW5lcmF0ZXMgYW5kIHNlbmRzIGEgcGFja2V0IG9mIHRoZSBmb3JtIElQKFNSSChUQ1AoLi4uKSkp IHdoZXJlDQo+PiAgICAgPiB0aGUgU1JIIGNvbnRhaW5zIHNlZ21lbnRzIDwxLDIsQj4uDQo+PiAg ICAgPg0KPj4gICAgID4gTm90ZSB0aGF0IEIgaXMgYW4gaW50ZXJmYWNlIGFkZHJlc3Mgb24gaG9z dCBCLg0KPj4gICAgID4NCj4+ICAgICA+IERvIHlvdSBiZWxpZXZlIHRoYXQgaW4gdGhpcyBjYXNl IHRoZSBob3N0IHNob3VsZCBzZW5kDQo+PiAgICAgPiBJUChTUkgoSVAoVENQKC4uLikpKSk/IElm IHllcywgd2h5Pw0KPj4gICAgID4NCj4+ICAgICA+IEkgdGhpbmsgdGhpcyBpcyBhIHJlbGV2YW50 IHVzZS1jYXNlIC1lLmcuIFBBTlJHLSwgYW5kIGRvbuKAmXQgc2VlIHdoeSB3ZQ0KPj4gICAgID4g d291bGQgZW5mb3JjZSBlbmNhcHN1bGF0aW9uLg0KPj4gICAgID4NCj4+ICAgICA+IFRoYW5rcywN Cj4+ICAgICA+DQo+PiAgICAgPiBQYWJsby4NCj4+ICAgICA+DQo+PiAgICAgDQoNCg== From nobody Tue Nov 6 02:37:55 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891B1130DC4 for ; Tue, 6 Nov 2018 02:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 k487WHMkHMwp for ; Tue, 6 Nov 2018 02:37:51 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 9473E130DC9 for ; Tue, 6 Nov 2018 02:37:51 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2E5E13ABDED; Tue, 6 Nov 2018 10:37:51 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 15CC3160050; Tue, 6 Nov 2018 10:37:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D5A9E160097; Tue, 6 Nov 2018 10:37:50 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9qtKK0r0TotB; Tue, 6 Nov 2018 10:37:50 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 71C7F160050; Tue, 6 Nov 2018 10:37:50 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-D5CDF6E1-0C65-4A07-9D1A-C0A9231594A4 Mime-Version: 1.0 (1.0) Subject: Re: Comments on IPv4-only flag document From: Mark Andrews X-Mailer: iPhone Mail (16A404) In-Reply-To: Date: Tue, 6 Nov 2018 21:37:46 +1100 Cc: Nick Hilliard , IETF IPv6 Mailing List Content-Transfer-Encoding: 7bit Message-Id: <0CE853AB-767D-41FD-A59A-07143D66E0AC@isc.org> References: <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> <7bd14b0f-a62e-e15e-29a1-dbd3a09b3aec@foobar.org> To: Lorenzo Colitti Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 10:37:53 -0000 --Apple-Mail-D5CDF6E1-0C65-4A07-9D1A-C0A9231594A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Working !=3D ipv4 link local.=20 --=20 Mark Andrews > On 6 Nov 2018, at 21:12, Lorenzo Colitti wrote: >=20 >> On Tue, 6 Nov 2018, 17:01 Nick Hilliard > What does the IETF say to the victims of this form of attack? That=20 >> their use case is not addressed and is therefore out of scope? >=20 >=20 > I proposed that what the IETF should say about this is: if a host already h= as a working IPv4 configuration, it SHOULD NOT not turn it off on receipt of= an IPv6-only flag. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-D5CDF6E1-0C65-4A07-9D1A-C0A9231594A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Working != ipv4 link local. 

    -- 
    Mark Andrews

    On 6 Nov 2018, at 21:12, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:

    On Tue, 6 Nov 2018, 17:01 Nick Hilliard <nick@foobar.org wrote:
    What does the IETF say to the victims of this form of attack?  That
    their use case is not addressed and is therefore out of scope?

    I proposed that what the IETF should say about this is: if a host already has a working IPv4 configuration, it SHOULD NOT not turn it off on receipt of an IPv6-only flag.
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --Apple-Mail-D5CDF6E1-0C65-4A07-9D1A-C0A9231594A4-- From nobody Tue Nov 6 02:53:34 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3E130DC4 for ; Tue, 6 Nov 2018 02:53:32 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 gtvy4i5fvJJm for ; Tue, 6 Nov 2018 02:53:29 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 C1C891277C8 for ; Tue, 6 Nov 2018 02:53:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7DCD02C056E; Tue, 6 Nov 2018 02:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1541501609; bh=cRkM3gp8zrWGN9KIH7hVnFbqkzn+i0mRlYP6VTAZbtg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gNc3kcR6VsqVA/MAu/zMWCt0kdSWKJaf9G2jC0gP905/gf7J8Qxjkf45rGsBmHDzx rAeAxD2R/sNcVbICyFLE5k9tLT29i1b58ypnaaktXukrCxfWHbRhmzyUkqYSZDg7aQ MD5h5MW5qIajeXOfT7mMKbq2JrKNkeLQNRhA48zc= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from dhcp-9f4f.meeting.ietf.org (unknown [IPv6:2001:67c:1232:144:9478:5251:141b:c977]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 049041C02A4; Tue, 6 Nov 2018 02:53:27 -0800 (PST) Subject: Re: Question 6man SRH encaps only To: "Darren Dukes (ddukes)" Cc: "Pablo Camarillo (pcamaril)" , "ipv6@ietf.org" References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> <9e3b89c3-0eee-84f5-2bbc-04b5399fd72b@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 6 Nov 2018 17:53:25 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 10:53:33 -0000 I do not understand your argument about a good base for future use. All the cases I know of can be handled with just the encapsulation mode. If there are issues that it can not handle, details on that would be good to hear them. Conversely, I don't see how the working group can decide that it needs a feature because some folks say that they think there is a use for it in the future. Yours, Joel On 11/6/18 5:28 PM, Darren Dukes (ddukes) wrote: > I think it depend on your view of simplicity. Simple to implement for a broad set of solutions or simple to specify? > > It is simple to specify a host must only encapsulate, or other restrictions but that doesn’t necessarily give us a strong base to build other specification. > > I prefer that we make sure the SRH draft define a good base on which other documents can be based to solve real problems beyond the very limited use cases we have defined. > > BTW It is simple to implement the socket based approach to apply an SR policy to a socket within an SR Domain - It is implemented, and it works. > > Darren > >> On Nov 6, 2018, at 4:44 AM, Joel M. Halpern wrote: >> >> The point is that a host inside the SR domain, when processing an SR policy, has to be prepared, for reasons we discussed on the list before the meeting, to generate the full IP(SR(IP(...))) packet format. Having an option to generate two different SR formats does not add value and does inherently add complexity. >> >> On the receive side, the host must also be prepared to receive both formats. One can argue that this is less of a burden, but it is still complexity. And we have already determined that it needs to be able to handle the encapsulated case. >> >> Yours, >> Joel >> >> On 11/6/18 3:56 PM, Pablo Camarillo (pcamaril) wrote: >>> I fail to see how this option is simpler. >>> Note that as opposed to what you stated, hosts A and B generate the packet and are inside the SR domain. >>> A Linux host B will receive IP(SRH(IP(TCP(...))). What is the purpose of the inner IP header? >>> On top of that, you can link a TCP/UDP socket with a given segment routing header [1]. Why would I insert here an IP header? >>> If you have the time [2] is an interesting read. In there you have a good list of benefits. >>> I believe that if hosts A and B are within the SR domain -which is the case when hosts A and B generate the SR header-, then there is no benefit to introduce an inner IP header before the L4 payload. >>> Thanks, >>> Pablo. >>> [1]. https://tools.ietf.org/html/draft-duchene-spring-srv6-socket-00 >>> [2]. David Lebrun, Mathieu Jadin, François Clad, Clarence Filsfils, >>> and Olivier Bonaventure. 2018. Software Resolved Networks: Rethinking >>> Enterprise Networks with IPv6 Segment Routing. In SOSR >>> ’18: SOSR ’18: Symposium on SDN Research, March 26–27, 2018, >>> Los Angeles, CA, USA. ACM, New York, NY, USA, 14 pages. >>> https://doi.org/10.1145/3185467.3185471 >>> On 06/11/2018, 15:14, "Joel M. Halpern" wrote: >>> Yes, I am saying that we should always use IP(SRH(IP(...))). >>> The reason is simplicity and robustness. >>> As we have already discussed, the host has to be prepared to generate >>> that form and process that form whenever it is talking to someone >>> outside the SR Domain. >>> Having two ways of encoding the same thing, and two processing paths for >>> generating / handling the same thing, introduces complexity. >>> If there is a strong benefit (beyond the number of bits in the packet), >>> I would like to hear about that benefit. I can easily believe I missed >>> something. >>> In the absence of a benefit, choices are in and of themselves harmful. >>> Yours, >>> Joel >>> On 11/6/18 3:08 PM, Pablo Camarillo (pcamaril) wrote: >>> > Hi Joel, >>> > >>> > Regarding your question on 6man about the SRH and allowing only >>> > encapsulation: >>> > >>> > There are two open-source host implementations of the SRH (Linux Kernel, >>> > FD.io VPP). I wrote the code for SRH in the latter. >>> > >>> > A---1---2---B >>> > >>> > (A and B are hosts) >>> > >>> > In one of the use-cases host A has awareness of the transport network. >>> > >>> > Host A generates and sends a packet of the form IP(SRH(TCP(...))) where >>> > the SRH contains segments <1,2,B>. >>> > >>> > Note that B is an interface address on host B. >>> > >>> > Do you believe that in this case the host should send >>> > IP(SRH(IP(TCP(...))))? If yes, why? >>> > >>> > I think this is a relevant use-case -e.g. PANRG-, and don’t see why we >>> > would enforce encapsulation. >>> > >>> > Thanks, >>> > >>> > Pablo. >>> > >>> > From nobody Tue Nov 6 03:23:52 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F54130DCE; Tue, 6 Nov 2018 03:23:36 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 TM9zWu2rIhz6; Tue, 6 Nov 2018 03:23:34 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B8BCD130DC4; Tue, 6 Nov 2018 03:23:34 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3E0E88366DAAC; Tue, 6 Nov 2018 11:23:31 +0000 (GMT) Received: from LHREML523-MBX.china.huawei.com ([169.254.7.239]) by lhreml707-cah.china.huawei.com ([10.201.108.48]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 11:23:29 +0000 From: "Yutianpeng (Tim)" To: "Henderickx, Wim (Nokia - BE/Antwerp)" , "Gert Doering" CC: "idr@ietf.org" , Fred Baker , "int-area@ietf.org" , "ipv6@ietf.org" Subject: RE: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Topic: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Thread-Index: AdR0BGE++Z0BF4I3RCC8M7+3nc3iHQAyVjcAAAmQjwAADT/zgAARARQAAA4u94AAAQq7gAAGDZKA Date: Tue, 6 Nov 2018 11:23:29 +0000 Message-ID: <35FF0D51C8DAB54B95B0426331F984FF5208F49A@lhreml523-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> <20181105165959.GB11393@Space.Net> <4B2F3673-5106-4914-B79F-F3C44013ED06@nokia.com> <20181106075259.GM11393@Space.Net> <58297F7F-5B02-495B-9E2C-87871342E317@nokia.com> In-Reply-To: <58297F7F-5B02-495B-9E2C-87871342E317@nokia.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.126.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 11:23:37 -0000 SGksDQpBcmUgeW91IHVzaW5nIFJGQyA2MDUyIG9ubHkgdG8gZW1iZWQgaXB2NCBpbnRvIGlwdjYg b25seSBvciBhbHNvIHVzaW5nIE1BUC1UIChyZmM3NTk5KS4NCkkgZ3Vlc3MgaXMgb25seSBSRkM2 MDUyIHJpZ2h0Pw0KTGV0J3MgcmVmZXIgdG8gUkZDIHRvIGhhdmUgYSBiZXR0ZXIgdW5kZXJzdGFu ZGluZy4NClRoYW5rcw0KVGltDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJ ZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlbmRlcmlja3gs IFdpbSAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KU2VudDogMDYgTm92ZW1iZXIgMjAxOCAwODoyMw0K VG86IEdlcnQgRG9lcmluZyA8Z2VydEBzcGFjZS5uZXQ+DQpDYzogaWRyQGlldGYub3JnOyBGcmVk IEJha2VyIDxmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+OyBpbnQtYXJlYUBpZXRmLm9yZzsgaXB2 NkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJZHJdIFVzaW5nIEJHUCB0byBhZHZlcnRpc2UgU0Qt V0FOIHR1bm5lbHMgZW5kIHBvaW50J3MgcHJpdmF0ZSBJUHY2IGFkZHJlc3Nlcy4gKHdhcyByZWdp c3RlcmluZyB0dW5uZWwgdHlwZXMNCg0KV2UgZG9u4oCZdCBwZXJmb3JtIGFueSBOQVQgb3BlcmF0 aW9uLiBMZXQncyBmaXJzdCBkaXNjdXNzIHRoZSBlbmNhcHN1bGF0aW9uOg0KSW4gU0QtV0FOIHRo ZXJlIGlzIGFuIElQIHR1bm5lbGluZyBvZiBzb21lIHNvcnQgKHRoZXJlIGFyZSBzZXZlcmFsIG9w dGlvbnMgYnV0IG5vdCByZWxldmFudCBoZXJlKS4gU28gd2UgaGF2ZSBhbiBpbm5lciBwYXlsb2Fk IHdoaWNoIGNhbiBiZSB2NCBvciB2NiBhbmQgZ29lcyBlbmQgdG8gZW5kLCB0aGUgaW5uZXIgcGF5 bG9hZCBpcyBlbmNhcHN1bGF0ZWQgaW4gYW4gb3V0ZXIgSVAgdHVubmVsLg0KDQpTbyB3aGF0IGhh cHBlbnMgaXMgdGhlIGZvbGxvd2luZy4gSSBtYWtlIGFic3RyYWN0aW9uIG9mIGlubmVyIHBheWxv YWQNCg0KU0QtV0FOIENQRTIgKHY0KQ0KU0QtV0FOIENQRTEgKHY0KSA8LS0tLS0tLS0tLS0gdjQg LS0tLS0tLS0tPiBHVyA8LS0tLS0tLS0tLS0tLS0tLS12NiAtLS0tLS0tLS0tLS0tID4gU0QtV0FO IENQRTModjYpLg0KDQpVcHN0cmVhbSB0cmFmZmljIGZyb20gU0QtV0FOIENQRTENCnNyYy1pcCB2 NDogQTEsIGRzdC1JUCB2NCBCMSAtLS0tLS0tLS0tLS0tLS0+IG1hcHBpbmcgPCBzcmMtSXAgdjY6 IEMxLCBkc3QtaXAgdjYgRDEgLS0tLS0+IA0KDQpVcHN0cmVhbSB0cmFmZmljIGZyb20gU0QtV0FO IENQRTINCnNyYy1pcCB2NDogQTIsIGRzdC1JUCB2NCBCMSAtLS0tLS0tLS0tLS0tLS0+IG1hcHBp bmcgPCBzcmMtSXAgdjY6IEMxLCBkc3QtaXAgdjYgRDEgLS0tLS0+DQoNClNvIGlycmVzcGVjdGl2 ZSBvZiB3aGljaCBzcmMtQ1BFIDEgb3IgMiBpcyBzZW5kaW5nIHRvIHRoZSB2NiBTRC1XQU4gQ1BF MyB3aWxsIHVzZSB0aGUgc2FtZSBzcmMvZHN0IHY2IGFkZHJlc3MNCg0KV2l0aCBOQVQ2NCBldmVu IHN0YXRlbGVzcyB0aGUgc3JjLUlQIG9yIHNyYy1wb3J0IHdpbGwgYmUgZGlmZmVyZW50IHRvIGVu c3VyZSB5b3UgY2FuIG1hcCB0aGUgcmV2ZXJzZS4NClRoaXMgaXMgYWxzbyB1c2VkIHRvIG1hcCBw cml2YXRlIElQdjQgdG8gcHVibGljIElwdjQsIGV0YyBhbmQgbWFueSBvdGhlciBvcGVyYXRpb25z Lg0KDQoNCu+7v09uIDA2LzExLzIwMTgsIDE0OjUzLCAiR2VydCBEb2VyaW5nIiA8Z2VydEBzcGFj ZS5uZXQ+IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAgT24gVHVlLCBOb3YgMDYsIDIwMTgg YXQgMDE6MDY6NTJBTSArMDAwMCwgSGVuZGVyaWNreCwgV2ltIChOb2tpYSAtIEJFL0FudHdlcnAp IHdyb3RlOg0KICAgID4gRXZlbiBhIE5BVDY0IGlzIG5vdCBuZWVkZWQuIFdoYXQgd2UgZG8gbm93 IGlzIHdlIGdvIHRvIGEgR1cgKGxldHMgY2FsbCBpdCBsaWtlIHRoaXMgZm9yIG5vdykgYW5kIHRo ZSBHVyByZXdyaXRlcyB0aGUgb3V0ZXIgaGVhZGVyIG9mIHRoZSB0dW5uZWwgc3JjSVAgYW5kIGRz dElQIGZyb20gdjQgdG8gdjYgb3IgdmljZSB2ZXJzYS4gSXQgaXMga2luZCBvZiBkZWNhcC9lbmNh cCBvcGVyYXRpb24gb24gdGhlIG91dGVyIGhlYWRlciBhcyBpZiB5b3UgdGVybWluYXRlIHRoZSB0 dW5uZWwgYW5kIHJlaW5pdGlhdGUgdGhlIHR1bm5lbC4gTm8gTkFUNjQgcmVxdWlyZWQuDQogICAg PiANCiAgICANCiAgICBTbyBob3cgZXhhY3RseSBpcyB0aGlzIGRpZmZlcmVudCBmcm9tIGEgTkFU NjQ/DQogICAgDQogICAgIllvdSB0YWtlIG9mZiB0aGUgSVB2NCBoZWFkZXIsIHB1dCBvbiBhbiBJ UHY2IGhlYWRlciwgYW5kIHJlbWVtYmVyIHdoZXJlDQogICAgdGhlIHJlc3BvbnNlIHBhY2tldHMg bmVlZHMgdG8gYmUgc2VudCB0byINCiAgICANCiAgICBJZiB5b3UgcHJlY29uZmlndXJlIHRoZSBt YXBwaW5nLCBpdCdzIHN0aWxsIGEgTkFUNjQgOi0pDQogICAgDQogICAgR2VydCBEb2VyaW5nDQog ICAgICAgICAgICAtLSBOZXRNYXN0ZXINCiAgICAtLSANCiAgICBoYXZlIHlvdSBlbmFibGVkIElQ djYgb24gc29tZXRoaW5nIHRvZGF5Li4uPw0KICAgIA0KICAgIFNwYWNlTmV0IEFHICAgICAgICAg ICAgICAgICAgICAgIFZvcnN0YW5kOiBTZWJhc3RpYW4gdi4gQm9taGFyZCwgTWljaGFlbCBFbW1l cg0KICAgIEpvc2VwaC1Eb2xsaW5nZXItQm9nZW4gMTQgICAgICAgIEF1ZnNpY2h0c3JhdHN2b3Jz LjogQS4gR3J1bmRuZXItQ3VsZW1hbm4NCiAgICBELTgwODA3IE11ZW5jaGVuICAgICAgICAgICAg ICAgICBIUkI6IDEzNjA1NSAoQUcgTXVlbmNoZW4pDQogICAgVGVsOiArNDkgKDApODkvMzIzNTYt NDQ0ICAgICAgICAgVVN0LUlkTnIuOiBERTgxMzE4NTI3OQ0KICAgIA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRy QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Tue Nov 6 03:45:00 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D4312F1AC for ; Tue, 6 Nov 2018 03:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 r-C-pUB6FXlh for ; Tue, 6 Nov 2018 03:44:57 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C417512D4F1 for ; Tue, 6 Nov 2018 03:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7538; q=dns/txt; s=iport; t=1541504696; x=1542714296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FxYYmezjOvS9PYdKH14VfNoQZqdPgrKo5r5Hwc0zSNE=; b=YgeYgpSVq0xyEKzUcKrzQgVFalt+eQRo+2ZAvzobet12I16uCiG5wYKh JE5SuEcTR/vDKVWiX8tPr/aP32EzjGzIvBYugkEoms7heMmlHtpnyROdv 0jeEGBLgZ7khgNjAwLuwgg6Jf0tvd5TrAmLlUBJqFudX+5pxIn5+LebrH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACrfeFb/4sNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVUuZoECJwqDbIgYjgAllzAUgWYLAQE?= =?us-ascii?q?jCYFLgnUCF4NBIjQNDQEDAQECAQECbRwMhToBAQEBAgEjEUUFCwIBCBgCAiY?= =?us-ascii?q?CAgIwFRACBA4FGwSDAgGBeQgPqA+BLoQtAQMCgQmEdoELimsXgUE/gREnDBO?= =?us-ascii?q?CTIMbAQEDgSIVPoJtMYImAoh5DgGWLgkChm2KIxiBVogihmmNDIoXAhEUgSY?= =?us-ascii?q?dOIFVcBU7KgGCQQmIYoIwhT5yAYEnijqBLgGBHgEB?= X-IronPort-AV: E=Sophos;i="5.54,471,1534809600"; d="scan'208";a="196920048" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 11:44:55 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id wA6Bitbj009919 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2018 11:44:55 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Nov 2018 05:44:54 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Tue, 6 Nov 2018 05:44:54 -0600 From: "Darren Dukes (ddukes)" To: "Joel M. Halpern" CC: "Pablo Camarillo (pcamaril)" , "ipv6@ietf.org" Subject: Re: Question 6man SRH encaps only Thread-Topic: Question 6man SRH encaps only Thread-Index: AQHUdafa15+XY1Mf/0a+ctWznq09V6VCyqYAgACBLwD//5gXgIAADDiAgAAHA4CAAA5hgA== Date: Tue, 6 Nov 2018 11:44:54 +0000 Message-ID: <229D9953-62DF-4796-914C-C9DA120202C2@cisco.com> References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> <9e3b89c3-0eee-84f5-2bbc-04b5399fd72b@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.26] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 11:44:59 -0000 Sm9lbCwgZm9yY2luZyBldmVyeSBob3N0IHRvIHBsYWNlIGFuIG91dGVyIGVuY2Fwc3VsYXRpb24g b24gYSBwYWNrZXQg4oCYYmVjYXVzZSB0aGVyZSBpcyBubyByZWFzb24gaXQgd29u4oCZdCB3b3Jr 4oCZIGlzIG5vdCBqdXN0aWZpY2F0aW9uLiAgSXTigJlzIGxpa2UgZm9yY2luZyBldmVyeSBob3N0 IHRvIHVzZSBJUFNlYyBiZWNhdXNlIHRoZXJlIGlzIG5vIHJlYXNvbiBpdCB3b27igJl0IHdvcmsu DQoNClRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIGludHJhLWRvbWFpbiBjb21tdW5pY2F0aW9uIGlu IHRoZSBkcmFmdC4gDQpUaGVyZSBpcyBubyBqdXN0aWZpY2F0aW9uIGZvciBhbiBhZGRpdGlvbmFs IG91dGVyIElQIGVuY2Fwc3VsYXRpb24gaW4gdGhhdCBjYXNlLiANCkl0IGlzIGltcGxlbWVudGVk IGFuZCB3b3Jrcy4NCg0KRGFycmVuDQoNCg0KPiBPbiBOb3YgNiwgMjAxOCwgYXQgNTo1MyBBTSwg Sm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4gDQo+IEkgZG8g bm90IHVuZGVyc3RhbmQgeW91ciBhcmd1bWVudCBhYm91dCBhIGdvb2QgYmFzZSBmb3IgZnV0dXJl IHVzZS4NCj4gDQo+IEFsbCB0aGUgY2FzZXMgSSBrbm93IG9mIGNhbiBiZSBoYW5kbGVkIHdpdGgg anVzdCB0aGUgZW5jYXBzdWxhdGlvbiBtb2RlLiAgSWYgdGhlcmUgYXJlIGlzc3VlcyB0aGF0IGl0 IGNhbiBub3QgaGFuZGxlLCBkZXRhaWxzIG9uIHRoYXQgd291bGQgYmUgZ29vZCB0byBoZWFyIHRo ZW0uICBDb252ZXJzZWx5LCBJIGRvbid0IHNlZSBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgY2FuIGRl Y2lkZSB0aGF0IGl0IG5lZWRzIGEgZmVhdHVyZSBiZWNhdXNlIHNvbWUgZm9sa3Mgc2F5IHRoYXQg dGhleSB0aGluayB0aGVyZSBpcyBhIHVzZSBmb3IgaXQgaW4gdGhlIGZ1dHVyZS4NCj4gDQo+IFlv dXJzLA0KPiBKb2VsDQo+IA0KPiBPbiAxMS82LzE4IDU6MjggUE0sIERhcnJlbiBEdWtlcyAoZGR1 a2VzKSB3cm90ZToNCj4+IEkgdGhpbmsgaXQgZGVwZW5kIG9uIHlvdXIgdmlldyBvZiBzaW1wbGlj aXR5LiAgU2ltcGxlIHRvIGltcGxlbWVudCBmb3IgYSBicm9hZCBzZXQgb2Ygc29sdXRpb25zIG9y IHNpbXBsZSB0byBzcGVjaWZ5Pw0KPj4gSXQgaXMgc2ltcGxlIHRvIHNwZWNpZnkgYSBob3N0IG11 c3Qgb25seSBlbmNhcHN1bGF0ZSwgb3Igb3RoZXIgcmVzdHJpY3Rpb25zIGJ1dCB0aGF0IGRvZXNu 4oCZdCBuZWNlc3NhcmlseSBnaXZlIHVzIGEgc3Ryb25nIGJhc2UgdG8gYnVpbGQgb3RoZXIgc3Bl Y2lmaWNhdGlvbi4NCj4+IEkgcHJlZmVyIHRoYXQgd2UgbWFrZSBzdXJlIHRoZSBTUkggZHJhZnQg ZGVmaW5lIGEgZ29vZCBiYXNlIG9uIHdoaWNoIG90aGVyIGRvY3VtZW50cyBjYW4gYmUgYmFzZWQg dG8gc29sdmUgcmVhbCBwcm9ibGVtcyBiZXlvbmQgdGhlIHZlcnkgbGltaXRlZCB1c2UgY2FzZXMg d2UgaGF2ZSBkZWZpbmVkLg0KPj4gQlRXIEl0IGlzIHNpbXBsZSB0byBpbXBsZW1lbnQgdGhlIHNv Y2tldCBiYXNlZCBhcHByb2FjaCB0byBhcHBseSBhbiBTUiBwb2xpY3kgdG8gYSBzb2NrZXQgd2l0 aGluIGFuIFNSIERvbWFpbiAtIEl0IGlzIGltcGxlbWVudGVkLCBhbmQgaXQgd29ya3MuDQo+PiBE YXJyZW4NCj4+PiBPbiBOb3YgNiwgMjAxOCwgYXQgNDo0NCBBTSwgSm9lbCBNLiBIYWxwZXJuIDxq bWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4+PiANCj4+PiBUaGUgcG9pbnQgaXMgdGhhdCBh IGhvc3QgaW5zaWRlIHRoZSBTUiBkb21haW4sIHdoZW4gcHJvY2Vzc2luZyBhbiBTUiBwb2xpY3ks IGhhcyB0byBiZSBwcmVwYXJlZCwgZm9yIHJlYXNvbnMgd2UgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0 IGJlZm9yZSB0aGUgbWVldGluZywgdG8gZ2VuZXJhdGUgdGhlIGZ1bGwgSVAoU1IoSVAoLi4uKSkp IHBhY2tldCBmb3JtYXQuICBIYXZpbmcgYW4gb3B0aW9uIHRvIGdlbmVyYXRlIHR3byBkaWZmZXJl bnQgU1IgZm9ybWF0cyBkb2VzIG5vdCBhZGQgdmFsdWUgYW5kIGRvZXMgaW5oZXJlbnRseSBhZGQg Y29tcGxleGl0eS4NCj4+PiANCj4+PiBPbiB0aGUgcmVjZWl2ZSBzaWRlLCB0aGUgaG9zdCBtdXN0 IGFsc28gYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBib3RoIGZvcm1hdHMuICBPbmUgY2FuIGFyZ3Vl IHRoYXQgdGhpcyBpcyBsZXNzIG9mIGEgYnVyZGVuLCBidXQgaXQgaXMgc3RpbGwgY29tcGxleGl0 eS4gIEFuZCB3ZSBoYXZlIGFscmVhZHkgZGV0ZXJtaW5lZCB0aGF0IGl0IG5lZWRzIHRvIGJlIGFi bGUgdG8gaGFuZGxlIHRoZSBlbmNhcHN1bGF0ZWQgY2FzZS4NCj4+PiANCj4+PiBZb3VycywNCj4+ PiBKb2VsDQo+Pj4gDQo+Pj4gT24gMTEvNi8xOCAzOjU2IFBNLCBQYWJsbyBDYW1hcmlsbG8gKHBj YW1hcmlsKSB3cm90ZToNCj4+Pj4gSSBmYWlsIHRvIHNlZSBob3cgdGhpcyBvcHRpb24gaXMgc2lt cGxlci4NCj4+Pj4gTm90ZSB0aGF0IGFzIG9wcG9zZWQgdG8gd2hhdCB5b3Ugc3RhdGVkLCBob3N0 cyBBIGFuZCBCIGdlbmVyYXRlIHRoZSBwYWNrZXQgYW5kIGFyZSBpbnNpZGUgdGhlIFNSIGRvbWFp bi4NCj4+Pj4gQSBMaW51eCBob3N0IEIgd2lsbCByZWNlaXZlIElQKFNSSChJUChUQ1AoLi4uKSkp LiBXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBpbm5lciBJUCBoZWFkZXI/DQo+Pj4+IE9uIHRv cCBvZiB0aGF0LCB5b3UgY2FuIGxpbmsgYSBUQ1AvVURQIHNvY2tldCB3aXRoIGEgZ2l2ZW4gc2Vn bWVudCByb3V0aW5nIGhlYWRlciBbMV0uIFdoeSB3b3VsZCBJIGluc2VydCBoZXJlIGFuIElQIGhl YWRlcj8NCj4+Pj4gSWYgeW91IGhhdmUgdGhlIHRpbWUgWzJdIGlzIGFuIGludGVyZXN0aW5nIHJl YWQuIEluIHRoZXJlIHlvdSBoYXZlIGEgZ29vZCBsaXN0IG9mIGJlbmVmaXRzLg0KPj4+PiBJIGJl bGlldmUgdGhhdCBpZiBob3N0cyBBIGFuZCBCIGFyZSB3aXRoaW4gdGhlIFNSIGRvbWFpbiAtd2hp Y2ggaXMgdGhlIGNhc2Ugd2hlbiBob3N0cyBBIGFuZCBCIGdlbmVyYXRlIHRoZSBTUiBoZWFkZXIt LCB0aGVuIHRoZXJlIGlzIG5vIGJlbmVmaXQgdG8gaW50cm9kdWNlIGFuIGlubmVyIElQIGhlYWRl ciBiZWZvcmUgdGhlIEw0IHBheWxvYWQuDQo+Pj4+IFRoYW5rcywNCj4+Pj4gUGFibG8uDQo+Pj4+ IFsxXS4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1Y2hlbmUtc3ByaW5nLXNy djYtc29ja2V0LTAwDQo+Pj4+IFsyXS4gRGF2aWQgTGVicnVuLCBNYXRoaWV1IEphZGluLCBGcmFu w6dvaXMgQ2xhZCwgQ2xhcmVuY2UgRmlsc2ZpbHMsDQo+Pj4+IGFuZCBPbGl2aWVyIEJvbmF2ZW50 dXJlLiAyMDE4LiBTb2Z0d2FyZSBSZXNvbHZlZCBOZXR3b3JrczogUmV0aGlua2luZw0KPj4+PiBF bnRlcnByaXNlIE5ldHdvcmtzIHdpdGggSVB2NiBTZWdtZW50IFJvdXRpbmcuIEluIFNPU1INCj4+ Pj4g4oCZMTg6IFNPU1Ig4oCZMTg6IFN5bXBvc2l1bSBvbiBTRE4gUmVzZWFyY2gsIE1hcmNoIDI2 4oCTMjcsIDIwMTgsDQo+Pj4+IExvcyBBbmdlbGVzLCBDQSwgVVNBLiBBQ00sIE5ldyBZb3JrLCBO WSwgVVNBLCAxNCBwYWdlcy4NCj4+Pj4gaHR0cHM6Ly9kb2kub3JnLzEwLjExNDUvMzE4NTQ2Ny4z MTg1NDcxDQo+Pj4+IO+7v09uIDA2LzExLzIwMTgsIDE1OjE0LCAiSm9lbCBNLiBIYWxwZXJuIiA8 am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4+ICAgICBZZXMsIEkgYW0gc2F5aW5nIHRo YXQgd2Ugc2hvdWxkIGFsd2F5cyB1c2UgSVAoU1JIKElQKC4uLikpKS4NCj4+Pj4gICAgIFRoZSBy ZWFzb24gaXMgc2ltcGxpY2l0eSBhbmQgcm9idXN0bmVzcy4NCj4+Pj4gICAgIEFzIHdlIGhhdmUg YWxyZWFkeSBkaXNjdXNzZWQsIHRoZSBob3N0IGhhcyB0byBiZSBwcmVwYXJlZCB0byBnZW5lcmF0 ZQ0KPj4+PiAgICAgdGhhdCBmb3JtIGFuZCBwcm9jZXNzIHRoYXQgZm9ybSB3aGVuZXZlciBpdCBp cyB0YWxraW5nIHRvIHNvbWVvbmUNCj4+Pj4gICAgIG91dHNpZGUgdGhlIFNSIERvbWFpbi4JDQo+ Pj4+ICAgICBIYXZpbmcgdHdvIHdheXMgb2YgZW5jb2RpbmcgdGhlIHNhbWUgdGhpbmcsIGFuZCB0 d28gcHJvY2Vzc2luZyBwYXRocyBmb3INCj4+Pj4gICAgIGdlbmVyYXRpbmcgLyBoYW5kbGluZyB0 aGUgc2FtZSB0aGluZywgaW50cm9kdWNlcyBjb21wbGV4aXR5Lg0KPj4+PiAgICAgICAgICBJZiB0 aGVyZSBpcyBhIHN0cm9uZyBiZW5lZml0IChiZXlvbmQgdGhlIG51bWJlciBvZiBiaXRzIGluIHRo ZSBwYWNrZXQpLA0KPj4+PiAgICAgSSB3b3VsZCBsaWtlIHRvIGhlYXIgYWJvdXQgdGhhdCBiZW5l Zml0LiAgSSBjYW4gZWFzaWx5IGJlbGlldmUgSSBtaXNzZWQNCj4+Pj4gICAgIHNvbWV0aGluZy4N Cj4+Pj4gICAgICAgICAgSW4gdGhlIGFic2VuY2Ugb2YgYSBiZW5lZml0LCBjaG9pY2VzIGFyZSBp biBhbmQgb2YgdGhlbXNlbHZlcyBoYXJtZnVsLg0KPj4+PiAgICAgICAgICBZb3VycywNCj4+Pj4g ICAgIEpvZWwNCj4+Pj4gICAgICAgICAgT24gMTEvNi8xOCAzOjA4IFBNLCBQYWJsbyBDYW1hcmls bG8gKHBjYW1hcmlsKSB3cm90ZToNCj4+Pj4gICAgID4gSGkgSm9lbCwNCj4+Pj4gICAgID4NCj4+ Pj4gICAgID4gUmVnYXJkaW5nIHlvdXIgcXVlc3Rpb24gb24gNm1hbiBhYm91dCB0aGUgU1JIIGFu ZCBhbGxvd2luZyBvbmx5DQo+Pj4+ICAgICA+IGVuY2Fwc3VsYXRpb246DQo+Pj4+ICAgICA+DQo+ Pj4+ICAgICA+IFRoZXJlIGFyZSB0d28gb3Blbi1zb3VyY2UgaG9zdCBpbXBsZW1lbnRhdGlvbnMg b2YgdGhlIFNSSCAoTGludXggS2VybmVsLA0KPj4+PiAgICAgPiBGRC5pbyBWUFApLiBJIHdyb3Rl IHRoZSBjb2RlIGZvciBTUkggaW4gdGhlIGxhdHRlci4NCj4+Pj4gICAgID4NCj4+Pj4gICAgID4g QS0tLTEtLS0yLS0tQg0KPj4+PiAgICAgPg0KPj4+PiAgICAgPiAoQSBhbmQgQiBhcmUgaG9zdHMp DQo+Pj4+ICAgICA+DQo+Pj4+ICAgICA+IEluIG9uZSBvZiB0aGUgdXNlLWNhc2VzIGhvc3QgQSBo YXMgYXdhcmVuZXNzIG9mIHRoZSB0cmFuc3BvcnQgbmV0d29yay4NCj4+Pj4gICAgID4NCj4+Pj4g ICAgID4gSG9zdCBBIGdlbmVyYXRlcyBhbmQgc2VuZHMgYSBwYWNrZXQgb2YgdGhlIGZvcm0gSVAo U1JIKFRDUCguLi4pKSkgd2hlcmUNCj4+Pj4gICAgID4gdGhlIFNSSCBjb250YWlucyBzZWdtZW50 cyA8MSwyLEI+Lg0KPj4+PiAgICAgPg0KPj4+PiAgICAgPiBOb3RlIHRoYXQgQiBpcyBhbiBpbnRl cmZhY2UgYWRkcmVzcyBvbiBob3N0IEIuDQo+Pj4+ICAgICA+DQo+Pj4+ICAgICA+IERvIHlvdSBi ZWxpZXZlIHRoYXQgaW4gdGhpcyBjYXNlIHRoZSBob3N0IHNob3VsZCBzZW5kDQo+Pj4+ICAgICA+ IElQKFNSSChJUChUQ1AoLi4uKSkpKT8gSWYgeWVzLCB3aHk/DQo+Pj4+ICAgICA+DQo+Pj4+ICAg ICA+IEkgdGhpbmsgdGhpcyBpcyBhIHJlbGV2YW50IHVzZS1jYXNlIC1lLmcuIFBBTlJHLSwgYW5k IGRvbuKAmXQgc2VlIHdoeSB3ZQ0KPj4+PiAgICAgPiB3b3VsZCBlbmZvcmNlIGVuY2Fwc3VsYXRp b24uDQo+Pj4+ICAgICA+DQo+Pj4+ICAgICA+IFRoYW5rcywNCj4+Pj4gICAgID4NCj4+Pj4gICAg ID4gUGFibG8uDQo+Pj4+ICAgICA+DQo+Pj4+ICAgICANCg0K From nobody Tue Nov 6 06:11:24 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A0D124BAA for ; Tue, 6 Nov 2018 06:11:23 -0800 (PST) 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, 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 Fnn6KCv-yFOA for ; Tue, 6 Nov 2018 06:11:19 -0800 (PST) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B6D130DE2 for ; Tue, 6 Nov 2018 06:11:16 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 2821E8D4A217; Tue, 6 Nov 2018 14:11:15 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 782D1D1F8F3; Tue, 6 Nov 2018 14:11:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id JiLldZUpy7ji; Tue, 6 Nov 2018 14:11:12 +0000 (UTC) Received: from [10.248.105.184] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9802FD1F83F; Tue, 6 Nov 2018 14:11:12 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Lorenzo Colitti" Cc: "IETF IPv6 Mailing List" Subject: Re: Comments on IPv4-only flag document Date: Tue, 06 Nov 2018 14:11:14 +0000 X-Mailer: MailMate (2.0BETAr6126) Message-ID: <5B0E93C5-B4C8-466B-8908-F93826CE56E8@lists.zabbadoz.net> In-Reply-To: References: <1AF860F7-3B4B-4F11-A6C0-12ED8A1595C4@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 14:11:23 -0000 On 6 Nov 2018, at 8:39, Lorenzo Colitti wrote: > No, it's not what I'm asking for. That text doesn't address the case > where > the RA was sent by an attacker on an IPv4-only network that is > currently > working just fine. That is the case for the majority of networks > today. > Such networks very likely don't have RA guard because they have never > had a > need for it. Ok, so in Section 9 there’s a paragraph starting with “A bad actor could use this mechanism to attempt turn off IPv4 service [..]” If that paragraph would be more explicit: A bad actor could use this mechanism to attempt turn off IPv4 service on a link that is intentionally using IPv4, by sending Router Advertisements with the IPv6-Only flag set to 1. If a host has working IPv4 services or connectivity and receives a Router Advertisements packet with the IPv6-only flag set to 1 on the same link without any other IPv6 configuration (i.e., an otherwise IPv4-only link), it SHOULD consider the IPv6-Only flag a configuration error and MAY continue to use IPv4. In the case that there are one or more legitimate routers on that link sending Router Advertisements with this flag set to 0, they would override this attack given the mechanism in Section 5. (and continued as there is already) Would that work for people? /bz From nobody Tue Nov 6 07:08:10 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FF2130DFE for ; Tue, 6 Nov 2018 07:08:08 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 cTZFhjtXSVld for ; Tue, 6 Nov 2018 07:08:05 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 319CE129C6A for ; Tue, 6 Nov 2018 07:08:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E13932C9A3D; Tue, 6 Nov 2018 07:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1541516884; bh=KqQ7vtZPygcnfcHrJlc8CT2G5+h7FVACVSAHWGssb9g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MC0tV0zPdm+Wl3QQXZw0z46B5orbIjoCqNLxIMDxvc3XhCfxxzbcvX528XReZQcI/ syePSEWzlFWmJyjbJkw+krL2rbJY6hTG3pEdChP+QTAWel9TjgwEEZxnXAyyEJ2qap ahq3GWTmDQfOPutUPZ0uJlgh9DJEMjiqMn84ybF4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from dhcp-9f4f.meeting.ietf.org (unknown [IPv6:2001:67c:1232:144:9478:5251:141b:c977]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 34FE02C9A3C; Tue, 6 Nov 2018 07:08:02 -0800 (PST) Subject: Re: Question 6man SRH encaps only To: "Darren Dukes (ddukes)" , "Joel M. Halpern" Cc: "Pablo Camarillo (pcamaril)" , "ipv6@ietf.org" References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> <9e3b89c3-0eee-84f5-2bbc-04b5399fd72b@joelhalpern.com> <229D9953-62DF-4796-914C-C9DA120202C2@cisco.com> From: Joel Halpern Direct Message-ID: Date: Tue, 6 Nov 2018 22:08:01 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <229D9953-62DF-4796-914C-C9DA120202C2@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 15:08:08 -0000 Darren, as I understand it, we have already agreed that hosts have to have the capability to generate and process encapsulated messages. With two representations, we have to have capabilities in the configuration and the SR Policy to indicate which one is to be used when. As far as I know, there is no simple rule the hosts can follow, as there is no obvious way a priori to know that a destination is in the same SR domain. Across our protocols, we have found that having multiple ways of doing the same thing generally makes life harder. So I am asking taht we either articulate a significant benefit from having such duplication, or we not duplicate capability. Yours, Joel On 11/6/18 6:44 PM, Darren Dukes (ddukes) wrote: > Joel, forcing every host to place an outer encapsulation on a packet ‘because there is no reason it won’t work’ is not justification. It’s like forcing every host to use IPSec because there is no reason it won’t work. > > There are use cases for intra-domain communication in the draft. > There is no justification for an additional outer IP encapsulation in that case. > It is implemented and works. > > Darren > > >> On Nov 6, 2018, at 5:53 AM, Joel M. Halpern wrote: >> >> I do not understand your argument about a good base for future use. >> >> All the cases I know of can be handled with just the encapsulation mode. If there are issues that it can not handle, details on that would be good to hear them. Conversely, I don't see how the working group can decide that it needs a feature because some folks say that they think there is a use for it in the future. >> >> Yours, >> Joel >> >> On 11/6/18 5:28 PM, Darren Dukes (ddukes) wrote: >>> I think it depend on your view of simplicity. Simple to implement for a broad set of solutions or simple to specify? >>> It is simple to specify a host must only encapsulate, or other restrictions but that doesn’t necessarily give us a strong base to build other specification. >>> I prefer that we make sure the SRH draft define a good base on which other documents can be based to solve real problems beyond the very limited use cases we have defined. >>> BTW It is simple to implement the socket based approach to apply an SR policy to a socket within an SR Domain - It is implemented, and it works. >>> Darren >>>> On Nov 6, 2018, at 4:44 AM, Joel M. Halpern wrote: >>>> >>>> The point is that a host inside the SR domain, when processing an SR policy, has to be prepared, for reasons we discussed on the list before the meeting, to generate the full IP(SR(IP(...))) packet format. Having an option to generate two different SR formats does not add value and does inherently add complexity. >>>> >>>> On the receive side, the host must also be prepared to receive both formats. One can argue that this is less of a burden, but it is still complexity. And we have already determined that it needs to be able to handle the encapsulated case. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/6/18 3:56 PM, Pablo Camarillo (pcamaril) wrote: >>>>> I fail to see how this option is simpler. >>>>> Note that as opposed to what you stated, hosts A and B generate the packet and are inside the SR domain. >>>>> A Linux host B will receive IP(SRH(IP(TCP(...))). What is the purpose of the inner IP header? >>>>> On top of that, you can link a TCP/UDP socket with a given segment routing header [1]. Why would I insert here an IP header? >>>>> If you have the time [2] is an interesting read. In there you have a good list of benefits. >>>>> I believe that if hosts A and B are within the SR domain -which is the case when hosts A and B generate the SR header-, then there is no benefit to introduce an inner IP header before the L4 payload. >>>>> Thanks, >>>>> Pablo. >>>>> [1]. https://tools.ietf.org/html/draft-duchene-spring-srv6-socket-00 >>>>> [2]. David Lebrun, Mathieu Jadin, François Clad, Clarence Filsfils, >>>>> and Olivier Bonaventure. 2018. Software Resolved Networks: Rethinking >>>>> Enterprise Networks with IPv6 Segment Routing. In SOSR >>>>> ’18: SOSR ’18: Symposium on SDN Research, March 26–27, 2018, >>>>> Los Angeles, CA, USA. ACM, New York, NY, USA, 14 pages. >>>>> https://doi.org/10.1145/3185467.3185471 >>>>> On 06/11/2018, 15:14, "Joel M. Halpern" wrote: >>>>> Yes, I am saying that we should always use IP(SRH(IP(...))). >>>>> The reason is simplicity and robustness. >>>>> As we have already discussed, the host has to be prepared to generate >>>>> that form and process that form whenever it is talking to someone >>>>> outside the SR Domain. >>>>> Having two ways of encoding the same thing, and two processing paths for >>>>> generating / handling the same thing, introduces complexity. >>>>> If there is a strong benefit (beyond the number of bits in the packet), >>>>> I would like to hear about that benefit. I can easily believe I missed >>>>> something. >>>>> In the absence of a benefit, choices are in and of themselves harmful. >>>>> Yours, >>>>> Joel >>>>> On 11/6/18 3:08 PM, Pablo Camarillo (pcamaril) wrote: >>>>> > Hi Joel, >>>>> > >>>>> > Regarding your question on 6man about the SRH and allowing only >>>>> > encapsulation: >>>>> > >>>>> > There are two open-source host implementations of the SRH (Linux Kernel, >>>>> > FD.io VPP). I wrote the code for SRH in the latter. >>>>> > >>>>> > A---1---2---B >>>>> > >>>>> > (A and B are hosts) >>>>> > >>>>> > In one of the use-cases host A has awareness of the transport network. >>>>> > >>>>> > Host A generates and sends a packet of the form IP(SRH(TCP(...))) where >>>>> > the SRH contains segments <1,2,B>. >>>>> > >>>>> > Note that B is an interface address on host B. >>>>> > >>>>> > Do you believe that in this case the host should send >>>>> > IP(SRH(IP(TCP(...))))? If yes, why? >>>>> > >>>>> > I think this is a relevant use-case -e.g. PANRG-, and don’t see why we >>>>> > would enforce encapsulation. >>>>> > >>>>> > Thanks, >>>>> > >>>>> > Pablo. >>>>> > >>>>> > From nobody Tue Nov 6 08:52:37 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2177812F1AC for ; Tue, 6 Nov 2018 08:52:36 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es 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 LIwI4M4Isbjs for ; Tue, 6 Nov 2018 08:52:33 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A68512F1A5 for <6man@ietf.org>; Tue, 6 Nov 2018 08:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1541523150; x=1542127950; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=qoTyDkH97laRzEyXztNKSSl/iiPfMHJoF0moFoZFaqI=; b=jSSvn/1mHI1cK XXp25OGKLNbkP6MSvaQjVyjBheTO+GeVCxmvZ5x1/9l5QJgm7Bpj7rq1LuCsoH+S jkodqCw7NkzULnn6KgNZuHyK9MpKeCB1Jn3oKB71D6CIL7ubonr4GmOm9fx3Rm4n kI9t8yjpnxSg0gM8xDo1xKUVNdjRlE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 06 Nov 2018 17:52:30 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 06 Nov 2018 17:52:29 +0100 Received: from [172.20.60.83] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005946968.msg for <6man@ietf.org>; Tue, 06 Nov 2018 17:52:28 +0100 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [172.20.60.83] X-MDArrival-Date: Tue, 06 Nov 2018 17:52:28 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=184881054d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: 6man@ietf.org User-Agent: Microsoft-MacOutlook/10.10.3.181015 Date: Tue, 06 Nov 2018 23:52:19 +0700 Subject: Re: DNS64 pref option. From: JORDI PALET MARTINEZ To: Mark Andrews , Lorenzo Colitti CC: 6man <6man@ietf.org> Message-ID: <514D1C95-B792-4164-987D-A7D2251252D8@consulintel.es> Thread-Topic: DNS64 pref option. References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 16:52:36 -0000 Hi Mark, Trying to understand your scenario ... Let's say I've an enterprise network which is dual-stack. In the same network (before the NAT64), you have servers, with use private = IPv4 addresses and they have A records for their names. The ideal solution, of course, is to have those servers with also AAAA reco= rds and be dual-stacked. Is this your scenario? So, if we have a way to inform the any "entity" doing the DNS64 function to= not synthetize the AAAA RRs, you will reach those host using IPv4 in the p= rivate network. I'm assuming that the "entity" doing the DNS64 is the stack, happy eyeballs= , or similar, in the local host that want to reach the IPv4-only server. Be= cause the problem doesn't exist if the synthesis is done in a DNS64 server,= as you can then use the mapping-out function. I described it in section 4.= 1.6. Mapping-out IPv4 addresses (discussing there the DNSSEC implications)= , of https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment. In the case you describe, this will only happen if the first-hop router fro= m the LAN where a host tries to reach one of those servers, doesn't have a = CLAT, otherwise even in the case it gets only an A record, will translate i= t (NAT46). BUT, if this network is dual-stack, why I need a NAT64/DNS64 at all? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ipv6 en nombre de Mark Andrews Fecha: martes, 6 de noviembre de 2018, 16:03 Para: Lorenzo Colitti CC: 6man <6man@ietf.org> Asunto: Re: DNS64 pref option. =20 =20 > On 6 Nov 2018, at 7:52 pm, Lorenzo Colitti wrote= : >=20 > On Tue, Nov 6, 2018 at 3:43 PM Mark Andrews wrote: > > =E2=80=A2 AIUI, the option is not useful on an IPv6-only netw= ork. It is only useful in the case where the host has an IPv4 address. In t= hat case the network might as well provide IPv4. >=20 > For local ipv6-only only the filtering of IPv6 is useful and possibly= could be skipped to just use well known values to skip. >=20 > What would be the purpose of such filters? A host that supports 464xl= at is just going to get the A record and send the packet to the NAT64 anywa= y, no? >=20 > > Mark, do you have a use case for #4? It's clear that this would be = useful DNS64 translator that provides service to other hosts, but for the c= ase where the host is just doing DNS64 synthesis for itself, the use case s= eems less clear. >=20 > The host still needs to know what addresses to not translate at the a= pplication level so long as we are locally dual stack. You don=E2=80=99t w= ant to send local traffic for IPv4 only local devices through the NAT64. >=20 > Can you provide an example scenario here? A host on a home network th= at has IPv4 as well as NAT64? Why would you deploy this as opposed to doing= , say, 464xlat on the home gateway? =20 Because you want to move the traffic to IPv6 as early as possible to re= move load from the router. Because your router doesn=E2=80=99t have a CLAT. =20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Nov 6 11:42:09 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACFD1294D7 for ; Tue, 6 Nov 2018 11:42:07 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZKGg9AziPA8F for ; Tue, 6 Nov 2018 11:42:04 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 CF04B124408 for ; Tue, 6 Nov 2018 11:42:03 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id j13-v6so6572930pff.11 for ; Tue, 06 Nov 2018 11:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fupBy4sx3ekKlCzMc1KBkq0Jds67tFhlWzcbjQxMXVQ=; b=Yz1xkRmeaXaJBCA9voVbUabycuuEUSRrdwPeNd/Z7a8/o2xdzK08Y9M8rM1X7vmHQi ADVoByuGRqmoZCaXKFS2oAhdbivG/EysRtQCvW0kNFYcsHE2HY8D3F7BTq/ljXQvvNqn vrEtiz/AKCsVFb951yGtFDETHxX4lDYeiZi47k/BGyzYrnOw1BcpHlJT2eJruwtgofsf P0PBMlH3iXUV0tQPzVP5jfCaTC5XSMnl27oyx3OSMrIM6++ayXxWEMo7OZuQcP3NZVeM tL1XCw0cPeWJ+5iIlCPerkG35orQVpgqj3Cn0Yj+a/5r7bgYb5qILDl4Wp2J9n5ndZVR Weqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fupBy4sx3ekKlCzMc1KBkq0Jds67tFhlWzcbjQxMXVQ=; b=B+7MUnQythuRr/NNwpYzEloDvVqUWwix2B/Ca56FNDMOFsh+c9lv/V1KyNlJ889X6G TeXoIJIOIHFZE5ra5ufjAkqGu6ofKQ4I6qbkYH/zOE2hgfPIMzGijnesxoA/lbuZrlqV Q46ENLQHp6WlOSsp0sgcEOvhKxnk2CROmLBgK266w8ZGN+VgicbQxUCN3AnAkDpyyykw HanrOJWiH0ODyH+41kvssUTlSnZzT09r98DD3ZG5gV5lS42CiJydgEErl9S9zoi9q/QK QrhtMFzEaF08FRAkBmfOFCmdiNOO/CpW+V4+Efz02dcFKR6XBdSXjnfXvM24lc9bcdK9 maAw== X-Gm-Message-State: AGRZ1gLoTet93odZw2EIU5hXKRu46DaMoA/4qAfzw5eNjs8Uu4yA65zp oh01yNUOd91SdgcDIRzqmpmt8OaL X-Google-Smtp-Source: AJdET5eT0HRaedroIJAfrnuqfJ5RRKuzYha7NrxkwJcAXtlR3z2ZDZU/mLnBJqMPMTHZvnYZFXI7zw== X-Received: by 2002:a63:4566:: with SMTP id u38mr18147895pgk.4.1541533322674; Tue, 06 Nov 2018 11:42:02 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id g190sm3362037pgc.28.2018.11.06.11.42.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 11:42:02 -0800 (PST) Subject: Re: Question 6man SRH encaps only To: ipv6@ietf.org References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> <9e3b89c3-0eee-84f5-2bbc-04b5399fd72b@joelhalpern.com> <229D9953-62DF-4796-914C-C9DA120202C2@cisco.com> From: Brian E Carpenter Message-ID: <575a23b8-8797-302e-8c3d-3b7d820aded2@gmail.com> Date: Wed, 7 Nov 2018 08:41:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 19:42:07 -0000 On 2018-11-07 04:08, Joel Halpern Direct wrote: > Darren, as I understand it, we have already agreed that hosts have to=20 > have the capability to generate and process encapsulated messages. >=20 > With two representations, we have to have capabilities in the=20 > configuration and the SR Policy to indicate which one is to be used=20 > when. As far as I know, there is no simple rule the hosts can follow, = > as there is no obvious way a priori to know that a destination is in th= e=20 > same SR domain. >=20 > Across our protocols, we have found that having multiple ways of doing = > the same thing generally makes life harder. So I am asking taht we=20 > either articulate a significant benefit from having such duplication, o= r=20 > we not duplicate capability. Put it this way: to allow the non-encapsulated mode, we need a watertight= way of ensuring that it is only used within a limited domain where we are certain that both hosts know what they're doing and trust each other.= That's a lot of complexity, quite in addition to the intrinsic complexity= of having both an encapsulated and non-encapsulated mode. Well, there's a draft for that: https://tools.ietf.org/html/draft-carpenter-limited-domains That draft expresses the opinion that there *will* be many such domains in future, but there's no disguising that this creates complexity. As things stand today, except for hand-crafted configurations, we have no way to support this that I am aware of. Brian >=20 > Yours, > Joel >=20 > On 11/6/18 6:44 PM, Darren Dukes (ddukes) wrote: >> Joel, forcing every host to place an outer encapsulation on a packet =E2= =80=98because there is no reason it won=E2=80=99t work=E2=80=99 is not ju= stification. It=E2=80=99s like forcing every host to use IPSec because t= here is no reason it won=E2=80=99t work. >> >> There are use cases for intra-domain communication in the draft. >> There is no justification for an additional outer IP encapsulation in = that case. >> It is implemented and works. >> >> Darren >> >> >>> On Nov 6, 2018, at 5:53 AM, Joel M. Halpern wro= te: >>> >>> I do not understand your argument about a good base for future use. >>> >>> All the cases I know of can be handled with just the encapsulation mo= de. If there are issues that it can not handle, details on that would be= good to hear them. Conversely, I don't see how the working group can de= cide that it needs a feature because some folks say that they think there= is a use for it in the future. >>> >>> Yours, >>> Joel >>> >>> On 11/6/18 5:28 PM, Darren Dukes (ddukes) wrote: >>>> I think it depend on your view of simplicity. Simple to implement f= or a broad set of solutions or simple to specify? >>>> It is simple to specify a host must only encapsulate, or other restr= ictions but that doesn=E2=80=99t necessarily give us a strong base to bui= ld other specification. >>>> I prefer that we make sure the SRH draft define a good base on which= other documents can be based to solve real problems beyond the very limi= ted use cases we have defined. >>>> BTW It is simple to implement the socket based approach to apply an = SR policy to a socket within an SR Domain - It is implemented, and it wor= ks. >>>> Darren >>>>> On Nov 6, 2018, at 4:44 AM, Joel M. Halpern w= rote: >>>>> >>>>> The point is that a host inside the SR domain, when processing an S= R policy, has to be prepared, for reasons we discussed on the list before= the meeting, to generate the full IP(SR(IP(...))) packet format. Having= an option to generate two different SR formats does not add value and do= es inherently add complexity. >>>>> >>>>> On the receive side, the host must also be prepared to receive both= formats. One can argue that this is less of a burden, but it is still c= omplexity. And we have already determined that it needs to be able to ha= ndle the encapsulated case. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 11/6/18 3:56 PM, Pablo Camarillo (pcamaril) wrote: >>>>>> I fail to see how this option is simpler. >>>>>> Note that as opposed to what you stated, hosts A and B generate th= e packet and are inside the SR domain. >>>>>> A Linux host B will receive IP(SRH(IP(TCP(...))). What is the purp= ose of the inner IP header? >>>>>> On top of that, you can link a TCP/UDP socket with a given segment= routing header [1]. Why would I insert here an IP header? >>>>>> If you have the time [2] is an interesting read. In there you have= a good list of benefits. >>>>>> I believe that if hosts A and B are within the SR domain -which is= the case when hosts A and B generate the SR header-, then there is no be= nefit to introduce an inner IP header before the L4 payload. >>>>>> Thanks, >>>>>> Pablo. >>>>>> [1]. https://tools.ietf.org/html/draft-duchene-spring-srv6-socket-= 00 >>>>>> [2]. David Lebrun, Mathieu Jadin, Fran=C3=A7ois Clad, Clarence Fil= sfils, >>>>>> and Olivier Bonaventure. 2018. Software Resolved Networks: Rethink= ing >>>>>> Enterprise Networks with IPv6 Segment Routing. In SOSR >>>>>> =E2=80=9918: SOSR =E2=80=9918: Symposium on SDN Research, March 26= =E2=80=9327, 2018, >>>>>> Los Angeles, CA, USA. ACM, New York, NY, USA, 14 pages. >>>>>> https://doi.org/10.1145/3185467.3185471 >>>>>> =EF=BB=BFOn 06/11/2018, 15:14, "Joel M. Halpern" wrote: >>>>>> Yes, I am saying that we should always use IP(SRH(IP(...))). >>>>>> The reason is simplicity and robustness. >>>>>> As we have already discussed, the host has to be prepared to = generate >>>>>> that form and process that form whenever it is talking to som= eone >>>>>> outside the SR Domain.=09 >>>>>> Having two ways of encoding the same thing, and two processin= g paths for >>>>>> generating / handling the same thing, introduces complexity. >>>>>> If there is a strong benefit (beyond the number of bits = in the packet), >>>>>> I would like to hear about that benefit. I can easily believ= e I missed >>>>>> something. >>>>>> In the absence of a benefit, choices are in and of thems= elves harmful. >>>>>> Yours, >>>>>> Joel >>>>>> On 11/6/18 3:08 PM, Pablo Camarillo (pcamaril) wrote: >>>>>> > Hi Joel, >>>>>> > >>>>>> > Regarding your question on 6man about the SRH and allowing = only >>>>>> > encapsulation: >>>>>> > >>>>>> > There are two open-source host implementations of the SRH (= Linux Kernel, >>>>>> > FD.io VPP). I wrote the code for SRH in the latter. >>>>>> > >>>>>> > A---1---2---B >>>>>> > >>>>>> > (A and B are hosts) >>>>>> > >>>>>> > In one of the use-cases host A has awareness of the transpo= rt network. >>>>>> > >>>>>> > Host A generates and sends a packet of the form IP(SRH(TCP(= =2E..))) where >>>>>> > the SRH contains segments <1,2,B>. >>>>>> > >>>>>> > Note that B is an interface address on host B. >>>>>> > >>>>>> > Do you believe that in this case the host should send >>>>>> > IP(SRH(IP(TCP(...))))? If yes, why? >>>>>> > >>>>>> > I think this is a relevant use-case -e.g. PANRG-, and don=E2= =80=99t see why we >>>>>> > would enforce encapsulation. >>>>>> > >>>>>> > Thanks, >>>>>> > >>>>>> > Pablo. >>>>>> > >>>>>> =20 >> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Nov 6 12:39:16 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BD3130DED for ; Tue, 6 Nov 2018 12:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 s3Ntz1C3pNCg for ; Tue, 6 Nov 2018 12:39:12 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 553B41292AD for <6man@ietf.org>; Tue, 6 Nov 2018 12:39:12 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 029AF3AD330; Tue, 6 Nov 2018 20:39:12 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C4CEE160098; Tue, 6 Nov 2018 20:39:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B4C86160097; Tue, 6 Nov 2018 20:39:11 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JoNCE53deSBg; Tue, 6 Nov 2018 20:39:11 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 23241160050; Tue, 6 Nov 2018 20:39:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: DNS64 pref option. From: Mark Andrews X-Mailer: iPhone Mail (16A404) In-Reply-To: <514D1C95-B792-4164-987D-A7D2251252D8@consulintel.es> Date: Wed, 7 Nov 2018 07:39:08 +1100 Cc: Lorenzo Colitti , 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <514D1C95-B792-4164-987D-A7D2251252D8@consulintel.es> To: JORDI PALET MARTINEZ Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 20:39:15 -0000 Dual stack network doesn=E2=80=99t mean all devices connected to it are dual= stack. There is still a lot of IPv4 only garbage being sold with some cla= sses of device without a IPv6 capable alternative.=20 Deliberately creating bad AAAA records is a bad thing. Sending traffic to t= hose addresses is a bad thing.=20 If you have a internally routed local dual stack network you don=E2=80=99t e= ven have the IPv4 default pointing at a local CLAT to help. As for Ipv4only.arpa APL records should also be published there. =20 --=20 Mark Andrews > On 7 Nov 2018, at 03:52, JORDI PALET MARTINEZ = wrote: >=20 > Hi Mark, >=20 > Trying to understand your scenario ... >=20 > Let's say I've an enterprise network which is dual-stack. >=20 > In the same network (before the NAT64), you have servers, with use private= IPv4 addresses and they have A records for their names. >=20 > The ideal solution, of course, is to have those servers with also AAAA rec= ords and be dual-stacked. >=20 > Is this your scenario? >=20 > So, if we have a way to inform the any "entity" doing the DNS64 function t= o not synthetize the AAAA RRs, you will reach those host using IPv4 in the p= rivate network. >=20 > I'm assuming that the "entity" doing the DNS64 is the stack, happy eyeball= s, or similar, in the local host that want to reach the IPv4-only server. Be= cause the problem doesn't exist if the synthesis is done in a DNS64 server, a= s you can then use the mapping-out function. I described it in section 4.1.6= . Mapping-out IPv4 addresses (discussing there the DNSSEC implications), of= https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment. >=20 > In the case you describe, this will only happen if the first-hop router fr= om the LAN where a host tries to reach one of those servers, doesn't have a C= LAT, otherwise even in the case it gets only an A record, will translate it (= NAT46). >=20 > BUT, if this network is dual-stack, why I need a NAT64/DNS64 at all? >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: ipv6 en nombre de Mark Andrews = > Fecha: martes, 6 de noviembre de 2018, 16:03 > Para: Lorenzo Colitti > CC: 6man <6man@ietf.org> > Asunto: Re: DNS64 pref option. >=20 >=20 >=20 >> On 6 Nov 2018, at 7:52 pm, Lorenzo Colitti wrote: >>=20 >> On Tue, Nov 6, 2018 at 3:43 PM Mark Andrews wrote: >>> =E2=80=A2 AIUI, the option is not useful on an IPv6-only network. I= t is only useful in the case where the host has an IPv4 address. In that cas= e the network might as well provide IPv4. >>=20 >> For local ipv6-only only the filtering of IPv6 is useful and possibly cou= ld be skipped to just use well known values to skip. >>=20 >> What would be the purpose of such filters? A host that supports 464xlat i= s just going to get the A record and send the packet to the NAT64 anyway, no= ? >>=20 >>> Mark, do you have a use case for #4? It's clear that this would be usefu= l DNS64 translator that provides service to other hosts, but for the case wh= ere the host is just doing DNS64 synthesis for itself, the use case seems le= ss clear. >>=20 >> The host still needs to know what addresses to not translate at the appli= cation level so long as we are locally dual stack. You don=E2=80=99t want t= o send local traffic for IPv4 only local devices through the NAT64. >>=20 >> Can you provide an example scenario here? A host on a home network that h= as IPv4 as well as NAT64? Why would you deploy this as opposed to doing, say= , 464xlat on the home gateway? >=20 > Because you want to move the traffic to IPv6 as early as possible to re= move load from the router. > Because your router doesn=E2=80=99t have a CLAT. >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 From nobody Tue Nov 6 14:32:08 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D605A130DC1 for ; Tue, 6 Nov 2018 14:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 dZnkdUzsa_8N for ; Tue, 6 Nov 2018 14:32:03 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 5FE4E1288BD for ; Tue, 6 Nov 2018 14:32:03 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id r14so4604920qtp.1 for ; Tue, 06 Nov 2018 14:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Y4JUjSBAK6u+VrEFyNJP/Cz41cdiObpiR/CgX++G1S0=; b=nrUJfJyUjBBFp4v+xSQiqBAbcqZ49DsqA2LuzPW7E91ON+FyIxiyapThKZx2y3nDod zDgYpWLQpQSN7Mt31GOEL2vnI2fJDhkIycWOyNB56IvlhQIjbphEOWbTl3yE8vkWWyxW QE3ug6NFZPBj2qB0c4I8NZmdzR5b0eprPN2K2bFqrkPfE5Gsm5k++myyH7qUu1iRKUXn pm3ok6I1TCBj2LBRsWLSGJHMP0OITYl4QwMfQJFrJysYPBmG/7g+FonBuZdCQdAQ6Ace ic3sx5q5eHu8Dvoaf/nZj7D7ckgx7dADXvaSt2mURe/BLRdHVFHnwHZ3KOCiyrQj7T7d Q1Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y4JUjSBAK6u+VrEFyNJP/Cz41cdiObpiR/CgX++G1S0=; b=jUDXchFMI4xzGcLn/bBzDSuSajm8Po3dgP5Oec41jpQtaeAkvaSpoHieGt46E2XhZf Y84MD2n3IKkhbmCSzwvX7L667N07nVG08neaN9BwqECdmnlxKCQC0GTmEj9j5JieL553 VHcoBaIyoVbs2H6FcvA6dX8bOMnuUhJgVVbTDmb+y4p8GYupDyUp1LXnDVve9oq0TjT/ MmkOSi+E8ZL+3UnEmVOfS78BZ2E4MDlNvtJyymtN3BRKwBsnqbQdguV0xBXnktD/cp3E AsaXVVOWXgeT4YpDf/IRoa6X//JxqwjisQnwXVgJa8FKGFSoTMuEtR3MGnHnVrp5I+7M JnaQ== X-Gm-Message-State: AGRZ1gJA/ijSwPHNWSfR/4sK1O4aeCfDiT9KJgSq7sMrdyaHhknd4F52 bentUxo5iHsuGxxj0lUbVL1WH4OvvQyTKcis1RSQQvTzwW4= X-Google-Smtp-Source: AJdET5dIebQns6YAIedGag9tt43F0RkHwp3DRYPPwktx4v6keGs1LJrqCG706d3hBgr0clDNwCfC7PuPfVQhXbTowSE= X-Received: by 2002:ac8:59:: with SMTP id i25-v6mr27787638qtg.246.1541543521956; Tue, 06 Nov 2018 14:32:01 -0800 (PST) MIME-Version: 1.0 Received: by 2002:aed:2022:0:0:0:0:0 with HTTP; Tue, 6 Nov 2018 14:32:01 -0800 (PST) In-Reply-To: <575a23b8-8797-302e-8c3d-3b7d820aded2@gmail.com> References: <7E1C8E10-DA95-4347-A99A-8A2FC1B79A77@cisco.com> <9dca543f-8806-0131-837d-b0cf147049f7@joelhalpern.com> <9e3b89c3-0eee-84f5-2bbc-04b5399fd72b@joelhalpern.com> <229D9953-62DF-4796-914C-C9DA120202C2@cisco.com> <575a23b8-8797-302e-8c3d-3b7d820aded2@gmail.com> From: Tom Herbert Date: Tue, 6 Nov 2018 14:32:01 -0800 Message-ID: Subject: Re: Question 6man SRH encaps only To: Brian E Carpenter Cc: 6man Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 22:32:07 -0000 On Tue, Nov 6, 2018 at 11:41 AM, Brian E Carpenter wrote: > On 2018-11-07 04:08, Joel Halpern Direct wrote: >> Darren, as I understand it, we have already agreed that hosts have to >> have the capability to generate and process encapsulated messages. >> >> With two representations, we have to have capabilities in the >> configuration and the SR Policy to indicate which one is to be used >> when. As far as I know, there is no simple rule the hosts can follow, >> as there is no obvious way a priori to know that a destination is in the >> same SR domain. >> >> Across our protocols, we have found that having multiple ways of doing >> the same thing generally makes life harder. So I am asking taht we >> either articulate a significant benefit from having such duplication, or >> we not duplicate capability. > > Put it this way: to allow the non-encapsulated mode, we need a watertight > way of ensuring that it is only used within a limited domain where we > are certain that both hosts know what they're doing and trust each other. > > That's a lot of complexity, quite in addition to the intrinsic complexity > of having both an encapsulated and non-encapsulated mode. > > Well, there's a draft for that: > https://tools.ietf.org/html/draft-carpenter-limited-domains > > That draft expresses the opinion that there *will* be many such domains > in future, but there's no disguising that this creates complexity. As > things stand today, except for hand-crafted configurations, we have no > way to support this that I am aware of. > I am not sure that the use case for hosts speaking SR would ever be prevalent. I suspect the vast majority of deployments will be to apply SR in the network in which case encapsulation is always used. There's a couple of reasons for this. In anything that resembles a public network (like in mobile where SRv6 is proposed as replacement for GTP) end hosts are not trusted and couldn't be part of the domain. Even if the hosts are trusted, say in a compartmentalized data center it's still less likely hosts would participate. It is not common for hosts to implement any sophisticated routing, and it's often the case that servers and networks are managed very differently by different internal organizations. An alternative to hosts participating directly in SR (or other complex routing) is described in draft-herbert-route-fast-00. The idea is that the network gives a host an ticket that encodes routing. When a network nodes sees the ticket it can apply the routing, for instance the ticket may indicate a SR list to use. Tom > Brian > >> >> Yours, >> Joel >> >> On 11/6/18 6:44 PM, Darren Dukes (ddukes) wrote: >>> Joel, forcing every host to place an outer encapsulation on a packet = =E2=80=98because there is no reason it won=E2=80=99t work=E2=80=99 is not j= ustification. It=E2=80=99s like forcing every host to use IPSec because th= ere is no reason it won=E2=80=99t work. >>> >>> There are use cases for intra-domain communication in the draft. >>> There is no justification for an additional outer IP encapsulation in t= hat case. >>> It is implemented and works. >>> >>> Darren >>> >>> >>>> On Nov 6, 2018, at 5:53 AM, Joel M. Halpern wrot= e: >>>> >>>> I do not understand your argument about a good base for future use. >>>> >>>> All the cases I know of can be handled with just the encapsulation mod= e. If there are issues that it can not handle, details on that would be go= od to hear them. Conversely, I don't see how the working group can decide = that it needs a feature because some folks say that they think there is a u= se for it in the future. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/6/18 5:28 PM, Darren Dukes (ddukes) wrote: >>>>> I think it depend on your view of simplicity. Simple to implement fo= r a broad set of solutions or simple to specify? >>>>> It is simple to specify a host must only encapsulate, or other restri= ctions but that doesn=E2=80=99t necessarily give us a strong base to build = other specification. >>>>> I prefer that we make sure the SRH draft define a good base on which = other documents can be based to solve real problems beyond the very limited= use cases we have defined. >>>>> BTW It is simple to implement the socket based approach to apply an S= R policy to a socket within an SR Domain - It is implemented, and it works. >>>>> Darren >>>>>> On Nov 6, 2018, at 4:44 AM, Joel M. Halpern wr= ote: >>>>>> >>>>>> The point is that a host inside the SR domain, when processing an SR= policy, has to be prepared, for reasons we discussed on the list before th= e meeting, to generate the full IP(SR(IP(...))) packet format. Having an o= ption to generate two different SR formats does not add value and does inhe= rently add complexity. >>>>>> >>>>>> On the receive side, the host must also be prepared to receive both = formats. One can argue that this is less of a burden, but it is still comp= lexity. And we have already determined that it needs to be able to handle = the encapsulated case. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 11/6/18 3:56 PM, Pablo Camarillo (pcamaril) wrote: >>>>>>> I fail to see how this option is simpler. >>>>>>> Note that as opposed to what you stated, hosts A and B generate the= packet and are inside the SR domain. >>>>>>> A Linux host B will receive IP(SRH(IP(TCP(...))). What is the purpo= se of the inner IP header? >>>>>>> On top of that, you can link a TCP/UDP socket with a given segment = routing header [1]. Why would I insert here an IP header? >>>>>>> If you have the time [2] is an interesting read. In there you have = a good list of benefits. >>>>>>> I believe that if hosts A and B are within the SR domain -which is = the case when hosts A and B generate the SR header-, then there is no benef= it to introduce an inner IP header before the L4 payload. >>>>>>> Thanks, >>>>>>> Pablo. >>>>>>> [1]. https://tools.ietf.org/html/draft-duchene-spring-srv6-socket-0= 0 >>>>>>> [2]. David Lebrun, Mathieu Jadin, Fran=C3=A7ois Clad, Clarence Fils= fils, >>>>>>> and Olivier Bonaventure. 2018. Software Resolved Networks: Rethinki= ng >>>>>>> Enterprise Networks with IPv6 Segment Routing. In SOSR >>>>>>> =E2=80=9918: SOSR =E2=80=9918: Symposium on SDN Research, March 26= =E2=80=9327, 2018, >>>>>>> Los Angeles, CA, USA. ACM, New York, NY, USA, 14 pages. >>>>>>> https://doi.org/10.1145/3185467.3185471 >>>>>>> =EF=BB=BFOn 06/11/2018, 15:14, "Joel M. Halpern" wrote: >>>>>>> Yes, I am saying that we should always use IP(SRH(IP(...))). >>>>>>> The reason is simplicity and robustness. >>>>>>> As we have already discussed, the host has to be prepared to g= enerate >>>>>>> that form and process that form whenever it is talking to some= one >>>>>>> outside the SR Domain. >>>>>>> Having two ways of encoding the same thing, and two processing= paths for >>>>>>> generating / handling the same thing, introduces complexity. >>>>>>> If there is a strong benefit (beyond the number of bits i= n the packet), >>>>>>> I would like to hear about that benefit. I can easily believe= I missed >>>>>>> something. >>>>>>> In the absence of a benefit, choices are in and of themse= lves harmful. >>>>>>> Yours, >>>>>>> Joel >>>>>>> On 11/6/18 3:08 PM, Pablo Camarillo (pcamaril) wrote: >>>>>>> > Hi Joel, >>>>>>> > >>>>>>> > Regarding your question on 6man about the SRH and allowing o= nly >>>>>>> > encapsulation: >>>>>>> > >>>>>>> > There are two open-source host implementations of the SRH (L= inux Kernel, >>>>>>> > FD.io VPP). I wrote the code for SRH in the latter. >>>>>>> > >>>>>>> > A---1---2---B >>>>>>> > >>>>>>> > (A and B are hosts) >>>>>>> > >>>>>>> > In one of the use-cases host A has awareness of the transpor= t network. >>>>>>> > >>>>>>> > Host A generates and sends a packet of the form IP(SRH(TCP(.= ..))) where >>>>>>> > the SRH contains segments <1,2,B>. >>>>>>> > >>>>>>> > Note that B is an interface address on host B. >>>>>>> > >>>>>>> > Do you believe that in this case the host should send >>>>>>> > IP(SRH(IP(TCP(...))))? If yes, why? >>>>>>> > >>>>>>> > I think this is a relevant use-case -e.g. PANRG-, and don=E2= =80=99t see why we >>>>>>> > would enforce encapsulation. >>>>>>> > >>>>>>> > Thanks, >>>>>>> > >>>>>>> > Pablo. >>>>>>> > >>>>>>> >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Nov 6 17:00:15 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD81292AD; Tue, 6 Nov 2018 17:00:13 -0800 (PST) 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 k8vAz2S24iPo; Tue, 6 Nov 2018 17:00:11 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 EBE4C12870E; Tue, 6 Nov 2018 17:00:10 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id n18so10274282lfh.6; Tue, 06 Nov 2018 17:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=t0RQfF1TBjF8U64sNo5qXqe5hkAFzSbblwxyQ0HUttU=; b=l5v6m9abncEQ1cox3DB8bYYFWVXTPqAjWqbgtTxIXXMtiX/S4zfqo03Jv2BT4evSjT tBNu3nvX4NyD6jDBAnDPaunXlqe/BkDAVY+6PD9sqFZshUCxj3d2aM9dLCcjcPlVqVGI KDL4Si8NlAWOLWJ58UsSZhm1Q+F9VSt4LrwxpCahe6E1LrWNRDCpt26n59dINAagsCS9 L9PkdEIPdyHaprUZat6rhxBCsbUTFa5hJxBrsA8S0cUzgzHb/yB2PJSSJHzR4DCnX7WJ /TVUdwYzyypXG0wVHUFKfPiJALtogbS4IxABSuPQ0WIwA4TvpZSl6qXhtVRHUDU/KkFw NidA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=t0RQfF1TBjF8U64sNo5qXqe5hkAFzSbblwxyQ0HUttU=; b=nGD+FkT8CVaGjASTvfJ2oAJuy86+F7OKYiBQzvP5DXH/7uzPGOP9qfEZIev2POuXBE F4J4K9jupDycU6Q8W4kYciRDnLgxXYlss0+N3Ryxn0BrqNHsND/wjqrk+qG1FwIGKbnJ x6Qj0Ik/MdJ0oS3xiqURG6YgbURz94EoWOTYnGnX3tJP+iebgN71ohGWBAK8bj6LX5L8 F8Hsqg5zc+GGhuGKPlH99hSCkIM3aRq6zeovA1unsprELmHfN1qF99eH9VEXAW6F0QuA rwPFqGV7Esmzz8dkaXx/UoNs+3bu+9YV5TUauGKJmhOnNqtmadcM+QeN0uL/dJIR+0b+ zTIg== X-Gm-Message-State: AGRZ1gJDVrsQrl+yaBgSKBkqvF9gEnTELjzWKuPlLEnJVjkHi7V9otiP uNricLWOR4Gu/L1biMk6ccsE/77EORi4KICy477x6vTT X-Google-Smtp-Source: AJdET5cihr4HV66u0S7gvKdW9xIl8s5J+zy9X2HGifmF5h5mmi4hsDTitLbn7Zs8+K/J/Gqr3qowrDOnnoJCZAT39JM= X-Received: by 2002:a19:26ce:: with SMTP id m197mr13659961lfm.23.1541552408616; Tue, 06 Nov 2018 17:00:08 -0800 (PST) MIME-Version: 1.0 References: <154155148848.30897.17784898234776136208.idtracker@ietfa.amsl.com> In-Reply-To: From: Naveen Kottapalli Date: Wed, 7 Nov 2018 06:29:52 +0530 Message-ID: Subject: Fwd: New Version Notification for draft-naveen-slaac-prefix-management-00.txt To: 6man WG , v6ops list Content-Type: multipart/alternative; boundary="000000000000b7e531057a08a339" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 01:00:14 -0000 --000000000000b7e531057a08a339 Content-Type: text/plain; charset="UTF-8" Hello, IPv6 StateLess Address AutoConfiguration (SLAAC) in its current form doesn't offer following services like: 1. Soliciting a prefix of specific length. The length could be of either /64 bit prefix (which would generally be solicited by nodes) or non /64 bit prefix (which would generally be solicited by either CPE or downstream routers). 2. Releasing the prefixes that are no more used by the device. This could be equally important for the routers who assigned the prefix to make the unused prefixes available for other nodes. To achieve the above objectives, a ND based message protocol is introduced in the below draft that does what a DHCPv6 node do; *without introducing any new message types or new option types or flag types*. Can you all share your thoughts on the draft? Thanks & Regards, Naveen ---------- Forwarded message --------- From: Date: Wed, Nov 7, 2018 at 6:14 AM Subject: New Version Notification for draft-naveen-slaac-prefix-management-00.txt To: Naveen Kottapalli A new version of I-D, draft-naveen-slaac-prefix-management-00.txt has been successfully submitted by Naveen Kottapalli and posted to the IETF repository. Name: draft-naveen-slaac-prefix-management Revision: 00 Title: IPv6 Stateless Prefix Management Document date: 2018-11-06 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-naveen-slaac-prefix-management-00.txt Status: https://datatracker.ietf.org/doc/draft-naveen-slaac-prefix-management/ Htmlized: https://tools.ietf.org/html/draft-naveen-slaac-prefix-management-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-naveen-slaac-prefix-management Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a provision for the hosts to request for a specific IPv6 address and manage the same, whereas the StateLess Address AutoConfiguration (SLAAC) doesn't have such a provision. Also, unavailability of DHCPv6 across all OS platforms has limited the IPv6 nodes to not use features like soliciting a prefix of desired length and lifetime, renewing, releasing / declining a prefix, etc. This document proposes IPv6ND extensions for enabling SLAAC devices to solicit prefix information as a hint PIO in RS and other methods like renewing or releasing or declining a prefix without introducing any new ICMPv6 message or option types. 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. The IETF Secretariat --000000000000b7e531057a08a339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello,

    IPv6 StateLess Address AutoConfiguration (SLAAC) in its curre= nt form doesn't offer following services like:

    1. Soliciting a prefix of spec= ific length.=C2=A0 The length could be of either /64 bit prefix (which woul= d generally be solicited by nodes) or non /64 bit prefix (which would gener= ally be solicited by either CPE or downstream routers).
    2. Releasing the prefixes that are no more used by the device.= =C2=A0 This could be equally important for the routers who assigned the pre= fix to make the unused prefixes available for other nodes.

    To achieve the above = objectives, a ND based message protocol is introduced in the below draft th= at does what a DHCPv6 node do; without introducing any new message types= or new option types or flag types.
    Can you all share your thoughts on the dr= aft?

    T= hanks & Regards,
    Naveen


    ---------- Forwarded message ---------
    From: <internet-drafts@ietf.org>
    Date: Wed, Nov 7, 2018 at= 6:14 AM
    Subject: New Version Notification for draft-naveen-slaac-prefix= -management-00.txt
    To: Naveen Kottapalli <nkottapalli@benu.net>


    A new version of I-D, draft-naveen-slaac-prefix-management-00.txt
    has been successfully submitted by Naveen Kottapalli and posted to the
    IETF repository.

    Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-naveen-slaac-prefix-man= agement
    Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
    Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 Stateless Prefix Management Document date:=C2=A0 2018-11-06
    Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
    URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-naveen= -slaac-prefix-management-00.txt
    Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-naveen-slaac-prefix-mana= gement/
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-naveen-slaac-prefix-management-00<= br> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-naveen-slaac-prefix= -management


    Abstract:
    =C2=A0 =C2=A0The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) prov= ides a
    =C2=A0 =C2=A0provision for the hosts to request for a specific IPv6 address= and
    =C2=A0 =C2=A0manage the same, whereas the StateLess Address AutoConfigurati= on
    =C2=A0 =C2=A0(SLAAC) doesn't have such a provision.=C2=A0 Also, unavail= ability of
    =C2=A0 =C2=A0DHCPv6 across all OS platforms has limited the IPv6 nodes to n= ot use
    =C2=A0 =C2=A0features like soliciting a prefix of desired length and lifeti= me,
    =C2=A0 =C2=A0renewing, releasing / declining a prefix, etc.=C2=A0 This docu= ment
    =C2=A0 =C2=A0proposes IPv6ND extensions for enabling SLAAC devices to solic= it
    =C2=A0 =C2=A0prefix information as a hint PIO in RS and other methods like<= br> =C2=A0 =C2=A0renewing or releasing or declining a prefix without introducin= g any
    =C2=A0 =C2=A0new ICMPv6 message or option types.




    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

    --000000000000b7e531057a08a339-- From nobody Tue Nov 6 17:28:17 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8943A128CE4 for ; Tue, 6 Nov 2018 17:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 43zF8Xw0crmq for ; Tue, 6 Nov 2018 17:28:12 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 4ACD2127598 for ; Tue, 6 Nov 2018 17:28:12 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id p16-v6so7076787plr.8 for ; Tue, 06 Nov 2018 17:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=E3P7PiWa3T4zCo9JsWgOpKkc4zXkne1R6/oVdswgbe4=; b=R/ntZ7O55YtjEHtoUTxZokgyFsjPTCZSCsC2We2XxW/LFWkUMPMXffA/RTavzF5Ecn n+RPx3HkvvGB/mDoTkY16seeCzDNmXKNijLyRo5jhZbI5UZqYy/dsLrslkqMQFpJc2C0 FCv24/22qeAqjMc99cGMUcDyq4DkJYF3USAucKMQD34VoLKNFsTcn3Y9S+CTZu18cASR 15bbc3QPo7kb3FLXoJwSBO80L3Qc8cZ5GbCvBUsmZmseWkyH6JYat4KlaWXXfD8KqA03 VDStr375gKruwc91A6ENEjoZFPJnyeCI18xQWvvAhF5Zho5zmSIAdVipqCxS0/xa/hQN XhFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=E3P7PiWa3T4zCo9JsWgOpKkc4zXkne1R6/oVdswgbe4=; b=R5l8WjuAumffOPkdSVYYLZGvz1+lPHYC6zkEjEnHK+nXokFpjDTnLIiWYMULHmrfsA bHmOw7eFmeFKTVd3ytoVeawow92d77Y31Ukv+P3UnXp5GIkOk7GORUGvKrfEXH1aBqJC vxWkCvDzrTd4aYcpoAmlNbaRUiCiRAmgb51VSBGL0x16Fca4HXjHkfFwyzCpdDgEZ0wT NJSz1RA2yvR53lTM6z6m/1yomk23JR///cieQ7xePNMj/Ikuk3CNxm1SQntTJsXWgmP0 7dOIkFOd5DAVluFTiaduQE/20sssEbQkTTXTTabOEyfUvHSyEMlektBqH6pd0tAKLFir U9ng== X-Gm-Message-State: AGRZ1gL18mGwexX6VYF4ua2Dbq2jXa9MPKSMNOHPRAJNu+JhRjw9HG6f QYAtPZ9sSUCelQzXm8BSbvilYc41 X-Google-Smtp-Source: AJdET5e9dFr4Ywz3wMuLRhen99o/XsepLTTFKrnA8ZjV6fIGPvrImtmsTEvbtmSaub0+A5FerT+/8A== X-Received: by 2002:a17:902:f83:: with SMTP id 3-v6mr29142956plz.254.1541554091332; Tue, 06 Nov 2018 17:28:11 -0800 (PST) Received: from [130.216.38.40] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.40]) by smtp.gmail.com with ESMTPSA id j187-v6sm5216701pfc.43.2018.11.06.17.28.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 17:28:10 -0800 (PST) Subject: Re: Comments on IPv4-only flag document To: IETF IPv6 Mailing List References: From: Brian E Carpenter Message-ID: <54c87b58-6c7a-a360-9672-e9e103df9b87@gmail.com> Date: Wed, 7 Nov 2018 14:28:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 01:28:15 -0000 Sorry I was unable to be on meetecho, but let me try to respond to this thread in a single message: On 2018-11-06 20:42, Lorenzo Colitti wrote: > Playing back my comments at the mike: > > 1. I don't think it's useful to say that IPv4 should be enabled if the > default router lifetime goes to zero. The default router lifetime going to > zero is a normal occurrence, e.g., when the router loses uplink > connectivity. Yes, but at that moment we cease to have a current signal of the admistrator's intention. It seems to me that in terms of the law of least astonishment, it's more correct to drop the IPv6-only assumption at that time. > I would say that the flag is valid in all cases. If the > network says it doesn't have IPv4, and it doesn't have working IPv6, the > host can always disconnect, try another network, or ignore the flag. It can always do that anyway. > > 2. We should not say that the flag means that IPv6 is "the only ip version > on the link". We don't want this draft to rule out new versions of IP. > Maybe instead of saying "no other versions of Internet protocol" we can say > "no lower-numbered version of the Internet protocol is in use". Fair enough, although that's a far-future issue... > 3. We should say that this flag has no effect if IPv4 configuration has > already succeeded (e.g., the host has obtained a valid configuration from > DHCPv4). This should address many of the security questions that have been > raised. I'm not sure. Maybe the administrator is about to switch off IPv4 services and is announcing this by setting the flag? On the security issue, see later. On 2018-11-06 21:37, Philip Homburg wrote: (in reply to Bjoern) >> (b) If the lifetimes of all the routers on the link subsequently >> expire, then the host state for the link is not IPv6-Only. Which >> doesnt say what to do (but Id probably do the same as above). > > Not switching back makes for a really nice attack vector on an > IPv4-only network without RA-guard: wait an incoming DHCPv4 discover and > send an RA with the IPv6-only set. Brilliant. If it's an IPv4-only network, it has no RA-guard by definition. Yes, as noted in the draft, this attack is possible. As also noted in the draft, "this is really no different than what such a bad actor can do anyway, if they have the ability to configure a bogus router in the first place." In such a situation the network is wide open to a wide variety of IPv4-based or IPv6-based attacks. Yes, this draft offers one more option for the attacker. (Same response to Nick Hilliard's message in this thread.) > It's great to have a draft that just consists of a new attack vector and > nothing else. Now that's just polemic. Of course we have to make a judgment call whether the mitigations this proposal brings outweigh the risks. On 2018-11-06 23:37, Mark Andrews wrote: > Working != ipv4 link local. Indeed. The flag actually conveys no information related to link-local operations. It only describes the admin intention for routing, DHCP and DNS/IPv4 services. On 2018-11-07 03:11, Bjoern A. Zeeb wrote: ... > If a host has working IPv4 services or connectivity and receives a > Router Advertisements packet with the IPv6-only flag set to 1 on the > same link without any other IPv6 configuration (i.e., an otherwise > IPv4-only link), it SHOULD consider the IPv6-Only flag a configuration > error and MAY continue to use IPv4. I don't strongly object to this text, but as noted above, it may not be an error or an attack: it may be an announcement by the admin that she just switched off the IPv4 services. BTW, the "MAY continue to use IPv4" is always true, as implied by the SHOULD language in the draft. Regards Brian From nobody Tue Nov 6 18:39:00 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6909A128CE4; Tue, 6 Nov 2018 18:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 TiXqYXlS4xaS; Tue, 6 Nov 2018 18:38:49 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 7416C126CB6; Tue, 6 Nov 2018 18:38:49 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id k1-v6so6708226pgq.1; Tue, 06 Nov 2018 18:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Jxf070nbTkm4Ppe44Biz1e22DuVjZ4dBEHa2tmDHD3c=; b=PVSP+wrDj8VbM07xMNiKt9azhQymy8vfbTPArnaeNlZlbBUuvh7Q5kITvaXprVO2RY T/9TTpcNyLYaJZAwsTg7b+vpXOnnEl7V9WR0CQdxYP37GSZcrDHkuAs8Yi2oxpyHx8eC gvBi1gpNj9sD47h/w2RQdbQ6YCDCO7tvRWQpH7XJOaOxu5qFMaoG1yTxhOz/E2dAMiVP hpZwD8KxW3UO53j+a3bQ14smi4iVGsRdTp+xzOury7DDGR5gfxLa6Fp5zk3kd2Zx5JCL HOkoBE70DoPSKdehow2tDXgXeUlU6u2i+jS9P+ILZBdGBr4GopcNqFz0oXSp/Z1JI9Kr DEmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Jxf070nbTkm4Ppe44Biz1e22DuVjZ4dBEHa2tmDHD3c=; b=nfGIyvnVb9cUfqlfYE2IHXd00Z4rPtG9NcALfxXro51+8I4UKFvVN0XsexfLyRMqZH Zo1UYTNiU/pITrC1O860KhPhJnmEtZzOrXQBEtL2DKA4terU0cjXXjx5LsxNMlU+vMW8 Fmiq3IdiQhsliqoM0QiJNJyzflD4pj2iczqzOZGTLYR8TKHUsL/KspOZ8w0h+u6BNDdK LFtEObaEzPFDw7h6gYHzGzPHw2Kpy00nBzJradQY8RTJpPYzpxwb+RuXjkUNd0+ST02M GALPBbnCZK3MrVSYqI9ouRqtCH5Vgs/htzJZbM8PQMBfL2zfgV6RXmcwElEJRZsCXrNb DSug== X-Gm-Message-State: AGRZ1gKXm/IH6+kQxAepaW7f6JtJic25X9VqcGFNUaQ7yKaj79vjs46l SaV8GlZL2RdA+wMiC5w+/lo= X-Google-Smtp-Source: AJdET5eI3uTDau+ikXzZk80Ivxxeujyr8PrAj1iHmXDHQieoCGR59T2razUevdSJmdS2a9jP5z5I4Q== X-Received: by 2002:a62:4301:: with SMTP id q1-v6mr80028pfa.163.1541558328963; Tue, 06 Nov 2018 18:38:48 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:9df0:b919:995c:c72b? ([2001:67c:1232:144:9df0:b919:995c:c72b]) by smtp.gmail.com with ESMTPSA id u7-v6sm58369383pfl.34.2018.11.06.18.38.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 18:38:48 -0800 (PST) From: Fred Baker Message-Id: <5B1684C1-A48A-4C53-949A-8DDAA7DF25BA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5CF419C5-9D1E-49EA-A057-69B1312DDAC5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-naveen-slaac-prefix-management-00.txt Date: Wed, 7 Nov 2018 09:38:45 +0700 In-Reply-To: Cc: 6man WG , v6ops list To: Naveen Kottapalli References: <154155148848.30897.17784898234776136208.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 02:38:51 -0000 --Apple-Mail=_5CF419C5-9D1E-49EA-A057-69B1312DDAC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 7, 2018, at 7:59 AM, Naveen Kottapalli = wrote: >=20 > Hello, >=20 > IPv6 StateLess Address AutoConfiguration (SLAAC) in its current form = doesn't offer following services like: >=20 > 1. Soliciting a prefix of specific length. The length could be of = either /64 bit prefix (which would generally be solicited by nodes) or = non /64 bit prefix (which would generally be solicited by either CPE or = downstream routers). SLAAC doesn't "solicit" anything. If you want a prefix with any specific = attributes, you're in the territory of RFC 3633. > 2. Releasing the prefixes that are no more used by the device. This = could be equally important for the routers who assigned the prefix to = make the unused prefixes available for other nodes. SLAAC doesn't do *anything* with prefixes. > To achieve the above objectives, a ND based message protocol is = introduced in the below draft that does what a DHCPv6 node do; without = introducing any new message types or new option types or flag types. >=20 > Can you all share your thoughts on the draft? My first thought is that a 2001 draft is a bit long in the tooth. Was it = really posted in June 2001? The second is that "autoconfiguration" is a bit different than anything = that one might solicit from or release to a network. For example, with = addresses, routing is handled by the router that advertised the prefix = in its RA (and maybe by other routers); when one solicits and starts to = use a prefix, one needs to advertise it in routing, which means that one = is going to need to implement and advertise some routing protocol. Third - L2TP is a bit dated. Maybe that's the reason for the 2001 date = on the draft. A 2013 article = (https://www.networkworld.com/article/2163334/tech-primers/what-can-l2tp-d= o-for-your-network-.html) calls it "unusual". What is your use case? = What are you trying to achieve? --Apple-Mail=_5CF419C5-9D1E-49EA-A057-69B1312DDAC5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlviUDUACgkQEhdRnd2G P+B1UxAAiVlFAoegc7n3Q4I3GhnaLZI/iO9/pEGaVGR8ROm8va42u6SIPmDUX5rI wSnSLSCleGpChd5cM7vIciG4UEfWsGC78Xp72lawhQV3ffu79y7KVq/n+5GhXbyU jQXoTfNnsJ6OHTDe/7oO21Hzt8ZD+nLgfb2FFNn3XoSUByMHc8yD2p7QCDY5iaIj JjgD4PYPRI5I+YIrt4v1CBWbUMg54nq3Zq1LJJgEgovmrVlFFkMch+3zrsf0aotv gB4xaUmpT3xDzk3b+HHAuKIPDNB/k1PvEeaxHB7oujyMUjCx1NedTPsOBvgveP1w 0UF/P3ilyiDgyyV52mPRqlCPnd+g8ZtAHMeJPGIgXOsaNiImR9mcR7aeaBvrjuJw qXRhA/RkJgPGZUo05O06Ab8PMw3nVzjKm73eoyGZLgJ0wGAX8B54jfaiUQt1UKAc f/1Iex57WeDnFsAJlNsdmxKZ5BXu5VRxgK/2mNGlMB+OUlZRqN7ghvXBXLrpjPCk tJv5Cdn39R+p5QSDTY296QbF3doffkkAZROthN2oJkJWGbijAMWAjgUdGyeEXAIt jgU0sjynTNhJlnwHnD4BndLtBofnPIzd88xqUaxGbvZRuIvoL0zTjClOuv2iPAC+ BmiviwjqP0gsPxTgqSb4lg2nnuMqZ+dlV8WMxXpWNkwOfSXNsgk= =dGJb -----END PGP SIGNATURE----- --Apple-Mail=_5CF419C5-9D1E-49EA-A057-69B1312DDAC5-- From nobody Tue Nov 6 19:31:50 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CEB127332 for ; Tue, 6 Nov 2018 19:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 5X5kcsHru9Zr for ; Tue, 6 Nov 2018 19:31:47 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 3E0A1126CB6 for ; Tue, 6 Nov 2018 19:31:47 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id u68so19801329qkg.9 for ; Tue, 06 Nov 2018 19:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=E4hxupNc5aWmbpsx0zznFeKiLkSmqH3es5voRcukGqE=; b=U5S6vAG4z9A/TNZ5Gp7itGuhVglvKy1Z/+UNk9GcVMTe000MPJDsKgTuKmU3gVOkFV MTvOBnsFWh8bs1v3ROuCE4TEv3ZvjBMXFZqjzRzd212NO8hRt/Hm/PDX6500ZwQBif4n J3Di9c6LdAVDDQ11IwS0UAmhB6uhiXaDtn5i/0u2843XVoCr8+jTWxUaukogNv3sElu4 KMdNOoVFoMsnNx6Dy9lFrBaB2pZK9in2ZiLm7ax7kUNdFOB/6oYx7oFEDGdVt2wgYPe8 QrUcKYDkH6m5F4WawV8GkmasJatxUgEq0eXUjuH2UjRHNBFCR/RgwSh28KE1NHHcgNwg s+6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E4hxupNc5aWmbpsx0zznFeKiLkSmqH3es5voRcukGqE=; b=YYVDPQHVeCq/HylgOsfo1MlV1Gpvs4RChP49KeaVZN7Jyp6JyWIfPvejMNuwmph8dO ETMZgYvnCJ56Km8VR+WnWqtMysfiW7bjPquZhNy18ebfk8RaZgFW5jMz9Wn53LBdTCIo f9p07OEPUjLqffbe3rTSszBJujLqpkWwKoIrtUhSof+KDTEVz/bbjTCG/S0VfqBWI8oH B4vY9rCoSWY9gTgIAgfxci+FIVh93BUJ6w3el935Ekvx5L4V6+GuojVorXsaiLVDb8ja nt9nyhvta60euUjV2Q5M0FleD1njojFUBvW+EjgU24x2pD8HD1Dml/aBax5DKlMiYCvD Gbpw== X-Gm-Message-State: AGRZ1gJFrV2BK6WxCzATda2UXIuHKOsxNdJgOvKT5d/JxHPA02Sth+X3 QMCWSdEHjhnvqGbcgb6sSvW+ta+YBqtBu4xtB06J78AkE+k= X-Google-Smtp-Source: AJdET5fyzDvVUM7vU6r7xQKOhJaApMHtMfBmOiBby5fp1SF1AurHw8TKrx2scCdL5jNPT9Zxs5hKVqm00BN9IrjpqaA= X-Received: by 2002:a37:aa91:: with SMTP id t139mr149816qke.139.1541561506020; Tue, 06 Nov 2018 19:31:46 -0800 (PST) MIME-Version: 1.0 From: Jen Linkova Date: Wed, 7 Nov 2018 14:31:34 +1100 Message-ID: Subject: Non-/96 pref64 use cases To: 6man , xing@cernet.edu.cn Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 03:31:48 -0000 It looks like there are a number of options to encode non/96 pref64 in an RA but before we start discussing them I'd like to understand the use case better. Even after re-reading RFC6052 I'm not sure what practical problem can not be solved with /96 prefix and requires using shorter pref64? Could anyone describe a use case for this? The only one I can this of is using the network equipment which is not capable of carrying routes longer than /64. Xing, AFAIR you made a comment yesterday saying that you have a use case for non-/96 prefixes. Would you be able to elaborate on this? Thanks! -- SY, Jen Linkova aka Furry From nobody Tue Nov 6 19:56:51 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1983127148 for ; Tue, 6 Nov 2018 19:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 8PBewpHhrMYF for ; Tue, 6 Nov 2018 19:56:47 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 1B472130E58 for ; Tue, 6 Nov 2018 19:56:47 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id h21-v6so11861018edq.9 for ; Tue, 06 Nov 2018 19:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+d8nAH5pyvYuAoDJfzk3ozAViqvAX8+7VdeZUg/DfsE=; b=S+OHTMjstGSDbecD+v8p2vOq5hT5ah4AOErmPeapJ0m0rPmYkTTfUug1OUlOnJJqw8 87uX0OusMMhbwcamuQH19w2onUvWO5ksVR/YyANg/qV1Ni0vNu7hOBI1kpb/NAQDjiu4 vYRQO8ajunjAS7TH52BttKp50uyjGAzcAjOM9OoMYAa1C7FEsKCK4wNlphNIKDhYkIYe c/n/itktg6L96affTy2j4Qpk1qPf54E5T58aVihUuxAIl4HwLF75JzqBmfZTtZpg+A4Y VkTBtvh9RDmt3YUmyOIuLET/WE43qtKXHXCS84a52O3QlUehh1FHxiFodAPcyzHV1l+k 3Hlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+d8nAH5pyvYuAoDJfzk3ozAViqvAX8+7VdeZUg/DfsE=; b=sr/+CYq+YetEwR5lZxYNPMcUEM/US6mToYB8sO62FMAENWUxk3PO2p3gGdVHu70h0H tTRPVJV3y0rb0DJk+UE/UVzSlub/lO+WNn43bLaLs2CWLUa311kgDZTAGFqcguD1Cn2s RStr9+pF5xI/0Od8z8VC6HyizV3B7EWLJTLBJmsod9MQX+i5ODBw15/7+w7vYpPhsDPU 7g6kLA2OZcDQ9ez6Kbb4hTQ4Nzl+sVEdP35qzx9Nwb0FQVmMzylIRn56R4WkGHOtdpdJ FNnPaDXlcgXiXMQpyIct+SBCuH/K3JcbjUYxJ/pi/eMoj9T+8wexG8V5+27ydg8Nk3ZN CQWw== X-Gm-Message-State: AGRZ1gKCF+KfDW1cJVpy9avFA4iVm6UJ3iCJloycCqXaoFuGDJHHWaPq 8oitNeKF6Fdwkean+80OSkOde5choUI= X-Google-Smtp-Source: AJdET5cSok5gx5r/lD8BSohyUAsnuQYe05u6x51rCuy9O+BZuXgrMDdcszNhXPsihn6LGIKxLCsUgg== X-Received: by 2002:a17:906:7308:: with SMTP id d8-v6mr454278ejl.162.1541563005638; Tue, 06 Nov 2018 19:56:45 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:9df0:b919:995c:c72b? ([2001:67c:1232:144:9df0:b919:995c:c72b]) by smtp.gmail.com with ESMTPSA id br3-v6sm358528ejb.24.2018.11.06.19.56.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 19:56:44 -0800 (PST) From: Fred Baker Message-Id: <80A97C24-17BE-41E5-B78C-E0802096720B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_EC1BCBF4-C9DA-434F-8664-E7E6651ACFA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Non-/96 pref64 use cases Date: Wed, 7 Nov 2018 10:56:38 +0700 In-Reply-To: Cc: 6man , Xing Li To: Jen Linkova References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 03:56:50 -0000 --Apple-Mail=_EC1BCBF4-C9DA-434F-8664-E7E6651ACFA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 7, 2018, at 10:31 AM, Jen Linkova wrote: >=20 > Xing, AFAIR you made a comment yesterday saying that you have a use > case for non-/96 prefixes. Would you be able to elaborate on this? The CERNET2 situation is this. They have 1000+ campuses, and distribute = one or more IPv4 translation prefixes among IPv6-only servers in the = network that are accessible from the IPv4-only CERNET via stateless = translation. Having the embedded IPv4 prefix straddle bit 64 means that = they can route from the translator to data centers whose prefix is the = upper part of an IPv4 address embedded in an IPv6 prefix, and the lower = part of the address is in the IID. The servers themselves are IPv6-only, = and can't distinguish the IPv4-embedded IPv6 addresses from other IPv6 = addresses. It's all about routing. Yes, they could use a /96 prefix, if they have a LOT MORE IPv4 prefixes = work with. = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_EC1BCBF4-C9DA-434F-8664-E7E6651ACFA7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlviYnYACgkQEhdRnd2G P+BmSA//XUUVue7xnN9kyPEfzNCPURMbqlLKzZ8U9aHXUjhWJxWxxapD+IDmPQfH 1mLw5yUw4zJzgrS+mBzhV5BvFZ6SncMU87NX5WakIGUCVNBKEktK0JhHwY1Pz0MQ kjDD7cQ+yQkZ5BHJ8ep+fzhWcQQ0vXlTh/fI2zboke9rDlmKkLfc8LPNDcINXEXh SkAlLLX5sRM1UzCj3mfs7tIDe+GHnwe45LLxmrv3qXQ91c6b5Km0n0RzOi/+Ypt0 JcgDT1w9QBuhFLHUFsK7hDN6AT+BEatNj0d7AMXuFA0sCcwDCUNBPyzoJhQTedxC oy6Z0M5w4mxiMwwn9uRwtk3OwbKz2ATItfKvjUH5/MHp/rgGpe+GfYS8BrrXeLKc fROSjzv4pY+/h8HqYO2GCQiOlF+byN+zE4Lo8XBsqAJ9XJuY9PlWX/JK9MPrd9SE yohn1nhkpXs1m24YsP3Kip+FaHwde6FmpbZhr4XmiJ+6dha67CqyEAqv2rxu8qHn +FwP5usM9u6dhzL8czv8tOIBtNJzqqDaTHq/XgngRXsaAWRznqKahswtA0rkb97x b0oa3NqTkFPO0BkJEpQBTObvmwlhWIeJyGRd6hm0YRY7EcyKAlwZlOXnnuVaLjnj LLFfR+LeOZz5E1BheTTXRVOZD4VJStnotfQWDVdcbh2bFEuIIlU= =xL7E -----END PGP SIGNATURE----- --Apple-Mail=_EC1BCBF4-C9DA-434F-8664-E7E6651ACFA7-- From nobody Tue Nov 6 20:12:06 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0710127148 for ; Tue, 6 Nov 2018 20:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 XenDBZhbNDOv for ; Tue, 6 Nov 2018 20:12:00 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 5CD35126CB6 for <6man@ietf.org>; Tue, 6 Nov 2018 20:12:00 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id y22-v6so10945312ioj.13 for <6man@ietf.org>; Tue, 06 Nov 2018 20:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jdrrWyzSWSrEz28AK7UAOkOfgk2toJjEhkCjnwIHBo8=; b=fEHIPloT1i2YkB5QOoJASJ0hJAs7z7Be4xFHqNBlKM8CFbNgzDN79ePhSZeuVsMoRM 4tQRviVm2EtmKG8B4zGZjolt1IOb2AlQP3FE97Fmmq/KG9qw+hXiyUABJr/shVAanYqj P+Ism8hDbN3plpnb4IkItf00JDdt575x/Js3otO20fU0211bv02gHYY2gLvxpzB2QdFY 53wQ4MRhDoUDfocDmQzz07gx/vY94qW5/5qm5ImQwgdMqRp/YGC9OKyShcPsl7wqyw/K WD5UCEFk3zj5U+07hRZO6QTj37wUlrYnmX6z9YGfSkIafIritbNw8ZWEkeYFTvlxOmxZ SJTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jdrrWyzSWSrEz28AK7UAOkOfgk2toJjEhkCjnwIHBo8=; b=c68ooz/QZAp1xIGuw2HGLNBiVSrlz5/OJZo8uLS5j32GrzoiUR3k0vbAlK8Z8qSmmO XOmlE+iK1lXIJMN3pQnfGQW5Z458lUvLPELxxxTl0RK1ZgwluTJnp+khCEe2hcTXcUhF KHL6pBNx+q58Mb5OdP2uwkrJXfQltiq4f+YxYRosnuHC5TgyRZOvMM1j6Vha4XJtZ8tu 6rgGfPIH8CRHqGaihn+wBeOCewxCf1mzehe4J3/4j3rKeItFQFi0HEO5SSq3PtG9v9ou uB4i5bjbJX39knOtqEzXn+b/eVNxumSdRN1xvY8SB3IcnGLulYQ2VfnSXcdBN7HktKcE D0hw== X-Gm-Message-State: AGRZ1gIo3PO3CLAuod+bszykxEep8eOjgHBNGPqygCfmrN4SmLcew6sO 1tyEvd4ihn0hF4GHqQRis9D0/qGB/ujPbJA8KeohScPdGTkokA== X-Google-Smtp-Source: AJdET5fIO3kbVh6UD5iGMbnOn5c9gClalSmC9FcXaRE7oqHPJQJ/qCtzNLS844TPwRIT5C2Wg+jPeN8//c74NJJHDhI= X-Received: by 2002:a6b:3e57:: with SMTP id l84-v6mr228539ioa.252.1541563919348; Tue, 06 Nov 2018 20:11:59 -0800 (PST) MIME-Version: 1.0 References: <514D1C95-B792-4164-987D-A7D2251252D8@consulintel.es> In-Reply-To: From: Lorenzo Colitti Date: Wed, 7 Nov 2018 11:11:45 +0700 Message-ID: Subject: Re: DNS64 pref option. To: Mark Andrews Cc: Jordi Palet Martinez , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000d0496d057a0b5156" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 04:12:04 -0000 --000000000000d0496d057a0b5156 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I still don't see a use case here. By definition, this is only useful if the host has both an IPv4 and IPv6 addresses. If the host has an IPv4 address, then it must have global reachability (either through NAT44 or 464xlat or whatever else) because otherwise IPv4 apps will be broken. If it does have global reachability, then there is no use point in the host doing any DNS64 synthesis. IPv4 traffic will use IPv4 (which may end up going through 464xlat and NAT64), and native IPv6 traffic will use IPv6. What am I missing? On Wed, Nov 7, 2018 at 3:39 AM Mark Andrews wrote: > Dual stack network doesn=E2=80=99t mean all devices connected to it are d= ual > stack. There is still a lot of IPv4 only garbage being sold with some > classes of device without a IPv6 capable alternative. > > Deliberately creating bad AAAA records is a bad thing. Sending traffic t= o > those addresses is a bad thing. > > If you have a internally routed local dual stack network you don=E2=80=99= t even > have the IPv4 default pointing at a local CLAT to help. > > As for Ipv4only.arpa APL records should also be published there. > -- > Mark Andrews > > > On 7 Nov 2018, at 03:52, JORDI PALET MARTINEZ < > jordi.palet@consulintel.es> wrote: > > > > Hi Mark, > > > > Trying to understand your scenario ... > > > > Let's say I've an enterprise network which is dual-stack. > > > > In the same network (before the NAT64), you have servers, with use > private IPv4 addresses and they have A records for their names. > > > > The ideal solution, of course, is to have those servers with also AAAA > records and be dual-stacked. > > > > Is this your scenario? > > > > So, if we have a way to inform the any "entity" doing the DNS64 functio= n > to not synthetize the AAAA RRs, you will reach those host using IPv4 in t= he > private network. > > > > I'm assuming that the "entity" doing the DNS64 is the stack, happy > eyeballs, or similar, in the local host that want to reach the IPv4-only > server. Because the problem doesn't exist if the synthesis is done in a > DNS64 server, as you can then use the mapping-out function. I described i= t > in section 4.1.6. Mapping-out IPv4 addresses (discussing there the DNSSE= C > implications), of > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment. > > > > In the case you describe, this will only happen if the first-hop router > from the LAN where a host tries to reach one of those servers, doesn't ha= ve > a CLAT, otherwise even in the case it gets only an A record, will transla= te > it (NAT46). > > > > BUT, if this network is dual-stack, why I need a NAT64/DNS64 at all? > > > > Regards, > > Jordi > > > > > > > > =EF=BB=BF-----Mensaje original----- > > De: ipv6 en nombre de Mark Andrews < > marka@isc.org> > > Fecha: martes, 6 de noviembre de 2018, 16:03 > > Para: Lorenzo Colitti > > CC: 6man <6man@ietf.org> > > Asunto: Re: DNS64 pref option. > > > > > > > >> On 6 Nov 2018, at 7:52 pm, Lorenzo Colitti wrote: > >> > >> On Tue, Nov 6, 2018 at 3:43 PM Mark Andrews wrote: > >>> =E2=80=A2 AIUI, the option is not useful on an IPv6-only network= . It is > only useful in the case where the host has an IPv4 address. In that case > the network might as well provide IPv4. > >> > >> For local ipv6-only only the filtering of IPv6 is useful and possibly > could be skipped to just use well known values to skip. > >> > >> What would be the purpose of such filters? A host that supports 464xla= t > is just going to get the A record and send the packet to the NAT64 anyway= , > no? > >> > >>> Mark, do you have a use case for #4? It's clear that this would be > useful DNS64 translator that provides service to other hosts, but for the > case where the host is just doing DNS64 synthesis for itself, the use cas= e > seems less clear. > >> > >> The host still needs to know what addresses to not translate at the > application level so long as we are locally dual stack. You don=E2=80=99= t want to > send local traffic for IPv4 only local devices through the NAT64. > >> > >> Can you provide an example scenario here? A host on a home network tha= t > has IPv4 as well as NAT64? Why would you deploy this as opposed to doing, > say, 464xlat on the home gateway? > > > > Because you want to move the traffic to IPv6 as early as possible to > remove load from the router. > > Because your router doesn=E2=80=99t have a CLAT. > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > > > --000000000000d0496d057a0b5156 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I still don't see a use case here.

    = By definition, this is only useful if the host has both an IPv4 and IPv6 ad= dresses. If the host has an IPv4 address, then it must have global reachabi= lity (either through NAT44 or 464xlat or whatever else) because otherwise I= Pv4 apps will be broken. If it does have global reachability, then there is= no use point in the host doing any DNS64 synthesis. IPv4 traffic will use = IPv4 (which may end up going through 464xlat and NAT64), and native IPv6 tr= affic will use IPv6.

    What am I missing?

    On Wed, Nov 7, 2018 at 3:3= 9 AM Mark Andrews <marka@isc.org>= ; wrote:
    Dual stack network doesn= =E2=80=99t mean all devices connected to it are dual stack.=C2=A0 =C2=A0The= re is still a lot of IPv4 only garbage being sold with some classes of devi= ce without a IPv6 capable alternative.

    Deliberately creating bad AAAA records is a bad thing.=C2=A0 Sending traffi= c to those addresses is a bad thing.

    If you have a internally routed local dual stack network you don=E2=80=99t = even have the IPv4 default pointing at a local CLAT to help.

    As for Ipv4only.arpa APL records should also be published there.=C2=A0 =C2= =A0
    --
    Mark Andrews

    > On 7 Nov 2018, at 03:52, JORDI PALET MARTINEZ <jordi.palet@consulintel.es&= gt; wrote:
    >
    > Hi Mark,
    >
    > Trying to understand your scenario ...
    >
    > Let's say I've an enterprise network which is dual-stack.
    >
    > In the same network (before the NAT64), you have servers, with use pri= vate IPv4 addresses and they have A records for their names.
    >
    > The ideal solution, of course, is to have those servers with also AAAA= records and be dual-stacked.
    >
    > Is this your scenario?
    >
    > So, if we have a way to inform the any "entity" doing the DN= S64 function to not synthetize the AAAA RRs, you will reach those host usin= g IPv4 in the private network.
    >
    > I'm assuming that the "entity" doing the DNS64 is the st= ack, happy eyeballs, or similar, in the local host that want to reach the I= Pv4-only server. Because the problem doesn't exist if the synthesis is = done in a DNS64 server, as you can then use the mapping-out function. I des= cribed it in section 4.1.6.=C2=A0 Mapping-out IPv4 addresses (discussing th= ere the DNSSEC implications), of h= ttps://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment.
    >
    > In the case you describe, this will only happen if the first-hop route= r from the LAN where a host tries to reach one of those servers, doesn'= t have a CLAT, otherwise even in the case it gets only an A record, will tr= anslate it (NAT46).
    >
    > BUT, if this network is dual-stack, why I need a NAT64/DNS64 at all? >
    > Regards,
    > Jordi
    >
    >
    >
    > =EF=BB=BF-----Mensaje original-----
    > De: ipv6 <ipv6-bounces@ietf.org> en nombre de Mark Andrews <marka@isc.org>
    > Fecha: martes, 6 de noviembre de 2018, 16:03
    > Para: Lorenzo Colitti <lorenzo@google.com>
    > CC: 6man <6man@i= etf.org>
    > Asunto: Re: DNS64 pref option.
    >
    >
    >
    >> On 6 Nov 2018, at 7:52 pm, Lorenzo Colitti <lorenzo@google.com> wrote:
    >>
    >> On Tue, Nov 6, 2018 at 3:43 PM Mark Andrews <marka@isc.org> wrote:
    >>>=C2=A0 =C2=A0 =C2=A0 =E2=80=A2 AIUI, the option is not useful o= n an IPv6-only network. It is only useful in the case where the host has an= IPv4 address. In that case the network might as well provide IPv4.
    >>
    >> For local ipv6-only only the filtering of IPv6 is useful and possi= bly could be skipped to just use well known values to skip.
    >>
    >> What would be the purpose of such filters? A host that supports 46= 4xlat is just going to get the A record and send the packet to the NAT64 an= yway, no?
    >>
    >>> Mark, do you have a use case for #4? It's clear that this = would be useful DNS64 translator that provides service to other hosts, but = for the case where the host is just doing DNS64 synthesis for itself, the u= se case seems less clear.
    >>
    >> The host still needs to know what addresses to not translate at th= e application level so long as we are locally dual stack.=C2=A0 You don=E2= =80=99t want to send local traffic for IPv4 only local devices through the = NAT64.
    >>
    >> Can you provide an example scenario here? A host on a home network= that has IPv4 as well as NAT64? Why would you deploy this as opposed to do= ing, say, 464xlat on the home gateway?
    >
    >=C2=A0 =C2=A0 Because you want to move the traffic to IPv6 as early as = possible to remove load from the router.
    >=C2=A0 =C2=A0 Because your router doesn=E2=80=99t have a CLAT.
    >
    >=C2=A0 =C2=A0 --
    >=C2=A0 =C2=A0 Mark Andrews, ISC
    >=C2=A0 =C2=A0 1 Seymour St., Dundas Valley, NSW 2117, Australia
    >=C2=A0 =C2=A0 PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 INTERNET: = marka@isc.org
    >
    >=C2=A0 =C2=A0 ---------------------------------------------------------= -----------
    >=C2=A0 =C2=A0 IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 ipv6@i= etf.org
    >=C2=A0 =C2=A0 Administrative Requests: https://www.iet= f.org/mailman/listinfo/ipv6
    >=C2=A0 =C2=A0 ---------------------------------------------------------= -----------
    >
    >
    >
    >
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > The IPv6 Company
    >
    > This electronic message contains information which may be privileged o= r confidential. The information is intended to be for the exclusive use of = the individual(s) named above and further non-explicilty authorized disclos= ure, copying, distribution or use of the contents of this information, even= if partially, including attached files, is strictly prohibited and will be= considered a criminal offense. If you are not the intended recipient be aw= are that any disclosure, copying, distribution or use of the contents of th= is information, even if partially, including attached files, is strictly pr= ohibited, will be considered a criminal offense, so you must reply to the o= riginal sender to inform about this communication and delete it.
    >
    >
    >

    --000000000000d0496d057a0b5156-- From nobody Tue Nov 6 20:16:50 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C991D130DC0 for ; Tue, 6 Nov 2018 20:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 QRKzIVjnOePJ for ; Tue, 6 Nov 2018 20:16:47 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 E6ACF12785F for ; Tue, 6 Nov 2018 20:16:46 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id q18-v6so10973455iod.5 for ; Tue, 06 Nov 2018 20:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SUrKtiLmfqV3M5mirp7WKkIJiyqpseied0LpFiPnvTU=; b=rJPbVZYfNL5zpE1O/RZxBwJnYJcQClCzD0KCJYLVkmLKplozjeQ6ApaueJjiXoseYP YkMVur3RMCfR8JiQFRsqkcQJYTOD6FQOl1uy1VoS+FoXyLoCS6rPszQvOkAyhD9cxuZe b/JwJNXnG0pQ4IQtgReajHdWlkFSebzEWjzDFlO0nBOfKr4BaxLQ8CkYK5hNTQ6GNJvo Hqr3Ii0UEJOOFmEztcp7P6KwKfuW+FGQGvXjROqTT+NgUPD8WddnbuiE196C/3dTvyx2 IhMhILJPOTc83GFuTaLFZjELR6s24NSGRXQMjI0MNelbJAEHZ8TE4b5A5Sg+dHdDcJSB aOfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SUrKtiLmfqV3M5mirp7WKkIJiyqpseied0LpFiPnvTU=; b=Oba+apr8S9kRKVTKr1+5DrUAbCcIq6eP8IlHHPPNrwV/yjNGNTSsuJbeZ5uVvndEdr vjyi3q3CTcmjOy1RT9T5CpcE1fhQluvPnBrsp1IYZyYGIU7z3lU9yOEDyL3cWQr7V2i+ 3wWrY7Mqb7Yo+coP/UOxiBJZjpCWaTCTo+Vl6osS8wT99ENrRKO3PAdftLigx0o2ilox iE6TsuqCinALqMc2JUEd7TEal6801ah1PjCJ510js33D3BV/nR4udWO20vYHdWbAIVgy D/WdzyYtkl8GxT97FS9Xwpd09dZw70bYSsh+6hsdZieqWmn62PoKpZtBSIo/Vh5IcW8l 3LRw== X-Gm-Message-State: AGRZ1gLKuwMBaNuLvtcvo1qS7LJB9R2ij1XrcjF/CWKoKua8SYlm9vBz zahSLm2/qqQq/H6lyPMFe1o8r0lwMb0XDQiFal8sPw== X-Google-Smtp-Source: AJdET5e0qkKXpkjn3V9E6Kr+MzTEzGVGLW4+crQRPHlYSnOgj+lV6iDgC7/hoX6SkPIwxfISUOj7x32/9d4yYrAgKfA= X-Received: by 2002:a6b:3e57:: with SMTP id l84-v6mr237285ioa.252.1541564205909; Tue, 06 Nov 2018 20:16:45 -0800 (PST) MIME-Version: 1.0 References: <80A97C24-17BE-41E5-B78C-E0802096720B@gmail.com> In-Reply-To: <80A97C24-17BE-41E5-B78C-E0802096720B@gmail.com> From: Lorenzo Colitti Date: Wed, 7 Nov 2018 11:16:33 +0700 Message-ID: Subject: Re: Non-/96 pref64 use cases To: Fred Baker Cc: Jen Linkova , Xing Li , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="000000000000e4c3d3057a0b6254" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 04:16:49 -0000 --000000000000e4c3d3057a0b6254 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 7, 2018 at 10:57 AM Fred Baker wrote: > > > > On Nov 7, 2018, at 10:31 AM, Jen Linkova wrote: > > > > Xing, AFAIR you made a comment yesterday saying that you have a use > > case for non-/96 prefixes. Would you be able to elaborate on this? > > The CERNET2 situation is this. They have 1000+ campuses, and distribute > one or more IPv4 translation prefixes among IPv6-only servers in the > network that are accessible from the IPv4-only CERNET via stateless > translation. Having the embedded IPv4 prefix straddle bit 64 means that > they can route from the translator to data centers whose prefix is the > upper part of an IPv4 address embedded in an IPv6 prefix, and the lower > part of the address is in the IID. The servers themselves are IPv6-only, > and can't distinguish the IPv4-embedded IPv6 addresses from other IPv6 > addresses. > > It's all about routing. > > Yes, they could use a /96 prefix, if they have a LOT MORE IPv4 prefixes > work with. > Fred, that explanation isn't very easy to understand. Could you provide an example? --000000000000e4c3d3057a0b6254 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Wed, Nov 7,= 2018 at 10:57 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:


    > On Nov 7, 2018, at 10:31 AM, Jen Linkova <furry13@gmail.com> wrote:
    >
    > Xing, AFAIR you made a comment yesterday saying that you have a use > case for non-/96 prefixes. Would you be able to elaborate on this?

    The CERNET2 situation is this. They have 1000+ campuses, and distribute one= or more IPv4 translation prefixes among IPv6-only servers in the network t= hat are accessible from the IPv4-only CERNET via stateless translation. Hav= ing the embedded IPv4 prefix straddle bit 64 means that they can route from= the translator to data centers whose prefix is the upper part of an IPv4 a= ddress embedded in an IPv6 prefix, and the lower part of the address is in = the IID. The servers themselves are IPv6-only, and can't distinguish th= e IPv4-embedded IPv6 addresses from other IPv6 addresses.

    It's all about routing.

    Yes, they could use a /96 prefix, if they have a LOT MORE IPv4 prefixes wor= k with.

    Fred, that explanation isn'= t very easy to understand. Could you provide an example?
    --000000000000e4c3d3057a0b6254-- From nobody Tue Nov 6 20:37:53 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A57E130ED7 for ; Tue, 6 Nov 2018 20:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 QOagA2BeTVB2 for ; Tue, 6 Nov 2018 20:37:44 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 F2084130E2A for ; Tue, 6 Nov 2018 20:37:43 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id z16-v6so15931550wrv.2 for ; Tue, 06 Nov 2018 20:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9nhnltMrR07mnvfhRvtnHW4OMqNePgG+Eb/YZ7R4414=; b=fknr+AFECGyVCRo0cNMdPujAOeyxeiguE0a71lUdjMU2qdfgjzh9H+S42W8m2bfOyB 4mbC9EZrvPEqrvJvELJ5Sm1otP6gpNXypZClv8G+Vrld2oSh7fp3ZkDnQ5yC1J3aoIXz ALxH841pHe3JBRngn3DOHaFZFKMJ79ZO2l0zsmreGohIL3P5U6zeFIMBJz9GivRSslsN 3uwnYBpRl9cGIhwaZD6K+HsgBr4C9YY28QoilwmTOaDS3obPqsEVxaq1fUgxw9cKpE7v InBkeSfCf45iHQw5qyBjy5VJbn2x8oOJyMDwHSCx0HaTQpZxJqIGbl/CToH54DQLzHT1 ogtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9nhnltMrR07mnvfhRvtnHW4OMqNePgG+Eb/YZ7R4414=; b=LibLSc6whpQwOmHA3ttDz21rkS1Dy4fZK7pvU9s+RK9xXTtGkOS5Lo3VLI+e2XQB8f RpCVJHcsIDEW8iXCH0S7Tvkl0yKXQIVhlj8HWIulHWf35nxHWlZUWVeT5ge/bhjqJSSQ RN5CF9G6DWtN/8uMEl0oh0pj2QoqS/+Isg9r5SLJCYGe6v8AH+f46o8eO0Wm+FhHy0Af vdWak3frvn2P3/FbTtkHDBkASLB3woqJUyb38FOBJYizNIkALHNjrqEDZehMpVlJ0Ljn Mqe7IxreCdmexbLQhZY+oiRgkER+2+Vm3kdHj9e4mXWFkaI3OyCfVK2tuxVfKDNiZavt MXRQ== X-Gm-Message-State: AGRZ1gJItipUoJMCds9W1f7/7cILjx6lV0BQ4X2CNk88mKRo1uD+HTtv 6iGr/nsJj2PhZO9Lbl8sUS0= X-Google-Smtp-Source: AJdET5d95yLiQkeasSZsYmdoP43qwu8aQJyNwZGmeuT054Y8jEAeF3j8+G6D/p8IvOHlc+LDb/oEIA== X-Received: by 2002:adf:e4c2:: with SMTP id v2-v6mr267287wrm.227.1541565462461; Tue, 06 Nov 2018 20:37:42 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:e9cd:f6d7:dd15:5e30? ([2001:67c:370:128:e9cd:f6d7:dd15:5e30]) by smtp.gmail.com with ESMTPSA id y131-v6sm2971630wmc.16.2018.11.06.20.37.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 20:37:41 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_12791E1A-DDF3-433F-B9B8-925F43F5334E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Comments on IPv4-only flag document Date: Wed, 7 Nov 2018 11:37:35 +0700 In-Reply-To: <54c87b58-6c7a-a360-9672-e9e103df9b87@gmail.com> Cc: Bob Hinden , IPv6 List To: Brian Carpenter References: <54c87b58-6c7a-a360-9672-e9e103df9b87@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 04:37:52 -0000 --Apple-Mail=_12791E1A-DDF3-433F-B9B8-925F43F5334E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, On the last point: > .... >> If a host has working IPv4 services or connectivity and receives a >> Router Advertisements packet with the IPv6-only flag set to 1 on the >> same link without any other IPv6 configuration (i.e., an otherwise >> IPv4-only link), it SHOULD consider the IPv6-Only flag a = configuration >> error and MAY continue to use IPv4. >=20 > I don't strongly object to this text, but as noted above, it may not > be an error or an attack: it may be an announcement by the admin that > she just switched off the IPv4 services. >=20 > BTW, the "MAY continue to use IPv4" is always true, as implied by the > SHOULD language in the draft. This was one of the conclusions in yesterday=E2=80=99s 6man discussion. = I think it is reasonable to have the draft be explicit that if the host = has working IPv4 connections (for example, via addresses received from = DHCPv4, not auto configured IPv4 addresses) then the flag can be = ignored. The case that started the idea in this draft was the IPv6-Only link at = IETF 100 meeting in Singapore, where there were no IPv4 services. The = goal is to turn off the background auto-configured IPv4 traffic and = resulting ARP, etc. Having this clarification will turn off this auto = configured traffic, but at the same time make the flag more robust = against attacks or misconfiguration on links with working IPv4 services. Bob --Apple-Mail=_12791E1A-DDF3-433F-B9B8-925F43F5334E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlvibA8ACgkQrut0EXfn u6gCIgf/Zg9F6oe8VnM1PBB8bhcAHxYuzBoHQZCdBwbGGVTq6nym5YeF42QC6FIk +ez753gyZMO1cEgAYHtVdY/bKuP7pt9EFPtgnqH5l2y0H2p/4XddDRZr89QOzxaO svXxNbgILUiSq0LBWHpAyLKNVaJum3+bPV9kdwp2BO80M3g12U62NabeAZ6Y80Nl tsDRMPMVuuHn2aEMIeQIlQF6CnAY6jmOw8rxdDqd2VFOD3nPe53V5DvMQPDD1GJq